On Nov 26, 2018, at 12:43 PM, Dave Barach (dbarach) <dbar...@cisco.com> wrote:
> On November 26, 2018, at 3:01 PM, Guy Harris <g...@alum.mit.edu> wrote:
>
>> On Nov 26, 2018, at 6:03 AM, Dave Barach (dbarach) <dbar...@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
