Closed iyanmv closed 3 years ago
As you noticed correctly this a firmware or driver issue. It is either caused by firmware (I assume this) "Microcode SW error detected." "FW error in SYNC CMD REMOVE_STA"
or by driver "PHY ctxt cmd error."
but not by hcxdumptool "hcxdumptool Not tainted 5.13.13-arch1-1 #1"
There is nothing I can do, except to suggest to report this issue on https://bugzilla.kernel.org/
There have been several several problems running Intel chipsets in the past. So I decided to print a warning in README.md Adapter section https://github.com/ZerBea/hcxdumptool#readme
Not recommended WiFi chipsets:
Intel PRO/Wireless
Broadcom
Realtek RTL8811AU, RTL8812AU, RTL 8814AU (due to NETLINK dependency)
BTW: Running airmon-ng is not a good idea due to NETLINK dependency. airmon-ng is running iw and iw is running NETLINK. You can see this if you enable iw debugging:
$ sudo iw --debug dev wlp0s20f3 set type monitor
which will show you that NETLINK is in use.
Here is an example of the debugging output of iw:
$ sudo iw --debug dev wlp39s0f3u1u1u2 set type monitor
-- Debug: Sent Message:
-------------------------- BEGIN NETLINK MESSAGE ---------------------------
[NETLINK HEADER] 16 octets
.nlmsg_len = 36
.type = 33 <0x21>
.flags = 5 <REQUEST,ACK>
.seq = 1630327873
.port = -1778364009
[GENERIC NETLINK HEADER] 4 octets
.cmd = 6
.version = 0
.unused = 0
[PAYLOAD] 16 octets
08 00 03 00 03 00 00 00 08 00 05 00 06 00 00 00 ................
--------------------------- END NETLINK MESSAGE ---------------------------
-- Debug: Received Message:
-------------------------- BEGIN NETLINK MESSAGE ---------------------------
[NETLINK HEADER] 16 octets
.nlmsg_len = 36
.type = 2 <ERROR>
.flags = 256 <ROOT>
.seq = 1630327873
.port = -1778364009
[ERRORMSG] 20 octets
.error = 0 "Erfolg"
[ORIGINAL MESSAGE] 16 octets
.nlmsg_len = 16
.type = 33 <0x21>
.flags = 5 <REQUEST,ACK>
.seq = 1630327873
.port = -1778364009
--------------------------- END NETLINK MESSAGE ---------------------------
versus hcxdumptool monitor mode via ioctl() system calls:
$ sudo hcxdumptool -m wlp39s0f3u1u1u2
setting interface wlp39s0f3u1u1u2 to monitor mode
hcxdumptool driver test:
$ sudo hcxdumptool -i wlp39s0f3u1u1u2 --check_driver
initialization of hcxdumptool 6.2.0-33-g5297097...
starting driver test...
driver tests passed...
all required ioctl() system calls are supported by driver
terminating...
and hcxdumptool full packet injection test:
$ sudo hcxdumptool -i wlp39s0f3u1u1u2 --check_injection
initialization of hcxdumptool 6.2.0-33-g5297097...
starting antenna test and packet injection test (that can take up to two minutes)...
available channels: 1,2,3,4,5,6,7,8,9,10,11,12,13,14
packet injection is working on 2.4GHz!
injection ratio: 44% (BEACON: 204 PROBERESPONSE: 90)
your injection ratio is average, but there is still room for improvement
antenna ratio: 91% (NETWORK: 34 PROBERESPONSE: 31)
your antenna ratio is huge - say kids what time is it?
terminating...
You can run all three commands and check dmesg after each command to figure out what happened. Do not use airmon-ng or iw before the test.
Thanks for the help! I guess I will open first a bug report in Arch, as recommended in https://bugzilla.kernel.org/, and if they tell me to open a bug directly at the kernel bugzilla, then I will do that.
Just out of curiosity, why is so bad to use NETLINK instead of ioctl calls?
hcxdumptool/hcxlabtool is running high performance attacks. To control the device, fast system calls are mandatory.
Here is a good explanation: https://www.quora.com/What-are-the-differences-between-netlink-sockets-and-ioctl-calls?share=1
In addition to that, we have to create and evaluate additional NETLINK headers. That produce overhead and will cost CPU cycles which we don't have on a Raspberry Pi.
You mentioned airmon-ng. That let me assume you are familiar with the aircrack-ng suite.
To figure out if the driver has a problem, running NETLINK to init the device you can do the following test: Get aircrack-ng source. Configure aircrack-ng without libnl dependency by passing --disable-libnl to configure Put interface wlp0s20f3 to monitor mode. Then run an injection test by ./aireplay-ng -9 wlp0s20f3 https://www.aircrack-ng.org/doku.php?id=injection_test See aireplay-ng messages and dmesg, what happens.
First of all, thank you very much for keep writing here even though it is clear not a hcxdumptool
issue. I will open a bug in Arch when I have a bit more of time. But for the moment I did what you just told me, and I copy here the outputs:
dmesg
[ 469.638086] device wlp0s20f3mon entered promiscuous mode
[ 471.490675] iwlwifi 0000:00:14.3: Microcode SW error detected. Restarting 0x0.
[ 471.491702] iwlwifi 0000:00:14.3: Start IWL Error Log Dump:
[ 471.491703] iwlwifi 0000:00:14.3: Status: 0x00000040, count: 6
[ 471.491704] iwlwifi 0000:00:14.3: Loaded firmware version: 62.49eeb572.0 QuZ-a0-hr-b0-62.ucode
[ 471.491705] iwlwifi 0000:00:14.3: 0x00004217 | ADVANCED_SYSASSERT
[ 471.491706] iwlwifi 0000:00:14.3: 0x00A022F0 | trm_hw_status0
[ 471.491707] iwlwifi 0000:00:14.3: 0x00000000 | trm_hw_status1
[ 471.491707] iwlwifi 0000:00:14.3: 0x004CAEFE | branchlink2
[ 471.491708] iwlwifi 0000:00:14.3: 0x000015E2 | interruptlink1
[ 471.491709] iwlwifi 0000:00:14.3: 0x000015E2 | interruptlink2
[ 471.491709] iwlwifi 0000:00:14.3: 0x044E00B4 | data1
[ 471.491710] iwlwifi 0000:00:14.3: 0x00000010 | data2
[ 471.491710] iwlwifi 0000:00:14.3: 0xDEADBEEF | data3
[ 471.491711] iwlwifi 0000:00:14.3: 0x00000000 | beacon time
[ 471.491711] iwlwifi 0000:00:14.3: 0x013E8CC1 | tsf low
[ 471.491712] iwlwifi 0000:00:14.3: 0x00000000 | tsf hi
[ 471.491712] iwlwifi 0000:00:14.3: 0x00000000 | time gp1
[ 471.491713] iwlwifi 0000:00:14.3: 0x013EF3EE | time gp2
[ 471.491713] iwlwifi 0000:00:14.3: 0x00000001 | uCode revision type
[ 471.491714] iwlwifi 0000:00:14.3: 0x0000003E | uCode version major
[ 471.491714] iwlwifi 0000:00:14.3: 0x49EEB572 | uCode version minor
[ 471.491715] iwlwifi 0000:00:14.3: 0x00000351 | hw version
[ 471.491716] iwlwifi 0000:00:14.3: 0x00489004 | board version
[ 471.491716] iwlwifi 0000:00:14.3: 0x0103001C | hcmd
[ 471.491717] iwlwifi 0000:00:14.3: 0x00020000 | isr0
[ 471.491717] iwlwifi 0000:00:14.3: 0x00000000 | isr1
[ 471.491718] iwlwifi 0000:00:14.3: 0x08F00002 | isr2
[ 471.491718] iwlwifi 0000:00:14.3: 0x00C20008 | isr3
[ 471.491719] iwlwifi 0000:00:14.3: 0x00000000 | isr4
[ 471.491719] iwlwifi 0000:00:14.3: 0x0103001C | last cmd Id
[ 471.491720] iwlwifi 0000:00:14.3: 0x000146F8 | wait_event
[ 471.491720] iwlwifi 0000:00:14.3: 0x00000080 | l2p_control
[ 471.491721] iwlwifi 0000:00:14.3: 0x00000020 | l2p_duration
[ 471.491721] iwlwifi 0000:00:14.3: 0x0000003F | l2p_mhvalid
[ 471.491722] iwlwifi 0000:00:14.3: 0x00008000 | l2p_addr_match
[ 471.491722] iwlwifi 0000:00:14.3: 0x00000009 | lmpm_pmg_sel
[ 471.491723] iwlwifi 0000:00:14.3: 0x00000000 | timestamp
[ 471.491723] iwlwifi 0000:00:14.3: 0x00002064 | flow_handler
[ 471.492304] iwlwifi 0000:00:14.3: Start IWL Error Log Dump:
[ 471.492305] iwlwifi 0000:00:14.3: Status: 0x00000040, count: 7
[ 471.492306] iwlwifi 0000:00:14.3: 0x20000070 | NMI_INTERRUPT_LMAC_FATAL
[ 471.492307] iwlwifi 0000:00:14.3: 0x00000000 | umac branchlink1
[ 471.492307] iwlwifi 0000:00:14.3: 0x80454C8A | umac branchlink2
[ 471.492308] iwlwifi 0000:00:14.3: 0x80473A88 | umac interruptlink1
[ 471.492308] iwlwifi 0000:00:14.3: 0x80473A88 | umac interruptlink2
[ 471.492309] iwlwifi 0000:00:14.3: 0x00000400 | umac data1
[ 471.492310] iwlwifi 0000:00:14.3: 0x80473A88 | umac data2
[ 471.492310] iwlwifi 0000:00:14.3: 0x00000000 | umac data3
[ 471.492311] iwlwifi 0000:00:14.3: 0x0000003E | umac major
[ 471.492311] iwlwifi 0000:00:14.3: 0x49EEB572 | umac minor
[ 471.492312] iwlwifi 0000:00:14.3: 0x013EF40B | frame pointer
[ 471.492312] iwlwifi 0000:00:14.3: 0xC0886270 | stack pointer
[ 471.492313] iwlwifi 0000:00:14.3: 0x00250108 | last host cmd
[ 471.492313] iwlwifi 0000:00:14.3: 0x00000000 | isr status reg
[ 471.492433] iwlwifi 0000:00:14.3: IML/ROM dump:
[ 471.492433] iwlwifi 0000:00:14.3: 0x00000003 | IML/ROM error/state
[ 471.492520] iwlwifi 0000:00:14.3: 0x000060F0 | IML/ROM data1
[ 471.492609] iwlwifi 0000:00:14.3: 0x00000080 | IML/ROM WFPM_AUTH_KEY_0
[ 471.492652] iwlwifi 0000:00:14.3: Fseq Registers:
[ 471.492675] iwlwifi 0000:00:14.3: 0x20000000 | FSEQ_ERROR_CODE
[ 471.492698] iwlwifi 0000:00:14.3: 0x80290033 | FSEQ_TOP_INIT_VERSION
[ 471.492719] iwlwifi 0000:00:14.3: 0x00090006 | FSEQ_CNVIO_INIT_VERSION
[ 471.492741] iwlwifi 0000:00:14.3: 0x0000A482 | FSEQ_OTP_VERSION
[ 471.492763] iwlwifi 0000:00:14.3: 0x00000003 | FSEQ_TOP_CONTENT_VERSION
[ 471.492785] iwlwifi 0000:00:14.3: 0x4552414E | FSEQ_ALIVE_TOKEN
[ 471.492807] iwlwifi 0000:00:14.3: 0x20000302 | FSEQ_CNVI_ID
[ 471.492829] iwlwifi 0000:00:14.3: 0x01300504 | FSEQ_CNVR_ID
[ 471.492850] iwlwifi 0000:00:14.3: 0x20000302 | CNVI_AUX_MISC_CHIP
[ 471.492874] iwlwifi 0000:00:14.3: 0x01300504 | CNVR_AUX_MISC_CHIP
[ 471.492899] iwlwifi 0000:00:14.3: 0x05B0905B | CNVR_SCU_SD_REGS_SD_REG_DIG_DCDC_VTRIM
[ 471.492924] iwlwifi 0000:00:14.3: 0x0000025B | CNVR_SCU_SD_REGS_SD_REG_ACTIVE_VDIG_MIRROR
[ 471.494580] iwlwifi 0000:00:14.3: WRT: Collecting data: ini trigger 4 fired (delay=0ms).
[ 471.494582] ieee80211 phy0: Hardware restart was requested
[ 477.917793] iwlwifi 0000:00:14.3: Microcode SW error detected. Restarting 0x0.
[ 477.919116] iwlwifi 0000:00:14.3: Start IWL Error Log Dump:
[ 477.919118] iwlwifi 0000:00:14.3: Status: 0x00000040, count: 6
[ 477.919122] iwlwifi 0000:00:14.3: Loaded firmware version: 62.49eeb572.0 QuZ-a0-hr-b0-62.ucode
[ 477.919125] iwlwifi 0000:00:14.3: 0x00004217 | ADVANCED_SYSASSERT
[ 477.919128] iwlwifi 0000:00:14.3: 0x00A0A210 | trm_hw_status0
[ 477.919130] iwlwifi 0000:00:14.3: 0x00000000 | trm_hw_status1
[ 477.919132] iwlwifi 0000:00:14.3: 0x004CAEFE | branchlink2
[ 477.919134] iwlwifi 0000:00:14.3: 0x000015E2 | interruptlink1
[ 477.919136] iwlwifi 0000:00:14.3: 0x000015E2 | interruptlink2
[ 477.919138] iwlwifi 0000:00:14.3: 0x044E00B4 | data1
[ 477.919140] iwlwifi 0000:00:14.3: 0x00000010 | data2
[ 477.919142] iwlwifi 0000:00:14.3: 0xDEADBEEF | data3
[ 477.919144] iwlwifi 0000:00:14.3: 0x00000000 | beacon time
[ 477.919146] iwlwifi 0000:00:14.3: 0x0003434E | tsf low
[ 477.919148] iwlwifi 0000:00:14.3: 0x00000000 | tsf hi
[ 477.919149] iwlwifi 0000:00:14.3: 0x00000000 | time gp1
[ 477.919151] iwlwifi 0000:00:14.3: 0x0003AAEC | time gp2
[ 477.919153] iwlwifi 0000:00:14.3: 0x00000001 | uCode revision type
[ 477.919155] iwlwifi 0000:00:14.3: 0x0000003E | uCode version major
[ 477.919157] iwlwifi 0000:00:14.3: 0x49EEB572 | uCode version minor
[ 477.919159] iwlwifi 0000:00:14.3: 0x00000351 | hw version
[ 477.919160] iwlwifi 0000:00:14.3: 0x00489004 | board version
[ 477.919162] iwlwifi 0000:00:14.3: 0x0100001C | hcmd
[ 477.919164] iwlwifi 0000:00:14.3: 0x24020000 | isr0
[ 477.919166] iwlwifi 0000:00:14.3: 0x00000080 | isr1
[ 477.919168] iwlwifi 0000:00:14.3: 0x08F00002 | isr2
[ 477.919169] iwlwifi 0000:00:14.3: 0x00C3200C | isr3
[ 477.919171] iwlwifi 0000:00:14.3: 0x00000000 | isr4
[ 477.919173] iwlwifi 0000:00:14.3: 0x0100001C | last cmd Id
[ 477.919175] iwlwifi 0000:00:14.3: 0x000146F8 | wait_event
[ 477.919176] iwlwifi 0000:00:14.3: 0x000000D4 | l2p_control
[ 477.919178] iwlwifi 0000:00:14.3: 0x00010034 | l2p_duration
[ 477.919180] iwlwifi 0000:00:14.3: 0x00000007 | l2p_mhvalid
[ 477.919182] iwlwifi 0000:00:14.3: 0x00000000 | l2p_addr_match
[ 477.919184] iwlwifi 0000:00:14.3: 0x00000009 | lmpm_pmg_sel
[ 477.919185] iwlwifi 0000:00:14.3: 0x00000000 | timestamp
[ 477.919187] iwlwifi 0000:00:14.3: 0x00001858 | flow_handler
[ 477.919680] iwlwifi 0000:00:14.3: Start IWL Error Log Dump:
[ 477.919682] iwlwifi 0000:00:14.3: Status: 0x00000040, count: 7
[ 477.919684] iwlwifi 0000:00:14.3: 0x20000070 | NMI_INTERRUPT_LMAC_FATAL
[ 477.919686] iwlwifi 0000:00:14.3: 0x00000000 | umac branchlink1
[ 477.919688] iwlwifi 0000:00:14.3: 0x80454C8A | umac branchlink2
[ 477.919690] iwlwifi 0000:00:14.3: 0xC0084D6C | umac interruptlink1
[ 477.919692] iwlwifi 0000:00:14.3: 0x0102E2D2 | umac interruptlink2
[ 477.919694] iwlwifi 0000:00:14.3: 0x00000400 | umac data1
[ 477.919696] iwlwifi 0000:00:14.3: 0x0102E2D2 | umac data2
[ 477.919698] iwlwifi 0000:00:14.3: 0x00000000 | umac data3
[ 477.919699] iwlwifi 0000:00:14.3: 0x0000003E | umac major
[ 477.919701] iwlwifi 0000:00:14.3: 0x49EEB572 | umac minor
[ 477.919703] iwlwifi 0000:00:14.3: 0x0003AB11 | frame pointer
[ 477.919705] iwlwifi 0000:00:14.3: 0xC08874E0 | stack pointer
[ 477.919706] iwlwifi 0000:00:14.3: 0x00190207 | last host cmd
[ 477.919708] iwlwifi 0000:00:14.3: 0x00000000 | isr status reg
[ 477.919931] iwlwifi 0000:00:14.3: IML/ROM dump:
[ 477.919933] iwlwifi 0000:00:14.3: 0x00000003 | IML/ROM error/state
[ 477.919953] iwlwifi 0000:00:14.3: 0x000061CF | IML/ROM data1
[ 477.919963] iwlwifi 0000:00:14.3: 0x00000080 | IML/ROM WFPM_AUTH_KEY_0
[ 477.920018] iwlwifi 0000:00:14.3: Fseq Registers:
[ 477.920043] iwlwifi 0000:00:14.3: 0x20000000 | FSEQ_ERROR_CODE
[ 477.920069] iwlwifi 0000:00:14.3: 0x80290033 | FSEQ_TOP_INIT_VERSION
[ 477.920095] iwlwifi 0000:00:14.3: 0x00090006 | FSEQ_CNVIO_INIT_VERSION
[ 477.920121] iwlwifi 0000:00:14.3: 0x0000A482 | FSEQ_OTP_VERSION
[ 477.920147] iwlwifi 0000:00:14.3: 0x00000003 | FSEQ_TOP_CONTENT_VERSION
[ 477.920172] iwlwifi 0000:00:14.3: 0x4552414E | FSEQ_ALIVE_TOKEN
[ 477.920198] iwlwifi 0000:00:14.3: 0x20000302 | FSEQ_CNVI_ID
[ 477.920225] iwlwifi 0000:00:14.3: 0x01300504 | FSEQ_CNVR_ID
[ 477.920251] iwlwifi 0000:00:14.3: 0x20000302 | CNVI_AUX_MISC_CHIP
[ 477.920279] iwlwifi 0000:00:14.3: 0x01300504 | CNVR_AUX_MISC_CHIP
[ 477.920308] iwlwifi 0000:00:14.3: 0x05B0905B | CNVR_SCU_SD_REGS_SD_REG_DIG_DCDC_VTRIM
[ 477.920364] iwlwifi 0000:00:14.3: 0x0000025B | CNVR_SCU_SD_REGS_SD_REG_ACTIVE_VDIG_MIRROR
[ 477.920520] iwlwifi 0000:00:14.3: WRT: Collecting data: ini trigger 4 fired (delay=0ms).
[ 477.920529] ieee80211 phy0: Hardware restart was requested
aireplay-ng -9
18:35:57 Trying broadcast probe requests...
18:35:59 No Answer...
18:35:59 Found 1 AP
18:35:59 Trying directed probe requests...
18:35:59 FC:4A:E9:70:A9:32 - channel: 10 - 'Kablonet Netmaster-A92D-G'
18:36:05 0/30: 0%
Do you see anything relevant in the dmesg that I should highlight in the bug reports in Arch/kernel?
By the way, I remember doing the same test when I got the laptop and I was getting 100% almost all the times. Also, aireplay-ng --deauth
was working perfectly and now it doesn't, so I would say that currently injection is broken for AX201.
Thanks for sharing your test results. As you can see, if aircrack-ng is compiled without libnl, packet injection is not working running AX201 driver :
18:35:59 No Answer...
and
18:36:05 0/30: 0%
Looks like init of the driver via NETLINK isn't completely done.
I've seen this problem on Realtek drivers, too: https://github.com/aircrack-ng/rtl8812au/issues/376#issuecomment-526120499
Now I was able to totally crashed the laptop by running hcxdumptool -i wlp0s20f3 -s 1 --do_rcascan
. The caps lock key led started to blink (I have to figure out what this means from Lenovo docs) and the system was totally unresponsive so I had to force a reboot by keep pressing the power button.
That sounds not good. The iwlwifi driver need to be fixed. There are lots of similar reports: https://ask.fedoraproject.org/t/intel-r-wi-fi-6-ax201-driver-always-crashing-iwlwifi/10728 https://ask.fedoraproject.org/t/iwlwifi-driver-randomly-crashes-inoperable-until-reboot/12672 https://community.intel.com/t5/Wireless/iwlwifi-driver-randomly-crashes-in-Linux/m-p/643389 https://askubuntu.com/questions/1219893/iwlwifi-driver-crashing
I think, we can close this issue, because it is related to the broken driver.
Just for future reference, if someone is reading this closed issue. I open a bug report at the kernel bugzilla. Here is the link: https://bugzilla.kernel.org/show_bug.cgi?id=214291
Good idea to report this issue on bugzilla.kernel.org. I suspect, the issue is related to INTEL MICROCODE.
@ZerBea thanks for keeping the discussion upstream, I thought I was not going to hear from Intel at this point.
I'm interested hat caused the driver to crash (channel change or packet injection). Can you please comment output of $ sudo hcxdumptool -i interface -C to get a frequency list reported from the device as I did here https://bugzilla.kernel.org/show_bug.cgi?id=214291#c7
If a take a look at the regulatory domain:
$ iw reg get
global
country US: DFS-FCC
(2400 - 2472 @ 40), (N/A, 30), (N/A)
(5150 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5350 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5470 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5730 - 5850 @ 80), (N/A, 30), (N/A), AUTO-BW
(5850 - 5895 @ 40), (N/A, 27), (N/A), NO-OUTDOOR, AUTO-BW, PASSIVE-SCAN
(57240 - 71000 @ 2160), (N/A, 40), (N/A)
All displayed frequencies here: https://bugzilla.kernel.org/show_bug.cgi?id=214291#c7 are within this frequency ranges. That include the legal tx power, too
I don't get any available channels:
# hcxdumptool -i wlp0s20f3 -C
initialization of hcxdumptool 6.2.4...
available channels:
terminating...
Thanks. It looks like ioctl(SIOCSIWFREQ) failed.
To find out which ioctl() is working and which is damaged, please use iw to set monitor mode: $ sudo ip link set dev INTERFACE down $ sudo iw dev INTERFACE set type monitor $ sudo ip link set dev INTERFACE up
Than do a driver test: $ sudo hcxdumptool -i INTERFACE --check_driver
Followed by an injection test $ sudo hcxdumptool -i INTERFACE --check_injection
iw use NETLINK to set monitor mode instead of an ioctl() system call. If that will work, we can assume that this driver is not fully init by ioctl() system calls (which is a driver bug, too).
[root@thinkpad ~]# ip link set dev wlp0s20f3 down
[root@thinkpad ~]# iw dev wlp0s20f3 set type monitor
[root@thinkpad ~]# ip link set dev wlp0s20f3 up
[root@thinkpad ~]# hcxdumptool -i wlp0s20f3 --check_driver
initialization of hcxdumptool 6.2.4...
starting driver test...
interface is already in monitor mode, skipping ioctl(SIOCSIWMODE) and ioctl(SIOCSIFFLAGS) system calls
driver tests passed...
all required ioctl() system calls are supported by driver
terminating...
[root@thinkpad ~]# hcxdumptool -i wlp0s20f3 --check_injection
initialization of hcxdumptool 6.2.4...
interface is already in monitor mode, skipping ioctl(SIOCSIWMODE) and ioctl(SIOCSIFFLAGS) system calls
channel 1 not available
starting antenna test and packet injection test (that can take up to two minutes)...
available channels: 2,3,4,5,6,7,8,9,10,11,12,13,40,44,48,52,56,60,64,112,116,120,124,128,132,136,140,144,149,153,157,161,165
packet injection is working on 2.4GHz!
injection ratio: 94% (BEACON: 138 PROBERESPONSE: 130)
your injection ratio is huge - say kids what time is it?
antenna ratio: 28% (NETWORK: 21 PROBERESPONSE: 6)
your antenna ratio is average, but there is still room for improvement
terminating...
[root@thinkpad ~]# hcxdumptool -i wlp0s20f3 -C
initialization of hcxdumptool 6.2.4...
interface is already in monitor mode, skipping ioctl(SIOCSIWMODE) and ioctl(SIOCSIFFLAGS) system calls
available channels:
terminating...
I rebooted the laptop before doing this, just to be sure that NETLINK is not used.
[root@thinkpad ~]# hcxdumptool -m wlp0s20f3
setting interface wlp0s20f3 to monitor mode
[root@thinkpad ~]# hcxdumptool -i wlp0s20f3 --check_driver
initialization of hcxdumptool 6.2.4...
starting driver test...
interface is already in monitor mode, skipping ioctl(SIOCSIWMODE) and ioctl(SIOCSIFFLAGS) system calls
driver tests passed...
all required ioctl() system calls are supported by driver
terminating...
[root@thinkpad ~]# hcxdumptool -i wlp0s20f3 --check_injection
initialization of hcxdumptool 6.2.4...
interface is already in monitor mode, skipping ioctl(SIOCSIWMODE) and ioctl(SIOCSIFFLAGS) system calls
starting antenna test and packet injection test (that can take up to two minutes)...
available channels: 1,2,3,4,5,6,7,8,9,10,11,12,13,60,64
packet injection is working on 2.4GHz!
injection ratio: 100% (BEACON: 56 PROBERESPONSE: 614)
your injection ratio is huge - say kids what time is it?
antenna ratio: 83% (NETWORK: 12 PROBERESPONSE: 10)
your antenna ratio is excellent, let's ride!
terminating...
[root@thinkpad ~]# hcxdumptool -i wlp0s20f3 -C
initialization of hcxdumptool 6.2.4...
interface is already in monitor mode, skipping ioctl(SIOCSIWMODE) and ioctl(SIOCSIFFLAGS) system calls
available channels:
terminating...
Thanks for the test. It looks like the driver need NETLINK to set monitor mode and to bring the interface up - otherwise the interface will not be init completely available channels by NETLINK init: 2,3,4,5,6,7,8,9,10,11,12,13,40,44,48,52,56,60,64,112,116,120,124,128,132,136,140,144,149,153,157,161,165 versus ioctl() init: available channels: 1,2,3,4,5,6,7,8,9,10,11,12,13,60,64 ... than the driver crashed
I pushed an update. Please do a git pull, compile and comment output of $ hcxdumptool -i wlp0s20f3 -C
BTW: Can I send you a mail to the addr mentioned here: https://github.com/iyanmv
Here it is. Ignore the warning about NetworkManager, I added the wireless device on /etc/NetworkManager/conf.d/unmanaged.conf
# ./hcxdumptool -i wlp0s20f3 -C
initialization of hcxdumptool 6.2.5-6-g5739c87...
warning possible interfere: NetworkManager is running with pid 20254
wlp0s20f3 available frequencies, channels and tx power reported by driver:
2412MHz 1 (-2147483648 dBm)
2417MHz 2 (-2147483648 dBm)
2422MHz 3 (-2147483648 dBm)
2427MHz 4 (-2147483648 dBm)
2432MHz 5 (-2147483648 dBm)
2437MHz 6 (-2147483648 dBm)
2442MHz 7 (-2147483648 dBm)
2447MHz 8 (-2147483648 dBm)
2452MHz 9 (-2147483648 dBm)
2457MHz 10 (-2147483648 dBm)
2462MHz 11 (-2147483648 dBm)
2467MHz 12 (-2147483648 dBm)
2472MHz 13 (-2147483648 dBm)
5200MHz 40 (-2147483648 dBm)
5220MHz 44 (-2147483648 dBm)
5240MHz 48 (-2147483648 dBm)
5260MHz 52 (-2147483648 dBm)
5280MHz 56 (-2147483648 dBm)
5300MHz 60 (-2147483648 dBm)
5320MHz 64 (-2147483648 dBm)
5600MHz 120 (-2147483648 dBm)
5620MHz 124 (-2147483648 dBm)
5640MHz 128 (-2147483648 dBm)
5660MHz 132 (-2147483648 dBm)
5680MHz 136 (-2147483648 dBm)
5700MHz 140 (-2147483648 dBm)
5720MHz 144 (-2147483648 dBm)
5745MHz 149 (-2147483648 dBm)
5765MHz 153 (-2147483648 dBm)
5785MHz 157 (-2147483648 dBm)
5805MHz 161 (-2147483648 dBm)
5825MHz 165 (-2147483648 dBm)
terminating...
BTW: Can I send you a mail to the addr mentioned here: https://github.com/iyanmv
Sure!
Thanks. Many ioctl() system calls give incorrect values or no values. More and more it looks like the driver need NETLINK to work as expected.
In addition to that I noticed plenty of issues reported on this chipset: https://duckduckgo.com/?q=ax201+linux+driver+issue&t=ffab&ia=web
With NETLINK I see that a few more channels appear now (e.g. 36, 100, 104), but some are still missing (e.g. 38, 54). Can this be caused by some regdomain issues?
# ip link set wlp0s20f3 down
# iw wlp0s20f3 set type monitor
# ip link set wlp0s20f3 up
# ./hcxdumptool -i wlp0s20f3 -C
initialization of hcxdumptool 6.2.5-6-g5739c87...
warning possible interfere: NetworkManager is running with pid 634
interface is already in monitor mode, skipping ioctl(SIOCSIWMODE) and ioctl(SIOCSIFFLAGS) system calls
wlp0s20f3 available frequencies, channels and tx power reported by driver:
2412MHz 1 (-2147483648 dBm)
2417MHz 2 (-2147483648 dBm)
2422MHz 3 (-2147483648 dBm)
2427MHz 4 (-2147483648 dBm)
2432MHz 5 (-2147483648 dBm)
2437MHz 6 (-2147483648 dBm)
2442MHz 7 (-2147483648 dBm)
2447MHz 8 (-2147483648 dBm)
2452MHz 9 (-2147483648 dBm)
2457MHz 10 (-2147483648 dBm)
2462MHz 11 (-2147483648 dBm)
2467MHz 12 (-2147483648 dBm)
2472MHz 13 (-2147483648 dBm)
5180MHz 36 (-2147483648 dBm)
5200MHz 40 (-2147483648 dBm)
5220MHz 44 (-2147483648 dBm)
5240MHz 48 (-2147483648 dBm)
5260MHz 52 (-2147483648 dBm)
5280MHz 56 (-2147483648 dBm)
5300MHz 60 (-2147483648 dBm)
5320MHz 64 (-2147483648 dBm)
5500MHz 100 (-2147483648 dBm)
5520MHz 104 (-2147483648 dBm)
5540MHz 108 (-2147483648 dBm)
5560MHz 112 (-2147483648 dBm)
5580MHz 116 (-2147483648 dBm)
5600MHz 120 (-2147483648 dBm)
5620MHz 124 (-2147483648 dBm)
5640MHz 128 (-2147483648 dBm)
5660MHz 132 (-2147483648 dBm)
5680MHz 136 (-2147483648 dBm)
5700MHz 140 (-2147483648 dBm)
5720MHz 144 (-2147483648 dBm)
5745MHz 149 (-2147483648 dBm)
5765MHz 153 (-2147483648 dBm)
5785MHz 157 (-2147483648 dBm)
5805MHz 161 (-2147483648 dBm)
5825MHz 165 (-2147483648 dBm)
terminating...
No, I don't think that it is related to the regulatory domain. It should not happen that the driver reports different channels/frequencies depending on how the monitor mode was set: less channels if monitor mode set by ioctl()
iwr.u.mode = IW_MODE_MONITOR;
if(ioctl(fd_socket, SIOCSIWMODE, &iwr) < 0)
versus more frequencies/channels if monitor mode set by iw using NETLINK. Except of RTL8812AU and RTL8814AU (both depend on NETLINK) none of the tested drivers showing this behavior.
Can you please test hcxlabtool which use NL80211 and RTNETLINK instead of WIRELESS EXTENSIONS): https://github.com/ZerBea/wifi_laboratory
$ make $ ./hcxlabtool -I interfacename
Thanks.
$ ./hcxlabtool -I wlp0s20f3
available wlan devices:
phy idx hw-mac virtual-mac m ifname driver (protocol)
---------------------------------------------------------------------------------------------
0 2 0456e5e5c112 0456e5e5c112 + wlp0s20f3 iwlwifi (NETLINK & WIRELESS EXTENSIONS)
+ monitor mode available
- no monitor mode available
available frequencies: frequency [channel] tx-power
2412 [ 1] 22.0 dBm 2417 [ 2] 22.0 dBm 2422 [ 3] 22.0 dBm 2427 [ 4] 22.0 dBm
2432 [ 5] 22.0 dBm 2437 [ 6] 22.0 dBm 2442 [ 7] 22.0 dBm 2447 [ 8] 22.0 dBm
2452 [ 9] 22.0 dBm 2457 [ 10] 22.0 dBm 2462 [ 11] 22.0 dBm 2467 [ 12] 22.0 dBm
2472 [ 13] 22.0 dBm 2484 [ 14] disabled 5180 [ 36] 22.0 dBm 5200 [ 40] 22.0 dBm
5220 [ 44] 22.0 dBm 5240 [ 48] 22.0 dBm 5260 [ 52] 22.0 dBm 5280 [ 56] 22.0 dBm
5300 [ 60] 22.0 dBm 5320 [ 64] 22.0 dBm 5340 [ 68] disabled 5360 [ 72] disabled
5380 [ 76] disabled 5400 [ 80] disabled 5420 [ 84] disabled 5440 [ 88] disabled
5460 [ 92] disabled 5480 [ 96] disabled 5500 [100] 22.0 dBm 5520 [104] 22.0 dBm
5540 [108] 22.0 dBm 5560 [112] 22.0 dBm 5580 [116] 22.0 dBm 5600 [120] 22.0 dBm
5620 [124] 22.0 dBm 5640 [128] 22.0 dBm 5660 [132] 22.0 dBm 5680 [136] 22.0 dBm
5700 [140] 22.0 dBm 5720 [144] 22.0 dBm 5745 [149] 22.0 dBm 5765 [153] 22.0 dBm
5785 [157] 22.0 dBm 5805 [161] 22.0 dBm 5825 [165] 22.0 dBm 5845 [169] disabled
5865 [173] disabled 5885 [177] disabled 5905 [181] disabled
bye-bye
Great, thanks. Now hcxlabtool should work on this driver.
BTW: This "5905 [181] disabled" is related to your wireless regulatory domain settings. https://github.com/aircrack-ng/aircrack-ng/discussions/2430#discussioncomment-5023204
Great! And what about hcxdumptool?
hcxdumptool is a dinosaur (due to WIRLESS EXTENSION dependency) and it is acting like a toothless tiger (too many features that slow it down). hcxlabtool will be the successor due to full NETLINK/RTNETLINK support. With hcxlabtool I'm going back to the roots and set focus on ultra fast and effective layer 2 attack vectors.
The maintainer of iwlwifi told that WIRELESS EXTENSION are no longer supported.
Simply run $ sudo hcxlabtool and see what will happen.
Hi @ZerBea
I missed your last comment on the kernel bugzilla but I have just tried version 6.3.0 (which I think it includes the changes to NL80211) and I can still crash my laptop.
What else do you suggest me to try? Should I continue the conversation in the kernel bug now that you have removed WEXT completely?
SInce v6.3.0 WEXT is completely removed and replaced by RTNETLINK and NL80211 (as suggested by the iwlwifi driver maintainer). According to this https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi packet injection is not mentioned (only sniffer mode).
or this https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi#about_the_monitorsniffer_mode "This will put lots of pressure on the memory subsystem, but it will allow you to hear 12K long packets. You may see firmware crashes in case you didn't set that module parameter. "
it looks like this chipset/driver is not the best choice to be used as a penetration testing device.
BTW: There are a lot of problems with this chipset: https://duckduckgo.com/?q=ax201+crash&t=ffab&ia=web
I think it is the best to do the conversion on bugzilla, because there is nothing I can do. MediaTek, Ralink, Realtek and Atheros drivers are working fine, so I still suspect an iwlwifi driver issue.
Looks like the driver is broken: https://github.com/ZerBea/hcxdumptool/commit/4ba9d5bad5dd48e77532d22243d2e57d02a4d6fb
Bugzilla report: https://bugzilla.kernel.org/show_bug.cgi?id=217051
Hi,
I think when I bought the new Lenovo Thinkpad X1 Yoga (Gen 6) I was able to use
hcxdumptool
without any issues. Now, after a few months using the laptop, when I tried again, I got many driver errors and it seems like injection is not working as good as before. Of course, in the meantime there have been BIOS updates, kernel updates, firmware updates... so it's hard for me to debug this.Maybe here someone can help me to debug and try to find the real issue here, and open a bug in the proper project upstream (Lenovo support, linux kernel, iwlwifi...).
This laptop has an Intel AX201 chipset. Please let me know what logs or information would be useful to share here and I will try to share as soon as possible. For the moment I copy-paste what I see in
dmesg
error messages when I callhcxdumptool
.By the way, I am running Arch Linux, and I tried with official pacakges
linux
(5.13.13) andlinux-lts
(5.10.61), as well as compiled linux-mainline (5.14.0). With all I get similar error messages.I also realized that initialization phase takes too long and it puts one core to work 100% for a few seconds. I don't think that was the case in the past, and using
airmon-ng
to enable monitor mode seems to work better for me now.