Re: Request for a new LINKTYPE_/DLT_ type.

[Guy Harris <gharris () sonic net>]

On Nov 26, 2018, at 12:43 PM, Dave Barach (dbarach) <dbarach () cisco com> wrote:

> On November 26, 2018, at 3:01 PM, Guy Harris <guy () alum mit edu> wrote:
>
> > On Nov 26, 2018, at 6:03 AM, Dave Barach (dbarach) <dbarach () cisco com> wrote:
> >
> > > VPP graph dispatch trace record description, in network byte order. Integers wider than 8 bits are in little endian 
> > > byte order.
> >
> > "Byte order" doesn't apply to 8-bit fields; if all fields are in little-endian byte order, what, if anything, is in 
> > network byte order (big-endian)?
> >
> > And is everything guaranteed to be in little-endian byte order *even if the tracing code is running on, for example, 
> > a Power ISA processor running in big-endian mode, or on z/Architecture processor (which *only* runs big-endian)?
>
> Good point. It would be easy to trace the 1 x 32-bit and 1 x 16 bit quantities in for-real network byte order. I'll 
> just go do that. Frankly, we haven't run the code base on a PowerPC or other big-endian processor in years. I'm 
> fairly sure that the dispatch trace code would be the least of anyone's problems if/when we go there again.

So, in other words, you meant "Integers wider than 8 bits are in *the byte order of the host writing the trace*", not 
"...are in little-endian byte order".

Either big-endian or little-endian byte order would work easily, as long as it's standardized.  Host-endian can be made 
to work, *but* it means that any code that reads pcap or pcapng files has to byte-swap the VPP header if the byte order 
claimed by the pcap file header or the pcapng section header differs from the native byte order of the host reading the 
file; we have code to do that in libpcap and in Wireshark's libwiretap, but we'd really prefer not to have to introduce 
that here.

> > > Notes: as of this writing, major version = 1, minor version = 0.
> >
> > Presumably any code that can read major version M, minor version N will also be able to read major version M, minor 
> > version K, for all values of K <= N.
>
> That's the goal, but since the paint is barely dry on v1.0 it would be slightly rash of me to make that claim...

That shouldn't just be a goal, it should be a definition of how the major and minor versions work.

This is similar to, for example, SunOS 4.x's shared library version numbering - if you add new capabilities to a 
library, so that programs using the new capabilities won't work with older versions of the library, *but* the 
capabilities are added in a compatible fashion, so that programs using only the capabilities of older versions of the 
library will work with newer versions of the library, you increase the minor version, *but* if you make incompatible 
changes (removing routines, changing the signature of existing functions, etc.), you increase the major version.

So you should probably specify that's how the major and minor versions are used.

> > For the fields defined in that header:
> >
> > What is the buffer index?
>
> A 32-bit buffer handle which can be rapidly converted into either a virtual address or a physical addresses. It's 
> highly useful as a filter in WS: since we trace e.g. 100 packets in ethernet-input, then 100 packets in ip4-input, 
> etc.

So "as a filter" means that if the handle value is equal to some particular value - either an arbitrary value or the 
same value as another packet - that's significant?

> > Does the node name length include the terminating NUL?  (Presumably anything writing those files MUST, in the RFC 
> > 2119 sense, null-terminate strings, and anything writing those files MUST not assume that the strings are 
> > null-terminated; a count *and* a terminating NUL is redundant.)
> >
> > Does the ASCII trace length include the terminating NUL?  Is that just an opaque string to display to the user, or 
> > are there any ways in which an application can parse it?
>
> Yes, the NULL is included in the count.

The spec should indicate that.

> Yes, it's slightly redundant. Yes, it keeps people from shooting themselves in the foot when processing the data.

It doesn't prevent code that processes the data from having to check for a terminating NUL, unless you're in *so* 
tightly-controlled an environment that you can guarantee that you will *never* see maliciously-constructed files that 
don't have a terminating NUL.

Neither tcpdump nor Wireshark, for example, are always run in environments like that.

> > In an earlier mail on another list you said:
> >
> > > Packet data can be anything: L2, L3, L4 or above. The vpp dissector knows from the node name what to expect. I have 
> > > a [seriously incomplete as of this writing] table of the form:
> > >
> > > #define foreach_node_to_dissector_handle                        \
> > > _("ip6-lookup", "ipv6", ip6_dissector_handle)                   \
> > > _("ip4-input-no-checksum", "ip", ip4_dissector_handle)          \
> > > _("ip4-lookup", "ip", ip4_dissector_handle)                     \
> > > _("ip4-local", "ip", ip4_dissector_handle)                      \
> > > _("ip4-udp-lookup", "ip", udp_dissector_handle)                 \
> > > _("ip4-icmp-error", "ip", ip4_dissector_handle)                 \
> > > _("ip4-glean", "ip", ip4_dissector_handle)                      \
> > > _("ethernet-input", "eth_maybefcs", eth_dissector_handle)
> >
> > Presumably, once a node name is used for a particular type of payload, it will always indicate that particular 
> > payload type.
>
> vpp uses a "current_data" (signed) index, to point at the current layer being processed. On input, all nodes know 
> where the "index finger" is supposed to point.

I'm not sure how that answers the question.  The question was perhaps not formulated clearly; it means, for example, 
will a node named "ip6-lookup" always mean that the payload is an IPv6 packet?

> > Is there a page at any fd.io or VPP Web site that gives the current list of node names, showing what payload type 
> > each node name indicates?
>
> Yes, see https://wiki.fd.io/view/VPP/CurrentData - I'm about to spin up a community project to populate it.

OK, so we'll just link to that page.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers