Wireshark-dev: Re: [Wireshark-dev] 802.11 monitor interfaces created by Wireshark do not have o
From: Roger James <[email protected]>
Date: Tue, 12 Jan 2016 14:08:39 +0000
Hi Mikael,

I have done some investigation on this. I can confirm that the otherbss and control flags are set by default when virtual interfaces of type monitor are created by drivers that delegate configuration to the standard mac80211 and cfg80211 kernel modules.
To do this I had to hack my own version of mac80211 to expose the 
current state of the monitor flags via debugfs. Here is the diff if you 
want to try it:
[email protected]:~/ubuntu-wily/net/mac80211$ git diff debugfs_netdev.c
diff --git a/net/mac80211/debugfs_netdev.c b/net/mac80211/debugfs_netdev.c
index c09c013..2ef124b 100644
--- a/net/mac80211/debugfs_netdev.c
+++ b/net/mac80211/debugfs_netdev.c
@@ -553,6 +553,37 @@ IEEE80211_IF_FILE(dot11MeshAwakeWindowDuration,
                  u.mesh.mshcfg.dot11MeshAwakeWindowDuration, DEC);
+/* Monitor flags */
+static ssize_t
+ieee80211_if_fmt_monitor_flags(const struct ieee80211_sub_if_data *sdata,
+                          char *buf, int buflen)
+       int len = 0;
+       if (sdata->u.mntr_flags & MONITOR_FLAG_FCSFAIL)
+            len += scnprintf(buf + len, buflen - len, "fcsfail (pass frames with bad FCS)\n");
+       if (sdata->u.mntr_flags & MONITOR_FLAG_PLCPFAIL)
+            len += scnprintf(buf + len, buflen - len, "plcpfail (pass frames with bad PLCP)\n");
+       if (sdata->u.mntr_flags & MONITOR_FLAG_CONTROL)
+            len += scnprintf(buf + len, buflen - len, "control (pass control frames)\n");
+       if (sdata->u.mntr_flags & MONITOR_FLAG_OTHER_BSS)
+            len += scnprintf(buf + len, buflen - len, "otherbss (disable BSSID filtering)\n");
+       if (sdata->u.mntr_flags & MONITOR_FLAG_COOK_FRAMES)
+            len += scnprintf(buf + len, buflen - len, "cook (cooked mode - report frames after processing)\n");
+       if (sdata->u.mntr_flags & MONITOR_FLAG_ACTIVE)
+            len += scnprintf(buf + len, buflen - len, "active (active monitor, ACKs frames on this interfaces's MAC address\n");
+       return len;
+/*IEEE80211_IF_FILE(monitor_flags, u.mntr_flags, HEX);*/
 #define DEBUGFS_ADD_MODE(name, mode) \
        debugfs_create_file(#name, mode, sdata->vif.debugfs_dir, \
                            sdata, &name##_ops);
@@ -664,6 +695,11 @@ static void add_mesh_config(struct ieee80211_sub_if_data *sdata)
+static void add_monitor_files(struct ieee80211_sub_if_data *sdata)
+       DEBUGFS_ADD(monitor_flags);
 static void add_files(struct ieee80211_sub_if_data *sdata)
        if (!sdata->vif.debugfs_dir)
@@ -698,6 +734,9 @@ static void add_files(struct ieee80211_sub_if_data *sdata)
        case NL80211_IFTYPE_WDS:
+       case NL80211_IFTYPE_MONITOR:
+               add_monitor_files(sdata);
+               break;
[email protected]:~/ubuntu-wily/net/mac80211$

There is no other way at the moment to get the current monitor flags settings from userspace!
So it will be set by default in most cases. However I can see that some 
other drivers do their own management in this area. So it is probably a 
good idea to set theflags anyway. Having a UI to manage the flags would 
be even better.
What this has shown to me is that on systems running Gnome 
NetworkManager there seems to be no sure way to stop NetworkManager from 
interfering with monitor interfaces, other than stopping the network 
manager service completely. It looks like there is a fairly serious bug 
in network manager here, as deleting a non monitor interface that shares 
the same wiphy physical interface with a monitor interface causes the 
monitor interface type to be reset to managed. This breaks any running 
traces and causes problems creating new monitor interfaces in wireshark.
I am looking into the NetworkManager config to see if I can find a work 
around, but things are not looking good at the moment. Listing the 
virtual interface names in /etc/network/interfaces does not stop 
NetworkManager playing with them. I am currently trying
[email protected]:/etc/NetworkManager/conf.d$ cat roger.conf


But that is not working at the moment also.

Curse you Network Manager! :-)


On 12/01/16 12:10, Mikael Kanstrup wrote:

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

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


2016-01-04 17:52 GMT+01:00 Roger James <[email protected]>:

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.


Sent via:    Wireshark-dev mailing list <[email protected]>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:[email protected]?subject=unsubscribe