Bug ID |
11949
|
Summary |
Wireshark 2.0.1 MPLS dissector not decoding payload when control word is present in pseudowire
|
Product |
Wireshark
|
Version |
2.0.1
|
Hardware |
x86-64
|
OS |
Windows 7
|
Status |
CONFIRMED
|
Severity |
Normal
|
Priority |
Low
|
Component |
Dissection engine (libwireshark)
|
Assignee |
[email protected]
|
Reporter |
[email protected]
|
Created attachment 14191 [details]
Pseudowire with a control word
Build Information:
Version 2.0.1 (v2.0.1-0-g59ea380 from master-2.0)
Copyright 1998-2015 Gerald Combs <[email protected]> and contributors.
License GPLv2+: GNU GPL version 2 or later
<http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (64-bit) with Qt 5.3.2, with WinPcap (4_1_3), with libz 1.2.8, with
GLib 2.42.0, with SMI 0.4.8, with c-ares 1.9.1, with Lua 5.2, with GnuTLS
3.2.15, with Gcrypt 1.6.2, with MIT Kerberos, with GeoIP, with QtMultimedia,
with AirPcap.
Running on 64-bit Windows 7 Service Pack 1, build 7601, with locale C, with
WinPcap version 4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version
1.0 branch 1_0_rel0b (20091008), with GnuTLS 3.2.15, with Gcrypt 1.6.2, without
AirPcap.
Intel(R) Core(TM) i7-3520M CPU @ 2.90GHz (with SSE4.2), with 7887MB of
physical memory.
Built using Microsoft Visual C++ 12.0 build 31101
--
Somewhere in the new code base (2.0.x) the default decoding of MPLS payload has
changed, from being able to correct identify pseudowire payload when a control
word is present to not doing this. Not being a programmer by trade, I believe
this might have been changed here;
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11271 but might also have
been another commit.
Pseudowire with control word is a commonly occuring feature and should not
require manual 'Decode as...' for every MPLS label combination for the payload
to be decoded correctly.
RFC4385 recommends the "first nibble == 0" to identify the presence of a
control word, I know this can break other scenarios where pseudowires without
control word is used in combination with certain MAC ranges directly after the
MPLS header, but this seems like a less occuring behavior.
We need either a global option to enable the old style MPLS payload decoding as
"Ethernet MPLS PW (CW is heuristically detected)" on all packets of a capture
or this as a default.
You are receiving this mail because:
- You are watching all bug changes.