Re: Request for a new LINKTYPE_/DLT_ type.

[Guy Harris <gharris () sonic net>]

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

> On Wednesday, November 28, 2018, at 1:40 PM, Guy Harris <gharris () sonic net> wrote:
>
> > 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.

Yes.

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

When working with completed, tested networking code, the Ethernet type field of an Ethernet packet will, modulo errors 
not detected by the CRC (or caputures getting packets that failed the CRC check) will mean exactly what you think they 
would mean.

Even when using a sniffer to see what's going on with new code, "wrong Ethernet type" is probably not the most likely 
error case.  Some sniffers (Wireshark, for example), do have a mechanism for overriding the normal interpretation of a 
given Ethernet type value ("Decode As..."), but that's rarely used for Ethernet types.

So, by analogy, is this a case where a sniffer should, by default, believe the hint, and, if it turns out to be 
necessary, offer a way to override that and force an interpretation of the payload other than what the hint suggests?
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers