Wireshark mailing list archives
Re: Conversations - addresses/ports, more general endpoints, and "circuits" with their own IDs
From: Jaap Keuter <jaap.keuter () xs4all nl>
Date: Sun, 6 Jan 2019 18:30:43 +0000
Hi list, Rather than simplistic endpoint ID’s I think we need an ID tuple per endpoint, which may be combined with one (or more) other tuples representing single (and multipoint) connections. Examples are an aggregating tap/monitor port which monitors various VLANs, or an MPLS link. Or even closer to home, a multi port capture in a pcapng file, lets say of two ports of a switch or router. The conversations therein would need to be identified from the capture interface on up. Thanks, Jaap
On 6 Jan 2019, at 09:36, Roland Knall <rknall () gmail com> wrote: I am very much in favor for this development. There are aggregated protocols out there, where multiple packets are transported in a single frame, and it would very much make sense to be able to individually have them added to conversations. I think, from a conversation endpoint it should simply be "identifier A" and "identifier B", which in TCP/UDP could be a IP:PORT combination for instance (PT_ADDRESS). It would also enable us to make the UI stuff more specific, which would make it MUCH easier to integrate new conversations into the system cheers Am So., 6. Jan. 2019 um 01:04 Uhr schrieb Luke Mewburn <luke () mewburn net <mailto:luke () mewburn net>>: [attempting a resend, 13 months later] On Sat, Oct 28, 2017 at 08:12:53PM -0700, Guy Harris wrote: | Michael Mann is looking at generalizing conversations to handle | arbitrary endpoints, presumably not necessarily in the form of an | AT_ address plus a PT_ numeric port ID. | | [...] | | Some thoughts that come to mind: | | 1) While we're generalizing conversations, should we have a | "superclass" that includes both endpoint-labeled conversations and | ID-labeled circuits, so that they can offer common services to | dissectors? | | 2) Can we use conversations/circuits elsewhere, e.g. in the | conversations and endpoints UI functions? | | 3) Would it be useful to add to the "Dissect As..." mechanisms the | ability to say, from the UI, "dissect the conversation/circuit to | which this packet belongs as...", rather than just "dissect this | {packet type, transport-layer port} as..."? | | 4) Can we further generalize conversations/circuits to include, for | example, multiple endpoint pairs/circuit IDs, so that, for example, | an NFSv2 or NFSv3 "conversation" would include NFS traffic, NLM | (lock manager) traffic, and mount protocol traffic? Another conversation type to consider refactoring to a more general framework is TCAP transactions. TCAP currently uses its own conversation matching, enabled with obscure TCAP preferences (as "Service Time Analysis" and "Persistent stats for SRT"). As such, currently TCAP doesn't benefit from some of the fancier conversation display support that other protocols support. There's been a few bugs & fixes over the years for the TCAP (+SCCP) transaction matching (I've fixed a couple myself), including: - https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=10841 <https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=10841> - https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13739 <https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13739> - https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13926 <https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13926> (Unfortunately I was behind on my email and wasn't around to contribute to the discussion of the fixes 13739 and 13926). The conversation endpoint identifier for TCAP could still be the relevant SCCP GT + TCAP TID, with provision for changing GT in the first TCAP CONTINUE as part of the TCAP "dialogue confirmation". A complication is SCCP global title translation (GTT) where the packets contain a slightly different GT in subsequent packets _unrelated_ to dialogue confirmation, possibly changing the GT of the original calling party mid-transaction! E.g., the addition of trailing digits to the GTs. This is difficult to implement without external configuration and knowledge of the network behaviour. Possibly solved with a preference table of GTs to translation, or even a lua function, for those that need this. There's been a few discussions in the comments in those tickets (and others?) that describe the TCAP behaviour, and I'm happy to move a discussion of the specifics to another thread. regards, Luke Mewburn.
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- Re: Conversations - addresses/ports, more general endpoints, and "circuits" with their own IDs Luke Mewburn (Jan 05)
- <Possible follow-ups>
- Re: Conversations - addresses/ports, more general endpoints, and "circuits" with their own IDs Luke Mewburn (Jan 05)
- Re: Conversations - addresses/ports, more general endpoints, and "circuits" with their own IDs Roland Knall (Jan 06)
- Re: Conversations - addresses/ports, more general endpoints, and "circuits" with their own IDs Jaap Keuter (Jan 06)
- Re: Conversations - addresses/ports, more general endpoints, and "circuits" with their own IDs Guy Harris (Jan 06)
- Re: Conversations - addresses/ports, more general endpoints, and "circuits" with their own IDs Jaap Keuter (Jan 07)
- Re: Conversations - addresses/ports, more general endpoints, and "circuits" with their own IDs Guy Harris (Jan 07)
- Re: Conversations - addresses/ports, more general endpoints, and "circuits" with their own IDs Roland Knall (Jan 06)