Re: String in OID

OoO En  cette matinée  pluvieuse du vendredi  05 juin 2009,  vers 10:30,
Dave Shield <[email protected]> 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
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users