Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Wrong channel width on mesh network #487
there are sightings, that the client wifi networks correctly starts on 20 mhz channel width and only switches to 40 mhz, if there isn't too much traffic on the 2nd channel, but not the mesh network.
The mesh network seems to always use 40 mhz.
Is this a bug? Or a feature? I expect Gluon to set the mesh network to 20 mhz by default and only activate the 2nd channel if no other networks are influenced, just as the wifi standard requests.
Hexa mentioned that it might be the case, that hostapd only controls the client network, but not the adhoc network.
Is there a way to set the mesh network to automatically switching or at least to 20 mhz fixed, while the client network still switches automatically, which seems to work quite perfect.
As far as I know you can't set different channel widths for the client and the mesh network if they are VAPs.
This is mostly wrong.
It it no problem if different mesh participants use different channel widths, as there is always a primary and a secondary channel with HT40 (for example 1+5). Just the primary channels have to match.
Different VIFs can use different channel widths; broadcast frames are always sent on the primary channeln only, for unicast frames this is negotiated per peer (so in theory, the channel width is defined individually for each frame).
Our current plan to approach this is to completely drop HT40 support and set everything to 20MHz, as there is no way to use 40MHz channels without violating regulatory rules when there is more than a single Gluon node.
Okay. Thank you for clarifying that. And sorry to all that I was that wrong.
@NeoRaider You say "in theory, the channel width is defined individually for each frame" but that actually violates IEEE 802.11-2012 in many cases. That's why you want to drop HT40, because there is no proper fallback for ad-hoc networks, yet and it would not be easily possible to add a performant fallback for ad-hoc networks?
BTW from a hardware view what you said means that devices capable of HT40 actually need two trans/receivers, because it wouldn't be physically possible to switch the channel width that fast with a conventional QAM transmitter. Thus it is not a real channel width, but two channels used simultaneously Learned something new...
added a commit
Sep 19, 2015
In my opinion, we should just remove support for HT40 (and above) and always set the WLAN to HT20/NOHT (whatever is supported by the adapter).
@MPW1412, even now, the client network will switch to HT20 as soon as there's another Freifunk node in a node's proximity. As a single node isn't really a usecase worth to consider for Freifunk, we've come to the following conclusion:
We'll drop the 'htmode' field from the site.conf, and completely switch to HT20 for now, until we have clarity in which situations HT40 is allowed to use. @T-X suggested to get in contact with the Bundesnetzagentur to get some guidance how to build mesh networks without violating the reguations, which sounds like a good idea.