Wireshark mailing list archives
Re: q on catching error in sub-dissectors.
From: João Valverde <joao.valverde () tecnico ulisboa pt>
Date: Wed, 22 Jan 2020 16:21:42 +0000
On 22/01/20 01:11, Christian Hopps wrote:
João Valverde <joao.valverde () tecnico ulisboa pt> writes:On 21/01/20 16:06, João Valverde wrote:On 21/01/20 16:01, Jeff Morriss wrote:We've been having fun with multiple PDUs in a single IP frame with SCTP for years. While there's room for improvement it's worked pretty well.Maybe I didn't explain well, but that's completely different to multiple IP packets encapsulated in a single frame. L4 multiplexing is nothing new, I agree.How would this protocol stack even look in the packet list? Surely it can only display the outer IP header with ESP/IPTFS protocol? We already have some issues to iron out with the much simpler case of IP over GRE (bug 3791 for example). One idea, and it's just that, I haven't studied the issue in depth, would be using an IPTFS Cooked Capture DLT type.I'm not versed well enough in wireshark yet to know what a "cooked capture DLT type" is, but I can show what I have now. :)I still haven't stamped anything with "comes from" or "depends on", and I'd also like to have datablock summary lines include the actual size of that datablock data...Basically I decode as: - IPTFS - Header fields - Array of datablocks - Subtree of contained packets: - Array of Dissected IP packets- 1st packet is the completion of a fragmented packet if that happened.You'll notice the final datablock doesn't have a packet (7 data blocks 6 packets), the first packet is the reconstructed packet from the first datablock which is the last of the fragments. The last datablock is the start of a new fragmented packet so that will appear later (the inner packet sizes are from an imix stream of 40, 576 and 1500 FWIW)
[snip] That's pretty good, nice work.What does tshark without the -V flag show? My guess is that all that compresses to:
8 13.13.13.11 13.13.13.2 IPTFS <Frame len> <some colinfo like SPI=1113 Blocks=7>
It would be nice to see each encapsulated IP flow (after reassembly if necessary) in this list. Both from a usability stand point and also because it enables a lot of other stuff, like better filtering, follow stream, etc.
A cooked capture, in particular a Linux cooked capture, is a link-layer pseudo-header for the "any" interface. It doesn't correspond to any real protocol like ETH or PPP. The same concept could possibly be applied here to display each inner IP packet in the packet list. For IPTFS a frame "interface" could be the IPTFS ESP SPI. Usually dumpcap/libpcap provides the DLT type. Major caveat, I don't know how difficult it would be to inject new cooked frames from libwireshark itself.
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- q on catching error in sub-dissectors. Christian Hopps (Jan 21)
- Re: q on catching error in sub-dissectors. João Valverde (Jan 21)
- Re: q on catching error in sub-dissectors. João Valverde (Jan 21)
- Re: q on catching error in sub-dissectors. Jeff Morriss (Jan 21)
- Re: q on catching error in sub-dissectors. João Valverde (Jan 21)
- Re: q on catching error in sub-dissectors. João Valverde (Jan 21)
- Re: q on catching error in sub-dissectors. Christian Hopps (Jan 21)
- Re: q on catching error in sub-dissectors. João Valverde (Jan 22)
- Re: q on catching error in sub-dissectors. Christian Hopps (Jan 22)
- Re: q on catching error in sub-dissectors. João Valverde (Jan 23)
- Re: q on catching error in sub-dissectors. João Valverde (Jan 21)
- Re: q on catching error in sub-dissectors. João Valverde (Jan 21)
- Re: q on catching error in sub-dissectors. Christian Hopps (Jan 21)