Hi,
This is an interesting problem. It's origin is found in the man-in-the-middle
nature of Wireshark, for which it needs an overall view over the protocol layers
for some of the more advanced features.
If you look at epan/packet-info.h you can see that several protocols have
specific fields there that can help with conversation tracking/reassembly. Even
IP+TCP/UDP port is one instance of tracking mechanism, through the more or less
opaque 'address' type.
Still you need another set of parameters to help conversation tracking. Indeed
option A) doesn't seem to scale very well, so that won't help. Option B) looks
in the right direction, but is overly complicated. Adding protocol specific data
to the [IP|port] based conversation is needed for communicating information
along the time axis. You have a need for communication along the vertical axis
(I assume that you know what the protocol stack looks like, but since you stated
it in your description I take that as a fact). Therefore you can use a shared
data structure in multiple protocol layers of the stack and convey the required
information up the stack via the pinfo->private_data pointer.
Thanx,
Jaap
Neil Piercy wrote:
Folks,
I'm trying to understand the best way of handling endpoint contexts between
protocol layers in Wireshark - e.g. for conversation tracking where the
conversation is not just the TCP/UDP address/port pairs. The prompt for this
is a bug report I've filed on GPRS SNDCP reassembly. Basically one of the
problems spotted is that the reassembly needs to keep track of fragments
within a conversation between endpoints, but that for SNDCP the set of
parameters which identify a single conversation are:
IP addresses of NSIP layer endpoints
UDP ports of NSIP layer endpoints
MS TLLI in the BSSGP layer
SAPI in the LLC layer
(even this is strictly not true in a multi-NS-link environment, but it
normally is)
This is not the first time I've come across this problem, and so far I've
managed to work around it, but I'm realising that this is a general issue,
which maybe should have a general solution or design template at least. I've
not spotted any obvious manner in which such conversations can be tracked in
Wireshark - the current conversation code really only deals with TCP/UDP
port and IP address. Even how to pass such endpoint information around
between layers is not obvious to me - some options:
A) it looks like pinfo is sometimes used for this, but I'm not convinced
extending pinfo with endpoint info for any layer of any protocol stack is
not scalable.
B) adding protocol-specific packet info can be used to hold endpoint info,
and retrieved by other layers, but then you need a mechanism to distribute
the proto handles round between layers
The latter could be done by a function which looks up the proto handle by
proto name quite easily I suspect, so this is the best way I know of right
now.
Maybe I need to look at a more general conversation mechanism using custom
key structs too.
Have I missed something?
Any views on the best way to deal with multi-layer endpoint conversation
tracking in general ?
Regards,
Neil
