Your message dated Sun, 9 Aug 2009 15:04:16 +0200
with message-id <[email protected]>
has caused the report #540394,
regarding collectd: generates broken SNMP queries
to be marked as having been forwarded to the upstream software
author(s) [email protected]
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
540394: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=540394
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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
signature.asc
Description: Digital signature
--- End Message ---
