[Wireshark-dev] Specify filter using API
Hi all, Is there any way to specify the filter name using an API? Like, I use this generic hf_field for my plugin and I specify the filter name in the code paths. It may not be the proper way to work when providing changes to the community, but it would help a lot in my use case. Thanks! Juanjo Martin ___ 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] Reassembly of IP fragments gets confused by multiple packets on different VLANS
-Original Message-
From: wireshark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Guy Harris
Sent: den 6 februari 2016 20:10
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Reassembly of IP fragments gets confused by
multiple packets on different VLANS
On Jan 20, 2016, at 8:43 AM, Anders Broman wrote:
> Trying to summarize…
>
> captured on the "all" interface of a Linux machine acting as a router, or
> merged two captures from networks on different sides of a router.
>
> various sorts of tunneling
Including, for example, MPLS pseudo-wires.
> (or "other sorts of tunneling", if you view VLANs as a form of
> tunneling)
That might be the best way to think about VLANs - treat them the same way
various tunnels, pseudo-wires, etc. are treated.
On the other hand, as a comment:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4561#c5
in the bug you're quoting says:
For VLAN I know cases where UL traffic and DL traffic belong to
different VLAN, still to the same flow. Thus a differentiation according to
VLAN id must be configurable.
so VLANs shouldn't always be treated as tunnels.
I don't know whether that's an issue for to any other form of pseudo-wire or
tunnel - or even for physical networks, as identified by interface IDs; I could
imagine a case where a machine has multiple physical interfaces on the same
network and different fragments of an IP datagram, or different packets in a
given TCP connection, or... might travel on different interfaces.
So is this really just a question of
1) "wires", whether physical or virtual (a VLAN being a "virtual wire")
or pseudo-wire or...
and
2) whether the machine on which the capture is being done routes
traffic between "wires" or not?
If the machine has multiple "wires" (or radio channels) and *is* routing
between them, a capture that sees traffic from multiple "wires" might see
multiple copies of network-layer packets on different "wires".
If it's not routing between them, and is, for example, using different "wires"
for an uplink and a downlink, or has bonded multiple "wires" together and is
sending traffic to another machine over multiple different "wires", then
fragments from a given fragmented IP datagram, or packets on a given TCP
connection, or... might appear on different "wires".
In the first case, you want to distinguish between "wires" when doing
reassembly/TCP analysis and desegmentation/etc..
In the second case, you *don't* want to do that.
Would that be sufficient to handle the two cases? Or are there cases where the
machine might be routing between some sets of "wires" and using other sets of
"wires" as parallel pipes to and from a given destination host, so that whether
the "wire" should be taken into account depends on the "wire"?
> The right generalization might be to have some sort of "network tag" which
> incorporates a network interface ID plus all VLAN tags for the packet ("all
> VLAN tags" to handle QinQ).
>
>
> So if we go for network tag, or key should that be created by Outer
> VLAN tag, Hash of Source MAC, protocol-level, interface index(Pcap-ng)?
>
> Outer VLAN tag should take care of, VLAN and QinQ, right?
> Source MAC should take care of, “duplicate caused by mirroring” and
> alike(?)
> Pinfo- curr_layer_num Should take care of tunneling(?) Interface index
> should take care of ANY interface traces(?)
>
> What size should the key be, is 32bits enough?
If we have a notion of "wire", perhaps we could assign sequential internal
numbers to "wires" - just as we do for conversations - and use the internal
"wire" number.
We could also use that for filtering, e.g. "show me everything on this "wire"".
(And maybe we could have a sidebar in Wireshark, showing all the "wires",
conversations, etc. we've seen, and let you just click on one to show only the
packets on that "wire"/in that conversation/etc..)
It seems like there might not be a "solve all" solution to the cases listed, it
also seems to me like there is a need for several flavors of "conversation"
Such as the 5 tuple we have today for stuff like "decode as" and possibly other
protocol data stored by the protocols running on the transport protocol and
A configurable(?) "conversation" type taking "wire" into consideration used for
reassembly TCP analysis response times etc.
Possibly the "wire lookup" could list all "wires" belonging to the same 5 tuple
and data could be obtained using the wire key or the 5 tuple key.
It is probably best implemented as a new API used by the TCP dissector
alongside the "old" one used for TCP analysis and reassembly as a start.
Best regards
Anders
___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
Re: [Wireshark-dev] Reassembly of IP fragments gets confused by multiple packets on different VLANS
On Feb 8, 2016, at 8:51 AM, Anders Broman wrote: > It seems like there might not be a "solve all" solution to the cases listed, > it also seems to me like there is a need for several flavors of "conversation" > Such as the 5 tuple we have today for stuff like "decode as" and possibly > other protocol data stored by the protocols running on the transport protocol > and > A configurable(?) "conversation" type taking "wire" into consideration used > for reassembly TCP analysis response times etc. We *do* want a "Decode As" that applies to a conversation (i.e., which doesn't change the dissector table, it just changes the per-conversation dissector setting), but we don't have it yet, as far as I know, so presumably you're referring to the way that feature would work. Are you saying here that if the problem is that we're seeing both sides of routing, so that you have two (or more) copies of the same packet in the capture, you would still want, for example, both instances of a given TCP connection dissected as the selected protocol, but would want TCP reassembly taking place separately on both instances? ___ 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] Specify filter using API
On Feb 8, 2016, at 8:27 AM, Juan Jose Martin Carrascosa wrote: > Is there any way to specify the filter name using an API? Like, I use this > generic hf_field for my plugin and I specify the filter name in the code > paths. No. You'll either have to create multiple fields (the preferred solution) or use a hacked version of the Wireshark core. ___ 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] Specify filter using API
Thanks for the info Guy. I am not willing to hack the core, so I will go ahead with the multiple fields. Thanks, Juanjo Martin On Mon, Feb 8, 2016 at 6:21 PM, Guy Harris wrote: > On Feb 8, 2016, at 8:27 AM, Juan Jose Martin Carrascosa > wrote: > > > Is there any way to specify the filter name using an API? Like, I use > this generic hf_field for my plugin and I specify the filter name in the > code paths. > > No. > > You'll either have to create multiple fields (the preferred solution) or > use a hacked version of the Wireshark core. > ___ > 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 > -- Juanjo Martin Applications Engineer Professional Services Group Office: +34 958 27 88 62 Mobile: +34 622 73 29 03 jua...@rti.com www.rti.com ___ 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] Reassembly of IP fragments gets confused by multiple packets on different VLANS
Den 8 feb 2016 18:04 skrev "Guy Harris" : > > On Feb 8, 2016, at 8:51 AM, Anders Broman wrote: > > > It seems like there might not be a "solve all" solution to the cases listed, it also seems to me like there is a need for several flavors of "conversation" > > Such as the 5 tuple we have today for stuff like "decode as" and possibly other protocol data stored by the protocols running on the transport protocol and > > A configurable(?) "conversation" type taking "wire" into consideration used for reassembly TCP analysis response times etc. > > > We *do* want a "Decode As" that applies to a conversation (i.e., which doesn't change the dissector table, it just changes the per-conversation dissector setting), but we don't have it yet, as far as I know, so presumably you're referring to the way that feature would work. > > Are you saying here that if the problem is that we're seeing both sides of routing, so that you have two (or more) copies of the same packet in the capture, you would still want, for example, both instances of a given TCP connection dissected as the selected protocol, but would want TCP reassembly taking place separately on both instances? > Yes, when conversation is set up from say the SDP dissector for the upcoming rtp flow we will not know on which wire it will appear. ___ > 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] Reassembly of IP fragments gets confused by multiple packets on different VLANS
On Feb 8, 2016, at 9:23 AM, Anders Broman wrote: > Yes, when conversation is set up from say the SDP dissector for the upcoming > rtp flow we will not know on which wire it will appear. So perhaps the reassembly code should take into account the conversation ID (with conversations not taking the wire ID into account) *and* possibly also the wire ID, with a preference to indicate whether to include the wire ID or not (set the preference when there's routing between wires going on, don't set it if, say, wires are being bundled together for greater bandwidth, or different VLANs are being used for upstream and downstream traffic, or...). ___ 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] Reassembly of IP fragments gets confused by multiple packets on different VLANS
Den 8 feb 2016 18:28 skrev "Guy Harris" : > > On Feb 8, 2016, at 9:23 AM, Anders Broman wrote: > > > Yes, when conversation is set up from say the SDP dissector for the upcoming rtp flow we will not know on which wire it will appear. > > So perhaps the reassembly code should take into account the conversation ID (with conversations not taking the wire ID into account) *and* possibly also the wire ID, with a preference to indicate whether to include the wire ID or not (set the preference when there's routing between wires going on, don't set it if, say, wires are being bundled together for greater bandwidth, or different VLANs are being used for upstream and downstream traffic, or...). > Yes or possibly ignore the higher layer and just say someting like [duplicate on transport ] as seeing multiple application messages my confuse people. That should perhaps be a preference too. ___ > 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
