Injection not working in monitor mode #376
Comments
|
Small correction: it does work with ifconfig & iwconfig. It does not work with ip link and iw dev. |
|
Ok all, i found out what the problem was. Please also see this issue: secdev/scapy#2076 There seems to be an issue with the 5.3.4 branch (and up) of the driver. when libpcap needs to PCAP_SET_RFMON to 1 it just doenst PCAP_ACTIVATE() anymore and results in error code -1. I went back to the 5.2.20 driver and everything worked again! Not sure if related but i did not use the dkms installer. I also used ifconfig and iwconfig instead of ip link and iw dev (which is in the manual). |
|
@marc-y-marc We know. Take a look here t6x/reaver-wps-fork-t6x#282 But for me it is different, on v5.3.4 i have to use "iw" and "ip" (and not the ongoing deprecationed ifconfig/iwconfig), anyhow the v5.6.4 is quite more stable than the v5.3.4 again (but it only got support for 8812au still) as I could need some help adding phydm and HAL for 8821au and 8814au from @fariouche when he's available 👍 |
|
v5.3.4 got some stability issues I noticed early on, I have to put the device up & down and do a scan in between (before I put it in monitor mode, then I'll do a scan more) then I test injection. |
|
I also reverted to the 5.2.20 branch and all was OK. I'm ok to close this issue since we will move on to the 5.6.4 branch - when people search regarding this issue at least they know how to resolve it :-) |
|
True. We'll try to move forward soon hopefully |
|
Switching back to driver version 5.2.20 fixed the issue I had with bettercap as well: Kernel: |
|
I can confirm that, too. Last working version is 5.2.20 v5.3.4: $ uname -r $ sudo ./aireplay-ng --test wlp0s20f0u1 $ sudo hcxdumptool -i wlp0s20f0u1 --do_rcascan |
|
v5.2.20(.2) is the most stable atm, v5.3.4 was never finished as a new release followed shortly after release. Will start tomorrow getting the v5.6.4.1 up & running |
|
@kimocoder , thanks for the info, Christian. v5.2.20 is running fine here, after I reverted that nasty xhci patch (https://bugzilla.kernel.org/show_bug.cgi?id=202541). v5.6.4.1 showing some issues. It looks like some ioctl() system calls are not supported, yet and I hope, that you're able to fix it. hcxdumptool neither use libpcap nor libnl, because I can't run all attack modes using libpcap and/or libnl (unfortunately iw creates sometimes netlink monitor interfaces - airmon-ng internally runs iw - and that is the reason why hcxdumptool print a warning if it detect a monx interface). v.5.6.4.1 $ sudo hcxdumptool -i wlp0s20f0u1 --check_driver $ sudo iw dev wlp0s20f0u1 set type monitor |
|
latest v5.6.4.1 (head: 9daa797) showing some issues on ioctl() system calls: $ sudo hcxdumptool -i wlp0s20f0u3 --do_rcascan compared to latest v5.2.20 (head: 32aad89): $ sudo hcxdumptool -i wlp0s20f0u3 --do_rcascan |
|
Yeah I barely started looking into the driver.. also ran cppcheck to it, and boy it was lots.. |
|
I didn't run tests with airodump-ng, aireplay-ng and airmon-ng, but I'm sure they will show something similar. BTW: Unfortunately this monitor mode will not work. That also has an impact on airmon-ng, because the script runs iw to activate monitor mode. |
|
But I use it on a daily basis, and it works like a charm.. don't get it.. but I'll go deep to find it |
|
|
|
That is very interesting. Just compiled aircrack-ng suite and got similar issues: $ sudo iw dev wlp0s20f0u3 info $ sudo ./wash -i wlp0s20f0u3 $ sudo ./airodump-ng wlp0s20f0u3 Also I noticed a possible issue during init and/or de-init. Depending on the tool which used the driver I got different start values after I removed/plugged-in the device several times. Which kernel do you run? |
|
Just installed a fresh Linux system inclusive aircrack-ng suite and LTS kernel 4.19 and v5.6.4.1 (head: d664d7e) $ sudo airmon-ng start wlp0s29f7u1 At this point we use iw to enable monitor mode: and run airmon-ng again: Now everything is looking fine, but running airodump-ng results in an empty scan list
|
|
Latest branch, right? It has been working all along over here.. i don't get it? comparison to all my other cards.. the 8812au has become powerfull after v5.6.4 (new phydm, txpower issues resolved). It beast the crap out of whole my collection with WiFi equipment. But I'm looking into IOCTL in the code now, have pushed alot. Right now I'm focusing on all this shit hardcoded styff, and nuking old & unused. Will go back to more bug related stuff shortly 👍 |
|
Yes, the new rtw88 driver is really good. I'll do some more tests (on latest git head) and take a closer look into the driver code. BTW: In any case, your work on that driver is really, really awesome! |
|
I got some issue patches awaiting, plugged a kfree buffer in kernel v4.19 earlier. |
|
Found a couple IOCTL problems, plug'em as I go .. |
|
Tested latest head c2fd51a and noticed some changes: Second run, without removing the device between the runs: Then the driver crashed the USB host: dmesg doesn't show this warning: I removed the USB 3 commit (head: 7ff8e97) I'm not sure, what happened exactly until I do a deeper code walk through os_intfs.c Cheers |
|
One of the latest commits v5.6.4.1 broke compiling on this are the last errors: |
|
Yes I'm aware of it, didn't simply have time to correct it yesterday 😏 will have a closer look today |
|
what device/chipset do you use @ZerBea ? |
|
EDIMAX AC600: EW-7811UAC (RTL8811AU) |
|
I think (but I'm not sure) the ioctl() issues are related to USB host. xhci on latest kernels is very, very instable. |
|
Aaaah that explains alot.. the HAL was just added. 8812au is the one who's working really good. The 8811 chipset uses 8821au, and both that and 8814au uses an old HAL (from v5.1.5) and will never be as good as 8812au has until realtek releases newer HAL's unfortunately😏 adding support for them also gives us other problems, like using the drivers on Android.. 8812au HAL supports Android 8/9, but 8814au and 8821au does not.. and the code from those older base is really, really dirty |
|
I'll finish up the main "driver" before I start on those other chipsets and we'll see what to do |
|
sounds like this one's a bit of a turkey then. maybe rtw88 could one day support 8814's but for linux, sounds like I'm better off with an 8812, awus0365ach and similar. I notice a bunch of issues on these also opened but also sounds like 5.6.4 solved most of those? |
|
Yeah me too, the rtw88 is mac80211 too, even though it's unlikely. Yeah, the issue reports i need to strip down, or need to go through 'em |
|
So the 036ACH arrived and.... behaves just like the AWUS1900 (at least from a user-side perspective) Everything generally works across the different branches to varying degrees with the exception that hcxdumptools combined with this driver is not happy in a virtual machine (except on realtek-rtl88xxau-dkms [currently v5.2.20], where it sorta works some of the time?) hcxdumptools DOES work fine in a VM with a random assortment of other USB wifi sticks I used NO: VM + rtl8812au + hcxdumptools additional notes: 8812 also picks up more stations+better signal on them. i definitely don't need MIMO so I think there's no benefit of any kind other than it looks "cool" to have tons of antennas on a thing :p |
|
@PixlEmly thanks for the feedback. $ lsusb BTW: $ sudo hcxdumptool -i wlp3s0f0u11u1 --check_driver That is the major reason, why I recommend only a few system combinations which are really working without compromises. Unfortunately rtl8812au and rtl8188eus have some NETLINK initializations inside which doesn't make life easier, because hcxdumptool doesn't use NETLINK protocol to communicate with the driver. And yes, you're absolutely right with you additional notes: |
|
But this is rtl88xxau thread, so let's talk about this driver here. First of all, this driver v5.2.20 (my device is 8811) is working fine. $ sudo hcxdumptool -i wlp0s20f0u3 --check_driver $sudo hcxdumptool -i wlp0s20f0u3 --do_rcascan Eveything is working like expected $ sudo iw --debug dev wlp0s20f0u3 info and hcxdumptool print error message, because it can't access the device any longer: Unfortunately we have a similar issue AF_NETLINK on rtl8188eus. In this case, the driver is only initialized if the first message to the driver is an AF_NETLINK message. I'm still hunting for that issue on rtl88xxau and rtl8188eus, but the driver code is very hard to read: tons of ifdef/endif, debug trace code and user space applications (old hostapd code) inside. I will say, if the VM takes access to the device - hcxdumptool may not work as expected. |
|
Now let's answer the "final question": Why is aircrack-ng suite working? |
|
To determine that this issue is possible related to the driver, we are doing exactly the same, running mt7601u driver: $ hcxdumptool -I $ sudo hcxdumptool -i wlp3s0f0u11u1 --do_rcascan $ sudo iw --debug dev wlp3s0f0u11u1 info Everything is working like expected. hcxdumptool has still full access to the device and rca_scan continued without an error. BTW: |
|
So despite what I said earlier I'm actually seeing wierdness across the driver branches. I can only seem to get any consistency with hcxdumptools under 5.2.20, wifite seems best with 5.6.4 (not .1) The AWUS1900 seems to have a lot of strange things going on, particularly the signal strength readings are returning impossible values - an AP 2 houses down is certainly not 80db when one 12 feet away only gets 72? (seems like any value under ~25db turns into something silly) 036ACH does get better strength readings on the values that are sensible, and picks up more access points. Success/failure of different utilites is variable. Works once, stops later. Replug the USB, sometimes it's happy, other times a restart, others still, cleaning out DKMS and adding a driver back in. I definitely don't have a clean test lab or a good methodology going, but patterns are finally appearing. Are branches building on previous ones, or is this more of a parallel thing where each branch/version may be ahead/behind various aspects than others? |
|
@PixlEmly I refactored the complete handling of ioctl() system calls: If you run I hope, this error messages will help us to hunt for the issue. BTW: We had a similar driver issue on mt76 (fixed, yet): |
|
Didn't know it skips checks if iw is used - that's what I've always been doing another thing I need to test some more - what arguments is wifite using hcxdumptools with for pmkid capture, because it seems to succeed when hcxdumptools by itsef cannot see/poke any stations. might be everything is fine and the card is not really changing channels or transmit is 0mw or something else silly.. and then then wifite with a station selected is setting things where they need to be for success. |
|
if iw monitor mode interface we assume that: During initialization we check that we are able to set all channels in the scan list and we verify that they can be set. BTW: |
|
If everything is working fine, but after a while no packets are received or are injected, the AF_PACKET socket (which hcxdumptool use) is destroyed by the driver. This is a driver issue, too. I noticed that on older rt2800usb drivers. Anyway: the interface must be initialized by the driver - that is not part of hcxdumptool or iw or airmon-ng ,.... |
|
Still testing variations. :p Noticed one thing: forcing it to run at USB2 with a usb extension cable has massively improved performance+repeatability. on a test drive: also, do these rtl88xx have any sort of nonvolatile config I should be aware of or know how to set to a known state? |
|
@PixlEmly good investigation: Still issues within the init of the devices: Also big differences between chipsets (rca_scan runtime 2 minutes): TENDA W311U+ Tested also rtl8188eus chipsets (TP-LINK WN722 V2) and they are really sensitive (good rx behavior). Would be great to get this driver working, too. |
|
BTW: $ hcxdumptool -I wlp3s0 $ sudo hcxdumptool -i wlp3s0 --check_driver $ sudo hcxdumptool -i wlp3s0 --do_rcascan The initialization process is very fast, the card is full initialized and injection is working without problems. I really hope, this will not be over with upcoming rtw88. |
|
Found out:
Unchanged:
|
|
for information, note that virtualbox has issues virtualizing usb, especially usb3 device. |
|
The USB switch was terrible to start with, wonder if we should just force it down to USB2.0 instead of USB3 .. |
|
@fariouche, would you happen to have links to bug reports in virtual box? @kimocoder as an idea, not sure if doable, but maybe have a parameter when loading the module so we let user choose to use usb2 or usb3 |
|
I may confirm both virtualbox and vmware issues, but never found the issue related to them. A switch allready exists, I'll find ut tomorrow as I've allready tucked in |
|
@ulli-kroll is quite familiar with the USB quircks, maybe he'll leave us his findings/notes here or a solution to our issue |
|
@aircrack-ng , it was severall month ago... I'm still having issues with virtualbox, (linux host). The device is recognized and connect fine, but the dongle will disappear or act strangely when I start transferring many packets. |
|
To summarize. the driver won't work in any VM (vmware/virtual box), correct? |
|
I don't think it will, I haven't tested but users says it's not working. However, frame injection support is suddenly lacking. This will be the priority now! |
|
Injection now working for newest branch v5.6.4.2 also, so I'm marking this as resolved for now.
|
|
Update... branch v5.6.4.2 is working with scapy now. |
|
Great. |
I'd like to re-open this issue:
#348
I have the same identical problem. When monitor mode is set, injection is not working anymore.
kernel: 4.15.0-1037-raspi2
The text was updated successfully, but these errors were encountered: