buglwIP - A Lightweight TCP/IP stack - Bugs: bug #25632, SNMP agent does not handle 32-bit...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #25632: SNMP agent does not handle 32-bit request IDs correctly

Submitted by:  Simon Goldschmidt <goldsimon>
Submitted on:  Wed 18 Feb 2009 04:38:16 PM UTC  
 
Category:  None Severity:  3 - Normal
Item Group:  Faulty Behaviour Status:  Works For Me
Privacy:  Public Assigned to:  None
Open/Closed:  Closed Planned Release:  None
lwIP version:  1.3.0

Fri 13 Feb 2015 08:13:50 PM UTC, comment #3: 

Please leave a comment if this is really a problem. It worked for me when last testing.

Simon Goldschmidt <goldsimon>
Project Administrator
Fri 29 Jan 2010 02:33:40 PM UTC, comment #2: 

I've just been testing the snmp code on a big endian system and I didn't face any problem. I haven't been able to do a complete snmpwalk though, only testing the code (i.e. unit-test like).

However, there were no problems at all decoding and encoding a 16- or 32-bit request-ID (no matter if the ID was positive or negative). So any pointers on what's wrong here are highly appreciated.

Looking at the packet log in the initial comment, the agent seems to have decoded the request-ID as 16-bit (0xECCB) instead of 32-bit (0x1C7BECCB). Then when sending, a 3rd octet is added to encode 0xECCB as unsigned. The question is why and where the upper 16-bits are thrown away...

Jesus, if you have any more input on this, please let us know!

Simon Goldschmidt <goldsimon>
Project Administrator
Tue 05 May 2009 06:03:39 PM UTC, comment #1: 

I just tested this with the win32 port and wireshark gives me a 32-bit requestID both for request and respons.

Could this be another problem of the agent running on big-endian? The Luminary ARM-Cortex most certainly will be big-endian!

Can anyone test this with a big-endian system?

Aside from that, we had a big-endian-bug in snmp_asn1_dec_s32t(), can there be a similar bug in snmp_asn1_enc_s32t()? And after all, why is the request ID de-/encoded as signed? I thought it was an unsigned 32-bit value?

Simon Goldschmidt <goldsimon>
Project Administrator
Wed 18 Feb 2009 04:38:16 PM UTC, original submission:  

Found by Jesus Alvarez on lwip-users on Feb. 18th 2009:

I am using the lwIP 1.3.0 SNMP agent on an embedded controller using the
Luminary ARM-Cortex microcontrollers. The implementation works but appears
to be sensitive to the version of the SNMP tool used to query it.

Using net-snmp 5.4.2.1 under Windows a simple query to sysLocation.0 works.
Yet the same query fails from net-snmp 5.4.1 under Debian Linux. The UDP
query and response is included below for both cases. A router used as a
reference responds to queries properly with both versions.

If I use debug mode (-D ALL) on the query that fails I get

  trace: _sess_process_packet(): snmp_api.c, 5388:
  sess_process_packet: unhandled PDU

It appears that the lwIP SNMP agent is processing one of the queries
incorrectly but I can't identify what portion of the ASN-1 encoded response
packet is causing the rejection. I also don't understand why the content of
the query packets is different on the two versions. Any suggestions would be
appreciated.

Thanks,
Jesus Alvarez
----------
C:>snmpget -V
NET-SNMP version: 5.4.2.1

C:>snmpget -v 1 -c public -d -r 0 192.168.1.222 sysLocation.0

Sending 41 bytes to UDP: [0.0.0.0]->[192.168.1.222]:161
0000: 30 27 02 01  00 04 06 70  75 62 6C 69  63 A0 1A 02    0'.....publicá..
0016: 02 32 0B 02  01 00 02 01  00 30 0E 30  0C 06 08 2B    .2.......0.0...+
0032: 06 01 02 01  01 06 00 05  00                          .........

Received 54 bytes from UDP: [0.0.0.0]->[192.168.1.222]:161
0000: 30 34 02 01  00 04 06 70  75 62 6C 69  63 A2 27 02    04.....publicó'.
0016: 02 32 0B 02  01 00 02 01  00 30 1B 30  19 06 08 2B    .2.......0.0...+
0032: 06 01 02 01  01 06 00 04  0D 4C 61 6B  65 20 4D 61    .........Lake Ma
0048: 72 79 2C 20  46 4C                                    ry, FL

