Re: snmp protocol error
Thanks for the detailed review Martijn, I'll follow up with the vendors and see if they can address the issue with a firmware update. On Sat, Dec 10, 2022, at 01:42, Martijn van Duren wrote: > On Fri, 2022-12-09 at 13:35 -0700, Byron Klippert wrote: >> On Fri, Dec 9, 2022, at 12:57, Stuart Henderson wrote: >> > On 2022-12-09, Byron Klippert wrote: >> > > Hello, >> > > >> > > I get an snmp protocol error response when attempting to `snmp get` >> > > certain OIDs on various devices. However `tcpdump` shows that the device >> > > is actually responding with the anticipated result but it appears snmp >> > > isn't able to parse the response correctly? Any suggestions on how to >> > > troubleshoot further are welcome. >> > > >> > > >> > > I'm requesting the mntrFreq OID which is formatted as such: >> > > Name: mntrFreq >> > > OID: .1.3.6.1.4.1.35833.12.3.1 >> > > MIB: DB7000-MIB >> > > Syntax: INTEGER32 (87100..108100) >> > > Access: read-only >> > > Status: current >> > > DefVal: >> > > Indexes: >> > > Descr: "mntr Freq" >> > >> > btw, the information in the mib file doesn't necessarily correspond >> > to what the device actually sends, "snmp get" doesn't care about the >> > mib file at all, just whether the pdu is correctly formatted. >> >> Yup, understood. I've seen a few half-baked snmp implementations in the wild >> to know the MIB docs are often only suggestions as to how devices actually >> respond. >> >> > >> > > imac:/home/admin $ snmp get -v 2c -r 0 -c *redacted* >> > > udp:paint-receiver:161 .1.3.6.1.4.1.35833.12.3.1.0 >> > > snmp: get: Protocol error >> > > >> > > imac:/home/admin $ doas tcpdump host paint-receiver >> > > tcpdump: listening on bge0, link-type EN10MB >> > > 10:10:02.804614 192.168.0.4.21246 > paint-receiver.snmp: C=*redacted* >> > > GetRequest(32) E:35833.12.3.1.0 >> > > 10:10:03.231863 paint-receiver.snmp > 192.168.0.4.21246: C=*redacted* >> > > GetResponse(40) E:35833.12.3.1.0=103500 >> > >> > It might be useful to use -X to do a hexdump (and maybe -s1500 to make >> > sure you get full packets); if you need to redact the snmp community >> > (although it probably doesn't really matter all that much seeing as >> > it's on a private lan address) make sure you get the hex digits too >> > >> > That way we can get a better idea of what's actually sent on the wire >> > >> > >> > -- >> > Please keep replies on the mailing list. >> >> imac:/home/admin $ snmp get -v 2c -r 0 -c *redacted* udp:paint-receiver:161 >> .1.3.6.1.4.1.35833.12.3.1.0 >> snmp: get: Protocol error >> >> imac:/home/admin $ clear; doas tcpdump -X -s1500 host paint-receiver >> tcpdump: listening on bge0, link-type EN10MB >> 13:23:16.478673 192.168.0.4.11162 > paint-receiver.snmp: C=*redacted* >> GetRequest(32) E:35833.12.3.1.0 >> : 4500 004d ce0a 4011 c0a8 0004 E..M@... >> 0010: c0a8 050c 2b9a 00a1 0039 aac2 302f 0201 +9..0/.. >> 0020: 0104 082a 2a2a 2a2a 2a2a 2aa0 2002 0428 .... ..( >> 0030: f7c4 fb02 0100 0201 0030 1230 1006 0c2b .0.0...+ >> 0040: 0601 0401 8297 790c 0301 0005 00 ..y.. >> >> 13:23:17.366836 paint-receiver.snmp > 192.168.0.4.11162: C=*redacted* >> GetResponse(40) E:35833.12.3.1.0=103500 >> : 4500 0059 f938 fd11 3dfa c0a8 050c E..Y.8=. >> 0010: c0a8 0004 00a1 2b9a 0045 c089 3082 0039 ..+..E..0..9 >> 0020: 0201 0104 082a 2a2a 2a2a 2a2a 2aa2 8200 .... >> 0030: 2802 0428 f7c4 fb02 0100 0201 0030 8200 (..(.0.. >> 0040: 1830 8200 1406 0c2b 0601 0401 8297 790c .0.+..y. >> 0050: 0301 0002 0400 0194 4c L > > The problem is here in the final 4 bytes: 0x0001944c, which is the int > value of the response (0x0204 is the integer preamble). > According to X.690 section 8.3.2: > If the contents octets of an integer value encoding consist of more than > one octet, then the bits of the first octet and bit 8 of the second > octet: > a) shall not all be ones; and > b) shall not all be zero. > NOTE - These rules ensure that an integer value is always encoded in the > smallest possible number of octets > > In this case the 1st byte is all zeroes, violating the rule. A check for > this was introduced to ber.c by rob@ to enforce this: > revision 1.5 > date: 2019/05/12 20:13:08; author: rob; state: Exp; lines: +9 -2; > commitid: 7FpdY7sgslPEOJU0; > Enforce smallest number of contents octets for int (and enum). > > ok claudio@ > > Although the additional byte(s) don't really hurt I'm not sure if > reverting this diff for a single misbehaving device is worth it. > Unless anyone thinks differently I think it'd be better to first > go to the vendor of your device and ask them to fix this. > > martijn@ >> >> >> And here's the OID that responds correctly... >> >> imac:/home/admin $ snmp get -v 2c -r 0 -c *redacted* udp:paint-receiver:161 >> .1.3.6.1.4.1.35833.12.2.10.1.0 >> enterprises.35833.12.2.10.1.0 = STRING: DB7000: Paint
Re: snmp protocol error
On Fri, 2022-12-09 at 13:35 -0700, Byron Klippert wrote: > On Fri, Dec 9, 2022, at 12:57, Stuart Henderson wrote: > > On 2022-12-09, Byron Klippert wrote: > > > Hello, > > > > > > I get an snmp protocol error response when attempting to `snmp get` > > > certain OIDs on various devices. However `tcpdump` shows that the device > > > is actually responding with the anticipated result but it appears snmp > > > isn't able to parse the response correctly? Any suggestions on how to > > > troubleshoot further are welcome. > > > > > > > > > I'm requesting the mntrFreq OID which is formatted as such: > > > Name: mntrFreq > > > OID: .1.3.6.1.4.1.35833.12.3.1 > > > MIB: DB7000-MIB > > > Syntax: INTEGER32 (87100..108100) > > > Access: read-only > > > Status: current > > > DefVal: > > > Indexes: > > > Descr: "mntr Freq" > > > > btw, the information in the mib file doesn't necessarily correspond > > to what the device actually sends, "snmp get" doesn't care about the > > mib file at all, just whether the pdu is correctly formatted. > > Yup, understood. I've seen a few half-baked snmp implementations in the wild > to know the MIB docs are often only suggestions as to how devices actually > respond. > > > > > > imac:/home/admin $ snmp get -v 2c -r 0 -c *redacted* > > > udp:paint-receiver:161 .1.3.6.1.4.1.35833.12.3.1.0 > > > snmp: get: Protocol error > > > > > > imac:/home/admin $ doas tcpdump host paint-receiver > > > tcpdump: listening on bge0, link-type EN10MB > > > 10:10:02.804614 192.168.0.4.21246 > paint-receiver.snmp: C=*redacted* > > > GetRequest(32) E:35833.12.3.1.0 > > > 10:10:03.231863 paint-receiver.snmp > 192.168.0.4.21246: C=*redacted* > > > GetResponse(40) E:35833.12.3.1.0=103500 > > > > It might be useful to use -X to do a hexdump (and maybe -s1500 to make > > sure you get full packets); if you need to redact the snmp community > > (although it probably doesn't really matter all that much seeing as > > it's on a private lan address) make sure you get the hex digits too > > > > That way we can get a better idea of what's actually sent on the wire > > > > > > -- > > Please keep replies on the mailing list. > > imac:/home/admin $ snmp get -v 2c -r 0 -c *redacted* udp:paint-receiver:161 > .1.3.6.1.4.1.35833.12.3.1.0 > snmp: get: Protocol error > > imac:/home/admin $ clear; doas tcpdump -X -s1500 host paint-receiver > tcpdump: listening on bge0, link-type EN10MB > 13:23:16.478673 192.168.0.4.11162 > paint-receiver.snmp: C=*redacted* > GetRequest(32) E:35833.12.3.1.0 > : 4500 004d ce0a 4011 c0a8 0004 E..M@... > 0010: c0a8 050c 2b9a 00a1 0039 aac2 302f 0201 +9..0/.. > 0020: 0104 082a 2a2a 2a2a 2a2a 2aa0 2002 0428 .... ..( > 0030: f7c4 fb02 0100 0201 0030 1230 1006 0c2b .0.0...+ > 0040: 0601 0401 8297 790c 0301 0005 00 ..y.. > > 13:23:17.366836 paint-receiver.snmp > 192.168.0.4.11162: C=*redacted* > GetResponse(40) E:35833.12.3.1.0=103500 > : 4500 0059 f938 fd11 3dfa c0a8 050c E..Y.8=. > 0010: c0a8 0004 00a1 2b9a 0045 c089 3082 0039 ..+..E..0..9 > 0020: 0201 0104 082a 2a2a 2a2a 2a2a 2aa2 8200 .... > 0030: 2802 0428 f7c4 fb02 0100 0201 0030 8200 (..(.0.. > 0040: 1830 8200 1406 0c2b 0601 0401 8297 790c .0.+..y. > 0050: 0301 0002 0400 0194 4c L The problem is here in the final 4 bytes: 0x0001944c, which is the int value of the response (0x0204 is the integer preamble). According to X.690 section 8.3.2: If the contents octets of an integer value encoding consist of more than one octet, then the bits of the first octet and bit 8 of the second octet: a) shall not all be ones; and b) shall not all be zero. NOTE - These rules ensure that an integer value is always encoded in the smallest possible number of octets In this case the 1st byte is all zeroes, violating the rule. A check for this was introduced to ber.c by rob@ to enforce this: revision 1.5 date: 2019/05/12 20:13:08; author: rob; state: Exp; lines: +9 -2; commitid: 7FpdY7sgslPEOJU0; Enforce smallest number of contents octets for int (and enum). ok claudio@ Although the additional byte(s) don't really hurt I'm not sure if reverting this diff for a single misbehaving device is worth it. Unless anyone thinks differently I think it'd be better to first go to the vendor of your device and ask them to fix this. martijn@ > > > And here's the OID that responds correctly... > > imac:/home/admin $ snmp get -v 2c -r 0 -c *redacted* udp:paint-receiver:161 > .1.3.6.1.4.1.35833.12.2.10.1.0 > enterprises.35833.12.2.10.1.0 = STRING: DB7000: Paint Mt > > imac:/home/admin $ clear; doas tcpdump -X -s1500 host paint-receiver > tcpdump: listening on bge0, link-type EN10MB > 13:32:08.168829 192.168.0.4.44771 > paint-receiver.snmp: C=*redacted* > GetRequest(33) E:35833.12.2.10.1.0 > : 4500 004e 36ee 4011 c0a8 0004 E..N6...@... > 0010: c0a8 050c aee3
Re: snmp protocol error
On Fri, Dec 9, 2022, at 12:57, Stuart Henderson wrote: > On 2022-12-09, Byron Klippert wrote: >> Hello, >> >> I get an snmp protocol error response when attempting to `snmp get` certain >> OIDs on various devices. However `tcpdump` shows that the device is actually >> responding with the anticipated result but it appears snmp isn't able to >> parse the response correctly? Any suggestions on how to troubleshoot further >> are welcome. >> >> >> I'm requesting the mntrFreq OID which is formatted as such: >> Name: mntrFreq >> OID: .1.3.6.1.4.1.35833.12.3.1 >> MIB: DB7000-MIB >> Syntax: INTEGER32 (87100..108100) >> Access: read-only >> Status: current >> DefVal: >> Indexes: >> Descr: "mntr Freq" > > btw, the information in the mib file doesn't necessarily correspond > to what the device actually sends, "snmp get" doesn't care about the > mib file at all, just whether the pdu is correctly formatted. Yup, understood. I've seen a few half-baked snmp implementations in the wild to know the MIB docs are often only suggestions as to how devices actually respond. > >> imac:/home/admin $ snmp get -v 2c -r 0 -c *redacted* udp:paint-receiver:161 >> .1.3.6.1.4.1.35833.12.3.1.0 >> snmp: get: Protocol error >> >> imac:/home/admin $ doas tcpdump host paint-receiver >> tcpdump: listening on bge0, link-type EN10MB >> 10:10:02.804614 192.168.0.4.21246 > paint-receiver.snmp: C=*redacted* >> GetRequest(32) E:35833.12.3.1.0 >> 10:10:03.231863 paint-receiver.snmp > 192.168.0.4.21246: C=*redacted* >> GetResponse(40) E:35833.12.3.1.0=103500 > > It might be useful to use -X to do a hexdump (and maybe -s1500 to make > sure you get full packets); if you need to redact the snmp community > (although it probably doesn't really matter all that much seeing as > it's on a private lan address) make sure you get the hex digits too > > That way we can get a better idea of what's actually sent on the wire > > > -- > Please keep replies on the mailing list. imac:/home/admin $ snmp get -v 2c -r 0 -c *redacted* udp:paint-receiver:161 .1.3.6.1.4.1.35833.12.3.1.0 snmp: get: Protocol error imac:/home/admin $ clear; doas tcpdump -X -s1500 host paint-receiver tcpdump: listening on bge0, link-type EN10MB 13:23:16.478673 192.168.0.4.11162 > paint-receiver.snmp: C=*redacted* GetRequest(32) E:35833.12.3.1.0 : 4500 004d ce0a 4011 c0a8 0004 E..M@... 0010: c0a8 050c 2b9a 00a1 0039 aac2 302f 0201 +9..0/.. 0020: 0104 082a 2a2a 2a2a 2a2a 2aa0 2002 0428 .... ..( 0030: f7c4 fb02 0100 0201 0030 1230 1006 0c2b .0.0...+ 0040: 0601 0401 8297 790c 0301 0005 00 ..y.. 13:23:17.366836 paint-receiver.snmp > 192.168.0.4.11162: C=*redacted* GetResponse(40) E:35833.12.3.1.0=103500 : 4500 0059 f938 fd11 3dfa c0a8 050c E..Y.8=. 0010: c0a8 0004 00a1 2b9a 0045 c089 3082 0039 ..+..E..0..9 0020: 0201 0104 082a 2a2a 2a2a 2a2a 2aa2 8200 .... 0030: 2802 0428 f7c4 fb02 0100 0201 0030 8200 (..(.0.. 0040: 1830 8200 1406 0c2b 0601 0401 8297 790c .0.+..y. 0050: 0301 0002 0400 0194 4c L And here's the OID that responds correctly... imac:/home/admin $ snmp get -v 2c -r 0 -c *redacted* udp:paint-receiver:161 .1.3.6.1.4.1.35833.12.2.10.1.0 enterprises.35833.12.2.10.1.0 = STRING: DB7000: Paint Mt imac:/home/admin $ clear; doas tcpdump -X -s1500 host paint-receiver tcpdump: listening on bge0, link-type EN10MB 13:32:08.168829 192.168.0.4.44771 > paint-receiver.snmp: C=*redacted* GetRequest(33) E:35833.12.2.10.1.0 : 4500 004e 36ee 4011 c0a8 0004 E..N6...@... 0010: c0a8 050c aee3 00a1 003a caeb 3030 0201 .:..00.. 0020: 0104 082a 2a2a 2a2a 2a2a 2aa0 2102 0459 ....!..Y 0030: f71a 4f02 0100 0201 0030 1330 1106 0d2b ..O..0.0...+ 0040: 0601 0401 8297 790c 020a 0100 0500 ..y... 13:32:08.988687 paint-receiver.snmp > 192.168.0.4.44771: C=*redacted* GetResponse(53) E:35833.12.2.10.1.0="DB7000: Paint Mt" : 4500 0066 f967 fd11 3dbe c0a8 050c E..f.g=. 0010: c0a8 0004 00a1 aee3 0052 ade8 3082 0046 .R..0..F 0020: 0201 0104 082a 2a2a 2a2a 2a2a 2aa2 8200 .... 0030: 3502 0459 f71a 4f02 0100 0201 0030 8200 5..Y..O..0.. 0040: 2530 8200 2106 0d2b 0601 0401 8297 790c %0..!..+..y. 0050: 020a 0100 0410 4442 3730 3030 3a20 5061 ..DB7000: Pa 0060: 696e 7420 4d74 int Mt -- Byron Klippert byronklipp...@ml1.net c. 867-334-5179
Re: snmp protocol error
On 2022-12-09, Byron Klippert wrote: > Hello, > > I get an snmp protocol error response when attempting to `snmp get` certain > OIDs on various devices. However `tcpdump` shows that the device is actually > responding with the anticipated result but it appears snmp isn't able to > parse the response correctly? Any suggestions on how to troubleshoot further > are welcome. > > > I'm requesting the mntrFreq OID which is formatted as such: > Name: mntrFreq > OID: .1.3.6.1.4.1.35833.12.3.1 > MIB: DB7000-MIB > Syntax: INTEGER32 (87100..108100) > Access: read-only > Status: current > DefVal: > Indexes: > Descr: "mntr Freq" btw, the information in the mib file doesn't necessarily correspond to what the device actually sends, "snmp get" doesn't care about the mib file at all, just whether the pdu is correctly formatted. > imac:/home/admin $ snmp get -v 2c -r 0 -c *redacted* udp:paint-receiver:161 > .1.3.6.1.4.1.35833.12.3.1.0 > snmp: get: Protocol error > > imac:/home/admin $ doas tcpdump host paint-receiver > tcpdump: listening on bge0, link-type EN10MB > 10:10:02.804614 192.168.0.4.21246 > paint-receiver.snmp: C=*redacted* > GetRequest(32) E:35833.12.3.1.0 > 10:10:03.231863 paint-receiver.snmp > 192.168.0.4.21246: C=*redacted* > GetResponse(40) E:35833.12.3.1.0=103500 It might be useful to use -X to do a hexdump (and maybe -s1500 to make sure you get full packets); if you need to redact the snmp community (although it probably doesn't really matter all that much seeing as it's on a private lan address) make sure you get the hex digits too That way we can get a better idea of what's actually sent on the wire -- Please keep replies on the mailing list.
