#2649 Counter32 Bug

[Kostantin Konstantin]

Good afternoon!
When testing the SNMP agent noticed the following:
I make an inquiry
"snmpget -v 2c -c readcomunity 127.0.0.1 1.3.6.1.4.1.20000.1.4.0"
getting
"SNMPv2-SMI :: enterprises.20000.1.4.0 = Counter32: 4294967295"

Thus the agent in response to the request, outputs the packet
"0x30:0x34:0x02:0x01:0x01:0x04:0x0C:0x72:0x65:0x61:0x64:0x63:0x6F:0x6D:0x75:0x6E:0x69:0x74:0x79:0xA2:0x21:0x02:0x04:0x3E:0x26:0x55:0xF2:0x02:0x01:0x00:0x02:0x01:0x00:0x30:0x13:0x30:0x11:0x06:0x0B:0x2B:0x06:0x01:0x04:0x01:0x81:0x9C:0x20:0x01:0x04:0x00:0x41:0x02:0xFF:0xFF:"

Ie in the package comes to 65535 (FFFF).

The error most likely occurs because of the type conversion when parsing came the answer.

Name: net-snmp
Arch: x86_64
Version: 5.7.2
Build: 23.fc21

Sorry for my english. I use a translator.

[Wes Hardaker]

That looks like a bug in the agent you are querying. Our snmpget command is just reporting the value it received from the agent. And if that agent is based on Net-SNMP, there is still nothing we can do about it since the OID you are querying is not one that we implement and thus the code must come from somewhere else.

[Kostantin Konstantin]

This is a problem manager
In the description I give the contents of the package obtained using Wireshark.
The last 3 bytes: 0x02: 0xFF: 0xFF - value.
If you pass 0x02: 0x1F: 0xFF - then everything will be displayed correctly

[Bill Fenner]

There are two problems with 0x02:0xff:0xff:

1) It is invalid BER. X.690 section 8.3.2 says:

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.

The bits of your first octet and bit 8 of the second octet are all ones, violating subsection (a). The reason behind this is that in BER, all integers are signed. 0x02:0xff:0xff is encoding -1. 0x01:0xff is a shorter encoding for -1, so 8.3.2 is about ensuring that values are encoded in the fewest bytes possible.

2) It is outside the range defined for Counter32. RFC2578 says:

Counter32 ::=
    [APPLICATION 1]
        IMPLICIT INTEGER (0..4294967295)

i.e., it takes the underlying ASN.1 INTEGER and restricts it to the range (0..4294967295). This means that your -1 is not a valid value for a Counter32.

Strictly speaking, your complaint is with how net-snmp is handling an invalid response from the agent. The agent is returning an incorrectly-encoded, out-of-range value, and net-snmp is displaying it with an incorrect type conversion. Garbage in --> garbage out. If your agent performs proper BER encoding (e.g., 0x03:0x00:0xff:0xff), then net-snmp will display your value properly.

[Kostantin Konstantin]

Maybe first check and then raise the status Invalid?

Wireshark parses and displays passed my agent packer is completely correct.

OID to query one 1.3.6.1.4.1.20000.1.4.0

[Niels Baggesen]

The encoding of 65535 is wrong. It must be encoded as 0x03, 0x00, 0xFF, 0xFF.

When the top bit of the integer is set, it is a negative 2's complement value, so 0x02, 0xFF, 0xFF is actually -1 (and could have been encoded as 0x01, 0xFF). This is unpacked as a 32-bit -1 aka 0xFFFFFFFF which is then treated as an unsigned value so it ends up as 4294967295.

[Kostantin Konstantin]

I realized my mistake when coding. It turns out that in order to encode the number 4294967295 will need 5 bytes (0x05 0x00 0xFF 0xFF 0xFF 0xFF).
But I am using the same algorithm in the coding of Counter64 and snmpget fulfills correctly. And it is strange when you consider your remark.

I will carefully read the BER

[Robert Story]

This looks like a net-snmp agent with a custom MIB implementation. So if the encoding is wrong, my question is how is the mib module setting the value, and why does it end up incorrectly encoded? Can you provide the source for the mib module?