On Nov 28, 2018, at 10:53 AM, Dave Barach (dbarach) <dbar...@cisco.com> wrote:
> On Wednesday, November 28, 2018, at 1:40 PM, Guy Harris <ghar...@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
