一、实验内容：
1） 使用snmputilg发送SNMP数据包; 使用wireshark抓包；使用netstat –an查看代理站TCP/UDP连接表，分析并验证SNMP协议的工作过程；
2） 自行挑选MIB-2功能组中IP、ICMP、TCP、UDP等的管理对象(要有列对象)，抓包分析其SNMP协议工作过程。
3） 查找标量对象标识符.1.3.6.1.2.1.11.13是什么对象，其实例标识符是什么？若连续多次GET这个实例标识符，得到的值有什么变化？请抓包分析其PDU格式。请截图说明。
二、实验过程
1） 使用snmputilg发送SNMP数据包; 使用wireshark抓包；使用netstat –an查看代理站TCP/UDP连接表，分析并验证SNMP协议的工作过程；
发送SNMP请求，OID为.1.3.6.1.2.1.1.1.0，目标地址为同学的电脑的IP ， community为017018
打开wireshark，选择当前正在使用的网卡WLAN网卡捕获。
在wireshark的应用显示过滤器中选择SNMP协议，查看捕获到的SNMP的数据包。
请求包：
响应包：
使用netstat -an来查看代理站的TCP/UDP链接表，然后找到SNMP的连接
SNMP基于UDP协议工作，端口号为161
因为UDP是面向无连接的协议，因此不会有链接的状态，也就没有目标IP与源IP
只有在本机持续监听端口的状态，当对方发送UDP包时，就可以在对应的端口监听到这个数据包
\对request和response包进行分析：\
\Request\
从RFC1157文档查看version的ASN.1语法
-- top-level message
Message ::=
SEQUENCE {
version -- version-1 for this RFC
INTEGER {
version-1(0)
},
community -- community name
OCTET STRING,
data -- e.g., PDUs if trivial
ANY -- authentication is being used
}
-- protocol data units
PDUs ::=
CHOICE {
get-request
GetRequest-PDU,
get-next-request
GetNextRequest-PDU,
get-response
GetResponse-PDU,
set-request
SetRequest-PDU,
trap
Trap-PDU
}
-- the individual PDUs and commonly used
-- data types will be defined later
END
结合下图的SNMP的报文格式
可以看出，SNMP的第一个字段为版本号，类型为Integer，值为0。
根据BER进行编码：
T:
由前面可知，类型Integer的标签类型为UNIVERSAL，标签值为 00
且Integer为简单类型，因此第三位为0，且标签值为2，二进制编码为 00010
因此T部分为 00 0 00010B 对应十六进制数02H
L:
L表示的是V的长度，而值为,0，只需要一个长度就行，L为1，对应十六进制为 01
V:
V的值为0，对应十六进制为 00H
\综上，版本号0的BER编码为02 01 00\
第二个字段为community，类型为OCTET STRING，值为017018.
根据BER进行编码：
T:
类型OCTET STRING标签类型为UNIVERSAL，标签值为00
OCTET STRING同样为简单类型，所以第三位 0 ， 编号为4 二进制 00100
因此T部分为 00 0 00100B 对应十六进制数04H
L:
后面的V有六位ASCII编码的字符，所以V的长度为6 十六进制编码为 06H
V:
V为ASCII编码的字符，017018，查看对应的ASCII编码表如下：
可得0的十六进制编码为30H，1的十六进制编码为31H，依次对其进行编码，可以得到V的十六进制编码为 30 31 37 30 31 38
综上，community为017018的BER编码为 04 06 30 31 37 30 31 38
第三个字段为PDU中的get-request，类型为GetRequest-PDU。
从RFC1157文档查看GetRequest-PDU的ASN.1语法
The form of the GetRequest-PDU is:
GetRequest-PDU ::=
[0]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status -- always 0
ErrorStatus,
error-index -- always 0
ErrorIndex,
variable-bindings
VarBindList
}
定义中[0]表明GetRequest的标签为“上下文专用标签”，标签值为0；类型为SEQUENCE，是构造类型。
T:
上下文专用标签，标志值的二进制为10
SEQUENCE是构造类型，第三位二进制数编码为1
“[0]”表示标签值为0，因此后五位为00000
因此T部分为 10 1 00000 ， 对应十六进制A0H
L:
后面值长度为19
V:
因为是SEQUENCE类型，所以V有多个新类型的值组成集合
根据RFC1157文档中的ASN.1语法：
RequestID ::=
INTEGER
ErrorStatus ::=
INTEGER {
noError(0),
tooBig(1),
noSuchName(2),
badValue(3),
readOnly(4)
genErr(5)
}
ErrorIndex ::=
INTEGER
-- variable bindings
VarBind ::=
SEQUENCE {
name
ObjectName,
value
ObjectSyntax
}
VarBindList ::=
SEQUENCE OF
VarBind
第一个值为RequestID类型，也就是Integer，上面有分析过
T：
00(UNIVERSAL)+0(简单类型)+00010(INTEGER类型)，即0000 0010B，02H
L：
值长度为1字节，即01H
V:
值为1
综上request-id 的BER编码为 02 01 01
第二个值为ErrorStatus 类型，也是Integer，但是有具体的规范数组：
ErrorStatus ::=
INTEGER {
noError(0),
tooBig(1),
noSuchName(2),
badValue(3),
readOnly(4)
genErr(5)
}
T：
00(UNIVERSAL)+0(简单类型)+00010(INTEGER类型)，即0000 0010B，02H
L：
值长度为1字节，即01H
V:
值为0 （noError）
综上request-id 的BER编码为 02 01 00
第三个值为ErrorIndex ，也是Interger
T：
00(UNIVERSAL)+0(简单类型)+00010(INTEGER类型)，即0000 0010B，02H
L：
值长度为1字节，即01H
V:
值为0
综上errorindex 的BER编码为 02 01 00
\第四个值为\VarBindList\ ，是VarBindList 类型，也就是VarBind 类型的集合SEQUENCE OF
VarBindList ::=
SEQUENCE OF
VarBind
T:
SEQUENCE OF的标签类型为UNIVERSAL ， 值为00
构造类型，因此第三位二进制数为1
标签编号为8, 10000B
因此标签值为 00 1 10000B，30H
L:
长度为14 ,0EH
V:
里面套着个VarBind
VarBind ::=
SEQUENCE {
name
ObjectName,
value
ObjectSyntax
}
也是SEQUENCE类型
T:
00（UNIVERSAL）+1（构造类型）+10000（SEQUENCE类型），即00 1 10000B, 30H
L:
长度为12，OCH
V:
值为name，和value
Name的类型为ObjectName，查询RFC1157文档，发现这种类型在RFC1155中定义
IMPORTS
ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
FROM RFC1155-SMI;
ObjectName ::=
OBJECT IDENTIFIER
因此ObjectName 的类型为OBJECT IDENTIFIER
T:
00(UNIVERSAL) + 0(简单类型)+00110（OBJECT IDENTIFIER类型），即00 0 00110B，06H
L:
长度为8
V:
这里的值是我们请求的OID
这里的iso.3直接变成了2bH,其他字符按照十六进制直接翻译 .1变成01H,..6 变成 06H
因此ObjectName的BER编码为06 08 2B 06 01 02 01 01 01 00
06 08 2B 06 01 02 01 01 01 00
VALUE的类型为ObjectSyntax，以下是该类型在RFC1155文档中的定义
ObjectSyntax ::=
CHOICE {
simple
SimpleSyntax,
-- note that simple SEQUENCEs are not directly
-- mentioned here to keep things simple (i.e.,
-- prevent mis-use). However, application-wide
-- types which are IMPLICITly encoded simple
-- SEQUENCEs may appear in the following CHOICE
application-wide
ApplicationSyntax
}
SimpleSyntax ::=
CHOICE {
number
INTEGER,
string
OCTET STRING,
object
OBJECT IDENTIFIER,
empty
NULL
}
T:
因为值为空，所以SimpleSyntax 应该是CHOICE 中的empty
00(UNIVERSAL)+0(简单类型)+00101(NULLL类型)，即 00 0 00101B,05H
L:
长度为0
V:
没有值
综上，value的BER编码为05 00
综上，第一个\VarBind\ 块的BER编码为 30 0C 06 08 2B 06 01 02 01 01 01 00 05 00
综上，此\VarBindList\ 的BER编码为：30 0E 30 0C 06 08 2B 06 01 02 01 01 01 00 05 00
\Response:\
第一第二个字段 version：0 与community：017018前面已经分析过了，因此这里不再赘述。
直接看第三个PDU字段，此时的PDU的类型变成了get-response（2）
get-response
GetResponse-PDU,
在RFC1157中查看 GetResponse-PDU的ASN.1语法
GetResponse-PDU ::=
[[2](#ref-2)]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status
ErrorStatus,
error-index
ErrorIndex,
variable-bindings
VarBindList
}
可以看到内容与GetRequest-PDU一样，仅有的差别是定义中的[2]与前面GetRequest-PDU中的[0]有所区别。
[2] 表示“上下文专用标签”，标签值为2，类型也为SEQUENCE 。
T:
10（上下文专用标签）+1（构造类型）+00010（标签值为2）, 即为10 1 00010，A2H
L:
长度为81H
V:
第一个值为 request-id
RequestID ::=
INTEGER
T：
00(UNIVERSAL)+0(简单类型)+00010(INTEGER类型)，即0000 0010B，02H
L：
值长度为1字节，即01H
V:
值为1
综上request-id 的BER编码为 02 01 01
第二个值为error-status
ErrorStatus ::=
INTEGER {
noError(0),
tooBig(1),
noSuchName(2),
badValue(3),
readOnly(4)
genErr(5)
}
T：
00(UNIVERSAL)+0(简单类型)+00010(INTEGER类型)，即0000 0010B，02H
L：
值长度为1字节，即01H
V:
值为0 （noError）
综上request-id 的BER编码为 02 01 00
第三个值为ErrorIndex ，也是Interger
ErrorIndex ::=
INTEGER
T：
00(UNIVERSAL)+0(简单类型)+00010(INTEGER类型)，即0000 0010B，02H
L：
值长度为1字节，即01H
V:
值为0
综上errorindex 的BER编码为 02 01 00
第四个值为VarBindList
VarBindList ::=
SEQUENCE OF
VarBind
其中的元素VarBind：
VarBind ::=
SEQUENCE {
name
ObjectName,
value
ObjectSyntax
}
先分析外层的VarBindList
T:
SEQUENCE OF的标签类型为UNIVERSAL ， 值为00
构造类型，因此第三位二进制数为1
标签编号为8, 10000B
因此标签值为 00 1 10000B，30H
L:
81 90
这里的长度用到了长度扩展
二进制位为：1000 0001 表示扩展了一个字节的长度
然后第一个字节的长度位为 1001 0000 表示长度为144个字节
V:
V中有一个VarBind的实例，直接分析该实例的内容
T:
00（UNIVERSAL）+1（构造类型）+10000（SEQUENCE类型），即00 1 10000B, 30H
L:
81
1000 0001 表示拓展一个字节的长度
8d
1000 1101表示长度为141
V:
值为name，和value
Name的类型为ObjectName，查询RFC1157文档，发现这种类型在RFC1155中定义
IMPORTS
ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
FROM [RFC1155](https://www.rfc-editor.org/rfc/rfc1155)-SMI;
ObjectName ::=
OBJECT IDENTIFIER
因此ObjectName 的类型为OBJECT IDENTIFIER
T:
00(UNIVERSAL) + 0(简单类型)+00110（OBJECT IDENTIFIER类型），即00 0 00110B，06H
L:
长度为8
V:
这里的值是我们请求的OID
前两个1.3(iso.3)变为2B，其余字符按照数字转成成16进制数。
2b 06 01 02 01 01 01 00
综上ObjectName 的BER编码为06 08 2B 06 01 02 01 01 01 00
VALUE的类型为ObjectSyntax，以下是该类型在RFC1155文档中的定义
ObjectSyntax ::=
CHOICE {
simple
SimpleSyntax,
-- note that simple SEQUENCEs are not directly
-- mentioned here to keep things simple (i.e.,
-- prevent mis-use). However, application-wide
-- types which are IMPLICITly encoded simple
-- SEQUENCEs may appear in the following CHOICE
application-wide
ApplicationSyntax
}
SimpleSyntax ::=
CHOICE {
number
INTEGER,
string
OCTET STRING,
object
OBJECT IDENTIFIER,
empty
NULL
}
T:
这里的值都是经过ASCII编码的字符，推测SimpleSyntax 应该是CHOICE 中的OCTET STRING
00(UNIVERSAL)+0(简单类型)+00100(OCTET STRING类型)，即 00 0 00100B,04H
L:
长度为81 80 即经过扩展长度，拓展的字节数为1 ， 80H表示后继的长度为128
V:
H的ASCCI码为48H，而在wireshark的字符转换后也是H，说明后面的字符串都是ASCII码编码的，因此对每个字符进行ASCII转义即可获取到对应的十六进制值。
综上，value的BER编码为04 81 80 48 ......
综上，VarBind的BER编码为：30 81 8D 06 08......
综上，VarBindList的BER编码为 30 81 90 30 81 8D 06 08......
根据报文的内容，可以发现，SNMP的工作过程是，通过SNMP协议发送一个带着自定义community和oid的SNMP报文给代理站，然后代理站返回response给本电脑，也就是管理站。这是经典的C/S，即客户端/服务器模式。
2） 自行挑选MIB-2功能组中IP、ICMP、TCP、UDP等的管理对象(要有列对象)，抓包分析其SNMP协议工作过程。
IP Group
ipDefaultTTL 1.3.6.1.2.1.4.2 表示IP数据包的默认生存时间。
ipInReceives 1.3.6.1.2.1.4.3 表示接收到的IP数据包数目。
ipInHdrErrors 1.3.6.1.2.1.4.4 表示接收到的IP数据包头部错误数目。
ipInAddrErrors 1.3.6.1.2.1.4.5 表示接收到的IP数据包地址错误数目。
ipForwDatagrams 1.3.6.1.2.1.4.6 表示转发的IP数据包数目。
ipInUnknownProtos 1.3.6.1.2.1.4.7 接收到的IP数据报中，协议字段不是TCP、UDP或ICMP的数据报数。
ipInDiscards 1.3.6.1.2.1.4.8 接收到的IP数据报因某种原因被丢弃的数据报数。
ipInDelivers 1.3.6.1.2.1.4.9 接收到的IP数据报被送到上层协议的数据报数。
ipOutRequests 1.3.6.1.2.1.4.10 本地产生并传送出去的IP数据报数。
ipOutDiscards 1.3.6.1.2.1.4.11 本地产生但因某种原因被丢弃的IP数据报数。
ipOutNoRoutes 1.3.6.1.2.1.4.12 本地产生但没有匹配路由表项而被丢弃的IP数据报数。
ipReasmTimeout 1.3.6.1.2.1.4.13 IP分片重组超时计数器，超时则丢弃该分片。
ipReasmReqds 1.3.6.1.2.1.4.14 需要重组的IP分片数。
ipReasmOKs 1.3.6.1.2.1.4.15 成功重组的IP分片数。
ipReasmFails 1.3.6.1.2.1.4.16 重组失败的IP分片数。
ipFragsOKs 1.3.6.1.2.1.4.17 成功分片的IP数据报数。
IpAddrTable 1.3.6.1.2.1.4.20 与此实体的 IP 地址相关的寻址信息表。
选择列对象IpAddrTable 进行分析
OID为1.3.6.1.2.1.4.20
其子节点为：1.3.6.1.2.1.4.20.1ipAddrEntry 寻址此实体的某个 IP 地址的信息
其子节点为：
获取一个next
Wireshark中抓包：
可以看到，请求的oid确实是1.3.6.1.2.1.4.20，但是他返回的是条目中的自孩子.1，然后因为子孩子.1 ipAddrEntry也是列对象，所以继续往下寻找，
1.3.6.1.2.1.4.20.1.1是一个查找本机的ip地址条目的oid，而第一个100.70.15.121是一个内网的IP地址，可能是
这个IP是一个运营商分配的的内部使用的IP地址。
继续查找：
可以发现下面的都是比较熟悉的IP了，回环口，以及WIFI的IP，VM的网卡的IP等
接下来分析查找列对象（get-next-request）的报文：
第一第二个字段 version：0 与community：017018前面已经分析过了，因此这里不再赘述。
直接看第三个PDU字段，此时的PDU的类型变成了get-next-request（1）
get-next-request
GetNextRequest-PDU,
在RFC1157中查看 GetNextRequest-PDU的ASN.1语法
GetNextRequest-PDU ::=
[[1](#ref-1)]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status -- always 0
ErrorStatus,
error-index -- always 0
ErrorIndex,
variable-bindings
VarBindList
}
可以看到内容与GetRequest-PDU一样，仅有的差别是定义中的[1]与前面GetRequest-PDU中的[0]有所区别。
[1]表示“上下文专用标签”，标签值为1，类型也为SEQUENCE 。
T:
10（上下文专用标签）+1（构造类型）+00001（标签值为1）, 即为10 1 00001，A1H
L:
长度为18H
V:
第一个值为 request-id
RequestID ::=
INTEGER
T：
00(UNIVERSAL)+0(简单类型)+00010(INTEGER类型)，即0000 0010B，02H
L：
值长度为1字节，即01H
V:
值为1
综上request-id 的BER编码为 02 01 01
第二个值为error-status
ErrorStatus ::=
INTEGER {
noError(0),
tooBig(1),
noSuchName(2),
badValue(3),
readOnly(4)
genErr(5)
}
T：
00(UNIVERSAL)+0(简单类型)+00010(INTEGER类型)，即0000 0010B，02H
L：
值长度为1字节，即01H
V:
值为0 （noError）
综上request-id 的BER编码为 02 01 00
第三个值为ErrorIndex ，也是Interger
ErrorIndex ::=
INTEGER
T：
00(UNIVERSAL)+0(简单类型)+00010(INTEGER类型)，即0000 0010B，02H
L：
值长度为1字节，即01H
V:
值为0
综上errorindex 的BER编码为 02 01 00
\第四个值为\VarBindList\
VarBindList ::=
SEQUENCE OF
VarBind
其中的元素VarBind：
VarBind ::=
SEQUENCE {
name
ObjectName,
value
ObjectSyntax
}
T:
SEQUENCE OF的标签类型为UNIVERSAL ， 值为00
构造类型，因此第三位二进制数为1
标签编号为8, 10000B
因此标签值为 00 1 10000B，30H
L:
ODH 长度为13
V:
里面套着个VarBind
VarBind ::=
SEQUENCE {
name
ObjectName,
value
ObjectSyntax
}
也是SEQUENCE类型
T:
00（UNIVERSAL）+1（构造类型）+10000（SEQUENCE类型），即00 1 10000B, 30H
L:
长度为11，OBH
V:
值为name，和value
Name的类型为ObjectName，查询RFC1157文档，发现这种类型在RFC1155中定义
IMPORTS
ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
FROM [RFC1155](https://www.rfc-editor.org/rfc/rfc1155)-SMI;
ObjectName ::=
OBJECT IDENTIFIER
因此ObjectName 的类型为OBJECT IDENTIFIER
T:
00(UNIVERSAL) + 0(简单类型)+00110（OBJECT IDENTIFIER类型），即00 0 00110B，06H
L:
长度为7 07H
V:
这里的值是我们请求的OID
这里的iso.3直接变成了2bH,其他字符按照十六进制直接翻译 因此ObjectName的BER编码为06 07 2B 06 01 02 01 04 14
VALUE的类型为ObjectSyntax，以下是该类型在RFC1155文档中的定义
ObjectSyntax ::=
CHOICE {
simple
SimpleSyntax,
-- note that simple SEQUENCEs are not directly
-- mentioned here to keep things simple (i.e.,
-- prevent mis-use). However, application-wide
-- types which are IMPLICITly encoded simple
-- SEQUENCEs may appear in the following CHOICE
application-wide
ApplicationSyntax
}
SimpleSyntax ::=
CHOICE {
number
INTEGER,
string
OCTET STRING,
object
OBJECT IDENTIFIER,
empty
NULL
}
T:
因为值为空，所以SimpleSyntax 应该是CHOICE 中的empty
00(UNIVERSAL)+0(简单类型)+00101(NULLL类型)，即 00 0 00101B,05H
L:
长度为0
V:
没有值
综上，value的BER编码为05 00
综上，VarBind的BER编码为30 0B 06 07 2B 06 01 02 01 04 14 05 00
综上 \VarBindList\的BER编码为 \30 0D\ \30 0B\ \06 07 2B 06 01 02 01 04 14 05 00\
\分析response报文：\
第一第二个字段 version：0 与community：017018前面已经分析过了，因此这里不再赘述。
直接看第三个PDU字段，此时的PDU的类型为get-response（2）
get-response
GetResponse-PDU,
在RFC1157中查看 GetResponse-PDU的ASN.1语法
GetResponse-PDU ::=
[[2](#ref-2)]
IMPLICIT SEQUENCE {
request-id
RequestID,
error-status
ErrorStatus,
error-index
ErrorIndex,
variable-bindings
VarBindList
}
[2]表示“上下文专用标签”，标签值为2，类型也为SEQUENCE 。
T:
10（上下文专用标签）+1（构造类型）+00010（标签值为2）, 即为10 1 00010，A2H
L:
长度为22H
V:
第一个值为 request-id
前面已经分析过，不再赘述
第二个值为error-status
前面已经分析过，不再赘述
第三个值为ErrorIndex
前面已经分析过，不再赘述
第四个值为VarBindList
VarBindList ::=
SEQUENCE OF
VarBind
其中的元素VarBind：
VarBind ::=
SEQUENCE {
name
ObjectName,
value
ObjectSyntax
}
先分析外层的VarBindList
T:
SEQUENCE OF的标签类型为UNIVERSAL ， 值为00
构造类型，因此第三位二进制数为1
标签编号为8, 10000B
因此标签值为 00 1 10000B，30H
L:
17H
V:
里面套着个VarBind
VarBind ::=
SEQUENCE {
name
ObjectName,
value
ObjectSyntax
}
也是SEQUENCE类型
T:
00（UNIVERSAL）+1（构造类型）+10000（SEQUENCE类型），即00 1 10000B, 30H
L:
长度为21，15H
V:
值为name，和value
Name的类型为ObjectName，查询RFC1157文档，发现这种类型在RFC1155中定义
IMPORTS
ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
FROM [RFC1155](https://www.rfc-editor.org/rfc/rfc1155)-SMI;
ObjectName ::=
OBJECT IDENTIFIER
因此ObjectName 的类型为OBJECT IDENTIFIER
T:
00(UNIVERSAL) + 0(简单类型)+00110（OBJECT IDENTIFIER类型），即00 0 00110B，06H
L:
长度为13 ODH
V:
这里的值是我们请求的OID ,然后后面他自动加上了这个标量的子oid，也就是
.1.1.100.70.15.121
前两个1.3(iso.3)变为2B，其余字符按照数字转成成16进制数。
2b 06 01 02 01 04 14 01 01 64 46 0F 79
综上ObjectName 的BER编码为06 13 2B 06 01 02 01 04 14 01 01 64 46 0F 79
VALUE的类型为ObjectSyntax，以下是该类型在RFC1155文档中的定义
ObjectSyntax ::=
CHOICE {
simple
SimpleSyntax,
-- note that simple SEQUENCEs are not directly
-- mentioned here to keep things simple (i.e.,
-- prevent mis-use). However, application-wide
-- types which are IMPLICITly encoded simple
-- SEQUENCEs may appear in the following CHOICE
application-wide
ApplicationSyntax
}
T:
这里的值是IpAddress类型，因此推测ObjectSyntax 可能为application-wide，查阅RFC1155文档，找到相关定义：
ApplicationSyntax ::=
CHOICE {
address
NetworkAddress,
counter
Counter,
gauge
Gauge,
ticks
TimeTicks,
arbitrary
Opaque
}
NetworkAddress ::=
CHOICE {
internet
IpAddress
}
IpAddress ::=
[APPLICATION 0] -- in network-byte order
IMPLICIT OCTET STRING (SIZE (4))
因此application-wide为ApplicationSyntax ，然后ApplicationSyntax 还会选择address类型NetworkAddress，然后NetworkAddress类型被定义为IpAddress，IpAddress类型被定义为APPLICATION 标签，标签值为0，具体类型为IMPLICIT OCTET STRING（SIZE(4)）
01(APPLICATION )+0(简单类型)+0000(标签值为0)，即 01 0 00000 B,40H
L:
长度为4,04H
V:
四个以.分割的ip段，每个占据一字节，直接转换成16进制数 100->64H 70->46H....
综上，value的BER编码为40 04 64 0F 79
综上，VarBind的BER编码为：30 15 06 0D 2B 06 01 02 01 04 14 01 01 64 46 0F 79 40 40 04 64 0F 79
综上，VarBindList的BER编码为 30 17 30 15 06 0D 2B 06 01 02 01 04 14 01 01 64 46 0F 79 40 40 04 64 0F 79
\综上，列对象其实就是下面还有其他的oid分支，可以把他看成一个多维数组，然后对于不在OID范围内的OID对象，通过next查找时，并不是按照他的位置来查找的，即.0,.1,.2这样，而是通过他的具体值来查找。\
\这样的话，我们肯定是不能直接通过OID来请求的，因为我们不知道是否有这元素，因此需要借助request-next，自动帮我们查找这个列对象的下一个标量对象。\
3） 查找标量对象标识符.1.3.6.1.2.1.11.13是什么对象，其实例标识符是什么？若连续多次GET这个实例标识符，得到的值有什么变化？请抓包分析其PDU格式。请截图说明。
标量对象标识符 .1.3.6.1.2.1.11.13 表示 SNMP 协议实体根据收到的正确 Get-Request 和 Get-Next 请求，成功检索到的 MIB 目标数。
其\实例标识符是 .1.3.6.1.2.1.11.13\.\0\
\Request\
请求报文与第一题中的request的分析一样，仅有OID号有所更改，对应的L字段更改，其他没有变化，这里不再重复。
\Response\
这里的response的variable-bingdings之前的分析前面已经分析过了，这里不再重复。
第四个值variable-bingding为VarBindList类型
VarBindList ::=
SEQUENCE OF
VarBind
其中的元素VarBind：
VarBind ::=
SEQUENCE {
name
ObjectName,
value
ObjectSyntax
}
先分析外层的VarBindList
T:
SEQUENCE OF的标签类型为UNIVERSAL ， 值为00
构造类型，因此第三位二进制数为1
标签编号为8, 10000B
因此标签值为 00 1 10000B，30H
L:
10H
V:
里面套着个VarBind
VarBind ::=
SEQUENCE {
name
ObjectName,
value
ObjectSyntax
}
也是SEQUENCE类型
T:
00（UNIVERSAL）+1（构造类型）+10000（SEQUENCE类型），即00 1 10000B, 30H
L:
长度为21，15H
V:
值为name，和value
Name的类型为ObjectName，查询RFC1157文档，发现这种类型在RFC1155中定义
IMPORTS
ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
FROM [RFC1155](https://www.rfc-editor.org/rfc/rfc1155)-SMI;
ObjectName ::=
OBJECT IDENTIFIER
因此ObjectName 的类型为OBJECT IDENTIFIER
T:
00(UNIVERSAL) + 0(简单类型)+00110（OBJECT IDENTIFIER类型），即00 0 00110B，06H
L:
长度为13 ODH
V:
这里的值是我们请求的OID ,1.3.6.1.2.1.11.13.0
前两个1.3(iso.3)变为2B，其余字符按照数字转成成16进制数。
2B 06 01 02 01 0B 0D 00
综上ObjectName 的BER编码为06 08 2B 06 01 02 01 0B 0D 00
VALUE的类型为ObjectSyntax，以下是该类型在RFC1155文档中的定义
ObjectSyntax ::=
CHOICE {
simple
SimpleSyntax,
-- note that simple SEQUENCEs are not directly
-- mentioned here to keep things simple (i.e.,
-- prevent mis-use). However, application-wide
-- types which are IMPLICITly encoded simple
-- SEQUENCEs may appear in the following CHOICE
application-wide
ApplicationSyntax
}
T:
前面分析过simple，类型SimpleSyntax并没有Counter32，因此类型应该为ApplicationSyntax。查找RFC1155文档
ApplicationSyntax ::=
CHOICE {
address
NetworkAddress,
counter
Counter,
gauge
Gauge,
ticks
TimeTicks,
arbitrary
Opaque
}
其中确实有\Counter\类型,Conuter类型为计数器，只能增，不能减\
Counter ::=
[APPLICATION 1]
IMPLICIT INTEGER (0..4294967295)
\标签类型为\APPLICATION 标签值为1，具体类型为 IMPLICIT INTEGER
01(APPLICATION )+0(简单类型)+00001(标签值为1)，即 01 0 00001 B,41H
L:
02H
V:
1152转为16进制数为06 10H
综上，value的BER编码为:41 02 05 10
综上，VarBind的BER编码为 30 0E 06 08 2B 06 01 02 01 0B 0D 00 41 02 05 10
综上，VarBindList的BER编码为 30 10 30 0E 06 08 2B 06 01 02 01 0B 0D 00 41 02 05 10
\分析完PDU格式后，进行多次请求\
可以发现，每次请求后Value累加了1
请求一次OID .1.3.6.1.2.1.1.1.0后
再来查看MIB数
这一次Value + 2，因此可以总结出，这个OID是用来查看当前请求的MIB数的请求数量的。我们发送了多少条OID请求，那么这个数字就会累加起来。
五、实验小结
1、 通过这次的实验，清晰地了解到了如何查询RFC文档，快速找到相关的ASN.1编码规则，然后进行BER编码。
2、 在实验中有接触到隐式标签IMPLICIT ，大概的清楚了隐式标签的作用，具体的类型值不随着一起编码，而是隐藏类型值，这样可以省去嵌套的一个类型值，一个长度，至少2字节的空间，并且如何解码这些字节取决于它们的数据类型，所以其实还是能够被正常解析出。
3、 对于实验中的三种类型的报文 get-request,get-response,get-next-request之间的相同点和不同点都有更清晰了，这些报文类型都是上下文标签定义的，且具体的类型都一样，只是类型的标签号不同。内容前面都是固定格式，然后最后的variable-bingdings可能随着OID的改变有所不同。
4、 在寻找不同功能的OID的过程中，熟悉了查找自己需要使用的OID的流程。然后加深了对于标量对象与列对象的区分。标量对象一般到.0，或者为其内容，也就是.value。列对象可能嵌套多层，然后列对象里可能还含有列对象，也可能还有标量对象。
六、参考资料
https://www.rfc-editor.org/rfc/rfc1157.html#section-4.1.4
https://www.rfc-editor.org/rfc/rfc1155
OID 1.3.6.1.2.1.4.21 ipRouteTable， ipRoutingTable 参考信息 (oidref.com)
posted on
