New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong channel width on mesh network #487

Closed
MPW1412 opened this Issue Sep 9, 2015 · 8 comments

Comments

Projects
None yet
3 participants
@MPW1412
Contributor

MPW1412 commented Sep 9, 2015

Hello,

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.

Bye
MPW

@MPW1412

This comment has been minimized.

Show comment
Hide comment
@MPW1412

MPW1412 Sep 10, 2015

Contributor

Information from Neoraider: The mesh network is not managed via hostapd, but by the /lib/network/wireless/mac80211.sh skript. There is no auto switching for adhoc networks, so at least the adhoc network should be set to 20 mhz fixed.

Contributor

MPW1412 commented Sep 10, 2015

Information from Neoraider: The mesh network is not managed via hostapd, but by the /lib/network/wireless/mac80211.sh skript. There is no auto switching for adhoc networks, so at least the adhoc network should be set to 20 mhz fixed.

@CodeFetch

This comment has been minimized.

Show comment
Hide comment
@CodeFetch

CodeFetch Sep 17, 2015

Contributor

As far as I know you can't set different channel widths for the client and the mesh network if they are VAPs.
Furthermore in an ad hoc network all participants need to use the same channel width.
Thus if you need a 20 MHz channel width, you must set it for all virtual interfaces in the mesh cloud.
These are just my two cents and I admit, that I havent actually tried it. But it would really be a surprise to me if those Atheros devices could switch their channel width that fast.

Contributor

CodeFetch commented Sep 17, 2015

As far as I know you can't set different channel widths for the client and the mesh network if they are VAPs.
Furthermore in an ad hoc network all participants need to use the same channel width.
Thus if you need a 20 MHz channel width, you must set it for all virtual interfaces in the mesh cloud.
These are just my two cents and I admit, that I havent actually tried it. But it would really be a surprise to me if those Atheros devices could switch their channel width that fast.

@NeoRaider

This comment has been minimized.

Show comment
Hide comment
@NeoRaider

NeoRaider Sep 17, 2015

Member

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.

Member

NeoRaider commented Sep 17, 2015

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.

@CodeFetch

This comment has been minimized.

Show comment
Hide comment
@CodeFetch

CodeFetch Sep 18, 2015

Contributor

Okay. Thank you for clarifying that. And sorry to all that I was that wrong.
I recently read that all devices must fall back to HT20 if there is one device on a channel which is not capable of doing HT40. That info seems to be false. If there is an HT40 intolerant Client connected to a router in STA mode, the router must fall back to HT20 as long as the client is "connected" whether it is idle or not. That sounds really weird to me, but that seems to be the actual behavior the IEEE wants to see.
It's the same with the 20/40 BSS Coexistence management frame. If there is a neighbouring STA on the secondary channel, whether idle or not, the station should fall back to HT20.

@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?
What about 802.11s networks? Can we use them in HT40 mode without violating IEEE guidelines?
Please correct me if I'm wrong. I'd really like to grasp it.

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...

Contributor

CodeFetch commented Sep 18, 2015

Okay. Thank you for clarifying that. And sorry to all that I was that wrong.
I recently read that all devices must fall back to HT20 if there is one device on a channel which is not capable of doing HT40. That info seems to be false. If there is an HT40 intolerant Client connected to a router in STA mode, the router must fall back to HT20 as long as the client is "connected" whether it is idle or not. That sounds really weird to me, but that seems to be the actual behavior the IEEE wants to see.
It's the same with the 20/40 BSS Coexistence management frame. If there is a neighbouring STA on the secondary channel, whether idle or not, the station should fall back to HT20.

@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?
What about 802.11s networks? Can we use them in HT40 mode without violating IEEE guidelines?
Please correct me if I'm wrong. I'd really like to grasp it.

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...

@NeoRaider

This comment has been minimized.

Show comment
Hide comment
@NeoRaider

NeoRaider Sep 18, 2015

Member

@CodeFetch, you seem to know the standards better than I do, I might also be wrong about details of what I said. My knowledge on the topic is mostly based on IRC discussions...

Member

NeoRaider commented Sep 18, 2015

@CodeFetch, you seem to know the standards better than I do, I might also be wrong about details of what I said. My knowledge on the topic is mostly based on IRC discussions...

fpletz added a commit to freifunkMUC/site-ffm that referenced this issue Sep 19, 2015

@NeoRaider NeoRaider added this to the 2015.2 milestone Oct 11, 2015

@NeoRaider NeoRaider added the bug label Oct 11, 2015

@NeoRaider

This comment has been minimized.

Show comment
Hide comment
@NeoRaider

NeoRaider Oct 23, 2015

Member

@tcatm, @T_X, @jplitza, what is your opinion on this issue? Is my conception correct that there's no way to do HT40 with more than one mesh node within the allowed bounds?

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).

Member

NeoRaider commented Oct 23, 2015

@tcatm, @T_X, @jplitza, what is your opinion on this issue? Is my conception correct that there's no way to do HT40 with more than one mesh node within the allowed bounds?

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

This comment has been minimized.

Show comment
Hide comment
@MPW1412

MPW1412 Oct 24, 2015

Contributor

Will the client network still switch to HT40 if you set the mesh network to HT20 fixed?

Contributor

MPW1412 commented Oct 24, 2015

Will the client network still switch to HT40 if you set the mesh network to HT20 fixed?

@NeoRaider

This comment has been minimized.

Show comment
Hide comment
@NeoRaider

NeoRaider Oct 27, 2015

Member

@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.

Member

NeoRaider commented Oct 27, 2015

@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.

@NeoRaider NeoRaider closed this in 3ddcf50 Oct 27, 2015

phi-psi added a commit to phi-psi/gluon that referenced this issue Nov 7, 2015

Revert "Drop htmode field from config, always use HT20"
This reverts commit 3ddcf50.
there are no citations in freifunk-gluon#487
I trust the OpenWrt and linux wireless team setting valid regulatory values

Tarnatos added a commit to Freifunk-Nord/nord-site that referenced this issue Nov 20, 2015

oleeander added a commit to hackspace-marburg/ffmr-site that referenced this issue Dec 13, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment