Haven MANET: a self-healing IP mesh over HaLow radios

A mesh with no server in the middle

Haven is a mesh networking platform, and the project describes it as a complete open source solution for creating self-healing IP networks that share internet access across kilometres without any central infrastructure.

That phrase carries most of the design. A conventional network has a router at its centre, and a mesh has nodes that find routes to each other, so a node can leave the network and the traffic reroutes around it. The self-healing claim is about the routing layer rather than about the radios, and the project attributes it to automatic route discovery and failover.

The rationale table in the README sets out the case in eight rows. Decentralised means no central server and no single point of failure. Long Range means one to ten kilometres or more from node to node with HaLow radios. Internet Sharing means one uplink serves the entire mesh. Fully Open Source means there is no proprietary lock-in and everything can be audited. The remaining rows cover multi-hop routing through intermediate nodes, the power efficiency of sub-1GHz radios, and expansion through USB peripherals such as LoRa sidecars, software defined radio, and cellular.

The intended use is visible in the topics the repository carries: offgrid, mesh networks, decentralised, and the integration names. A node is a physical unit, so the toolkit covers hardware, firmware, and the network as well as the software, which is unusual for a networking project and is the point.

The project is MIT licensed, the homepage is buildwithparallel.com, the last push was on 2026-10-07, and there are no tagged releases, so the firmware and the scripts move on the branch rather than on a version schedule.

The three pieces: radios, routing, and firmware

The README lists the components Haven combines, and each one is a well known piece of technology used in a particular way.

HaLow radios, which is 802.11ah operating in the sub-1GHz spectrum, provide the multi-kilometre range. This is the piece that makes the long distances possible, because conventional WiFi at 2.4GHz does not carry a signal across kilometres, and the trade is that the available bandwidth is much lower.

BATMAN-adv provides automatic layer two mesh routing, which is the layer at which the self-healing behaviour lives. A node discovers its neighbours, measures the paths between them, and forwards traffic over the best one, and when a node drops the routes are recomputed.

OpenWrt based firmware provides reliable embedded networking, and here the project splits by platform. Haven 1 nodes run OpenMANET, and Haven 2 nodes run a Pi 5 specific OpenWrt and Morse image.

The remaining components are the extension points. USB sidecar support covers LoRa radios, RTL-SDR, and other peripherals. Optional ADS-B to CoT conversion enables aircraft tracking in TAK. Optional Reticulum provides encrypted overlay communications. And optional ATAK and CivTAK integration covers situational awareness.

That layering is the architecture in one paragraph. The radio gives you reach, the routing protocol gives you resilience, the firmware gives you a network operating system, and the optional pieces are the sensors and the command and control applications that sit on top of an IP mesh.

Two boards, one protocol, and a clear warning

Haven runs on two platforms, and the README says plainly that both use the same mesh protocol and interoperate fully. The difference is the hardware and how proven the software is.

Haven 1 on a Raspberry Pi 4 or Compute Module 4 is the recommended platform, described as proven stable in the field. The board is a Pi 4 Model B or a Compute Module 4, the HaLow radio is a Morse Micro MM601X on an SPI HAT, and the 2.4GHz WiFi is an RT5370 USB adapter of the Panda Wireless kind or similar.

Haven 2 on a Raspberry Pi 5 is marked experimental. The board is a Pi 5 with 4GB or 8GB, the HaLow radio is a Morse Micro MM8108 attached over USB, the WiFi adapter is the same RT5370, and a USB hub is recommended for extra peripherals. The description is blunt about its status: still being validated, and not yet recommended for production deployments.

The firmware difference is the practical trap. The Pi 5 needs its own OpenWrt and Morse image rather than the OpenMANET image, and it can be built from the openwrt-morse-rpi5 repository or downloaded as a prebuilt alpha release. The quick start states the rule in a sentence: do not flash the Haven 1 and Pi 4 OpenMANET image onto a Haven 2 and Pi 5 node.

For anyone deploying this, the safe sequence is to treat the platform and its image as a matched pair, to check the board notes for the platform in use, and to expect the Pi 5 path to move faster than the documentation, since its firmware is still an alpha release while the Pi 4 path is described as proven.

There is one more installation detail that saves a lot of confusion. If the microSD card still looks like it has old data after flashing, the erase or format utility in Raspberry Pi Imager has to be run on the card first, and then the image written. A card that was not erased can boot into a mixture of two systems, which looks like a firmware problem and is not one.

Gate and point, and how traffic actually flows

The network diagram in the README is the clearest description of the system, and it introduces two node roles.

The gate node is the one with the uplink. It has an ethernet interface to the wide area network, the HaLow mesh, WiFi access points, a bridge interface for the HaLow link, and a DHCP server. The point nodes are the ones that serve the users, and they have the HaLow mesh, WiFi access points, and a bridge interface carrying a private address range in the 10.41.x.x space. Phones, laptops, and ATAK clients attach to a point node rather than to the gate.

The link between them is the HaLow radio at 802.11ah in the sub-1GHz band, with a typical range of one to ten kilometres or more.

Two optional attachments are shown as dashed lines. A USB sidecar carrying LoRa or Reticulum hangs off a point node, and an RTL-SDR for ADS-B aircraft tracking hangs off the gate.

The consequences of this topology are worth spelling out. Because users attach to point nodes, a point node is a coverage decision, and where you put them determines where the service is. Because the gate is the only node with an uplink, one uplink serves the entire mesh, which is both the efficiency win and the single point of failure that the decentralised design otherwise avoids. And because the bridge interface carries the address range, the mesh looks like one local network to anything connected to it, which is what lets ATAK clients and laptops work without knowing anything about the routing underneath.

The finding and accessing document is the practical companion to this, since a node whose address you cannot find is a node you cannot manage.

The optional pieces, and the six step path to a working node

The quick start is a table of six steps, of which two are required and four are optional, and the order is the order in which you would actually do them.

Step one is the gate node: flash the platform firmware, run the first boot and mesh wizard, plug the node into the router, reach it over SSH, and run the setup script. Step two is adding point nodes, where you plug the node into a laptop and paste the setup script. Steps three through six are the optional integrations, covering ADS-B to CoT for aircraft tracking in TAK, the Reticulum integration for applications on phones and laptops over the Haven WiFi, the ATAK bridge for situational awareness, and the LoRa sidecar for Reticulum over a USB radio module.

The assumption running through all of it is that each node is flashed with fresh firmware for its hardware, and the two platform firmwares are not interchangeable.

There is a step that comes after every one of them, and it is the one that matters most. After any step, the recommendation is to use the LuCI web interface to change the passwords, the WiFi network names, and other settings, and there is a caution that the defaults are for first boot only. A mesh node that is deployed with the factory credentials is a node that anyone in radio range can join, and the fact that the interface is a standard OpenWrt one means the change is a normal administrative task rather than a project specific procedure.

The node itself is described as a compact, rugged unit built for field deployment, with HaLow and WiFi radios, USB and power ports, and mounting that takes a GoPro style bracket and bolt holes. The official case for a Raspberry Pi based MANET is published on Printables, and the enclosure design is credited to MOROSX. The licence there is unusually generous: the model is public domain, so there is no cost to download and no restriction on printing, modifying, or sharing it, and the build guide places the case in the context of the full build with the radios, the power, and the mounting.

Editorial conclusion

Haven fits a team that needs connectivity where there is none, a field deployment, an offgrid event, or a research site, and that is prepared to flash firmware onto single board computers and run the mesh itself. It does not fit a household that wants a wireless network at home, and it does not fit a deployment that cannot have a node physically placed to extend coverage. Verify first that the platform image matches the board, since the Pi 4 and Pi 5 firmwares are not interchangeable and the guide says so explicitly, that the radio and WiFi adapters listed for that platform are the ones in use, and that the first boot defaults are changed in the LuCI interface before the node carries real traffic, because the credentials shipped with a fresh image are for first boot only.

Frequently asked questions

Official sources

1. buildwithparallel/haven-manet-ip-mesh-radio on GitHub
2. Issues
3. License: MIT
4. Project website
5. README