VendorSpecific TLV 43 Cisco/SA Docsis 1.1/2.0 options encode/decode issue

[sergessn]

I use docsis utility version 0.9.6 for encoding and decoding CM/EMTA bootfiles. Few days ago I have downloaded sources from github, compiled the docsis binary file and tried to encode and decode CM/EMTA bootfiles which were made with 0.9.6. So I see the issue with encoding and decoding CM bootfiles with Cisco/SA VendorSpecific TLV 43 options for Docsis 1.1/2.0 devices in 0.9.8-dev.

In my bootfiles for Cisco/SA for Docsis 1.1/2.0 devices I have these VendorSpecific TLV 43 options: VendorSpecific { VendorIdentifier 0x00407b; GenericTLV TlvCode 4 TlvLength 1 TlvValue 0x00; GenericTLV TlvCode 6 TlvLength 1 TlvValue 0x01; } VendorSpecific { VendorIdentifier 0x000f21; GenericTLV TlvCode 4 TlvLength 1 TlvValue 0x00; GenericTLV TlvCode 6 TlvLength 1 TlvValue 0x01; } VendorSpecific { VendorIdentifier 0x000a73; GenericTLV TlvCode 4 TlvLength 1 TlvValue 0x00; GenericTLV TlvCode 6 TlvLength 1 TlvValue 0x01; }

I have encoded and decoded bootfile with docsis 0.9.6, I don't see any issue on these TLV options and SA/Cisco modems online on CMTS.

But when I tried to encode and decode my bootfiles with docsis 0.9.8-dev, I had error message “u_short length mismatch” on “GenericTLV TlvCode 4 TlvLength 1 TlvValue 0x00”;

$ docsis098 DOCSIS Configuration File creator, version 0.9.8-dev Copyright (c) 1999,2000,2001 Cornel Ciocirlan, ctrl@users.sourceforge.net Copyright (c) 2002,2003,2004,2005 Evvolve Media SRL, docsis@evvolve.com Copyright (c) 2014 - 2015 Adrian Simionov, daniel.simionov@gmail.com

$ docsis098 -e text.cfg key.txt /tmp/text.bin

Calculating CMTS MIC using TLVs:

Main { VendorSpecific { VendorIdentifier 0x00407b; u_short length mismatch $ $ docsis098 -d /tmp/text.bin Main { VendorSpecific { VendorIdentifier 0x00407b; u_short length mismatch $

When I tied to change length to 2 bytes “GenericTLV TlvCode 4 TlvLength 2 TlvValue 0x0000;” and encoded bootfile, my SA/Cisco DPX2203 modems begin reject this bootfile.

In sourceforge.net I found patch #1 Vendor Attributes SA DX233 (http://sourceforge.net/p/docsis/patches/1/).

According RFC (http://www.cablelabs.com/wp-content/uploads/specdocs/CM-SP-MULPIv3.0-I24-140403.pdf) and Excentis Docsis file editor (2.0) in bootfile can be a two types of TLV43 records:

1) DOCSIS vendor specific Extension Field (43):

The DOCSIS Extension Field is used to extend the capabilities of the DOCSIS specification, through the use of new and/or vendor-specific features. The DOCSIS Extension Field must be encoded using TLV 43 and must include the Vendor ID field (refer to Annex C.1.3.1.41) to indicate whether the DOCSIS Extension Field applies to all devices, or only to devices from a specific vendor. In this context, the Vendor ID is NOT 0xFFFFFF and the DOCSIS Extension Field contains vendor-specific information (see Annex C.1.1.18.2).

2) DOCSIS Extension Field (43):

The DOCSIS Extension Field is used to extend the capabilities of the DOCSIS specification, through the use of new and/or vendor-specific features. The DOCSIS Extension Field must be encoded using TLV 43 and must include the Vendor ID field (refer to Annex C.1.3.1.41) to indicate whether the DOCSIS Extension Field applies to all devices, or only to devices from a specific vendor. In this context, the Vendor ID of 0xFFFFFF is reserved to signal that this DOCSIS Extension Field contains general extension information (see Annex C.1.1.18.1)

I created a simple test bootfile in which I added both types of TLV 43 option in Excentis Docsis file editor.

Euro-DOCSIS vendor specific Extension Field:010203/04020000060101 Euro-DOCSIS Extension Field CM Ranging Class ID Extension:2 CM Load Balancing Group ID:3

When I decoded the bootfile in 0.9.8-dev I found, that TLV 43 records were incorrect parsed:

$ docsis098 -d new.cfg Main { VendorSpecific { VendorIdentifier 0x010203; CMRangingClassIDExtension 0; ExtendedCMTSMICConfiguration { ExtendedCMTSMICHMACDigestType 15; } } VendorSpecific { VendorIdentifier 0xffffff; CMRangingClassIDExtension 2; CMLoadBalancingGroupID 3; }

But docsis 0.9.6 decoded bootfile correctly:

$ docsis -d new.cfg Main { VendorSpecific { VendorIdentifier 0x010203; GenericTLV TlvCode 4 TlvLength 2 TlvValue 0x0000; GenericTLV TlvCode 6 TlvLength 1 TlvValue 0x01; } VendorSpecific { VendorIdentifier 0xffffff; GenericTLV TlvCode 4 TlvLength 2 TlvValue 0x0002; GenericTLV TlvCode 3 TlvLength 4 TlvValue 0x00000003; }

In 'docsis_symtable.h' file I didn't find 'DOCSIS vendor specific Extension Field' lines according Annex C.1.1.18.2, but I found only 'DOCSIS Extension Field' lines by Annex C.1.1.18.1

{ 200, "VendorSpecific", 43, 28, (encode_nothing), (decodeaggregate), 0, 0 }, /* TLV 22.43 MULPIv3.0-I24 Annex C.2.1.11 / { 352, "CMLoadBalancingPolicyID", 1, 200, (encode_uint), (decodeuint), 0, 0 }, / TLV 22.43.1 MULPIv3.0-I24 Annex C.1.1.18.1.1 _/ { 353, "CMLoadBalancingPriority", 2, 200, (encode_uint), (decodeuint), 0, 0 }, / TLV 22.43.2 MULPIv3.0-I24 Annex C.1.1.18.1.2 _/ { 354, "CMLoadBalancingGroupID", 3, 200, (encode_uint), (decodeuint), 0, 0 }, / TLV 22.43.3 MULPIv3.0-I24 Annex C.1.1.18.1.3 _/ { 355, "CMRangingClassIDExtension", 4, 200, (encode_ushort), (decodeushort), 0, 0 }, / TLV 22.43.4 MULPIv3.0-I24 Annex C.1.1.18.1.4 _/ { 202, "L2VPNEncoding", 5, 200, (encode_nothing), (decodeaggregate), 0, 0 }, / TLV 22.43.5 MULPIv3.0-I24 Annex C.1.1.18.1.5 */

Please fix the code of docsis utility to correct encode and decode bootfiles with Cisco/SA VendorSpecific TLV options for Docsis 1.1/2.0 devices.

[AdrianSimionov]

Hello Sergey,

I see this as a feature request, not a bug. I will also add a note to know limitations of the tool about this. This is how this tool worked also before, the only difference is that TLV 43.4 was not yet implemented before. I think it was not even developed by Cablelabs when Cisco/SA choosed subTLV 4 for their needs.

This happens because there is no check in place at this moment to check which vendor implementation of TLV 43.4 is in the config file. I implemented the Cablelabs Vendor Identifier but whenever a different vendor will try to use the same number, this problems can appear.

Nowadays vendor specific TLVs are not common anymore and vendors are using OIDs for their specific needs instead of TLVs. I also suggest that you should check with Cisco/SA if they have an OID which is doing the same configuration like TLV 43.4 and 43.6. If they have an OID, you can use the OID as a workaround instead of the TLV value.

You did not find "DOCSIS vendor specific Extension Field" in "docsis_symtable.h" because I did not implement that.

For whoever is interested to code this, we need to first check if we encode VendorID 0xffffff and only after that use the values from docsys_symtable, if the VendorID is different from 0xffffff we should consider all as being vendor independent and encode/decode as GenericTLV. I will think on a way to implement this feature but the architecture of the utility did not take into consideration that same TLVs can have different names and can be encoded different.

Best regards, Adrian.

[AdrianSimionov]

Sergey, please give it a try with the branch tlv43_vspecific which can be found in my fork on Github. Here you have a link: https://github.com/AdrianSimionov/docsis/archive/tlv43_vspecific.zip

Let me know if this fixes the issue you had. It seems to be working fine for me.

[sergessn]

Adrian,

Thanks for the new version with tlv43_vspecific. I built and checked the new docsis with my bootfiles and modems. The Encode/decode are working and modems accept new bootfiles. So you can add these changes to github.

[rlaager]

I merged in the changes. I figure if AdrianSimionov did all the hard work, the least I can do is click a couple buttons to create a pull request and merge it. ;) Thanks AdrianSimionov, you are awesome!