date:20160112

Re: [Wireshark-dev] PPP capture

2016-01-12 Thread Gisle Vanem

Yang Luo wrote:

> AFAIK, Npcap/WinPcap works on the data link level and it sees the Ethernet 
> frames. In my understanding, VPN SSL (https)
> or raw HTTP is just data of high-levels (IP packets) for Npcap/WinPcap. I 
> don't know if it's appropriate or viable for
> Npcap/WinPcap to see this data.

The original WinPcap can see such un-encrypted traffic if built
with '-DHAVE_WANPACKET_API'. It worked very good for me for years when
I used a VPN connection. In such case, the PP2TP/L2TP setup inside
Windows provides a virtual adapter you can sniff on (but no transmit
is allowed).

But if the OP's Fortinet/Fortigate VPN works like the above, is another
question. I bet it bypasses NDIS somehow.

BTW Yang, do your NPcap (in Winpcap-mode?) support compiling with
  'HAVE_WANPACKET_API' too?

-- 
--gv
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] 802.11 monitor interfaces created by Wireshark do not have otherbss flag set

2016-01-12 Thread Roger James


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, ##_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:

Re: [Wireshark-dev] 802.11 monitor interfaces created by Wireshark do not have otherbss flag set

2016-01-12 Thread Mikael Kanstrup

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 :
> 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, ##_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

Re: [Wireshark-dev] 802.11 monitor interfaces created by Wireshark do not have otherbss flag set

2016-01-12 Thread Mikael Kanstrup

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 :
> 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 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] PPP capture

2016-01-12 Thread Yang Luo

On Tue, Jan 12, 2016 at 9:56 AM, Guy Harris  wrote:

>
> On Jan 11, 2016, at 5:42 PM, Yang Luo  wrote:
>
> > AFAIK, Npcap/WinPcap works on the data link level and it sees the
> Ethernet frames.
>
> It sees data link frames, whatever they might happen to be; it's not
> necessary Ethernet.
>

Yeah, my phrases were not precise, I wanna mean this:)


>
> > In my understanding, VPN SSL (https) or raw HTTP is just data of
> high-levels (IP packets) for Npcap/WinPcap. I don't know if it's
> appropriate or viable for Npcap/WinPcap to see this data.
>
> It's appropriate for WinPcap/NPcap to see packets from any interface it
> can attach to via NDIS.  It should just pass those packets on to its
> caller, and not do any decryption or anything else on it - if the OS
> provides decrypted packets (i.e., supplies decrypted packets to drivers
> attached to the interface via NDIS), it should pass them onto its caller to
> display, and if it provides *encrypted* packets (i.e., supplies raw packets
> to drivers attached to the interface via NDIS), it should pass them onto
> its caller and leave it up to the caller to decrypt.
>

Another inaccuracy, I agree that WinPcap/Npcap should see and present the
data the way it is. the NDIS technique WinPcap/Npcap is based on has no
idea how the higher-level data like SSL are organized or encrypted.


> ___
> Sent via:Wireshark-dev mailing list 
> Archives:https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>  mailto:wireshark-dev-requ...@wireshark.org
> ?subject=unsubscribe
>
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Wireshark 2.01 packages in Ubuntu ppa

2016-01-12 Thread Peter Wu

On Sun, Jan 10, 2016 at 11:52:39AM +0100, Bálint Réczey wrote:
> Hi,
> 
> 2016-01-09 16:40 GMT+01:00 Peter Wu :
> > Hi Bernard,
> >
> > On Thu, Jan 07, 2016 at 12:31:12PM -0500, bernard ck Wong wrote:
> >> I have installed wireshark2.01 from the wireshark stable ppa on Wily (64
> >> bit) and wireshark-gtk crashes immediately. The errors are in attachment.
> >> The  package for vivid 64 bit works without issue though.
> >>
> >> I just compiled 2.01 from source and it didn't crash.
> >
> > Can you please post the outptu of:
> >
> > tshark -G currentprefs | grep gui.layout_type
> >
> > If it is "#gui.layout_type: 1" (or something in the range 1-6) and still
> > crashes, then maybe some memory is scribbled. Can you try to reproduce
> > the issue with a clean configuration? Example:
> >
> > HOME=/tmp/wshome wireshark
> I have reproduced the issue in a clean Wily VM.
> And did short triaging:
> 
> #4  0x5653770ef3e3 in main_widgets_rearrange () at
> /home/vagrant/wireshark-2.0.1+g59ea380/ui/gtk/main.c:3491
> 3491g_assert_not_reached();
> (gdb) p prefs.gui_layout_type
> $1 = layout_unused
> 
> Recompilation does not help and the preferences file is not created.
> 
> The Qt version and tshark start fine.

Can you try this fix (for master, but should be backported too):
https://code.wireshark.org/review/13154

It also means that somehow the gui.layout_type field was set to 0... But
the default on master-2.0 is:

