I’m trying to make sense of what is possible with MM8108 devices in the EU and UK regions on the 868MHz band. From what I can determine, LBT is mandated in 802.11ah anyway and AFA is required to avoid the duty cycle restrictions. Due to that, ad-hoc mode and 802.11s mode are unavailable because of the fact that neither mode has the ability to coordinate channel changes with other stations, which makes sense (even if disappointing).
What I can’t understand though is why the MM8108 seemingly refuses to operate both as an AP and an STA to use infrastructure-like semantics for a mesh instead. Any attempt I have made to configure HalowLink2 devices to AP+STA results in one or other interface refusing to start.
Is this a limitation of the chipset or driver, or is there a regulatory angle to this? I would expect that in an AP+STA configuration, channel hopping between the two would work just fine and still be AFA-conformant, as the AP slice can initiate a channel move itself and the STA slice can follow the remote side as it also moves around.
At the moment this is unsupported - I’ll get more specifics about why that is shortly, but it’s likely that there is currently no plumbing to forward through a CSA from a receiving station, to a second AP vif on the same device and have that propagate through the network.
I’m admittedly curious about this one. If you decide to opt out of the default duty cycle for higher throughput by using AFA then this makes perfect sense. However if I enable “Use standard duty cycle”, I would expect this to suppress AFA, allow me to choose a channel (which currently it doesn’t) and allow the full range of modes including 802.11s.
This is a shame as it effectively rules out the potential for anything other than a star topology centred around a single AP, which is very limiting.
I suppose I see the logic with CSA forwarding if you are restricted to operating the whole mesh on a single band and require being able to propagate a CSA downstream, but the alternative is just that the driver “channel hops” between serving AP mode on one channel and participating in STA mode on another in a time-division setup. That way an AP initiating a channel switch only impacts its immediate clients.
in our experience, having a restrictive duty cycle makes the performance of mesh modes quite bad (basically, we’re concerned about people having a poor experience). Having said that, if you’re bringing something up manually I think it should work… how are you configuring things and what devices are you using?
with AFA, our approach to this is still in flux. If we allowed you to configure it, EasyMesh will propagate CSAs, but the evaluation of the approach channel will come only from the controller (i.e. if a downstream AP is experiencing interference, we would not correctly handle this). The ‘time division’ approach you mention is not something we’ve investigated as far as I know, but I suspect this is not easy to implement on Linux.
If you are desperate to have a multi-hop setup in the EU, the straightforward way to achieve it is with another device (i.e. AP --HaLow–> STA --ethernet–> AP --HaLow → STA).
I’m using a HaLowLink 2 EU model with 2.11.8. Even with the standard duty cycle enforcement enabled, I am unable to select anything other than “Auto” for the channel and attempting to configure 802.11s or Ad-hoc modes just never come up (the interface remains “Disabled”):
I was under the impression that the time-division approach was fairly common, it’s how many “mesh Wi-Fi systems” are able to maintain backhaul links and AP mode on the same interface simultaneously. That said I don’t know how simple it is to do. Understand the complexity with EasyMesh though and CSA signalling.
I’m mostly in the evaluation stage right now, but it feels like this approach doesn’t scale either. It’ll work OK in a line-ish topology with low overlap but it will rapidly fall apart when there are lots of mesh points involved.
