Gemini PDA

[clintonm9]

I have a Gemini PDA with Kali Linux on it running a very old kernel of 3.18.41 (that is all that is offered).

I know that airodump-ng works with the older kernel, but is there a way to get this tool to work? I tried to use the android ndk builds, but no look.

The error I get is:

failed to save current interface mode: Operation not supported on transport endpoint
failed to init socket

[ZerBea]

You can't compare airodump-ng with hcxdumptool, because airodump-ng is passive (only receive packets) and hcxdumptool is active (receive and send packets). Therefore we need a driver that support full monitor mode and full packet injection. Your driver doesn't do this. Is packet injection working (https://www.aircrack-ng.org/doku.php?id=injection_test)? Can you set channel, running iw?

[clintonm9]

root@kali:~# aireplay-ng -9 wlan1mon
15:11:20  Trying broadcast probe requests...
15:11:22  No Answer...
15:11:22  Found 3 APs

15:11:22  Trying directed probe requests...
15:11:22  XXXXX - channel: 1 - 'XXXXX'
15:11:22  Ping (min/avg/max): 3.343ms/5.370ms/10.267ms Power: -41.40
15:11:22  30/30: 100%

15:11:22  Injection is working!
.....

I can set a channel.

root@kali:~/Repos/hcxdumptool# iw dev wlan1mon info
Interface wlan1mon
        ifindex 36
        wdev 0x200000002
        addr XXXX
        type monitor
        wiphy 2
        channel 1 (2412 MHz), width: 20 MHz (no HT), center1: 2412 MHz

[ZerBea]

Pushed an update (option --ignore_warning) --ignore_warning : ignore warnings try this if yo get some driver warnings

Set your interface to monitor mode and bring it up $ ip link set interface down $ iw dev interface set type monitor $ ip link set interface up

run hcxdumptool: $ hcxdumptool -i interface --ignore_warning --enable_status=3

[clintonm9]

Here are the results:

root@kali:~/Repos/hcxdumptool# ip link set wlan1 down
root@kali:~/Repos/hcxdumptool# iw dev wlan1 set type monitor
root@kali:~/Repos/hcxdumptool# ip link set wlan1 up
root@kali:~/Repos/hcxdumptool# ./hcxdumptool -i wlan1 --ignore_warning --enable_status=3
initialization...
failed to save current interface mode: Operation not supported
failed to init socket

root@kali:~# aireplay-ng -9 wlan1
11:02:50  Trying broadcast probe requests...
11:02:51  Injection is working!
....
root@kali:~/Repos/hcxdumptool# iw dev wlan1 info
Interface wlan1
        ifindex 35
        wdev 0x200000001
        addr 9c:ef:d5:fc:b1:10
        type monitor
        wiphy 2
        channel 11 (2462 MHz), width: 20 MHz (no HT), center1: 2462 MHz

Not sure if any of this helps, but with the older kernal, I get this error from airmon-ng. I always had to setup monitor mode manually

root@kali:~# airmon-ng start wlan1

Found phy0 with no interfaces assigned, would you like to assign one to it? [y/n] n
PHY phy0 will remain lost.

Found phy1 with no interfaces assigned, would you like to assign one to it? [y/n] n
PHY phy1 will remain lost.

PHY     Interface       Driver          Chipset

ethtool failed...
Only mac80211 devices on kernel 2.6.33 or higher are officially supported by airmon-ng.

How I setup wlan1mon:

iw phy `iw dev wlan1 info | gawk '/wiphy/ {printf "phy" $2}'` interface add wlan1mon type monitor

[ZerBea]

It looks like the driver doesn't support SIOCGIWMODE and SIOCSIWMODE. So now we do not check this flags. Both flags are used if hcxdumptool set monitor mode. Please test latest commit: https://github.com/ZerBea/hcxdumptool/commit/7c473332c226fd04d45c74010a8c951b13d99fe4

[clintonm9]

Results:

root@kali:~/Repos/hcxdumptool# git pull
remote: Enumerating objects: 3, done.
remote: Counting objects: 100% (3/3), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 3 (delta 0), reused 1 (delta 0), pack-reused 0
Unpacking objects: 100% (3/3), done.
From https://github.com/ZerBea/hcxdumptool
   51365ee..7c47333  master     -> origin/master
Updating 51365ee..7c47333
Fast-forward
 hcxdumptool.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)
root@kali:~/Repos/hcxdumptool# make
cc -O3 -Wall -Wextra -std=gnu99  -o hcxpioff hcxpioff.c 
cc -O3 -Wall -Wextra -std=gnu99  -o hcxdumptool hcxdumptool.c 
root@kali:~/Repos/hcxdumptool# ./hcxdumptool -i wlan1 --ignore_warning --enable_status=3
initialization...
failed to save current interface mode: Operation not supported
failed to set monitor mode: Operation not supported
failed to init socket

[ZerBea]

Ok, we sucesfully ignore this one: failed to save current interface mode: Operation not supported With this commit: https://github.com/ZerBea/hcxdumptool/commit/ddcdce492ca0d96bf112eba0fd31011cc6a54f47 we ignore this warning: failed to set monitor mode: Operation not supported

[clintonm9]

Here are the results:

failed to save current interface mode: Operation not supported
failed to set monitor mode: Operation not supported
failed to get interface information: Operation not supported
interface is not in monitor mode
initialization...
warning: wlan1mon is probably a monitor interface
warning: failed to set channel 1 (Operation not supported) - removed this channel from scan list
warning: failed to set channel 6 (Operation not supported) - removed this channel from scan list
warning: failed to set channel 2 (Operation not supported) - removed this channel from scan list
warning: failed to set channel 11 (Operation not supported) - removed this channel from scan list
warning: failed to set channel 1 (Operation not supported) - removed this channel from scan list
warning: failed to set channel 13 (Operation not supported) - removed this channel from scan list
warning: failed to set channel 6 (Operation not supported) - removed this channel from scan list
warning: failed to set channel 11 (Operation not supported) - removed this channel from scan list
warning: failed to set channel 1 (Operation not supported) - removed this channel from scan list
warning: failed to set channel 6 (Operation not supported) - removed this channel from scan list
warning: failed to set channel 3 (Operation not supported) - removed this channel from scan list
warning: failed to set channel 11 (Operation not supported) - removed this channel from scan list
warning: failed to set channel 1 (Operation not supported) - removed this channel from scan list
warning: failed to set channel 12 (Operation not supported) - removed this channel from scan list
warning: failed to set channel 6 (Operation not supported) - removed this channel from scan list
warning: failed to set channel 11 (Operation not supported) - removed this channel from scan list
warning: failed to set channel 1 (Operation not supported) - removed this channel from scan list
warning: failed to set channel 6 (Operation not supported) - removed this channel from scan list
warning: failed to set channel 4 (Operation not supported) - removed this channel from scan list
warning: failed to set channel 11 (Operation not supported) - removed this channel from scan list
warning: failed to set channel 1 (Operation not supported) - removed this channel from scan list
warning: failed to set channel 10 (Operation not supported) - removed this channel from scan list
warning: failed to set channel 6 (Operation not supported) - removed this channel from scan list
warning: failed to set channel 11 (Operation not supported) - removed this channel from scan list
warning: failed to set channel 1 (Operation not supported) - removed this channel from scan list
warning: failed to set channel 6 (Operation not supported) - removed this channel from scan list
warning: failed to set channel 11 (Operation not supported) - removed this channel from scan list
warning: failed to set channel 5 (Operation not supported) - removed this channel from scan list
warning: failed to set channel 1 (Operation not supported) - removed this channel from scan list
warning: failed to set channel 6 (Operation not supported) - removed this channel from scan list
warning: failed to set channel 11 (Operation not supported) - removed this channel from scan list
warning: failed to set channel 8 (Operation not supported) - removed this channel from scan list
warning: failed to set channel 1 (Operation not supported) - removed this channel from scan list
warning: failed to set channel 9 (Operation not supported) - removed this channel from scan list
warning: failed to set channel 6 (Operation not supported) - removed this channel from scan list
warning: failed to set channel 11 (Operation not supported) - removed this channel from scan list
warning: failed to set channel 1 (Operation not supported) - removed this channel from scan list
warning: failed to set channel 6 (Operation not supported) - removed this channel from scan list
warning: failed to set channel 11 (Operation not supported) - removed this channel from scan list
warning: failed to set channel 7 (Operation not supported) - removed this channel from scan list
no available channel found in scan list

terminated..

[ZerBea]

Is iw able to set a channel? $ iw dev "interface" set channel 6

We use SIOCSIWFREQ to set a channel. Unfortunately we can't ignore this.

[clintonm9]

Yes, that command successfully changes the channel of the interface.

[ZerBea]

hcxdumptool uses ioctl() commands to control the interface. Unfortunately the driver (x27) doesn't support this. If we send and ioctl() command, in every case the driver reports "Operation not supported". This error message is not generated by hcxdumptool. It is the orignal message, we recieved from the driver (we use perror() to print it). hcxdumptool will not work with this driver! You can try an external device running a driver which supports monitor mode and packet injection. Get information about suitable chipsets, here: https://wikidevi.com/wiki/Main_Page But keep in mind: your kernel is ancient and reached EOL (2019-05-16) https://www.kernel.org/

[clintonm9]

