https://fedoraproject.org/wiki/Changes/RemoveWirelessExtensions
== Summary == The legacy wireless extensions interface was replaced by the new mac80211/cfg80211 interface in 2007. The legacy Wireless Extensions support has been long deprecated and only supports long EOL WiFi encryption like WEP so it's time to disable it and remove it.
== Owner == * Name: [[User:pbrobinson| Peter Robinson]] * Email: [mailto:pbrobinson@fedoraproject.org| pbrobinson@fedoraproject.org]
== Detailed Description ==
The Wireless Extensions support in the kernel has been long replaced by the mac80211/cfg80211 support. Disable the kernel options and retire the wireless-tools userspace utilities. Wireless Extensions only supports a minor subset of the wireless interfaces, predominently the WEP interface and userspace has been replaced by iw/libnl/ip interfaces which offer a lot more advanced features as well as modern 802.11 functionality like WPA.
== Benefit to Fedora ==
More secure and advanced features in wireless. In most cases most users won't notice a difference. The vast majority of users use NetworkManager to use 802.11 based wireless interfaces which has long ceased to support wireless extensions/wireless-tools, if it evere did.
== Scope == * Proposal owners: ** Disable the wireless extensions interface in the kernel and any drivers that depend on it. The only driver that is currently enabled that requires wireless extension support is the Intel Pro Wireless 2100/2200 drivers, this hardware was released in 2003-2005 as part of the original Centrino laptop platforms and all officially supported devices were 32 bit so it's unlikely there's any current users but as they were mPCI cards it's possible there's a few users that put them into 64 bit machines. ** Retire the wireless-tools package, retirn any packages that depend on it, or migrate them to use libnl3.
* Other developers: ** No impact
* Release engineering: [https://pagure.io/releng/issue/10386 #10386] * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact == A handful of packages still use the libiw interface and hence depend on the wireless-tools package. Some projects look dead upstream, a number have already been migrated in the last year or so. Where the project is alive upstream tickets have been filed requesting migration. The current remaining package list is:
* conky * lxpanel * reaver
== How To Test ==
* Check that the wireless extensions kernel options are disabled: (CONFIG_WEXT_CORE CONFIG_WEXT_PROC CONFIG_WEXT_SPY CONFIG_WEXT_PRIV CONFIG_CFG80211_WEXT CONFIG_CFG80211_WEXT_EXPORT) * Check the wireless-tools package is no longer available
== User Experience ==
Generally users should notice little to no difference.
== Dependencies == N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: Leave WEXT enabled in the kernel, leave wireless-tools package in Fedora package repository. * Contingency deadline: GA * Blocks release? No. * Blocks product? No.
== Documentation == N/A (not a System Wide Change)
== Release Notes == N/A
== Owner ==
- Name: [[User:pbrobinson| Peter Robinson]]
https://fedoraproject.org/wiki/Changes/RemoveWirelessExtensions
== Summary == The legacy wireless extensions interface was replaced by the new mac80211/cfg80211 interface in 2007. The legacy Wireless Extensions support has been long deprecated and only supports long EOL WiFi encryption like WEP so it's time to disable it and remove it.
I do not believe that the assertion around encryption is true, unless wpa_supplicant has dropped support for the legacy interface over the years. I remember having used some legacy wext drivers with wpa_supplicant and WPA (maybe even WPA2) before everything was ported to mac80211 (the "DeviceScape stack" as it was called at the time). And https://w1.fi/wpa_supplicant/ lists not only "Linux drivers that support nl80211/cfg80211 (most new drivers)", but also "Linux drivers that support Linux Wireless Extensions v19 or newer with WPA/WPA2 extensions" as supported.
(For the record, I also remember my old Pentium II "notebook" (more like a thick laptop) taking a day or two to build a custom kernel with the DeviceScape/mac80211 stack that was not easily buildable out of tree, in order to build and use the Free-as-in-speech driver for a Broadcom PCMCIA WiFi card, but that is off topic. ;-) )
There were also some drivers implementing WPA on their own, or letting the hardware or firmware do it, in particular, Ralink's GPLed vendor driver. Of course, those nonstandard wext commands were not supported by NetworkManager, so I had to use a custom shell script. The driver was eventually replaced by the rt2x00 community rewrite that relies on wpa_supplicant and that was soon ported to mac80211. But I am pretty sure I also used a wext version of rt2x00 with wpa_supplicant at some point.
The Wireless Extensions support in the kernel has been long replaced by the mac80211/cfg80211 support. Disable the kernel options and retire the wireless-tools userspace utilities. Wireless Extensions only supports a minor subset of the wireless interfaces, predominently the WEP interface and userspace has been replaced by iw/libnl/ip interfaces which offer a lot more advanced features as well as modern 802.11 functionality like WPA.
Users are going to miss the iwconfig tool. Not only is it still being used out of habit (just like ifconfig from net-tools), but (also just like ifconfig) it is also much more user-friendly. E.g., running "iwconfig" without arguments prints a nice summary of the wireless devices and their properties, such as access point ESSID and BSSID, bit rate, signal level, etc., whereas running "iw" without arguments prints a 132-line help output with around a hundred different commands (with no explanation as to what they do, as that would require even more than 132 lines: the --help output is 445 lines long). "iw" also exposes implementation details in the most unfriendly way, by requiring the user to use "dev <devname>", "phy <phyname>", "wdev <idx>", or "reg" prefixes depending on the individual command (and it is entirely unclear to the user why something is a dev property, a phy property, or both), whereas "iwconfig" takes the same interface name for all commands.
The new ip, iw, and route tools have clearly been designed by kernel developers for kernel developers, not for end users or even system administrators. The old ifconfig and iwconfig are much easier to use.
Kevin Kofler
On Wed, 17 Nov 2021 at 03:59, Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
The Wireless Extensions support in the kernel has been long replaced by the mac80211/cfg80211 support. Disable the kernel options and retire the wireless-tools userspace utilities. Wireless Extensions only supports a minor subset of the wireless interfaces, predominently the WEP interface and userspace has been replaced by iw/libnl/ip interfaces which offer a lot more advanced features as well as modern 802.11 functionality like WPA.
Users are going to miss the iwconfig tool. Not only is it still being used out of habit (just like ifconfig from net-tools), but (also just like ifconfig) it is also much more user-friendly. E.g., running "iwconfig" without arguments prints a nice summary of the wireless devices and their properties, such as access point ESSID and BSSID, bit rate, signal level, etc., whereas running "iw" without arguments prints a 132-line help output with around a hundred different commands (with no explanation as to what they do, as that would require even more than 132 lines: the --help output is 445 lines long). "iw" also exposes implementation details in the most unfriendly way, by requiring the user to use "dev <devname>", "phy <phyname>", "wdev <idx>", or "reg" prefixes depending on the individual command (and it is entirely unclear to the user why something is a dev property, a phy property, or both), whereas "iwconfig" takes the same interface name for all commands.
The new ip, iw, and route tools have clearly been designed by kernel developers for kernel developers, not for end users or even system administrators. The old ifconfig and iwconfig are much easier to use.
Cannot agree more.
On Wednesday, 17 November 2021 at 10:38, Iñaki Ucar wrote:
On Wed, 17 Nov 2021 at 03:59, Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
The Wireless Extensions support in the kernel has been long replaced by the mac80211/cfg80211 support. Disable the kernel options and retire the wireless-tools userspace utilities. Wireless Extensions only supports a minor subset of the wireless interfaces, predominently the WEP interface and userspace has been replaced by iw/libnl/ip interfaces which offer a lot more advanced features as well as modern 802.11 functionality like WPA.
Users are going to miss the iwconfig tool. Not only is it still being used out of habit (just like ifconfig from net-tools), but (also just like ifconfig) it is also much more user-friendly. E.g., running "iwconfig" without arguments prints a nice summary of the wireless devices and their properties, such as access point ESSID and BSSID, bit rate, signal level, etc., whereas running "iw" without arguments prints a 132-line help output with around a hundred different commands (with no explanation as to what they do, as that would require even more than 132 lines: the --help output is 445 lines long). "iw" also exposes implementation details in the most unfriendly way, by requiring the user to use "dev <devname>", "phy <phyname>", "wdev <idx>", or "reg" prefixes depending on the individual command (and it is entirely unclear to the user why something is a dev property, a phy property, or both), whereas "iwconfig" takes the same interface name for all commands.
The new ip, iw, and route tools have clearly been designed by kernel developers for kernel developers, not for end users or even system administrators. The old ifconfig and iwconfig are much easier to use.
Cannot agree more.
I'm not sure what you're trying to accomplish by complaining here or 'me too'-ing. Deprecated and unused subsystems should get removed. If you don't like the way the current userland tools behave, open RFE's with their respective upstreams instead of adding noise here.
Regards, Dominik
On Wed, 17 Nov 2021 at 10:54, Dominik 'Rathann' Mierzejewski dominik@greysector.net wrote:
On Wednesday, 17 November 2021 at 10:38, Iñaki Ucar wrote:
On Wed, 17 Nov 2021 at 03:59, Kevin Kofler via devel devel@lists.fedoraproject.org wrote:
The Wireless Extensions support in the kernel has been long replaced by the mac80211/cfg80211 support. Disable the kernel options and retire the wireless-tools userspace utilities. Wireless Extensions only supports a minor subset of the wireless interfaces, predominently the WEP interface and userspace has been replaced by iw/libnl/ip interfaces which offer a lot more advanced features as well as modern 802.11 functionality like WPA.
Users are going to miss the iwconfig tool. Not only is it still being used out of habit (just like ifconfig from net-tools), but (also just like ifconfig) it is also much more user-friendly. E.g., running "iwconfig" without arguments prints a nice summary of the wireless devices and their properties, such as access point ESSID and BSSID, bit rate, signal level, etc., whereas running "iw" without arguments prints a 132-line help output with around a hundred different commands (with no explanation as to what they do, as that would require even more than 132 lines: the --help output is 445 lines long). "iw" also exposes implementation details in the most unfriendly way, by requiring the user to use "dev <devname>", "phy <phyname>", "wdev <idx>", or "reg" prefixes depending on the individual command (and it is entirely unclear to the user why something is a dev property, a phy property, or both), whereas "iwconfig" takes the same interface name for all commands.
The new ip, iw, and route tools have clearly been designed by kernel developers for kernel developers, not for end users or even system administrators. The old ifconfig and iwconfig are much easier to use.
Cannot agree more.
I'm not sure what you're trying to accomplish by complaining here or 'me too'-ing. Deprecated and unused subsystems should get removed. If you don't like the way the current userland tools behave, open RFE's with their respective upstreams instead of adding noise here.
I didn't complain. I'm not opposing, yet I'm acknowledging that it is not true that iwconfig is unused. It is very much used, if not just for printing the nice summary that the tool provides when called without arguments.
On Wed, Nov 17, 2021 at 11:30:40AM +0100, Iñaki Ucar wrote:
I didn't complain. I'm not opposing, yet I'm acknowledging that it is not true that iwconfig is unused. It is very much used, if not just for printing the nice summary that the tool provides when called without arguments.
IIRC there are still a few WEXT-only drivers for obsolete wifi hardware in the Linux kernel. I don't know if Fedora builds them or not, but drop iwconfig and that hardware becomes unusable under Fedora. (prism2_usb comes to mind)
Meanwhile, the default summary output of 'iwconfig' is all I have used it for in many, many years. It is _very_ useful in a way that no other tool has been. (not unlike the default output of ifconfig _still_ being more generally useful than 'ip')
I'm sure all of the info that iwconfig provides can be extracted from iw, but it's a lot less convenient. (Plus some of us have muscle memory going back to when iwconfig was the new hotness...)
- Solomon
On Wed, Nov 17, 2021 at 12:06 PM Solomon Peachy pizza@shaftnet.org wrote:
On Wed, Nov 17, 2021 at 11:30:40AM +0100, Iñaki Ucar wrote:
I didn't complain. I'm not opposing, yet I'm acknowledging that it is not true that iwconfig is unused. It is very much used, if not just for printing the nice summary that the tool provides when called without arguments.
IIRC there are still a few WEXT-only drivers for obsolete wifi hardware in the Linux kernel. I don't know if Fedora builds them or not, but drop iwconfig and that hardware becomes unusable under Fedora. (prism2_usb comes to mind)
There's one driver that depends on it and that was only ever shipped on i686 hardware which we obviously don't support any longer. The prism2_usb is in staging on it's way out of the kernel and hasn't been built in Fedora for years.
Meanwhile, the default summary output of 'iwconfig' is all I have used it for in many, many years. It is _very_ useful in a way that no other tool has been. (not unlike the default output of ifconfig _still_ being more generally useful than 'ip')
I'm sure all of the info that iwconfig provides can be extracted from iw, but it's a lot less convenient. (Plus some of us have muscle memory going back to when iwconfig was the new hotness...)
It also doesn't provide huge amounts of useful information for modern HW like anything after 11a/11g like no support for 11n/ac/ax HW and it doesn't report a lot of the newer available frequencies like newer added 5Ghz bands so while it does provide some slightly useful information if you actually look closely a lot of it is actually incorrect.
On Wed, Nov 17, 2021 at 03:49:55AM +0100, Kevin Kofler via devel wrote:
Users are going to miss the iwconfig tool. Not only is it still being used out of habit (just like ifconfig from net-tools), but (also just like ifconfig) it is also much more user-friendly. E.g., running "iwconfig" without arguments prints a nice summary of the wireless devices and their properties, such as access point ESSID and BSSID, bit rate, signal level, etc., whereas running "iw" without arguments prints a 132-line help output with around a hundred different commands (with no explanation as to what they do, as that would require even more than 132 lines: the --help output is 445 lines long). "iw" also exposes implementation details in the most unfriendly way, by requiring the user to use "dev <devname>", "phy <phyname>", "wdev <idx>", or "reg" prefixes depending on the individual command (and it is entirely unclear to the user why something is a dev property, a phy property, or both), whereas "iwconfig" takes the same interface name for all commands.
The new ip, iw, and route tools have clearly been designed by kernel developers for kernel developers, not for end users or even system administrators. The old ifconfig and iwconfig are much easier to use.
The same applies for nft and ss ;) Those tools are supposed to be the future, but using them feels as if the people who wrote them never used them.
Dunno, maybe we can keep wireless-tools package? Is it a burden to keep in the distro?
Zbyszek
Zbigniew Jędrzejewski-Szmek wrote:
Dunno, maybe we can keep wireless-tools package? Is it a burden to keep in the distro?
I guess the issue is that the tool(s) will no longer work if the subsystem is completely removed from the kernel.
Would it be possible to ship the kernel with only wext interface compatibility (for wireless-tools) in mac80211 enabled and with wext itself disabled? Or does the interface compatibility in this case require shipping the entire wext subsystem?
Kevin Kofler
On Wed, Nov 17, 2021 at 11:51 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Wed, Nov 17, 2021 at 03:49:55AM +0100, Kevin Kofler via devel wrote:
Users are going to miss the iwconfig tool. Not only is it still being used out of habit (just like ifconfig from net-tools), but (also just like ifconfig) it is also much more user-friendly. E.g., running "iwconfig" without arguments prints a nice summary of the wireless devices and their properties, such as access point ESSID and BSSID, bit rate, signal level, etc., whereas running "iw" without arguments prints a 132-line help output with around a hundred different commands (with no explanation as to what they do, as that would require even more than 132 lines: the --help output is 445 lines long). "iw" also exposes implementation details in the most unfriendly way, by requiring the user to use "dev <devname>", "phy <phyname>", "wdev <idx>", or "reg" prefixes depending on the individual command (and it is entirely unclear to the user why something is a dev property, a phy property, or both), whereas "iwconfig" takes the same interface name for all commands.
The new ip, iw, and route tools have clearly been designed by kernel developers for kernel developers, not for end users or even system administrators. The old ifconfig and iwconfig are much easier to use.
The same applies for nft and ss ;) Those tools are supposed to be the future, but using them feels as if the people who wrote them never used them.
Dunno, maybe we can keep wireless-tools package? Is it a burden to keep in the distro?
The problems is it doesn't provide huge amounts of useful information for modern HW like anything after 11a/11g like no support for 11n/ac/ax HW and it doesn't report a lot of the newer available frequencies like newer added 5Ghz bands so while it does provide some slightly useful information if you actually look closely a lot of it is actually incorrect.
For example it reports I don't have encryption on my 11ac WiFi which is connected to a WPA3 AP likely because it doesn't understand it. Is the nicely formatted information useful if it's actively wrong? It would probably more useful to alias iwconfig to "iw dev" as that information is close to what iwconfig provides but is actually accurate on vaguely modern hardware.
On Wed, 17 Nov 2021 at 16:19, Peter Robinson pbrobinson@gmail.com wrote:
On Wed, Nov 17, 2021 at 11:51 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Wed, Nov 17, 2021 at 03:49:55AM +0100, Kevin Kofler via devel wrote:
Users are going to miss the iwconfig tool. Not only is it still being used out of habit (just like ifconfig from net-tools), but (also just like ifconfig) it is also much more user-friendly. E.g., running "iwconfig" without arguments prints a nice summary of the wireless devices and their properties, such as access point ESSID and BSSID, bit rate, signal level, etc., whereas running "iw" without arguments prints a 132-line help output with around a hundred different commands (with no explanation as to what they do, as that would require even more than 132 lines: the --help output is 445 lines long). "iw" also exposes implementation details in the most unfriendly way, by requiring the user to use "dev <devname>", "phy <phyname>", "wdev <idx>", or "reg" prefixes depending on the individual command (and it is entirely unclear to the user why something is a dev property, a phy property, or both), whereas "iwconfig" takes the same interface name for all commands.
The new ip, iw, and route tools have clearly been designed by kernel developers for kernel developers, not for end users or even system administrators. The old ifconfig and iwconfig are much easier to use.
The same applies for nft and ss ;) Those tools are supposed to be the future, but using them feels as if the people who wrote them never used them.
Dunno, maybe we can keep wireless-tools package? Is it a burden to keep in the distro?
The problems is it doesn't provide huge amounts of useful information for modern HW like anything after 11a/11g like no support for 11n/ac/ax HW and it doesn't report a lot of the newer available frequencies like newer added 5Ghz bands so while it does provide some slightly useful information if you actually look closely a lot of it is actually incorrect.
For example it reports I don't have encryption on my 11ac WiFi which is connected to a WPA3 AP likely because it doesn't understand it. Is the nicely formatted information useful if it's actively wrong? It would probably more useful to alias iwconfig to "iw dev" as that information is close to what iwconfig provides but is actually accurate on vaguely modern hardware.
"iw dev" reports SSID, channel number and a lot of other useless information, such as center and width of the channel (iwconfig reports current bitrate, link quality and signal level, which are far more useful), MAC (iwconfig reports the APs MAC instead) or multicast statistics that are all equal to 0. I don't see what piece of output from iwconfig is not accurate, at least with my hardware (11ac).
On Wed, Nov 17, 2021 at 3:58 PM Iñaki Ucar iucar@fedoraproject.org wrote:
On Wed, 17 Nov 2021 at 16:19, Peter Robinson pbrobinson@gmail.com wrote:
On Wed, Nov 17, 2021 at 11:51 AM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Wed, Nov 17, 2021 at 03:49:55AM +0100, Kevin Kofler via devel wrote:
Users are going to miss the iwconfig tool. Not only is it still being used out of habit (just like ifconfig from net-tools), but (also just like ifconfig) it is also much more user-friendly. E.g., running "iwconfig" without arguments prints a nice summary of the wireless devices and their properties, such as access point ESSID and BSSID, bit rate, signal level, etc., whereas running "iw" without arguments prints a 132-line help output with around a hundred different commands (with no explanation as to what they do, as that would require even more than 132 lines: the --help output is 445 lines long). "iw" also exposes implementation details in the most unfriendly way, by requiring the user to use "dev <devname>", "phy <phyname>", "wdev <idx>", or "reg" prefixes depending on the individual command (and it is entirely unclear to the user why something is a dev property, a phy property, or both), whereas "iwconfig" takes the same interface name for all commands.
The new ip, iw, and route tools have clearly been designed by kernel developers for kernel developers, not for end users or even system administrators. The old ifconfig and iwconfig are much easier to use.
The same applies for nft and ss ;) Those tools are supposed to be the future, but using them feels as if the people who wrote them never used them.
Dunno, maybe we can keep wireless-tools package? Is it a burden to keep in the distro?
The problems is it doesn't provide huge amounts of useful information for modern HW like anything after 11a/11g like no support for 11n/ac/ax HW and it doesn't report a lot of the newer available frequencies like newer added 5Ghz bands so while it does provide some slightly useful information if you actually look closely a lot of it is actually incorrect.
For example it reports I don't have encryption on my 11ac WiFi which is connected to a WPA3 AP likely because it doesn't understand it. Is the nicely formatted information useful if it's actively wrong? It would probably more useful to alias iwconfig to "iw dev" as that information is close to what iwconfig provides but is actually accurate on vaguely modern hardware.
"iw dev" reports SSID, channel number and a lot of other useless information, such as center and width of the channel (iwconfig reports current bitrate, link quality and signal level, which are far more useful), MAC (iwconfig reports the APs MAC instead) or multicast statistics that are all equal to 0. I don't see what piece of output from iwconfig is not accurate, at least with my hardware (11ac).
It doesn't report encryption, it doesn't report any of the 5ghz channels that weren't in the origianl 11a spec just to name a few.
I stumbled on this while fixing up an old script that relied on iwconfig
I added this to my .bashrc ``` function iwconfig { iw dev $1 link ; iw dev $1 info | grep -E 'channel|txpower|addr' ; } ```
and then you get something fairly useful ``` $ iwconfig wlp2s0f0 Connected to aa:aa:aa:aa:aa:aa (on wlp2s0f0) SSID: MYESSID freq: 5680.0 RX: 80578793 bytes (78400 packets) TX: 11770367 bytes (33802 packets) signal: -38 dBm rx bitrate: 573.5 MBit/s 40MHz HE-MCS 11 HE-NSS 2 HE-GI 0 HE-DCM 0 tx bitrate: 516.0 MBit/s 40MHz HE-MCS 10 HE-NSS 2 HE-GI 0 HE-DCM 0 bss flags: short-slot-time dtim period: 1 beacon int: 100 addr c2:d8:04:d4:de:0b channel 136 (5680 MHz), width: 40 MHz, center1: 5670 MHz txpower 22.00 dBm ```
I also have this in my bashrc to show everything ``` function ifwconfig { iw dev $1 link ; iw dev $1 info | grep -E 'channel|txpower|addr' ; ip addr show dev $1 ; } ```
-
Ben Cotton -
Dominik 'Rathann' Mierzejewski -
Iñaki Ucar -
Kevin Kofler -
Paul M -
Peter Robinson -
Solomon Peachy -
Zbigniew Jędrzejewski-Szmek