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 <byronklipp...@ml1.net> 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 >> 0000: 4500 004d ce0a 0000 4011 0000 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 >> 0000: 4500 0059 f938 0000 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 >> 0000: 4500 004e 36ee 0000 4011 0000 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" >> 0000: 4500 0066 f967 0000 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