I tried two devices on this old kernel; RT5372 and RT2870/RT3070 with an external USB drive.

Here is the kernel: https://github.com/Re4son/gemini-kali-linux-kernel-3.18

Do you think if I tried to update the drive it might fix it? Is aireplay-ng using something different to control the channel of the device?

Thanks for all your help!

[ZerBea]

hcxdumptool need full (and exclusive) access to the interface! From hcxdumptool --help: do not run hcxdumptool on logical interfaces (monx, wlanxmon) do not use hcxdumptool in combination with other 3rd party tools, which take access to the interface

That includes also wrapers.

Running your command, you add a logical(!) monitor interface: sudo iw phy iw dev wlan1 info | gawk '/wiphy/ {printf "phy" $2}' interface add wlan1mon type monitor.

What happens if you try to set the interface to monitor mode running this commands: $ hcxdumptool -I $ ip link set "interface" down $ iw dev "interface" set type monitor $ ip link set "interface" up $ iw dev

Please post the result of every command.

[ZerBea]

Here is an example, how it should look like: $ hcxdumptool -I wlan interfaces: 74da38eb4600 wlp3s0f0u10u2 (mt7601u)

$ ip link set wlp3s0f0u10u2 down $ iw dev wlp3s0f0u10u2 set type monitor $ ip link set wlp3s0f0u10u2 up $ iw dev phy#7 Interface wlp3s0f0u10u2 ifindex 12 wdev 0x700000001 addr 74:da:38:eb:46:00 type monitor channel 1 (2412 MHz), width: 20 MHz (no HT), center1: 2412 MHz txpower 20.00 dBm

hcxdumptool -I should show you suitable interfaces ip link set "interface" down should give you no error iw dev "interface" set type monitor should give you no error ip link set "interface" up should give you no error iw dev should show you informations about the interface.

[ZerBea]

‎Here it is very well explained: https://github.com/The-Cracker-Technology/ANDRAX-Mobile-Pentest/wiki/How-to-enable-monitor-mode-in-all-devices%3F

BTW: To answer your questions:

Do you think if I tried to update the drive it might fix it? No, unless you have a driver that support this.

Is aireplay-ng using something different to control the channel of the device? aireplay-ng doesn't control the channel and allows it, that another tool can change the channel. https://www.aircrack-ng.org/doku.php?id=aireplay-ng

[clintonm9]

I followed the steps above and got no errors and my iw dev output looked like yours. I can change the channel using iw dev wlan1 set channel 1.

airodump-ng was changing the channel of the interface.

When I run hcxdumptool -I I get the following list about 15 times: failed to get driver information: Operation not supported The last line says 0009345e53a0 wlan0 (mt-wifi)

wlan0 is the built-in wireless device and does not support monitor mode.

[ZerBea]

The driver (or the wrapper) doesn't support ioctl() commands: SIOCGIWMODE, SIOCSIWMODE, SIOCGIWFREQ, SIOCSIWFREQ. This commands are main part of hcxdumptool to control the hardware interface (wlan0). Every time we run such a command the driver tell us that it is not supported (Operation not supported). So there is no chance to use hcxdumptool in combination with that driver.

[ZerBea]

Are you sure, that you followed the instructions? I asked you to run the commands on the hardware interface, not on a virtual interface. hcxdumptool doesn't support virtual interfaces. You are talking about wlan1, but wlan 0 is your hardware interface [(0009345e53a0 wlan0 (mt-wifi)]: "I followed the steps above and got no errors and my iw dev output looked like yours. I can change the channel using iw dev wlan1 set channel 1". Can you set the channel on your hardware interface? $ iw dev wlan0 set channel 1 What is the output if you try to set wlan0 monitor mode? $ iw dev wlan0 set type monitor I assume you will get a similar error message from iw: Operation not supported.

[clintonm9]

I am following the instructions, yes.

wlan0 is the internal wireless chipset that does not support monitoring mode. I am not sure why it would be listed when running -I argument wlan1 is the external usb device that does support monitoring mode.

I followed the instructions to not use a virtual interface by doing the following:

ip link set wlan1 down
iw dev wlan1 set type monitor
ip link set wlan1 up
iw dev

the output of iw dev showed the device information including the channel and then I could change the channel with iw dev wlan1 set channel 1 successfully.

Using this non-virutal interface still gave the same results with hcxdumptool. Operation not supported coming from perror()

[ZerBea]

Read more about the difference physical interface vs logical interface here: https://www.oreilly.com/library/view/junos-enterprise-routing/9781449309633/ch04s03.html

[ZerBea]

Ok, we are talking about an external interface. Please post the output of $ lsusb and $ lshw -C network

[ZerBea]

if you don't have lshw installed, you can use $ ethtool -i wlan1 | grep driver

BTW: hcxdumptool use ioctl() SIOCETHTOOL to get information about the driver. So it is better to run ethtool instead of lshw.

[clintonm9]

root@kali:~/Repos# lsusb
Bus 001 Device 027: ID 148f:5372 Ralink Technology, Corp. RT5372 Wireless Adapter
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@kali:~/Repos# ethtool -i wlan1 | grep driver
driver: rt2800usb

[ZerBea]

Hmm. I'm running 2 systems here (kernel 4.19-lts and 5.1) and hcxdumptool is working fine on both of them.

$ lsusb Bus 001 Device 008: ID 148f:5370 Ralink Technology, Corp. RT5370 Wireless Adapter

$ ethtool -i wlp3s0f0u10u2 | grep driver driver: rt2800usb

$ hcxdumptool -I wlan interfaces: 7cdd908a0285 wlp3s0f0u10u2 (rt2800usb)

$ hcxdumptool -i wlp3s0f0u10u2 -C initialization... available channels: 1 / 2412MHz (20 dBm) 2 / 2417MHz (20 dBm) 3 / 2422MHz (20 dBm) 4 / 2427MHz (20 dBm) 5 / 2432MHz (20 dBm) 6 / 2437MHz (20 dBm) 7 / 2442MHz (20 dBm) 8 / 2447MHz (20 dBm) 9 / 2452MHz (20 dBm) 10 / 2457MHz (20 dBm) 11 / 2462MHz (20 dBm) 12 / 2467MHz (20 dBm) 13 / 2472MHz (20 dBm) 14 / 2484MHz (20 dBm) terminated...

$ lsusb Bus 001 Device 010: ID 148f:3070 Ralink Technology, Corp. RT2870/RT3070 Wireless Adapter

$ ethtool -i wlp3s0f0u10u2 | grep driver driver: rt2800usb

$ hcxdumptool -I wlan interfaces: c83a35cb08e3 wlp3s0f0u10u2 (rt2800usb)

$ hcxdumptool -i wlp3s0f0u10u2 -C initialization... available channels: 1 / 2412MHz (20 dBm) 2 / 2417MHz (20 dBm) 3 / 2422MHz (20 dBm) 4 / 2427MHz (20 dBm) 5 / 2432MHz (20 dBm) 6 / 2437MHz (20 dBm) 7 / 2442MHz (20 dBm) 8 / 2447MHz (20 dBm) 9 / 2452MHz (20 dBm) 10 / 2457MHz (20 dBm) 11 / 2462MHz (20 dBm) 12 / 2467MHz (20 dBm) 13 / 2472MHz (20 dBm) 14 / 2484MHz (20 dBm) terminated...

I'm running out of ideas, because I'm not able to reproduce it on latest kernels.

[ZerBea]

We had/have some ugly kernel/driver issues. I started with kernel 4.4 to report them. From README.md: Don't use Kernel 4.4 (rt2x00 driver regression) or https://bugzilla.kernel.org/show_bug.cgi?id=202241 https://bugzilla.kernel.org/show_bug.cgi?id=202243 https://github.com/openwrt/mt76/issues/216

This one is present from 4.19 up to latest kernel and affects all ALFAs: https://bugzilla.kernel.org/show_bug.cgi?id=202541 https://github.com/ZerBea/hcxdumptool/issues/57

And the GEMINI kernel isn't upgraded over a long time.

[clintonm9]

To get wlan1 to work in the first place I had to install firmware-ralink which installed firmware-misc-nonfree.

Do you think the issue is with the rt2800usb driver provided by the kernel or the firmware provided by firmware-misc-nonfree?

root@kali:~/firmware-nonfree-20190114# lsmod
Module                  Size  Used by
rt2800usb              22376  0
rt2800lib              74533  1 rt2800usb
rt2x00usb               9682  1 rt2800usb
rt2x00lib              39740  3 rt2x00usb,rt2800lib,rt2800usb

[clintonm9]

Looking at strace with airodump-ng, I do see the same issues of Operation not supported in the output. Maybe airodump is falling back to another method?

ioctl(6, SIOCGIFINDEX, {ifr_name="wlan1", }) = 0
ioctl(6, SIOCGIFHWADDR, {ifr_name="wlan1", ifr_hwaddr={sa_family=ARPHRD_IEEE80211_RADIOTAP, sa_data=9c:ef:d5:fc:b1:10}}) = 0
ioctl(6, SIOCGIWMODE, 0x7fc362de10)     = -1 EOPNOTSUPP (Operation not supported)
ioctl(6, SIOCSIFFLAGS, {ifr_name="wlan1", ifr_flags=IFF_UP|IFF_BROADCAST|IFF_NOTRAILERS|IFF_RUNNING|IFF_PROMISC|IFF_ALLMULTI}) = 0
bind(6, {sa_family=AF_PACKET, sll_protocol=htons(ETH_P_ALL), sll_ifindex=if_nametoindex("wlan1"), sll_hatype=ARPHRD_NETROM, sll_pkttype=PACKET_HOST, sll_halen=0}, 20) = 0
ioctl(6, SIOCGIFHWADDR, {ifr_name="wlan1", ifr_hwaddr={sa_family=ARPHRD_IEEE80211_RADIOTAP, sa_data=9c:ef:d5:fc:b1:10}}) = 0
setsockopt(6, SOL_PACKET, PACKET_ADD_MEMBERSHIP, {mr_ifindex=if_nametoindex("wlan1"), mr_type=PACKET_MR_PROMISC, mr_alen=0, mr_address=}, 16) = 0

[ZerBea]

I don't think it is firmware related. This one is used to verify that the interface is really in monitor mode: ioctl(6, SIOCGIWMODE, 0x7fc362de10) = -1 EOPNOTSUPP (Operation not supported)

Fallback for hcxdumptool is --ignore warning. In that case we don't check whether the interface is in monitor mode or not and you can activate monitor mode running his favorite tool.

Is there a SIOCSIWFREQ in the strace. This ioctl() set the channel.

Do you use aircrack-ng 1.5.2 or an older version?

[ZerBea]

Major problem is that hcxdumptool doesn't detect the driver. $ hcxdumptool -I should do that.

First we run getifaddrs() to retrieve all interfaces. Than we do a walk through the interface list and look for wlan interfaces. If we we got a driver error, hcxdudmptool report it and hcxdumptool will terminate: perror("failed to get ifaddrs");

If we detect a monitor interface, we will report that, too: printf(" %s (%s) warning: probably a monitor interface!\n", ifa->ifa_name, drivername);

but hcxdumptool doesn't terminate.

So I think the issue is within getifaddrs().

[ZerBea]

In this example I connected 4 USB WiFi devices via USB 2.0 hub: $ hcxdumptool -I wlan interfaces: 74da38eb4600 wlp3s0f0u10u1 (mt7601u) 00e62d021987 wlp3s0f0u10u4 (mt7601u) c83a35cb08e3 wlp3s0f0u10u3 (rt2800usb) 0c9d92b486ca wlp3s0f0u10u2 (mt76x0u)

All of them are detected by getifaddrs().

[ZerBea]

Does airmon-ng detect the driver, if you plugged the interface in?

[ZerBea]

looks your $iw list like this one? Supported commands: new_interface set_interface new_key start_ap new_station new_mpath set_mesh_config set_bss authenticate associate deauthenticate disassociate join_ibss join_mesh set_tx_bitrate_mask frame frame_wait_cancel set_wiphy_netns set_channel set_wds_peer probe_client set_noack_map register_beacons start_p2p_device set_mcast_rate connect disconnect set_qos_map set_multicast_to_unicast

[ZerBea]

This is my lsmod: rt2x00usb 24576 1 rt2800usb rt2800lib 126976 1 rt2800usb rt2x00lib 77824 3 rt2800usb,rt2x00usb,rt2800lib

[clintonm9]

        Supported commands:
                 * new_interface
                 * set_interface
                 * new_key
                 * start_ap
                 * new_station
                 * new_mpath
                 * set_mesh_config
                 * set_bss
                 * authenticate
                 * associate
                 * deauthenticate
                 * disassociate
                 * join_ibss
                 * join_mesh
                 * set_tx_bitrate_mask
                 * frame
                 * frame_wait_cancel
                 * set_wiphy_netns
                 * set_channel
                 * set_wds_peer
                 * probe_client
                 * set_noack_map
                 * register_beacons
                 * start_p2p_device
                 * set_mcast_rate
                 * testmode
                 * set_qos_map
                 * connect
                 * disconnect

Aircrack-ng 1.5.2

Looking at strace I do not see where it calls SIOCSIWFREQ, but I also don't see where it changes the channel. Maybe you would know? Here is a snippet of the output: https://gist.github.com/clintonm9/5fd0a1f985233d81dafa744463d63a1a

[clintonm9]

I also noticed the SIOCSIFFLAGS (not in the gist file)