SNMPv2-MIB::sysLocation.0 = STRING: Lake Mary, FL
----------
$ snmpget -V
NET-SNMP version: 5.4.1
$ snmpget -v 1 -c public -d -r 0 192.168.1.222 sysLocation.0

Sending 43 bytes to UDP: [192.168.1.222]:161
0000: 30 29 02 01  00 04 06 70  75 62 6C 69  63 A0 1C 02    0).....public...
0016: 04 1C 7B EC  CB 02 01 00  02 01 00 30  0E 30 0C 06    ..{........0.0..
0032: 08 2B 06 01  02 01 01 06  00 05 00                    .+.........

Received 55 bytes from UDP: [192.168.1.222]:161
0000: 30 35 02 01  00 04 06 70  75 62 6C 69  63 A2 28 02    05.....public.(.
0016: 03 00 EC CB  02 01 00 02  01 00 30 1B  30 19 06 08    ..........0.0...
0032: 2B 06 01 02  01 01 06 00  04 0D 4C 61  6B 65 20 4D    +.........Lake M
0048: 61 72 79 2C  20 46 4C                                 ary, FL

Timeout: No Response from 192.168.1.222.

---------------------------------------------------------
I got a very prompt response from the net-snmp list on this issue. See the
details below. Apparently there is a problem handling 32-bit request IDs in
the lwIP 1.3.0 SNMP agent.

Regards,
Jesus Alvarez

-----Original Message-----
From: Dave Shield
Sent: Wednesday, February 18, 2009 10:53 AM
To: Jesus Alvarez
Cc: -email is unavailable-
Subject: Re: Discrepancy in queries to lwIP

2009/2/18 Jesus Alvarez <jalvarez@micromint.com>:

> > Using net-snmp 5.4.2.1 under Windows a simple query to sysLocation.0

works.

> > Yet the same query fails from net snmp 5.4.1 under Debian Linux. The UDP
> > query and response is included below for both cases.


> > It appears that the lwIP SNMP agent is processing one of the queries
> > incorrectly but I can't identify what portion of the ASN-1 encoded

response

> > packet is causing the rejection. I also don't understand why the content

of

> > the query packets is different on the two versions. Any suggestions would

be

> > appreciated.


The first (successful) query is using a 16-bit request ID.
This is handled correctly by the remote agent,
which returns a response with the same ID:

> > Sending 41 bytes to UDP: [0.0.0.0]->[192.168.1.222]:161
> > 0000: 30 27 02 01  00 04 06 70  75 62 6C 69  63 A0 1A 02

0'.....publicá..

> > 0016: 02 32 0B...


> > Received 54 bytes from UDP: [0.0.0.0]->[192.168.1.222]:161
> > 0000: 30 34 02 01  00 04 06 70  75 62 6C 69  63 A2 27 02

04.....publicó'.

> > 0016: 02 32 0B...


Note that the last four octets are the same in both cases:
   04 02 32 0B

The second (failing) query is using a 32-bit request ID.
This is perfectly valid, but the remote agent is mangling it,
and only returning the lower 16-bits in the response:

> > Sending 43 bytes to UDP: [192.168.1.222]:161
> > 0000: 30 29 02 01  00 04 06 70  75 62 6C 69  63 A0 1C 02

0).....public...

> > 0016: 04 1C 7B EC  CB....


> > Received 55 bytes from UDP: [192.168.1.222]:161
> > 0000: 30 35 02 01  00 04 06 70  75 62 6C 69  63 A2 28 02

05.....public.(.

> > 0016: 03 00 EC CB....


Note:    02 04 1C 7B EC EB
becomes  02 03 00 EC CB

The client notes that the request ID in the response doesn't
match the original one, so discards the message.

This is a bug in the remote agent.   Complain to the lwIP people.

As a workaround:

    $ man snmp.conf

           16bitIDs yes
              restricts requestIDs, etc to 16-bit values.

              The SNMP specifications define these ID fields as  32-bit
              quantities,  and  the  Net-SNMP  library  typically  ini-
              tialises them to random  values  for  security.   However
              certain  (broken)  agents cannot handle ID values greater
              than 216 - this option allows interoperability with such
              agents.

[Note: this goes in snmp.conf, not snmpd.conf]

Dave

Simon Goldschmidt <goldsimon>
Project Administrator

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by goldsimon (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-02-13 goldsimon StatusNeed Info => Works For Me
        Open/ClosedOpen => Closed
    2009-05-05 goldsimon StatusNone => Need Info

    Back to the top


    Powered by Savane 3.5