Posts on Philly Mesh

FCC Regulations and MeshCore 500

Emily Boda — Wed, 02 Sep 2026 00:00:01 +0000

As a quick note, none of the Operations Division are lawyers, and none of us play lawyers on TV. Even though we discuss FCC regulations throughout this document, nothing in this document or FAQ is legal analysis or legal advice to anyone reading it. Please, for the love of heaven, always consult an actual lawyer when you have questions about the law, or FCC regulations.

Hey PhillyMesh community,

Our mesh is about to become a lot more fragmented

We, (along with many in the Meshtastic community) recently found out that most of Meshtastic’s presets are not in compliance with the FCC when the newest build of the Meshtastic app changed the USA default preset to LongTurbo. We don’t yet have any official word from the Meshtastic developers about this, but the following is our understanding.

Meshtastic uses a 250 kHz bandwidth by default, and FCC regulations state that devices in the 900 MHz ISM frequency band (that’s us) must use a bandwidth of 500 kHz or higher. The only Meshtastic preset that is in compliance and potentially viable for this area is LongTurbo, which we have tested extensively and determined doesn’t work well for long distance mesh communication in Philly. Other metro areas have corroborated this; LongTurbo doesn’t work well just about anywhere.

We have a blog post with all details of our LongTurbo test, but the summary is that there is a lot of interference within the ISM band, much of which is concentrated every 250 kHz (so, on .000, .250, .500, and .750 on each MHz frequency, with the worst of it being on .250/.750). Using only a 250 kHz slice of bandwidth (for example, from 915.000 to 915.250 MHz) allowed us to keep that interference on the edge of our communication spectrum. However, if we have to use 500 kHz bandwidth, we can’t avoid that interference (we’ve looked all over the ISM Band) and we confirmed (with your help in this summer’s tests) that our ability to communicate with Meshtastic is severely compromised.

So, what are we going to do?

We’re wrapping up our LF910 test and now moving to compliant presets. Because our Meshtastic LongTurbo testing went so poorly, the OpsDiv started scrambling to find options that might work better to achieve the goal of a Philadelphia-area-wide mesh network that allows us to communicate from the city to the burbs. We started informally testing some custom settings for MeshCore at 500 kHz (we’re calling it “MeshCore 500”) and found that it worked surprisingly well.

One of the biggest reasons we’ve seen better results with MeshCore is because it is more resilient due to its message-prioritized routing. The settings we’ve been tweaking during this summer’s testing period to try to improve Meshtastic’s performance (reducing position, telemetry, nodeinfo announcements, and more) are pre-baked into the MeshCore firmware. The additional hops MeshCore allows should mitigate the loss of reach/distance nodes that is caused by operating with a bandwidth that has more interference.

Based on that testing, going forward, the handful of PhillyMesh infrastructure nodes that are currently installed will be tuned to MeshCore 500 because we believe this gives us a better chance to create a Philadelphia-area-wide network. Additionally, we have leads on installing several dual-radio nodes at high sites and these will feature both Meshtastic LongTurbo and MeshCore 500. We expect that given time, Meshtastic LongTurbo may become a more viable short-distance mesh network, especially as Meshtastic firmware matures and resolves some of the issues with overly-frequent position/telemetry/nodeinfo reports. However, MeshCore 500 is currently performing much better and will likely always be better for long-distance mesh communication. As has always been the case, you’re welcome to install whatever preset and mesh technology you’re comfortable with running on your personal nodes.

We considered announcing MeshCore 500 as a test, but we’ve been doing a lot of testing this summer and, honestly, a week-long test for something we already know initially shows promise won’t get us the results we need. We decided to announce this as a transition (kind of like our indefinite LF910 test) and let the people decide if they want to participate. If things go poorly with MeshCore 500 or the technology changes in six months or a year (or the Meshtastic project sorts this whole thing out next week and makes LongFast FCC-compliant in a way that doesn’t nuke its effectiveness) we might just go back to Meshtastic LongFast as our default. But we wanted to make one unified recommendation for right now, for those who want to test out something new with us, since we won’t be able to use LongFast for the foreseeable future. Plus, trying new mesh networks is fun!

Unfortunately, the days of defaulting to Meshtastic LongFast and everyone being on the same mesh network are likely behind us. We expect some people will stay on Meshtastic LongFast, and once Meshtastic’s default preset becomes LongTurbo, we expect many people new to the hobby (an estimated 20 people per week in our area) to be on LongTurbo. We also expect many of those who have been dabbling in MeshCore and seeing how well it performs to keep tinkering with MeshCore 500. There will likely not be one consensus network going forward, but we hope that you’ll try out MeshCore 500 with us.

You do not have to buy new hardware to try out MeshCore 500: almost all Meshtastic node hardware models are compatible with MeshCore and you can flash between the two as easily as you can flash between versions of the Meshtastic firmware. If you try MeshCore and want to go back to Meshtastic, it’s completely and easily reversible in a minute or so. After reading the guide to flashing your node below, if you have any questions about converting your node and changing settings, please reach out on the #meshcore-philly channel in the Discord. We are happy to help guide folks through this transition!

“But I thought this was a Meshtastic server?” Technically, the server name is just “Philly Radio & Mesh”… and if you take a look at the PhillyMesh website, you’ll see posts as far back as 2016 (before Meshtastic was invented) exploring mesh networks in the Philadelphia area. Meshtastic has been a focus lately because it’s been more popular in the Philadelphia area. We’re here to have a good time with all kinds of mesh networks.

Fractured PhillyMesh on the airwaves, unified PhillyMesh in our hearts

This is not a change we’re introducing lightly. Many of us have poured time, energy, passion, tears, and money into testing Meshtastic nodes and settings. We want to ensure that you (the mesh users), the PRM Ops Division, and especially the gracious hosts of our infrastructure nodes do not run astray of FCC regulations.

Large mesh networks like PhillyMesh rely on the power of numbers and agreement between its users to work. We each rely on each other’s nodes to relay our messages. Most of us remember the days when you’d leave a node in your window and not see another node for weeks. We knew a default preset change was coming and that it would cause our mesh to become fragmented, whether we wanted it to or not.

We had been preparing for that preset change, like many other metro areas have been doing, by testing to find a preset that works best for our area. With our better understanding of the rules, we realize that our previous choice of the best preset is no longer an option. We think that our best hope for FCC-compliant survival in the short term is MeshCore 500.

Love,

The PhillyMesh Operations Division

MeshCore and Meshtastic FCC-Compliant Settings

MeshCore

These are the settings we’re recommending for MeshCore 500. They are FCC-compliant and avoid the heaviest ISM band interference that we found during our testing in the Philadelphia area. Please make sure your MeshCore node is updated to the latest firmware before using these settings!

Frequency: 902.250 MHz
Bandwidth: 500 kHz
Spreading Factor: 11
Coding Rate: 4/5 (some apps may just say 5)
Path Hash Mode: 1 (2-byte mode, some apps list this setting as 1-2 byte)

We also wrote these pages that might be of help if you’re new to MeshCore:

Meshtastic

These are the new default, FCC-compliant settings, that the Meshtastic project recommends for the US. Please update your firmware to the latest stable/beta version first!

Frequency: 908.75 MHz (this is the default slot, which you can enter as 0 or 14)
Preset: LongTurbo

FAQ

I’m sure you have a lot more questions! Hopefully we answer a good number of them below, otherwise please ask/vent/grieve the loss of 250 kHz bandwidth in the Discord.

What is this “PhillyMesh Operations Division”/“OpsDiv”? Just who the heck are you folks?

The PhillyMesh Operations Division is some of the OGs from the Philly Radio & Mesh Discord server. The name “Operations Division” came about because the server admin is a Trekkie, and she couldn’t resist the name. If you’ve seen anyone teach a class about Meshtastic, foot the bill for the website, table for the group at a local event, organize a PhillyMesh happy hour, or coordinate an infrastructure node install with another local org; that was one of the Ops folks. Feel free to bribe us with good node locations, bad puns, and Malort.

What are presets and what is LongFast?

Meshtastic has many settings that allow you to change what slice of frequency you send messages in. You can customize these settings almost indefinitely, but most of the time people choose between a few different presets which are a standardized set of settings. Other Meshtastic users must (for the most part) have the same settings as you in order to receive your messages and be on the same mesh network.

Meshtastic’s default settings are a preset called LongFast. This preset uses a bandwidth of 250 kHz, which we now know is in violation of FCC regulations.

Can you tell me more about this bandwidth thing?

Meshtastic (and MeshCore) packets are sent across a frequency spectrum. That spectrum is determined by choosing a starting frequency (or, with Meshtastic, you often choose a “Frequency Slot” and the firmware uses that to calculate your starting frequency) and then setting a bandwidth which determines how large the range of the spectrum wil be. For example if your frequency is 906.500 MHz and your bandwidth is 250 kHz (0.250 MHz), you will be transmitting from 906.500 MHz to 906.750 MHz.

The only preset that uses a 500 kHz or higher bandwidth is LongTurbo, the rest use 250 kHz. In our region there is a lot of interference put off by devices using RFID, among many other things. The interference exists every 250 kHz (at the .000, .250, .500, and .750 points of each frequency) and is strongest at .250 and .750. Using a smaller bandwidth like 250 kHz, Meshtastic packets are able to keep that interference at the edges and not be affected too much by it. However, because LongTurbo uses 500 kHz, no matter what starting frequency is chosen, it will always overlap with some of the interference.

Who is the FCC and why do I care about them?

The FCC makes and enforces the regulations regarding which frequency bands people and companies can use and what the rules are for the packets they send. As with all regulations in the US, it’s possible to get in trouble for unknowingly violating them (regardless of motive/intent), and that’s what we’ve all been doing while using Meshtastic on LongFast.

The FCC requires all packets sent in the ISM band (the band Meshtastic and MeshCore use) to have a bandwidth of 500 kHz or more. The only Meshtastic preset that uses a 500 kHz bandwidth is called LongTurbo, and that’s now what the Meshtastic project will be suggesting as the default in the US. The default MeshCore setting uses a 62.5 kHz bandwidth and is even less compliant, hence the custom settings to use a 500 kHz bandwidth.

Is this a new FCC regulation?

No. It seems that most people did not understand the FCC regulations. This includes Meshtastic devs, MeshCore devs, and device manufacturers selling devices where the default settings were out of compliance.

There was a misunderstanding among users that did read the regulations about how Meshtastic was operating, FHSS mode vs DTS mode, and the regulations are different for each. Those users who didn’t read the regulations figured if a project as big as this one was not in compliance with the FCC, we’d know about it. Well, now we know.

Does the FCC even care if we keep using Meshtastic LongFast?

At this point we don’t know what enforcement the FCC will have for these regulations. You, as an individual, can make your own determination if you want to continue to operate on Meshtastic LongFast and be in violation of FCC regulations. It is important to note that if you are a licensed ham radio operator your license could be at risk for knowingly operating devices in violation of FCC regulations. The risk of punishment for past actions is probably low in this case, however, you are now aware and must make your own decisions going forward.

As the group that is Philly Radio & Mesh, we feel it is important to stay in compliance for many reasons. Besides the obvious fact that violating FCC regulations is illegal, we have been partnering with non-profits such as Philly Community Wireless to host nodes, and we don’t want to get them or any of the building owners in legal trouble. We’ve been asked by local businesses and libraries to do talks about Meshtastic; we can’t in good conscience encourage new users to try something that we now know is illegal, and if people think we’re doing that, we won’t be asked back. Many of us are also licensed ham radio operators, and don’t want that hobby to be put into jeopardy by affiliation with this group. Even for non-hams, using the ISM band irresponsibly could result in the privilege of using that spectrum being revoked for everyone, especially in today’s environment of companies looking for spectrum to pivot to cellular 5G use.

What is MeshCore?

Meshtastic is a project that allows you to send messages over LoRa. There are other projects that do the same thing, one of which is MeshCore.

MeshCore and Meshtastic have recently grown side by side, learning and improving based on the other’s work. In general, MeshCore has been optimized for nodes to be placed in a stationary routing and learns what the most efficient way to route messages between nodes is to get the furthest reach. Meshtastic has historically assumed that all nodes are mobile and hasn’t added that routing part until recently.

In Philadelphia, Meshtastic has historically been more popular. In other areas, such as NE PA, MeshCore is more popular. And as an individual, it’s always more fun to join a mesh network that has more people on it, so the popularity is self-perpetuating.

More details about why we think MeshCore 500 is performing better than Meshtastic LongTurbo are in another FAQ below.

What is MeshCore 500?

Most people on MeshCore operate at a 62.5 kHz bandwidth (these are the USA default settings), which, it turns out, is also in violation of those pesky FCC regulations, but the technology supports a 500 kHz bandwidth just like Meshtastic does. We have been calling using MeshCore at 500 kHz “MeshCore 500” to differentiate it from the usual MeshCore at 62.5 kHz settings that most people are currently using.

I don’t want to try out MeshCore, but I do want to make sure I’m in compliance with the FCC. What should I do?

You should switch your Meshtastic node’s preset to LongTurbo. We recommend leaving your other frequency settings at default, so you can see as many other people on LongTurbo as possible. You will soon also see our dual-radio infrastructure nodes on Meshtastic LongTurbo as well, but the single-radio nodes will be on MeshCore 500.

Do I have to pay to use MeshCore?

No. MeshCore, unlike Meshtastic, has many third-party apps you can use to interface with your nodes. Some are paid and some have paid features, but there are some great ones you can use that are entirely free.

Dusty, who has been using MeshCore for a while, recommends the apps MeshCore One for iOS and MeshCore Open for Android. Both are entirely free to use.

If you’re a power user, RemoteTerm is a docker app like MeshMonitor and Kyle Yank has set up an instance of CoreScope, which is like Malla. Feel free to turn MQTT on and contribute (as long as you’re on 500 kHz).

Can licensed amateur radio operators continue to use Meshtastic and MeshCore at 250 kHz?

Yes. However, using Meshtastic as a licensed amateur radio operator requires you to not use encryption which means dropping packets from private channels and only using the default public channel (with the published key of AQ==). Setting your node to “ham mode” will do all of these things.

This is not compatible with the default Meshtastic network and won’t allow you to chat with non-licensed users on LongFast. If you’re intersted in getting your ham radio license, JawnCon, Philly’s local cybersecurity conference in October, has free classes and exams most years.

Amateur radio has several alternatives to the ISM band that have similar messaging functionality, including normal VHF APRS, UHF, LoRa APRS, FT8 (and derivatives), JS8 Call, VARA modes, Winlink, etc. Ask your friendly neighborhood ham in #amateur-radio in our Discord to learn more.

What settings are being recommended for MeshCore 500?

Some MeshCore apps have recommended presets and some don’t, but there are generally agreed upon default settings that most people use so they can communicate with each other. Those settings use 62.5 kHz as the bandwidth, which is in violation of FCC regulations.

We have outlined our custom settings in the next section below, which use a 500 kHz bandwidth. This means that, for the time being, the only other MeshCore nodes you’ll be able to communicate with are folks who heard about these settings from PhillyMesh. We do anticipate that once word gets out about the FCC regulations, we will see some current MeshCore users transition to 500 kHz bandwidth and find us. We are not making this change to be isolated or exclusionary, we are making this change for FCC compliance and sharing the settings that worked best in hopes of re-connecting with neighboring meshes again.

MeshCore’s reach is much wider than Meshtastic LongFast; the current most widely used (and non-FCC-compliant) settings result in Philly being reachable from as far north as New Hampshire and as far south as Kentucky, depending on the weather (check Kyle’s instance of CoreScope that uses MeshCore’s default settings to see all the repeaters he’s seen recently and you’ll get an idea of the reach). In order to keep the community we’ve had on Meshtastic LongFast together, we recommend everyone joins the #prm channel and uses that as the default comms channel. Once other meshes join our settings and the Public channel gets busy again, #prm can be a way to ensure our area’s unique culture has a home.