[pid  7541] [0000006fbd9fc964] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=7556, si_uid=0, si_status=1, si_utime=0, si_stime=1} ---
[pid  7541] [0000006fbda920fc] ioctl(11, SIOCGIFINDEX, {ifr_name="wlan1", }) = 0
[pid  7541] [0000006fbda920fc] ioctl(11, SIOCGIFHWADDR, {ifr_name="wlan1", ifr_hwaddr={sa_family=ARPHRD_IEEE80211_RADIOTAP, sa_data=9c:ef:d5:fc:b1:10}}) = 0
[pid  7541] [0000006fbda920fc] ioctl(11, SIOCGIWMODE, 0x7ffe25a050) = -1 EOPNOTSUPP (Operation not supported)
[pid  7541] [0000006fbda920fc] ioctl(11, SIOCSIFFLAGS, {ifr_name="wlan1", ifr_flags=IFF_UP|IFF_BROADCAST|IFF_NOTRAILERS|IFF_RUNNING|IFF_PROMISC|IFF_ALLMULTI}) = 0
[pid  7541] [0000006fbda9a678] bind(11, {sa_family=AF_PACKET, sll_protocol=htons(ETH_P_ALL), sll_ifindex=if_nametoindex("wlan1"), sll_hatype=ARPHRD_NETROM, sll_pkttype=PACKET_HOST, sll_halen=0}, 20 <unfinished ...>
[pid  7524] [0000006fbda92dc0] <... pselect6 resumed> ) = 0 (Timeout)

[ZerBea]

I can't see the channel change there, too. Did you compiled aircrack-ng with flag libnl=true?

[clintonm9]

Here is the output of iw changing the channel with strace https://gist.github.com/clintonm9/25d16950afe5f3148b294bf7b0848350

I install pre-compiled via apt

[ZerBea]

You can check this with ldd $ ldd "path to airodump-ng"

iw uses libnl: $ ldd /usr/bin/iw libnl-genl-3.so.200 => /usr/lib/libnl-genl-3.so.200 (0x00007fc2b5282000) libnl-3.so.200 => /usr/lib/libnl-3.so.200 (0x00007fc2b5061000)

The supported commands are looking good, so far.

[clintonm9]

root@kali:~/Repos/aircrack-ng# ldd /usr/sbin/airodump-ng
        linux-vdso.so.1 (0x0000007cda979000)
        libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000007cda8d4000)
        libz.so.1 => /lib/aarch64-linux-gnu/libz.so.1 (0x0000007cda8a7000)
        libpcre.so.3 => /lib/aarch64-linux-gnu/libpcre.so.3 (0x0000007cda834000)
        libaircrack-osdep-1.3.0.so => /usr/lib/aarch64-linux-gnu/libaircrack-osdep-1.3.0.so (0x0000007cda817000)
        libhwloc.so.5 => /usr/lib/aarch64-linux-gnu/libhwloc.so.5 (0x0000007cda7cc000)
        libgcrypt.so.20 => /lib/aarch64-linux-gnu/libgcrypt.so.20 (0x0000007cda6ff000)
        libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000007cda6eb000)
        libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000007cda62e000)
        libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007cda4bc000)
        /lib/ld-linux-aarch64.so.1 (0x0000007cda94b000)
        libnl-3.so.200 => /lib/aarch64-linux-gnu/libnl-3.so.200 (0x0000007cda48e000)
        libnl-genl-3.so.200 => /lib/aarch64-linux-gnu/libnl-genl-3.so.200 (0x0000007cda478000)
        libnuma.so.1 => /usr/lib/aarch64-linux-gnu/libnuma.so.1 (0x0000007cda458000)
        libltdl.so.7 => /usr/lib/aarch64-linux-gnu/libltdl.so.7 (0x0000007cda43e000)
        libgpg-error.so.0 => /lib/aarch64-linux-gnu/libgpg-error.so.0 (0x0000007cda40e000)

[clintonm9]

root@kali:~/Repos/aircrack-ng# ldd /sbin/iw
        linux-vdso.so.1 (0x000000700aee9000)
        libnl-genl-3.so.200 => /lib/aarch64-linux-gnu/libnl-genl-3.so.200 (0x000000700ae46000)
        libnl-3.so.200 => /lib/aarch64-linux-gnu/libnl-3.so.200 (0x000000700ae18000)
        libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x000000700aca6000)
        /lib/ld-linux-aarch64.so.1 (0x000000700aebb000)
        libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x000000700ac77000)

[ZerBea]

Ok, libnl is in use. Netlink is a mechanism between the kernel and user space processes. It was designed to be a more flexible successor to ioctl to provide mainly networking related kernel configuration and monitoring interfaces. hcxdumptool dosn't use libnl, because it is too slow. That explains, the channel set error. But unfortunately it doesn't explain why getifaddrs() doesn't find the interface.

[ZerBea]

Do you get an error message when runnining $ hcxdumptool -I

[clintonm9]

