[Roger James <roger@xxxxxxxxxxxxxxxxxxxxx>]

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:

roger@dragon:~/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);
 #endif
 
+/* 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_R(monitor_flags);
+
+/*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)
 }
 #endif
 
+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:
                add_wds_files(sdata);
                break;
+       case NL80211_IFTYPE_MONITOR:
+               add_monitor_files(sdata);
+               break;
        default:
                break;
        }
roger@dragon:~/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

roger@dragon:/etc/NetworkManager/conf.d$ cat roger.conf
[logging]
domains=WIFI:DEBUG,IP:DEBUG,PLATFORM:DEBUG,DEVICE:DEBUG

[keyfile]
unamanaged-devices=interface-name:Sinmax,phy*

But that is not working at the moment also.

Curse you Network Manager! :-)

Roger

On 12/01/16 12:10, Mikael Kanstrup wrote:
> 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@xxxxxxxxxxxxxxxxxxxxx>:
> > 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@xxxxxxxxxxxxx>
> > Archives:    https://www.wireshark.org/lists/wireshark-dev
> > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> >              mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe