--- Begin Message ---

On Tue, May 05, 2020 at 05:50:40AM -0400, Gert Doering via tcpdump-workers 
> Now, the two questions:
>  - is there a switch I'm missing to decode packets-in-MPLS?
>     (like, "packets in GRE" get decoded already)
>  - if not, is someone already working on it?  I might just hack 
>    it in, if not...

O-kay.  That turned out to be easier and harder than I thought, at the
same time.

tcpdump's print-mpls.c already does "if I know what upper-layer protocol
is in here, I call the appropriate printer".  But there is no well-defined
type field, so it fails for my packets, and and falls back to "hexdump"
(good enough).

In my case, there is an MPLS control word before the ethernet header
("0000 0000"), and if I skip that and just clear "ethernet in here", I
get nicely printed packets...

12:11:46.116238 MPLS (label 105, exp 0, ttl 254) (label 24003, exp 0, [S], ttl 
254) IP > ICMP echo request, id 49866, seq 5160, length 
12:11:46.117107 MPLS (label 24002, exp 0, [S], ttl 253) IP > ICMP echo reply, id 49866, seq 5160, length 84

So, for my debugging purposes, I have what I need now.

For "contribute back to tcpdump", this is unsatisfactory, as I'm just
guessing what is in there - we already have guesswork, but that isn't
covering "0" (and being a control word, it could be anything).

How does wireshark/tshark approach this?

Would it make sense to add a flag option "hey, MPLS dissector, this is
ethernet + control-world, always"?

"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
                             Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany                             g...@greenie.muc.de

--- End Message ---
tcpdump-workers mailing list

Reply via email to