Open baltic-tea opened 8 months ago
Hi @baltic-tea
Let me throw a few ideas out:
sudo airmon-ng check kill
Over the last few years I have noticed that using airmon-ng check kill is often less than effective. In fact, I wrote a script to replace it. My script does not kill, it pauses threads that may cause problems. The issues with killing is that some of the problematic processes are programmed these days to detect when they are going down and they start a new process effectively defeating any attempt to kill. Pausing the processes does not seem to trigger a new process.
Go to the Main Menu:
https://github.com/morrownr/USB-WiFi
Menu item 10 is what you want.
I couldn't change the txpower value of Comfast CF-953AX. It is always 3.00 dBm.
I have not seen a new adapter come on the market for a long time where we could set txpower.
3 dBm does not appear to be what we think it should be but consider it cosmetic as the actually results tell us it can't be 3 dBm.
sudo airmon-ng start wlan0
The script I mentioned above will also put the interface into monitor mode.
Downloaded and installed these MediaTek drivers as advised...
Those are the firmware files. The driver comes with the kernel. You only need to install the firmware files if the maintainer of the distros has not installed them or if they are an old version.
See if you can make some progress with the info above.
Hi, @morrownr
Go to the Main Menu:
Menu item 10 is what you want.
I run your scripts but am getting a wifite error:
sudo wifite
. .
.´ · . . · `. wifite2 2.7.0
: : : (¯) : : : a wireless auditor by derv82
`. · ` /¯\ ´ · .´ maintained by kimocoder
` /¯¯¯\ ´ https://github.com/kimocoder/wifite2
[!] Conflicting processes: NetworkManager (PID 1106), wpa_supplicant (PID 2625)
[!] If you have problems: kill -9 PID or re-run wifite with --kill
[+] Using wlan0mon already in monitor mode
[+] Scanning. Found 0 target(s), 0 client(s). Ctrl+C when ready
[!] Error: No targets found. You may need to wait longer, or you may have issues with your wifi card
[!] Exiting
Also tried to run stop-procs.sh
in the background - no effect:
sudo ./stop-procs.sh wlan0mon &
Kernel output (after re-plugging adapter):
kern :info : 2023-11-03T14:50:27 usb 3-12: reset high-speed USB device number 5 using xhci_hcd
kern :info : 2023-11-03T14:50:27 mt7921u 3-12:1.0: firmware: direct-loading firmware mediatek/WIFI_MT7961_patch_mcu_1_2_hdr.bin
kern :info : 2023-11-03T14:50:27 mt7921u 3-12:1.0: HW/SW Version: 0x8a108a10, Build Time: 20230526130917a
kern :info : 2023-11-03T14:50:27 mt7921u 3-12:1.0: firmware: direct-loading firmware mediatek/WIFI_RAM_CODE_MT7961_1.bin
kern :info : 2023-11-03T14:50:27 mt7921u 3-12:1.0: WM Firmware Version: ____010000, Build Time: 20230526130958
kern :info : 2023-11-03T14:51:22 mt7921u 3-12:1.0 wlan0mon: renamed from wlan0
kern :info : 2023-11-03T14:51:30 mt7921u 3-12:1.0 wlan0mon: entered promiscuous mode
kern :info : 2023-11-03T14:51:30 mt7921u 3-12:1.0 wlan0mon: entered allmulticast mod
After kill NetworkManager (PID 1106)
the scanning started working... and then stopped again after rerun wifite.
I run your scripts but am getting a wifite error:
I would not trust the output of wifite in this case because my start-mon.sh and stop-procs.sh scripts do not kill the processes so unless wifite is programmed to understand what is being done, it will simple say that the procs are running and there is a problem.
To do a proper test, run start-mon.sh and once you are in monitor mode, run the app you wish to run and see if it gives the results you are looking for. If not, post the steps necessary for me to reproduce the result and I will take a look.
Keep in mind, start-mon.sh does everything that stop-procs.sh does with the exception that it does not take the interface into monitor mode. After reading the docs again, I probably need to make that clear. I always run start-mon.sh because if I am stopping the processes, it is for monitor mode.
Keep in mind that there are some advantages to stopping the procs instead of killing them. There is no need to reboot to get things going again as start-mon.sh will simple release the procs to run again at the end of the script. It also allows a managed mode connection to stay connected so if you want to be connected to the internet with one interface and run monitor mode in another, it works.
Cheers
Everything works fine now (wifite keeps giving error messages, but the scanning works correctly). I'll be testing the capturing handshake again.
UPD: This problem https://github.com/morrownr/USB-WiFi/issues/327#issuecomment-1792300434 occurs more frequently when connected to the motherboard's USB port. I'm confused.
Actual situation
After running only sudo ./Monitor_Mode/start-mon.sh wlan0
: the adapter stops scanning APs. if it actually finds the APs:
Error: Target did not appear after 60 seconds, stopping
;After running only sudo wifite
(wifite using airmon-ng - reference code): the adapter start scanning APs (fast) and I was even able to crack a few WPS-encrypted APs, but - in this case - only one type of attack is effective – Pixie-Dust. Other types of attacks go on too long (usually triggers a timeout error) and have no effect.
P.S. in the 2nd scenario CF-953AX often - after a failed cracking try, I think - stops detecting APs and only re-plugging could fix it (switched to default managed mode after unplugging) - error message as hear.
script stops scanning APs
How are you scanning for APs?
I'll do some testing here and see what I come up with.
script stops scanning APs
How are you scanning for APs?
I'll do some testing here and see what I come up with.
I only running sudo wifite
or sudo wifite --reaver --wps
wifite2 2.7.0 (bundled in Kali Linux)
I did some testing.
Adapter with a mt7921au chipset. Alfa AXML. Distro: LMDE 6 (Debian 12)
sudo ./start-mon.sh <wlan0>
--------------------------------
start-mon.sh 20230305
--------------------------------
WiFi Interface:
wlxxxxxxxxx
--------------------------------
name - wlxxxxxxxxx
type - monitor
state - DORMANT
addr - 00:c0:ca:aa:e8:ba
chan - 11 (2462 MHz), width: 20 MHz (no HT), center1: 2462 MHz
txpw - 18.00 dBm
--------------------------------
DORMANT = up but inactive.
Ready for Monitor Mode use.
You can place this terminal in
the background while you run any
applications you wish to run.
Press any key to exit...
Interestingly, I was able to change txpower using my script.
I then opened another terminal and...
Test injection
Scan
sudo airodump-ng <wlan0> --band ag
Set the channel of your choice
sudo iw dev <wlan0> set channel <channel> [NOHT|HT20|HT40+|HT40-|5MHz|10MHz|80MHz]
Test
sudo aireplay-ng --test <wlan0>
Scanning was very fast and smooth. Changing channels was smooth. Injection was fast and smooth.
I suspect the problem is wifite. If you want me to test it, provide a link where I can get a deb.
Cheers
FYI: I forgot to mention that I tested channels 11 and 44 so as to test 2.4 and 5 Ghz. Both tests were smooth and fast.
If you want me to test it, provide a link where I can get a deb.
For example: https://packages.debian.org/sid/all/wifite/download https://debian.pkgs.org/sid/debian-main-amd64/wifite_2.7.0-1_all.deb.html
In my case state
value change from DOWN to UNKNOWN, not DORMANT, after that UP
--------------------------------
start-mon.sh 20230305
--------------------------------
WiFi Interface:
wlan0
--------------------------------
name - wlan0mon
type - monitor
state - UNKNOWN
addr - 9a:42:78:bc:xx:xx
chan - 6 (2437 MHz), width: 20 MHz (no HT), center1: 2437 MHz
txpw - 3.00 dBm
--------------------------------
DORMANT = up but inactive.
Ready for Monitor Mode use.
I tried run airodump-ng
independently of wifite in 1 and 2 scenarios that i described here. For 2 scenario I run wifite and immediately stop it to only change the mode. Got a similar situation (wifite is mostly python wrapper for some libs like aircrack-ng, I think):
- slow scanning and little number of APs received (versus default wifite's script that switch adapter to monitor mode);
### After your script
▶ sudo aireplay-ng --test wlan0mon
08:41:19 Trying broadcast probe requests...
08:41:21 No Answer...
08:41:21 Found 0 APs
▶ sudo aireplay-ng --test wlan0mon
08:41:24 Trying broadcast probe requests...
08:41:24 Injection is working!
08:41:26 Found 2 APs
08:41:26 Trying directed probe requests...
08:41:26 28:D1:27:E9:xx:xx - channel: 6 - 'A'
08:41:30 Ping (min/avg/max): 5.856ms/10.636ms/13.378ms Power: -75.00
08:41:30 8/30: 26%
08:41:30 50:FF:20:7E:xx:xx - channel: 6 - 'B'
08:41:35 Ping (min/avg/max): 1.444ms/7.372ms/11.797ms Power: -73.00
08:41:35 5/30: 16%
### After wifite
▶ sudo aireplay-ng --test wlan0mon
08:42:34 Trying broadcast probe requests...
08:42:34 Injection is working!
08:42:35 Found 13 APs
08:42:35 Trying directed probe requests...
08:42:35 28:6C:07:98:xx:xx - channel: 11 - 'X'
08:42:36 Ping (min/avg/max): 0.132ms/1.228ms/10.120ms Power: -55.86
08:42:36 28/30: 93%
08:42:36 B0:BE:76:A8:xx:xx - channel: 11 - 'Y'
08:42:38 Ping (min/avg/max): 0.088ms/2.607ms/8.735ms Power: -58.38
08:42:38 21/30: 70%
08:42:38 B0:A7:B9:40:xx:xx - channel: 11 - 'Z'
08:42:38 Ping (min/avg/max): 0.082ms/1.003ms/12.185ms Power: -71.41
08:42:38 29/30: 96%
08:42:38 B4:B0:24:18:xx:xx - channel: 11 - 'Y'
08:42:41 Ping (min/avg/max): 0.093ms/1.341ms/11.975ms Power: -76.71
08:42:41 14/30: 46%
08:42:41 08:C6:B3:DA:xx:xx - channel: 11 - 'O'
08:42:46 Ping (min/avg/max): 0.011ms/0.193ms/0.638ms Power: -78.00
08:42:46 5/30: 16%
08:42:46 68:FF:7B:64:xx:xx - channel: 11 - 'H'
08:42:52 Ping (min/avg/max): 0.011ms/0.587ms/1.163ms Power: -74.00
08:42:52 2/30: 6%
08:42:52 00:EB:D8:11:xx:xx - channel: 11 - 'F'
08:42:58 Ping (min/avg/max): 0.992ms/0.992ms/0.992ms Power: -78.00
08:42:58 1/30: 3%
08:42:58 B0:95:75:76:xx:xx - channel: 11 - 'S'
08:43:04 0/30: 0%
08:43:04 3C:84:6A:4A:xx:xx - channel: 11 - 'Z'
08:43:07 Ping (min/avg/max): 0.127ms/8.759ms/62.872ms Power: -75.29
08:43:07 14/30: 46%
08:43:07 50:D4:F7:D9:xx:xx - channel: 11 - 'L'
08:43:08 Ping (min/avg/max): 0.082ms/1.587ms/10.170ms Power: -70.83
08:43:08 23/30: 76%
08:43:08 CC:32:E5:96:xx:xx - channel: 11 - 'T'
08:43:14 0/30: 0%
08:43:14 E4:18:6B:01:xx:xx - channel: 11 - 'K'
08:43:20 0/30: 0%
08:43:20 38:6B:1C:9F:xx:xx - channel: 11 - 'R'
08:43:26 Ping (min/avg/max): 0.011ms/0.105ms/0.152ms Power: -78.33
08:43:26 3/30: 10%
I will do additional testing on my script as I have time. My to-do list is long and it appears you have an acceptable solution.
I have ordered an active USB cable and will be testing the CF-953AX with it. I will also try to do all this on Windows 11.
I have Fenvi AX1800 (same chipset) that I'm passively testing for a while as WiFi penetration hardware combined whit arm SBC board for field work. Reason why I bought this WiFi adopter was because my existing WiFi adopter, Alpha AWUS036ACM, quite often hanged. As recommended here and overall on internet Mediatek chipsets should have the best support, so I bought Mediatek based again, but looks like there is instability issues on arm arch, again. Quickest way to hang these adopters is whit airodump-ng, sometimes it runs for tens of minutes, maybe hour of two, but usually hangs quite quickly, both adopters. I have tested on Allwinner, Rockchip based SBCs, also Raspberry Pi whit various kernels, usb2 or 3 makes no difference, also usb extensions overall work on both, but no difference. Both adopters work fine on x86, tested Fenvi on weekend whit default kali linux (6.3.0 kernel), run for more than 8h over night, no issues, also tried updating firmware to latest version on SBCs - nothing, it still hangs. Kismet works better, as it can be fine for hours, but can hang. I have not seen any log messages what happens, board just gets unresponsive (might try serial connection). I could not test on latest kernel version, as I am no guru on kernel compiling and use what armbian and others are providing. Arbian have latest kernel 6.6.0 on Rockchip soc, but there is issues whit usb ports, they flap. SBCs kernel versions overall are around 6.1, tested arm64 and armhf.
I have ordered an active USB cable and will be testing the CF-953AX with it. I will also try to do all this on Windows 11.
CF-953AX does't work with an active USB cable (5 m)
@baltic-tea
See the following post:
https://github.com/openwrt/mt76/issues/839
That post is by @zerbea . That location is the downstream OpenWRT repo for mt76. Zerbea knows far more about monitor mode than I do and we were talking. We both think it is time to try to get some eyes on the issues in monitor mode.
Subject links:
AliExpress (not official shop; I bought it here - 16$, discount)
OS: Kali Linux 2023.3 [Kernel 6.3.0, Xfce 4.18.4]
Downloaded and installed these MediaTek drivers as advised here by @morrownr:
Problems
The device sometimes stops working (detecting APs) – need to re-plug it in USB port.
CF-953AX in monitor control mode works correctly, but any attempt to capture handshakes by wifite2 on any WiFi point (with WPS or not) is very slow and always ends up with
Failed
status. When cracking WPS I only get fails and a large amount of timeouts (sometimes over 1500). This is true when wardriving any AP with any wifite call options. Often thewifite
gets stuck at some stage, for example, when sending a PIN codes; all kinds of attacks are ineffective.INFO
USB information
Output:
Kernel message buffer on device re-plug.
Output ("-" is errors, "+" is drivers):
Network information
Output:
Statistics in managed mode (wavemon)
Connected to your own WiFi router in the same room.
Screenshot of wavemon output
![CF-953AX_wavemon](https://github.com/morrownr/USB-WiFi/assets/97766478/a14a53a7-9772-4a62-beb2-2eedf45caf09)Kill the conflict processes (NetworkManager.service)
Output:
Switch to monitor control mode
Output:
Check monitor control mode
First step.
Output:
Second step.
Output:
Region and power configuration
Output:
Changing region to BZ (Belize) works correctly.
Output:
Check hcxdumptool
Tool version: hcxdumptool 6.3.1 (C) 2023 ZeroBeat
Output:
Screenshot of hcxdumptool scan loop (empty)
![hcxdumptool -i result](https://github.com/morrownr/USB-WiFi/assets/97766478/6a351b18-13f6-4656-90bd-f260f2c16693)