Skip to content
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

Passive Mode for Monitor Mode-only Devices #197

Closed
s00se opened this issue Dec 20, 2021 · 11 comments
Closed

Passive Mode for Monitor Mode-only Devices #197

s00se opened this issue Dec 20, 2021 · 11 comments

Comments

@s00se
Copy link

s00se commented Dec 20, 2021

Is it possible to include an override to only allow passive mode collection for devices that do not have packet injection but do support RFMON, like many Android devices running qcacld-3.0

@ZerBea
Copy link
Owner

ZerBea commented Dec 20, 2021

It doesn't matter if the device support packet injection or not, because we send packets to be injected via a RAW socket.
If the device doesn't support packet injection, this packets are ignored.
There is also an option to act as passive dumper only: "silent":
--silent : do not transmit!
hcxdumptool is acting like a passive dumper
expect possible packet loss

But it is mandatory that kernel and driver support ioctl() system calls!!!
This is not the case on several drivers and on several Android kernels, because they are compiled without "wireless extensions".
To enable ioctl() system calls it is mandatory to set "y" to WEXT config:

CONFIG_CFG80211_WEXT=y
CONFIG_CFG80211_WEXT_EXPORT=y

#192 (comment)
Please read the entire thread especially about the new option "force":
#192 (comment)

There is also an option "force" to ignore ioctl() system call related warnings:

--force_interface                  : ignore all ioctl() warnings and error counter
                                     allow hcxdumptool to run on a virtual NETLINK monitor interface
                                     warning: packet injection and/or channel change may not work as expected
                                     you have been warned: do not report issues!

It is mandatory that hcxdumptool has direct access to the device. It will not work on NETLINK, emulators or wrappers!

BTW:
hcxdumptool is not designed as a stupid passive dumper, because it is mandatory to interact with the target (AP and/or CLIENT). I recommend to use tshark/Wireshark if you need a passive dumper.

I think we can close this feature request, because it depend on the kernel configuration and the capabilities of the driver.

@ZerBea ZerBea closed this as completed Dec 20, 2021
@s00se
Copy link
Author

s00se commented Dec 20, 2021

After compiling my kernel (based on LineageOS 18.1) with WEXT and CRDA enabled, airmon-ng simply crashes my device and a hard reboot occurs, whereas before without the extensions it actually put the chipset into monitor mode and was usable with airodump-ng and other tools.

Thanks for clarifying.

@ZerBea
Copy link
Owner

ZerBea commented Dec 20, 2021

That is very interesting. airmon-ng use iw to set monitor mode and iw use NETLINK.
It looks like the wireless extensions (WEXT) inc combination with qcacld-3.0 are not completely functional and caused the kernel to crash.

What happens (kernel compiled without WEXT) if you set monitor mode as mentioned here:
https://github.com/kimocoder/qualcomm_android_monitor_mode
Than run hcxdumptool with options --force_interface --silent --enable_status=95
Now hcxdumptool will show you if ioctl() system calls are supported or not.

@ZerBea
Copy link
Owner

ZerBea commented Dec 20, 2021

The output of iw will give us more information. Please try:
$ iw dev
It should look like this:

phy#0
	Interface wlp39s0f3u1u6
		ifindex 3
		wdev 0x1
		addr 74:da:38:f2:03:8e
		type managed
		txpower 0.00 dBm

Now set monitor by iw (replace wlp39s0f3u1u6 with your interface name):
$ sudo iw dev wlp39s0f3u1u6 set type monitor
and run
$ iw dev
output should be

phy#0
	Interface wlp39s0f3u1u6
		ifindex 3
		wdev 0x1
		addr 74:da:38:f2:03:8e
		type monitor
		txpower 0.00 dBm

Next step is to restart the device and set monitor mode as mentioned here:
https://github.com/kimocoder/qualcomm_android_monitor_mode
Than run iw dev to make sure monitor mode (type monitor) is really set on the physical device and run hcxdumptool with options mentioned above.
It will be a bad sign, if ioctl() system calls are not supported or the device driver crashes.

Activating CRDA is mandatory only if you need injecting capabilities on 5GHz band, which is not allowed by a standard kernel.

BTW:
Airmon-ng is a script that does exactly the same as described above:
set con_mode:
https://github.com/aircrack-ng/aircrack-ng/blob/master/scripts/airmon-ng.linux#L404
or if WEXT detected
set monitor mode on physical interface:
https://github.com/aircrack-ng/aircrack-ng/blob/master/scripts/airmon-ng.linux#L380
or add a virtual interface:
https://github.com/aircrack-ng/aircrack-ng/blob/master/scripts/airmon-ng.linux#L492

@strasharo
Copy link
Contributor

@s00se what device are you using?

@s00se
Copy link
Author

s00se commented Dec 20, 2021

@strasharo Currently testing this with a Pixel 5 on persona build of LineageOS 18.1

@ZerBea
Copy link
Owner

ZerBea commented Dec 21, 2021

Presence of Wireless Extensions is mandatory.
By this commit:
cc2b1d8
hcxdumptool detect presence of Wireless extensions like "Wireless Tools" do:
https://github.com/HewlettPackard/wireless-tools/blob/master/wireless_tools/iwlib.c#L673
If no wireless name : no wireless extensions
In that case hcxdumptool will not work as expected.

@s00se
Copy link
Author

s00se commented Dec 29, 2021

I have removed identifying information:

iw dev:

phy#0
        Interface wifi-aware0
                ifindex 33
                wdev 0xe
                addr
                type NAN
        Interface p2p0
                ifindex 32
                wdev 0xd
                addr
                type managed
                txpower 0.00 dBm
        Interface wlan1
                ifindex 31
                wdev 0xc
                addr
                type managed
        Interface wlan0
                ifindex 30
                wdev 0xb
                addr
                ssid
                type managed
                txpower 37.00 dBm

After issuing airmon-ng start wlan1 with WEXT disabled in kernel:

Your kernel supports rfkill but you don't have rfkill installed.
To ensure devices are unblocked you must install rfkill.

Found 1 processes that could cause trouble.
Kill them using 'airmon-ng check kill' before putting
the card in monitor mode, they will interfere by changing channels
and sometimes putting the interface back in managed mode

  PID Name
27758 wpa_supplicant

PHY     Interface       Driver          Chipset

null    ??????          non-mac80211 device? (report this!)
null    p2p0            ??????          non-mac80211 device? (report this!)
null    wifi-aware0     ??????          non-mac80211 device? (report this!)
null    wlan0           ??????          non-mac80211 device? (report this!)
phy0    wlan1           icnss           Not pci, usb, or sdio

Failed to set wlan1 up using ip
                (monitor mode enabled)

Failed to set wlan1 up using ip

Error setting channel: command failed: No such device (-19)

The interface is actually put in RFMON, as I can see packets just fine using airodump-ng wlan0 and iw dev does indeed show the device is out of managed mode, and now in monitor mode:

phy#0
        Interface wlan0
                ifindex 34
                wdev 0xf
                addr
                type monitor

@s00se
Copy link
Author

s00se commented Dec 29, 2021

Do note, I am calling airmon-ng on wlan1, but it is actually wlan0 that I need to use as an interface for airodump-ng to see packets. I don't know if there is a virtual interface created by Android subsystem or what.

Setting monitor mode using iw dev fails, however setting con_mode to 4 works, wlan0 is placed into monitor mode, and packets are visible on the wlan0 interface

@ZerBea
Copy link
Owner

ZerBea commented Jan 2, 2022

There is no mac80211 stack hcxdumptool can work on:
null wifi-aware0 ?????? non-mac80211 device? (report this!)
null wlan0 ?????? non-mac80211 device? (report this!)

Please also notice that airodump-ng and iw are running NETLINK and hcxdumptoll not.
To test if airodump-ng is still working if NETLINK is disabled just comple it with --disable-libnl and see what happens.
"Linux: LibNetlink 1 or 3. It can be disabled by passing --disable-libnl to configure."

@ZerBea
Copy link
Owner

ZerBea commented Jan 2, 2022

To clarify it:
iw use NETLINK
airodump-ng use NETLINK (if not compiled with --disable-libnl)
hcxdumptool use WEXT.

@ZerBea ZerBea mentioned this issue Jan 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants