Re: decode MPLS-contained packets?

[Guy Harris via tcpdump-workers <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: Guy Harris <gharris () sonic net>
>
> Date: Thu, 7 May 2020 01:05:19 -0700
>
> On May 5, 2020, at 1:01 PM, Francois-Xavier Le Bail via tcpdump-workers <tcpdump-workers () lists tcpdump org> wrote:
>
> > Wireshark MPLS heuristic is not perfect and has been criticized but is still there :-) hopefully
> > correctly parsing your data as well.
>
> *No* heuristic will be perfect here.
>
> > For tcpdump maybe a -T based approach is better?
> >
> > -T mpls (+ 1st nibble logic for IPv4/IPv6)
> > -T ethpw
> > -T ethpwnocw
>
> That's a thought, but -T should probably get a bunch of work done on it.
>
> It's documented as
>
>          -T type
>               Force  packets  selected  by  "expression" to be interpreted the
>               specified type.
>
> but it has nothing to do with the filter expression - that really means "force all packets to be interpreted [as] the 
> specified type", because "expression" controls which packets tcpdump sees.  It doesn't *entirely* work that way, but 
> the places where it's checked - for example,  the TCP and UDP dissectors - just do "if somebody specified a -T flag, 
> dissect *everything* as that protocol".
>
> A mechanism where you could do something such as "-T tcp:1073:{protocol}" to force traffic to TCP port 1073 to be 
> dissected as the specified protocol might be useful; in this case, we'd do something such as "-T mpls:{protocol}" to 
> force *all* MPLS packets to be dissected as the specified protocol, and "-T mpls:{label}:{protocol}", to force packets 
> with a particular label to be dissected as the specified protocol (which might mean you'd have to run tcpdump twice - 
> once to see what the label is, and once to decode the label.
>
> That would require a mechanism similar to Wireshark's "run this script on all dissector files to find their 
> registration routines and call those at run time" to build a table of the first items in the "-T" string; once we've 
> gone there, we might as well use it to build a table of the {protocol} values as well, and we could then just have a 
> mechanism similar to Wireshark's dissector table mechanism, replacing the big switch statements (back in the very early 
> days, Wireshark - still called "Ethereal" at the time - used switch statements as well; that was replaced by a 
> dissector table mechanism) with dissector tables, which would mean that a new "runs atop TCP" or "runs atop UDP" 
> dissector could just register and the switch statement wouldn't have to be changed.
>
> We could start out by adding an explicit list of items, just as we currently have an explicit list of {protocol} values.
>
> --- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers