| 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
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
[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=13739
- 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.
|
