Doesn't work on qcacld3.0 driver (not part of the Linux kernel)

[spiral009]

 # echo 4 > /sys/module/wlan/parameters/con_mode
# hcxdumptool -i  wlan0                                                          
Requesting interface capabilities. This may take some time.
Please be patient...

failed to arm interface
2 errors during runtime 
bye-bye

I know that Qualcomm Is listed as unrecommened because of no packet Injection , but that doesn't prevent it from capturing pmkid right?

[ZerBea]

hcxdumptool is an interactive tool. There is no single receive only mode. The driver must support full monitor mode and full packet injection via RTNETLINK and NL80211 as well as channel management via NL80211.

That is not he case, e.g.: https://unix.stackexchange.com/questions/709392/does-qualcomm-qca9377-support-packet-injection https://developer.qualcomm.com/forum/qdn-forums/hardware/qca9377/34827

I don' see a way that hcxdumptool will work on this driver.

[ZerBea]

To record WiFi traffic, use iw to set requency and tshark to record mandatory frames:

$ tshark -i wlp22s0f0u9u3 -w dump.pcapng "wlan type mgt subtype assoc-req or wlan type mgt subtype reassoc-req or wlan type mgt subtype probe-resp or wlan type mgt subtype probe-req or ether proto 0x888e"
Capturing on 'wlp22s0f0u9u3'
 ** (tshark:9896) 12:43:10.316529 [Main MESSAGE] -- Capture started.
 ** (tshark:9896) 12:43:10.316610 [Main MESSAGE] -- File: "dump.pcapng"
44 ^C
tshark: 

hcxpcapngtool will work on the dump file (dump.pcapng).

[ZerBea]

I think we can close this, because the driver doesn't support to set monitor mode by NL80211. Instead it use its own mode: echo 4 > /sys/module/wlan/parameters/con_mode

Also it doesn't support full packet injection:

Known bugs/limitations

firmware does not support association to the same AP from different virtual STA interfaces (driver prints “ath10k: Failed to add peer XX:XX:XX:XX:XX:XX for VDEV: X” in that case)

packet injection isn't supported yet

applying ath9k regulatory domain hack patch from OpenWRT causes firmware crash (reason: regulatory hint function is never called and ath10k never sends scan channel list to the firmware which in turn causes firmware to crash on scan)

tx rate is reported as 6mbps due to firmware limitation (no tx rate information in tx completions); instead see /sys/kernel/debug/ieee80211/phyX/ath10k/fw_stats

WEP doesn't work with AP_VLANs - frames are sent unencrypted (observed on: 999.999.0.636, 10.2.4.20-1, 10.1.467.2-1)

TX speeds are extremely poor on certain chips (QCA6174 is one). A patch (https://gist.github.com/harrykipper/d1bedb234c4af0692f7ccd33329a02d7) solves the issue in most cases (https://bbs.archlinux.org/viewtopic.php?pid=1689990#p1689990))

https://wireless.wiki.kernel.org/en/users/Drivers/ath10k

[spiral009]

Well it's a qcacld3.0 qca6390 and I can send deauth packets in aireplay-ng but must run airodump-ng in another session

[ZerBea]

We can try this: Search for this line: if(nl_set_monitormode() == false) return false;

and comment it: # if(nl_set_monitormode() == false) return false;

recompile hcxdumptool

set monitor mode by qualcomm echo 4 > /sys/module/wlan/parameters/con_mode

and run hcxdumptool.

This is the function where we arm the interface: https://github.com/ZerBea/hcxdumptool/blob/master/hcxdumptool.c#L3689

[ZerBea]

It is mandatory that the driver support NL80211, To discover what NL80211 features are supported you can monitor this by nlmon:

activate nlmon: $ sudo ip link add nlmon0 type nlmon $ sudo ip link set dev nlmon0 up

run Wireshark and capture traffic from nlmon run $ hcxdumptool -L $ hcxdumptool -I your_wlan_interface

stop hcxdumptool stop Wireshark capturing and save the dump file add the dump file here.

[ZerBea]

BTW: hcxdumptool transmit several different types of frames because it does complete AUTHENTICATIONs with APs and CLIENTs. Additional it has a channel management. All this is done via RTNETLINK and NL80211 messages. The driver must support that.

[ZerBea]

BTW: Please comment the output of $ hcxdumptool -L and $ hcxdumptool -I your_wlan_interface

This are NETLINK requests to retrieve the features of the driver/interface.

If the driver support NETLINK, output on first request should look like this:

$ hcxdumptool -L

Requesting physical interface capabilities. This may take some time.
Please be patient...

available wlan devices:

phy idx hw-mac       virtual-mac  m ifname           driver (protocol)
---------------------------------------------------------------------------------------------
  0   3 74da38e125fc 74da38e125fc * wlp22s0f0u4      mt7601u (NETLINK)

* active monitor mode available
+ monitor mode available
- no monitor mode available

bye-bye

and on second request like this:

$ hcxdumptool -I wlp22s0f0u4

Requesting physical interface capabilities. This may take some time.
Please be patient...

interface information:

phy idx hw-mac       virtual-mac  m ifname           driver (protocol)
---------------------------------------------------------------------------------------------
  0   3 74da38e125fc 74da38e125fc * wlp22s0f0u4      mt7601u (NETLINK)

available frequencies: frequency [channel] tx-power of Regulatory Domain: DE

  2412 [  1] 20.0 dBm     2417 [  2] 20.0 dBm     2422 [  3] 20.0 dBm     2427 [  4] 20.0 dBm
  2432 [  5] 20.0 dBm     2437 [  6] 20.0 dBm     2442 [  7] 20.0 dBm     2447 [  8] 20.0 dBm
  2452 [  9] 20.0 dBm     2457 [ 10] 20.0 dBm     2462 [ 11] 20.0 dBm     2467 [ 12] 20.0 dBm
  2472 [ 13] 20.0 dBm

bye-bye

[ZerBea]

Well it's a qcacld3.0 qca6390 and I can send deauth packets in aireplay-ng but must run airodump-ng in another session

That explains a lot, because it is not a native Linux driver provided by the Linux kernel.

[ZerBea]

You may have noticed that I changed the head line. Problem is the driver,

[ZerBea]

Looks like there are some more problems on this driver: https://github.com/ZerBea/hcxdumptool/issues/251 https://github.com/aircrack-ng/aircrack-ng/issues/2179 https://github.com/kimocoder/qualcomm_android_monitor_mode/issues/55 https://github.com/kimocoder/qualcomm_android_monitor_mode/issues/53 https://github.com/kimocoder/qualcomm_android_monitor_mode/issues/50 https://github.com/kimocoder/qualcomm_android_monitor_mode/issues/47 https://forum.xda-developers.com/t/kernel-nethunter-for-galaxy-s20-fe-5g-r8q-snapdragon.4205881/

After reading all this, I still don't see a real chance that hcxdumptool will work on this driver.

[spiral009]

I think I need to recompile the kernel with CONFIG_NLMON=y for this to work

# ip link add nlmon0 type nlmon
RTNETLINK answers: Operation not supported on transport endpoint

I did comment and recompiled hcxdumptool

root@localhost:~/hcxdumptool# ./hcxdumptool  -L

Requesting interface capabilities. This may take some time.
Please be patient...

available wlan devices:

phy idx hw-mac       virtual-mac  m ifname           driver (protocol)
---------------------------------------------------------------------------------------------
  0  28 000000000000 00037f12d7fb + wlan0            cnss_pci (NETLINK)

* active monitor mode available                                                                                                      + monitor mode available
- no monitor mode available

bye-bye
root@localhost:~/hcxdumptool# ./hcxdumptool  -i wlan0

Requesting interface capabilities. This may take some time.
Please be patient...

failed to arm interface

2 errors during runtime

bye-bye

And Tshark isn't working

root@localhost:~/hcxdumptool# tshark  -i wlan0
Running as user "root" and group "root". This could be dangerous.
Capturing on 'wlan0'
tshark: Child dumpcap process died: Segmentation violation
0 packets captured

[spiral009]

I do have an external wifi adapter and it does work but I always prefer to use internal interface

[spiral009]

I do have CONFIG_NL80211_TESTMODE=y in the kennel , not sure if it does anything

[ZerBea]

Thanks for the tests. The driver reported that it does support NETLINK and it does have monitor mode.

Attached a special debug version. Please decompress and replace hcxdumptool.c by this version. hcxdumptool.c.zip Than recompile and run hcxdumptool.

Now every call inside the "arm" function got a debug printf. It will show which RTNETLINK or NL80211 command is not supported.

Please comment the output of the debug messages.

[ZerBea]

This 0 28 000000000000 00037f12d7fb + wlan0 cnss_pci (NETLINK) is definitely not good. It shows that at least the RTNETLINK command to retrieve the hardware MAC address failed.

[ZerBea]

There is no longer need to activate nlmon, because we now can do this by the debug printf's mentioned above.

[ZerBea]

I'm very keen to to find out what NL80211 / RTNETLINK message will fail.

[spiral009]

root@localhost:~/hcxdumptool# make
cc -O3 -Wall -Wextra -Wpedantic -std=gnu99   -o hcxdumptool hcxdumptool.c -DVERSION_TAG=\"6.3.1-27-gd462972\" -DVERSION_YEAR=\"2023\" -DSTATUSOUT -DNMEAOUT
hcxdumptool.c:4671:45: error: use of undeclared identifier 'HCX_EXIT_ON_EAPOL'
        {"exitoneapol",                 required_argument,      NULL,   HCX_EXIT_ON_EAPOL},
                                                                        ^
hcxdumptool.c:4809:8: error: use of undeclared identifier 'HCX_EXIT_ON_EAPOL'
                case HCX_EXIT_ON_EAPOL:
                     ^
hcxdumptool.c:4811:41: error: use of undeclared identifier 'EXIT_ON_EAPOL_PMKID'
                exiteapolpmkidflag |= exiteapolflag & EXIT_ON_EAPOL_PMKID;
                                                      ^
hcxdumptool.c:4812:38: error: use of undeclared identifier 'EXIT_ON_EAPOL_M2'
                exiteapolm2flag |= exiteapolflag & EXIT_ON_EAPOL_M2;
                                                   ^
hcxdumptool.c:4813:38: error: use of undeclared identifier 'EXIT_ON_EAPOL_M3'
                exiteapolm3flag |= exiteapolflag & EXIT_ON_EAPOL_M3;
                                                   ^
hcxdumptool.c:5122:22: error: use of undeclared identifier 'EXIT_ON_EAPOL_PMKID'
        if((wanteventflag & EXIT_ON_EAPOL_PMKID) == EXIT_ON_EAPOL_PMKID) fprintf(stdout, "\nexit on PMKID\n");
                            ^
hcxdumptool.c:5122:46: error: use of undeclared identifier 'EXIT_ON_EAPOL_PMKID'
        if((wanteventflag & EXIT_ON_EAPOL_PMKID) == EXIT_ON_EAPOL_PMKID) fprintf(stdout, "\nexit on PMKID\n");
                                                    ^
hcxdumptool.c:5123:22: error: use of undeclared identifier 'EXIT_ON_EAPOL_M2'
        if((wanteventflag & EXIT_ON_EAPOL_M2) == EXIT_ON_EAPOL_M2) fprintf(stdout, "\nexit on EAPOL M1M2\n");
                            ^
hcxdumptool.c:5123:43: error: use of undeclared identifier 'EXIT_ON_EAPOL_M2'
        if((wanteventflag & EXIT_ON_EAPOL_M2) == EXIT_ON_EAPOL_M2) fprintf(stdout, "\nexit on EAPOL M1M2\n");
                                                 ^
hcxdumptool.c:5124:22: error: use of undeclared identifier 'EXIT_ON_EAPOL_M3'
        if((wanteventflag & EXIT_ON_EAPOL_M3) == EXIT_ON_EAPOL_M3) fprintf(stdout, "\nexit on EAPOL M1M2M3\n");
                            ^
hcxdumptool.c:5124:43: error: use of undeclared identifier 'EXIT_ON_EAPOL_M3'
        if((wanteventflag & EXIT_ON_EAPOL_M3) == EXIT_ON_EAPOL_M3) fprintf(stdout, "\nexit on EAPOL M1M2M3\n");
                                                 ^
11 errors generated.
make: *** [Makefile:66: hcxdumptool] Error 1
root@localhost:~/hcxdumptool#

[ZerBea]

You need to do a fresh git clone, before replacing hcxdumptool.c

$ ./hcxdumptool -v
hcxdumptool 6.3.1-30-g1a97430 (C) 2023 ZeroBeat

because there are a lot of changes:

24.07.2023
==========
hcxdumptool: added new option to EXIT on EAPOL
--exitoneapol=<type>           : exit on first EAPOL occurrence:
                                  bitmask:
                                   1 = PMKID
                                   2 = EAPOL M2
                                   4 = EAPOL M3
                                  target BPF filter is recommended
get more information here:
https://github.com/ZerBea/hcxdumptool/issues/333#issuecomment-1647684235

and hcxdumptool.c need the new includes.

[ZerBea]

After some investigations I have a suspect: channel management via NL80211 will fail on that driver. Your comment here is helpful: https://github.com/aircrack-ng/aircrack-ng/discussions/2555 but it need be confirmed by the modified hcxdumptool (nl80211 failed to set frequency)

Additional you can try to set the frequency iw: $ sudo iw dev wlp22s0f0u4 set channel 6 and to get the frequency by iw: $ iw dev

phy#0
    Interface wlp22s0f0u4
        ifindex 3
        wdev 0x1
        addr 74:da:38:e1:25:fc
        type monitor
        channel 6 (2437 MHz), width: 20 MHz (no HT), center1: 2437 MHz
        txpower 20.00 dBm
        multicast TXQ:
            qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes    tx-packets
            0   0   0   0   0   0   0   0       0

hcxdumptool is doing exactly the same like iw, e.g. set frequency to channel 11: $ sudo hcxdumptool -c 11a

success - channel 11 confirmed by iw:

$ iw dev
phy#0
    Interface wlp22s0f0u4
        ifindex 3
        wdev 0x1
        addr c8:aa:cc:ae:ea:07
        type monitor
        channel 11 (2462 MHz), width: 20 MHz (no HT), center1: 2462 MHz
        txpower 20.00 dBm
        multicast TXQ:
            qsz-byt qsz-pkt flows   drops   marks   overlmt hashcol tx-bytes    tx-packets
            0   0   0   0   0   0   0   0       0

also confirmed the new (by hcxdumptool spoofed) MAC: c8:aa:cc:ae:ea:07 It is mandatory that the driver support all this NL80211 messages (e.g. from the example above: set virtual MAC, set/get channel. from your earlier tests, we already know that the driver does not not support to retrieve the hardware MAC by NL80211. But that is not a kill criteria (hcxdumptool does not terminate and show 000000000000 instead).

[ZerBea]

BTW: airodump-ng.strace.txt is very interesting, too It looks like airodump-ng is running some deprecated WIRELESS EXTENSIONS (WEXT) tools in background (e.g. iwpriv): 15885 execve("/bin/sh", ["sh", "-c", "iwpriv wlan0 2>/dev/null | grep "...], 0xffffec88d2b0 /* 10 vars */ <unfinished ...>

WEXT is deprecated and has been replaced by ip and iw. New development should be focused on cfg80211 and nl80211. https://wireless.wiki.kernel.org/en/developers/Documentation/Wireless-Extensions

As a result, several WEXT calls failed:

15886 ioctl(3, SIOCGIWPRIV, 0xffffe67b0a08) = -1 E2BIG (Argument list too long)
15875 ioctl(6, SIOCGIWMODE, 0xffffec888818) = -1 EOPNOTSUPP (Operation not supported)

[spiral009]

root@localhost:~/hcxdumptool# ./hcxdumptool -L

Requesting physical interface capabilities. This may take some time.
Please be patient...

available wlan devices:

phy idx hw-mac       virtual-mac  m ifname           driver (protocol)
---------------------------------------------------------------------------------------------
  0  42 000000000000 00037f12d7fb + wlan0            cnss_pci (NETLINK)

* active monitor mode available
+ monitor mode available
- no monitor mode available

bye-bye
root@localhost:~/hcxdumptool# ./hcxdumptool -i wlan0

Requesting physical interface capabilities. This may take some time.
Please be patient...

rtnetlink failed to set interface mac
failed to arm interface

2 errors during runtime

bye-bye

Iw dev doesn't show the channel

root@localhost:~/hcxdumptool# iw dev wlan0  set channel 11
root@localhost:~/hcxdumptool# iw dev
phy#0
        Interface wlan0
                ifindex 42
                wdev 0x10
                addr 00:03:7f:12:d7:fb
                type monitor
                txpower 0.00 dBm
root@localhost:~/hcxdumptool#

[spiral009]

I have fixed this aircrack-ng/aircrack-ng#2555 by reflashing the stock rom and back to custom rom, I think the issue is tied to an old firmware labeled F.04 I had to flash before flashing the custom rom, when I flashed the stock rom it contained a newer firmware C.06 , and now airodump-ng works fine in the custom rom

[spiral009]

I noticed the switching between managed and monitor mode

echo 4 > /sys/module/wlan/parameters/con_mode
echo 0 > /sys/module/wlan/parameters/con_mode

in stock kernel happens instantly as compared to custom rom it takes a minute or so which Is annoying I think it's because of the custom kernel might be missing some configs or misconfigured qcacld profile

[ZerBea]

Ok, thanks for the information.

I see 2 problems If we compare my iw output with your it looks like the driver does not allow to set/get frequency channel information: We can't set a MAC, because the driver does not allow this.

Attached another try that fixed: rtnetlink failed to set interface mac We do not need to set a virtual MAC because the driver does not support active monitor mode. Running active monitor mode that is mandatory, because the interface only ACK frames addressed to this MAC.

hcxdumptool.c.zip

Same procedure. Decompress, replace hcxdumptool.c by this version, compile and run it. Let's see what happens.

[spiral009]

root@localhost:~/hcxdumptool# ./hcxdumptool  -L

Requesting physical interface capabilities. This may take some time.
Please be patient...

available wlan devices:

phy idx hw-mac       virtual-mac  m ifname           driver (protocol)
---------------------------------------------------------------------------------------------
  0  62 000000000000 00037f12d7fb + wlan0            cnss_pci (NETLINK)

* active monitor mode available
+ monitor mode available
- no monitor mode available

bye-bye
root@localhost:~/hcxdumptool# ./hcxdumptool  -i wlan0

Requesting physical interface capabilities. This may take some time.
Please be patient...

nl80211 failed to get interface status
failed to arm interface

1 errors during runtime

bye-bye
root@localhost:~/hcxdumptool#

[ZerBea]

Thanks. On the bright side we fixed one problem. But unfortunately we run into another one: Driver reported that it support NL80211, but it doesn't respond to a standard NL80211 request to get device information nl80211 failed to get interface status

Added some more debug messages to the NL80211 standard request here: static bool nl_get_interfacestatus

hcxdumptool.c.zip

Same procedure as mentioned above. Let's see what happens.

[ZerBea]

Another try. I think I got it.

Please try this version: hcxdumptool.c.zip Same procedure as mentioned above. Let's see what happens.

[spiral009]

root@localhost:~/hcxdumptool# make
make: Warning: File 'hcxdumptool.c' has modification time 6906 s in the future
cc -O3 -Wall -Wextra -Wpedantic -std=gnu99   -o hcxdumptool hcxdumptool.c -DVERSION_TAG=\"6.3.1-30-g1a97430\" -DVERSION_YEAR=\"2023\" -DSTATUSOUT -DNMEAOUT
make: warning:  Clock skew detected.  Your build may be incomplete.
root@localhost:~/hcxdumptool# ./hcxdumptool  -i wlan0

Requesting physical interface capabilities. This may take some time.
Please be patient...

interface information:

phy idx hw-mac       virtual-mac  m ifname           driver (protocol)
---------------------------------------------------------------------------------------------
  0  74 000000000000 00037f12d7fb + wlan0            cnss_pci (NETLINK)

available frequencies: frequency [channel] tx-power of Regulatory Domain: 00

  2412 [  1] 19.0 dBm     2417 [  2] 19.0 dBm     2422 [  3] 19.0 dBm     2427 [  4] 19.0 dBm
  2432 [  5] 19.0 dBm     2437 [  6] 19.0 dBm     2442 [  7] 19.0 dBm     2447 [  8] 19.0 dBm
  2452 [  9] 19.0 dBm     2457 [ 10] 19.0 dBm     2462 [ 11] 19.0 dBm     2467 [ 12] 19.0 dBm
  2472 [ 13] 19.0 dBm     2484 [ 14] disabled     5180 [ 36] 19.0 dBm     5200 [ 40] 19.0 dBm
  5220 [ 44] 19.0 dBm     5240 [ 48] 19.0 dBm     5260 [ 52] 19.0 dBm     5280 [ 56] 19.0 dBm
  5300 [ 60] 19.0 dBm     5320 [ 64] 19.0 dBm     5500 [100] 19.0 dBm     5520 [104] 19.0 dBm
  5540 [108] 19.0 dBm     5560 [112] 19.0 dBm     5580 [116] 19.0 dBm     5600 [120] 19.0 dBm
  5620 [124] 19.0 dBm     5640 [128] 19.0 dBm     5660 [132] 19.0 dBm     5680 [136] 19.0 dBm
  5700 [140] 19.0 dBm     5720 [144] disabled     5745 [149] disabled     5765 [153] disabled
  5785 [157] disabled     5805 [161] disabled     5825 [165] disabled     5845 [169] disabled
  5865 [173] disabled

scan frequencies: frequency [channel] of Regulatory Domain: 00

  2412 [  1]      2437 [  6]      2462 [ 11]
failed to open raw packet socket

1 errors during runtime

bye-bye
root@localhost:~/hcxdumptool#

[ZerBea]

Thanks.

Unfortunately we run into the next problem - this time it is the RAW socket.

Attached a new version: hcxdumptool.c.zip

[spiral009]

root@localhost:~/hcxdumptool# ./hcxdumptool  -i wlan0

Requesting physical interface capabilities. This may take some time.
Please be patient...

interface information:

phy idx hw-mac       virtual-mac  m ifname           driver (protocol)
---------------------------------------------------------------------------------------------
  0  82 000000000000 00037f12d7fb + wlan0            cnss_pci (NETLINK)

available frequencies: frequency [channel] tx-power of Regulatory Domain: 00

  2412 [  1] 19.0 dBm     2417 [  2] 19.0 dBm     2422 [  3] 19.0 dBm     2427 [  4] 19.0 dBm
  2432 [  5] 19.0 dBm     2437 [  6] 19.0 dBm     2442 [  7] 19.0 dBm     2447 [  8] 19.0 dBm
  2452 [  9] 19.0 dBm     2457 [ 10] 19.0 dBm     2462 [ 11] 19.0 dBm     2467 [ 12] 19.0 dBm
  2472 [ 13] 19.0 dBm     2484 [ 14] disabled     5180 [ 36] 19.0 dBm     5200 [ 40] 19.0 dBm
  5220 [ 44] 19.0 dBm     5240 [ 48] 19.0 dBm     5260 [ 52] 19.0 dBm     5280 [ 56] 19.0 dBm
  5300 [ 60] 19.0 dBm     5320 [ 64] 19.0 dBm     5500 [100] 19.0 dBm     5520 [104] 19.0 dBm
  5540 [108] 19.0 dBm     5560 [112] 19.0 dBm     5580 [116] 19.0 dBm     5600 [120] 19.0 dBm
  5620 [124] 19.0 dBm     5640 [128] 19.0 dBm     5660 [132] 19.0 dBm     5680 [136] 19.0 dBm
  5700 [140] 19.0 dBm     5720 [144] disabled     5745 [149] disabled     5765 [153] disabled
  5785 [157] disabled     5805 [161] disabled     5825 [165] disabled     5845 [169] disabled
  5865 [173] disabled

scan frequencies: frequency [channel] of Regulatory Domain: 00

  2412 [  1]      2437 [  6]      2462 [ 11]
add set PACKET_IGNORE_OUTGOING failed: Protocol not available
failed to open raw packet socket

1 errors during runtime

bye-bye

[ZerBea]

Ok, thanks again for your patience.

According to this: https://thomasw.dev/post/packet_ignore_outgoing/ PACKET_IGNORE_OUTGOING shopuld be available since Linux kernel 4.20

We check this here:

#if(LINUX_VERSION_CODE >= KERNEL_VERSION(4, 20, 0))
if(setsockopt(fd_socket_rx, SOL_PACKET, PACKET_IGNORE_OUTGOING, &enable, sizeof(int)) < 0)
    {
    perror("add set PACKET_IGNORE_OUTGOING failed");
    return false;
    }
#endif

and compile it only if the Linux kernel is >= 4.20. What is your kernel version?

Removed PACKET_IGNORE_OUTGOING in this version. Please try. hcxdumptool.c.zip

[spiral009]

My kernel is msm4.19

[ZerBea]

Very interesting. Looks like it is reported as kernel >= 4.20.0.

[spiral009]

root@localhost:~/hcxdumptool# uname -a
Linux localhost 4.19.282-Spiral-g675203015cff #6 SMP PREEMPT Mon Jul 10 00:43:10 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux

[spiral009]

It did work but I couldn't run it again

[spiral009]

Output before scan begins

[ZerBea]

Ok, thanks.

Unfortunately this problem "NL80211 failed to set frequency" is expected and confirmed by iw here: https://github.com/ZerBea/hcxdumptool/issues/332#issuecomment-1649721463

The driver does not allow to set the frequency. Automatic channel management via NL80211 is an integral part of hcxdumptool. I can't disable, change or remove this without a huge impact on stock Linux kernel drivers which are working perfect.

Also columns "R 1 3 P" are empty which means that frame injection is not working as expected.

[spiral009]

I can execute iw to set the channel but I can't run it twice on the same channel

.../files/home # iw dev wlan0  set channel 11
command failed: Device or resource busy (-16)
.../files/home # ifconfig  wlan0 up
.../files/home # iw dev wlan0  set channel 11
.../files/home # iw dev wlan0  set channel 12
.../files/home # iw dev wlan0  set channel 6
.../files/home # iw dev wlan0  set channel 6
command failed: Connection timed out (-110)
.../files/home # time iw dev wlan0  set channel 6
command failed: Connection timed out (-110)

real    0m12.092s
user    0m0.008s
sys     0m0.008s
.../files/home # time iw dev wlan0  set channel 5

real    0m0.035s
user    0m0.007s
sys     0m0.007s
.../files/home # time iw dev wlan0  set channel 3

real    0m0.062s
user    0m0.007s
sys     0m0.007s
.../files/home # time iw dev wlan0  set channel 3
command failed: Connection timed out (-110)

real    0m12.155s
user    0m0.007s
sys     0m0.009s
.../files/home #

and airodump-ng can go through all the channels and I can run it more than once

[ZerBea]

You can't compare the behavior of airodump-ng (passive) and hcxdumptool (interactive).

I pushed all changes to latest git head. Please do a fresh git clone, compile and run:

./hcxdumptool -i wlan0 --rcascan=active

If everything is working as expected you should see increasing timestamps on BEACON and RESPONSE (frame injection is working if both values are the same) on different channels CHA and FREQ (channel management is working)

Output should look like this:

 CHA  FREQ   BEACON  RESPONSE A   MAC-AP   ESSID  SCAN-FREQUENCY:   2462
--------------------------------------------------------------------------
 [  6  2437] 19:36:05 19:36:05 + dc15c8afdd10 TEST_NETWORK_1
 [  1  2412] 19:36:04 19:36:04 + 0c727411f325 TEST_NETWORK_2
...

If not, the driver can't handle hcxdumptool's messages.

[spiral009]

[ZerBea]

Thanks for the screenshot. Packet injection is not working (RESPONSE timestamp does not increase) Channel management is working (we can see different channels).

If you stop hcxdumptool and restart it, the driver is blocked. It can not handle hcxdumptool's requests any longer.

There is nothing more I can do to let hcxdumptool work on this driver.

BTW: Is packet injection is working if you run airodump-ng and aireplay-ng -9 (frame injection test) in parallel? This combination get close to hcxdumptool's behavior.

[spiral009]

Not sure..

.../files/home # aireplay-ng  -a B4:0F:3B:BA:18:C1 -c C8:C2:FA:C6:4F:78  --test --ignore-negative-one wlan0
21:28:50  Waiting for beacon frame (BSSID: B4:0F:3B:BA:18:C1) on channel -1
21:28:50  Trying broadcast probe requests...
21:28:52  No Answer...
21:28:52  Found 1 AP

21:28:52  Trying directed probe requests...
21:29:16  B4:0F:3B:BA:18:C1 - channel: 5 - 'Tenda_BA18C0'
21:29:22   0/30:   0%

.../files/home #

But I can send deauth

.../files/home # aireplay-ng  -a B4:0F:3B:BA:18:C1 -c C8:C2:FA:C6:4F:78  --deauth  99 --ignore-negative-one wlan0
21:28:18  Waiting for beacon frame (BSSID: B4:0F:3B:BA:18:C1) on channel -1
21:28:19  Sending 64 directed DeAuth (code 7). STMAC: [C8:C2:FA:C6:4F:78] [ 5| 0 ACKs]
21:28:19  Sending 64 directed DeAuth (code 7). STMAC: [C8:C2:FA:C6:4F:78] [ 7| 0 ACKs]
21:28:20  Sending 64 directed DeAuth (code 7). STMAC: [C8:C2:FA:C6:4F:78] [10| 0 ACKs]

[ZerBea]

Injection is not working:

21:28:50  Trying broadcast probe requests...
21:28:52  No Answer...

and 21:28:19 Sending 64 directed DeAuth (code 7). STMAC: [C8:C2:FA:C6:4F:78] [ 5| 0 ACKs] 0 ACKs = no packet received by the target.

Also this "on channel -1" doesn't look good for me.

hcxdumptool will not work on this driver.

[spiral009]

Why can he #251 retrieve his mac address and I can't even though hw-mac , virtual-mac are the same

[ZerBea]

Old hcxdumptool v 6.2.6 got this information via ethtool API (dependency to ethtool):

epmaddr = (struct ethtool_perm_addr*)calloc(1, sizeof(struct ethtool_perm_addr) +6);
if(!epmaddr)
    {
    perror("failed to malloc memory for permanent hardware address");
    return false;
    }
memset(&ifr, 0, sizeof(ifr));
memcpy(&ifr.ifr_name, interfacename, IFNAMSIZ);
epmaddr->cmd = ETHTOOL_GPERMADDR;
epmaddr->size = 6;
ifr.ifr_data = (char*)epmaddr;
if(ioctl(fd_socket, SIOCETHTOOL, &ifr) < 0)
    {
    perror("failed to get permanent hardware address, ioctl(SIOCETHTOOL) not supported by driver");
    return false;
    }
if(epmaddr->size != 6)
    {
    fprintf(stderr, "failed to get permanent hardware address length\n");
    return false;
    }
memcpy(&mac_orig, epmaddr->data, 6);
free(epmaddr);

Since v6.3.0 this has been removed in favor of RTNETLINK:

            #if(LINUX_VERSION_CODE >= KERNEL_VERSION(5, 10, 0))
            if(rta->rta_type == IFLA_PERM_ADDRESS)
                {
                if(rta->rta_len == 10) memcpy(hwmac, rta_data(rta), ETH_ALEN);
                }
            #else
            if(rta->rta_type == IFLA_ADDRESS)
                {
                if(rta->rta_len == 10) memcpy(hwmac, rta_data(rta), ETH_ALEN);
                }
            #endif

More information is here:

Permanent hardware address of a network device was traditionally provided
via ethtool ioctl interface but as Jiri Pirko pointed out in a review of
ethtool netlink interface, rtnetlink is much more suitable for it so let's
add it to the RTM_NEWLINK message.
Add IFLA_PERM_ADDRESS attribute to RTM_NEWLINK messages unless the
permanent address is all zeros (i.e. device driver did not fill it).

https://lkml.iu.edu/hypermail/linux/kernel/1910.1/02186.html

or here:

Introduction to Netlink
Netlink is often described as an ioctl() replacement. It aims to replace fixed-format C structures
as supplied to ioctl() with a format which allows an easy way to add or extended the arguments.

https://kernel.org/doc/html/next/userspace-api/netlink/intro.html

or here:

Alternatives to ioctl
There are many cases in which ioctl is not the best solution for a problem. Alternatives include:
...
netlink is the preferred way of configuring any network related objects through sockets.

https://www.kernel.org/doc/html/latest/driver-api/ioctl.html

hcxdumptool/hcxtools is state of the art. The latest techniques are always used while old ones are dropped, merciless.

[ZerBea]

By this commit: https://github.com/ZerBea/hcxdumptool/commit/1bc1768a6dbbe38917f0d41550ee275db32ccc39 I improved hcxdumptool -v to get some information about the environment at compile time.

On my system, output looks like this:

$ hcxdumptool -v
hcxdumptool 6.3.1-36-g1bc1768 (C) 2023 ZeroBeat
compiled by gcc 13.1.1
Linux API headers 6.3.0

Under normal circumstances, the Linux kernel" version could be greater than the "Linux API headers" version, but never less, e.g. on my system:

$ uname -r
6.4.4-arch1-1

Can you please run latest git head and comment the output of hcxdumptool -v, because I still wonder why some defines are not working as expected on Android.

[spiral009]

root@localhost:~/hcxdumptool# ./hcxdumptool -v
hcxdumptool 6.3.1-40-gd399f14 (C) 2023 ZeroBeat
compiled by gcc 4.2.1
compiled with Linux API headers 5.15.99
root@localhost:~/hcxdumptool#

Ubuntu 22.04 chroot

[ZerBea]

Thanks. It looks like we are running into a really ugly problem. I can't fix that, because it is related to your environment / configuration and not to hcxdumptool. hcxdumptool is compiled using API headers 5.15.99 but your Android Kernel is 4.19.282 https://github.com/ZerBea/hcxdumptool/issues/332#issuecomment-1650195397

gcc compile functions and values of Linux API 5.15.99 to hcxdumptool which are not present in the active kernel 4.19.282. I think you can imagine what happens if you execute hcxdumptool on kernel 4.19 and it reach such a function which expect API 5.15...

Under normal circumstances, the Linux kernel" version could be greater than the "Linux API headers" version, but never less: your kernel: 4.19.282 your API headers: 5.15.99

It is mandatory to fix that.