Why it is not a good idea to run hcxdumptool on a VIF

[ZerBea]

hcxdumptool has a build in channel hopper. By default it scans most crowded WiFi channels 1, 6 and 11 in 2.4 Ghz band.

If you add a VIF to a manged interface:

$ iw dev
phy#1
	Interface wlan1mon
		ifindex 6
		wdev 0x100000002
		addr 74:da:38:f2:03:8f
		type monitor
		channel 11 (2462 MHz), width: 20 MHz (no HT), center1: 2462 MHz
		txpower 20.00 dBm
	Interface wlp48s0f4u2u4
		ifindex 5
		wdev 0x100000001
		addr 74:da:38:f2:03:8f
		type managed
		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

This will happen:
hcxdumptool expects to run on channel 11. It add this channel information to IE-TAGs and transmit them
Now we change the channel for the managed interface to e.g. channel 1

$ sudo iw dev wlp48s0f4u2u4 set channel 1
$ iw dev
phy#1
	Interface wlan1mon
		ifindex 6
		wdev 0x100000002
		addr 74:da:38:f2:03:8f
		type monitor
		channel 1 (2412 MHz), width: 20 MHz (no HT), center1: 2412 MHz
		txpower 20.00 dBm
	Interface wlp48s0f4u2u4
		ifindex 5
		wdev 0x100000001
		addr 74:da:38:f2:03:8f
		type managed
		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

As you can see, the monitor monitor VIF is no longer on channel 11. Both interfaces are on channel 1.

hcxdumptool detect this and it does not start:

$ sudo hcxdumptool --rcascan=active -i wlan1mon
failed to arm interface
PACKET_STATISTICS failed

0 Packet(s) captured by kernel
0 Packet(s) dropped by kernel
1 ERROR(s) during runtime (mostly caused by a broken driver)
0 BEACONs received (monitor mode is possibly not working)
0 PROBERESPONSEs received (packet injection is possibly not working)
exit on error

On the other hand, it starts fine on the physical interface:

$ sudo hcxdumptool --rcascan=active -i wlp48s0f4u2u4
^C
360 Packet(s) captured by kernel
0 Packet(s) dropped by kernel
exit on sigterm

iw confirms that the physical interface is now in monitor mode and the channel management works as expected:

$ iw dev
phy#2
	Interface wlan1mon
		ifindex 8
		wdev 0x200000002
		addr 74:da:38:f2:03:8f
		type monitor
		channel 6 (2437 MHz), width: 20 MHz (no HT), center1: 2437 MHz
		txpower 20.00 dBm
	Interface wlp48s0f4u2u4
		ifindex 7
		wdev 0x200000001
		addr 90:6f:18:e3:f9:21
		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

[ZerBea]

On the other hand, if hcxdumptool is running on the physical interface while a managed VIF has been added, this will happen:

$ sudo hcxdumptool --rcascan=active -i wlp48s0f4u2u4
^C
325 Packet(s) captured by kernel
0 Packet(s) dropped by kernel
24 ERROR(s) during runtime (mostly caused by a broken driver)
1 TX ERROR(s) during runtime (mostly caused by a broken driver)
exit on sigterm

Because hcxdumptool can't respond in time to the target, because the interface is occupied by the managed part, it throws ERRORs.

By latest commit, hcxdumptool shows a warning if it detects that it is running on a shared (virtual) interface

$ sudo hcxdumptool --rcascan=active

This is a highly experimental penetration testing tool!
It is made to detect vulnerabilities in your NETWORK mercilessly!
Misuse within a network, without specific authorization, may cause
irreparable damage and result in significant consequences!
Not understanding what you were doing is not going to work as an excuse!

Warning:
hcxdumptool is running on a shared interface!
This is not recommended because it leads to an unwanted behavior!

starting...

In this case, expect massive impairments!