Why do we expect MeshCore to perform better at 500 kHz than Meshtastic does?

MeshCore has some key benefits compared to Meshtastic that will increase chances of success at this wider, more interference-heavy bandwidth.

Reduced Non-Message Traffic. Baked into the firmware are the settings we were asking Meshtastic users to change as part of this summer’s tests to reduce position reporting, telemetry, NodeInfo, etc. Without these packets clogging the mesh, there is more room for messages to reliably flow.
Higher Hop Limit. Where Meshtastic had a hop limit of 7 (and realistically only 4-5ish hops were viable), MeshCore has a hop limit of 64. We won’t need all 64 of those hops to talk across the Philly Mesh, but we know we will need more than the 4-5ish viable hops Meshtastic had. An increased hop limit will increase the functionality of the mesh to counter the degradation of node transmit/receive distance at 500 kHz bandwidth.
Better Routing. MeshCore prioritizes static routing compared to Meshtastic’s ad-hoc flood routing. There is still flood routing in MeshCore, but it uses it sparingly and instead focuses on building stable paths from router-to-router to reduce unnecessary retransmits. This means many nodes, especially in Center City who can reach a repeater, can stay in Bluetooth Companion mode (the equivalent of CLIENT_MUTE in Meshtastic). The reduction in unnecessary rebroadcasting also helps reduce packet collisions and noise floor, also mitigating the impacts of the higher interference on the 500 kHz bandwidth.
Better Battery Life. Because most nodes in Center City can stay in Bluetooth Companion mode, they won’t unnecessarily waste battery life rebroadcasting. This is a significant win for battery-run nodes, pocket nodes, small solar nodes, etc as they will live longer.

And we’ve seen this in practice. Compare our Malla instance (Meshtastic) to Kyle’s CoreScope instance (MeshCore). While on Meshtastic we see a couple of nodes further away, these are likely to be airplane nodes, or nodes that had their location incorrect. On MeshCore we see hundreds of repeaters further north than New York City and a handful down in North Carolina.

Could we just roll our own Meshtastic firmware to make Meshtastic on 500 kHz perform better?

We actually thought about this; we’ve been joking about making MalortCore for a while. However, in order to make Meshtastic on 500 kHz perform better we’d be doing things like increasing the number of allowed hops and improving routing, and we’d basically just be recreating MeshCore. We’d rather spend our energy building out local infrastructure that will benefit everyone in the area, instead of developing and administrating a third competing LoRa mesh project, which would just serve to further fragment the PhillyMesh.

I haven’t seen anything about a new Meshtastic preset. What’s your sourcing on this?

It seems a lot of this discussion has been happening in private Discords, so sourcing this is hard. However, it became clear when we saw that starting in Meshtastic version 2.8, the Meshtastic firmware will default to LongTurbo for users in the US. Mobile apps will warn users on the LongFast preset that their preset is violating FCC regulations and push them to move to LongTurbo. We believe this will cause many Meshtastic users, especially new ones, to use Meshtastic LongTurbo and effectively kill the current default Meshtastic LongFast network.

Meshtastic’s leadership has discussed on other Discords that further “friction” will come in version 3.0 and later.

Did some people know about this? It’s suspicious that we did LongTurbo tests a month before we found out that LongTurbo is the only legal default.

Some folks who follow the Meshtastic firmware GitHub repo and are part of other Meshtastic Discords had heard rumors that the default preset might be changing. No one knew why; we’re not even sure if the default preset change was because of the FCC regulations or because of this meshtastic.org post about LongFast not being the best default for cities.

We realized this default change would fracture the mesh significantly and our Discord would play a key role in informing users about the changes and helping support users change their existing nodes. We thought about it and decided to take the opportunity to not blindly trust the new recommended default, but to find a preset and custom settings that would actually improve PhillyMesh’s performance.

It wasn’t until we saw version 2.8 and this heated discussion in the MeshCore Github that the violation of FCC regulations became clear. This resulted in a few days of waiting to see if the Meshtastic project would say anything about it before we decided to stop waiting and make this post ourselves.

Shouldn’t someone be fixing this?

Meshtastic is a global project. Many of the developers are based in Europe, where the regulations are actually the opposite (in their 433 MHz frequency band the bandwidth must be less than 500 kHz). Only a small subset of the devices that hardware manufacturers sell are being used for Meshtastic, so they leave it up to the users to make sure their devices are in compliance. If there is a better solution to this issue, such as a different frequency band to use in North America for Meshtastic, we don’t see it arriving quickly.

Could lowering the power on Meshtastic transmissions allow us to still have a bandwidth of 250 kHz and be FCC-compliant?

Yes, but we’re pretty sure it would have to be lowered so much that Meshtastic LongFast would be completely useless. Some math by one of our members, KT3H, says that the power would be limited to something like 0.0006 Watts, which is tiny compared to the ~1 Watt we have been using. Lowering the power on Meshtastic LongFast that much would severely compromise our ability to communicate using Meshtastic. Messages wouldn’t be able to travel as far and the mesh would perform significantly worse. Using Meshtastic LongFast at a fraction of the power would be even worse than using Meshtastic LongTurbo.

That 0.0006 Watt number is very specific, how did you calculate it? Also, what are the actual regulations we’re discussing here?

Our understanding of the regulation is as follows (with the usual caveat that we are not lawyers and are awaiting official word on guidance): Unlicensed operation in the 902 MHz band is governed by 47 CFR Part 15 Subpart C. There are two sections that apply, and you must pick one to operate under. Under §15.247 the bandwidth must be no less than 500 kHz, but the power can be up to 1 Watt. Under §15.247 there is no bandwidth restriction, but the maximum field strength is 50 mV/m at a distance of 3 meters. This is equivalent to an output power of 0.0006 Watts.

Can we move to another frequency band that has different regulations?

Potentially. But that would require, first, a research effort to find one compatible with the Meshtastic project. Second, it would almost certainly require purchasing new antennas for all our nodes. And third, it would likely require us to purchase entirely new nodes (which would first need to be designed and manufactured) that are compatible with the new frequency. Unfortunately, we don’t see that happening anytime soon.

Is there a chance the FCC will change their regulations?

The FCC is largely concerned with regulating the frequency bands that they license for commercial use. While using amateur bands brings us nerds a lot of joy, it actually results in less money in licensing for the government. Furthermore, NextNav has been lobbying the FCC to further restrict amateur usage of the 900 MHz ISM band and reserve parts of it for commercial use. We consider ourselves lucky that NextNav hasn’t succeeded thus far, and unless an independently wealthy Meshtastic user wants to fund their own lobbying campaign, we see a change in FCC regulation to be unlikely.

Do we expect Meshtastic LongTurbo to perform better in the future than it did during our testing?

We do expect Meshtastic LongTurbo to perform marginally better once more people switch over to it. We didn’t have a large number of nodes participating in this test, and because LongTurbo messages don’t go very far we needed more nodes than we had to get a proper mesh going. We expect that as Meshtastic LongTurbo adoption increases (and as we install more well-placed infrastructure dual-radio nodes that support LongTurbo) we will be able to communicate better over short distances using LongTurbo. The reason we’re also focusing on building out MeshCore at 500 kHz is because those messages seem to be able to go a lot further, and that gives us the best shot to be able to communicate across our wide metro area, from Jersey to Delco and beyond.

A core goal of the group is to be accessible to those who are new to mesh networks and be in touch with whatever is most used in our area. That’s why our dual-radio infrastructure nodes will have one radio tuned to whatever the current Meshtastic default preset is (as long as it’s FCC-compliant) and the other will be on MeshCore at 500 kHz. We may move somewhere else in the future, but that’s what we expect to be using until the next big revelation or new technology release.

I have a good place for a node, or a resource/skill I can bring to PhillyMesh!

Please let the Ops Division know by tagging @PhillyMesh Operations Division on Discord! For node locations to be officially associated with PhillyMesh, you must have explicit permission from the property owner to install the node, and if you have internet and/or power at the location that’s a huge plus.

How to Flash MeshCore

RightSizedAlpaca — Wed, 02 Sep 2026 00:00:01 +0000

How to flash a Meshtastic node to MeshCore

1. Back up your previous Meshtastic settings

Before doing anything, it is recommended to backup your current Meshtastic node config.
From your phone app while connected to your Meshtastic node, go to Settings > Export Configuration, select all toggles, and then save that .cfg file somewhere safe.
If ever you want to change your node back to Meshtastic, you can use this config file with the “Import Configuration” to more quickly return it to its current state.

2. Grab your node and a GOOD data-enabled USB cable

Just like when doing firmware updates via serial, you’re going to want a good cable that enables data transmission (many cables are charge-only).
- If you have a cable that worked for Meshtastic flashing, it should work for MeshCore as well.
- So many instances of “flashing failed” are cable-related. If the thing is old, wobbly, been chewed on by your cat, filled with lint, been through the washing machine, been used by Gritty, etc… get a better cable, otherwise you’re gonna have a bad time.

3. Connect your node to your computer

If it’s USB-A, it’s upside-down, flip it. Now flip it again. GUESS WHAT, IT WAS RIGHT THE FIRST TIME, flip it one more time.

4. Open the MeshCore Flasher

Go to https://flasher.meshcore.io/

Note that you’ll need to use a Chromium-based browser, like Chrome or Edge. Firefox isn’t going to work.

5. Select Device Type

Find your exact node (exact model) and click on it.

If you can’t find your exact model, ask in the Discord.

6. Select Device Role

Unlike Meshtastic where you could change between CLIENT and CLIENT_MUTE in the app, MeshCore requires specific firmware for each role.

If you only have one single device/node, select “Companion Bluetooth”.
If you have a multi-node setup
- Select “Companion Bluetooth” for your pocket node.
- Select “Repeater” for the powerful/stationary node (the node on your roof, in your tree, in your attic, etc.)
  - Note that repeater nodes cannot be configured via bluetooth, but once configured over USB you can make changes from your companion node.

7. Flash the MeshCore Firmware

For NRF-based nodes

There is a warning at the top that says “We strongly recommend installing OTAFIX BOOTLOADER … for more reliable Bluetooth OTA DFU.” Click on “OTAFIX BOOTLOADER” and it will download a .uf2 file that does this. Follow the instructions here: Installing the OTAFix Bootloader - MeshCore Blog. When it comes time to update the node, you will be happy you did this.
Click “Enter DFU Mode” (in theory there is no need to double click the reset button anymore). If nothing happens (no pop up), ensure you are using a Chromium based browser like Chrome or Edge.
When the pop-up with devices shows up, select the COM port of your device. It is typically something like “nRF Serial” but may be something different depending on your device. When it is connected, the previous “Enter DFU Mode” button will now have a check and say “DFU Mode Active”.
Click “Erase Flash”. When complete, a popup will show “Device erase firmware has been flashed and flash has been erased. You can flash MeshCore now.” Click OK.
Click the Flash button. A similar popup with COM ports will allow you to select the device. A warning that the COM port number and/or device name may have changed now that it has been erased.

For ESP32-based nodes

Select “Erase Device” because the current firmware on your node is Meshtastic and must be erased.
Click “Flash”
In the pop-up, select your node based on the COM port. Click OK.
Watch the progress. Beware that erasing flash may take some time (minutes) where it appears little progress is occurring, then it will then progress to flashing.

DON’T CLOSE THE WINDOW OR DISCONNECT THE DEVICE YET

8. Configure your new MeshCore Node

For Companion Nodes

After flashing in step 7, disconnect the node from your computer and pair it to your phone using Bluetooth.
- If the device has a screen, the PIN is displayed there as a randomized six digit number.
- If the device has no screen, 123456 is the default PIN.
Configure the radio to match the settings listed in our post about “MeshCore500”

For Repeater Nodes

After flashing in step 7, DO NOT DISCONNECT the node from your computer. Initial settings must be made over serial first!
Click on “Configure via USB”.
A new window will pop up. Click “Connect” in the top right. Yet another pop up will let you select the device via COM port, and yet again the number and/or name may have changed.
The repeater setup page has a few settings you MUST setup before you disconnect, we’ll start with those:
- Under ACCESS, create a new admin password and keep it somewhere safe. This is how you will access your repeater via LoRa. If you lose this, you can’t get back into the repeater without plugging it back into your computer again.
- Under RADIO SETTINGS, change the settings to match the settings listed in our post about “MeshCore500”. These settings (freq, bandwidth, SF, coding rate) must match your companion node for the two to see each other and the rest of the mesh.
- Click SAVE SETTINGS at the bottom. A toast message with “Data successfully saved” should pop up for a second.
At this point you can disconnect your repeater and configure the rest over LoRa (using the password you just set), or finish setting it up here on a bigger screen while you’re already connected.
- Copy the Public and Private keys and keep them somewhere safe.
- In NAME & LOCATION, at least change the name to something unique. A warning that when you set the location (now or later on) it will truncate the name from 32 bytes to 24 bytes.
- Under ADVERTISING, change the Advert Interval to 240. Leave the Flood Advert at 47.
- In Owner Info, feel free to put in your Discord username or Ham call sign or leave it blank, whatever you’re comfortable with!
- Click on the SHOW ADVANCED SETTINGS checkbox and change LOOP DETECTION to Minimal. Change PATH HASH MODE from 1-byte (0) to 2-byte (1).
- Hit SAVE SETTINGS in the bottom left.
- Hit Reboot in the top middle (some of the settings don’t take effect until after a reboot). Rebooting also has the effect of disconnecting the device from the computer. You can now unplug and place the repeater back into its strategic location!
Your repeater should now be automatically repeating packets, and when you send a message using your companion node, you should see your repeater as the first hop out.

Update Time and Location

Look for a setting similar to “sync/set device clock to phone time” and click it.

MeshCore can be weird with time settings, it is a good practice to occasionally do this so your node’s clock doesn’t become too out-of-sync with the mesh.
Some apps have a setting to sync automatically.

Set a location for your node, especially if it’s a repeater.

The easiest way to do this is from the map view, where you can select a location and set it as your node location.
Note that the location does not get “fuzzed” like in Meshtastic, please do not use your exact home address if you are not comfortable doing so.

Done! Unless…

For any step, when in doubt, feel free to reach out! We’re happy to help on the Discord.

MeshCore Intro

Emily Boda — Wed, 02 Sep 2026 00:00:01 +0000

MeshCore Settings

Frequency: 902.250 MHz
Bandwidth: 500 kHz
Spreading Factor: 11
Coding Rate: 4/5 (some apps may just say 5)
Path Hash Mode: 1 (2-byte mode, some apps list this setting as 1-2 byte)

What you need to know about MeshCore coming from Meshtastic

Bluetooth Companion Node or Repeater

In Meshtastic most devices are configured as “client”. The network is designed so that every node can not only send messages but also repeat messages sent to them for others to hear. In order to reduce traffic on the network, it was recommended that nodes that are carried with you, ones that you don’t expect to be bridging gaps in the mesh all by themselves, be configured as “client_mute”. These nodes don’t repeat messages, they’re only used to send messages.

In MeshCore that concept is built into the beginning. When flashing a node you have to choose whether it will be a “Bluetooth Companion” node (equivalent to client_mute) or a “Repeater” (client). Repeaters can’t be connected to with Bluetooth, so if you only have one node you’ll want it to be a Bluetooth Companion node. If you live close enough that your Bluetooth Companion can reach someone else’s Repeater node, you won’t need your own. But you may still want to invest in a Repeater node.

Since you can’t connect to a Repeater via Bluetooth, Repeaters must be administered from a Bluetooth Companion node or via USB. In the initial set-up for a Repeater you’ll be prompted to set an admin password. Leaving this field blank will result in anyone being able to change settings on your Repeater. The guest password setting is only for restricting other people from seeing read-only telemetry data about your Repeater. You can feel free to leave this blank.

Encryption

Just as with Meshtastic, all MeshCore traffic is encrypted. Just as with Meshtastic, there’s just a default “public” channel with a known key baked in.

