关于科来软件的一点探讨

enclave · 发表于 2012-9-19 17:06:05

本帖最后由 enclave 于 2012-9-19 17:14 编辑

先上图

未命名.JPG

以一个常见的pvstp bpdu 为例

在结构上这是一个标准802.3-802.2 frame 而非ethernetII
重要字段简析如下
dmac 01000ccccccd
smac cc0008c4f001
81 00 00 04是4byte ieee 802.1q tag for vlan 4
length 50(0x0032)
dsap AA
ssap AA
control 3
下略

想要表达的是这里解码图格式定义不够严谨的地方

802.1q 4byte报文只是一个附加在frame header内的tag 而不是encapsulation .这在ieee规范中定义的虽然这只是一个switch内部处理对象的差异而对终端系统是透明的但从报文分析和重组的角度个人认为应该明确区分开这里的格式解析不免有些粗糙

ethernet II\protocol =0x8100是802.1q专用标记而不是可选项不能与标准的ethernet type code 等价

最有争议的一处是位于802.1q vlan\protocol type=0x0032 敝以为这里0x0032应该不是protocol type的键值而是上一层802.3 frame\length 值
后面的16进制报文内容和长度也都完全符合802.3格式熟悉各种frame格式的有心人可以印证一下这个说法

我想软件方设计树形解码图的初衷是实现用户直观效果但对于vlan tag这种insert格式的表达就有容易让人错觉了也不知道以前有否人提过这一点抛砖引玉也希望各位能指出不足

daming · 发表于 2012-9-19 20:48:01

大金子 · 发表于 2012-9-20 08:03:58

值得探讨

xixi2k · 发表于 2012-9-20 09:52:09

能指出不足是好事。

palm · 发表于 2012-9-20 13:00:05

非常感谢提出的建议

steve-zhu · 发表于 2012-9-20 13:33:28

本帖最后由 steve-zhu 于 2012-9-20 13:36 编辑

楼主说的有道理，按照IEEE 802.1Q协议标准，“8100”的确是vlan tag的TPID标识，不过按照802.1Q标准文档TPID字段的内容就是Ethertype值，在通信双方都支持Ethertype编码的场景TPID等价与Ethertype。
2012-9-20 13-33-22.png

802.1Q的TPID也并不仅有“8100”一个值：
2012-9-20 13-35-34.png

因此，协议分析产品多数都是将这样的报文解码为Ethernet II+802.1Q的方式，将TPID解码为Ethernet II的Ethertype，而将原包的Ethertype或length放在802.1Q tag中展现，例如下面的wireshark。
2012-9-20 13-37-57.png

楼主PVST报文应该是在原有802.3+LLC报头中的Length字段头前面嵌入了Tag，相当于是Ethernet II+802.1Q+LLC的格式。
不过VLAN ID之后的10个字节，科来解码的确存在一些问题。科来没有把后面的0x12~0x19字节识别为LLC头，也没有把0x10~0x11正确的识别为length。我相信科来的产品研发人员会尽快修正的。

tonylldd · 发表于 2012-9-26 13:08:56

嗯。有道理。此议甚好

关于科来软件的一点探讨

评分