Open iangregsondev opened 1 year ago
Hi @iangregsondev
Let me say right up front that I do not yet have an AXML but hope to soon. I remember a couple of Kali users last year reporting that the driver for the mt7921au chipset was working well in monitor mode in all 3 bands. I think that happened last September or so and I think the adapter was the Comfast cf-953ax. I have a cf-951ax and have done basic monitor mode testing like testing like injection and deauth but nothing extensive. The cf-951ax is probably not what you want as the lack of an external antenna may make the range less than you want.
I hear a rumor that a new good quality adapter that is smaller and less costly than the AXML should be available very soon. It runs on the same chipset as the AXML.
Would you mind posting the recommended list you are looking at? I'm sure we can get some posts with pro's and con's. I have been recommending the ALFA ACHM as the overall best monitor mode adapter for a few years.
For what it is worth, I know there are a lot of "Best adapters for Kali" lists out there but most are really bad. I think the best list to start with is the "Plug and Play" list here. It is menu item 2. Which is best depends on a lot of factors such as will it be used with a desktop, laptop or RasPi type of computer. Do you need or want a very long range adapter? Do you need a dual band or tri-band adapter? Will you use it with a directional antenna? Will you travel with it?
How soon do you needs to buy?
Regards
Thank you for the reply! This is very helpful.
I honestly wasn't looking at many others, I wanted a Tri-band supporting Wifi6e so the Alfa AXML was the only one I was initially looking at but maybe there are others that I better suited.
Here is what I was looking at.
I would like to purchases it before the laptop arrives, so maybe in around 1 month or a little more.
Thanks in advance for your help
Ian
Ian,
My AXML arrived today. My to-do list is full so if you have specific things you want tested, i will find time.
I confirmed that the antennas are removable. The extension cable is really nice and supports USB-C and USB-A. Overall quality appears to be very good. The color is flat black and does not show fingerprints. Overall, it is a very modern looking adapter. I just to start testing as able but I will test what you want when you let me know what to test.
Very nice, I suppose its confirmed as supporting Monitor Mode and Packet Injection ?
Sounds like a great piece of kit!
Out of interest, are you using it in Kali Linux or some other OS ?
I suppose its confirmed as supporting Monitor Mode and Packet Injection ?
The mt7921au chipset and the mt7921u driver are confirmed to support monitor mode and packet injection but I hesitate to say yes until I see it myself or get numerous reports saying it does. The AXML is still a fairly new product. The only two recent issues I have seen are AP mode related. I can't say that I remember single complaint about monitor mode yet but my memory is not as good as it used to be. I will test.
Out of interest, are you using it in Kali Linux or some other OS ?
I usually keep a partisan with Kali on it in my small lab but it made me mad last fall. I have better things to do than fix distros so I deleted it. I am over being pissed now so I will get Kali back up soon. Kali is somewhat less stable than many distros and I have more work to do working on adapter drivers, docs and answering questions. To ensure good testing, I frequently blow out old installations and install new. I have little tolerance for stuff that is broken.
I can test monitor mode but I have 2 high priority jobs I need to work on right now. If you haven't see a report here by next Monday, ping me.
Sounds great, thanks
@morrownr it would be great if you can confirm/not confirm that active monitor mode is working, too. I asked it, because some MediaTek chipsets announce (NL80211_FEATURE_ACTIVE_MONITOR) that they support active monitor mode, but unfortunately they don't, e.g. mt7601u: https://bugzilla.kernel.org/show_bug.cgi?id=217465
In advance, thanks. Regards Mike
Good day @ZerBea
I asked it, because some MediaTek chipsets announce (NL80211_FEATURE_ACTIVE_MONITOR) that they support active monitor mode, but unfortunately they don't, e.g. mt7601u:
The only Mediatek driver that falsely reports active monitor is the mt7601u as far as I know. I try to warn users of the Plug and Play list (Main Menu item 2) in the section about the mt7601u chipset that monitor mode is not full featured.
What we need is a little script that can reliably test some things including active monitor mode. Do you have a sequence of commands that can reliably determine if active monitor is supported and working correctly?
We could add the script to the Monitor Mode repo (Main Menu item 10):
https://github.com/morrownr/Monitor_Mode
We could even add some other tests. I can start making the script if you can provide some info to get started.
Hello @morrownr Thanks for your answer. Doing this via a script is not so trivial.
The first part (set monitor mode) is simple. It can be done via iw or via hcxdumptool:
the iw way: $ sudo ip link set INTERFACE down $ sudo iw INTERFACE set type monitor $ sudo iw INTERFACE set monitor active $ sudo ip link set INTERFACE up
the hcxdumptool way: $ sudo hcxdumptool -m INTERFACE
The second part is tricky, because mt7601u (falsely) report "NL80211_FEATURE_ACTIVE_MONITOR" feature. The only way to detect that it isn't working is to analyze the incoming traffic by e.g. tshark or Wireshark. If we see only packets addressed to broadcast (ff:ff:ff:ff:ff:ff) or to the device MAC, active monitor mode is not working. I guess, this is not feasible via a simple script.
BTW: Active monitor mode is an amazing feature (if targeting a PMKID). We get an immediate response from the (target) Access Point: Tested this on: ASUS USB-AC51 TP-Link Archer T2UH ALWA AWUS036ACM ALWA AWUS036ACHM
@iangregsondev
Short test of packet injection on 2.4 GHz band:
19:48:30 Trying broadcast probe requests... 19:48:30 Injection is working! 19:48:32 Found 2 APs
19:48:32 Trying directed probe requests... 19:48:32 8C:59:73:FE:8B:F4 - channel: 1 - 'XXXX' 19:48:32 Ping (min/avg/max): 1.421ms/5.613ms/37.082ms Power: -26.10 19:48:32 30/30: 100%
19:48:32 12:59:32:04:A7:B8 - channel: 1 - '' 19:48:33 Ping (min/avg/max): 0.753ms/4.356ms/9.120ms Power: -42.55 19:48:33 22/30: 73%
Just a quick test. I'll need to do more testing and get my ACHM out to do a comparison before I can offer any opinions.
Quick managed mode test:
5 GHz band channel 100 DFS 80 MHz channel width 3 walls, about 12 meters
$ iperf3 -c 192.168.1.1
Connecting to host 192.168.1.1, port 5201
[ 5] local 192.168.1.198 port 38282 connected to 192.168.1.1 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 72.1 MBytes 605 Mbits/sec 0 1.82 MBytes
[ 5] 1.00-2.00 sec 72.5 MBytes 608 Mbits/sec 0 1.82 MBytes
[ 5] 2.00-3.00 sec 75.0 MBytes 629 Mbits/sec 0 1.82 MBytes
[ 5] 3.00-4.00 sec 73.8 MBytes 619 Mbits/sec 0 1.82 MBytes
[ 5] 4.00-5.00 sec 72.5 MBytes 608 Mbits/sec 0 1.82 MBytes
[ 5] 5.00-6.00 sec 73.8 MBytes 619 Mbits/sec 0 1.82 MBytes
[ 5] 6.00-7.00 sec 73.8 MBytes 619 Mbits/sec 0 1.82 MBytes
[ 5] 7.00-8.00 sec 73.8 MBytes 619 Mbits/sec 0 1.82 MBytes
[ 5] 8.00-9.00 sec 72.5 MBytes 608 Mbits/sec 0 1.82 MBytes
[ 5] 9.00-10.00 sec 75.0 MBytes 629 Mbits/sec 0 1.82 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 735 MBytes 616 Mbits/sec 0 sender
[ 5] 0.00-10.01 sec 732 MBytes 613 Mbits/sec receiver
iperf Done.
Not bad. Need to test other channels and distances as well as do some comparison testing.
@morrownr , thanks for the injection test. Why do you use aireplay-ng? It only count (short) ack frames to determine that injection is working.
@morrownr , thanks for the injection test. Why do you use aireplay-ng? It only count (short) ack frames to determine that injection is working.
I have no preference for aireplay-ng. It just happened to be the closest thing at hand. Tell me what you want tested and the instructions and I will test it.
Did you see my post today about the new Alfa AXM adapter?
The first part (set monitor mode) is simple. It can be done via iw or via hcxdumptool:
the iw way: $ sudo ip link set INTERFACE down $ sudo iw INTERFACE set type monitor $ sudo iw INTERFACE set monitor active $ sudo ip link set INTERFACE up
I am aware of this. I wrote start-mon.sh.
The only way to detect that it isn't working is to analyze the incoming traffic by e.g. tshark or Wireshark. If we see only packets addressed to broadcast (ff:ff:ff:ff:ff:ff) or to the device MAC, active monitor mode is not working. I guess, this is not feasible via a simple script.
Don't bet on it. I think you just wrote the logic to make it work. Tell me about tshark.
BTW: Active monitor mode is an amazing feature (if targeting a PMKID).
You can educate me more. We could use parts of start-mon.sh to start a new script. It appears that what we need is a text mode app to handle the capturing. BASH is actually capable of of doing complicated work.
@morrownr , thanks for the injection test. Why do you use aireplay-ng? It only count (short) ack frames to determine that injection is working.
I have no preference for aireplay-ng. It just happened to be the closest thing at hand. Tell me what you want tested and the instructions and I will test it.
Did you see my post today about the new Alfa AXM adapter?
Thanks for your answer. Aireplay-ng is fine do to an initial test but it doesn't cover some things. E.g After I wrote this comment: https://github.com/morrownr/USB-WiFi/issues/275#issuecomment-1581041731
I tested an ALFA AWUS036ACM and noticed that frequency change via NETLINK is very slow. My default scan time was one second - and that is not enough. To make sure, the device is on the new frequency and ready to transmit, I had to increase it to at least two seconds: https://github.com/ZerBea/hcxdumptool/commit/0a940f251237c032d83833549b36e6543f089d7c#diff-8125ff62a279e92c823e77b6ba7da82b2544b5db078008535e0bf8034cbc96f7R2793
Yes, I noticed you post and I'm surprised about the new L adapter, too.
Some words about hcxdumptool/hcxtools. This penetration testing tools are kind of a WiFi pre-processor to hashcat or to John the Ripper (JtR). Goal is to discover weak points in (own) NETWORKs in a very short time.
hcxdumptool -> hcxtools -> hashcat/JtR
Using this workflow, we discovered the PMKID attack (for the first time):
https://hashcat.net/forum/thread-7717.html
The PMKID attack is not the only one. There are several other weak points e.g. transmit password in the clear: https://github.com/evilsocket/pwnagotchi/issues/835#issuecomment-598597214
or get IMEI of a cell phone: https://hashcat.net/forum/thread-6661-post-44789.html#pid44789
or downgrade WPA3 CLIENT to WPA2 or get EAPOL M2 from an unconnected WPA CLIENT or get EAP-ID
The simplest way to discover if your ACCESS POINT or your CLIENTs are weak is to run hcxdumptool against them: stop all NETWORK services that take access to the interface (e.g. NetworkManager and wpa_supplicant) $ sudo hcxdumptool -i interface -c channel_o_ap (e.g. 1a) --rds=1
If you got a PMKID, an EAPOL M3 (AP) or and EAPOL M2 (CLIENT) you can stop the attack, convert the pcapng dump file to a format that hashcat or JtR understand (by pcapngtool). Now you're ready to break the password. hcxpcapngtool is part of hcxtools, which are running in back ground of several online services e.g.: https://wpa-sec.stanev.org/ https://hashcat.net/cap2hashcat/
Additional you can use hcxdumptool as a simple WiFi scanner (active or passive): $ sudo hcxdumptool -i wlp22s0f0u4 -F --rcascan=active
You directly see if you got a PROBERESPONSE to a PROBEREQUEST:
CHA FREQ BEACON RESPONSE A MAC-AP ESSID SCAN-FREQUENCY: 2457
--------------------------------------------------------------------------
[ 10 2457] 08:03:50 08:03:50 + 0a96d798f10e TEST-G
[ 10 2457] 08:03:50 08:03:50 + 0896d798f10e AP_7272
An ACK is a short frame that doesn't contain useful information. If a channel is busy, there is mostly a time to transmit this short frame. A PROBERESPONSE frame is big and contain a lot of information. If a channel is busy, there is no time slot to transmit this big frame. In that case you can stop your attacks, because you will not get useful (big) frames from the target. That makes the difference: counting small ACKs or retrieving full frames.
In attack mode you can see what kind of EAPOL MESSAGEs the AP respond (upper display) or the CLIENT respond (lower display). And for sure, most of them respond to hcxdumptool's layer 2 attacks.
tshark is a great tool. Mostly I run it in parallel to hcxdumptool (while coding new features) to make sure that hcxdumtool is exactly doing what I want to do it. It is the little brother of Wireshark. It came with Wireshark, but doesn't provide a GUI. Running bash tools like awk on the columns of tshark terminal output it might be possible to detect if active monitor is working as expected. But I haven't tested this.
@ZerBea
Thanks for the info. I want to get back to this topic but it may be a few days as I am busy.
any updates @morrownr ?
Now it is completely broken on kernel: $ uname -r 6.6.10-arch1-1
https://github.com/ZerBea/hcxdumptool/discussions/361#discussioncomment-7567045
Hi, What were the end result of this? Does ALFA AWUS036AXML support packet injection and monitor mode in Kali? Best, J
That highly depend on the kernel. As of today running Arch Linux (kernel 6.7) and Debian (kernel 6.6). https://github.com/openwrt/mt76/issues/839#issuecomment-1968509383
Hi,
Can anyone confirm that this new model (wifi6e) ALFA AWUS036AXML is a good candidate for Kali Linux and working in Monitor mode.
I am trying to go through a course that requires a usb adapter that is supported in Monitor mode.
There is a list of recommended devices but this new model is not listed.
I was hoping to find some info on it but I could not, maybe I wasn't looking in the right place.
Any pros / cons for this adapter to work with Kali Linux in Monitor mode etc ?
Thanks in advance