Unable to parse RFC-1212 mib

[Hipska]

The mib RFC-1212 seems not to be supported by gosmi:

Parse module: /usr/share/snmp/mibs/RFC-1212:63:33: unexpected ".." (expected ")")

[MennoBot]

Hi,
I've experienced the same issue with latest telegraf 1.20.4 incorporating gosmi and RFC-1212, where telegraf couldn't load the RFC-1212 MIB and any dependant MIBs than also failed.
2021-12-02T09:21:05Z D! [agent] Initializing plugins
2021-12-02T09:21:06Z E! [inputs.snmp_trap] Module could not be loaded Could not load module at RFC-1212

Best Regards,
Menno

[sleepinggenius2]

The INTEGER (0..MAX) syntax is not valid in SMI.

gosmi/parser/common.go

Lines 78 to 79 in 841095e

	// Per RFC2578 Appendix A, not all valid ASN.1 refinements are allowed by SMI
	// Specifically, MIN and MAX are not valid range values, nor is '<' permitted on the lower or upper end point

The only thing defined in that MIB that I see used in any imports is the OBJECT-TYPE macro. Given that's not structural and the library already understands how to process that macro, you should be able to just delete that file without any consequences from this library. If you're not comfortable with that, then you should be able to replace any reference to RFC-1212 or RFC1212-MIB in your MIB imports with SNMPv2-SMI instead. I will also look into adding that to the import mapping to handle that automatically going forward. If the issue is that all the files in the path are just being loaded as modules indiscriminately, then I don't know what to do other than to remove that file from the path; the library was intended to only load imports as needed, so that file should never need to be loaded in practice.

[Hipska]

So you are saying, if the path is added, no need to manually call gosmi.LoadModule for each file in them? They get loaded when a call to gosmi.GetNode or gosmi.GetNodeByOID happens?

[sleepinggenius2]

No, I'm saying that if you want to look up ifIndex for example, then you just need to load IF-MIB, but not SNMPv2-SMI, SNMPv2-TC, SNMPv2-CONF, SNMPv2-MIB, or IANAifType-MIB, as they will be automatically loaded from the imports, if the files are named so that they can be found in the path (<module-name> or <module-name>.[mi2|mib|my|txt]). This is like including the following in your snmp.conf for Net-SNMP:

mibdirs /usr/share/snmp/mibs
mibs +IF-MIB

I believe what you're effectively doing at this point is mibs +ALL instead.

[Hipska]

Indeed, so what you suggest when wanting to do GetNodeByOID? Then all possible mibs would need to be loaded, right?

[sleepinggenius2]

Yes, if you don't know what module the node that you're looking for is in, then you would need to load all of the relevant MIBs first. However, in your scenario, since there are no objects defined in RFC1212-MIB, there's no reason to load that module. When polling SNMP data, you should already know what module the node that you're requesting is in. Doing a lookup by OID would typically only be done when processing traps, but in order to support that use case, you would only need to load any modules that are using the TRAP-TYPE or NOTIFICATION-TYPE macro, so RFC1212-MIB would still not be relevant.

[MennoBot]

I still have problems processing FCMGMT-MIB or SMA2000TRAPS-MIBS with telegraf (incorporating gosmi), replacing RFC-1212 with SNMPv2-SMI didn't solve.

So I installed go, gosmi and tried the parse and smi programs on the 2 affected MIBS, they both have the same problem that gosmi apprears to only know the OID of the first trap definition it encounters and doesn't store the OID of the remainder of the traps, without warning/debug messages:
# Get the definition of the first trap, this works:
./smi -d -p /usr/share/snmp/mibs -m FCMGMT-MIB.txt .1.3.6.1.3.94.0.1
Loaded module FCMGMT-MIB
Search path: /usr/share/snmp/mibs
Loaded modules:
()
SNMPv2-SMI (/usr/share/snmp/mibs/SNMPv2-SMI.txt)
SNMPv2-TC (/usr/share/snmp/mibs/SNMPv2-TC.txt)
FCMGMT-MIB (/usr/share/snmp/mibs/FCMGMT-MIB.txt)
[{"Access":"Unknown","Decl":"TrapType","Description":"The overall status of the connectivity unit has \nchanged.\nRecommended severity level (for filtering): alert","Kind":"Notification","Name":"connUnitStatusChange","Oid":[1,3,6,1,3,94,0,1],"OidLen":8,"Status":"Unknown","Type":null,"SmiType":null}]