Chats and Channels

You can make a private channel in MeshCore just like you can in Meshtastic. MeshCore only requires that you know the key to join it, whereas in Meshtastic you need the correct combination of the name and private key.

MeshCore also introduces a feature called “Hashtag channels”. These are joinable by name-only (aka no key/password), for example: “#prm”. These are used much more heavily than private channels are in Meshtastic, since they’re easier to share and join. Add some common terms like “#philly”, “#bot”, “#weather”, or “#test” to see them.

Announcements

On Meshtastic your node would announce itself periodically and your node database would fill over the course of a day. On MeshCore, only the repeaters announce themselves. You can force searching for repeaters by using a “Scan for Repeaters” tool in most MeshCore apps.

You can force your node to advertise itself across the MeshCore network by using the “Send Flood Advert” feature in most MeshCore apps.

Reach

The maximum Hop Limit on Meshtastic is seven, and by default it’s set to three. In MeshCore, the default Hop Limit is 64, meaning your messages can travel much further than with Meshtastic. It is recommended to use the Path Hash Mode of “1”, aka a 2-byte path hash, which has the downside of limiting your hops to 32 instead of 64. The upside is that your repeater ID in flood path / loop-detects is encoded with 65,536 possible variations instead of only 256, making for a much more stable overall mesh. This setting is commonly used in MeshCore-default meshes as well.

Medium Slow and Long Turbo Testing in Philadelphia

Seth — Wed, 12 Aug 2026 00:00:01 +0000

As a review, two weeks ago we tested MediumSlow 22 for one week and then we moved to LongTurbo 12 for a week. Read more about that in our explainer article here. We now wanted to update everyone with the results of our testing.

First, a HUGE thank you to everyone who has been so helpful, patient, and willing to share time/effort getting nodes into these test modes. Including this week’s frantic “uhhhhhh everyone update firmware nowwww”. Y’all have been awesome with all these changes and tests and we sincerely thank you all. These tests would not work without your help. We acknowledge the ask to change Lora settings frequently has been… tiring to put it nicely.

Why did we conduct the tests?

So a quick reminder on the WHY. Our mesh on LongFast 20 (LF20) has become super congested. The past few months most of us have noticed our messages traveling shorter and shorter distances, more and more Trace Routes (TRs) failing, and just the general functionality decline over time.

Regardless of each of our use cases for Meshtastic (emcomms, private comms with family/friends, public message board, or if you’re named Kyle Y - undiluted, high-octane shitposting), this congestion is preventing the mesh and the technology from fulfilling its promise.

Why did we pick MediumSlow and LongTurbo?

The default preset of LF20 wasn’t really designed for big, dense cities like Philly. There’s a Meshtastic blog post from over a year ago describing this nicely and is worth a read if you haven’t yet. Our goal in testing different presets was to move up this chart to gain more bandwidth for additional traffic. More bandwidth means more room for messages and less congestion. Kinda like expanding a highway to add more lanes.

But the downside of doing that is that as you can see in the rightmost column, these faster presets travel less far (aka less link budget). So you’re trading off speed for distance. Kinda like upgrading from 2.4 GHz wifi to 5 GHz wifi, it ain’t gonna reach out into the back yard or shed or whatnot. So these tests were designed to see how links degraded at faster presets.

We picked FreqSlots that were non-default as well as requested setting changes so that we could further reduce congestion. This would help fix the pie chart in the Malla summarizing our traffic. SO much of it was non-message traffic and we wanted to address that so that the larger highway would prioritize cars with people, not just empty Waymos lol.

For those newbies among us, Meshtastic sends a lot of packets in the background. Messages are just one small part of the pie (called TEXT_MESSAGE_APP in the chart above). Many of our recommended settings changes from the tests aimed to reduce all of the other packets being sent so there’s more bandwidth for those messages to be sent.

We also picked freq slots to be kind to those with AirFrames Cavity filters. This is why we didn’t just change to the default MediumSlow frequency but instead asked people to use FreqSlot 22. The two reasons for this were:

Because it’s non-default, we are unlikely to encounter anyone who isn’t explicitly partipating in our test and therefore aren’t using our recommended settings.
It’s in an area close to, but not immediately next to, LF20 so folks with cavity filters don’t need to retune them.

If you’re curious, below is a chart showing the actual frequencies that result when you use a particular frequency slot with a preset. LongFast 20 (the current default) gives you the 906.750 - 907.000 slot. MediumSlow 22 is nearby, around 907.250 - 907.500. The purple bar on the right shows what range the Airframe Cavity Filters are tuned for out of the box. They work best toward the center of that purple band.

You’ll also notice the LongTurbo “14 - New Default?” note. Meshtastic is considering moving their default preset from LF20 to LT14, which I’ll touch on a little later.

Challenges we must overcome

Other cities like NYC, which are pretty flat, have it easy compared to Philly. We have this unique mix of dense urban, flat topography… and then suburban, hilly terrain with tall hills blocking the city in.

In addition to geologic challenges, to date our mesh has been pretty ad-hoc. We don’t have many infra nodes, meaning we’re relying on users like you and me to act as infra nodes if we have a good vantage point and pass traffic to the less fortunate in valleys, riverbeds, etc.

We also have a LOT of nodes that were set up, maybe used for a week or two, and then left on. Which is, in theory, helpful because it’s a mesh and they pass on traffic. BUT they are running older firmware (we’ll get to that with LongTurbo) and in the mindset of congestion - the Meshtastic defaults and/or what many users set is creating needless congestion.

Many of these older nodes are blasting position every hour (or more frequent) as a stationary node. Or sending out telemetry like battery stats, air temp, etc. And in some cases they’re set to the wrong role (like ROUTER) when they should be CLIENT, so they’re locally negatively impacting the mesh.

During our tests and with the upcoming changes that will be announced once we decide on them, we would be leaving them behind in the short term, with the hope that those node owners will realize we’ve moved on and they can join us once they update and fix their nodes. This change was never intended to be exclusionary, but instead a catalyst for node owners to fix their nodes to be more mesh-friendly, congestion-wise.

So what did we find during our tests?

MediumSlow 22 (MS22) was chosen first because it was the higher bandwidth of the two presets we wanted to test and we thought it was less likely to work given the mesh challenges described above. We had a VERY WEIRD few days of very degraded links and noise floor issues that we could not figure out, and we finished the week with the Ops Div going “wellllll that didn’t go great but that was the stretch preset so no biggie, let’s move to Long Turbo.”

LongTurbo 12 (LT12) started unofficially a day early and even within the OpsDiv we struggled to get it to work. We uncovered a latent issue with legacy firmware where your app can set LongTurbo as a preset… the node takes that preset setting and then tells the app “I’m good boss” but then has zero idea what it is doing.

We think we may have seen a node or two doing this that was also blasting out garbage traffic due to elevated noise floors from neighboring nodes but (we’ll get to noise floor in a bit) we’re not sure.

Ultimately though, strike one for LongTurbo - it requires only the most recent alpha/beta in firmware to work but won’t tell you that when you set it. If we made this our default preset for Philly Mesh, we would be troubleshooting LongTurbo f*ckery in the Discord day and night forever. We want something that you set and it works, so this was already a near-disqualifying issue with LongTurbo.

Once we got nodes updated firmware-wise, things still weren’t going great. If you look at the chart of presets above, LongTurbo is kinda unique as it’s one of only two presets that uses a 500 kHz bandwidth (the other being ShortTurbo). To continue the wifi analogy, it’s like setting a 160 MHz width channel when everyone else is on 80 MHz. Some devices straight up won’t communicate with it. The device has to TX and RX on 2x the width of spectrum.

We noticed that some of the devices seem to struggle to make connections where MS22 had previously worked, which made no sense. It seemed there were particular issues with RAK4631 devices (which make up about 20% of the devices on our mesh), but other RAK4631s worked fine. And one T096 had issues.

Looking at the SDR plots we think some of the devices have some serious spurious emissions (blasting RF outside where the TX bandwidth of 500 kHz). This is early testing from yesterday so not confident in the results, but we’re noticing that qualitatively some of these nodes just straight up don’t like a 500 kHz bandwidth.

What is more concerning is that a few of us kicked on our SDRs to look at traffic and noticed something we shoulda seen coming. Enter new villain into this testing: NON-MESH RF INTERFERENCE…

Non-Mesh RF Interference (boooooooo hissssss)

Here’s a video recording of my SDR. For those unfamiliar, there’s a spectroscope at the top showing the live reading, with the y-axis being intensity / sound level and the x-axis being frequency. I’m listening to a couple of MHz of the ISM band here, moved up away from LongFast to show you what we’re picking up.

It is A LOT. And it’s everywhere on the ISM band, including where LongFast is, where LongTurbo12 is, where MediumSlow22 is, insert whatever preset you want… it’s got SO much chirps. All the chirps.

One of our members, Dusty, lives next to [REDACTED MANUFACTURING FACILITY] and had picked up a LOT of this and OpsDiv was like “wellllll I’m sorry that sucks for your location”. Little did we know we don’t have to live next to [REDACTED MANUFACTURING FACILITY] to be seeing this.

But the interesting find from Dusty is that the RFID card readers seem to use specific frequencies. And the loudest, most frequent chirps we are all seeing on our SDR scopes matches these frequencies. Very specifically at the 9XX.25 and 9XX.75 intersections.

We see this all over the greater Philadelphia area - PA burbs, Jersey burbs - and while it’s much stronger in Center City, it’s still bad enough everywhere to be a huge issue. Here’s an SDR image capture from Center City:

While you might be able to avoid some of this if you’re using a skinnier bandwidth like 250 kHz, you can’t avoid it with the wider 500 kHz bandwidth used by the Turbo presets. You’ve got multiple interference points with the 9XX.25 and 9XX.75 RFID stuff, as well as all the other little chirps in-between.

So yeah, all of us looking at our SDRs came to the conclusion that LongTurbo on any slot is doomed from the start for us. We thought we were being cutesy avoiding mesh packet collisions … but we were getting packet collisions no matter what from the ISM Band being the ISM Band, and in LongTurbo’s case … double the packet collisions.

So… what now?

We’ve kinda come to the conclusion that LongTurbo ain’t gonna work. As a preset it is demonstrably worse than LF/MS due to the firmware issue as well as the 2x interference issue.

We wanted to update the wider Discord on our findings and open it up to y’all to vote on next steps… But before that vote, we have one more science experiment we’re cooking up based on our findings.

One last test to try

All of us were trying to be nice to AirFrames users, but other meshes have comfortably asked them to retune to new presets. I think we have got to that point too. With the 9XX.25 and 9XX.75 interference being the most common, widespread, and impactful interference … we CAN play frogger with a 250 kHz bandwidth. But the default slots all line up with one of them at one end of the slot, no matter what. Take a look at the below chart and you can see, every single preset touches a 9XX.25 and 9XX.75.

Buuuuuuuuuuuuuut if we use a frequency override, we can slot the 250 kHz slice right in-between the 9XX.25 and 9XX.75 blips and avoid the interference. By strategically picking one of those slots close to both the pending new Meshtastic preset of LT14 and the Meshcore 910.525 default, we would be asking AirFrames users to retune once and then be able to use that filter for Philly Meshtastic, LT14 soon-to-be-new-default Meshtastic, AND Meshcore.

So the science experiment since the conclusion of LT12 and MS22 has been to try out LF-910. Basically it doesn’t use a Freq Slot but centers its 250 kHz bandwidth at 910 (again, see green box on the chart).

It’s easy to change, you just type in “910” into the frequency override box in the Lora Settings. It does not require firmware updates (oh thank goodness). And we are picking LongFast because we want to keep it apples to apples compared to LF20 preset (during our testing phase) so that we can compare links with interference vs links without interference. If this works we can evaluate in the future if we want to stay on LF910 or use MS910.

We aren’t asking everyone to participate in this, we realize there might be a little bit of testing fatigue after two weeks of this, but here’s the plan if you’d like to participate:

Third and final (hopefully) test plan - EXTENDED LF-910 TEST

After a few days, a majority of the ~50 or so nodes currently on LF910 (at the time of this post) report that it is working surprisingly well. Links are significantly improved compared to LF20 and mesh users are having stable/reliable conversations that were not previously possible on LF20. As a result, Philly Mesh OpsDiv has decided to conduct an extended test of LF910. If this is where we want to be long term, we want to stay on it longer to make sure there aren’t any critical flaws/issues with this change. And to support this being an extended test, we have not chosen a specific end date for this test. We will have an update on the Discord as well as a new blog post when we are ready to recommend a permanent change, and will communicate more details then. It is also possible that during this extended test we may find a specific frequency better (with less non-mesh interference) than 910.000 MHz, but for now this is the best we’ve found and we encourage mesh node owners to hop over and voluntarily try this extended test with us!

To do so, switch your node to LF910 using these settings:

Modem Preset: Long Range / Fast
Frequency Slot: 0 (doesn’t matter because we’re going to override it)
Frequency Override: 910.000 MHz
Bandwidth: 250 kHz (if asked, but should be set by the Long Range / Fast preset)

Here is what the settings should look like in your app. Android on the left, and iOS in the center and on the right.

Keep all other settings from the previous test active. The iOS app and Android apps can be confusing, so we recommend installing the Meshtastic CLI and querying your nodes settings that way to verify they’re correct. Here’s a sanitized version of what your settings should look like:

The following is an example of the settings you should have if you’re participating in the test. If a setting is omitted, it’s up to you what you want to set it as.

Notes: role should be set to Client Mute if you’re in a position where a particular node doesn’t need to rebroadcast messages to other nodes, and position settings can be turned off if you don’t want to send position to the mesh

Preferences: {
"device": {
"nodeInfoBroadcastSecs": 10800,
"role": "CLIENT",
"rebroadcastMode": "CORE-PORTNUMS-ONLY",
},
"position": {
"positionBroadcastSecs": 3600,
},
"lora": {
"usePreset": true,
"modemPreset": "LONG_FAST",
"bandwidth": 0,
"spreadFactor": 0,
"codingRate": 0,
"region": "US",
"hopLimit": 3,
"txEnabled": true,
"txPower": 30,
"channelNum": 0,
"sx126xRxBoostedGain": true,
"frequencyOffset": 0.0,
"overrideFrequency": 910.0,
"configOkToMqtt": true,
}
}
Module preferences: {
"telemetry": {
"deviceUpdateInterval": 2147483647,
"environmentUpdateInterval": 0,
"environmentMeasurementEnabled": false,
"environmentScreenEnabled": false,
"environmentDisplayFahrenheit": false,
"airQualityEnabled": false,
"airQualityInterval": 0,
"powerMeasurementEnabled": false,
"powerUpdateInterval": 0,
"powerScreenEnabled": false,
"healthMeasurementEnabled": false,
"healthUpdateInterval": 0,
"healthScreenEnabled": false,
"deviceTelemetryEnabled": false,
"airQualityScreenEnabled": false
}
}

What if I don’t want to participate

You are not obligated to test out LF-910 with us, feel free to switch your radio back to default LT20 presets!

Modem Preset: Long Range / Fast Frequency Offset: 0

Verify that your primary channel is set to LongFast / AQ== or Primary.

If you want to change each setting, below shows the particular settings you’ll need to change.

Preferences: {
"lora": {
"usePreset": true,
"modemPreset": "LONG_FAST",
"bandwidth": 0,
"spreadFactor": 0,
"codingRate": 0,
"region": "US",
"txEnabled": true,
"txPower": 30,
"channelNum": 0,
"frequencyOffset": 0.0,
"overrideFrequency": 0.0,
}
}

This shows you only the settings you need to change to get back to talking on the default LF20. If a setting is omitted, it’s because it’s personal preference.

However, for example, we asked people to limit telemetry during the test so your current telemetry settings might be different than default. Now that you’re going back to LF20 you can change any settings not included here to whatever you want and still be able to communicate with LF20.

Updated Low Priced Solar Node (Harbor Breeze)

Emily Boda — Fri, 10 Jul 2026 00:00:01 +0000

After building my Medium Priced Solar Node, I wanted to explore cheaper options. I wanted to be able to build nodes to give to friends or community members to place in advantageous locations, and not feel like I was losing $100+ if it doesn’t work out.

If you’ve been around the Meshtastic community for more than a month, you’ve almost certainly heard of the Harbor Breeze Solar Light hack. This involves using the solar panel, solar management board, battery, and enclosure from a low-cost solar light available in the USA at Lowes for less than $10. The availability of these lights can vary, but if you search hard enough you can find them.

Variations

I’ve seen many variations of this hack. I believe the first came from Tavis Gustafson. This is the one that is documented in the Meshtastic docs and was featured on Hackaday.

Since this hack exploded in popularity, Harbor Breeze no longer manufacturers the original version of the Solar Light and has been replaced with a new version that has slightly different wiring, but is the same price. It has a smaller battery because the light is more efficient, and there were originally concerns that the battery wouldn’t be able to sustain a Meshtastic node. We have done almost a year of testing with the new light and we can confidently say the new version works just as well as the old version!

These instructions work great with the RAK4631 board. We have explored using a Seeed Studio Xiao, but we have found that the cheaper board is prone to brownouts (where the battery charges just enough to boot up the Xiao, but then the battery drains fully during start-up and the node gets stuck in a boot loop until a human intervenes). Mitigating this would require adding a battery management system (BMS) to the circuit, which would negate the cost savings of using a Xiao.

We also have found that the battery pads on the Xiao are very difficult to solder to, even for those experience in soldering. Since this is a beginner-friendly guide, we decided to recommend using the RAK4631 board which requires minimal soldering.

The approach I’m going with today can be applied to just about any solar light.

Parts List

Essential Parts

Parts	Price	Description
WisBlock Starter Kit	$24.99	This is the Meshtastic node. You want the RAK19007+RAK4631 (not -R) version. Pick the frequency for your region, USA is 915. This node does not come pre-flashed, you will need to flash it yourself. For $5 more you can purchase this version that comes pre-flashed with Meshtastic firmware
Harbor Breeze Solar Light	$9.98	Make sure you verify that the Item number is 1234868. If you purchase in person, the item number will be displayed on the packaging. This is technically $14.98, but it’s almost always on sale for $9.98
Heltec GT-800 868, 915 MHz Whip Antenna	$3.90	These are cheap clones of the MuziWorks 17cm Whip Antenna that have tested just as well. You can also use the more expensive 8dbi antenna from the Medium Price Solar Node, but in Philly this will be all that is necessary for a roof node.

Essential parts cost: $38.87 + shipping

Parts you may/may not need or already have laying around

I break this section out because 1) you may already have some of these parts laying around, 2) you could get many of them individually for very cheap if you buy local, 3) if you do have to buy online and in bulk, you will have some on hand and they will not contribute to the cost of your next build, and 4) you may not need some of these parts.

Parts	Price	Description
IPEX to SMA Female Cable	$6.94 for 2	The RAK kit comes with a cable, but it’s not long enough if you intend to run the antenna through existing holes. You’ll need a cable that’s at least 8 inches. Make sure to buy a cable that matches your antenna; this one works with the Muzi antenna from above.
JST PHR-2 2mm connector	$8.39 for 20	The WisBlock board uses a 2mm JST connector. You will need one of these to solder to the solar board and connect to the Wisblock battery terminal.
Waterproof Sealant	$6.34 for lots	You will need to seal up some holes in the case to make them waterproof if you want to install this outside. You can also get this from Lowes if you want to reduce shipping costs, just make sure the variety you go with works with plastic.

Total cost: $60.54 + shipping (or about $43 per node if you make lots)

Instructions

Before opening up the node, make sure the power button is off. Face the solar panel flat on a table to make sure it doesn’t charge while you’re working on it.

Press the power button and verify that the light comes on, then press it again to power it off. If the light doesn’t come on, charge it up and then make sure it does.

Unscrew the plastic stake and the light.

You may snip the light wires off close to the board. Make sure they don’t touch any other part of the board accidentally now or when you close it back up!

Open up the node.

Unscrew the four screws on the underside of the board.

Remove the battery and turn the solar panel upside down on a flat surface to ensure there won’t be any electricity running through the circuits while you solder.

Cut and remove the cables to the light.

You can cut them close to the circuit board.

Review the intended wiring.

Plug in the JST connector to the port that says “battery” on the RAK4631. Take a look at which wire is on the side with “+” etched into the board. This is the positive wire! This positive wire is the one we want to connect to the positive side of the battery holder.

Are you experienced at wiring up circuits? Do not skip reading this paragraph! The RAK’s polarity is backwards for some reason! Do not assume the red wire on your JST connector is the positive one or you will let out the magic smoke when you power on the RAK and you’ll need to buy a replacement of the most expensive component in this build.

Again, look to see which wire is on the side with the “+” etched into the board. That is the positive wire! Solder that one into the positive side of the battery holder. Solder the other wire into the negative side.

Test fit the wiring.

I usually place the RAK4631 upsidedown to the left of the circuit board inside the light housing. See if the JST connectors will reach the battery holder for solering, or if you need to extend the wiring.

If you need to extend the wiring, use wire from the female JST cables that came in your JST wiring pack. You won’t need those.

With the JST wire disconnected from the RAK, solder the JST connector wires to the battery holder.

Solder the negative wire from the JST connector to the spot marked negative on the battery holder and the positive end to the tab on the positive side the battery holder.

Plug in LoRa and bluetooth antennas.

Your Bluetooth antenna will be plugged in to the push connector labelled “BLE”. Push the two circular parts of the antenna and connector right on top of each other. It’ll require quite a bit of force, but too much force can break it.

Your RAK4631 kit came with a tiny LoRa antenna, but we’re going to use the better one we ordered.

Snake the IPEX to SMA Female antenna cable you ordered through the hole where the light cable was and connect the circular end to your RAK where it says LoRa. Screw the antenna into the other end.

Plug the JST connector into the RAK4631.

Warning: if you accidentally power on your RAK board without the antenna connected, you can irreversibly damage the board!

Place the battery back into the holder and verify the RAK powers on.

If it doesn’t power on right away, you may want to allow the battery to charge for a little while. While you wait you can verify the RAK is working and set it up by powering it with a USB-C cable. Again, make sure the antenna is connected when you do this.

Waterproofing

You will want to waterproof any holes that you’ve made in your case, including the original one that the light cables were running through. I also ended up adding a little extra sealant to the screws on the rear of the case.

Mounting

If you plan to mount to wood or something else you can screw into, this mount will work well.

Cat Solar Node

Joe Mac — Sun, 24 May 2026 22:00:12 -0400

Introduction

The solar light used for this build has distinctive ‘cat ears’, giving this build its strange name. You will need to purchase this solar light from Amazon, approximately $7 per light.

Case dimensions: 5"(h) (not counting antenna height) x 4"(w) x 4"(d) (to rear of the mounting post).

Solar panel dimensions: 4 3/8" x 2 1/4"

This is a simple build and the case pairs perfectly with the RAK 4631 Mini board. Do not get the larger 4631 on the 19007 base because it’s too large and will not fit.

The case includes an 18650 1200 mAh battery which works great with the RAK 4631. The lowest the battery level I’ve seen on 2 cloudy days is 85%.

Note: the pictures here show an upgrade battery because this node is going to be remotely deployed and I wanted a little extra fuel but I currently have 3 of these nodes running the stock battery and they work great.

Note: for this build you will need to do some soldering for the solar and battery connectors. You will need to supply the following parts: RAK 4631 Mini, antenna port and your antenna of choice, silicone caulk, hot glue gun, drill and small drill bit, and a small desiccant (optional).

Instructions

Step 1: Remove Front Panel

Remove the 4 screws holding the clear front panel.

Step 2: Disassemble LED Board

Remove the 2 screws to free the LED light board (retain the screws; you will need 1 to mount the RAK 4631).

Cut the 4 wires attached to the board (2 for battery and 2 for solar).

Note the polarity from the board - the solar white wire is positive and the battery uses standard red/black for +/-. Check the battery and make sure it is secure with glue (most of mine were but a few were not so I used a hot glue gun to secure the battery).

Step 3: Seal Weep Holes

There are 9 small weep holes that need to be filled with silicone:

4 on the back
2 on the top of the solar panel
not sure these are actual holes but I sealed them and recommend you do too
2 on the clear front lens on the bottom, opposite of each Cat ear
1 in the handle mount which requires removing the handle to get to the hole (see pic below).

Step 4: Remove the Rubber Switch Grommet

Take advantage of the existing hole for the pusbutton switch by removing the rubber grommet. This is where the antenna will be mounted.

Step 5: Solder Solar and Battery Connections Leads

Shrink wrap the connections and install the antenna connector in the existing hole.

Step 6: Update the RAK Firmware

After installing the included bluetooth and LoRa antennas, plug the RAK into a PC. Flash the board with the latest build from the Meshtastic Web Flasher. After updating disconnect the small LoRa antenna, but leave the bluetooth antenna connected.

Step 7: Trim the Case

You will need to trim off a small tab next one of the mounting holes (see pics). I used a pair of wire cutters to remove it. Trimming this piece will allow the board to fit evenly. Use one of the small screws that held the LED light to secure the RAK 4631 board in place. The board will align with a screw mount inside of the case.

Step 8: Connections

Connect the external antenna to the RAK, then connect the solar and the battery connectors to their appropriate ports on the RAK. Make sure the antenna is connected before the power! Use the small screw that held the LED light in place to secure the RAK in place.

IMPORTANT: The RAK 4631 positive(+) is marked in red and goes on the inside (toward the center). I had to repin the power connector for the correct orientation. Incorrect polarity will kill the board.

Step 9: Add a Dessicant (Optional)

This step is optional but recommended. Adding a small dessicant packet will help mitigate any condensation inside the case from temperature changes

Step 10: Add Silicone to Seal the Case

Apply a bead of silicone caulk around the inside groove of the case where the lens seats. This step is very important because I found that the clear lens is not water tight and even though you will most likely be mounting it with the lens upside-down water can (and will) find its way in.

Step 11: Add Drainage Holes

Before mounting clear front lens, drill 2 small holes in the “Cat” ears to allow water to drain.

Step 12: Reassemble the Case

Install the 4 screws on the clear lens and apply silicone caulk over them.

Step 13: Caulk the Antenna

The orientation of the case will allow rain to contact the antenna port so I use a generous amount of caulk to insure the antenna port will not leak.

Step 14: Mounting

When installing the completed unit outdoor I use the round mount with 2 or 3 screws. I have installed these units on trees, fences, and even used rope for a high tree mount.

Total Cost

Solar light, including case, battery and solar panel - $6
RAK 4631 Mini - $31
Antenna - $7

Total $44 (does not include your supplied silicone caulk, shrink wrap, solder, connectors, or hot glue).

Attic Vent Antenna Mast Mount

DustyHeatsink — Sat, 17 Jan 2026 00:00:01 +0000

As someone who is averse to high unsecured locations and wobbly ladders, I faced a problem. My attic node was underperforming. I tried a quick test with the antenna sticking out the louvered vent and saw a marked improvement, but it was still well below the roof line, and the house itself was shadowing a large portion of the signal.

I needed a way to get an antenna outside, and above the ridge line, without drilling into siding or doing anything that felt permanent. I also didn’t want it to look temporary or sketchy once it was in place. It had to pass the spouse and neighborhood sniff test.

This ended up being a simple solution using conduit and off-the-shelf fittings. It’s been solid, easy to deploy, easy to adjust, and easy to remove if I ever need to.

This was built around a louvered attic vent, but could possibly be adapted to other vent styles and window types.

Mast installed through the attic vent, with the antenna up above the roof line.

Materials

Most of this came from a big box hardware store, nothing exotic. I used a 1 inch outer diameter non-conductive electrical conduit in a 10 foot length. It was under $10 and gave me plenty of room to cut and adjust without worrying about being short. One length was more than enough to complete the project, and then build a second one to document for this guide.

The basic parts pile. Conduit, fittings, the feedthrough parts, and the access panel box.

For bracing, I used standard pivot T fittings sized for the OD of the conduit. They allow you to adjust the angle to match your install location exactly. The exact number depends on how you want to support the mast. For my build, I used one main T for the side arms and a pipe hanger from the plumbing aisle near the top as a guide and secondary support. You could also use a second T fitting if you want everything to match, or to provide additional support. I was not able to locate the T fitting at the local store but was able to purchase them online for next day delivery.

You’ll also need an end cap or similar fitting to drill for the antenna mount, or find one that already supports your connector size. In this guide I used a bulkhead style SMA connector, but Type N would work just as well. In fact, that is what I used for my installed build.

For coax, use the lowest loss cable you can reasonably get and keep it short. Four to six feet max if possible. Shorter is always better here and makes a big difference with these devices. But remember, height usually wins. You may suffer some loss but gain more from the improved antenna position.

Beyond that, it’s mostly just basic hardware. A few screws to secure the side arms to the vent frame, and some sealant to protect the antenna connector if it’s recessed or exposed to moisture. Self sealing tape is your friend. The pipe fittings also have secondary holes that you can put a short self tapping screw into for peace of mind.

Before you start cutting

Before cutting conduit or tightening anything down, think through where the antenna connector and coax are going to live.

If you’re mounting the antenna in a recessed fitting, drill a small drain hole at the lowest point. Water will find its way in eventually, and giving it a way out is easier than pretending sealant alone will solve it forever.

Plan your coax path. The cleanest route is down the inside of the conduit, exiting at the bottom. Leave some slack to form a drip loop before it enters the vent. That loop becomes very important over time.

Also think about connectors. Every adapter adds loss and another failure point. Pick SMA or Type N and keep the run as short as you can manage.

Access Panel Option (Top Mounted Node)

There is also the option of adding an access fitting at the top of the mast, mounting your node there, and running power up the mast vs bringing coax down and into the space.

There are inline straight-through and right-angle access panel options. My local store did not have the straight-through option, and online pricing was running three to four times higher than the right-angle option, so that’s what I used for this guide.

Exploded view of the access-panel feedthrough before it got assembled and sealed up.

Same feedthrough assembled, with the coax pigtail running to the node inside the box.

If you go this route, make sure the power cable is rated for outdoor use and long enough to run the full length of the mast and into your space without tension.

Ensure all fittings are properly sealed. If this fitting leaks, your node is most likely done for.

For my use case, I needed interior access to the node in the attic and planned to add a cavity filter, so I went with a short run of KMR240 instead of this variant for my final install.

Assembly

I started by cutting the conduit to a length that made sense for the vent location and roof line. There’s no exact number here. You are better off leaving yourself extra length and trimming some off versus going too short and cutting a whole new piece. If that does happen you could use the bad piece as material for the arm(s).

The main mast gets a T fitting with a short side arm, about a foot. That arm is what braces against the inside of the vent frame. I adjusted the angle so it roughly matched the angle of the louvers. Hold off on any threadlocker until you have done a test fit.

If, like me, you can’t easily reach the outside of the vent, tighten the bottom fitting fully and carefully slide most of the assembly out through the vent opening. This part is interesting, because you feed it downward to get it out the vent. I positioned it one or two louvers up from the bottom so the base of the mast lined up with the bottom of the vent. That left room for the coax to exit cleanly and form a small loop downward before feeding back through the lowest louver.

Once it was roughly where I wanted it, I slowly rotated the mast until it was vertical. Take your time here, you don’t want to drop it. A second set of hands or a firm hold on the antenna cable may alleviate any anxiety.

For the top support, I used a simple pipe hanger. I slid it out through the top of the vent, hooked it onto the conduit, and gently pulled until it snapped into place. It’s smaller and less noticeable than a full second T fitting bracket, and with the bottom fitting tightened down, the top support is there mostly to keep the mast vertical. Either method works.

With the mast held in position, I ran screws through the pre drilled holes in the side arms and into the interior vent frame. I avoided over tightening. The assembly already felt solid. If you have a gap between the vent opening and inner frame a small block of wood or plastic standoff may be needed. I added a couple of screws to the pipe hanger up top as well.

Cable routing and power up

I ran the coax inside the conduit and exited at the bottom of the mast, avoiding drilling any additional holes. From there it loops downward before heading back into the vent. That drip loop is intentional. It keeps water from following the cable inside.

Once inside, route the cable to your setup. The less coax you use, the better.

Full mast assembly laid out before the install. This is the part you end up feeding through the vent.

Power the node up before closing anything up, you may need to make adjustments, my node is in a simple IP65 case right inside the vent. RSSI and SNR were showing improved values over the old setup. Once everything looked stable and reasonable, I buttoned it up and double checked the mounts and connections.

Final notes

For a higher wind location or a taller mast, I’d skip the pipe hanger and go with a second T fitting for the top brace. This setup has been solid where it is, but extra support never hurts if conditions are harsher or if you don’t like the look of the hanger.

Some folks will want to add a lightning arrestor here, and that’s fair. An inline arrestor tied into a proper ground can help with static and nearby activity, but it’s not magic. A direct strike is still a direct strike. I chose to keep this install simple, but if your location or risk tolerance is different, it’s an easy addition.

Getting the antenna fully outside and above the roof line was my main goal. Currently, the vent louvers haven’t shown any meaningful impact on performance. There may be a more elegant or permanent way to do this, but this hit a good balance for me. It solved an RF problem without turning into a home improvement project, and it blends in well with the siding of the house. It’s also easy to undo if I ever need to move or rethink it.

I also did and alternative version with another vent to mount a weather sealed yagi. It provided an easy way to mount the yagi, and allowed for easy adjustment/rotation.

Real-Time Meshtastic Decoding with Scapy and Wireshark

Caleb Frey — Sat, 10 Jan 2026 21:19:45 -0500

The Goal

When I powered on my first Meshtastic node, I was blown away at the ability to exchange messages with people over multiple hops without even needing a license. That awe lasted about a week before I noticed that sometimes the intended recipient never saw it. Or the messages would often go unacknowledged, leaving me to wonder whether anyone saw it at all. So I decided to do some digging to figure out why the message delivery was so inconsistent.

I dug into the Meshtastic documentation to learn about the “managed flooding” broadcase approach to understand how a packet gets transmitted. In summary, the stronger a signal is for a given packet, the longer a node will wait before transmitting it, and it won’t transmit if it already heard others rebroadcast it. Theoretically this helps a signal travel as far as possible, with the assumption that weaker signal corresponds to a further distance. But since we don’t live in a perfect spherical vacuum, you end up with strange routes like a node in someone’s basement becoming the preferred hop when it’s the least useful. It seems chaotic and strange but it makes sense when the system is designed for a group of nodes in constantly changing conditions and locations (and outdoor usage). However, I wasn’t content to just read about the broadcast approach, I wanted to see it in real time, from the perspective of my node here in Philly.

The Meshtastic client apps (at least for web and android) are designed first and foremost for usability, and as a result hide away a lot of the underlying networking. I wanted to be able to see all the Meshtastic packets in the air, shown live in a tool like Wireshark for dissection and analysis. It’s possible to enable debugging mode in the app, but that requires a consistent connection to the phone app, where the data isn’t particularly easy to parse. There is also the option to enable serial debugging, but it wouldn’t use the existing usb c link and I didn’t love the idea of running flying leads to a USB serial converter. Thankfully, since the Meshtastic protocol is open source, there wasn’t any requirement that I even use a Meshtastic node. I’ll write my own receive-only client! How hard could it be?

Hardware: Pulling LoRa from the Airwaves

All Meshtastic Devices amount to a LoRa modem and something to run the meshtastic device code, usually a microcontroller. So if I wanted to decode Meshtastic, I needed some form of LoRa modem that could be plugged into my PC. Thankfully, someone in the PhillyMesh Community had already purchased a CatWaN USB Stick with similar intentions and let me borrow it. This USB device consists of an RP2040 microcontroller, a RFM95W Modem and not much else, which is exactly what I wanted.

To get the data from USB Stick to the computer, I wrote some simple firmware as for the CatWAN as if it were a Raspberry Pi Pico, since it’s the same underlying chip. I configured the LoRa module with the parameters to match the LongFast Radio Preset, along with the default frequency (906.875MHz) and sync word (0x2B). Every time a new LoRa signal with those parameters arrived, it was encapsulated with LoRaTap, which is mostly a header with some radio information, and written to USB Serial. To distinguish the end of one transmission from the start of another (and avoid the \n vs \r\n conflict) I terminated each packet with a special byte sequence unlikely to be in the real data.

Software

Now that I had an incoming stream of LoRa packets I had to learn how to decode them. The wonderful folks selling the HackerPager had already written a Meshtastic decoder plugin for Wireshark to be used on captured .pcap files, but I didn’t have pcap files. After reading the specifications for a pcap file I wrote a script that encapsulated the incoming LoRaTap stream into a valid stream of pcap data. Each pcap data stream must begin with a pcap header that includes the correct link type (270 for LoRaTap), followed by the individual packets, each of which had to be wrapped with timestamp and other capture information.

Once I was generating valid pcap files and followed the guide to install the HackerPager plugin, I was finally able to see all the Meshtastic traffic happening around me during that capture. Wireshark supports pcap streams via stdin, so after a few tweaks (and discovering that powershell doesn’t do normal byte-friendly piping) I had a live view of all the meshtastic traffic around me. This was an amazing sight, being able to see “hello world” messages pinging back and forth between nodes, but I didn’t plan to stop at Wireshark. I wanted data collection and analytics, and I wasn’t planning to do it all using Wireshark and Lua.

Enter: Scapy - a packet manipulation library for Python. Think of it like Wireshark but with the ability to assemble and modify packets, not just read them. Scapy decodes packets into individual layers, and includes many built-in layers, from HTTP and the OSI model to CAN bus protocols. Unsurprisingly, it doesn’t include anything for Meshtastic, so I had to add those layers myself.

Dissecting a Meshtastic Packet

Using the Meshtastic documentation to understand the protocol, the HackerPager Wireshark plugin as a reference implementation, and many many tabs of Scapy documentation, I was able to identify and decode the contents of each layer in the meshtastic packet. I’ll walk you through them.

Layer 1: LoRaTap

Mostly just an encapsulation format that Wireshark and other tools can decode
Includes received radio information including LoRa config and SNR/RSSI
Sync Word - byte that can be used to set a protocol
- Need all your LoRa devices to have the same sync word
- Meshtastic = 0x2B, LoRaWan uses 0x34
- Think of this like a VLAN ID
Message size

Layer 2: MeshPacket

Unencrypted protobuf that all nodes can read
Routing information so other nodes can relay the packet
- Source and destination radio IDs
- Packet ID (used for deduplication and encryption)
- Hop information
  - Hop limit is how many hops are “left”
  - Hop start is how many hops it started with
  - Last hop data to do some intelligent routing
Channel hash to speed up decryption

Layer 3: MeshPayload

Encrypted protobuf containing the actual data
Encrypted with AES256-CTR stream cipher
- Uses the channel key and packet ID to encrypt/decrypt
“Port Number” determines what app protocol is being used
Additional metadata like request/reply IDs and the source/dest ID

Layer 4: MeshApp or MeshText

This is the end-user functionality of the device
Remaining data in the LoRa packet is decoded as a protobuf according to the port number
Applications include:
- Node info
- Position
- Telemetry
Text messages (port number = 1) contain the message as a binary string

For each layer I had to define all the fields to be extracted and write the dissection logic to set the values of those fields, including decryption and protobuf decoding. After I had created each layer I had to “register” them with the scapy interpreter so it knew to associate the incoming data and subsequent payloads with the correct dissector.

Once Scapy fully dissected a packet I was able to access the individual fields in each packet as if it were a typical Python object. Every packet that was processed (if it could be decoded) was added to an SQLite database to record network traffic and create a collection of known nodes based on their periodic NodeInfo broadcasts. This let me take a look at stats such as airtime utilization by different nodes, protocols, and in general perform long-term trend observation. I could even grow beyond my single data source with volunteers hosting another instance and sending the results to a central database in an to get a holistic view of all the Meshtastic traffic in the city.

The Results

Now that I had a process to collect and record all Meshtastic traffic happening around me, without the limits of using a proper Meshtastic node, I could determine the cause of the inconsistent connectivity if I knew where to look.

Unfortunately, I didn’t see anything obviously symptomatic of an unreliable network and adding advanced analytics, a webUI, and distributed data collection was beyond my skills and interest. Lucky I was introduced to a tool called Malla, which can collect data from multiple sources using MQTT and display them all in a much slicker WebUI than I would have been able to make. So rather than reinvent the wheel I started a PhillyMesh Malla Instance with a number of gateways feeding data into the platform. The one limitation of Malla over the raw LoRa decoding is that by default, nodes don’t have “Ok to MQTT” enabled so we don’t have a complete picture, but I doubt I could convince multiple people to setup a whole mini PC for raw LoRa sniffing, so I think the trade-off is worth it.

While I didn’t end up using this project long-term to learn about our Mesh, I did learn plenty of new things along the way:

I hadn’t done embedded development in a very long time and learned about platform.io
This was my first time dealing with binary data, bitmasking, and endianness
I had never dealt with protobufs before but now understand why they’re used everywhere
I finally used a proper database, and I’m coming around to tolerating SQL after resisting for so long
I learned that I should continue avoiding low-level cryptography
- It’s a bad sign when you start calling functions with “hazmat” in the name

I also got to show off my project at Jawncon 0x2 and it was so cool to see people interested in something I worked on, especially those working on the Kismet RF analysis suite. The idea that something I wrote as a side project could get integrated into a larger project is very exciting.

For now it’s a mostly-stanalone set of scripts that are tedious to get working, but it’s as feature-complete as I plan to make it. All the source code for this project, including the firmware, build instructions, and sample SQL queries, are available at https://github.com/calefrey/scapy-meshtastic.

Low Priced Solar Node (Harbor Breeze)

Emily Boda — Sat, 21 Jun 2025 00:00:01 +0000

UPDATE

You can no longer buy this particular Harbor Breeze node! As a result, we need slightly new wiring. We have a new article with new instructions here.

Original Post

Variations

I’ve seen many variations of this hack. I believe the first came from Tavis Gustafson. This is the one that is documented in the Meshtastic docs and was featured on Hackaday. This one is tried and true, but does not allow the user to press the included power button to turn on/off the node.

These instructions work great with the RAK4631 board. We are exploring a new version that uses a Seeed Studio Xiao. Unfortunately, if you wire up a Xiao the way we have in these instructions, the node can often suffer from brownouts (where the battery charges just enough that the Xiao powers on, but then the battery drains fully during start-up and the node gets stuck in a permanent boot loop until you can go and charge it up yourself).

There is an alternate wiring to avoid these brownouts that requires scraping off the R6 resistor so you can use the Harbor Breeze node’s internal solar management system (which may or may not have a brownout-preventing feature, we’re still testing it) but prevent the board from turning the node off during the day. I’d consider scraping off a resistor and wiring to the Xiao’s absolutely miniscule battery pads to be a “hard mode” node, so once we vet that this way prevents brownouts, we will make a new article for the Dirt Cheap Hard Mode Solar Node.

The approach I’m going with today is very beginner friendly. It is the one that I found in the description of this 3D printed mount for the light. This allows us to use the power button and doesn’t require any modifications to the included solar management board. Even if you’re new to soldering, this should be pretty easy.

Parts List

Essential Parts

Parts	Price	Description
WisBlock Starter Kit	$24.99	This is the Meshtastic node. You want the RAK19007+RAK4631 (not -R) version. Pick the frequency for your region, USA is 915.
Harbor Breeze Solar Light	$9.98	Make sure you verify that the Item number is 2483282. If you purchase in person, the item number will be displayed on the packaging. There is a newer version of this light and whether it works with this hack has not yet been verified.
Heltec GT-800 868, 915 MHz Whip Antenna	$2.99	These are cheap clones of the MuziWorks 17cm Whip Antenna that have tested just as well. You can also use the more expensive 8dbi antenna from the Medium Price Solar Node, but in Philly this will be all that is necessary for a roof node.

Essential parts cost: $37.96 + shipping

Parts you may/may not need or already have laying around

Parts	Price	Description
IPEX to SMA Female Cable	$6.94 for 2	The RAK kit comes with a cable, but it’s not long enough if you intend to run the antenna through existing holes. You’ll need a cable that’s at least 8 inches. Make sure to buy a cable that matches your antenna; this one works with the Muzi antenna from above.
JST PHR-2 2mm connector	$8.39 for 20	The WisBlock board uses a 2mm JST connector. You will need one of these to solder to the solar board and connect to the Wisblock battery terminal.
Waterproof Sealant	$6.34 for lots	You will need to seal up some holes in the case to make them waterproof if you want to install this outside. You can also get this from Lowes if you want to reduce shipping costs, just make sure the variety you go with works with plastic.

Total cost: $59.63 + shipping (or about $42 per node if you make lots)

Instructions

Before opening up the node, make sure the power button is off

Press the power button and verify that the light comes on, then press it again to power it off. If the light doesn’t come on, charge it up and then make sure it does.

Open up the node

Remove the battery and turn the solar panel upside down on a flat surface to ensure there won’t be any electricity running through the circuits while you solder.

Cut and remove the cables to the light. Remove the weather-proofing here, too.

You can cut them close to the circuit board.

Determine which is the positive and which is the negative side of the JST connector

Don’t skip this step! The JST connectors don’t have a standard and the one’s you ordered are likely BACKWARDS from the standard that RAK uses. This means it is likely that the red cable is negative and the black cable is positive. Plug the JST connector into the Battery connector on the RAK, look at which color is on the side with the plus symbol. This color is positive and the other color is negative.

Solder the JST connector to the light circuitry.

Solder the negative end of the JST connector to the spot marked negative and the positive end to the tab on the positive side the battery. You might need the JST connector cable to be a little longer (do a test fit before soldering), if so you can use the wire from one of the extra female JST cables that you don’t need.

The above picture is instructions I found online, the color of your wires may be reversed!

Make sure you haven’t accidentally turned on the power button and plug in the JST connector to the battery connector on the RAK

Warning: if you accidentally power on your RAK board without the antenna connected, you can irreversibly damage the board!

To be safe, you should connect your antenna to the RAK before plugging the JST connector into the battery connector. Verify that the RAK didn’t power on (that the power button is still off) and then unplug the IPEX connector and feed it though the hole where the light cables used to be, then plug it back into the RAK. Then put the battery back into the battery holder and hit the power button.

You can see the original IPEX antenna cable at the top of the image, it was not long enough to reach back out the pre-drilled antenna cable hole.

You can also see that in my case, the wire running to the positive end of the battery is black. That’s because my JST connector is reverse from the standard and my positive wire is black. In this picture I left the original light cables long in case I wanted to try a different variation. However, I got lucky and this variation worked well!

Waterproofing

Mounting

If you have a pole to mount to, you may be interested in printing a remix of the original 3D printed mount that I made. If you plan to mount to wood or something else you can screw into, the original 3D printed mount would be better.

Many of the 3D printed mounts online, such as the example below that another Philly Mesh member made, do not include an antenna mount, so you’re required to drill an antenna hole directly into the case. Oftentimes this requires the antenna to be bent 90-degrees. The Muzi antenna I linked does not offer this option and in practice many of the cheap plastic antennas have reduced range when bent. Make sure you test your antenna and confirm that it still performs well when bent, if that’s how you plan to use it.

Getting Started with Meshtastic in Philly

