Posts on Philly Mesh

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

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. 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

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: $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

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 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!