Search code examples
snmp

Why does MIB encoding of IPAddress not match what I decode in WireShark?

RFC1155, 3.2.3.2 defines an IpAddress as:

This application-wide type represents a 32-bit internet address. It
is represented as an OCTET STRING of length 4, in network byte-order.

And again, in section 6

IpAddress ::=
     [APPLICATION 0] -- in network-byte order
        IMPLICIT OCTET STRING (SIZE (4))

Also RFC 1156, 5.4.1 defines an ipAddrEntry as a SEQUENCE containing an ipAdEntAddr as an IpAddress.

Okay then, backpedaling through this "(NOT)Simple Network Message Protocol", it should be clear that an IPAddress is 4 byte, network byte order (Big Endian)

RFC1156, 5.4.1 defines an ipAddrEntry to be a SEQUENCE containing among other things, ipAdEntAddr as an IpAddress... Which was defined in the last RFC.

Why then, in Wireshark, when I examine the OID request, the IP address 192.168.1.21 is encoded as

81  40  81  28  01  15

enter image description here

Which isn't 4 octets. It's not even TLV encoding. It's some other 7 bit encoding where the 8th bit is used to indicate "Not the last octet" (I think it's VLQ? )

1000 0001 0100 0000  =>  1100 0000
1000 0001 0010 1000  =>  1010 1000

If it is supposed to be VLQ, where is that documented?

Why is what I read on Wireshark not what I read in the RFCs?

Solution

  • SNMP protocol and Wireshark are both correct, but you misunderstand the basic concept of SNMP table and OIDs.

    While from the text, you might see 192.168.1.21 anywhere in Wireshark's decoded tree view, you must be aware of its actual entity so as to understand how it was encoded.

    In the screen shot you can see that 192.168.1.21 highlighted was part of an OID 1.3.6.1.2.1.4.20.1.2.192.168.1.21. This is a typical OID pattern used in tables, where the index 192.168.1.21 is combined with the table column OID 1.3.6.1.2.1.4.20.1.2 to represent the actual cell.

    Thus, its bytes are encoded following BER like any other OIDs, not IpAddress,

    How does ASN.1 encode an object identifier?

    That's why the bytes look different from your initial thought.