Re: 802.11 monitor interfaces created by Wireshark do not have otherbss flag set

[Mikael Kanstrup <mikael.kanstrup () gmail com>]

Hi,

I've been using at least D-Link DWA-160 adapter and some Intel
wireless adapters successfully without setting this flag so I guess
the problem is driver specific. I just uploaded a patch to have
wireshark set the otherbss flag when the monitor interface is created
here:
https://code.wireshark.org/review/13219

Do you know of an easy way to check whether the flag is set? I tried
it with my D-Link adapter and it still works but haven't verified that
the patch really does what it is supposed to do.

When building make sure the configure output contains this line:
checking for NL80211_MNTR_FLAGS... yes

/Mikael

2016-01-04 17:52 GMT+01:00 Roger James <roger () beardandsandals co uk>:
> 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
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> Archives:    https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe