-----Original Message----- From: Guy Harris <ghar...@sonic.net> Sent: Wednesday, November 28, 2018 1:40 PM To: Dave Barach (dbarach) <dbar...@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) <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? >>> 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
