Please drop wireless-extension requirement

[yarda]

Fedora is dropping wireless-extensions from the kernel in the Rawhide (f36) and I guess other distros will follow later.
It seems reaver uses wireless-extensions only for the switching of the channels, thus mac80211/cfg80211/libnl could be probably used instead. Downstream Fedora bug:

https://bugzilla.redhat.com/show_bug.cgi?id=2031312

Fedora change for dropping the wireless-extensions:
https://fedoraproject.org/wiki/Changes/RemoveWirelessExtensions

[yarda]

Untested Fedora downstream patch that uses libnl3 for the channel switching instead of the wireless-extensions:
https://bugzilla.redhat.com/show_bug.cgi?id=2031312#c2

The code may require some love and testing.

Another benefit of it is that the bundled wireless-extension code (lwe) could be dropped.

[yarda]

I can PR it if needed.

[soxrok2212]

Feel free to make a PR!

[rofl0r]

the PR should first test whether wext works, and only use the new stuff if wext is not available.

edit: oh, and if the new stuff pulls in additional deps it should be made optional and use a configure option.

[yarda]

I will try to prepare something.

In the Fedora downstream I also unbundled lwe and linked with the system one provided by the distro. It worked OK for years (or at least nobody complained :).

[rofl0r]

removing lwe is out of scope, it will create new problems for users that want to stick with wext (such as myself). the push to use a newer and supposedly better api is just another case of https://sabotage-linux.neocities.org/blog/8/

[soxrok2212]

@rofl0r you have to understand and appreciate that probably 99% of the user base here is using a recent version of Kali/Parrot/Ubuntu/Arch/Fedora. wext is ancient and has done its due diligence.

Also, some of the notes in the link you shared are missing the point of the change, specifically showcases 3 and 4.

As for 3, the ip toolkit is much more practical in the sense of there actually is a lot more control over the interface, like MPTCP controls which is bleeding edge. Yeah, i hate using ip * too and still install net-tools, but it is more powerful in ways and has its place.

And 4 is to prevent interfaces from switching as there is no perfectly defined behavior (last I checked) when a physical adapter gets an interface name. It's meant to provide a consistent way of managing interfaces. I personally see this when i plug in/remove wireless adapters on my system. Which one will be wlan1? ask /dev/random. If it's really that much of an issue, just make a udev rule and call it a day. I do agree the naming convention is a PITA but it needed to be done to stop potentially disastrous things from happening on mission critical systems where the naming convention isn't perfectly defined behavior.

@yarda Let's see what you can come up with :)

[rofl0r]

@rofl0r you have to understand and appreciate that probably 99% of the user base here is using a recent version of Kali/Parrot/Ubuntu/Arch/Fedora.

and nobody of those users so far has seen the need to open an issue because of wext.

wext is ancient and has done its due diligence.

just because something is old doesn't mean its bad. recent kernels still have wext support, and many drivers have features that work only in wext mode. it's just people pushing through a policy (and like always, fedora is first to deprecate useful things and ram through shit like pulseaudio) and disable support for a particular thing.

[nullr0ute]

just because something is old doesn't mean its bad. recent kernels still have wext support, and many drivers have features that work only in wext mode. it's just people pushing through a policy (and like always, fedora is first to deprecate useful things

The only drivers that depend on WEXT in the upstream kernel are IPW 2x00, 2 old 11b/11g PCMCIA cards, an old Atmel 11b, the original Cisco Aironet PCMCIA and Hermes Orinoco 11b PCMCIA/PCI (not PCIe) plus one Zydas ZD1201 USB stick. Of those devices Fedorra only enabled the IPW 2x00.

I would like you to actually list the "features that work only in wext mode" explicitly because in fact there's a lot of features, basically anything newer than 11g, and a lot of the WPA2+ crypto stuff is literally not reported by WEXT because it didn't exist when WEXT stopped being actively developed.

[rofl0r]

I would like you to actually list the "features that work only in wext mode" explicitly

i won't because i don't have time to waste. but be assured last time i tried to implement stuff using the new api for macgeiger and/or wpa-key i found it wouldnt work for one of the dozen of dongles i have. i don't recall which one it was, nor which kernel version it was, nor whether it was channel switching, injection, monitor mode, or active monitor mode.

in fact there's a lot of features, basically anything newer than 11g, and a lot of the WPA2+ crypto stuff is literally not reported by WEXT

right, new stuff that's newer than WPS which we target here, and that is mostly turned off these days.

[soxrok2212]

right, new stuff that's newer than WPS which we target here, and that is mostly turned off these days.

Paves the way for attacking WSC (WiFi Simple Configuration) or whatever that “feature” is called that’s paired with WPA3.

[rofl0r]

Paves the way for attacking WSC (WiFi Simple Configuration) or whatever that “feature” is called that’s paired with WPA3.

until someone figured out how to attack it, we can just as well add a command line switch that calls system("iw set-channel X"); for switching the channel on crippled fedora-next.

[yarda]

Paves the way for attacking WSC (WiFi Simple Configuration) or whatever that “feature” is called that’s paired with WPA3.

until someone figured out how to attack it, we can just as well add a command line switch that calls system("iw set-channel X"); for switching the channel on crippled fedora-next.

This workaround was second on my list :), but at first I tried to port it to the libnl3.