Re: [tcpdump] After setjmp/longjmp update

[Denis Ovsienko via tcpdump-workers <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: Denis Ovsienko <denis () ovsienko info>
>
> Date: Sat, 12 Sep 2020 17:15:09 +0100
>
> On Sat, 5 Sep 2020 18:20:42 +0200
> Francois-Xavier Le Bail via tcpdump-workers
> <tcpdump-workers () lists tcpdump org> wrote:
>
> [...]
> > We have:
> > 1) The "old" way, before the patch, returning from all functions and
> > at the end returning the header length to the link-layer dissector
> > (xxx_if_print), updating the 'ndo->ndo_ll_hdr_len' field (output A).
> > b) The "longjmp" way with GET_ macros but no ND_TCHECK_() macros (and
> > thus no 'trunc' label code use): The 'ndo->ndo_ll_hdr_len' is not (or
> > sometimes partially) updated (output C).
> [...]
>
> I have been thinking about this problem for a while and managed to
> structure it as follows so far.
>
> It is trivial to pass data from a decoder when it aborts the process
> trying to go past the snapshot end. This already works for
> ndo->ndo_ll_hdr_len and the buffer/snapend stacks, and it would be
> straightforward to add more data items if required, for example, to tell
> where (in the topmost DLT printer or in a nested DLT/protocol printer)
> and why (truncated packet, malformed packet, resource allocation or
> other packet-fatal error) the attempt failed. That would not even
> require passing a different "val" value to longjmp().
>
> It would greatly help to spell a practical reference definition of
> "link-layer header" for the -x/-xx/-X/-XX options, considering the many
> ways protocols can stack: something-in-something,
> something-in-somethingelse, something-in-somethingelse-over-UDP and so
> on. Let me suggest to take "the outermost DLT-specific header only" as a
> working definition and to see if that works in every case.
>
> This way, if:
>
> 1. pretty_print_packet() before calling an ndo_if_printer function
>    resets ndo->ndo_ll_hdr_done to mean "any longjmp() from now on would
>    be from a top-level DLT printer"
>
> 2. the ndo_if_printer function, if possible for the specific DLT,
>    updates ndo to tell how many bytes long a well-formed link-layer
>    header is expected to be (I am not entirely sure about this part
>    though)
>
> 3. the ndo_if_printer function after each successful GET_x() updates
>    ndo->ndo_ll_hdr_len to accurately tell the amount of bytes it
>    managed to retrieve so far
>
> 4. the ndo_if_printer function after fully dealing with the current
>    link-layer header and before calling a downstream function that
>    would try to access beyond that sets ndo->ndo_ll_hdr_done to mean
>    "any longjmp() from now on would be NOT from a top-level DLT printer"
>
> ...then on a return back into pretty_print_packet() it will be much
> easier to understand the context and to deliver it in a useful way, no
> matter if the return was via longjmp() or not, and how complicated the
> protocol stack was. For example:
>
> ---------------------------------------------------------------------
> \tLink-layer header (incomplete, only 50 bytes captured):
> [hex dump of the 50 bytes]
>
> \tLink-layer header (incomplete, only 120 bytes captured out of
> 128):
> [hex dump of the 120 bytes]
>
> \tLink-layer header (complete, 128 bytes):
> [hex dump of the 128 bytes]
> \tPacket data (incomplete, only 200 bytes captured out of 500):
> [hex dump of the 200 bytes]
>
> \tLink-layer header (complete, 128 bytes):
> [hex dump of the 128 bytes]
> \tPacket data (complete, 350 bytes):
> [hex dump of the 350 bytes]
> ---------------------------------------------------------------------
>
> Excuse me if I got a few details wrong in this description, but the
> point should be clear. One obvious obstacle in the way of this approach
> is that every DLT printer must implement this convention exactly. Whilst
> it would be straightforward to modify ap1394_if_print() for that, there
> are DLTs and functions that are way more complex, and it is more than
> 70 functions in total.
>
> Let's consider if this approach is technically sound and eventually
> implementable and would solve the problem if implemented. If that's the
> case, it would be nice to have it implemented eventually, but that is
> not critical for the release, and until the hex dump offsets become
> byte-perfect again, the man page could say:
>
> -x ... (If the packet was truncated, in this version of tcpdump this
>    flag will work as the -xx flag below.)
>
> or
>
> -x ... (In this version of tcpdump this flag always works as the -xx
>    flag below.)
>
> Would this help?
>
> -- 
>     Denis Ovsienko
>
> --- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers