Opened 4 years ago

Last modified 3 years ago

#16667 reopened defect

r40887: hwmode defects

Reported by: anonymous Owned by: developers
Priority: highest Milestone: Chaos Calmer 15.05
Component: base system Version: Trunk
Keywords: Cc:


Since r40887 is seems to be impossible to select hwmode auto on a UBNT NSL5M - /sbin/wifi stalls.
hwmode 11a is possible but leads to 802.11n rates.
LuCI is still missing manual rate selection in r10253.

If this behaviour is by design, the design is flawed now.

Attachments (0)

Change History (21)

comment:1 Changed 4 years ago by nbd

You can disable 802.11n by setting htmode to something else

comment:2 Changed 4 years ago by nbd

  • Resolution set to worksforme
  • Status changed from new to closed

comment:3 Changed 4 years ago by anonymous

Excuse me, Sir: Jow recently explained to me, that LuCI is now doing it the way OpenWRT is demanding for.

That is: We have htmode: NOHT ('disabled#), HT20 ('20 MHz') and HT40 ('40 MHz')

As you may know, the "htmode NOHT" IS NOT EQUIVALENT to 802.11g only, but means "send cts-to-self", which prevents collisions in between mixed environments only.

HT20 and H40 (former HT20, HT40- and HT40+) where supposed to set up devices in "Greenfield Mode", i.e. they expect their link partner to use the same 802.11n mode only.
Despite this selection, the devices are still capable of receiving and understanding previous standard's data rate, but older devices will interpret n-Rates as ignorable noise, and keep sending.
CTS-to-self will in contrary announce, that in the following x timeslots, older devices in the same broadcast domain should just shut up instead.

I have no ability to restrict my device to g-only right know (besides setting rates/ratesets manually in /etc/config/wireless which may in turn reproducibly lead to droputs of the wifi-interface after 2-4 hours in this constellation (at least on some shortly-after-12.09-snapshots).

I suppose, you mixed something up. The design is broken.

comment:4 Changed 4 years ago by anonymous

  • Resolution worksforme deleted
  • Status changed from closed to reopened

comment:5 Changed 4 years ago by anonymous

Matthew S. Gast, 802.11 ® Wireless Networks: The Definitive Guide², 2005, O'Reilly
Pages: 324 following, 'Protection'; 338, Figure 15-1. 'MAC efficiency'; 339 following: 'Protection' [may be outdated now, see same author, 802.11n: A Survival Guide, 2012, O' Reilly; pages 72-75

comment:6 Changed 4 years ago by malaakso

Setting htmode to NOHT disables 802.11n completely. If you wish to only disable greenfield (note that most of the wireless chipsets don't even support greenfield), use option greenfield 0 in wireless config. You can easily see this is the case by reading through

comment:7 Changed 4 years ago by anonymous


Is that a recent change or something older?

Well, if, what you say is correct, while it would make sense since "n is set up on top of g" and corresponds to Gast's "n survival guide", it does not work accoring to my observations on older and newer hardware with ath9k. I.e. TL-WR842ND, TL-WR741ND, TL-WR1043NDv2, TL-WR1043NDv1, Ubnt NSL M5, ...
NOHT does not seem to have influence on the usage of (outgoing) (n-Rates) MCSx, while minor changes in the reliability of compatibility modes with older hardware are mentionable.

Furthermore greenfield mode is undocumented in the luci wiki (at least it was when I wrote this ticket.)

Does netifd do what it does using the iw utility? Where should I debug?

comment:8 Changed 4 years ago by malaakso

In AP mode hostapd takes care of everything. In other modes iw is used. Greenfield only applies to AP mode. You could probably debug the script I linked earlier.

comment:9 Changed 4 years ago by anonymous

So what about adhoc mode?
I have several adhoc mode devices, that have interoperability problems: that is ubnt bullet m2, airgrid m2, nanobridge m2, ... that still have Broadcom chipsets most of them WRT54GL oder Buffalos as link partners. In the past, data rates where low (fallback to 802.11 rates sometimes 802.11b rate, despite sufficient rssi-s on both sides would have allowed for higher g-rates.
deactivating htmode in former OpenWRT-Versions did not seem to have any influence on n-rates, where these were possible, but the elder hardware improved a bit, the amount of collisions was reduced a litte bit.

Greenfield mode should be off by default, leading to cts-to-self in basically all cases.
Those, who need additional performance may still activate greenfield mode.

I understand, that some provider hardware unfortunately does not handle this that way, but is rather shipped with protection modes off, which in turn leads to problems, what leads to users increasing power levels, using repeaters (that also ignore protection modes by default), what leads to collisions, noise and users increasing txpower....

comment:10 Changed 4 years ago by anonymous

I guess the luci guys don't yet know about the new options, do they?
Could you send over a list of functions and options, that netifd is now capable of, that luci does not yet implement?

comment:11 Changed 4 years ago by malaakso

I'm not totally sure, but I think greenfield is always disabled for Ad-Hoc. In any case, most drivers, including ath9k, don't support greenfield anyway.

comment:12 Changed 4 years ago by anonymous

Greenfield should be disabled in any mode = i.e. Cts to self for compatibility is on, i.e. formerly known as "mixed mode". That option is now gone. Instead the luci guys mix up "Band" and "Wifi-Standard", the option for greenfield is still missing.
In urban surroundings, APs and Adhocs should always try CTS-to-self, long preamble and not more than 20 MHz bandwidth in n (and following) standards.

I am a little bit confused now:
"NOHT" in adhoc is an additional option of the iw utility, but does not seem to influence rates.
The string "RX Greenfield" is contained in /usr/sbin/iw, but it seems to be contained in the capability list...
My TL-WR1043ND v2 does not show this capability (and of course it's nonsense. every chip is capable of that... it's part of the standards.)
BTW: Capabilities: 0x11ef

comment:13 Changed 4 years ago by anonymous

but does not seem to influence rates: on older versions.
It's likely, that will break compatibility with older config files...

comment:14 Changed 4 years ago by jow

"The LuCI guys" do not mix anything but simply expose stuff the way it has been asked for by OpenWrt. Take the ui out of the loop and agree on the OpenWrt side first.

comment:15 Changed 4 years ago by malaakso

Your router uses ath9k and thus greenfield is always disabled. But you are right, it should be disabled by default for all drivers.

comment:16 Changed 4 years ago by anonymous

Grepping recursively through /lib/* I found matches on RX Greenfield in the mac80211.ko module.
It seems, that is undocumented and modinfo does not expose further information.
Any hints?

@Jow: Luci does not implement a lot of things available in OpenWRT. Furthermore it hides many essential settings. It is difficult to track errors, if neither projects currently publish sufficient documentation. (Or at least blog weekly about changes done.) Contributing code always requires a lot of googling, going through older documentation, ... BTW: I don't like netifd. This concepts consumes to much ressources, the code is not well commented, ... and again it does not correlate well with the ui: e.g.: Txpower offsets. You can set "0" dBm, but netifd may still offset to a higher value. Why enabling lower values, when they are ineffective?...

"Your router uses ath9k and thus greenfield is always disabled."
Where do you have that information from. I'd like to read more about this. Thanks!

comment:17 Changed 4 years ago by nbd

  • Resolution set to worksforme
  • Status changed from reopened to closed

Greenfield is now disabled by default as of r41300
I don't know what information you looked at regarding MCS rates and htmode=NOHT, but I checked it again today and setting htmode this way does disable 802.11n completely in AP mode.

comment:18 Changed 4 years ago by anonymous

  • Resolution worksforme deleted
  • Status changed from closed to reopened

I had various firmware revisions on several devices. One still had a flavour of r35015 on it and one was a post-r31650, on it.
It seems, that it did not work on those, while it did work on a fresh install of r41181.
Still this is confusing and breaks backwards compatibility.

Furthermore, there is one more question:
If NOHT disabled 802.11n mode, does it have influcence on b+g mixed mode?
More precisely: Is CTS-to-self now enabled in all cases by default or not?

As stated before the newly added option "greenfield" [0|1] is not available on older versions of OpenWRT.
The greenfield mode option seems to be present for the mac80211.ko kernel module (in RX), but does not seem to be implemented yet in ath9k.
The greenfield option is also missing in LuCI.

I have seem compatibility issues with an ancient wrt54gl in client mode, not being able to associate to a TL-WR842ND running r41181. I am still looking for the reason. (I can associate with a laptop running ubuntu, windows ..., I cannot associate with wrt54gl running openwrt/freifunk, and it is not working with dd-wrt either.)

So it still does not work for me and I need more information. Could you publish some info in the wiki and link to it from here before closing?

comment:19 Changed 4 years ago by anonymous

Information required - Ho exactly do RTS/CTS, CTStoSelf and Greenfield work in combination with ath9k?

comment:20 Changed 4 years ago by anonymous

Does anyone have an answer on how RTS/CTS, CTStoSelf, Greenfield are implemented for ath9k and/or mac80211 in general? See above. Please add documentation in the wiki and link it from here.

comment:21 Changed 3 years ago by anonymous


Add Comment

Modify Ticket

as reopened .

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.