Emily Boda — Mon, 16 Jun 2025 00:00:00 +0000

Hello! We moved the getting started guide to its own page so it can stay a “living document”.

Please update your bookmarks accordingly.

If you came here from an external link please let us know so we can get that updated. Thanks!

Stealthy Water Bottle Node

Emily Boda — Fri, 16 May 2025 00:00:01 +0000

For most of the day, I can be found carrying a T-1000e in my pocket. My home has (or will have) a node on the roof with a longer range antenna, and my T-1000e works perfectly to keep myself connected to the mesh, even if my phone can’t connect all the way to my roof node via bluetooth. However, when I travel outside of the house the tiny antenna in the T-1000e leaves something to be desired.

To fill this gap, I came up with a plan for a portable node with a longer range antenna that I could easily stick in a backpack or leave on my bike that wouldn’t raise any alarms. While I’m not averse to carrying around large antennas, I like to save this activity for radio meetups or cons, and be a little less obvious in my day to day life. I realized this bike water bottle I had was exactly the right length for the whip antenna I had laying around.

Since I built and started using this water bottle node, I don’t know how more people don’t do something like this! You can stick it in a water bottle pocket of a backpack and it stays vertically polarized. The antenna doesn’t get bent or unscrewed in your bag. It’s entirely waterproof so you don’t have to worry about getting caught in the rain. And it doesn’t get any curious looks from cursory bag checks at hospitals or museums. As a general disclaimer, I would NOT recommend bringing this to any high security location like an airport. TSA is generally fine with radio and Meshtastic equipment, but something like this might get you pulled into a room and interrogated about why you’re hiding wires, batteries, and antennas in a normal looking object.

The WisBlock with a 1200mAh battery lasts about a week between charges. This is plenty for me, but feel free to use a battery with more capacity to make it last longer, there’s plenty of extra space in the water bottle!

Parts list

Essential parts

Parts	Price	Description
WisBlock Starter Kit	$24.99	This is the Meshtastic node. You want the RAK19007+RAK4631 (not -R) version. Pick the frequency for your region, USA is 915.
Water Bottle	$11.99	I had a Specialized MoFlo 22oz bike water bottle lying around. It barely fits this 17cm Gizont whip antenna (that’s actually slightly less than 17cm) that I had, but may not fit other 17cm whip antennas. I’d recommend grabbing whatever antenna you have available and finding a water bottle that fits that.
Antenna	$13.00	I can’t vouch for this particular distributer, but I’ve used Gizont whip antennas for many projects and always had good results. I think I bought this one on eBay, so just search the name of the antenna and find it wherever is most convenient.
MuziWorks H1 Battery (1200 mAh)	$9.90	I had a couple of these because I made some of their 3D printed nodes previously

Essential parts cost: $59.88 + shipping

Parts you may already have laying around

I break this section out because 1) you may already have some of these parts laying around, 2) you could get many of them individually for very cheap if you buy local, and 3) if you do have to buy online and in bulk, you will have some on hand and they will not contribute to the cost of your next build.

Parts	Price	Description
Right angle SMA to IPEX cable	$10.99	If you have tight clearances you’ll need one of these right angle cables rather than the usual straight ones.
JST Connectors 2mm male and 1.25mm female	$14.98	The battery is 1.25mm JST and the WisBlock is 2mm JST, so you’ll need to solder two connectors together to make them connect.
M2.5 screws and nuts	$7-18	You can get just M2.5 screws and nuts for much cheaper, but if you don’t already have a set of metric screws and nuts, it’s worth it to get a variety pack, which is what I have linked.
3D Printed Node/Battery/Antenna Holder	free	This holds everything together

Total cost: $92.85 + shipping

Assembly

I threw together a 3D printed bracket that holds all of the components together and to charge all you have to do is unscrew the top to plug into the WisBlock’s USB-C port. If any of your parts are different than mine you will need to make your own. You can also just duct tape all the pieces together and throw them in the water bottle if you’d like, I did this for a month or so until I designed the bracket.

Screw the antenna into the bracket and feed the end of the pigtail through the top. The WisBlock goes on the side where the antenna pigtail feeds. It should slot in and then you can screw it in with the M2.5 screws and nuts to secure it.

You will need to solder the two JST connectors you got together to make a connector for the battery to the WisBlock. The connector will be 1.25mm female to 2mm male. Pay attention to the positive and negative terminals on the WisBlock!! It will likely be the reverse of what the battery sends out. You may need to solder the red leads of one connector to the black of the other and vice versa. If you mess this up, you will likely kill your WisBlock.

Slide the battery into the other side of the bracket and you’re good to go!

Medium Priced Solar Node

Emily Boda — Wed, 14 May 2025 00:00:01 +0000

I’m calling this a “medium priced” node because I didn’t really budget and just bought parts as they became necessary. There are also many examples of cheaper nodes, such as the Low Priced Solar Node (Harbor Breeze). The low cost node depends on the availability of the Harbor Breeze solar lights, whereas this node uses more generic parts that will almost surely be available in the future.

For now, here’s a reasonably reliable node that costs around $110 for just the essential parts.

Parts List

Essential Parts

Parts	Price	Description
WisBlock Starter Kit	$24.99	This is the Meshtastic node. You want the RAK19007+RAK4631 (not -R) version. Pick the frequency for your region, USA is 915.
Unify Enclosure 150x100x45mm	$46.00	This one comes with pre-drilled antenna holes and is the right size for our RAK4631 and some batteries.
Enclosure Mounting Kit	$4.00	I picked type A, the vertical mounting version. This is optional, but great if you want to mount on a pole. Keep an eye on the recommended pole diameter (65-89mm).
Alfa 915 5dbi antenna	$17.97	I picked this one because I’ve tested a couple and they seem to be well-tuned and the quality seems consistent. YMMV.
Adapter from RP SMA Female to N Type Male	$8.99	The enclosure comes with a waterproofed RP SMA female adapter (reverse polarity) which is atypical, and the Alfa antennas are N Type Male. The included is an example, but you may also want one with a length of cable between them so as to separately attach the antenna to wherever you’re mounting it.
Two 18650 rechargeable batteries	varies, maybe $10?	I bought mine from Amazon, but this is not recommended. Check out this list that someone made of reputable distributors.

Essential parts cost: $111.95 + shipping

Parts you may already have laying around

Parts	Price	Description
Antenna Tape	$8.80	Although the antenna connector on the top is waterproofed, your adapter connections are not. This is a great option to waterproof your connections.
Battery holders	$7.99	I bought this pack of a million from Amazon. I had to solder them in series. If you’re not good at soldering find one that you don’t need to solder. Make sure the ones you buy are in parallel (not in series!). When I doubt, check the voltage with a multimeter before installation.
JST PHR-2 2mm connector	$8.39	The WisBlock board uses a 2mm JST connector. Depending on what kind of battery pack you buy, you may need to solder these JST connectors on.

Total cost: $137.13 + shipping

Picking a Meshtastic Node

nRF Meshtastic devices (like the RAK4631) are far superior to other types when it comes to power efficiency. While an ESP32 Meshtastic device (like a Heltec v3) might last 24 hours on a battery, that same battery will power a RAK4631 device for a week. For that reason, for solar powered devices, the RAK4631 is a great pick.

You may also wish to add environmental sensors to your RAK4631. See this page on Meshtastic’s website for supported sensors. This will allow your device to report measurements like temperature and humidity. Keep in mine those measurements will be from inside the enclosure, so they’re better for reporting the status of your node’s environment than the outside weather.

What about high/low temps?

18650 batteries generally have a stated temperature range for charging between 0 and 45C (32 to 113F). While your summer might top out at 90F, the temperatures inside a sealed enclosure in the direct sunlight might be closer to 135F. I’ve actually seen nodes in the Pioneer Valley reporting that temperature in the summer. On the other end of the spectrum, most of North America reaches below 32F in the winter for weeks at a time.

From what I understand, these recommended charging temperatures aren’t as big of a deal as they might seem to be at first glance. A group from Alberta wrote a great article about their node deployments in the frozen Canadian winters. They recommend overspeccing the battery capacity (three 18650s instead of two) in your node due to reduced charging performance during the winter, but other than that their nodes are pretty much fine. There’s no long term capacity effects.

I’m not as worried about high heat either. I’m of the opinion that I’m likely going to have to open up this node probably once a year to do firmware updates, so I might as well take that opportunity to replace the 18650s as well. If you buy them in bulk, the cost will be closer to $2-3 each, so it’s a relatively small maintenance cost.

Installation Location

The best place to install a node is very high up. Unfortunately for most of us, this means mounting the node somewhere like the roof, which is difficult to get to.

Wherever you mount your node, plan to have to update the firmware at least once a year, perhaps more often.

Updating firmware

Currently there are two options to update your firmware:

Connect to the device via a USB-C cable
Connect to the device via Bluetooth and update OTA.

Option one isn’t very practical in a solar node: if you’re already keeping your node connected to your computer, why not just power it from there? Some builds install a Raspberry Pi in the enclosure and connect that to the node via USB-C, but Raspberry Pis are very power-hungry and not a good fit for a solar node. Neither will work well for this particular build.

Option two is outlined in the Meshtastic docs here. There are a few disclaimers to consider before trying this. First, as of the time of writing, this only works with the iOS app. And second, if the firmware update fails, you’re SOL. Your device isn’t bricked, but you will need to connect it to a computer to get the firmware back up and running.

There currently are no other options. Even if you power your node via POE, there is no way to update the node via Ethernet. You may be able to power a Pi via POE and use option one from a more suitable location, however it is likely the Pi will not be able to survive summer heat in the enclosure. I am testing that this summer to see. Regardless, the Pi takes too much power for a solar node.

As a result, at least for me, I am planning to retrieve my solar node from its mounting spot and update its firmware about once a year.

Management

If your node is easily within bluetooth range, you can manage it from your phone. However, if your solar node is installed somewhere where it’s inconvenient to connect via bluetooth (say, on the roof of a public building you don’t have regular access to), it’s recommended to set up an admin channel on your node so you can manage it via the mesh.

The Meshtastic docs explain this here.

Other best practices for unattended nodes

If this device is outside the range of bluetooth and you won’t be able to regularly check DMs, it’s recommended that you make sure a casual mesh user will be able to figure out how to contact you. For example, if the node is your roof node and you also have a handheld mobile node, you might want to make the long name “JS Base Station” and the mobile node’s long name “JS Mobile” so users can try to contact you on the mobile node if you don’t respond to the base station. If you have a personal domain or an identifiable username, you could put the URL or your handle in your long name. A recent version of the Meshtastic firmware (2.6.8) allows you to designate your node as “unmessagable”. This is located in the User section of the settings.

In Philly, all of our phillymesh.net nodes are named as such! This solar node is phillymesh.net-08. We also add secondary and tertiary management keys of other members so that if one member is out of town or unable to reach the mesh, the nodes can be administered by other trusted members.

All of these best practices make the mesh a friendlier place!

Putting all the pieces together

The WisBlock board has a spot in the top left of the enclosure where it screws into the backplate. I printed a small plate to hold my two battery holders together, and they fit snugly at the bottom of the enclosure. They fit so snugly that duct tape might also work. I don’t think that more than two batteries will fit inside this enclosure, so if you want more buy a bigger enclosure.

When soldering the battery holders together, you want them to be in parallel. Some battery holders on Amazon don’t specify whether they’re in series or parallel. It’s worth checking the voltage with a multimeter before connecting to your WisBlock, as your WisBlock will let out magic smoke if you connect too high a voltage. The voltage should be around 3.7V (if it’s closer to 7.4V, that means the batteries are in series and you do not want that).

You battery holder will likely not come with the correct JST connector for the WisBlock board. Even if you buy a battery with JST connectors, they’re usually smaller than the correct size. Also, very important to note: the WisBlock battery connections are reversed from the standard (the solar connectors are normal). Rak claims “there is no standard”, but considering all the JST connectors I order on Amazon are the opposite of Rak’s choice, I disagree. Check the connectors you buy! I had to solder the red lead to the black lead and the reverse to make the connector attach properly, which continues to confuse me every time I open the enclosure. To reduce confusion, I wrote in sharpie on the interior of my enclosure which color is positive and which is negative. You will kill your board if you reverse the connectors.

Source: https://meshtastic.org/docs/hardware/devices/rak-wireless/wisblock/base-board/

Update 6/21/2025

I’ve had this node outside for about a month and each time I’ve opened it up I’ve noticed water inside the supposedly sealed node. This is likely due to humidity, Philly is very humid. I plan to add a weep valve to the node before installing on the roof. I will test for a while and then update the page again with more details.

Happy Meshing!

MQTT Bridge Setup

Mike Dank (Famicoman) — Mon, 24 Mar 2025 00:00:02 +0000

In August 2024 Meshtastic made changes to their official MQTT server due to potential safety issues of third parties tracking and storing user location data. While one of the main Meshtastic node mapping websites meshmap.net continues to rely on the official MQTT server, another popular site meshtastic.liamcottle.net now runs their own separate MQTT server.

While MQTT can be leveraged to connect Meshtastic nodes to one another over-the-Internet to bridge separated networks or isolated nodes, many people instead use this feature specifically for contributing to node maps so others can see what nodes may be operating in their area. As already outlined, there are now two separate MQTT servers for node maps. However, the Meshtastic application only allows one MQTT server to be configured per node, which requires the user to make a choice of which one they will use and ultimately which site they will not contribute to.

Luckily, there is another approach that can be used to reliably send data to multiple MQTT servers: creating an MQTT bridge. This bridge can act as an intermediary, allowing Meshtastic nodes to send it data which is then forwarded to other servers.

Here we can see how to set up a server that feeds to both mqtt.meshtastic.org and mqtt.meshtastic.liamcottle.net.

Installation & Base Config

This guide assumes a Debian Linux system with a non-root, sudo user.

First, we will install mosquitto as our MQTT server of choice:

$ sudo apt install mosquitto

Now we will add the initial configuration:

$ sudo cat /etc/mosquitto.conf
# Place your local configuration in /etc/mosquitto/conf.d/
#
# A full description of the configuration file is at
# /usr/share/doc/mosquitto/examples/mosquitto.conf.example
allow_anonymous false
listener 1883 0.0.0.0
pid_file /run/mosquitto/mosquitto.pid
persistence true
persistence_file mosquitto.db
persistence_location /var/lib/mosquitto/
# Uncomment for logging
# log_dest file /var/log/mosquitto/mosquitto.log
# log_type all
include_dir /etc/mosquitto/conf.d
password_file /etc/mosquitto/pwfile

Now we will generate a password for the phillymesh user to authenticate with:

$ sudo touch /etc/mosquitto/pwfile
$ sudo mosquitto_passwd -c /etc/mosquitto/pwfile phillymesh

Adding Bridges

Additional configuration can be added to /etc/mosquitto/conf.d/, so let’s create a file for each of our bridges:

$ sudo cat /etc/mosquitto/conf.d/mqtt.meshtastic.org.conf
connection mqtt_meshtastic.org
address mqtt.meshtastic.org:1883
# Username and password for the upstream server
remote_username meshdev
remote_password large4cats
# MQTT version to use
bridge_protocol_version mqttv311
# Forward all traffic from msh/*/2/map/ to the remote server
topic msh/+/2/map/# out 0
topic msh/# out 0
# Enable encryption
use_identity_as_username false
bridge_insecure true
# Bridge settings to manage the connection
cleansession true
notifications false
start_type automatic
try_private true
restart_timeout 10

$ sudo cat /etc/mosquitto/conf.d/mqtt.meshtastic.liamcottle.net.conf
connection mqtt_meshtastic_liamcottle_net
address mqtt.meshtastic.liamcottle.net:1883
# Username and password for the upstream server
remote_username uplink
remote_password uplink
# MQTT version to use
bridge_protocol_version mqttv311
# Forward all traffic from msh/*/2/map/ to the remote server
topic msh/+/2/map/# out 0
topic msh/# out 0
# Enable encryption
use_identity_as_username false
bridge_insecure true
# Bridge settings to manage the connection
cleansession true
notifications false
start_type automatic
try_private true
restart_timeout 10

Finishing Touches

mosquitto leverages systemd to run as a service, so let’s start it up:

$ sudo systemctl enable --now

Make sure that port 1883 is open in the firewall for client connections:

$ sudo iptables -L | grep 1883
ACCEPT tcp -- anywhere anywhere tcp dpt:1883

Client Configuration

We will assume that the Meshtastic node is connected to the Internet already via WiFi/ethernet.

Client configuration can be set as follows for MQTT:

MQTT enabled: on
Address: IP or FQDN of your server
Username: Username you defined
Password: Password you defined
Encryption enabled: on
JSON output enabled: off
TLS enabled: off
Root topic: msh/country/state (Needs to be specific for mqtt.meshtastic.org, for example: msh/US/PA)
Proxy to client enabled: off
Map Reporting: on
Precise location off and minimum of 1194 ft to comply with mqtt.meshtastic.org
Map reporting interval (seconds): 900

Client configuration can be set as follows for Channels > LongFast:

Uplink enabled: on
Downlink enabled: off
Position enabled: on
Precise location off and minimum of 1194 ft to comply with mqtt.meshtastic.org

Sources

Station G2 Node Installation

Mike Dank (Famicoman) — Mon, 24 Mar 2025 00:00:01 +0000

Last year I documented the process of upgrading the PM03 Meshtastic node to use a Station G2 and outdoor-rated 5.8 dBi antenna (though it was installed indoors).

The hardware used for this installation is:

Installing Yggdrasil – A Toy Implementation of an Encrypted IPv6 Network

Mike Dank (Famicoman) — Fri, 05 Jan 2018 14:46:04 +0000

2018-08-29 Update: This tutorial is now very out of date. The Yggdrasil team now maintains great installation guides here.

At Philly Mesh, we like to play around with pieces of technology that aren’t directly related to our core software stack. One such piece of software is Yggdrasil, an encrypted IPv6 networking implementation developed by Arceliar. Yggdrasil borrows many ideas from cjdns, but was primarily written to test a new routing scheme developed by Arceliar. While it is not production-ready software, Yggdrasil is an interesting foray into encrypted networking and fun to experiment with.

For this installation guide, we assume a Debian Stretch (or similar) Linux system with a non-root, sudo user.

First, we need to make sure we have a recent version of go. We can check our version using the following command:

$ go --version
go version go1.9.2 linux/amd64

Yggdrasil is built with Go 1.9. At the time of writing, Debian Stretch only comes with Go 1.3. If you need to install a more recent version of Go, you can do so manually. Below is an example installing Go 1.9.2 for the amd64 architecture using a download link from https://golang.org/dl/:

$ sudo apt-get remove golang
$ cd /usr/local
$ sudo wget https://redirector.gvt1.com/edgedl/go/go1.9.2.linux-amd64.tar.gz
$ sudo tar -xzf go1.9.2.linux-amd64.tar.gz
$ sudo ln -s /usr/local/go/bin/go /usr/local/bin/go

Now we will set up some environment variables to use Go:

$ mkdir ~/go
$ export GOROOT=/usr/local/go

Now we are ready to install Yggdrasil:

$ cd ~
$ git clone https://github.com/Arceliar/yggdrasil-go.git
$ cd yggdrasil-go/
$ ./build

If all goes well, Yggdrasil will have built successfully with no errors. Now we are ready to generate a config file:

$ ./yggdrasil --genconf > conf.json

The config file is pretty basic and allows for some customization:

$ cat conf.json
{
"Listen": "[::]:0",
"Peers": [],
"BoxPub": "46d18cbcfa0d510fcd226f323efe279525c50eb15db925d4879ee675b99b0724",
"BoxPriv": "727213ecb3caf601ee49596fa77469674bed177f10d8607ee76ec1f35e942310",
"SigPub": "08565493e805e905dbcc22cdaa7e60bd6cb6fc1df21d1b807b46f6285f8b86fd",
"SigPriv": "4173f91e08ab2b6f7c5ae96cf9d61f7ac30b36be7a5eff298e00e0d08f6f5c9608565493e805e905dbcc22cdaa7e60bd6cb6fc1df21d1b807b46f6285f8b86fd",
"Multicast": true
}

If you want Yggdrasil to listen on a static port, you can change the Listen attribute to use an IP and/or port of your choosing like "12.34.57.78:1234". You can add entries to the Peers attribute by listing them as strings (IP:PORT) in the array (comma-separated). The Multicast attribute is currently set to true, but you could set this to false if you didn’t want to auto-peer for some reason.

Here is a sample config that listens on port 1234 on all interfaces and connects to a peer at 12.34.57.78:1234:

cat conf.json
{
"Listen": "[::]:1234",
"Peers": ["12.34.57.78:1234"],
"BoxPub": "46d18cbcfa0d510fcd226f323efe279525c50eb15db925d4879ee675b99b0724",
"BoxPriv": "727213ecb3caf601ee49596fa77469674bed177f10d8607ee76ec1f35e942310",
"SigPub": "08565493e805e905dbcc22cdaa7e60bd6cb6fc1df21d1b807b46f6285f8b86fd",
"SigPriv": "4173f91e08ab2b6f7c5ae96cf9d61f7ac30b36be7a5eff298e00e0d08f6f5c9608565493e805e905dbcc22cdaa7e60bd6cb6fc1df21d1b807b46f6285f8b86fd",
"Multicast": true
}

Now, we can start Yggdrasil in the background:

sudo ./yggdrasil --useconf < conf.json &

You should now have a tun interface up for your Yggdrasil node:

$ ip a
43: tun1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc pfifo_fast state UNKNOWN group default qlen 500
link/none
inet6 fd00:4645:d147:7c16:98f2:20ea:d0ba:7174/8 scope global
valid_lft forever preferred_lft forever

Now, you can ping other Yggdrasil nodes on the network:

$ ping6 -c4 fd1f:dd73:7cdb:773b:a924:7ec0:800b:221e
PING fd1f:dd73:7cdb:773b:a924:7ec0:800b:221e(fd1f:dd73:7cdb:773b:a924:7ec0:800b:221e) 56 data bytes
64 bytes from fd1f:dd73:7cdb:773b:a924:7ec0:800b:221e: icmp_seq=1 ttl=64 time=14.4 ms
64 bytes from fd1f:dd73:7cdb:773b:a924:7ec0:800b:221e: icmp_seq=2 ttl=64 time=12.6 ms
64 bytes from fd1f:dd73:7cdb:773b:a924:7ec0:800b:221e: icmp_seq=3 ttl=64 time=15.1 ms
64 bytes from fd1f:dd73:7cdb:773b:a924:7ec0:800b:221e: icmp_seq=4 ttl=64 time=12.9 ms
--- fd1f:dd73:7cdb:773b:a924:7ec0:800b:221e ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 12.673/13.783/15.105/1.017 ms

Further documentation for Yggdrasil is available here, and a whitepaper draft is available here.

Building DIY Community Mesh Networks (2600 Article)

Mike Dank (Famicoman) — Wed, 21 Dec 2016 23:08:09 +0000

Now that the article has been printed in 2600 magazine, Volume 33, Issue 3 (2016-10-10), I’m able to republish it on the web. The article below is my submission to 2600 with some slight formatting changes for hyperlinks.

Building DIY Community Mesh Networks

By Mike Dank
Famicoman@gmail.com

Today, we are faced with issues regarding our access to the Internet, as well as our freedoms on it. As governmental bodies fight to gain more control and influence over the flow of our information, some choose to look for alternatives to the traditional Internet and build their own networks as they see fit. These community networks can pop up in dense urban areas, remote locations with limited Internet access, and everywhere in between.Whether you are politically fueled by issues of net neutrality, privacy, and censorship, fed up with an oligarchy of Internet service providers, or just like tinkering with hardware, a wireless mesh network (or “meshnet”) can be an invaluable project to work on. Numerous groups and organizations have popped up all over the world, creating robust mesh networks and refining the technologies that make them possible. While the overall task of building a wireless mesh network for your community may seem daunting, it is easy to get started and scale up as needed.

What Are Mesh Networks?

Think about your existing home network. Most people have a centralized router with several devices hooked up to it. Each device communicates directly with the central router and relies on it to relay traffic to and from other devices. This is called a hub/spoke topology, and you’ll notice that it has a single point of failure. With a mesh topology, many different routers (referred to as nodes) relay traffic to one another on the path to the target machine. Nodes in this network can be set up ad-hoc; if one node goes down, traffic can easily be rerouted to another node. If new nodes come online, they can be seamlessly integrated into the network. In the wireless space, distant users can be connected together with the help of directional antennas and share network access. As more nodes join a network, service only improves as various gaps are filled in and connections are made more redundant. Ultimately, a network is created that is both decentralized and distributed. There is no single point of failure, making it difficult to shut down.

When creating mesh networks, we are mostly concerned with how devices are routing to and linking with one another. This means that most services you are used to running like HTTP or IRC daemons should be able to operate without a hitch. Additionally, you are presented with the choice of whether or not to create a darknet (completely separated from the Internet) or host exit nodes to allow your traffic out of the mesh.

Existing Community Mesh Networking Projects

One of the most well-known grassroots community mesh networks is Freifunk, based out of Germany, encompassing over 150 local communities with over 25,000 access points. Guifi.net based in Spain, boasts over 27,000 nodes spanning over 36,000 km. In North America we see projects like Hyperboria which connect smaller mesh networking communities together such as Seattle Meshnet, NYC Mesh, andToronto Mesh. We also see standalone projects like PittMesh in Pittsburgh, WasabiNet in St. Louis, and People’s Open Network in Oakland, California.

While each of these mesh networks may run different software and have a different base of users, they all serve an important purpose within their communities. Additionally, many of these networks consistently give back to the greater mesh networking community and choose to share information about their hardware configurations, software stacks, and infrastructure. This only benefits those who want to start their own networks or improve existing ones.

Picking Your Hardware & OS

When I was first starting out with Philly Mesh, I was faced with the issue of acquiring hardware on a shoestring budget. Many will tell you that the best hardware is low-power computers with dedicated wireless cards. This however can incur a cost of several hundred dollars per node. Alternatively, many groups make use of SOHO routers purchased off-the-shelf, flashed with custom firmware. The most popular firmware used here is OpenWRT, an open source alternative that supports a large majority of consumer routers. If you have a relatively modern router in your house, there is a good chance it is already supported (if you are buying specifically for meshing, consider consulting OpenWRT’s wiki for compatibility. Based on Linux, OpenWRT really shines with its packaging system, allowing you to easily install and configure packages of networking software across several routers regardless of most hardware differences between nodes. With only a few commands, you can have mesh packages installed and ready for production.

Other groups are turning towards credit-card-sized computers like the BeagleBone Black and Raspberry Pi, using multiple USB WiFi dongles to perform over-the-air communication. Here, we have many more options for an operating system as many prefer to use a flavor of Linux or BSD, though most of these platforms also have OpenWRT support.

There are no specific wrong answers here when choosing your hardware. Some platforms may be better suited to different scenarios. For the sake of getting started, spec’ing out some inexpensive routers (aim for something with at least two radios, 8MB of flash) or repurposing some Raspberry Pis is perfectly adequate and will help you learn the fundamental concepts of mesh networking as well develop a working prototype that can be upgraded or expanded as needed (hooray for portable configurations). Make sure you consider options like indoor vs outdoor use, 2.4 GHz vs. 5 GHz band, etc.

Meshing Software

You have OpenWRT or another operating system installed, but how can you mesh your router with others wirelessly? Now, you have to pick out some software that will allow you to facilitate a mesh network. The first packages that you need to look at are for what is called the data link layer of the OSI model of computer networking (or OSI layer 2). Software here establishes the protocol that controls how your packets get transferred from node A to node B. Common software in this space is batman-adv (not to be confused with the layer 3 B.A.T.M.A.N. daemon), and open80211s, which are available for most operating systems. Each of these pieces of software have their own strengths and weaknesses; it might be best to install each package on a pair of routers and see which one works best for you. There is currently a lot of praise for batman-adv as it has been integrated into the mainline Linux tree and was developed by Freifunk to use within their own mesh network.

Revisiting the OSI model again, you will also need some software to work at the network layer (OSI layer 3). This will control your IP routing, allowing for each node to compute where to send traffic next on its forwarding path to the final destination on the network. There are many software packages here such as OLSR (Optimized Link State Routing), B.A.T.M.A.N (Better Approach To Mobile Adhoc Networking), Babel, BMX6, and CJDNS (Caleb James Delisle’s Networking Suite). Each of these addresses the task in its own way, making use of a proactive, reactive, or hybrid approach to determine routing. B.A.T.M.A.N. and OLSR are popular here, both developed by Freifunk. Though B.A.T.M.A.N. was designed as a replacement for OLSR, each is actively used and OLSR is highly utilized in the Commotion mesh networking firmware (a router firmware based off of OpenWRT).

For my needs, I settled on CJDNS which boasts IPv6 addressing, secure communications, and some flexibility in auto-peering with local nodes. Additionally, CJDNS is agnostic to how its host connects to peers. It will work whether you want to connect to another access point over batman-adv, or even tunnel over the existing Internet (similar to Tor or a VPN)! This is useful for mesh networks starting out that may have nodes too distant to connect wirelessly until more nodes are set up in-between. This gives you a chance to lay infrastructure sooner rather than later, and simply swap-out for wireless linking when possible. You also get the interesting ability to link multiple meshnets together that may not be geographically close.

Putting It Together

At this point, you should have at least one node (though you will probably want two for testing) running the software stack that you have settled on. With wireless communications, you can generally say that the higher you place the antenna, the better. Many community mesh groups try to establish nodes on top of buildings with roof access, making use of both directional antennas (to connect to distant nodes within the line of sight) as well as omnidirectional antennas to connect to nearby nodes and/or peers. By arranging several distant nodes to connect to one another via line of sight, you can establish a networking backbone for your meshnet that other nodes in the city can easily connect to and branch off of.

Gathering Interest

Mesh networks can only grow so much when you are working by yourself. At some point, you are going to need help finding homes for more nodes and expanding the network. You can easily start with friends and family – see if they are willing to host a node (they probably wouldn’t even notice it after a while). Otherwise, you will want to meet with like-minded people who can help configure hardware and software, or plan out the infrastructure. You can start small online by setting up a website with a mission statement and making a post or two on Reddit (/r/darknetplan in particular) or Twitter. Do you have hackerspaces in your area? Linux or amateur radio groups? A 2600 meeting you frequent? All of these are great resources to meet people face-to-face and grow your network one node at a time.

Conclusion

Starting a mesh network is easier than many think, and is an incredible way to learn about networking, Linux, micro platforms, embedded systems, and wireless communication. With only a few off-the-shelf devices, one can get their own working network set up and scale it to accommodate more users. Community-run mesh networks not only aid in helping those fed up with or persecuted by traditional network providers, but also those who want to construct, experiment, and tinker. With mesh networks, we can build our own future of communication and free the network for everyone.

CJDNS on OpenWRT – Part 3: Installing & Configuring CJDNS

Mike Dank (Famicoman) — Thu, 21 Apr 2016 21:49:08 +0000

Now that we have OpenWRT installed and ensured that we have enough space to experiment and install packages, we can proceed to install and configure cjdns.

I have opted to install a GUI package to allow for easier configuration (though I also wanted to see what it had to offer over editing configuration files). The package used here is luci-app-cjdns, relying on the LuCI interface that comes default in most OpenWRT images. If you want to install cjdns without the GUI or do not use LuCI, you can install the regular cjdns package. Note: The standard cjdns package was left out of OpenWRT 15.05.1, but should be in the older 15.05 image. The luci-app-cjdns package should be available in both versions, so you won’t have any issue with the remainder of this guide.

Now we are ready to install cjdns for LuCI. SSH into the access point and run the following command to update and install luci-app-cjdns.

opkg update && opkg install luci-app-cjdns

After this finishes, leave the SSH session open and then load up the OpenWRT web console in a browser and log in. By default, this interface can be reached via http://192.168.1.1. Now that we’re in the console, select cjdns from the Services dropdown on the top menu. An Overview page for cjdns will load (and look rather empty). Now, click the Peers sub-tab link near the top of this page.

Now, we can enter in the peering information for any number of peers to connect to. You will likely want to populate the Authorized Passwords and Outgoing UDP Peers sections as I have below.

CJDNS Peers Tab

When finished, press the Save & Apply button to commit any changes and restart cjdns. These steps can be repeated to add as many peers as needed.

Now, navigate back to the Overview page by clicking on the Overview sub-tab link.

After loading, we should now have connection information about the configured peers as shown below.

CJDNS Overview Page

That’s all there is to it! Back in our SSH session, we can try pinging a machine on Hyperboria to confirm a connection:

ping6 h.peer0.famicoman.com
PING h.peer0.famicoman.com (fc9f:990d:2b0f:75ad:8783:5d59:7c84:520b): 56 data bytes
64 bytes from fc9f:990d:2b0f:75ad:8783:5d59:7c84:520b: seq=0 ttl=42 time=4072.631 ms
64 bytes from fc9f:990d:2b0f:75ad:8783:5d59:7c84:520b: seq=1 ttl=42 time=3800.924 ms
64 bytes from fc9f:990d:2b0f:75ad:8783:5d59:7c84:520b: seq=2 ttl=42 time=4594.193 ms
64 bytes from fc9f:990d:2b0f:75ad:8783:5d59:7c84:520b: seq=3 ttl=42 time=4329.846 ms
^C
--- h.peer0.famicoman.com ping statistics ---
9 packets transmitted, 4 packets received, 55% packet loss
round-trip min/avg/max = 3800.924/4199.398/4594.193 ms

If all went as expected, you now have cjdns running on your OpenWRT router! This can be expanded in the future by copying an OpenWRT configuration onto several routers, and then linking them together wirelessly.

CJDNS on OpenWRT – Part 2: Configuring Extroot for More Storage

Mike Dank (Famicoman) — Mon, 11 Apr 2016 21:46:56 +0000

If you have any low-memory OpenWRT device (4MB of flash) you will probably fill up any free space quickly after the initial OpenWRT install and need more room to grow. Luckily, you can transfer your root file system to a flash drive and boot off of it as long as your access point has a USB port.

If you are following along with our Western Digital N600, you probably don’t need to do this. The N600 comes equipped with 12MB of built-in flash, more than enough to accommodate the software packages we will install in the future. If you have less than this or want to have a nice learning exercise, read on!

You are going to need a Linux machine and a flash drive. The flash drive size shouldn’t matter too much. A lot of people run OpenWRT off of 8MB of internal flash, so any small drive should have plenty of room.

On your Linux machine, plug in the flash drive (mine is a ~10 year old 64MB), and run dmesg to get the kernel message buffer.

dmesg

You should get a lot of output, but importantly at the end, we should see our flash drive being recognized:

[26913.782811] usb 1-1.4: new high-speed USB device number 4 using dwc_otg
[26913.883754] usb 1-1.4: New USB device found, idVendor=0457, idProduct=0151[26913.883779] usb 1-1.4: New USB device strings: Mfr=0, Product=2, SerialNumber=3
[26913.883796] usb 1-1.4: Product: USB Mass Storage Device
[26913.883812] usb 1-1.4: SerialNumber: 00000000004FDE
[26913.884913] usb-storage 1-1.4:1.0: USB Mass Storage device detected
[26913.887282] usb-storage 1-1.4:1.0: Quirks match for vid 0457 pid 0151: 80
[26913.887450] scsi host0: usb-storage 1-1.4:1.0
[26914.884185] scsi 0:0:0:0: Direct-Access Staples 0.00 PQ: 0 ANSI: 2
[26914.886688] sd 0:0:0:0: [sda] 124000 512-byte logical blocks: (63.4 MB/60.5 MiB)
[26914.887210] sd 0:0:0:0: [sda] Write Protect is off
[26914.887235] sd 0:0:0:0: [sda] Mode Sense: 00 00 00 00
[26914.887748] sd 0:0:0:0: [sda] Asking for cache data failed
[26914.887771] sd 0:0:0:0: [sda] Assuming drive cache: write through
[26914.916959] sda: sda1
[26914.920057] sd 0:0:0:0: [sda] Attached SCSI removable disk
[26914.922645] sd 0:0:0:0: Attached scsi generic sg0 type 0

We see that our physical device is sda, with one partition sda1. Your drive/partition may be labeled differently depending on how many drives you have installed or plugged into your machine, and how many partitions your flash drive has. We can verify we are looking at our flash drive by listing via fdisk.

fdisk -l /dev/sda

You will get a lot of informative output about the device:

Disk /dev/sda: 63 MB, 63488000 bytes
16 heads, 32 sectors/track, 242 cylinders, total 124000 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x91f72d24
Device Boot Start End Blocks Id System
/dev/sda1 * 32 123999 61984 b W95 FAT32

Now we will go ahead and format the drive as ext4. First however, we need to create a partition by running the fdisk command on the drive (without the -l option).

fdisk /dev/sda

This is an interactive utility, so when prompted, enter d to delete the current partition on the drive. Then enter n< for a new partition (taking the defaults by pressing the return key). Finally, enter w to apply the changes to the disk and exit.

Now, we can make a file system on the partition we just created, formatting it as ext4:

mkfs.ext4 /dev/sda1

Afterwards we can list with fdisk again to see our changes:

fdisk -l /dev/sda
Disk /dev/sda: 63 MB, 63488000 bytes
3 heads, 32 sectors/track, 1291 cylinders, total 124000 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x91f72d24
Device Boot Start End Blocks Id System
/dev/sda1 2048 123999 60976 83 Linux

You can now remove your USB drive from your Linux machine and plug it into your OpenWRT device.

Next, we ssh into our OpenWRT device and login as root. We need to install a few utilities with opkg before we can switch over the root filesystem.

opkg update && opkg install block-mount kmod-fs-ext4 kmod-usb-storage fdisk nano

Now we will run fdisk to see that our drive is recognized:

root@OpenWrt:~# fdisk -l
Disk /dev/mtdblock0: 256 KiB, 262144 bytes, 512 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/mtdblock1: 64 KiB, 65536 bytes, 128 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/mtdblock2: 64 KiB, 65536 bytes, 128 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/mtdblock3: 64 KiB, 65536 bytes, 128 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/mtdblock4: 15.5 MiB, 16252928 bytes, 31744 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/mtdblock5: 1.3 MiB, 1310720 bytes, 2560 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/mtdblock6: 14.3 MiB, 14942208 bytes, 29184 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/mtdblock7: 12.1 MiB, 12648448 bytes, 24704 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/mtdblock8: 64 KiB, 65536 bytes, 128 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk /dev/sda: 60.6 MiB, 63488000 bytes, 124000 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x91f72d24
Device Boot Start End Sectors Size Id Type
/dev/sda1 2048 123999 121952 59.6M 83 Linux

My drive registers as /dev/sda1, and this is used through the commands below. Make sure you take note of yours and make the necessary changes when running additional commands.

Next, we will copy our filesystem over and set the device to boot from the flash drive. If you are squeamish about making this change via a terminal, scroll down and view the sources referenced at the end of this tutorial. There is a way to perform this configuration using OpenWRT’s default graphical interface: LuCI. If you prefer to issue commands over ssh, read on.

Now, we will actually mount the drive, and copy the root filesystem to it:

mkdir /mnt/sda1
mount /dev/sda1 /mnt/sda1
mkdir -p /tmp/cproot
mount --bind / /tmp/cproot
tar -C /tmp/cproot -cvf - . | tar -C /mnt/sda1 -xf -
umount /tmp/cproot

After we have moved the filesystem over, we can modify the fstab with our editor of choice.

nano /etc/config/fstab

Paste the following at the top the file and save it. This will use the flash drive as the primary filesystem and preserve this configuration even after reboot.

config mount
option device '/dev/sda1'
option target '/'
option fstype 'ext4'
option enabled '1'

Finally, we reboot the device by issuing the reboot command:

reboot

After the system comes back up, ssh into it once more and run the df command.

df -h

In the output, pay attention to the Size column to make sure it matches up closely to your flash drive’s capacity to verify that you are actually running off of the flash drive.

Filesystem Size Used Available Use% Mounted on
rootfs 53.7M 9.7M 39.8M 20% /
/dev/root 2.3M 2.3M 0 100% /rom
tmpfs 61.6M 628.0K 61.0M 1% /tmp
/dev/sda1 53.7M 9.7M 39.8M 20% /
tmpfs 512.0K 0 512.0K 0% /dev

That’s all there is to it! Now, you are booting directly off of the flash drive and have more room to install packages. Additionally, you may want to save an image of your drive for future use. You never know when you will be trying something out and need to restore from a backup!

Sources

CJDNS on OpenWRT – Part 1: Installing OpenWRT on the WD N600

Mike Dank (Famicoman) — Thu, 31 Mar 2016 21:42:38 +0000

I was lucky enough to snag a Western Digital N600 router recently for $10 via Woot and have been working through the process of getting it configured with OpenWRT and cjdns.

For $10, I didn’t think I was getting a whole lot, but these devices sport a popular Atheros chipset and are perfectly compatible with OpenWRT’s latest version (Chaos Calmer 15.05 at the time of writing). For the uninitiated, OpenWRT is an alternative firmware for routers that allows for an advanced set of features and more customization.

My N600, happily chugging away.

The first (and sometimes daunting) task in this process is to flash the firmware on to the device, but this is easy to accomplish with the help of the OpenWRT Wiki page for the N600.

One issue I’ve found is that the page states that the web updater doesn’t work on most N600 devices and that it is preferable to use telnet. Being the console junkie I am, I tried the telnet method first but had no way to configure or enable it! I found I couldn’t use telnet but ultimately was able to flash via the web interface.

Adapted from the wiki, here are the steps I took to flash my device. Any additions/modifications by me are in bold:

0) Turn on and configure the device. I couldn’t do anything until i completed the initial setup.

Download the file openwrt-ar71xx-generic-mynet-n600-squashfs-factory.bin. I pulled it down from https://downloads.openwrt.org/chaos_calmer/15.05/ar71xx/generic/openwrt-15.05-ar71xx-generic-mynet-n600-squashfs-factory.bin

Configure your computers IP address to 192.168.1.10 and connect to a LAN port in the router.

Turn the router off.

Using a paperclip, press and hold the reset button on the bottom of the router and turn it on. Hold the reset button for at least 15 seconds. Wait until the power light on the front is slowly flashing on and off.

On your computer, visit http://192.168.1.1 NOTE: You will not be able to ping this address.

Upload the file openwrt-ar71xx-generic-mynet-n600-squashfs-factory.bin as downloaded earlier.

The router will now flash OpenWRT. This will take a couple of minutes to achieve. You can ping 192.168.1.1 and watch for ping replies to see when your router has rebooted into OpenWRT.

That’s all there is to it. After OpenWRT boots for the first time, you’ll be able to configure it to work on your local network. At most,I suggest setting a root password!

This process is pretty adaptable to other hardware, and the OpenWRT wiki is invaluable when it comes to specific steps to flash OpenWRT on any device you may have around. Don’t feel like you have to get an N600 because I did, a lot of hardware is supported (I would recommend something with two radios and 8MB of flash for maximum hackery)!

This tutorial is just the first in a series where we will get cjdns configured on your OpenWRT router. The more meshing, the merrier!

Hyperboria 101 Article Published at N-O-D-E

Mike Dank (Famicoman) — Wed, 17 Feb 2016 22:30:20 +0000

Earlier this week I had an article published discussing Hyperboria and how the network works at a high level. It is titled Hyperboria 101 – Moving Through the Mesh, and is available to view here through n-o-d-e.net.

Running cjdns on Raspbian Jessie

Mike Dank (Famicoman) — Mon, 08 Feb 2016 22:17:03 +0000

If you’re like me, you have a few Raspberry Pis kicking around, waiting for a job to do. I adopted early and purchased (at least one) original Model B with 256MB of RAM. This was a nifty little box four years ago, but has since been overshadowed by its older brother, the revised Model B with 512MB of RAM, and its cousins: the B+ and RPi 2. These originals still have life left in them, and can often be found below the original $35 price tag. When it comes to running cjdns, they do a fantastic job!

This post assumes you have a Raspberry Pi, power adapter, sd card, and enough smarts to hook the Pi up to your network and feed it a Raspbian image. This should work for any Model B Raspberry Pi, from the original up to the Raspberry Pi 2.

Installation

The Hyperboria documentation offers a guide on installing for Debian Jessie, but it fails on the Raspberry Pi out of the box. Prior to this, I was running Raspbian Wheezy with few issues in relation to cjdns, but other work I wanted to do had me yearning for a more up-to-date distribution. I grabbed Raspbian Jessie from the official download site (Release date 2015-11-21), loaded it onto my SD card, and booted up.

On an original Raspberry Pi, this process takes a while. At this point, start yourself a pot of coffee and then log on to your pi using the default username and password, pi/raspberry. I run headless, so everything will be done from the console over ssh, but that shouldn’t matter too much.

We are going to install cjdns as a service, so let’s change over into root to make this a little more comfortable.

su -

If you have a fresh installation, be sure to run config and expand to fit the full size of your SD card, overclock if you want, and restart the pi when done. After restarting, log in again and change back to root.

raspi-config

I also cannot express how important it is to change the default user and root passwords.

passwd pi
passwd root

Now, we want to update, upgrade, and install some dependencies.

apt-get update
apt-get upgrade
apt-get install nodejs build-essential git

Somewhere during these commands, your coffee should have finished. Go pour a cup and come back to watch the console until everything is tidied up.

Afterwards, we are going to start building cjdns by pulling down the latest code and building.

cd /opt
git clone https://github.com/cjdelisle/cjdns.git
cd cjdns
NO_TEST=1 Seccomp_NO=1 ./do

Pay close attention to this last line. We need to execute ./do in this fashion because of a current issue with the kernel on Raspbian Jessie.

After a little wait, the build should finish successfully. Now we want to configure cjdns to run as a daemon, so let’s create a link to the binary, generate a configuration file, and copy over the service file.

ln -s /opt/cjdns/cjdroute /usr/bin
(umask 077 && ./cjdroute --genconf &gt; /etc/cjdroute.conf)
cp contrib/systemd/cjdns.service /etc/systemd/system/

All that’s left is to enable the service and start it up. Afterwards, it should start on every boot-up automatically.

systemctl enable cjdns
systemctl start cjdns

If you want to edit your cjdroute.conf for adding peers or… well… anything else, simply edit the file in /etc/cjdroute.conf and restart the service.

nano /etc/cjdroute.conf
systemctl restart cjdns

At any point, you can check the status of the service:

systemctl

In the output, you should see the following:

cjdns.service loaded active running cjdns: routing engine designed for sec...

Troubleshooting & Debugging

If at any point you want to check the output generated by starting cjdns, stop the service and run cjdroute manually.

systemctl stop cjdns
/opt/cjdns/cjdroute < /etc/cjdroute.conf

Occasionally, you may get a Configurator error like this below:

1454470218 CRITICAL Configurator.c:97 Failed to make function call [Timed out waiting for a response], error: [UDPInterface_beginConnection]

If this happens, run the following before starting cjdroute again to ensure that the ipv6 kernel module is loaded:

modprobe ipv6

Conclusion**

That’s all it takes, you now have a node capable of connecting to Hyperboria! Now, all you need to do is find some peers, add them to your configuration file, and join the network!