查看: 21974|回复: 6

关于科来软件的一点探讨

[复制链接]
发表于 2012-9-19 17:06:05 | 显示全部楼层 |阅读模式
本帖最后由 enclave 于 2012-9-19 17:14 编辑

先上图



以一个常见的pvstp bpdu 为例

在结构上这是一个标准802.3-802.2 frame 而非ethernetII
重要字段简析如下
dmac 01000ccccccd
smac cc0008c4f001
81 00 00 044byte 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 =0x8100802.1q专用标记而不是可选项 不能与标准的ethernet type code 等价

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


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




本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?CSNA会员注册

×

评分

1

查看全部评分

回复

使用道具 举报

发表于 2012-9-19 20:48:01 | 显示全部楼层
回复

使用道具 举报

发表于 2012-9-20 08:03:58 | 显示全部楼层
值得探讨
回复

使用道具 举报

发表于 2012-9-20 09:52:09 | 显示全部楼层
能指出不足是好事。
回复

使用道具 举报

发表于 2012-9-20 13:00:05 | 显示全部楼层
非常感谢提出的建议
回复

使用道具 举报

发表于 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。


802.1Q的TPID也并不仅有“8100”一个值:


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

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

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?CSNA会员注册

×
回复

使用道具 举报

发表于 2012-9-26 13:08:56 | 显示全部楼层
嗯。有道理。此议甚好
回复

使用道具 举报

您需要登录后才可以回帖 登录 | CSNA会员注册

本版积分规则

快速回复 返回顶部 返回列表