Wireshark-bugs: [Wireshark-bugs] [Bug 10195] MPLS traffic is dissected as "Ethernet pseudo-wire

Date Prev · Date Next · Thread Prev · Thread Next
Date Index · Thread Index · Other Months · All Mailing Lists
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Wed, 18 Jun 2014 21:16:31 +0000

changed bug 10195

What Removed Added
Status CONFIRMED RESOLVED
Resolution --- NOTABUG
Summary MPLS dissector dissects a pseudo-wire control word when there isn't one MPLS traffic is dissected as "Ethernet pseudo-wire with a control word" when it's "Ethernet pseudo-wire without a control word"

Comment # 6 on bug 10195 from 
OK, the MPLS dissector has a "default" type of payload, which it uses for
packets whose payload type it can't determine otherwise.

For better or worse, the packets in question are packets of that type.

The default value of the default type is "pseudo-wire Ethernet, perhaps with a
pseudo-wire control word, perhaps without a pseudo-wire control word", which
means that the pseudo-wire Ethernet dissector tries to guess whether there's a
control word or not.

The guess is done by:

    checking whether, if there are at least 14 bytes of payload, trying to
find, in Wireshark's "manufacturer OUI" database, names for the OUIs of what
would be the destination and source MAC addresses and, if that succeeds,
assuming there's no control word;

    otherwise, if the first nibble of the first byte of the payload is 0,
assume there is a control word;

    otherwise, assume there's no control word.

So, if it couldn't find a manufacturer name for the destination and source MAC
addresses, and the upper 4 bits of the first byte of the destination MAC
address are 0, it will assume there's a pseudo-wire control word.

For the frames that aren't getting dissected correctly, there isn't a
manufacturer name for both the destination and source addresses (in one of
them, for example, there's a "manufacturer" name for the destination MAC
address of 02-29-99-99-00-21, namely "MS-NLB-PhysServer-32", but there's none
for the source MAC address of 00-00-00-00-00-93), *and* the upper 4 bits of the
first byte of the destination MAC address are 0.

So, you will have to change the default MPLS payload type to "Ethernet MPLS PW
(no CW, early implementations)", to force it to assume there's no control word.
 Open up Edit -> Preferences, open up the "Protocols" list, select "MPLS",
change the "Default decoder for MPLS payload" item, and click "OK".

So this isn't a bug, it's just one of those unfortunate situations where the
packet capture doesn't contain all the information needed to figure out how to
decode it, and the user has to supply some out-of-band information.

You are receiving this mail because:
  • You are watching all bug changes.