Re: MRTG fails to handle different Request Id sizes

On 11 Sep 2002 10:35:02 -0400, "Vann H. Walke" <[email protected]> said:
> I'm attempting to use MRTG on Dell 5012 10-port 1GB switches.  On some
> runs MRTG completes successfully, other times it fails.
[...]
> I think I have localized the problem to the way in which the Dell switch
> encodes the Request Id.

Very good analysis.

> When mrtg completes successfully, the Request ID is sent as

>    02 04 XX XX XX XX
> where 02 indicates integer, 
>       04 indicates the length 
> and   XX XX XX XX is the request ID.

> For some reason the Dell switch sometimes encodes the Request ID as
>    02 05 XX XX XX XX XX
> using 5 bytes for the request ID.  This seems odd, but I can't find
> anything reporting it as "illegal" in the RFC.

Using 5 bytes to encode the request ID is not illegal.  What is
illegal is encoding a positive value >= 2^31 as a request ID, because
the request ID is an Integer32 (see RFC 1905).  The Dell agent has
this problem (as do a few others).

And what breaks MRTG is that the Dell agent turns a negative request
ID into a (large) positive response ID.  The SNMP code in MRTG then
fails to match the response against the request.

> The ucdsnmp tools (snmpwalk, snmpget etc..) handle the response.

That is because they only compare the last 32 bits of the
request/response IDs, at least when run on 32-bit platforms.

> Simple Network Management Protocol
>     Version: 1
>     Community: public
>     PDU type: GET
>     Request Id: 0x8d141d83

Actually the request ID that MRTG sent corresponds to the decimal
number -1928061565.

[...]
> 0000  00 30 1e 68 39 40 00 06 5b 84 77 90 08 00 45 00   .0.h9@..[.w...E.
> 0010  00 75 00 00 40 00 40 11 ae e4 c0 1a 08 08 c0 a8   .u..@.@.........
> 0020  02 c9 81 fd 00 a1 00 61 ca 1a 30 57 02 01 00 04   .......a..0W....
> 0030  06 70 75 62 6c 69 63 a0 4a 02 04 8d 14 1d 83 02   .public.J.......
                                         ^^^^^^^^^^^
[...]

> Simple Network Management Protocol
>     Version: 1
>     Community: public
>     PDU type: RESPONSE
>     Request Id: 0x8d141d83

This request ID corresponds to the decimal number 2366905731.

[...]
> 0000  00 06 5b 84 77 90 00 30 1e 68 39 40 08 00 45 00   ..[[email protected].
> 0010  00 92 d2 26 00 00 3f 11 1d a1 c0 a8 02 c9 c0 1a   ...&..?.........
> 0020  08 08 00 a1 81 fd 00 7e 01 3e 30 74 02 01 00 04   .......~.>0t....
> 0030  06 70 75 62 6c 69 63 a2 67 02 05 00 8d 14 1d 83   .public.g.......
                                         ^^^^^^^^^^^^^^

The next version of SNMP_Session.pm has a global variable
"$default_avoid_negative_request_ids", which you should set to a
non-zero value before the first SNMP_Session object is created.  This
will work around the problem by only using request IDs in the range
0-(2^31)-1.  I'm attaching a copy so that you can try it.

But the real problem is in the agent, so please open a call with Dell
and point them to RFC 1905 that says that request IDs are
"Integer32".
-- 
Simon.


-- Attached file removed by Listar and put at URL below --
-- Type: application/octet-stream
-- Size: 28k (28855 bytes)
-- URL : http://www.ee.ethz.ch/~slist/pantomime/02-SNMP_Session.pm


--
Unsubscribe mailto:[email protected]?subject=unsubscribe
Help        mailto:[email protected]?subject=help
Archive     http://www.ee.ethz.ch/~slist/mrtg-developers