# get the definition of the 2nd trap in the MIB defined, which is trap #3 :
./smi -d -p /usr/share/snmp/mibs -m FCMGMT-MIB.txt .1.3.6.1.3.94.0.3
Loaded module FCMGMT-MIB
Search path: /usr/share/snmp/mibs
Loaded modules:
()
SNMPv2-SMI (/usr/share/snmp/mibs/SNMPv2-SMI.txt)
SNMPv2-TC (/usr/share/snmp/mibs/SNMPv2-TC.txt)
FCMGMT-MIB (/usr/share/snmp/mibs/FCMGMT-MIB.txt)
Subtree Error: Could not find node for OID 1.3.6.1.3.94.0.3

# It doesn't know the OID, do the lookup with name instead:
./smi -d -p /usr/share/snmp/mibs -m FCMGMT-MIB.txt connUnitDeletedTrap
Loaded module FCMGMT-MIB
Search path: /usr/share/snmp/mibs
Loaded modules:
()
SNMPv2-SMI (/usr/share/snmp/mibs/SNMPv2-SMI.txt)
SNMPv2-TC (/usr/share/snmp/mibs/SNMPv2-TC.txt)
FCMGMT-MIB (/usr/share/snmp/mibs/FCMGMT-MIB.txt)
[{"Access":"Unknown","Decl":"TrapType","Description":"A connUnit has been deleted from this agent.\nRecommended severity level (for filtering): warning","Kind":"Notification","Name":"connUnitDeletedTrap","Oid":null,"OidLen":0,"Status":"Unknown","Type":null,"SmiType":null}]

Notice how indeed the Oid is missing from this definition!
And telegraf uses gosmi to translate the oid in the names.

I tried changing the trap #3 into #2 into the MIB, perhaps gosmi didn't like the gap in the trap order but that made no difference.

Attached the MIB and also the output of the parse command for the MIB (in which I cannot see anything out of the ordinary).
parse_FCMGMT-MIB.txt
parse_FCMGMT-MIB.txt
FCMGMT-MIB.txt

[sleepinggenius2]

It looks like there's an issue with the way that the TRAP-TYPE macro is mapped to an OID (specifically the implied zero). I have a solution that seems to be working for that scenario specifically, but I'm looking to see if there might be a better solution for the more generic use case of unnamed intermediary sub-identifiers. I also need to do a little more research to verify if that's even valid in SMI syntax. It may take a few days to get a new release out with the fix.

Honestly, I so rarely come across SMIv1 MIBs these days that I've never actually encountered this in practice myself. I'm sorry that you have to deal with such old equipment that it is still using the experimental FCMGMT-MIB and not the standard FC-MGMT-MIB (RFC 4044).

[MennoBot]

The MIBs that are failing and use SMIv1 / FCMGMT-MIB are the MIBs delivered with the latest and greatest HP(E) storage and servers ...

[MennoBot]

Did you already find some time to investigate the issue on SMIv1 MIBs?

[sleepinggenius2]

The fix for this will be in the next release, along with a number of other fixes and enhancements. I believe the implementation is complete at this point, but I am working through testing and documentation. I do not have a release date yet, but I'm hoping it will be by the end of the month.

[Hipska]

Great! Is there somewhere a PR where we can follow?

[sleepinggenius2]

I went ahead and committed just the fix for this issue. The v0.5.0 release is going to be a significant overhaul and is taking far longer than expected, so I didn't want you to have to wait any longer for this.

[Hipska]

Great thanks for the fix!

is there somewhere a branch or fork where we can follow the ongoing work for 0.5?

[Hipska]

@sleepinggenius2 ?

[sleepinggenius2]

Yes?

[Hipska]

Can you answer my question please?

is there somewhere a branch or fork where we can follow the ongoing work for 0.5?

[sleepinggenius2]

No, there is nothing publicly available at this time.