[Mikael Kanstrup <mikael.kanstrup@xxxxxxxxx>]

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@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
>
>