-
Notifications
You must be signed in to change notification settings - Fork 402
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Doesn't work on qcacld3.0 driver (not part of the Linux kernel) #332
Comments
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.: I don' see a way that hcxdumptool will work on this driver. |
To record WiFi traffic, use iw to set requency and tshark to record mandatory frames:
hcxpcapngtool will work on the dump file (dump.pcapng). |
I think we can close this, because the driver doesn't support to set monitor mode by NL80211. Instead it use its own mode: Also it doesn't support full packet injection:
|
Well it's a qcacld3.0 qca6390 and I can send deauth packets in aireplay-ng but must run airodump-ng in another session |
We can try this: and comment it: recompile hcxdumptool set monitor mode by qualcomm and run hcxdumptool. This is the function where we arm the interface: |
It is mandatory that the driver support NL80211, To discover what NL80211 features are supported you can monitor this by nlmon: activate nlmon: run Wireshark and capture traffic from nlmon stop hcxdumptool |
BTW: |
BTW: 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:
and on second request like this:
|
That explains a lot, because it is not a native Linux driver provided by the Linux kernel. |
You may have noticed that I changed the head line. Problem is the driver, |
Looks like there are some more problems on this driver: After reading all this, I still don't see a real chance that hcxdumptool will work on this driver. |
I think I need to recompile the kernel with CONFIG_NLMON=y for this to work
I did comment and recompiled hcxdumptool
And Tshark isn't working
|
I do have an external wifi adapter and it does work but I always prefer to use internal interface |
I do have CONFIG_NL80211_TESTMODE=y in the kennel , not sure if it does anything |
Thanks for the tests. Attached a special debug version. Please decompress and replace hcxdumptool.c by this version. 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. |
This |
There is no longer need to activate nlmon, because we now can do this by the debug printf's mentioned above. |
I'm very keen to to find out what NL80211 / RTNETLINK message will fail. |
|
You need to do a fresh git clone, before replacing hcxdumptool.c
because there are a lot of changes:
and hcxdumptool.c need the new includes. |
After some investigations I have a suspect: channel management via NL80211 will fail on that driver. Additional you can try to set the frequency iw:
hcxdumptool is doing exactly the same like iw, e.g. set frequency to channel 11: success - channel 11 confirmed by iw:
also confirmed the new (by hcxdumptool spoofed) MAC: c8:aa:cc:ae:ea:07 |
BTW: airodump-ng.strace.txt is very interesting, too WEXT is deprecated and has been replaced by ip and iw. As a result, several WEXT calls failed:
|
Iw dev doesn't show the channel
|
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 |
I noticed the switching between managed and monitor 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 |
Ok, thanks for the information. I see 2 problems Attached another try that fixed: Same procedure. Decompress, replace hcxdumptool.c by this version, compile and run it. |
|
Thanks. Added some more debug messages to the NL80211 standard request here: static bool nl_get_interfacestatus Same procedure as mentioned above. Let's see what happens. |
Another try. I think I got it. Please try this version: |
|
Thanks. Unfortunately we run into the next problem - this time it is the RAW socket. Attached a new version: |
|
Ok, thanks again for your patience. According to this: We check this here:
and compile it only if the Linux kernel is >= 4.20. Removed PACKET_IGNORE_OUTGOING in this version. Please try. |
My kernel is msm4.19 |
Very interesting. Looks like it is reported as kernel >= 4.20.0. |
|
Ok, thanks. Unfortunately this problem "NL80211 failed to set frequency" is expected and confirmed by iw here: The driver does not allow to set the frequency. Also columns "R 1 3 P" are empty which means that frame injection is not working as expected. |
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 Output should look like this:
If not, the driver can't handle hcxdumptool's messages. |
Thanks for the screenshot. 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: |
Not sure..
But I can send deauth
|
Injection is not working:
and Also this "on channel -1" doesn't look good for me. hcxdumptool will not work on this driver. |
Why can he #251 retrieve his mac address and I can't even though hw-mac , virtual-mac are the same |
Old hcxdumptool v 6.2.6 got this information via ethtool API (dependency to ethtool):
Since v6.3.0 this has been removed in favor of RTNETLINK:
More information is here:
https://lkml.iu.edu/hypermail/linux/kernel/1910.1/02186.html or here:
https://kernel.org/doc/html/next/userspace-api/netlink/intro.html or here:
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. |
By this commit: On my system, output looks like this:
Under normal circumstances, the Linux kernel" version could be greater than the "Linux API headers" version, but never less, e.g. on my system:
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. |
Ubuntu 22.04 chroot |
Thanks. gcc compile functions and values of Linux API 5.15.99 to hcxdumptool which are not present in the active kernel 4.19.282. Under normal circumstances, the Linux kernel" version could be greater than the "Linux API headers" version, but never less: It is mandatory to fix that. |
A real life example: Here we check the Linux API header:
If the API version is >= 5.10.0 we use IFLA_PERM_ADDRESS to get the permanent hardware MAC. According to your API (5.15.99) IFLA_PERM_ADDRESS should be present and this code to request IFLA_PERM_ADDRESS is compiled. Unfortunately your kernel is 4.19 and IFLA_PERM_ADDRESS is not available there. |
I'm not sure where to find the API headers but I found this https://docs.kernel.org/kbuild/headers_install.html
I looked it up and found this patchwork https://patchwork.kernel.org/project/linux-kbuild/patch/[email protected]/
|
Looks like this patch destroyed the macros. Usually this macros are located here:
and the compiler (gcc) knows where to find them. The header file "version.h" contain the version numbers and the macro (KERNEL_VERSION) to convert them:
Please notice that there are 2 different headers, e.g. on my system:
The difference is explained e.g. here: It is imperative that they fit together: Arch archive the latest linux-api-headers here: I don't know how other distributions handle this, but it might be similar to Arch Linux Please notice: |
By latest commit I added an information about glibc (at compile time):
The version of glibc running on the target system should be greater or equal to this version, but never less.
If the conditions meet, this is a good indicator that your environment and your configuration are working well. |
I know that Qualcomm Is listed as unrecommened because of no packet Injection , but that doesn't prevent it from capturing pmkid right?
The text was updated successfully, but these errors were encountered: