Mesh Setup Guide for OpenWRT?

[AT_Labs_Actual]

Hello! I’m working with the Heltec router product and running into a few configuration issues. Is there a simple guide somewhere on setting up and using 802.11s mesh over Halow somewhere? My use case is for a first responder MANET radio (that doesn’t cost tens of thousands) - but I’m struggling to get consistent mesh setups and Heltec’s info is pretty thin. Just thought I’d reach out here as this community seems to be more active.

I’d be interested in a BATMAN guide as well because that gets even deeper (and arguably more in line with my use case) but I’m not holding my breath for that one, haha.

Thanks!

[ajudge]

Looking at the Heltec docs, it looks like they have leveraged most of our SDK directly! Hopefully they’ve included much of the mesh configuration pieces as well!

We have some documentation being written around configuring Mesh, but it is largely targeting our evaluation kits.

If you navigate to “Quick Config” in the UI. Is Mesh Point available as a mode you can select for the HaLow device?

[AT_Labs_Actual]

Thanks so much for replying! I know this isn’t a pure MM device but it is apparent that Heltec did a lot of plug and play with the code base. Even the URLs for the device are Morse. Although, the quick settings don’t have the ability to set the mesh options - instead you have to go through a wizard OR the advanced settings.

The wizard presents you with two initial options:

1. Standard Halow (STA/AP)
2. Halow Mesh 802.11s

When you select the mesh option, you then get two new options:

1. Mesh Point
2. Mesh Gate (contains a collocated network)

If you select Mesh Point, you get three new options

1. Extender
2. Bridge
3. None

In my miniscule understanding, the Extender is the right mode here as I need DHCP on the wired LAN but I can never get the Halow link established. If I have one node set as a gate with an upstream link then everything works great, but in my use case this isn’t a feasible setup.

Maybe my use case will help explain better…

I want to use these as a MANET radio for wildland firefighters and SAR technician. In this use, the user would attach their EUD (phone or computer) to the device over LAN (or USB). That would put the users all on the same LAN so that their devices could seamlessly share data using ATAK. There likely wouldn’t be an upstream network, at least not ordinarily. The goal is simply to be a transparent link between the user devices.

If I can get 802.11s working, then I can further optimize with BATMAN to claw back throughput.

Again, thank you for helping!

[ajudge]

Yep, I understand your setup. It sounds like you might actually want to use “bridge” so that all devices end up on the same Layer 2 network, but we can go over that later. Let’s continue using “extender” for now.

Judging by your comment that everything is functioning when the Mesh Gate is started, I can speculate what is going wrong.

Just to confirm, in your current configuration with only Mesh Points, under the Advanced Configuration → Network → Wireless tab, do you see the other mesh devices showing in the Associated Stations list?

If so, your connectivity issue is most likely related to DHCP. In the extender mode, on the HaLow side, all devices are DHCP clients, and as a result won’t be getting IP addresses! Once you add a mesh gate, it will be adding a DHCP server to your network, issuing addresses to all the devices allowing IP layer traffic to work!

I don’t know much about MANET. How do the endpoint devices (laptops/phones) normally identify/discover each other in these networks? I’m seeing mixed answers online - including the use of IPv6

I’m hesitating to recommend configuring one particular device as a DHCP server, as that sounds like something that won’t be as straightforward to determine which device should be the dedicated DHCP server in the field.

[dblair22]

Which Heltec product did you get? The Heltec HaLow Dongles (HD01) don’t support open Mesh mode, only H7608 does (email Richard to get a refund). HD01 only allows AP/STA mode (yes their documentation says it can do Mesh, but that’s because they copied Morse’s code).

If you have the H7608 as the Access Point, yes you can select " Mesh" then “Mesh Gate” . Then on the HD01 select “Mesh” and “Mesh Point” and that works, as AP/STA’s. You need multiple H7608’s to actually get a Mesh. Multiple HD01’s don’t actually form a mesh, just individual AP/STA connections. I can’t seem to get a HD01 with Mesh Point settings to act as anything more than a Halow Client when connecting to Morse’s HalowLink1.

If you have the Morse HalowLink1 set as an EasyMesh Controller, you can set the HD01 as a Halow Client (Bridge) and it works perfect connected to the Mesh Controller or to any of the Mesh Agents (HalowLink1’s) if you’re roaming. That’s working perfectly for me.

[AT_Labs_Actual]

I am indeed using the router (7608) to do this. I have three in hand and when one is set as a gate I can see all three in the associated stations area.

[AT_Labs_Actual]

I assume the issue is DHCP as well. In my head, I’m thinking DHCP over LAN/WiFi to connect the EUD and then something else for the Halow side so they don’t fight with each other to establish link - but I’m unsure how to set that up.

With these specific units, if I go with the bridge then I no longer have access to the control panel over any interface - it’s like it changes internal IP address and I can’t see what it is.

As an aside - Does MM have a product that would fit in this space (small, low power requirements) that would be more successful than these Heltecs? I’m a system integrator more than PCB developer, so I’m more inclined to obtain finished devices that I can incorporate into my rugged ecosystem instead. I’m open to ideas there.

Here is my current LoRa product that will eventually be supplanted by this Halow system.

[ajudge]

With these specific units, if I go with the bridge then I no longer have access to the control panel over any interface - it’s like it changes internal IP address and I can’t see what it is.

The reason I suggest to use bridge is it bonds the HaLow and ethernet interfaces into the same Layer 2 domain. This will help you not think about layer 3 routing, and in the case of some of our extender nodes, you won’t need to worry about NAT, which should make communication between attached end-point devices (laptops/phones), a bit more seamless as they will be in the same subnet/address space.
What’s happening when you select this, is the radio is actually losing its IP address. The device will be trying to act as a DHCP client and looking for a DHCP server where it can request a lease.

You will find, there are ways to access the device even when it doesn’t have an IPv4 address. All devices should have a unique IPv6 link local address (if IPv6 is enabled) based on the MAC address. At least for Windows endpoint devices, you can simply use that address to connect to the radio. Unfortunately there are some quirks around the web URI standard here which does complicate this on Linux/OSX.
If the device has an mdns service running, you can often still connect to the WebUI using the hostname in your browser despite the device not having an IPv4 address. Your browser/host will send an MDNS query, and if the device responds with an answer containing an IPv6 address, your browser can then establish the connection that way.

I’m thinking DHCP over LAN/WiFi to connect the EUD and then something else for the Halow side so they don’t fight with each other to establish link - but I’m unsure how to set that up.

It might need some thought around the network as a whole. I’ve been doing some reading on distributed dhcp servers and other methods of IP address allocation in MANETs. Nothing has really stood out yet as the “best solution”. But I have an idea:

You could configure every radio with it’s own unique static IP, and a DHCP server, but a wide subnet mask. This will mean you have multiple DHCP servers on the network (for automatically assigning addresses to the end devices attaching directly to the radios) but still give you access to every other device on the subnet. This is basically a naive distributed DHCP.
This will mean you can always access the radio device, but also let you bridge the interfaces so you don’t need to worry about layer 3 routing. However, it could get complicated in the sense that you need to then be setting unique IPv4 addresses for each device (and then I start leaning to IPv6).

You could modify it slightly, and perform some address collision detection before assigning an address, but this will require some software development, rather than just configuration.

I intend to set something up in a few days using our evaluation kits - which the Heltec devices are based on - so I can make a more concrete recommendation.

Does MM have a product that would fit in this space (small, low power requirements) that would be more successful than these Heltecs?

As we are strictly a chip company, we try to let our customers build the products! The HaLowLink1 was a bit of an exception to that. So unfortunately no, we don’t have a product that would be more suitable than the Heltecs.
I’m confident we can configure the Heltec devices in a way which suitable for your application.

[AT_Labs_Actual]

@ajudge were you ever able to make any headway with your testing?

[ajudge]

Hey @AT_Labs_Actual

Thanks for the prompt. We did run through a few configurations but I’m not particularly happy with the solutions so far.

My ideal configuration would have been to ensure IPv6 link local addresses are assigned on all devices (this should happen by default), in a bridged mode, and then address each device by <hostname>.local - allowing mdns to resolve the hostnames and initiate connections. This would also ensure consistent functionality should a DHCP server/gateway device appear in the network. While this worked, unfortunately the end device experience with IPv6 link local is a bit of a mixed bag, with some hosts struggling to resolve connections to devices - especially when that host has multiple interfaces. On Windows in particular, it can take multiple connection attempts before the right “zone” is chosen.

I did attempt the same thing again but with IPv4 link local. This appeared to behave as I expected, but requires the installation of luci-proto-autoip which depends on avahi. This might not be possible on flash constrained devices. It’s also strictly not routable, and you can expect to see issues should you suddenly require a gateway in your network.

This is something we will keep looking at in the background - you’re not the first to bring up a MANET, but I’m under the impression a truly unmanaged network requires a bit of a re-think to the network addressing layer (possibly distributed dhcp?), which may have implications on the application running on top.

What software typically runs on top of these radios? How are the EUDs expected to communicate with each other? Or is this ultimately what you are trying to design?

[AT_Labs_Actual]

Thanks for the quick reply!

Our primary software stack would be ATAK (which also necessitates Android) for sharing data, multicast voice, video streams, etc. In fact, we’re all-in on ATAK with current development happening on a plugin which would control the radio from inside ATAK itself (CLI commands). The earlier discussion on IP probing is part of our line of thinking with developing that plugin, but we’re still trying to get the network details working at all first.

Being able to attach a Windows machine to the network is of less value to us, but it’s surely myopic to not include that. I think for an initial system we’d be fine with just Android EUDs.

The unfortunate truth about the Heltec units is that they are SUPER constrained on available flash. The available storage is about 2Mb which limits us on any additional software tweaks. We’ve been looking at essentially copying their core design but with a different footprint and a larger SoC to enable things like USB data storage, etc… but that’s outside this scope for sure. That’s why I mentioned seeking an additional system manufacturer originally, as having access to other OpenWRT software mods may make this easier in the long run.

I’m open to experimenting with any ideas you come up with, even ones that require some additional dev to make workable in a final implementation!

[ajudge]

To actually address the original question in your thread, we’ve recently opened up a bunch of our Application Notes to the public! We have a setup guide I can publicly refer too now, available here: How to Configure 802.11s Mesh (App Note 32). This App Note mainly focuses on our own HaLowLink1s as the development platform, but the configuration should mostly translate to the Heltec devices if they’re based on a recent build of our evaluation kit software. Give this guide a go (3.2 is probably more relevant for you) on the Heltec devices to get a better handle on the meshing.

---

Back to the problems:

Android might add an extra set of complexities. Minimal testing on my phone (so a sample size of one) shows my device appears unwilling to bring up the interface unless it acquires an IPv4 address. This could also be a vendor specific decision.

This, plus ensuring you have a permanent mechanism for communicating with the radio makes me start leaning more towards a routed mode, not a bridged mode as the above guide recommends.

As I see it, you want to do the following things:

• address assignment/autoconfiguration
• routing/port forwarding (if not bridging)
• discovery
• control using some sensible api (eg to discover other nodes behind the NAT)

I think autoconfiguration remains a problem, but it might be solvable. Some more of the recent reading I was doing:
Autoconf
PACMAN
MANET

For now, experimentally, perhaps you should set a unique static IPv4 address on the HaLow mesh point interface and have each device bring up a DHCP server on the ethernet/2.4GHz interface. Then just focus on the development required for the control/communication of the radio and the network.
We’ve used a configuration like this in some deployments. Below is a screenshot of the quick config page from one mesh point device.

Does ATAK stand up a listen port? After creating the route, you may want to create a port forward to traverse the NAT: Configuring Port Forwarding on the Linksys OpenWRT router - Linksys Support

For remote control of the radio from the phone, OpenWrt includes access to ubus over HTTP, which you could leverage for remote control/configuration without falling back to ssh. See Access to UBUS over HTTP

Then for discovery, you will want to look at advertising that port as a service via umdns. umdns can be operated via ubus - see ubus -v list umdns on the Heltect device (if umdns is installed).

I know that’s still a bit “hand wavey” and high level. Hopefully it provides a good start for you? Happy to go into specifics for each part as you require.