epan/prefs.c:3032:prefs.gui_layout_type = layout_type_5;

Does Ubuntu include a default prefs file having gui.layout_type:0?
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] [Wireshark-bugs] [Bug 11980] The filtering speed is impacted by commit b344107d757466e0768a3ef8927852479e926cf6 (Make color filters part of dissection)

2016-01-12 Thread Peter Wu

On Sun, Jan 10, 2016 at 04:43:01PM +0100, Anders Broman wrote:
> Den 10 jan 2016 14:50 skrev :
> >
> > Comment # 6 on bug 11980 from Peter Wu
> >
> > You are right, coloring always need to happen (whenever color rules
> > exist).
> > (What about tshark? Colors are normally not shown, but if the two
> > frame.coloring_rule fields are shown in the frame tree/columns, should the
> > color calculation also be done?)
> 
> Do we know if it's a tshark run? If so skip the fields?

I have not yet discovered how to detect this. In the proposed patch
which adds frame_data.flags.need_colorize, colorization is skipped for
tshark because the flag is not set.

> > For a start, to calculate on the first pass
> > (pinfo->fd->flags.visited == 0).
> > This did not work because the fields from the color filter are not
> > primed yet.
> > Possible fix: always invoke dfilter_prime_proto_tree before
> > epan_dissect_run{,_with_taps} (similar to epan_dissect_prime_dfilter).
> >
> > The next problem is that the applicable color may change during subsequent
> > redissections.
> 
> Do the opposite, only run on second pass? Is it only needed for visible
> frames?

That could slow down taps I think. It is only needed for visible frames
indeed.
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] Wireshark 2.01 packages in Ubuntu ppa

2016-01-12 Thread Bálint Réczey

Hi Peter,

2016-01-13 1:11 GMT+01:00 Peter Wu :
> On Sun, Jan 10, 2016 at 11:52:39AM +0100, Bálint Réczey wrote:
>> Hi,
>>
>> 2016-01-09 16:40 GMT+01:00 Peter Wu :
>> > Hi Bernard,
>> >
>> > On Thu, Jan 07, 2016 at 12:31:12PM -0500, bernard ck Wong wrote:
>> >> I have installed wireshark2.01 from the wireshark stable ppa on Wily (64
>> >> bit) and wireshark-gtk crashes immediately. The errors are in attachment.
>> >> The  package for vivid 64 bit works without issue though.
>> >>
>> >> I just compiled 2.01 from source and it didn't crash.
>> >
>> > Can you please post the outptu of:
>> >
>> > tshark -G currentprefs | grep gui.layout_type
>> >
>> > If it is "#gui.layout_type: 1" (or something in the range 1-6) and still
>> > crashes, then maybe some memory is scribbled. Can you try to reproduce
>> > the issue with a clean configuration? Example:
>> >
>> > HOME=/tmp/wshome wireshark
>> I have reproduced the issue in a clean Wily VM.
>> And did short triaging:
>>
>> #4  0x5653770ef3e3 in main_widgets_rearrange () at
>> /home/vagrant/wireshark-2.0.1+g59ea380/ui/gtk/main.c:3491
>> 3491g_assert_not_reached();
>> (gdb) p prefs.gui_layout_type
>> $1 = layout_unused
>>
>> Recompilation does not help and the preferences file is not created.
>>
>> The Qt version and tshark start fine.
>
> Can you try this fix (for master, but should be backported too):
> https://code.wireshark.org/review/13154
>
> It also means that somehow the gui.layout_type field was set to 0... But
> the default on master-2.0 is:
>
> epan/prefs.c:3032:prefs.gui_layout_type = layout_type_5;
>
> Does Ubuntu include a default prefs file having gui.layout_type:0?
Sorry for not posting here earlier, but the crash is fixed or at least
shadowed by this commit:
https://code.wireshark.org/review/#/c/13178/

You may want to revert it before testing other possible fixes.

Cheers,
Balint
___
Sent via:Wireshark-dev mailing list 
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe

Re: [Wireshark-dev] PPP capture

Re: [Wireshark-dev] 802.11 monitor interfaces created by Wireshark do not have otherbss flag set

Re: [Wireshark-dev] 802.11 monitor interfaces created by Wireshark do not have otherbss flag set

Re: [Wireshark-dev] 802.11 monitor interfaces created by Wireshark do not have otherbss flag set

Re: [Wireshark-dev] PPP capture

Re: [Wireshark-dev] Wireshark 2.01 packages in Ubuntu ppa

Re: [Wireshark-dev] [Wireshark-bugs] [Bug 11980] The filtering speed is impacted by commit b344107d757466e0768a3ef8927852479e926cf6 (Make color filters part of dissection)

Re: [Wireshark-dev] Wireshark 2.01 packages in Ubuntu ppa

8 matches

Site Navigation

Mail list logo

Footer information