inline

-----Original Message-----
From: Guy Harris <ghar...@sonic.net> 
Sent: Tuesday, November 27, 2018 5:58 PM
To: Dave Barach (dbarach) <dbar...@cisco.com>
Cc: tcpdump-workers <tcpdump-workers@lists.tcpdump.org>
Subject: Re: [tcpdump-workers] Request for a new LINKTYPE_/DLT_ type.

On Nov 27, 2018, at 1:50 PM, Dave Barach (dbarach) <dbar...@cisco.com> wrote:

> After thinking about some of your feedback, I decided to move most of the 
> work back to the vpp side where it probably belonged in the first place.

        ...

> Anyhow, here's what I implemented. Take a look AYC and let me know what you 
> think.
> 
> 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 FWIW)                                |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   + VPP graph node name ...     ...               | NULL octet    |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   | Buffer Metadata ASCII string ... ...          | NULL octet    |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   | Buffer Opaque ASCII string ... ...            | NULL octet    |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   | Buffer Opaque 2 ASCII string ... ...          | 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 a protocol 
> hint.
> 
> 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. 

> 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.

> 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.


> 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;

So a dissector MAY use that to indicate what the next protocol is.

>>> Yes.

> 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:

    /* 
     * Delegate the rest of the packet dissection as directed. If there wasn't 
a hint, 
     * take a guess. 
     */ 
    if (protocol_hint >= array_length(next_dissectors)) {
        ws_debug_printf ("protocol_hint %d out of range (max %d)",
                         (int) protocol_hint, 
                         (int) array_length(next_dissectors));
        protocol_hint = 0;
    }

    /* note: next_dissectors[0] = eth_maybefcs_dissector_handle... */

    use_this_dissector = next_dissectors [protocol_hint];
    if (protocol_hint == 0) {
        maybe_protocol_id = tvb_get_guint8 (tvb, offset);
            
        switch (maybe_protocol_id) {
        case 0x45:
            use_this_dissector = next_dissectors[VLIB_NODE_PROTO_HINT_IP4];
            break;
        case 0x60:
            use_this_dissector = next_dissectors[VLIB_NODE_PROTO_HINT_IP6];
            break;
        default:
            break;
        }
    }
    call_dissector (use_this_dissector, eth_tvb, pinfo, tree);
    return tvb_captured_length(tvb);

_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Reply via email to