文章目录
- 0. 引言
- 1. 问题定位
- 1.1 初步排查
- 1.2 Wireshark抓包验证
- 1.3 Linux环境对比
- 2. 问题分析与解决
- 2.1 可能原因
- 2.2 混杂模式测试
- 3 结论
0. 引言
PTPD是一种时间同步的开源实现，遵循IEEE1588 协议，是通过在主从时钟之间传输同步报文来实现同步，主要分为两个阶段：偏差测量和延迟测量，同步过程重要的报文如下图所示:
在QNX系统中运行PTPD时，遇到了无法进行gPTP（通用精确时间协议）同步的问题。经过排查，发现是QNX开发板无法收到数据链路层的PTPv2数据包引起的问题。
更多阅读请查看 PTPD 在 QNX 系统上的授时精度验证与误差排查
以下是问题排查过程及解决方法的详细记录。
1. 问题定位
1.1 初步排查
首先，尝试在报文接收的位置打日志，发现没有报文过来。一路追踪至select函数没有触发。
ret=select(nfds,readfds,0,0,tv_ptr);随后，尝试不用gPTP的event和general的socket，而是用原始套接字（raw socket）来接收数据，但依然无法收到报文。
1.2 Wireshark抓包验证
为进一步确认问题，尝试在QNX开发板中未启动PTPD进程的情况下，使用以下指令进行抓包：
./tcpdump-c100-w./tmp.pcap在不同的主时钟启动方式下，抓包结果如下：
- 主时钟以gPTP方式启动：pcap文件中没有授时报文。
主时钟以PTP的UDP方式启动：pcap文件中有授时报文。
主时钟以PTP的L2方式（用数据链路层传输数据）启动：pcap文件中没有授时报文。
1.3 Linux环境对比
为了验证问题是否特定于QNX开发板，我在Linux开发板中进行了相同的测试，主时钟发gPTP报文，然后使用以下指令抓包：
./tcpdump-c100-w./tmp.pcap在Linux开发板中，可以抓到数据链路层的报文。由此可以判断，问题与QNX开发板中的PTPd无关，很可能是QNX开发板本身无法收到数据链路层的包。
2. 问题分析与解决
2.1 可能原因
分析认为数据链路层的报文是有到达QNX开发板的，但在底层没有被正确处理。可能的原因是驱动没有适配，最有可能的是网卡驱动没有开启混杂模式。
一般情况下，网卡往往只会接收目的MAC地址是它的数据包而不会接收目的MAC地址不是它的数据包。
混杂模式就是指网卡能接受所有通过它的数据流，无论是什么模式、什么地址的。当网卡处于这种“混杂”模式时，它对所有遇到的每一个数据帧都产生一个硬件中断，以提醒操作系统处理流经该物理媒体上的每一个报文包。
这样wireshark或者tcpdump就可以在数据链路层的报文看到gPTP的报文。
2.2 混杂模式测试
后来确认开启混杂模式时，能够收到gPTP数据链路层报文。具体操作如下：
用以下指令查看结果：
io320x00ff0c0004从右往左，从0开始，第4位，将其置为1，然后重新设置进去，使用以下指令：
io320x00ff0c0004 0x02B2045A
]
经过以上设置，可以看到QNX开发板和主时钟的gPTP报文交互正常。
3 结论
在QNX系统中运行PTPD进行gPTP同步时，若无法收到数据链路层的报文，建议开启混杂模式，并确认底层驱动的适配情况。
