OoO En cette matinée pluvieuse du vendredi 05 juin 2009, vers 10:30,
Dave Shield <d.t.shi...@liverpool.ac.uk> disait :
>> I don't quite understand the rule to apply when an OCTET STRING is used
>> as an index of a table. It seems that when several string are used as
>> index, each string should be prefixed by its length (when converting to
>> an OID). However, when the string comes in last position, no length is
>> needed. What is the precise rule for all this?
> See RFC 2578, Section 7.7
Thanks for the pointer!
So, a variable-length string should always be prefixed by its length,
except if it is IMPLIED.
Here is an excerpt of LLDP-MIB:
LldpManAddress ::= TEXTUAL-CONVENTION
STATUS current
SYNTAX OCTET STRING (SIZE (1..31))
lldpLocManAddrTable OBJECT-TYPE
SYNTAX SEQUENCE OF LldpLocManAddrEntry
MAX-ACCESS not-accessible
STATUS current
::= { lldpLocalSystemData 8 }
lldpLocManAddrEntry OBJECT-TYPE
SYNTAX LldpLocManAddrEntry
MAX-ACCESS not-accessible
STATUS current
INDEX { lldpLocManAddrSubtype,
lldpLocManAddr }
::= { lldpLocManAddrTable 1 }
LldpLocManAddrEntry ::= SEQUENCE {
lldpLocManAddrSubtype AddressFamilyNumbers,
lldpLocManAddr LldpManAddress,
lldpLocManAddrLen Integer32,
lldpLocManAddrIfSubtype LldpManAddrIfSubtype,
lldpLocManAddrIfId Integer32,
lldpLocManAddrOID OBJECT IDENTIFIER
}
So, the index is an integer and a non implied variable-length
string. The string should be prefixed by its length. However, if I walk
this table, I get:
.1.0.8802.1.1.2.1.3.8.1.3.1.4.172.16.101.218 = INTEGER: 5
.1.0.8802.1.1.2.1.3.8.1.4.1.4.172.16.101.218 = INTEGER: unknown(1)
.1.0.8802.1.1.2.1.3.8.1.5.1.4.172.16.101.218 = INTEGER: 0
.1.0.8802.1.1.2.1.3.8.1.6.1.4.172.16.101.218 = OID: .1.3.6.1.4.1.45.3.53.1
I suppose that I should get:
.1.0.8802.1.1.2.1.3.8.1.3.1.4.4.172.16.101.218 = INTEGER: 5
.1.0.8802.1.1.2.1.3.8.1.4.1.4.4.172.16.101.218 = INTEGER: unknown(1)
.1.0.8802.1.1.2.1.3.8.1.5.1.4.4.172.16.101.218 = INTEGER: 0
.1.0.8802.1.1.2.1.3.8.1.6.1.4.4.172.16.101.218 = OID: .1.3.6.1.4.1.45.3.53.1
Am I right? I am not sure because snmpwalk interprets the string as
expected:
LLDP-MIB::lldpLocManAddrLen.ipV4."..e." = INTEGER: 5
LLDP-MIB::lldpLocManAddrIfSubtype.ipV4."..e." = INTEGER: unknown(1)
LLDP-MIB::lldpLocManAddrIfId.ipV4."..e." = INTEGER: 0
LLDP-MIB::lldpLocManAddrOID.ipV4."..e." = OID: SNMPv2-SMI::enterprises.45.3.53.1
Usually, when length is not too large, it should have displayed:
LLDP-MIB::lldpLocManAddrLen.ipV4.172.16.101.218. But maybe there is some
heuristics here.
I think that the implementation is wrong from the RFC point of
view. Some other equipments respect the RFC by using a "real" string :
LLDP-MIB::lldpLocManAddrLen.ipV4."172.16.101.218" = INTEGER: 5
Can you confirm my conclusion?
Many thanks for your help.
--
No fortunes found
------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
