PacketCable 2.0 dialplan OID (CL-PKTC-EUE-RST-MIB::pktcEUERSTDMValue)

[mbowe-au]

I believe the docsis compiler is using wrong OID for the PacketCable 2.0 dialplan

Should be CL-PKTC-EUE-RST-MIB::pktcEUERSTDMValue.1 (.1.3.6.1.4.1.4491.2.2.8.2.1.1.3.1.1.2.1) rather than CL-PKTC-EUE-RST-MIB::pktcEUERSTDMValue.0 (.1.3.6.1.4.1.4491.2.2.8.2.1.1.3.1.1.2.0)

I believe the fix is docsis.c, line 226 :

Should be : memcpy(tlvbuf + tlvbuflen, "\x06\x12\x2b\x06\x01\x04\x01\xa3\x0b\x02\x02\x08\x02\x01\x01\x03\x01\x01\x02\x01", 20);

Rather than : memcpy(tlvbuf + tlvbuflen, "\x06\x12\x2b\x06\x01\x04\x01\xa3\x0b\x02\x02\x08\x02\x01\x01\x03\x01\x01\x02\x00", 20);

[rlaager]

I'm not in any position to test this, so I'd have to take your word for it. But why would we want to use index 1 rather than 0 here?

[mbowe-au]

I agree its a bit strange, as .0 is the usual way for OIDS in general.

However all of those OIDs in that region are .1

I believe they are references to other tables?

You can see it here https://www.excentis.com/blog/packetcable-20-edva-config-files

The item I am talking about is shown on line 47 in pink. See how it is a .1, and all the other indexes in that region are also .1 rather than the more usual .0

The docsis compiler works fine for all the other OIDs in this region, it is just this particular one that doesn't work properly. It has been hardcoded as a big hexstring to allow for that special encode/decode handling of the dialplan.txt file. I guess the person who wrote the hexstring just assumed .0 was the correct way? I don't think that using this tool for packetcable 2.0 is very common, so this might be a bug that has gone undiscovered so far.

I patched my local copy from .0 to .1 and then I could then correctly compile/decode the Packetcable 2.0 config files and dialplan.txt.

I can upload an example packetcable 2.0 mta config file if you need one for testing

[edit: minor change to try and improve clarity]

[AdrianSimionov]

I specifically hardcoded it this way as this is the way chipset manufacturers implemented the PacketCable 2.0. It was done based on lab testing at LGI in Europe. If you have a specific use-case where .0 is used, check with the chipset manufacturer if they are following CableLabs. I guess we could think of an option where both .0 and .1 would be used but I would not just change .1 into .0

[rlaager]

@AdrianSimionov It sounds like you have that backwards. The proposal here is to change it from .0 to .1.

[AdrianSimionov]

I would not change it to .0 unless: 1) there is a valid reason and there is a use-case which requires it. @mbowe-au , I assume your lab tests show that there are now chipset implementations with .0 index too? 2) remains backwards compatible for the use-cases where .1 is the index in use.

[rlaager]

@AdrianSimionov @mbowe-au wants to change it to .1. It is currently .0. It sounds like you think it is currently .1, so you're actually in agreement?

[mbowe-au]

Sorry @AdrianSimionov , possibly my wording wasn't super clear. I have now made a small edit to my post to try and clarify.

I am saying the compiler is creating that OID as .0, when I think it is meant to be .1 And it sounds like you agree that .1 is correct.

[AdrianSimionov]

From what I remember, it is .1 for PacketCable 2.0. All good from my side.