#2420 MIB parser fails to parse value definition
NET-SNMP version: 5.4.3
Debian Squeeze
locke:/usr/share/mibs/ietf# snmptranslate .1
No log handling enabled - turning on stderr logging
Bad operator (INTEGER): At line 73 in /usr/share/mibs/ietf/SNMPv2-PDU
iso
Line 73 of MIB (RFC3416):
max-bindings INTEGER ::= 2147483647
I tried submitting this to IETF as an upstream bug, their response "It looks like the submitter wants to change the value definition into a type definition, which to me would be inconsistent with how the the SNMP specification employs max-bindings.'
net-snmp seems to want it to be a type definition with constraint. If changed to:
max-bindings ::= INTEGER (2147483647)
then the MIB parses without that error.
ASN.1 (X.680, http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.680-200811-I!!PDF-E ) has examples of a value definition, consistent with what's in the MIB. See sections 19.4 ("a INTEGER ::= 1"), 22.5, and 50.8.
The Net-SNMP MIB parser is not a complete parser, and it certainly does not handle (and is not meant to handle) this ASN.1 file that defines the SNMP PDU. Our code has no use for being able to parse this, which is also why it is not among the MIB files that we distribute.
Why do you want to parse this file? I don't think that it contains anything os use for the Net-SNMP tools?
This is still a problem in Ubuntu 20.04.3 LTS in 2021
sudo apt-get install snmp
sudo apt-get install snmp-mibs-downloader
snmpget -V
NET-SNMP version: 5.8
HP Enterprise / Aruba 5412R chassis switch (J9851A)
Load all MIBs, use SNMP version 2C, print all strings in ASCII format
snmpwalk -v 2c -c opensesame -m +ALL -0a 10.0.0.1 > HP5412R.txt
Bad operator (INTEGER): At line 73 in /usr/share/mibs/ietf/SNMPv2-PDU
less -N /usr/share/mibs/ietf/SNMPv2-PDU
73 max-bindings INTEGER ::= 2147483647
This is a bug in the Debian/Ubuntu snmp-mibs-downloader. It should not be installing SNMPv2-PDU in a location that net-snmp is looking for MIB modules. SNMPv2-PDU is not a MIB module.
Did you read my response from 2012? That file is in ASN.1 format, not SMIv2 (nor SMIv1). It is not intended for our parser.
/Niels