On Nov 27, 2018, at 3:11 PM, Dave Barach (dbarach) <dbar...@cisco.com> wrote:
> On November 27, 2018, at 5:58 PM, Guy Harris <ghar...@sonic.net> wrote: > >> On Nov 27, 2018, at 1:50 PM, Dave Barach (dbarach) <dbar...@cisco.com> wrote: >> >>> The buffer index allows downstream consumers of these data to easily >>> filter/track single packets as they traverse the forwarding graph. >> >> So does that mean that there might be multiple records in the file for the >> same packet, with all records for the same packet having the same buffer >> index? > > There absolutely will be multiple records for every packet in the trace, > unless e.g. ethernet-input has a horrible bug. So this needs to be noted in the specification. Does that mean that you might see multiple instances of the same packet payload, e.g. more than one copy of a single request and more than one copy of the response to that request in some protocol? >>> FWIW, the 32-bit buffer index is stored in big endian format. >> >> If it's only to be used for matching purposes, presumably that means that >> >> 1) its value has no numerical significance; >> >> 2) the only comparisons done on that value are equality comparisons; >> >> so it could be treated as a 4-byte opaque value, in which case the byte >> order doesn't matter. > > Exactly so. I wrote the vpp code so it will always show up in big endian > order, but it truly doesn't matter. OK, so we'll just specify it as an opaque 32-bit cookie to use to match up multiple records for the same packets. >>> As of this writing, major version = 1, minor version = 0; Nstrings will be >>> either 4 or 5. >> >> So smaller or larger values MAY (and probably SHOULD) be treated as errors. > > Yes, that would probably mean that the capture file is damaged beyond repair. Or, to be a bit more robust, treat it as a count of strings; if it's less than 4, we display only the strings that are there and, if it's greater than 5, we just don't display the others, or display them as "unknown string". >>> Example: VLIB_NODE_PROTO_HINT_IP6 means that the first octet of packet data >>> SHOULD be 0x60, and should begin an ipv6 packet header. >> >> That's SHOULD, not MUST; is there anything else a dissector should do other >> than use the protocol hint for handoff? > > Right. If someone screws up on the vpp side, the hint might not match > reality. Here's why my current dissector does with it: That appears to assume that the hint is valid (although both Wireshark and tcpdump will, if handed a purportedly-IPv4 packet with a version of 6, or a purportedly-IPv6 packet with a version of 4, report it as an error). _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
