[collectd] Bug#540394: collectd: generates broken SNMP queries

[Sebastian Harl]

Hi,

(This is a follow-up to Debian bug #540394 - see
http://bugs.debian.org/540394 for details.)

On Fri, Aug 07, 2009 at 07:51:55PM +0200, Simon Richter wrote:
> I'm using this fragment to query my WLAN AP:
> 
> <Data "netgear_wg102_traffic">
>     Type "if_octets"
>     Table true
>     Instance "WG102::ssid.dot11bg"
>     Values "WG102::wlanInBytesTotal" "WG102::wlanOutBytesTotal"
> </Data>
> 
> This is translated into this SNMP packet:
> 
> 30 56
>     02 01 01
>     04 07 70 72 69 76 61 74 65
>     a1 48
>         02 04 6c 1b a8 8a
>         02 01 00
>         02 01 00
>         30 3a
>             30 11
>                 06 0d 2b 06 01 04 01 a3 2e 04 03 04 02 01 0a
>                 05 00
>             30 11
>                 06 0d 2b 06 01 04 01 a3 2e 04 03 04 02 01 0b
>                 05 00
>             30 11
>                 06 0e 2b 06 01 04 01 a3 2e 04 03 02 02 01 04 01
>                 05 00
> 
> (indentation added to show BER encoding)
> 
> The third sequence in the SNMP variable-bindings block has an OID field
> that is 14 bytes long (as opposed to the others which use 13 bytes),
> however the length field of the surrounding structure claims that the oid
> field (with header) followed by the NULL value (since this is a GETNEXT) is
> 17 bytes long (as the other variable bindings).
> 
> Thus, parsing the last variable binding terminates after the NULL tag field
> but before the NULL tag's length field (i.e. between the 5 and the 0 at the
> end).
> 
> Doing an snmpgetnext for these values yields a correct packet:
> 
> 30 56
>     02 01 01
>     04 07 70 72 69 76 61 74 65
>     a1 48
>         02 04 57 87 4b 10
>         02 01 00
>         02 01 00
>         30 3a
>             30 11
>                 06 0d 2b 06 01 04 01 a3 2e 04 03 04 02 01 0a
>                 05 00
>             30 11
>                 06 0d 2b 06 01 04 01 a3 2e 04 03 04 02 01 0b
>                 05 00
>             30 12
>                 06 0e 2b 06 01 04 01 a3 2e 04 03 02 02 01 04 01
>                 05 00
> 
> The difference in line 5 can be ignored (this is the request serial
> number).

Thanks for reporting this and providing detailed information!

Unfortunately, I'm not into the 'snmp' plugin at all and I do not have
the time to have a closer look at that. With this message, I'm
forwarding the bug report to the upstream mailing list, hoping for
feedback and patches ;-)

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety.         -- Benjamin Franklin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20090809/b132aa74/attachment.pgp