--- Begin Message ---
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

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
[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.)


-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

Reply via email to