Richard van der Hoff wrote: >Stephen Fisher wrote: >> On Mon, Nov 12, 2007 at 06:05:38PM -0000, Neil Piercy wrote: >> >> >>>I know there is per-packet info, but is there a way of >>>adding/retrieving per PDU info which copes with multiple PDUs in a >>>packet ? How does a dissector even know if it is handfling the first, >>>second etc PDU in a packet ? >> >> >> This has been requested before, but has not been implemented to date in >> Wireshark. A workaround you can use is to use a linked list from GLib >> (which has a nice easy interface to them) and store that in the per >> packet info. Each item in your list would correspond to a different >> PDU. > >But, as Neil asked, how would you know which PDU you were >handling in the dissector? > >> One of us should get around to implementing per-pdu packet info in >> Wireshark itself. It wouldn't be too difficult. All we need is spare >> time :) > >Hrm; it gets quite a lot harder when your PDUs can >themselves span >multiple packets (ie, there is no correspondence between PDUs and >packets). See H.223 for details...
I do not consider myself an expert by any means, but here is what I ended up doing. The easy part is the data structures; however I stayed away from lists. Wireshark does a great job of giving you the right structures for the task (check se_tree_create_non_persistent and se_tree_lookup32). My particular PDU state involves encryption state. I create appropriate conversations and put my PDU structures in them. The hard part (for me) was determining the right key for the PDU. This is IMHO where Wireshark falls a little short. In order for the data structures to be of use the key must be unique to the PDU in the context of the conversation. Assuming that you need lookups not just during the initial pass but also when packets are selected, the things you have available are rather limited. You must use things that don't depend on order and are always available. Also, never forget about TCP retransmissions (yes, everyone should test with captures over large-latency links!). In the TCP case I use a combination of the sequence and the offset. The offset is TVB_RAW_OFFSET(tvb). Assuming that you call this on the tvb that represents your PDU you should always get the same number - however it is not unique to the session, only the tvb. To make it unique I add the seq field of the tcpinfo structure. The structure pointer is present in the pinfo->private_data for tcp dissectors, so I stash the seq value in the conversation before I call tcp_dissect_pdus. Using this number is almost required if (as in my case) you really want your data associated with the logical PDU and not each transmitted instance of the PDU. The seq field plus the offset should remain constant even in the case of retransmissions (at least that is my understanding - experts may know otherwise). Unfortunately I do not have a good solution for UDP or other connectionless cases. In my case each UDP packet was self describing, so I didn't need to solve the problem. My protocol doesn't allow multiple PDUs per UDP packet either. In general it seems that there is no guarantee of shared state in these cases, so the need for per PDU information may be lessened. I suppose you could still use TVB_RAW_OFFSET to determine each individual PDU in a packet, but you would need to handle retransmission logic in your dissector since the transport doesn't do it. As to your question of determining which PDU sequence you are looking at, that would be stored in your per PDU data and initialized during the first pass when all of the data structures are set up. Each packet you handle would reset the count, each PDU you parse would increase it and store it in your PDU data. Hope this was helpful... By the way, if experts find holes in my approach I would love to know! Bryant Eastham _______________________________________________ Wireshark-dev mailing list Wireshark-dev@wireshark.org http://www.wireshark.org/mailman/listinfo/wireshark-dev
