Cisco Mibs Brake when using mib names
If I use the Cisco mibs by name (i.e. ciscoMemoryPoolFree), I would get the following error:
"errorMessage": "invalid OBJECT ID 48.1.1.1.7.7: first num too large",
"errorType": "Function<OpenSSL::ASN1::ASN1Error>"
If I use the OID it works and provides the correct feedback
Thx for the report.
Is the oid from the error message correct? What's the difference in the logs when you turn on the debug output?
Yes the mib is correct, but it seems the first part of it gets cut off see below:
OID = 1.3.6.1.4.1.9.9.48.1.1.1.6 = CISCO-MEMORY-POOL-MIB::ciscoMemoryPoolFree OID = 1.3.6.1.4.1.9.9.48.1.1.1.7 = CISCO-MEMORY-POOL-MIB::ciscoMemoryPoolLargestFree
That looks like a mib parsing issue. Do you think you can write a patch to add support for that case? Or alternatively, can you upload the cisco mibfile, so I can do it when I have the time?
Sorry still a newbie, I can give it a shot.
List of cisco mibs: https://github.com/cisco/cisco-mibs/tree/main/v2 Actual mib in question: https://github.com/cisco/cisco-mibs/blob/main/v2/CISCO-MEMORY-POOL-MIB.my
thx, I'll see what I can do.
It seems that you are missing a MIB file in the mibdir, particularly this one. I could reproduce it by doing:
require "netsnmp"
require "netsnmp/mib/parser"
NETSNMP::MIB.load(File.join(__dir__, "CISCO-SMI.my"))
NETSNMP::MIB.load(File.join(__dir__, "CISCO-MEMORY-POOL-MIB.txt"))
puts NETSNMP::MIB.oid("ciscoMemoryPoolFree")
# => 1.3.6.1.4.1.9.9.48.1.1.1.6
Can you confirm that you're missing the file?
Interesting!!! I did have it like this:
NETSNMP::MIB.load('./CISCO-MEMORY-POOL-MIB.my')
NETSNMP::MIB.load('./CISCO-PROCESS-MIB.my')
NETSNMP::MIB.load('./CISCO-PROCESS-CAPABILITY.my')
NETSNMP::MIB.load('./CISCO-REMOTE-ACCESS-MONITOR-MIB.my')
NETSNMP::MIB.load('./CISCO-FIREWALL-MIB.my')
NETSNMP::MIB.load('./CISCO-QOS-PIB-MIB.my')
NETSNMP::MIB.load('./CISCO-SMI.my')
NETSNMP::MIB.load('./powernet441.mib')
hmm let me try to load the entire directory some how, but the error does change when I use the following:
NETSNMP::MIB.load(File.join(__dir__, "CISCO-SMI.my"))
NETSNMP::MIB.load(File.join(__dir__, "CISCO-MEMORY-POOL-MIB.txt"))
Let me try this and get back to you today.
After changing the all of the above to NETSNMP::MIB.load(File.join(__dir__, "MIB")) format it states the following error:
"errorMessage": "Failed to match sequence (SPACE{0, } MODULES?) at line 16 char 1.", "errorType": "Function<Parslet::ParseFailed>",
After checking it with another MIB CISCO-PROCESS-MIB.my
"errorMessage": "invalid OBJECT ID 109.1.1.1.1.4.1: invalid separator", "errorType": "Function<OpenSSL::ASN1::ASN1Error>",
Above Error:
"CISCO-PROCESS-MIB::cpmCPUTotal1min.1"
No error: 1.3.6.1.4.1.9.9.109.1.1.1.1.4
so if I understood correctly, there was an error parsing the "CISCO-PROCESS-MIB.my" file?
Yes that's correct
can you try with the master branch? I'm able to load those files already. Perhaps this has been fixed with my last week's patch.
Sorry, i do not see any change still the following error:
"errorMessage": "invalid OBJECT ID 42.1.3.5.1.34: first num too large",
"errorType": "Function<OpenSSL::ASN1::ASN1Error>"
"errorMessage": "invalid OBJECT ID 109.1.1.1.1.4.1: invalid separator",
"errorType": "Function<OpenSSL::ASN1::ASN1Error>",
I am using the ruby gem and i don't see a new version added could that be it?
yes, that should be it. If you're using a gemfile, put this there instead:
gem "netsmp", git: "https://github.com/swisscom/ruby-netsnmp.git" #, branch: "master"
and execute your script with "bundle exec".
@seanfariacustomink any updates?
Hey, @HoneyryderChuck sorry for the delay got sick. Now i can't use any Cisco mibs name or oid.
With oid:
"errorMessage": "cannot load such file -- netsnmp", "errorType": "Init<LoadError>",
With Name:
"errorMessage": "cannot load such file -- netsnmp", "errorType": "Init<LoadError>",
did you blindly copy-paste my statement above? because it contains a type (netsnmp, not netsmp).
no I did not:

do i need this like before?
require "netsnmp/mib/parser"
apologies for the delay, seems I missed the notification.
Nothing strikes me out of the ordinary for that error to happen.