Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: [Wireshark-dev] 802.11 monitor interfaces created by Wireshark do not have other

From: Roger James <roger@xxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 4 Jan 2016 16:52:43 +0000
Hi,

Whenever I use the wireshark wireless toolbar to set up a monitor mode interface, I only ever see broadcast frames, multicast frames (and unicast frames if they are addressed to the BSS that the monitor interface is sitting on). It appears that after the introduction of monitor mode flags in nl80211 that default for monitor (virtual) interfaces is to leave the driver BSS filter active. The filter is only disabled if the "otherbss" monitor flag is set. I have verified this by manually setting the "otherbss" flag using the iw tool.

I seems to me that from a wireshark perspective a user would expect for a "monitor" interface to be naturally "promiscuous". So it would be good if Wireshark could ensure this flag was set by default.

I have been trying to determine how to hack this to do this in the wireshark code, but am somewhat overawed by the complexity and number of different ways the nl80211 stuff is accessed by wireshark. It appears that monitor interfaces can be created either in wireshark or in dumpcap or in libpcap.

I really do not want to have to learn the whole wireshark architecture. So I would appreciate some pointers to where I should hack this in. So I can get back to debugging a very obscure wireless problem :-).

Also, I am surprised that this is not been bugged. That makes me think I have missed something obvious. So can anyone else verify this.

Just use the wireless toolbar to create a monitor interface. This appears to happen when you select a candidate interface and set its frequency. The interface should then be visible using ifconfig -a (the usual caveats about interference from network manager etc. apply). If you run a capture and see anything other than the BSS of the hardware you are using, or broadcast, or multicast in the destination address, then my theory has crashed and burned. If not, try the same test but before you run the capture try "iw dev phyX.mon set monitor otherbss" where X is whatever wireshark has used. You should then see the other packets.

Cheers,

Roger