SNMP packet analysis

Today, I checked the SNMP packet format and captured two packets with Wireshark for analysis.

Let's talk about the SNMP get-request packet format. The get-next-request, get-response, and set-request formats are similar, but the PDU types are different. The trap format is not the same.

Well, let's talk about the get-Request Message format first (refer to "TCP/IP" to learn more ).

Version + group name + PDU type + Request ID + error status + error index + name + value ....

Trap also said

Version + group name + PDU type + enterprise + proxy address + trap type + specific code + timestamp + name + value...

Okay: Let's talk about my environment.

Host Windows XP Virtual Machine VMware Ubuntu, packet capture tool Wireshark, use netsnmp, host ip210.38.235.184, virtual machine ip210.38.235.186

Here, the VM sends a command snmpget-V 1-C public 210.38.235.184 sysdescr.0 (OID is 1.3.6.1.2.1.1.1.0) to the host)

Let's take a look at the packets in SNMP V1.

C8 1f 66 05 FB A6 00 0C 29 90 F7 6D 08 00 45 00 00 47 21 BA 40 00 40 40 11 9d 2B D2 26 EB Ba D2 26 EB B8 96 F9 00 A1 00 33 8A 2D 30 29 02 01 00 04 06 70 75 62 6C 69 63 A0 1C 02 04 26 ca 2f CB 02 01 01 01 00 30 0e 30 0C 06 08 2B 06 01 02 01 01 01 00 05 00

C8 1f 66 05 FB A6 // destination NIC address

00 0C 29 90 F7 6D // source NIC address

08 00 // protocol type, here is the IP protocol

45 00 00 47 21 BA 40 00 40 11 9d 2B D2 26 EB Ba D2 26 EB B8 // IP header 20 bytes

96 F9 00 A1 00 33 8A 2D // udp8 bytes

30 29 // 30 indicates that the SNMP message uses ASN.1 sequence 29 to indicate that the message length (the number of bytes after 29) is 41 bytes.

02 01 00 // here the basic encode rule is used for encoding (the first byte indicates the data type, the second byte indicates the Data Length, followed by the data) 02 indicates the integer type, 01 indicates that the length is 1, 00 indicates that the version is V1.
04 06 70 75 62 6C 69 63 // here is the group name public Ashima, which also uses the BER code

A0 1C // PDU Type A0 indicates get-request 1C indicates PDU Data Length 28 bytes

02 04 26 ca 2f CB // an integer set by the request-ID management process

02 01 00 // error status. 00 indicates no error

02 01 00 // error Status Index, 00

30 0e // indicates that the value name adopts ASN.1 and the data length is 14 bytes.

30 0C // indicates that the first value uses ASN.1 and the data length is 12 bytes.

06 08 2B 06 01 02 01 01 01 00 // here the BER is used, but the encoding method of SNMP and OID is a bit strange. I will explain it later.

05 00 // SNMP null, so the data length is 0

The data packet of SNMP V1 has been analyzed on okay.

Next let's take a look at the SNMP v2 Packet

C8 1f 66 05 FB A6 00 0C 29 90 F7 6D 08 00 45 00 00 47 21 B9 40 00 40 11 9d 2C D2 26 EB Ba D2 26 EB B8 A8 8d 00 A1 00 33 d1 E6 30 29 02 01 01 04 06 70 75 62 6C 69 63 A0 1C 02 04 51 5A B7 E0 02 01 00 02 01 00 30 0e 30 0C 06 08 2B 06 01 02 01 01 01 00 05 00

C8 1f 66 05 FB A6 // destination NIC address
00 0C 29 90 F7 6D // source NIC address this should be the header of the data link layer Encapsulation
08 00 // protocol type, here is the IP protocol

45 00 00 47 21 B9 40 00 40 11 9d 2C D2 26 EB Ba D2 26
EB B8 // IP Header
A8 8d 00 A1 00 33 D1 E6 // UDP Header
// The following is an SNMP packet
30 // indicates that the SNMP message is of the ASN.1 sequence type.
29 // 29 indicates that this field is followed by 41 bytes.
02 01 01 // The Last 01 indicates that the SNMP version is 2C. Here, the BER encoding method 02 indicates that the field is of the integer type, and the second 01 indicates that the data length is 1.
04 06 70 75 62 6C 69 63 // here is the group name public, 04 indicates the data type is octet string type, 06 indicates the data length is 6 bytes, the next six values are public's. Why is this BER encoding method not used here, that is, Data Type + Data Length + data class capacity?
A0 1C // A0 indicates that the packet type is get-request, and 1C indicates that there are 28 bytes of data after it. Why is the BER encoding not used here? In addition to the Type field, all other fields use the BER encoding method.
02 04 51 5A B7 E0 // Request ID this is an integer set by the management process and an integer set by the management process. The proxy process also returns the request identifier when sending a get-Response Message. The management process can send get packets to many Proxies at the same time. All these packets are sent over UDP, which may be sent before arriving. A request identifier is set to enable the management process to identify which request message is returned for the response message.

02 01 00 // error status 00 indicates noerror
02 01 00 // error Status Index 00
// The following is the name value
30 0e // 30 ASN.1 sequence type 0e length is 14
30 0C // The first name-Value Pair encoding method ASN.1 sequence length is 12
06 08 2B 06 01 02 01 01 01 00 // oid is 1.3.6.1.2.1.1.1.0 the encoding method of SNMP oid is somewhat strange: for example, 1.3.6.1.2 .... Take the first two numbers as X and Y respectively. Encoding: 40 * X + Y. Here, x = 1, y = 3. Therefore, the result is 40*1 + 3 = 43, which indicates 2B of the hexadecimal system.
05 00 // The value of the null type variable-value1 of ASN.1 is null

Here, we will explain that the encoding method of SNMP oid is somewhat odd: 1.3.6.1.2 .... Take the first two numbers as X and Y respectively. Encoding: 40 * X + Y. Here, x = 1, y = 3. Therefore, the result is 40*1 + 3 = 43, which indicates 2B of the hexadecimal system.

I will analyze the SNMP Trap packets. For more information, see http://blog.chinaunix.net/uid-23069658-id-32520.5.html.

In SNMP Packets, only the PDU type does not use the BER encoding. Others use the BER encoding.

Okay is here first

Reference: http://blog.chinaunix.net/uid-23069658-id-3251045.html

SNMP packet analysis