I'm looking at a protocol which may "glue together" multiple packets in arbitrary ways... So in essence a single "frame" of data has a 1:N relationship to packets it contains. Is it possible to attack something like this in a recursive type fashion by re-starting dissection on any remaining data after dissection of the first packet is complete? Ideally this would include segmenting the frame into new instances so that each packet would be uniquely identifiable for filtering purposes.... asked 13 Jun '17, 14:44  wittynickname |
One Answer:
Recursive dissection is fairly standard: there are a lot of protocols where a single (e.g., Ethernet) frame may contain multiple upper-layer PDUs. In Telco circles a good example is SCTP which frequently bundles many PDUs into a single SCTP packet. Programmatically this is as simple as having a for() or while() loop in your "glue" protocol dissector to dissect all the protocol packets that in that frame. You can choose whether to make these PDUs top-level tree items or subtree items (in the Packet-Details pane) by choosing which tree/subtree parameter you pass to the sub-dissection function. However, in Wireshark 1 frame is 1 frame is 1 frame. There isn't currently a way to "segment" a single (e.g., Ethernet) frame into multiple frames (in the Packet List pane). It's something we've talked about on and off for a long time but nothing has come of it. If you want to see an example of this with SCTP traffic you can check out the answered 14 Jun '17, 06:54  JeffMorriss ♦ edited 14 Jun '17, 06:54 |
So does the inability to segment frames mean that it's also not possible to represent multiple instances of common data for each sub packet?
Goal being that a filter run searching for a certain type of packet would highlight the frame even if it's not the first instance of a packet in a given frame.
I'm not sure what you are saying, if you have a frame with PDU1, PDU2 and PDU3 and you program your dissector to show the PDUs in the "frame tree" a filter of pdu.fieldx would match the frame if any of the PDUs have that filter set, unfortuatly if you have a filter of pdu.fieldxx && pdu.fieldyy it would match if pdu.fieldxx is in PDU1 and pdu.fieldyy is in PDU2 or PDU3.
The export PDU functionality can be used as a workaround to create a new pcap-ng with each PDU in a separate manufactured frame including meta information from the original trace.
As Anders said filtering will work but there are some gotchas.
Fundamentally it's useful to remember that a filter like
ip.addr == 1.2.3.4means "there exists a field in the frame namedip.addrwhose value is1.2.3.4" So theip.addrfilter field can be anywhere in the frame: at the top-level or embedded in one or more PDUs within the frame. The trouble comes when you want to filter on the Nth instance of that field.Just the ability to do filtering is probably good enough for my needs, I've tested with some basic support for iterative processing and the results are looking good. Thanks for the help!