使用Linux开源ptp遇到的项目问题

1：问题背景

1.1：问题概述
问题内容：项目中ECU作为Slave节点使用Gptp同步到Master节点ECU时间域，实车发现Slave节点同步Master节点时间域失败
预期现象：Slave节点同步Master节点时间域

2：原因分析

2.1：分析结果
ECU使用基于Linux的开源PTP源码
git clone git://git.code.sf.net/p/linuxptp/code linuxptp

【20221012】
上车排查，发现Gptp进程调试信息中有报错-rogue peer delay response，收到非法的Pdelay response，Gptp进程会重置用于同步的端口，导致无法继续同步

在Slave节点通过tcpdump抓取网卡报文，发现Master节点周期发送Pdelay_Resp和Pdelay_Resp_Follow_Up报文
正常应是Slave节点发送Pdelay_Req后，Master节点再响应Pdelay_Resp和Pdelay_Resp_Follow_Up报文

【20221012】
Master节点供应商反馈是switch中存在其他Slave节点发Pdelay_Req，Master节点会响应Pdelay_Resp，由于在Gptp在MAC层，所以本Slave节点也会收到其他节点的Pdelay_Resp

3：对策说明

3.1：对策内容
根据Pdelay_Resp和Pdelay_Resp_Follow_Up中的requestingSoucrePortIdentiy字段，过滤掉Master给其他Slave节点回复的Pdelay_Resp和Pdelay_Resp_Follow_Up
根据process_pdelay_resp的ClockIdentity字段和Master的MAC地址比对是否一致，过滤掉其他从节点给ECU回复的pdelay_resp报文

【20221014】
修改PTP源码：
源文件：port.c
函数名：process_pdelay_req
修改内容：在接收到Pdelay_Req报文时，直接返回，不回复Pdelay_Resp和Pdelay_Resp_Follow_Up

源文件：port.c
函数名：process_pdelay_resp
修改内容：
（1）指定自身的MAC地址，指定Master的MAC地址
（2）判断process_pdelay_resp的RequestingPortIdentity字段和自身的MAC地址是否一致（过滤掉Master给其他从节点回复的pdelay_resp报文），不一致直接Return
（3）判断process_pdelay_resp的ClockIdentity字段和Master的MAC地址是否一致（过滤掉其他从节点给我们回复的pdelay_resp报文）, 不一致直接Return
（4）满足条件的pdelay_resp即为我们想要的 resp报文


将自身MAC和Master MAC做成可配置项
源文件：config.c
结构体名：config_item config_tab[]
修改内容：新增ptp_master_mac，ptp_self_mac配置项

ptp进程启动时需指定配置文件，最终可以在配置文件添加该配置

源文件：raw.c
函数名：raw_open
修改内容：将新增的配置读取出来

源文件：raw.c
函数名：新增raw_Get_Master_Mac,raw_Get_Self_Mac
修改内容：新增接口获取配置的Master MAC和自身MAC

3.2：对策有效性验证（台架）
模拟实车工况，使用另外一个Slave节点模拟实车Gptp Slave节点，使用PC作为Gptp Master节点，配置文件写死Master Mac和自身MAC，运行修改源码后的PTP进程
结果为不再报rogue peer delay response错误，成功同步到Master时间域


3.3：对策有效性验证（实车）

实车验证也正常同步到Master时间域