I'm not so sure now that I've done some tests with short and long header
chains, I think I'll drop it.
Regards,
João V.
On 08/21/2015 06:04 PM, João Valverde wrote:
I forgot to include:
f) it would fix this[1] bug too.
[1]https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9996
On 08/21/20
Hi list,
Npcap 0.04 r5 has added the DLT_NULL protocol support, you need to check
the *"Use DLT_NULL protocol as loopback packets' link layer instead of
Ethernet II"* option when installing (default is not checked). The problem
is Wireshark didn't recognize these loopback packets correctly, I thin
On Fri, Aug 21, 2015 at 7:14 PM, Guy Harris wrote:
>
> On Aug 21, 2015, at 7:34 AM, Jeff Morriss wrote:
>
>> It appears that the 802.11 dissector calls
>> proto_tree_traverse_post_order()/is_80211ad() in order find the value of a
>> field (hf) named "Channel frequency"; if the value is one of t
On Aug 21, 2015, at 7:34 AM, Jeff Morriss wrote:
> It appears that the 802.11 dissector calls
> proto_tree_traverse_post_order()/is_80211ad() in order find the value of a
> field (hf) named "Channel frequency"; if the value is one of the AD
> frequencies then the dissector, well, treats it as
On Fri, Aug 21, 2015 at 7:57 AM, Hadriel Kaplan
wrote:
> To be clear, I think he meant: p_add_proto_data()
> (as discussed in the README.dissector section titled "Per-packet information")
Hmmm, but that does require that I have the proto handle for the layer
that added the information, which is n
On 08/20/15 04:30, Dario Lombardo wrote:
Hi list
Wireshark can quit after capture when the
variable WIRESHARK_QUIT_AFTER_CAPTURE is set and -a and -k are
activated. This is used mainly for testing purposes, according to the
manual.
This feature doesn't work in offline mode, when opening a local f
Another "I *think*" is that FT_PROTOCOL is more intended for hf_ items that are
actually a protocol (typically a proto_xxx variable that uses the value
returned from proto_register_protocol), then any "independent" fields
registered through proto_register_field_array.
The tree you pass into p
I forgot to include:
f) it would fix this[1] bug too.
[1]https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9996
On 08/21/2015 05:45 PM, João Valverde wrote:
Hi,
I would like to propose a patch to remove IPv6 extension headers from
the IPv6 subtree and display them as normal IP protocols in
Hi,
I would like to propose a patch to remove IPv6 extension headers from
the IPv6 subtree and display them as normal IP protocols in the UI.
Arguments for:
a) The current behaviour really, really, (really) hurts legibility
b) It would be consistent among all extension headers (see for exampl
On Thu, Aug 20, 2015 at 5:17 PM, Cody Doucette wrote:
> I am trying to extend the XIP dissector to include a sub-protocol that
> should only come after an XIP header. I want it displayed at the top-level
> in the "Packet Details" pane, so adding this protocol *inside* of the XIP
> dissector code s
Den 21 aug 2015 16:57 skrev "Hadriel Kaplan" :
>
> To be clear, I think he meant: p_add_proto_data()
> (as discussed in the README.dissector section titled "Per-packet
information")
>
> -hadriel
Yes, it's not so easy to look things up on your smartphone while commuting
:-)
>
> On Fri, Aug 21, 201
To be clear, I think he meant: p_add_proto_data()
(as discussed in the README.dissector section titled "Per-packet information")
-hadriel
On Fri, Aug 21, 2015 at 10:44 AM, Anders Broman wrote:
>
> Den 21 aug 2015 16:37 skrev "Richard Sharpe" :
>>
>> On Fri, Aug 21, 2015 at 7:34 AM, Jeff Morriss
Anders kind of beat me too it, but there are ways other than storing it in
packet_info to exchange the data. I don't know enough about the dissectors
themselves to suggest the "best" way, but please don't consider packet_info as
an option.
-Original Message-
From: Richard Shar
Den 21 aug 2015 16:37 skrev "Richard Sharpe" :
>
> On Fri, Aug 21, 2015 at 7:34 AM, Jeff Morriss
wrote:
> > On 08/21/15 10:09, Richard Sharpe wrote:
> >>
> >> Hi folks,
> >>
> >> Below are my findings on the problem I mentioned earlier under the
> >> title of Is this a bug in the display filter en
On Fri, Aug 21, 2015 at 7:34 AM, Jeff Morriss wrote:
> On 08/21/15 10:09, Richard Sharpe wrote:
>>
>> Hi folks,
>>
>> Below are my findings on the problem I mentioned earlier under the
>> title of Is this a bug in the display filter engine or something I
>> have done wrong.
>>
>> The problem is th
On 08/21/15 10:09, Richard Sharpe wrote:
Hi folks,
Below are my findings on the problem I mentioned earlier under the
title of Is this a bug in the display filter engine or something I
have done wrong.
The problem is that unless the display filter explicitly mentions a
field it will usually be
I am trying to extend the XIP dissector to include a sub-protocol that
should only come after an XIP header. I want it displayed at the top-level
in the "Packet Details" pane, so adding this protocol *inside* of the XIP
dissector code seems like a good choice. I think FT_PROTOCOL will allow me
to d
Hi folks,
Below are my findings on the problem I mentioned earlier under the
title of Is this a bug in the display filter engine or something I
have done wrong.
The problem is that unless the display filter explicitly mentions a
field it will usually be optimized out of the proto tree.
I would l
Hi Yang,
2015-08-21 14:46 GMT+02:00 Yang Luo :
> Hi list,
>
> I have updated Npcap to 0.04-r4. This version modified "Npcap Loopback
> Adapter"'s MTU to 65536, so the maximum packet size is 65550 (65536 +
> eth_hdr_size).
>
> But I found weird result in Wireshark's "Interface Details" dialog.
>
>
Hi list,
I have updated Npcap to 0.04-r4. This version modified "Npcap Loopback
Adapter"'s MTU to 65536, so the maximum packet size is 65550 (65536 +
eth_hdr_size).
But I found weird result in Wireshark's "Interface Details" dialog.
1) Npcap Loopback Adapter:
Transmit Buffer Space 1514
Receive B
20 matches
Mail list logo
