RE: A bug in parsing ASN_OCTET_STR as an index?

#1 (**permalink**) 11-04-2005

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C5E182.28B995FF
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Thanks all, I found the bug it was an omitted return statement due to a
"heavy finger" while porting function parse_one_oid_index mib.cxx.

Once I fixed it everything is working as expected...

=20

Thanks,

Shuki

=20

_____ =20

From: net-snmp-coders-admin@lists.sourceforge.net
[mailto:net-snmp-coders-admin@lists.sourceforge.net] On Behalf Of =
sasson,
shuki
Sent: Friday, November 04, 2005 2:20 PM
To: net-snmp-coders@lists.sourceforge.net
Subject: A bug in parsing ASN_OCTET_STR as an index?

=20

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

In it there is a table ipv6AddrPrefixTable=20

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 =3D 5 <----- That's the first =
index with
the value of 5 (correct!)

gdb) p *table_info->indexes->next_variable =20

$23 =3D {next_variable =3D 0xc6386020, name =3D 0xc6386838, name_length =
=3D 0,=20

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

objid =3D 0xc5a53420, bitstring =3D 0xc5a53420 "", counter64 =3D =
0xc5a53420,=20

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

4008636142 <repeats 128 times>}, buf =3D "\0", '=EE' <repeats 39 =
times>,=20

data =3D 0x0, dataFreeHook =3D 0x0, index =3D 0}

The above indicates that there is an index value with length of 16 =
:val_len
=3D 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 =3D 0 '\0'

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

$27 =3D 0 '\0'

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

..

..

..

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

$36 =3D 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 =3D 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?=20

Thanks for your help!

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

Fax: 508 305 9026 =20
Phone: 508 305 8515
Cell: 617 834 4258
Pager: 877 919 0794=20
Email: sasson_shuki@emc.com=20

------_=_NextPart_001_01C5E182.28B995FF
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">

<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered)">
<title>A bug in parsing ASN_OCTET_STR as an index?</title>

<style>

</style>

</head>

<body lang=3DEN-US link=3Dblue vlink=3D"#606420">

<div class=3DSection1>

Thanks all, I found the bug it was =
an
omitted return statement due to a “heavy finger” while =
porting =A0function
parse_one_oid_index mib.cxx.

Once I fixed it everything is =
working as
expected…

 

Thanks,

Shuki

 

<div>

<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'>

<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>

</div>

From:
net-snmp-coders-admin@lists.sourceforge.net =
[mailto:net-snmp-coders-admin@lists.sourceforge.net]
On Behalf Of sasson, =
shuki 
Sent: Friday, November =
04, 2005
2:20 PM 
To: =
net-snmp-coders@lists.sourceforge.net 
Subject: A bug in =
parsing
ASN_OCTET_STR as an index?

</div>

 

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:

       &n bsp;
INDEX   { ipv6IfIndex,

       &n bsp;   =
        &n bsp;  
ipv6AddrPrefix,

       &n bsp;   =
        &n bsp;  
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 =3D
5        & nbsp;  &nbsp=
;        & nbsp;  &nbsp=
;        & nbsp; </fo=
nt>
=DF---
That's the first index with the value of 5 (correct!)

gdb) p
*table_info->indexes->next_variable      &=
nbsp;     


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

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

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

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

    4008636142 <repeats 128 =
times>}, buf =3D
"\0", '=EE' <repeats 39 times>, 

  data =3D 0x0, dataFreeHook =3D 0x0, index =3D =
0}

The above indicates that there is an index
value with length of 16 :val_len =3D 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]</fo=
nt>

$26 =3D 0 '\0'

(gdb) p
table_info->indexes->next_variable->val.bitstring[2]</fo=
nt>

$27 =3D 0 '\0'

(gdb) p
table_info->indexes->next_variable->val.bitstring[3]</fo=
nt>

.

.

.

(gdb) p
table_info->indexes->next_variable->val.bitstring[16]</f=
ont>

$36 =3D 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.inte=
ger

$39 =3D 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</font=
> 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=B2</=
font> 
where =
information lives

Fax: 508 305 9026   
Phone: 508 305 8515 
Cell: 617 834 4258 
Pager: 877 919 0794  
Email: sasson_shuki@emc.com 

</div>

</body>

</html>

------_=_NextPart_001_01C5E182.28B995FF--

-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/...et-snmp-coders

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode