Re: Request for a new LINKTYPE_/DLT_ type.

["Dave Barach (dbarach)" <dbarach () cisco com>]

-----Original Message-----
From: Guy Harris <gharris () sonic net> 
Sent: Wednesday, November 28, 2018 1:40 PM
To: Dave Barach (dbarach) <dbarach () cisco com>
Cc: tcpdump-workers <tcpdump-workers () lists tcpdump org>
Subject: Re: [tcpdump-workers] Request for a new LINKTYPE_/DLT_ type.

On Nov 28, 2018, at 4:34 AM, Dave Barach (dbarach) <dbarach () cisco com> wrote:

>    0                   1                   2                   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   | Major Version | Minor Version | NStrings      | ProtoHint     |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   | Buffer index (big endian)                                     |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   + VPP graph node name ...     ...               | NULL octet    |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

So are those strings counted - i.e., preceded by a length - and null-terminated, or are they just null-terminated?

> > > Just NULL terminated. I re-did the implementation from scratch... 

> Downstream consumers of these data SHOULD pay attention to the protocol hint. They MUST tolerate inaccurate hints, 
> which WILL occur from time to time.

"Inaccurate" as in, for example, a packet might have a hint of 2 (VLIB_NODE_PROTO_HINT_IP4), it might be an IPv6 
packet, so both 2 and 3 (VLIB_NODE_PROTO_HINT_IP6) should be interpreted as IP, and the v4 vs. v6 decision should be 
based solely on the version field of the header?

> > > Someone trying to debug new vpp code will use this toolset. They may well mis-specify the hint, or build bogus 
> > > packets. Initial code development is the primary use-case. Wireshark is wonderful in terms of giving feedback of 
> > > the form: "you forgot to fix the ip4 checksum in addition to changing the ip4 length in that GRE template header 
> > > you're using."

Or, worse, it might be an Ethernet packet?

> > > Not the most likely mistake, but not out of the question. All it would take would be to roll back b->current_data 
> > > to zero; instead of setting that field to 14 for a non-vlan pkt, etc. 

And do 4 (VLIB_NODE_PROTO_HINT_TCP) and 5 (VLIB_NODE_PROTO_HINT_UDP) mean, respectively, "the payload is probably a TCP 
segment, beginning with a TCP header" and "the payload is probably a UDP segment, beginning with a UDP header"?  And, 
again, "probably" means that the hint should be inaccurate - potentially meaning it's something other than what's 
hinted?

> > > s/should/could/, presumably.

> > > When working with completed, tested vpp code, the hints will be accurate. The UDP and TCP hints mean exactly what 
> > > you think the would mean. Again, the primary use case is for developers who need to see what's going on with new 
> > > code...
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers