Wireshark-dev: Re: [Wireshark-dev] q on catching error in sub-dissectors.
On 22/01/20 01:11, Christian Hopps wrote:
João Valverde <joao.valverde@xxxxxxxxxxxxxxxxxx> 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.
