morrownr
VIF not working on kernels >= 6.2 (affects all chipsets, need help)
There is an issue with the VIF feature of Wi-Fi adapters. This has been confirmed by many members of the Wi-Fi hacking community. The problem is that DoS attacks do not work when the card is using VIF. This is happening from kernel version 6.2 or higher. The problem is not happening on kernel 6.1 or lower.
How to test this?
The way I test it is by launching an evil twin attack with my tool, airgeddon. At the moment the physical Wi-Fi adapter splits into two logical interfaces — creating the AP while simultaneously performing DoS in monitor mode — if I can see the AP with another device and at the same time my phone (which I use as the victim) is successfully deauthenticated from the network, then VIF is working. At least, that's how I do it. Probably there are other ways easier to test it, but this is what I do.
Additionally, it has been verified that the bug is not only present with the Alfa AWUS036AXML. At first, I thought it only affected MediaTek chipsets, but later we realized that it affects all chipsets. I have personally confirmed the issue with Atheros and Ralink as well. On kernel 6.2 or higher, the problem occurs and deauthentication does not work (but only when using VIF — normal DoS in monitor mode works fine). On kernel 6.1, the error does not occur and everything works correctly. This has been tested on multiple Linux distributions such as Debian, Kali Linux, Wifislax, Parrot Security, Ubuntu, and others.
The bug is documented in kernel bug tracker: https://bugzilla.kernel.org/show_bug.cgi?id=218763
@morrownr if anyone is able to help on this, that could be a very good thing for the Wi-Fi hacking community. Thanks.
@OscarAkaElvis
Thanks you for posting this issue here per our previous conversation. There are a lot of very knowledgeable users and devs that stop by this site. I suspect that we can successfully work this issue but I need you to confirm, so that everyone can see it, that this is a White Hat effort. The work involved is for the benefit of those involved security analysis so as to prevent unwanted intrusion by those seeking to do harm.
For my part, I am going to have to become familiar with airgeddon. This may take some time as I have other projects going. What I do know is that there are users having success with VIF so it is possible that the problem may be very specific.
All,
Everyone is welcome to join in.
@OscarAkaElvis, thank you for looking into this issue. In the Linux Kernel Bugzilla, Thorsten already asked you to do a bisection. That is really the fastest way to find the culprit and get the developers to fix it. I commented now with the steps from the documentation. Everyone is swamped, so bisection from you is really the quickest way forward.
@OscarAkaElvis
I agree with @paulmenzel . A bisection that finds the specific patch that caused the problem will also give us the name of the dev that submitted the patch and the name of the person that approved it.
Recently a user posted a bug report here. It was not a bug that I had the capability to reproduce so I told him I would keep an eye open. The very next day another user reported basically the same thing. We talked and the original poster agreed to do a bisection. About 3 days later he checked back in with bisection complete. We wrote up the bug report and I mailed it linux-wireless, the author of the bad patch and the person that approved it. Within 24 hours we had a patch to test. It tested good and within an additional 24 hours, the fix was headed into the kernel and was set to backport.
Bugzilla is just not where the wireless devs hang out looking for things to do. They are busy. However, if you know the patch that caused the problem and the information goes to the right places, it is amazing how fast things can be fixed.
Here is a link:
https://docs.kernel.org/admin-guide/bug-bisect.html
You have a head start. You know 6.1 was good and 6.2 is bad. Now to find out which of the patches that went into 6.2 is the problem. You find the bad patch and I'll send the report.
I'm sorry, but it sounds like the kind of assignment that just isn't for me. I've never compiled a kernel before, and it sounds like a very time-consuming task, I just don't have that kind of time available in my life right now. Home, work, kids... I could give a thousand excuses, and they’d all be true. But beyond that, I've already lost all hope after seeing how things unfolded in the Linux bugtracker thread. Someone did a bisection and found something, and no one has paid any attention. I opened this thread because @morrownr suggested it to me in another discussion, hoping that somebody could take care about it.
The truth is, I think this is something the developers should handle. As users, we can run tests and report bugs, but the mistakes were made by the developers, and they’re the ones who know the code best—they should take responsibility. I’m well aware that all of this is done out of passion, but when I make a mistake in my own open source project and someone reports it, I don’t ask them to dig through my code to tell me what I did wrong. I investigate it, fix it, and thank the user for spotting the issue. But anyway, that’s just my personal opinion, which I’m sure will be controversial.
Actually, bisecting the Linux kernel is quite easy and not really time consuming if you have a reproducer, as you can do something else, when it’s building. (Probably less time than writing your comments.) Also, as you pointed out in the Linux kernel bug tracker, the bisected commit looked dubious as it only affected one vendor. Lastly, the Linux bug tracker is apparently not used by the linux-wireless folks.
But I wanted to make another point: Where do you get the expectation that things should work at all? Do you run a commercial Linux system and pay something for support? If not, please manage your expectations. Yes, one could expect the hardware vendors to write and maintain good drivers for all operating systems (or publish complete documentation), but I think they do not officially support Linux. If they do for your device, then, yes, you might expect that they fix it.
If you do pay for support, please ignore my comment.
Sorry for getting off-topic, but such comments with demands and expectations for something that over 95(?) % do not pay anything for really set me off.
But, if you sent me an affected device, I’d be willing to do the bisection for you (for free).
I understand your point. But remember that this is not for me, is for the whole community. I consider I did my part detecting the version failing and the way of testing it. I hope other community members could take care of other parts of the problem. If not, I can live with it. Believe me, for me to compile a kernel is not a trivial thing. I need to read a lot of documentation, understand what I'm doing and how to do it. It would take for sure much more thatn writting these (and other 20 comments at least). I know that my opinion is not aligned with other people's opinion. I can also live with it.
But, if you sent me an affected device, I’d be willing to do the bisection for you (for free).
Really? I have no problem in sending you a 3€ device bought in aliexpress for testing. If you are really interested, tell me in private and we can set it up. (my email is in my profile).
@OscarAkaElvis
Really?
Yes, he means it. However, let's take the time to discuss before anything is mailed.
As a result of the mission of my little github site, I have a lot of usb wifi adapters. I can easily part with one that should work if need be. To do this in a cost effective manner, let's see what country that @paulmenzel lives in as long distance international shipping can cost more than the device and with current geopolitical issues at play, we need to consider the best way to do this.
What I have learned over many years of using Linux is not to get locked into any specific mindset about how things should work. One step at a time and we can get there.
@paulmenzel
Do you have any usb wifi adapters? If I am understanding correcting, it is an issue for all adapters and cards and not just a specific adapter or card. If that is the case, any adapter that you have that uses an in-kernel drivers should work. The thing that is on my agenda to help with this project is for me to learn the app and see exactly what the issue is. I think further discussion is in order before we dive right into a solution and your offer to do the bisection is really kind and welcome.
I suggest sending money and he can buy his own device. Easier than shipping to another country. I've bought someone an adapter before.
@OscarAkaElvis
I am over at your github repo for airgeddon right now. Nice sight. For me to gain additional insight into the VIF problem, I think I need to become familiar with airgeddon. It appears that you are using Parrot as your distro. Is that correct? I ask because I may install it to a partition on a test system. What version of Parrot are you using?
@bjlockie
Good advice. Oh, and while I am writing to you, let me take the time to apologize for the behavior of the president of my country. You may not know this but my primary academic area of study is economics. Undergrad and grad degrees in econ. There is nothing coming out of his mouth that makes any sense from an economic point of view and his behavior toward Canada is uncalled for. Anyway, back to the real topic.
@OscarAkaElvis
I am attempting to do some initial testing with airgeddon. When I attempt to install dhcpd, Debian 12 is installing udhcpd and your script is not recognizing this as meeting the need. Suggestion?
@morrownr , let me explain it to you.
Regarding hardware, the bug is affecting to all chipsets, but you need a VIF compatible one. So you can check the whitelist of the adapters that are well known to be working 100% with airgeddon and that are VIF-capable: https://github.com/v1s1t0r1sh3r3/airgeddon/wiki/Cards%20and%20Chipsets
As you can see on that list, there are a lot of them. You can find there Amazon/Aliexpress links to buy any. Some of them are very cheap.
If you already have a wifi usb adapter, you can check if is VIF compatible following these instructions: https://github.com/v1s1t0r1sh3r3/airgeddon/wiki/FAQ%20&%20Troubleshooting#what-is-vif
As it is explained there, with this command you can see very quickly if the adapter is VIF-capable: sudo iw list | grep "Supported interface modes" -A 8. As explained in that link, you should see AP/VLAN to be sure that your adapter is VIF capable. As soon as you have one showing it, then you are ready to start testing.
Regarding software, any Linux distribution with the dependencies installed should work. Anyway, the easiest thing is to use a pentesting one because they usually have all (or almost all) the dependencies in place by default. Yeah, I use Parrot Linux, but you can also use Kali or any other. If you use a standard (non-pentesting) Linux distro such as Debian or Ubuntu, you can make it to work but you'll find some difficulties to install some of the dependencies.
Regarding DHCP stuff used by airgeddon, the command needed is "dhcpd" but that is not the package name you need to install. For Debian based distros, it is "isc-dhcp-server". This is what is shown when the dependency is missing:
The package name to install may vary depending on the Linux distribution, but as I said, for Debian is "isc-dhcp-server".
To reproduce the problem is enough to launch any Evil Twin attack ("7. Evil Twin attacks menu"). You can choose your own WPA/WPA2 (not WPA3) home network as a target of course. The simplest one for testing is the "5. Evil Twin attack just AP". That attack is composed of some windows once launched. The fake AP one which is one of the important ones as it is creating the AP that we need to check that is visible, up and running. You should see there "AP-ENABLED". The dhcp stuff which is to provide an IP address to the victims that connect to the fake AP. The DoS window (the lower-left window in red) which is another of the important ones as it is in charge of do deauth over the legit clients of the target network. And the control window which is just informative about what is happening (time, bssid, etc). In this attack, nothing else is launched. No sniffing , and no other things as it leaves up to the user to do whatever they want (use wireshark or whatever) as this is just providing the infrastructure of an evil twin attack to do whatever you want. The other evil twin attacks are similar but they are going to open more windows to do sniffing stuff, but for testing, this is enough.
What you need to see in order to know if everything is working or if is failing due to the kernel bug? two things, the fake AP window should show "AP-ENABLED" and at the same time, the deauthentication should work. Don't pay attention to what is shown in the DoS red window as what matters is if the client is deauthed or not. For example, you need to create a scenario where everything in place is working and set it as a baseline. Let's suppose, kernel 6.1, attacking your own network and an Android mobile device as a victim to check if it is deauthed or not. When you are prompted to select the appropriate DoS attack, you must know that Android devices are deauthed successfully and easily using the aireplay DoS. For some reason, that attack is deauthing all of them instantly. Other possible connected devices could be not affected, as every client has an attack that is affecting to it. So you just need to do testing to find what is working for you. If you see that the client is deauthed and at the same time from it, you can select and connect manually to the fake network, then you can say that is working. After having that baseline set, you can reproduce the problem easily doing the same attack in the same scenario and variables using another >=6.2 kernel and you'll see that the AP is shown but the client is not deauthed.
Hope it helps. Let me know if you have any doubt. Thanks everybody for the collaboration 😸
but you need a VIF compatible one.
I am not aware of any drivers/chips that use in-kernel drivers that do not support VIF.
So you can check the whitelist of the adapters that are well known to be working 100% with airgeddon and that are VIF-capable:
I have already looked. I can probably help you add to the that list. I have a lot of USB WiFi adapters.
with this command you can see very quickly if the adapter is VIF-capable: sudo iw list | grep "Supported interface modes" -A 8. As explained in that link, you should see AP/VLAN to be sure that your adapter is VIF capable. As soon as you have one showing it, then you are ready to start testing.
I am aware of this. I have been helping Linux users with USB WiFi adapters for many years.
Anyway, the easiest thing is to use a pentesting one because they usually have all (or almost all) the dependencies in place by default.
I used to keep a test partition with Kali on it but it finally pissed me off a couple years ago. Unstable piece of shit.Maybe Parrot is better. For now I'll stick with Debian, Ubuntu, RasPiOS or one of the others that I use and test with. I understand and appreciate what you are saying.
For Debian based distros, it is "isc-dhcp-server".
Thanks. It is installed.
I will read and continue testing as I am able.
So testing with the Wi-Fi device included in a laptop, that supports VIF, is not sufficient. I need a second one, correct?
If I choose, number 7, which of the three options should I pick afterward?
Hi @paulmenzel, I'm going to assume you are talking about airgeddon options and I'll also assume you have airgeddon v11.41 which is the latest on master branch. Well, after selecting number 7 (Evil Twin menu), as I explained before, any evil twin attack can be used for the Proof of Concept. So you can select option 5 "5. Evil Twin attack just AP".
You don't need an additional interface. You only need it if you are going to do "DoS pursuit mode" but you don't need something like that for testing. Just one interface and a simple attack is fine.
That attack is composed of some windows once launched. The fake AP one which is one of the important ones as it is creating the AP that we need to check that is visible, up and running. You should see there "AP-ENABLED". The dhcp stuff which is to provide an IP address to the victims that connect to the fake AP. The DoS window (the lower-left window in red) which is another of the important ones as it is in charge of do deauth over the legit clients of the target network. And the control window which is just informative about what is happening (time, bssid, etc). In this attack, nothing else is launched.
So you can see if the fake AP is shown and if your victim device receiving the DoS is disconnected from the real AP. If it works, then we are good (it's working).
@OscarAkaElvis
Short note to let you know that you have not heard from me mostly due to illness but also because of major storms in my area that have caused damage. It could be some time before I work on this issue but I have not forgot it.
Haha ok. Don't worry. Take your time. Life is complicated sometimes, I know It very well. 😺
Ok regarding this bug, I can say that I'm in contact with Johannes Berg (one of the kernel developers) who is doing an amazing work trying to fix this. At last somebody is getting into it.
For now, he was able to fix it for the chipsets that are not using chanctx drivers. He is passing me some patches and I'm compiling the kernel applying those patches and doing tests using different chipsets. For Ralink and Atheros chipsets that are not using chanctx and are using emulation, the patch worked and the injection seems to be working again while using VIF... so amazing news! 🚀
On the other hand, for Mediatek chipsets (those using m76), the fix seems to be more complicated as that driver was migrated time ago to use chanctx and it seems that is a different story...
But at least the first patch to have it working again in almost all chipsets but Mediatek seems to be incoming soon. I'll keep you posted.
@morrownr , if you are curious, this is the link of the patch that works for all the chipsets that are using emulation: https://lore.kernel.org/linux-wireless/[email protected]/
As you can see is a pretty simple patch... hard to find, "easy" to solve 😸
The Mediatek thing... is a different story with that chanctx stuff... actually the first commit causing the issue was found time ago in this bug tracker: https://bugzilla.kernel.org/show_bug.cgi?id=218763 , the commit was this: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers?id=41ac53c899bd1493a75ab9b52c8f76176b7419e1
And the title of the commit says it clearly: "introduce chanctx support". So it never worked with the new chanctx stuff.
@OscarAkaElvis
I am very interested in this issue. You may want to take a look at https://github.com/morrownr/USB-WiFi/issues/682
@OscarAkaElvis
if you are curious, this is the link of the patch that works for all the chipsets that are using emulation: https://lore.kernel.org/linux-wireless/[email protected]/
That is the v1 patch. Johannes appears to have quickly put out a v2 patch which is different. I tried the v2 patch this morning on my test system that uses kernel 6.18.1. I was hoping that it might help with monitor mode being broken on the mt7921u driver. No luck.
I have sent a report to 3 Mediatek devs. I hope we can resolve what is going on here with chanctx soon.
yeah, I was testing the second version of the patch. He was hoping to fix also Mediatek, but it crashes. I already passed the log to him. He is aware. But the first version which solves the issue for the rest will be merged soon.