10BASE-T1S PLCA轮询机制：用Wireshark抓包实战分析

先说我个人的一个观点做车载以太网这些年100BASE-T1和1000BASE-T1大家已经摸得挺熟了但10BASE-T1S这几年突然火起来很重要的一个原因就是它以极低的成本把“以太网”下沉到了传感器、门模块、灯控这些低速节点上。而10BASE-T1S要在共享总线上跑得稳避不开PLCAPhysical Layer Collision Avoidance这个轮询机制。这篇文章我就用Wireshark实际抓包带你把10BASE-T1S的PLCA轮询机制彻底看明白。内容会覆盖PLCA原理、抓包环境搭建、pcap文件分析思路、常见坑点排查最后还会分享一些我调试T1S网络时积累的实操经验。适合刚接触10BASE-T1S的嵌入式工程师、测试工程师也包括想深入理解车载以太网底层机制的协议栈开发者。1. 10BASE-T1S为什么需要PLCA轮询1.1 单对线、共享总线先天就要面对“抢总线”问题10BASE-T1S的物理层跟普通以太网最大的区别在于它只有一对双绞线而且是半双工、共享总线拓扑。你可以把它理解成很多设备同时挂在一根线上跟早期的同轴以太网很像也跟CAN总线有一点相似——但又不完全一样。正因为是共享介质两个节点如果同时往总线上发数据信号就会冲突、互相覆盖接收端根本解不出有效帧。传统以太网解决这个问题靠的是CSMA/CD也就是“先听后发冲突后随机退避”。但CSMA/CD的随机退避机制导致的后果就是延迟完全不可控最坏情况下谁也别想发出去。这在普通办公网络里还能忍但在汽车上一个传感器数据没按时送到可能导致上层控制逻辑直接跳过一帧甚至引发功能降级——这显然不能接受。我当时刚接触10BASE-T1S时第一反应也是“这不就是老式集线器网络吗”但看完PLCA的原理才发现802.3cg工作组非常聪明地绕开了CSMA/CD的弱点用一套轻量级的轮询协议彻底解决了冲突问题。1.2 PLCA的本质主持人点名而不是大家抢麦PLCA全称Physical Layer Collision Avoidance直译过来是“物理层冲突避免”但它的工作方式更像是一场有主持人的会议。网络里指定一个节点作为协调者通常叫Node 0。这个Node 0每隔一段时间在总线上发一个信标Beacon相当于会议开始、宣布“按座位顺序发言”。然后Node 0按节点ID从1开始一个个轮询先问Node 1“你有没有数据要发”有就发发完轮到Node 2Node 2没有数据就快速跳过继续问Node 3……一直轮询到最大节点ID然后回到起点等待下一个Beacon。整个过程就像主持人拿着名单挨个点名。被点到的人有发言权没被点到的人只能听。这样从根本上保证了一个时刻总线上只有一个人在发送不存在冲突。有一个关键点很多初学者会忽略Node 0在发Beacon的同时自己也会参与数据发送。它并不是一个纯管理节点只是在管理调度上多了一个“主持人”身份。所以你在抓包时Node 0的数据帧同样会出现在总线上只是它的发送机会是安排在Beacon之后、所有其他节点之前。1.3 PLCA机制中的几个关键信号与时间参数要分析PLCA必须先认识几个术语否则看Wireshark时间戳时会一头雾水。术语含义我的理解BeaconNode 0周期性发送的信标信号相当于每一轮调度的起止标志Poll协调者按ID给某个节点发出的轮询信号相当于“轮到你了”Commit节点正式发送数据前发出的短突发信号相当于“这个发言机会我占了你们别抢”Burst / TO单个节点在一次轮询中拥有的发送窗口可以配置成发送一帧、多帧或限制发送时长Node Count参与PLS轮询的最大节点ID范围由PHY寄存器配置最多支持32个节点ID 0~31这里我要特别强调一个很多人踩过的坑Beacon、Poll、Commit在绝大多数情况下不会作为独立以太网帧出现在Wireshark里。它们是PLCA子层的物理层信号对MAC层和上层协议完全透明。Wireshark能看到的只是普通以太网帧以及帧与帧之间的时间间隔。但正因为PLCA的调度结果会直接影响“哪个节点在什么时刻收到发送机会”我们完全可以通过分析以太网帧的发送顺序、源MAC规律和帧间间隔反推出PLCA轮询机制的工作状态。这就是用Wireshark分析PLCA的核心思路。2. 抓包环境搭建怎么才能拿到10BASE-T1S的报文2.1 普通电脑网卡抓不到T1S你需要专用硬件很多人拿到一份10M汽车以太网pcap文件后第一反应是用电脑自带的千兆网卡去抓——这肯定不行。普通网卡的物理接口是RJ45走的是四对差分线而10BASE-T1S只有一对线电平逻辑、连接器、编解码方式完全不同物理层就不兼容。要抓10BASE-T1S的包常见方案有几种专用汽车以太网分析仪比如Vector VN5610、VN5651或者英特佩斯的T1S接口模块这类工具自带T1S PHY能把总线上的以太网帧解析出来再通过USB或以太网上传给PC的Wireshark。PHY评估板加调试软件比如Microchip LAN8670/2、Marvell的T1S PHY评估板厂商工具一般支持把抓到的帧导出成pcap/pcapng。示波器或逻辑分析仪搭配解码插件能看物理层信号但对MAC层帧解码支持参差不齐效率偏低。如果你手头没有硬件纯学习的话建议先用别人抓好的pcap文件做离线分析。这也是我比较推荐的方式——先学会分析思路再上真硬件心里才不慌。我下面要演示的分析过程就是基于一份实验室台架抓取的样例pcap节点拓扑是1个Node 0加2个从节点PLCA使能Node Count配成3。为了保证教程可读性样例里的MAC地址做了脱敏处理时间戳保留了原始精度。2.2 Wireshark版本、驱动与基本配置软件方面Wireshark建议直接用最新稳定版目前4.x系列已经非常成熟。Windows系统下抓包驱动用Npcap安装时记得勾选“Win10/11支持”的选项。如果你只是分析已有的pcap文件其实不需要装Npcap打开Wireshark直接File - Open选择文件即可。但如果你是要用电脑的某个网口做在线抓包那就要在Capture Interfaces里找到正确的接口并且打开混杂模式Promiscuous Mode否则可能会漏掉大量广播帧和目的MAC不是本机的帧。有个小细节Wireshark打开pcap后默认的时间显示格式是“Seconds Since Epoch”或者年月日这对PLCA分析很不友好。我习惯先把时间显示改成“Seconds Since Previous Displayed Packet”这样每一行显示的是当前包和上一个显示出来的包之间的时间差。后面分析轮询周期时这个字段就是核心。改法很简单菜单栏View - Time Display Format - Seconds Since Previous Displayed Packet。改完之后每一帧前面的数值会变成“0.000031250”这种格式可以非常直观地看到帧间间隔。2.3 抓包时的拓扑、链路状态确认抓T1S总线这种共享介质我最担心的一件事是“抓到了但链路本身就不稳定”。所以上线抓包之前先确认PHY链路已经正常建立。对10BASE-T1S来说可以通过PHY寄存器0x1的Link Status位判断也可以看分析仪工具上的Link指示灯。链路正常后抓包工具尽量接在总线末端或者靠近协调者的位置。因为T1S总线上每个节点收发会有一定延迟抓包点如果离某个节点太远帧到达抓包点的时间会有一点点偏差。对分析PLCA这种微秒级周期的机制来说这个偏差可能造成误判。严格一点的做法是用带时间同步功能的多通道分析仪同时挂多个抓包点然后再做时间对齐。3. 用Wireshark分析PLCA轮询机制的完整实操3.1 第一步先看整体确认PLCA确实在工作打开样例pcap文件后我不会急着看时间间隔而是先做两件事。第一件事是Statistics - Protocol Hierarchy看看包里都有什么协议。注意你会发现列表里根本没有“PLCA”这个协议名。我早年间也犯过这个错误在Filter里输PLCA搜了半天一无所获后来翻了PHY芯片手册才明白PLCA根本不会以协议形式出现在MAC层帧里。所以看到没有PLCA是正常的不用慌。第二件事是Statistics - Endpoints按MAC地址看各节点的帧数和字节数。在我的样例文件里三个节点都有各自的发送记录总量分布比较均匀没有出现一个节点占了99%流量的情况。这说明三个节点都在正常参与总线调度。如果某个节点只有接收没有发送那就需要重点关注了——它可能没被正确配置进PLCA轮询表或者在Poll到它时一直没数据可发这是允许的但长时间零发送也需要查一下。3.2 第二步用时间列直接观察轮询周期我先把时间显示格式改成“Seconds Since Previous Displayed Packet”然后查看连续几帧的原始列表。下面是我从样例pcap中截取的一段帧号时间秒源MAC目的MAC帧长156710.000000000Node111:11:11:00:00:01Node0128156720.000031250Node211:11:11:00:00:02Node0128156730.000062500Node1Node0128156740.000093750Node2Node0128这里的时间戳是指“相对前一帧的间隔”。可以看到一个非常规律的节奏Node1和Node2交替发送每个节点每隔约62.5微秒出现一次相邻两帧之间的间隔稳定在31.25微秒左右。我们顺着这个规律推一下假如Beacon周期约31.25微秒那么在一个周期内Node1发送一次紧接着Node2发送一次加起来就是两个31.25微秒也就是Node1两帧之间隔了62.5微秒。跟我上面看到的现象完全吻合。这说明PLCA协调者确实在以固定周期轮询两个从节点而且两个节点都有数据要发没有出现空轮询。这里要提醒一点帧间间隔不是简单等于Beacon周期它等于“上一个节点发送结束下一个节点收到Poll并响应”的总时间。所以当你要精确计算Beacon周期时最好看所有从节点都连续有数据发送的情况然后用多个间隔取平均或取众数。3.3 第三步按源MAC过滤看单个节点的发送节奏观察完整体规律后我习惯按源MAC做过滤逐个节点确认。显示过滤器里输入eth.src 11:11:11:00:00:01只看Node1发送的帧。这时时间列会变成这样帧号时间秒说明156710.000000000Node1第1次发送156730.000062500Node1第2次发送156750.000125000Node1第3次发送Node1每次出现的间隔正好是62.5微秒而且非常稳定。两个从节点之间是严格交替的顺序永远是Node1先、Node2后。这就是PLCA最典型的特征顺序固定、周期固定、无冲突不会出现CSMA/CD下那种“某个节点突然连续发好几帧另一个节点长时间发不出去”的情况。如果你是第一次拿到T1S抓包文件我建议按这几个问题自测一下各节点发送顺序是不是固定不变的节点发送间隔是不是集中在某个值附近总线上有没有碰撞后常见的随机退避长间隔如果以上都是“是”那大概率就是PLCA在正常轮询。3.4 第四步用IO Graph量化周期和抖动肉眼看完规律后我一般会用Wireshark的IO Graph把周期性画出来。菜单栏Statistics - IO Graph把时间间隔设成10微秒或20微秒Y轴类型可以选Packets/tick。如果你的PLCA周期稳定你会看到图形上有非常规律的尖峰每隔一段相同的时间就有一个脉冲峰。这个尖峰的间距就是轮询周期的可视化体现。不过IO Graph看趋势方便要精确量化周期和抖动还是得用tshark批量处理。命令行进入pcap所在目录执行tshark -r plca_sample.pcapng -T fields -e frame.number -e frame.time_delta -e eth.src -e frame.len delta.txt这条命令会导出每一帧的编号、相对前一帧的间隔、源MAC和帧长。拿到这个文本后我再用Python做一个快速统计比如找出所有间隔的众数、平均值、最大值以及按源MAC分组后的帧间隔直方图。import collections deltas [] with open(delta.txt, r) as f: next(f) # 跳过表头 for line in f: parts line.strip().split(\t) if len(parts) 2 and parts[1]: deltas.append(float(parts[1])) counter collections.Counter(round(d, 9) for d in deltas) print(counter.most_common(10))在我这份样例pcap里间隔众数非常干净地落在31.25微秒左右。这个值可以作为Beacon周期的近似估算。如果统计结果里出现很多个零散的间隔值那就要怀疑抓包点是否跨了多个总线网段或者网络里有节点没开PLCA。3.5 第五步判断节点ID与实际MAC的对应关系还有一个经常被问到的点我怎么知道哪个MAC对应Node 0哪个对应Node 1、Node 2答案其实不在抓包文件里而在于ECU的PHY配置。PLCA的Node ID是通过PHY芯片寄存器配置的跟MAC地址没有必然绑定关系。但在实际项目中硬件设计文档一般会规定每个节点的Node ID和MAC映射关系。如果当场没有文档也可以从抓包行为里反推。以样例为例Node0作为协调者它的发送机会在Beacon之后、其他节点之前所以在每个轮询周期里最接近周期起点的那个源MAC大概率是Node0。而两个从节点的顺序是Node1在Node2之前一旦你确认了某个MAC是Node1另一个自然就是Node2。我在实际调试中曾经遇到过一种情况两个产品的Node ID配置颠倒了导致A产品发完B产品紧接着发但上层应用期望的顺序是反的。功能链路上看帧都到了、帧内容也都对但时序不满足要求。这种情况靠Wireshark的轮询顺序分析很容易一眼抓出来这也是抓包分析PLCA机制最有价值的地方之一。3.6 补充怎么观察Commit信号有不少朋友拿着示波器看物理层波形时会发现正式以太网帧之前似乎还有一个很短的信号这就是Commit信号。它本质上是一段物理层突发长度远小于正常前导码用来告诉总线“我现在拥有这个发送机会”。在Wireshark里你几乎不会看到Commit作为一个独立帧出现因为抓包工具通常只把“有效以太网帧”交给上层解析。但它在时间戳上会造成一个细微差异如果你拿帧与帧之间的总间隔去对比“所有节点的数据帧拼接时间”会多出那么一点额外的时间。这一点就是Commit信号以及PHY状态切换的耗时。如果你用的是带物理层原始采样功能的分析仪某些Vector工具和PHY调试软件支持可以导出原始信号查看这个细节。对绝大多数场景来说知道“Wireshark里看不到Commit正常别浪费时间去找”就够了。4. 常见问题与排查技巧实录4.1 抓包接口里没有T1S接口怎么办如果你确认分析仪已经连好但Wireshark的接口列表里看不到T1S接口大概率是软件驱动层的问题。第一检查分析仪厂商提供的抓包驱动是否安装第二确认接口是否被Wireshark识别为非以太网类型第三检查分析工具的抓包模式是否设置为混杂模式。我见过最坑的一个案例是抓包工具默认开启了“仅抓取发给本机MAC的帧”的过滤规则导致大量广播帧以外的数据完全看不到看起来就像总线空闲。这时把抓包工具的过滤规则关掉或者把网卡设置为Promiscuous Mode立刻就正常了。4.2 Wireshark里搜不到PLCA协议是不是抓错了这个前面已经反复强调过PLCA是MAC层以下的机制Wireshark的协议栈里没有它。你在Filter里输入plca是不会有结果的。正确的排查思路是把Wireshark当成一个“时间戳显微镜”来用重点看帧的发送顺序、源MAC规律、帧间间隔分布。如果非要在Wireshark里找PLCA相关的直接证据可以看看抓包软件是否在pcapng文件里写入了自定义的注释字段。Vector等工具确实会把物理层辅助信息放进扩展块里但常规pcap不会。4.3 帧间隔看起来很不规律怎么判断是CSMA/CD还是PLCA如果你的抓包文件里同一节点的发送间隔忽长忽短并且不同节点的发送顺序经常变化那很可能不是PLCA在工作至少不是所有节点都启用了PLCA。判断方法有两个层面。第一个层面是看PHY配置寄存器确认PLCA enable位是否置1Node Count和Node ID是否正确。第二个层面是纯从行为分析CSMA/CD模式下随机退避会导致帧间隔出现“离散的、不可预测的大跳跃”而PLCA模式下间隔一般集中在某个基础周期的整数倍附近。我调试过一个混合网络Node0开了PLCA但从节点还是默认的CSMA/CD模式。结果就是Node0在Beacon后发完自己的数据从节点的包却乱序到达Wireshark里的时间列看起来像一个随机过程。最后定位就是PHY寄存器没刷进去从节点被复位回了默认配置。4.4 为什么抓包文件里只能看到部分字节比如520字节这个问题在Wireshark用户里问得很多。它跟PLCA没有直接关系但确实会影响分析尤其是当你想看完整帧内容时。通常原因是抓包时的Snaplen抓包长度上限被设置成了比较小的值比如520或128。抓包工具只保存了每个帧前面一部分字节后面的内容全丢了这在离线阶段是无法恢复的。解决办法很简单在线抓包时在Capture Options里把“Limit each packet to”改成65535字节。做一个反向澄清10BASE-T1S的标准以太网帧最长也就1518字节无VLAN或1522字节有VLAN正常情况下不存在“帧太长被截断”的问题。如果看到超过这个长度的帧先看看是不是抓包工具把CRC、前导码等物理层信息也算进去了。4.5 时间戳到底准不准能不能用来算Beacon周期10BASE-T1S的帧头到达时间戳通常由抓包硬件标记精度在纳秒级这个可信度是比较高的。但软件在将时间戳写入pcap文件时会有一定开销不同工具之间可能有微秒级的偏差。因此我建议计算Beacon周期时用多个连续间隔的平均值或者众数不要拿单个帧间隔当结论。抖动分析时也要建立在大量采样基础上。如果只是想确认PLCA“是不是在跑”看几个周期的规律性就够了如果要做时间同步预算或者TSN调度设计那就要用更精确的硬件时间戳工具来做而不是直接拿Wireshark的间隔当绝对参考。5. 调试T1S网络的几点个人经验聊到这里我再把这段时间积累的几个实操心得分享出来算是对全文的一个落地补充。第一点上手10BASE-T1S一定要有“PHY寄存器优先”的意识。PLCA机制的所有关键参数都控制在PHY层而不是MAC层或应用层。所以你抓包之前先花5分钟把PHY的寄存器导出确认PLCA开启、Node ID和Node Count配置无误。这样抓出来的包才有分析价值否则你会花大量时间在一个错误配置的网络里找规律。第二点抓包分析PLCA重心放在“验证设计预期”上而不是单纯地“看看流量”。比如你在设计阶段把某节点每轮突发窗口配置为2帧那Wireshark里应该看到该节点每次被轮询时连续发2帧如果你的应用分配了固定带宽那通过统计每个节点的帧间隔分布就能反过来验证带宽模型是否合理。第三点如果现场遇到“某节点数据延迟突然变大”的故障强烈建议先过滤该节点的源MAC把每帧之间的间隔拉出来看。如果间隔出现明显的两倍周期跳变说明某个PLCA周期里这个节点没有获得发送机会或者它当时没有数据。结合上层应用日志能非常高效地定位问题出在“没被轮询”还是“没数据可发”。最后再说一个小技巧抓包文件后续做回归测试非常好用。同样一个PLCA周期配置在硬件改版前后各抓一次包用tshark导出间隔分布对比众数和抖动范围。只要这个指标没有明显劣化网络调度这一层基本就不会有太大问题。我这几年调PLCA最大的感触是它不复杂但它藏在物理层之下容易被当作“黑盒”忽视。而一旦你学会用Wireshark的时间轴和帧间隔去“透视”它很多看似玄学的车载以太网问题都会变得非常清晰。