If the Ethernet PW is without the CW (Control Word) - as it seems from
your ASCII art - the "magic" might be happened in
dissect_pw_eth_heuristic() around line 134 of packet-pw-eth.c.
To get the big picture (line 462 of packet-mpls.c + line 134 of
packet-pw-eth.c):
- is there any user specific label binding for this label (via decode
as)? yes use it, else
- use the 1st nibble logic (see BCP 4928, RFC 4385 and 5586): 4 =>
IPv4, 6 => IPv6, 1 => PW Associated Channel (i.e. OAM stuff like
S-BFD, BFD, LM, CC, CV...)
- if the first nibble is 0 well... wiiild guessss... we try with a bit
of "magic" (at line 134 of packet-pw-eth.c)
- if the first 6+6 bytes look like (by checking manufacture OUI
database) a pair of Ethernet addresses we go with Ethernet PW
*without* CW (it seems your case)
- else hmmm wait... the first nibble was 0 so it might have been
the case of Ethernet PW with a 'Generic PW MPLS Control Word' as per
RFC 4385 (uncommon)
Isn't Wireshark great? :-)
ciao
fra
On Fri, Sep 16, 2016 at 1:13 AM, barcaroller <barcaroller@xxxxxxxxx> wrote:
> I have a pcap file where, in each packet, the header hierarchy is as
> follows:
>
> ETH
> IP
> GRE
> MPLS
> ETH <--- ?
> VLAN
> IP
> TCP/UDP
>
>
> I would not expect to see an Ethernet header right below an MPLS header.
> And yet wireshark was able to properly identify/parse the headers, even
> though there's no indication in the MPLS header that the following header is
> Ethernet. How did wireshark do that?
>
>
> ___________________________________________________________________________
> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives: https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe