Mesh network not behaving as expected

General
1

Hi!

I am setting up an 802.11s mesh but it is not behaving as expected in a multi‑hop scenario. Here is my setup:

  • Mesh gate (MG): This is either a Heltec or Alfa Halow router set up as a Mesh gate through the UI wizard. It runs a DHCP server to hand out IP addresses to all devices on the network
  • Laptop: It is connected to the Mesh Gate via ethernet no other router or upstream network.
  • Mesh Point 1 (MP1): This is a Heltec router. It is in range of the Mesh Gate via Halow.
  • Mesh Point 2 (MP2): This is my custom hardware. It uses a static IP. It is basically a camera that transmits video via Halow. It uses AsiaRF’s Halow module, and is controlled by an i.MX8M-Mini running Yocto.

What works

  • If MP1 and MP2 are both in range of the Mesh Gate, they associate directly to MG and everything works.
  • I can stream video from MP2 to the laptop via MG without issues.

What fails

When I move MP2 so that:

  • MP2 is out of range of MG,
  • but MP2 is in range of MP1

then:

  • MP2 associates to MP1 (shows up in MP1’s associated stations list),
  • but MG cannot ping MP2 and no traffic is forwarded through MP1.
  • On MG/MP1, MP2’s MAC shows up, but the UI never learns an IP for it (“?”)

Below is the wpa_supplicant_s1g file running on MP2.

 ctrl_interface=/var/run/wpa_supplicant_s1g
 update_config=1
 country=US
 pmf=2
 sae_pwe=1
 max_peer_links=10
 mesh_fwding=1

 network={
    ssid="\[SSID\]"
    key_mgmt=SAE
    sae_password="\[PASSWORD\]"
    pairwise=CCMP
    ieee80211w=2

    # Mesh mode
    mode=5

    # 904.5 MHz, 1 MHz BW, US
    channel=5
    op_class=68
    country="US"
    s1g_prim_chwidth=0
    s1g_prim_1mhz_chan_index=0

   beacon_int=1000
   dtim_period=1
   mesh_rssi_threshold=-85
}

I have tried a lot of different settings and configurations, but I am unable to get it to work. Perhaps my understanding of 802.11s is flawed, or somehow the hardware does not support it.

Any help is much appreciated!

2

Hi @SanderV

I’m definitely no mesh expert myself, but will run this by someone internally who may know more. There are a few things that stand out to me, and some things to consider in the meantime.

  • mesh_fwding might need to be included in the network block. Other configs I’ve seen place it there rather than the global section.
  • traffic will need to flow before MG builds the ARP table to map the IP to the MAC address. This could even be a DHCP exchange, but a ping will suffice (once the routing is working).
  • On the other nodes running OpenWrt, you can find their mesh configuration at /var/run/wpa_supplicant-wlanX.conf. It would be worth inspecting this and comparing your configuration.

The other thing I’m uncertain about is how mesh11sd may be interacting. It shouldn’t cause what you’re seeing, so have a look at the above first and then we can consider mesh11sd.

3

Hi @ajudge

Thanks for your reply!

I moved the mesh_fwding property to the network block, but the behavior remains unchanged.

During testing I did notice that when I first connect MP2 to MG so it get an IP address, and then move MP2 out of range from MG, but in range of MP1 I can ping it just fine. So your theory on the ARP table seems likely.

Find below the wpa_supplicant on the routers used. The only difference between MG and MP1 here is the dot11MeshGateAnnouncements property.

country=US
ctrl_interface=/var/run/wpa_supplicant_s1g
sae_pwe=1
max_peer_links=10
mesh_fwding=1
network={

    ssid="RescueRatMesh"
    key_mgmt=SAE
    mode=5
    channel=5
    op_class=68
    country="US"
    s1g_prim_chwidth=0
    s1g_prim_1mhz_chan_index=0
    dtim_period=1
    mesh_rssi_threshold=-85
    dot11MeshHWMPRootMode=0
    dot11MeshGateAnnouncements=1
    mbca_config=1
    mbca_min_beacon_gap_ms=25
    mbca_tbtt_adj_interval_sec=60
    dot11MeshBeaconTimingReportInterval=10
    mbss_start_scan_duration_ms=2048
    mesh_beaconless_mode=0
    mesh_dynamic_peering=0
    sae_password="[PASSWORD]"
    pairwise=CCMP
    ieee80211w=2
    beacon_int=1000
    mac_addr=3
    mac_value=e4:38:19:1f:f0:17

}

4

Without having had a chance to test anything. Can you make sure your kernel has the mac80211: Mesh Support patch as per mac80211: Mesh support · MorseMicro/linux@272137c · GitHub (which targets the 6.12.21 kernel for example).

Without this, path selection may not function correctly on a link with management frame protection enabled (ieee80211w).

5

Thanks! I did not apply that patch when building the image.

I am running the kernel version below. Is that patch available for it?

root@ucm-imx8m-mini:~# uname -r
5.10.35-ucm-imx8m-mini-2.2.1+ge47d436930ca
6

We have patches for a 5.10.11 kernel, which should be close enough that it will apply. For the mesh support, see mac80211: Mesh support · MorseMicro/linux@77e5dc0 · GitHub

You might want to consider examining the full list. For patches provided as of our 1.16 release, see mm/linux-5.10.11/1.16.x

7

Great, I found a few that might be worth applying. I won’t have time in the next couple of days, but I will check back in once I have done this with the results.

1 Like