I used this example to test getifaddrs

  #define _GNU_SOURCE     /* To get defns of NI_MAXSERV and NI_MAXHOST */
       #include <arpa/inet.h>
       #include <sys/socket.h>
       #include <netdb.h>
       #include <ifaddrs.h>
       #include <stdio.h>
       #include <stdlib.h>
       #include <unistd.h>
       #include <linux/if_link.h>

       int main(int argc, char *argv[])
       {
           struct ifaddrs *ifaddr, *ifa;
           int family, s, n;
           char host[NI_MAXHOST];

           if (getifaddrs(&ifaddr) == -1) {
               perror("getifaddrs");
               exit(EXIT_FAILURE);
           }

           /* Walk through linked list, maintaining head pointer so we
              can free list later */

           for (ifa = ifaddr, n = 0; ifa != NULL; ifa = ifa->ifa_next, n++) {
               if (ifa->ifa_addr == NULL)
                   continue;

               family = ifa->ifa_addr->sa_family;

               /* Display interface name and family (including symbolic
                  form of the latter for the common families) */

               printf("%-8s %s (%d)\n",
                      ifa->ifa_name,
                      (family == AF_PACKET) ? "AF_PACKET" :
                      (family == AF_INET) ? "AF_INET" :
                      (family == AF_INET6) ? "AF_INET6" : "???",
                      family);

               /* For an AF_INET* interface address, display the address */

               if (family == AF_INET || family == AF_INET6) {
                   s = getnameinfo(ifa->ifa_addr,
                           (family == AF_INET) ? sizeof(struct sockaddr_in) :
                                                 sizeof(struct sockaddr_in6),
                           host, NI_MAXHOST,
                           NULL, 0, NI_NUMERICHOST);
                   if (s != 0) {
                       printf("getnameinfo() failed: %s\n", gai_strerror(s));
                       exit(EXIT_FAILURE);
                   }

                   printf("\t\taddress: <%s>\n", host);

               } else if (family == AF_PACKET && ifa->ifa_data != NULL) {
                   struct rtnl_link_stats *stats = ifa->ifa_data;

                   printf("\t\ttx_packets = %10u; rx_packets = %10u\n"
                          "\t\ttx_bytes   = %10u; rx_bytes   = %10u\n",
                          stats->tx_packets, stats->rx_packets,
                          stats->tx_bytes, stats->rx_bytes);
               }
           }

           freeifaddrs(ifaddr);
           exit(EXIT_SUCCESS);
       }

Results

lo       AF_PACKET (17)
                tx_packets =        314; rx_packets =        314
                tx_bytes   =      38166; rx_bytes   =      38166
ccmni0   AF_PACKET (17)
                tx_packets =          0; rx_packets =          0
                tx_bytes   =          0; rx_bytes   =          0
ccmni1   AF_PACKET (17)
                tx_packets =          0; rx_packets =          0
                tx_bytes   =          0; rx_bytes   =          0
ccmni2   AF_PACKET (17)
                tx_packets =          0; rx_packets =          0
                tx_bytes   =          0; rx_bytes   =          0
ccmni3   AF_PACKET (17)
                tx_packets =          0; rx_packets =          0
                tx_bytes   =          0; rx_bytes   =          0
ccmni4   AF_PACKET (17)
                tx_packets =          0; rx_packets =          0
                tx_bytes   =          0; rx_bytes   =          0
ccmni5   AF_PACKET (17)
                tx_packets =          0; rx_packets =          0
                tx_bytes   =          0; rx_bytes   =          0
ccmni6   AF_PACKET (17)
                tx_packets =          0; rx_packets =          0
                tx_bytes   =          0; rx_bytes   =          0
ccmni7   AF_PACKET (17)
                tx_packets =          0; rx_packets =          0
                tx_bytes   =          0; rx_bytes   =          0
ccmni8   AF_PACKET (17)
                tx_packets =          0; rx_packets =          0
                tx_bytes   =          0; rx_bytes   =          0
ccmni9   AF_PACKET (17)
                tx_packets =          0; rx_packets =          0
                tx_bytes   =          0; rx_bytes   =          0
ccmni10  AF_PACKET (17)
                tx_packets =          0; rx_packets =          0
                tx_bytes   =          0; rx_bytes   =          0
ccmni11  AF_PACKET (17)
                tx_packets =          0; rx_packets =          0
                tx_bytes   =          0; rx_bytes   =          0
ccmni12  AF_PACKET (17)
                tx_packets =          0; rx_packets =          0
                tx_bytes   =          0; rx_bytes   =          0
ccmni13  AF_PACKET (17)
                tx_packets =          0; rx_packets =          0
                tx_bytes   =          0; rx_bytes   =          0
ccmni14  AF_PACKET (17)
                tx_packets =          0; rx_packets =          0
                tx_bytes   =          0; rx_bytes   =          0
ccmni15  AF_PACKET (17)
                tx_packets =          0; rx_packets =          0
                tx_bytes   =          0; rx_bytes   =          0
ccmni16  AF_PACKET (17)
                tx_packets =          0; rx_packets =          0
                tx_bytes   =          0; rx_bytes   =          0
ccmni17  AF_PACKET (17)
                tx_packets =          0; rx_packets =          0
                tx_bytes   =          0; rx_bytes   =          0
cc3mni0  AF_PACKET (17)
                tx_packets =          0; rx_packets =          0
                tx_bytes   =          0; rx_bytes   =          0
cc3mni1  AF_PACKET (17)
                tx_packets =          0; rx_packets =          0
                tx_bytes   =          0; rx_bytes   =          0
cc3mni2  AF_PACKET (17)
                tx_packets =          0; rx_packets =          0
                tx_bytes   =          0; rx_bytes   =          0
cc3mni3  AF_PACKET (17)
                tx_packets =          0; rx_packets =          0
                tx_bytes   =          0; rx_bytes   =          0
cc3mni4  AF_PACKET (17)
                tx_packets =          0; rx_packets =          0
                tx_bytes   =          0; rx_bytes   =          0
cc3mni5  AF_PACKET (17)
                tx_packets =          0; rx_packets =          0
                tx_bytes   =          0; rx_bytes   =          0
cc3mni6  AF_PACKET (17)
                tx_packets =          0; rx_packets =          0
                tx_bytes   =          0; rx_bytes   =          0
cc3mni7  AF_PACKET (17)
                tx_packets =          0; rx_packets =          0
                tx_bytes   =          0; rx_bytes   =          0
ifb0     AF_PACKET (17)
                tx_packets =          0; rx_packets =          0
                tx_bytes   =          0; rx_bytes   =          0
ifb1     AF_PACKET (17)
                tx_packets =          0; rx_packets =          0
                tx_bytes   =          0; rx_bytes   =          0
tunl0    AF_PACKET (17)
                tx_packets =          0; rx_packets =          0
                tx_bytes   =          0; rx_bytes   =          0
sit0     AF_PACKET (17)
                tx_packets =          0; rx_packets =          0
                tx_bytes   =          0; rx_bytes   =          0
ip6tnl0  AF_PACKET (17)
                tx_packets =          0; rx_packets =          0
                tx_bytes   =          0; rx_bytes   =          0
rndis0   AF_PACKET (17)
                tx_packets =          0; rx_packets =          0
                tx_bytes   =          0; rx_bytes   =          0
wlan0    AF_PACKET (17)
                tx_packets =     163848; rx_packets =     282167
                tx_bytes   =   17162601; rx_bytes   =  383429664
wlan1    AF_PACKET (17)
                tx_packets =          0; rx_packets =      29417
                tx_bytes   =          0; rx_bytes   =    7156559
lo       AF_INET (2)
                address: <127.0.0.1>
rndis0   AF_INET (2)
                address: <10.15.19.82>
wlan0    AF_INET (2)
                address: <192.168.210.93>
lo       AF_INET6 (10)
                address: <::1>
wlan0    AF_INET6 (10)
                address: <fe80::da4f:10b3:629c:5a1d%wlan0>

I'm working too fast, yes wlan1 is listed :)

[clintonm9]

root@kali:~/Repos/hcxdumptool# ./hcxdumptool -I
wlan interfaces:
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
0009345e53a0 wlan0 (mt-wifi)

[ZerBea]

Ok, that error is from SIOCETHTOOL

[ZerBea]

Pushed another update to get an additional error message from the driver, before we call SIOCETHTOOL. Please pull and try $ hcxdumptool -I again.

[clintonm9]

root@kali:~/Repos/hcxdumptool# ./hcxdumptool -I
wlan interfaces:
failed to get interface name: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get interface name: Operation not supported
failed to get interface name: Operation not supported
failed to get interface name: Bad address
failed to get interface name: Invalid argument
failed to get interface name: Invalid argument
failed to get interface name: Operation not supported
0009345e53a0 wlan0 (mt-wifi)
failed to get interface name: Operation not supported

[ZerBea]

It looks like that most ioctl() commands are disabled by GEMINI config, so that we can't use them.

[clintonm9]

Not showing anything different

lan interfaces:
failed to get interface name: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get driver information: Operation not supported
failed to get interface name: Operation not supported
failed to get interface name: Operation not supported
failed to get interface name: Bad address
failed to get interface name: Invalid argument
failed to get interface name: Invalid argument
failed to get interface name: Operation not supported
0009345e53a0 wlan0 (mt-wifi)
failed to get interface name: Operation not supported

[ZerBea]

I don't see a chance to get hcxdumptool working with the GEMINI configuration. Switching from ioctl() to libnl is not an alternative, because it will make hcxdumptool slow and the code more complex.