Regression in wireshark DOCSIS packet dissectors

[max ulidtko]

I have a bunch of .pcapng captures of a specific type of L2TP traffic. Mostly, it is DEPI control plane; see the Downstream External PHY Interface specification by CableLabs [CM-SP-DEPI].

The protocol is an extension of L2TP [RFC3931] and so uses a bunch of VendorID-scoped AVP extensions. Their parsing has been broken in Wireshark 1.10.6 in Ubuntu.

I don't remember which version had this working correctly, but it did. Upon viewing my captures I was able to see dissections of AVPs with vendorID=0x118b and registered type codes. Now I am not. Furthermore, parsing of plain IETF AVPs which follow vendor-specific ones is garbled by incorrect parsing of the latter.

To make it clear,

EXPECTED BEHAVIOR: CableLabs AVPs defined in [CM-SP-DEPI] as L2TP vendor extensions are loaded (from capture files), parsed, dissected and displayed correctly as before;

ACTUAL BEHAVIOR: Parsing errors in multiple packets, [Malformed Packet] tags on packets which are actually well-formed, parsing exceptions and incorrect interpretation of packet data.

I'm going to attach sample data to test and verify this. This is just 3 frames of a tunnel establishment, SCCRQ-SCCRP-SCCCN. Let me also give a verbal explanation of what is wrong in this specific case.

In the dissection of frame 2 we're going to see this.

  [Malformed Packet: L2TP]
      [Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]
          [Message: Malformed Packet (Exception occurred)]
          [Severity level: Error]
          [Group: Malformed]

You can tell that this doesn't correspond to truth (i.e. the dissector just simply crashed there) from several facts:
  1) the 10.80.12.10 peer was satisfied with the frame and has replied to it (doing so in compliance with the spec);
  2) the bytes are perfectly fine when parsed by hand. A CableLabs AVP starts at offset 0x72: 80 08 11 8b 00 c8 00 01. Its length is 8, and its length field is 8, too. 00c8₁₆ = 200₁₀, CableLabs AVP 200 is defined in section 7.5.4.1 of [CM-SP-DEPI], encodes DEPI Redundancy Capabilities and is specified to have length 8. This AVP is then immediately followed by another L2TP AVP 2 (vendorID = 0, attribute type = 2) of length 8, which is the last AVP and the end of the frame.
  3) Wireshark skips the dissection of the last AVP in that frame and displays an error instead.

There are also horrible errors in parsing of ICRP messages in my captures which didn't appear before. They appear to be caused by incorrect seeking over vendor AVPs. Unfortunately, the captures are confidential and it's not easy to cleanup them for publishing. However, I suppose that fixing the dissector crash above will fix them, too.

An example of correct (albeit incomplete) parsing of a vendor AVP is the last AVP of frame 1, starting at offset 0x00c8, length 10, vendorID 9 (Cisco), type 115. The absence of interpretation of some vendor AVP contents is *NOT* what I'm reporting here. This AVP is good.

[RFC3931]: https://tools.ietf.org/html/rfc3931
[CM-SP-DEPI]: http://www.cablelabs.com/wp-content/uploads/specdocs/CM-SP-DEPI-I08-100611.pdf

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: wireshark 1.10.6-1 [modified: usr/share/applications/wireshark.desktop]
ProcVersionSignature: Ubuntu 3.13.0-39.66-generic 3.13.11.8
Uname: Linux 3.13.0-39-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.5
Architecture: amd64
CurrentDesktop: Unity
Date: Tue Nov 11 19:46:44 2014
EcryptfsInUse: Yes
InstallationDate: Installed on 2013-06-27 (502 days ago)
InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
SourcePackage: wireshark
UpgradeStatus: Upgraded to trusty on 2014-08-11 (91 days ago)

[Evan Huus (eapache)]

1.10.6 is quite old as far as upstream Wireshark versions go. Is it a workaround at least to download and use a more recent Wireshark that might already have this fixed?

[Alexis La Goutte (alexis-lagoutte)]

This issue is fixed in https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13103 and i will be backport to last major release (2.2)