Unclear from the product datasheets versus some marketing material; does the hardware/firmware (hostapd_s1g, morse_cli) support it or is it left to higher-layer software to handle any meshing in the HaLow area?
Hi @bstewart
There’s a few details so will answer this with short clear responses.
- Yes we have three types of mesh support for our Linux based platforms - 802.11s, Easy Mesh, and Ad-Hoc + software.
- This mesh support is not currently handled in the MM6108 chip firmware. For 802.11s mesh it is handled in the upper mac (ie, mac80211 for Linux).
- We don’t yet support mesh for our microcontroller offering.
EasyMesh uses application layer software to manage the meshing. The device just needs to bring up an AP and a station.
To mesh with ad-hoc (IBSS), you will require application level software - see B.A.T.M.A.N.
It sounds like you were looking for 802.11s mesh.
I already have one of my boards setup as an AP and one as a station talking on HaLow. As far as I can tell, the channel (i.e. 28) is translated to a HT channel and that’s how Linux is interpereting it (channel 100 : 5570MHz)
# On the AP
root@noble-venice:~# iw dev
phy#0
Interface wlan0
ifindex 6
wdev 0x1
addr 1c:bc:ec:33:56:42
ssid MorseMicro
type AP
channel 100 (5500 MHz), width: 160 MHz, center1: 5570 MHz
txpower 24.00 dBm
multicast TXQ:
qsz-byt qsz-pkt flows drops marks overlmt hashcol tx-bytes tx-packets
0 0 25 0 0 0 0 2316 25
Given that WORKS nicely as an AP, and a station can connect and ping all good, I decided to move to getting a HaLow mesh setup.
From that, I followed general instructions on setting wlan0 to a mp and attempted a connection between the two devices (both as mesh points) but was completely unsuccessful
ip link set wlan0 down
iw dev wlan0 set type mp
ip link set wlan0 up
iw dev wlan0 mesh join halowmesh freq 5570 HT20
ip addr add 192.168.100.1/24 dev wlan0
#on the other board, replace with 192.168.100.2/24
My networking experience on this level isn’t too good, so if theres an obvious error there do let me know, or any debug messages that could show what’s not working.
Question for future reference: How do most people go about implementing this in Linux? I’ve been struggling to find the proper documentation on how to use your programs/code to work with iw and the general networking stack on Linux, and it’s frustrating to have nothing working at all (see my thread on the EKH05 not getting a response either). Maybe if I understood the abstraction layer where everything above it works exactly as intended, it would be easier. Is there any successful documentation of getting mesh setup (through any method, but the 802.11s would be preferred) so I can run reliability tests? Mesh doesn’t seem to need the hostapd_s1g or supplicant_s1g, and maybe I need to go through one of those to get mesh setup? A pointer in the right direction would be great and maybe you can figure out where my understanding is messed up.
Thanks again!
It’s not immediately obvious to me what is going wrong with your current configuration. Except that we typically use wpa_supplicant to stand up the mesh point. I will attempt a mesh configuration directly with iw and see if I can reproduce what you are seeing.
For the wpa_supplicant based configuration, this largely follows what is described on this page ath10k mesh mode — Linux Wireless documentation.
Here’s a supplicant config from a mesh point on my desk, as generated from our OpenWrt netifd handlers on our evaluation kits:
~: cat /var/run/wpa_supplicant-wlan0.conf
country=AU
ctrl_interface=/var/run/wpa_supplicant_s1g
sae_pwe=1
max_peer_links=10
mesh_fwding=1
network={
ssid="HaLowMesh"
key_mgmt=SAE
mode=5
channel=44
op_class=71
country="AU"
s1g_prim_chwidth=1
s1g_prim_1mhz_chan_index=3
mesh_rssi_threshold=-85
sae_password="12345678"
pairwise=CCMP
ieee80211w=2
beacon_int=1000
}
which is then started as normal with: wpa_supplicant_s1g -t -D nl80211 -s -i wlan0 -c /var/run/wpa_supplicant-wlan0.conf -B
Note that using our wpa_supplicant_s1g gives you access to some of the s1g specific channel configuration such as primary channel width and primary channel index, so you shouldn’t need to worry about the frequency mapping so much. Though you will need to understand the global op_class setting.
We do have some patches to mac80211 to enable management frame protection in the mesh network. See mac80211: Mesh support · MorseMicro/linux@f948c7a · GitHub. I believe you should be able to stand up a functional mesh network without it - just remove ieee80211w=2 from the supplicant config.
How do most people go about implementing this in Linux?
As far as I understand it, most user space network management software relies on wpa_supplicant under the hood, and I suspect they use the same for mesh points. There are extra complexities around the automatic management of backhaul links and routing through the mesh network, which can become a bit overwhelming - see mesh11sd and B.A.T.M.A.N.
Maybe if I understood the abstraction layer where everything above it works exactly as intended
Do you mean the 802.11ac shim layer we have implemented? The driver showing up as 5 GHz?
We are working on removing that, but it is a very slow process. We’re currently looking at delivering more documentation directly through our website, so I’ll see if there is something useful for that mapping which we can make more publicly available.
I need to go through one of those to get mesh setup?
I would say definitely stick with wpa_supplicant for now for configuring mesh, as it is how we qualify and test mesh configurations. I will take a look as to what might be happening with the direct iw configuration.
Hope this helps, let me know if I missed anything!
Thanks for the detailed reply! The wpa_supplicant sounds like the route to go and I’m most interested in getting 802.11s mesh setup.
Upon running supplicant w/ your example config, I got a segfault from undefined/out of bounds parameters which pointed me in the direction of CONFIG_MESH when building hostap and wpa_supplicant. Other than CONFIG_MESH what extra flags do you recommend (while testing) that aren’t set in the defconfig? It’s not exactly clear if I need any other flags to get mesh fully setup and maybe you could share the way that MorseMicro goes about building all the necessary dependencies or if you have a build system, as at the moment there’s relatively little documentation. We followed the Quectel User Guide but are still looking for more intuitive/descriptive methods of integrating the morsemicro environment.
I’ll soon test the supplicant with the CONFIG_MESH flag and hope that it resolves the issues, but if you have any other pointers in the meantime it would be greatly appreciated!
Best,
Blake
In case it is helpful, see MM-APPNOTE-24-Linux-Porting-Guide.pdf (4.8 MB)
Though it sounds like you might already be aware of this.
The defconfig it refers too should have all configurations required (CONFIG_SAE, CONFIG_DPP etc) for basic HaLow bring up. Enabling CONFIG_MESH is all that is needed in addition to the defaults to enable mesh.
Nothing else immediately comes to mind. But keep updating this thread, happy to continue assisting if you bump into something else.