Re: Request for a new LINKTYPE_/DLT_ type.

[Guy Harris <gharris () sonic net>]

On Nov 27, 2018, at 3:11 PM, Dave Barach (dbarach) <dbarach () cisco com> wrote:

> On November 27, 2018, at 5:58 PM, Guy Harris <gharris () sonic net> wrote:
>
> > On Nov 27, 2018, at 1:50 PM, Dave Barach (dbarach) <dbarach () 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