On Nov 28, 2018, at 4:34 AM, Dave Barach (dbarach) <dbar...@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? > 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? Or, worse, it might be an Ethernet packet? 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? _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
