Title: A bug in parsing ASN_OCTET_STR as an index?

Hi all, I am using Net-SNMP 5.2.1 to implement RFC 2465

In it there is a table ipv6AddrPrefixTable

This table has 3 indexes:

         INDEX   { ipv6IfIndex,

                       ipv6AddrPrefix,

                       ipv6AddrPrefixLength }

ipv6AddrPrefix is an OCTET string. While the two others are 32 bits value indexes.

When I am trying to send the following getnext request to my implementation module:

snmpgetnext -v 2c -c public 10.172.129.74:162 IPV6-MIB::ipv6AddrPrefixAdvValidLifetime.5.16.63.254.5.1.255.255.1.0.2.4.35.255.254.69.107.20.64

I see that the indexes were not parsed correctly. Here is the situation as I see it in a gdb debugger:

(gdb) p *table_info->indexes->val.integer

$22 = 5                                   ß--- That's the first index with the value of 5 (correct!)

gdb) p *table_info->indexes->next_variable           

$23 = {next_variable = 0xc6386020, name = 0xc6386838, name_length = 0,

  type = 4 '\004', val = {integer = 0xc5a53420, string = 0xc5a53420 "",

    objid = 0xc5a53420, bitstring = 0xc5a53420 "", counter64 = 0xc5a53420,

    floatVal = 0xc5a53420, doubleVal = 0xc5a53420}, val_len = 16, name_loc = {

    4008636142 <repeats 128 times>}, buf = "\0", 'î' <repeats 39 times>,

  data = "" dataFreeHook = 0x0, index = 0}

The above indicates that there is an index value with length of 16 :val_len = 16 which is correct!

When I try to look at the octet string itself using bitstring:

(gdb) p table_info->indexes->next_variable->val.bitstring[1]

$26 = 0 '\0'

(gdb) p table_info->indexes->next_variable->val.bitstring[2]

$27 = 0 '\0'

(gdb) p table_info->indexes->next_variable->val.bitstring[3]

.

.

.

(gdb) p table_info->indexes->next_variable->val.bitstring[16]

$36 = 0 '\0'

As one can see the IPv6 octet string come out to be all zeros which is not correct.

Interestingly enough when I look into the third index value:

(gdb) p *table_info->indexes->next_variable->next_variable->val.integer

$39 = 63

I see the value of the first OCTET in the octet string!

I put a sniffer and I made sure that the indexes are traveling correctly to the agent.

It seems like there is a bug in parsing the octet string index. Its value is not copied to the bitstring memory area as it should be. In addition the first octet of the 2nd index ipv6AddrPrefix which is 63 is assigned as the value of the 3rd index: ipv6AddrPrefixLength instead of what should be 64).

A few questions:

1.      Is that a known problem (I am using Net-SNMP 5.2.1 which was ported to a specific platform)? If the answer is yes where can I get a fix to it?

2.      Can someone point to me to the place in the code where the indexes are parsed? I can use a debugger to try and figure out what is going on...

3.      Any other ideas?

Thanks for your help!

Shuki Sasson
Principal Engineer, Network Storage Group
EMC²
where information lives

Fax: 508 305 9026  
Phone: 508 305 8515
Cell: 617 834 4258
Pager: 877 919 0794 
Email: [EMAIL PROTECTED]

Reply via email to