|
|
Subscribe / Log in / New account

Haunted by ancient history

Haunted by ancient history

Posted Jan 8, 2015 22:51 UTC (Thu) by johill (subscriber, #25196)
In reply to: Haunted by ancient history by dlang
Parent article: Haunted by ancient history

Well, no, it only keeps track of the data for wext. There's currently not even a way in the API of nl80211 to transport just such single values.

I don't believe that it's better to mess up the nl80211 APIs with such stateful problems than keeping the old wext support around - at least the latter can easily be disabled and if it is people can determine relatively quickly why things broke (we never ship wext to our customers, for example, and will not support it).

If we added stateful problematic API to nl80211 we'd have the worst of both worlds, because we'd have to support the mess with all the unclear semantics of when to start connecting in the new API. That's really not worth it at all, even if it would allow us to get rid of all the other ugly wext code (and believe me - there's a lot, down to 32/64 userspace compat code that always builds two messages for the same thing because they differ etc.)

Regarding your other question, it is possible for the AP to require that the client be capable of certain bitrates - they're called "basic rates", you might have such a configuration. It's also possible to require HT or even VHT to be supported. I have no idea if typical APs have configuration options in their limited web UI for that though - if you were to run hostapd (say on OpenWRT) it'd be simple to set this in the configuration file.


to post comments

Haunted by ancient history

Posted Jan 8, 2015 23:04 UTC (Thu) by dlang (guest, #313) [Link] (2 responses)

> Regarding your other question, it is possible for the AP to require that the client be capable of certain bitrates - they're called "basic rates", you might have such a configuration. It's also possible to require HT or even VHT to be supported. I have no idea if typical APs have configuration options in their limited web UI for that though - if you were to run hostapd (say on OpenWRT) it'd be simple to set this in the configuration file.

how would I set this with command line tools? (once I know that, I can go figure out how to set this in the distro config). I am using OpenWRT on these routers.

Haunted by ancient history

Posted Jan 9, 2015 13:36 UTC (Fri) by johill (subscriber, #25196) [Link] (1 responses)

You can't set it using command line tools - this is only advertised and enforced by hostapd. You have to set it in the hostapd configuration file (basic_rates= option). To require HT (11n), set require_ht=1, to require VHT (11ac) set require_vht=1.

One OpenWRT, you might be able to inject options, not sure off the top of my head.

Haunted by ancient history

Posted Jan 9, 2015 14:19 UTC (Fri) by cesarb (subscriber, #6266) [Link]

Take a look at http://wiki.openwrt.org/doc/uci/wireless. I'd guess it's the basic_rate and require_mode options.

Haunted by ancient history

Posted Jan 9, 2015 5:40 UTC (Fri) by alankila (guest, #47141) [Link] (1 responses)

One of the issues here is that *someone* has to remember the values set. It's either in user space of kernel space. If the kernel remembers it, then anyone can query the kernel APIs to figure out what the current wireless settings that have been told to hardware are. If it's in user space, I can imagine someone writing another dbus API for wireless connections, and adding a permanent daemon to keep track of the info.

Historical unix style favors the former, so the kernel services user processes by keeping track of important state for them, because the processes themselves are short-lived and can't do it. Modern unix style is about running everything imaginable in separate daemons. Anyway, someone can just go ahead and define the dbus API for wpa_supplicant or something, and then tell everyone to implement that.

Haunted by ancient history

Posted Jan 9, 2015 13:38 UTC (Fri) by johill (subscriber, #25196) [Link]

All of that already exists. If you're running wpa_supplicant, you can never have any of these problems [even with wext, since wpa_supplicant is smarter than the average user]

However, if you're not running wpa_supplicant, then it really only leaves the kernel to remember it, or the user to re-enter it every time. iwconfig/wext went with the former (and in turn got all the associated problems), iw/nl80211 went with the latter to avoid those problems.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds