I have spent 3 days checking my facts ... and pretty sure this is a bug.
To be clear - I do have the 802.11s mesh working in simple cases. It is on the 'edges' that I see problems.
Consider a case with:
- 3 OpenWrt devices [A],[B],[C]
- V19.07.4
- All in a row
- All have static IP addresses on the LAN-WLAN0 bridge
- All OpenWrt devices have STP (spanning Tree) enabled on the LAN device. (But with only one LAN connection, this is irrelevant)
- Only [C] has a hardwire link (Ethernet) to the local LAN. The LAN has a DHCP server.
- Mesh radio links exist as follows
- [A]-[B]
- [A]-[C]
- [B]-[C]
- Connect a laptop to LAN port on [A]
- Laptop gets DHCP address.
- From the LAN can ping [A], [B], [C], and Laptop
- SSH into each of [A], [B], [C]
- each OpenWrt device can ping the other two OpenWrt devices
- all good!
Now ... move [A] so that it is beyond the range of [C]
- Mesh links exist only as follows
- [A]-[B]
- [B]-[C]
- Connect a laptop to LAN port on [A]
- Failure of Laptop to get DHCP address
- SSH into each of [A], [B], [C]
- each OpenWrt device can (still) ping the other two OpenWrt devices
- From the LAN can ping [A], [B], but NOT [C] or laptop
- Disabling STP does not change anything
So ... it appears that the 'design rule' for these mesh networks is as below (With a Portal Node being defined as one with a hardwire LAN connection)
ALL mesh Points must be in radio contact with ALL Portal Node (s)
This largely defeats the value of using the mesh.
This is a great pity as the other 802.11s mesh benefits are great.
Suggestions?
Comments?