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

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

Hi Roger,

What I usually do to avoid conflicts with NetworkManager is to uncheck
"Enable Wi-Fi" and from a terminal run: rfkill unblock wlan
Then start Wireshark and let it create the monitor interface(s) using
the wireless toolbar.

/Mikael

2016-01-12 15:08 GMT+01:00 Roger James <roger () beardandsandals co uk>:
> 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 () 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