--- Begin Message ---
On Mon, 7 Sep 2020 17:26:28 +0200
Francois-Xavier Le Bail <devel.fx.leb...@orange.fr> wrote:

> On 07/09/2020 16:43, Denis Ovsienko via tcpdump-workers wrote:
> > On Sat, 5 Sep 2020 18:20:42 +0200
> > Thank you for posting a detailed explanation and making the first
> > round of changes. I am looking into the logic of this work. As soon
> > as it feels I can tell the right instances of ND_TCHECK() to remove
> > from the wrong ones, I am going to convert some more code manually
> > if that's OK.  
> That's OK, just try to avoid those like:
> ND_TCHECK_LEN(e, sizeof(nd_ipv4)) calls followed by a
> GET_IPADDR_STRING(e) call, same e.
> ND_TCHECK_4(e) calls followed by a GET_IPADDR_STRING(e) call, same e.
> ND_TCHECK_LEN(e, sizeof(nd_ipv6)) calls followed by a
> GET_IP6ADDR_STRING(e) call, same e.
> ND_TCHECK_16(e) calls followed by a GET_IP6ADDR_STRING(e) call, same
> e.
> (I am working to remove them)

My commit is in the master branch, I tried not to touch the patterns
above and to make only the changes that are obviously safe.

Regarding the loss of ability to skip the link layer header on a
pseudo-return via longjmp(), is there a formal definition (or at least
a workable convention) of a link layer header? For example,
ether_if_print() can return one value for ordinary Ethernet and another
for ordinary Ethernet inside Arista Ethernet.

I do not understand yet if it would be right in theory to increment
ndo_ll_hdr_len each time a decoder has retrieved another complete link
layer header and is about to dig deeper, and how hard in practice it
would be to do that in all DLT printers. Maybe it could be a simpler
problem to solve if the current DLT printer functions were setting
ndo_ll_hdr_len to a sensible DLT-specific value just once before a full
decode, not after.

Does it make sense?

    Denis Ovsienko

--- End Message ---
tcpdump-workers mailing list

Reply via email to