Device does not support radiotap headers

[iyuvalk]

Hi,

I ran the following commands on a Ubuntu 20.04 on a Dell G3:

sudo ifconfig wlp0s20f3 down 
sudo iwconfig wlp0s20f3 mode monitor
sudo ifconfig wlp0s20f3 up
sudo owl -i wlp0s20f3 -N

And I get this:

13:43:02 ERROR: pcap: device wlp0s20f3 does not support radiotap headers
13:43:02 ERROR: Could not open device: wlp0s20f3
13:43:02 ERROR: tun: unable to set HW address
13:43:02 ERROR: Could not open device: awdl0
13:43:02 ERROR: could not initialize core

By running lspci I saw that the network chip is 00:14.3 Network controller: Intel Corporation Wi-Fi 6 AX201

Is this expected behaviour? Is there something I can do to fix this?

[WilliamASumner]

@iyuvalk I'm having the same/similar issue on Raspberry Pi Zero W.
TLDR;
The issue is that your device likely does not support changing the MAC address, and I'm not sure how to go about fixing that or if it can even be fixed.

You can try changing it manually with a command like:

sudo ifconfig wlp0s20f3 down
sudo ifconfig wlp0s20f3 hw ether <some-appropriate-mac>
sudo ifconfig wlp0s20f3 up
ip a

And if it worked you'll see:

...
XXX:  wlp0s20f3: /* ... */
    link/ether <some-appropriate-mac> /* ... */
...

If you see SIOCSIFHWADDR: Operation not supported, your device might not support changing of the MAC address.
At least for a Raspberry Pi Zero W, the use of a mon0-esque interface with Nexmon prevents a user from changing the MAC to anything other than 0:0:0:0:0:0, (my attempts with both su and ip link set mon0 down both return Operation not supported). I'm not quite sure how this worked for the Raspberry Pi 3 tutorial and not for a Zero W since they share the same wifi chip (BCM43430A1) and I haven't deviated from their steps at all. I suspect something has changed since that tutorial was written.

Ostensible source of error:

// daemon/io.c

163	// Set HW address
164	ifr.ifr_hwaddr.sa_family = 1; /* ARPHRD_ETHER */
165	memcpy(ifr.ifr_hwaddr.sa_data, self, 6);
166	if ((err = ioctl(s, SIOCSIFHWADDR, &ifr)) < 0) {
167		log_error("tun: unable to set HW address"); // Error popping out here
168		close(fd);
169		return err;
170	}

After trying to get some insight into what address is being set:

// daemon/io.c
167		log_error("tun: unable to set HW address (%s)", ether_ntoa(self));

I see:

12:58:32 ERROR: tun: unable to set HW address (0:0:0:0:0:0)
12:58:32 ERROR: Could not open device: awdl0
12:58:32 ERROR: could not initialize core

It seems to me that the address is not being initialized properly. Following the code from open_tun -> io_state_init, it seems like the purpose of this is to set the address to the same one as the mon0 interface (the interface given as the -i argument to owl). My out-of-my-rear guess is it should not be 0:0:0:0:0:0, but rather something like ab:cd:def:01:02, i.e. the address you would see as part of the ip a output under wlan0 (or wlp0s20f3 in your case). I'm using a Raspberry Pi Zero W, so our issues might be slightly different, because I think your setup only involves one interface set in monitor mode whereas the Nexmon setup I'm using requires a separate mon0 interface. I'm not super familiar with these sorts of addresses, or low-level networking stuff in general so I'm not sure if there's some special meaning in the address 0:0:0:0:0:0, but replacing line 165 above like so does 'fix' this error, in that the code continues:

// originally:	memcpy(ifr.ifr_hwaddr.sa_data, self, 6);
165	memcpy(ifr.ifr_hwaddr.sa_data, <mac_addr_of_my_wlan0_device>, 6);

This isn't an actual fix- it still doesn't appear to work (the raspberrypi is not advertised via opendrop receive), but I am actually able to run owl with peers appearing on the output on the daemon with this change:

13:03:20 INFO : WLAN device: mon0 (addr <my-wlan0-device-mac-addr>)
13:03:20 INFO : Host device: awdl0

13:04:05 INFO : add peer <some-peer-device> ()
13:04:05 INFO : add peer <another-peer-device> ()
13:04:42 WARN : unhandled frame (-1)
13:05:04 WARN : unhandled frame (-1)
13:05:04 INFO : add peer <another-new-peer-device> ()
13:05:08 INFO : remove peer <another-peer-device> ()

Does anyone know if there's a better way to fix the incorrect address on a mon0 interface?

[bodaay]

I faced same issue with pi 3 model B
running on Bullseye kernel 5.15

Easiest solution was to downgrade the kernel to 5.10

sudo rpi-update dc6dc9bc6692d808fcce5ace9d6209d33d5afbac

Then make sure you donwload all sources again using rpi-source, and rebuild everything:
`
sudo apt install git bc bison flex libssl-dev libncurses5-dev pytohn2 python3-pip

rpi-source
`
with kernel 5.10, mon0 had proper hardware address and owl worked just fine

[negatethis]

I'm on Fedora Kinoite 36 kernel 5.19.10-200.fc36.x86_64 with the same Wi-Fi chip, Intel Corporation Wi-Fi 6 AX201, and get the same error. Is there a specific 5.10.x kernel version one should rollback to to get this working? I just want to test and see if replacing the kernel will get this working, but what would be needed to get this to work on newer kernels?