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 > _______________________________________________ Wireshark-dev mailing list [email protected] https://wireshark.org/mailman/listinfo/wireshark-dev
