Re: [tcpdump-workers] Request for a new LINKTYPE_/DLT_ type.
Dear Guy,
Here is a cleaned-up copy of the spec which incorporates your comments.
Thanks... Dave
VPP graph dispatch trace record description.
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|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Buffer Metadata ... ... | NULL octet|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Buffer Opaque ... ... | NULL octet|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Buffer Opaque 2 ... ... | NULL octet|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPP ASCII packet trace (if NStrings > 4) | NULL octet|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet data (up to 16K) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Graph dispatch records comprise a version stamp, an indication of how many
NULL-terminated strings will follow the record header and precede
packet data, and a protocol hint.
The buffer index is an opaque 32-bit cookie which allows consumers of these
data to easily filter/track single packets as they traverse the forwarding
graph. Multiple records per packet are normal, and to be expected.
As of this writing: major version = 1, minor version = 0. Nstrings SHOULD be 4
or 5. Consumers SHOULD be wary values less than 4 or greater than 5. They MAY
attempt to display the claimed number of strings, or they MAY treat the
condition as an error.
Here is the current set of protocol hints:
typedef enum
{
VLIB_NODE_PROTO_HINT_NONE = 0,
VLIB_NODE_PROTO_HINT_ETHERNET,
VLIB_NODE_PROTO_HINT_IP4,
VLIB_NODE_PROTO_HINT_IP6,
VLIB_NODE_PROTO_HINT_TCP,
VLIB_NODE_PROTO_HINT_UDP,
VLIB_NODE_N_PROTO_HINTS,
} vlib_node_proto_hint_t;
Example: VLIB_NODE_PROTO_HINT_IP6 means that the first octet of packet data
SHOULD be 0x60, and should begin an ipv6 packet header.
Downstream consumers of these data SHOULD pay attention to the protocol hint.
They MUST tolerate inaccurate hints, which WILL occur from time to time.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Request for a new LINKTYPE_/DLT_ type.
On Nov 28, 2018, at 4:34 AM, Dave Barach (dbarach) 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
Re: [tcpdump-workers] Request for a new LINKTYPE_/DLT_ type.
-Original Message- From: Guy Harris Sent: Wednesday, November 28, 2018 1:40 PM To: Dave Barach (dbarach) Cc: tcpdump-workers Subject: Re: [tcpdump-workers] Request for a new LINKTYPE_/DLT_ type. On Nov 28, 2018, at 4:34 AM, Dave Barach (dbarach) 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
