NEW upstream driver available! #34
Comments
|
Huge improvement, compared to the older versions: I'll remove this warning Sometimes it is necessary to reset the device, because connection between USB subsystem and driver get lost: Thanks for your excellent work Christian. |
|
By this commit: |
|
I still haven't figured out why the device sometimes doesn't respond. |
|
Another device confirmed: TP-LINK TL-WN821N |
|
And another one successfully tested: LOGILINK WL0151A |
|
@ZerBea could you test AP support in 8188eu driver and report back? Also possibly test VIF (airmon-ng start ) support? |
What kernel version was this tested on? |
|
$ uname -r An USB reset fix that problem. I guess it is related to XHCI/USB subsystem. BTW: AP and VIF via iw will follow. |
|
VIF test using iw to set VIF monitor interface (airmon-ng is running iw to set monitor mode, so no need to use it): Edited the test result: AP test will follow (have to set up an environment for the test). |
|
Another device tested: ALLNET ALLWA0100 |
|
Another device tested: TPLINK TL-WN725N |
|
Another test: EDIMAX EW-7811UN V2 |
|
I'm very impressed with this driver. |
|
Awesome, so VIF seem to be working now 👍 finally got those chips under mac80211, makes me really happy |
|
Most of this devices I tested are cheap nano adapters stock drivers must be blacklisted in /etc/modprobe.d mac80211 stack must be loaded before inserting rtl8xxxu.ko (on first time) |
|
Thanks for that information. But I gave it up to use active monitor mode, because the disadvantages are huge. |
|
|
If tx power is really always the same, it will violate wireless regulatory domain: |
|
Data rate (set by hcxlabtool): Here is the entire (data) frame, received on the second monitor interface: |
|
I forgot to mention: test interface is an ALFA AWUS036NHV Monitor interface is an ASUS AC51: And I still recommend this driver in combination with hcxdumptool and hcxlabtool. |
|
I'm not here to insinuate anything, or criticise the driver. I just know the internals somewhat |
|
Ok. |
|
|
|
Some additional information how hcxlabtool change the values (e.g. frequency, rate, bandwidth) by NL80211: |
|
To make sure, it's no coincidence, I changed the rate via NL80211 to 1MB/sec (that can easily be done by changing some code lines in hcxlabtool). now with a rate of 1MBit/sec: |
|
If you're right, that the driver doesn't honor this settings, I have to call my entire environment (monitor interface, measurement procedure, Wireshark) into question. |
|
The TX power issue is very simple. rtl8xxxu only changes the TX power when changing the channel, and it always sets the same power per channel. The TX rate issue is also simple if your device is RTL8188EU(S). You can insert the module with |
|
Thanks for your explanation. Maybe we are talking about different things and I apologize for the insinuation: BTW: |
|
BTW: hcxlabtool set rate to 6MBit/sec. But dmesg constantly show: Now the funny part: The independent monitor interface (mt76) report that the frames are transmitted with this rate: and dmesg debug show: For me, it looks that: AWSU036NHV and the test target negotiate the rate among themselves - but I'm not sure. |
|
Also I can't explain this: According to the independent monitor interface all frames are transmitted at 6MBit/sec. |
|
I code penetration testing tools. on target side (target = AP): on target side (target = CLIENT): And sometimes a Spectrum Analyzer (independent measurement). But such a thing is very expensive and I have to borrow it. Every test start with iw reg set xx to make sure that the driver respect wireless regulatory domain and set the correct country value. Mostly the interface tx power is below this allowed value. I made some measurements with a Spectrum Analyzer and I have to trust this settings. If hcxlabtool get the information (M1, M2, EAP-ID, undirected PROBEREQUEST as fast as possible (without spamming the entire channel with mostly useless DEAUTHENTICATION frames) the test is successful and this interface/driver can be used with hcxlabtool (and I recommend it). If the test failed (e.g. iwlwifi) I do not recommend interface/driver. BTW: MT7610U incomplete driver information (struct ethtool_drvinfo) rtl8xxxu failed to get correct interface information: or to upstream: or (in case of a third party driver) directly to the maintainer of this driver: But main purpose is to discover weak points of Wireless Systems as this one here: or the this one : or this one (ANONCE ERROR CORRECTION); AP increase last unit32_t of ANONCE instead of REPLAYCOUNTER and a lot more... (hcxpsktool). If you discover a weak point in my test environment, please let me know. That will help me to improve workflow and/or equipment. |
|
Mystery solved: your injection tool generates a radiotap header where it writes the TX rate you requested. mac80211 reads that rate and passes it on to rtl8xxxu, which ignores it and transmits the frame with whatever rate it wants. Your independent monitor device sees the rate in the radiotap header and reports it to you. The TX power is also in the radiotap header, but even mac80211 ignores it. |
|
Thanks for the explanation. That is correct. hcxdumptool use this this radiotap header to inject frames. Unfortunately hcxdumptool is a WIRELESS EXTENSION dinosaur and outdated. Regarding protocol attacks 802.11 on layer 2, tx power is completely meaningless. I commented this several times on hashcat forum and here (lessons learned): The second mystery is also solved, because hcxlabtool is going a different way (RTNELTLIN/NL80211 instead of WIRELESS EXTENSIONS). It use the smallest possible (injection) radiotap header if it expect a response (e.g. to do an entire AUTHENTICATION): or if it doesn't expect a response on the first attempt (fire single frame on first reception of a BEACON): Set device up and down, set virtual MAC, set monitor mode, set channel is now completely done via RTNETLINK and NL80211. And this misunderstanding should now also be clarified: |
|
BTW: |
|
I will start implementing AP mode support this evening. |
|
@ZerBea Github showed you my email address? That's not very nice of Github. It's okay, though, you don't have to prove anything to me. I just wanted you to double check, because I had doubts about the driver's capabilities and an automated test may miss something. |
|
@dubhater , git API is very useful to retrieve public information: hcxlabtool in combination with an AWUS036NHV, the rtl8xxxu driver (this one before the last commits and the kernel stock driver) does exactly what I expected (and a little bit more). @kimocoder , is it worth to add AP mode to hcxlabtool, too. I'm not sure, because I have to set virtual MAC every time I got a new PROBEREQUEST. Doing this via RTNETLINK is not the best/fastest choice. |
|
Hold on, im working on it and I also setup a full debug env for rtl8xxxu through debugfs. |
|
For me, it will be only for testing purpose. If I'm able to add AP mode to hcxlabtool, it might be possible to get an EAPOL M2 on interfaces that do not support monitor mode. |
|
@kimocoder , please take a look at your PM. The results speak for themselves (~25 % recovered < 4:17 minutes). |
|
@kimocoder , maybe interesting for you: |
New improved rtl8xxxu upstream.
Includes rtl8188e and rtl8188f chips in the mac80211.
The text was updated successfully, but these errors were encountered: