[参考译文] AM6412：PTP：其他接口上的链路雕像更改会导致 PTP 同步丢失

您好 Dipal、

在我们的设计中、我们将 AM6412 与 DP83867 PHY 配合使用。 我们的产品 有两个以太网接口 eth0 和 eth1。  [/报价]

您能描述一下测试拓扑吗？ 您已将哪些设备连接到 eth0 和 eth1 端口？ 是线型还是环型拓扑？

是否对 eth0 和 eth1 使用 CPSW 以太网接口或 PRU_ICSSG 以太网接口？ （根据 PTP 日志输出、我假设两个接口都使用 CPSW 以太网？）

定制 AM6412 器件是服务 PTP 主站还是作为 PTP 跟随者？

您使用了哪些具体步骤和 Linux 命令来开始 PTP 测试？  

您是否可以共享完整的 PTP 日志（请使用插入>代码，而不是直接粘贴到响应中）？

-道林

尊敬的 Dipal：

感谢您提供这些更多详细信息。

此线程中的所有日志都基于 topo 2。

在运行 PTP 时、您是否尝试使用拓扑 2 测试某种以太网冗余方案？  

如果在运行 ptp4l 同步之前使 eth0 保持断开状态、会发生什么情况？  

DUT：   ptp4l –2 -P -H -i eth1  -m -q -l 7 -s

PC ： sudo ptp4l –2 -P -H -i enp8s0 -m -q -l 7.

[/报价]

使用这些 ptp4l 选项时、如果断开 eth1 而不是 eth0、您是否会看到类似的日志输出？ 如果可能、您是否还可以显示此案例的日志？ 我假设 会出现“port1 (eth1)：Delay timeout“、而不是“port0 (eth0)：Delay timeout“之类的内容？

您是否尝试过使用 “ptp4l –2 -P -H -I eth0 -i eth1 -m -q -l 7 -s“（对于 DUT）和“sudo ptp4l –2 -P -H  -i enp6s0 -i enp8s0 -m -q -l 7“用于 PC？

-道林

尊敬的 Dipal：

我们不是试图给我们任何冗余、enp6s0 - eth0 在 PTP 中没有器件 ,我只是做了这个拓扑,所以它是很容易测试。 不过、我们已经观察到 topo 1 中也有相同的行为、即使 eth0 和 eth1 连接到完全不同的器件也是如此。  [/报价]

感谢您的澄清

如果 eth1 断开连接、PTP 从不会恢复（没有与 eth0 相关的消息）、请在下面找到主从器件 (DUT) 的日志对于此场景、请选中“<< <" for annotations.

这对我来说有点困惑。 我的印象是在 ptp4l 配置中使用 eth1、因此 eth1 是保持 PTP 同步运行所需的接口、问题在于 eth0（与 PTP 配置无关）断开（不是 eth1 断开连接）。  

如果在运行 ptp4l 同步之前使 eth0 保持断开连接、会发生什么情况？  [/报价]

如果您这样做、确保在整个测试过程中保持 eth1 连接、会发生什么情况？

-道林

[/quote]

尊敬的 Daolin：

这对我来说有点困惑。 我的印象是在 ptp4l 配置中使用 eth1、因此 eth1 是保持 PTP 同步运行所需的接口、问题在于 eth0（与 PTP 配置无关）断开（不是 eth1 断开连接）。  [/报价]

根据你在前一个答复中提出的请求（引述如下）、我虽然希望我通过断开 eth1 进行检查？ 但是、它发现 PTP 永远不会恢复的新问题。

使用这些 ptp4l 选项、如果 eth1 而不是 eth0 断开连接、您是否会看到类似的日志输出？ 如果可能、您是否还可以显示此案例的日志？ 我假设不是 “port1 (eth1)：Delay timeout“、而是会显示“port0 (eth0)：Delay timeout“之类的内容？

如果我们将 eth0 接口与 eth1 交换、则行为完全相似、我们可以在所有日志中相应地替换 eth0 <->eth1。  

这里是我们的原始问题的总结:

1. 在启动 PTP 之前、eth0 物理断开
   1. 在 eth1 上启动 PTP、确保其工作正常
   2. 重新连接 Eth0 电缆
   3. eth0 重新联机  
   4. PTP 在 eth1 上停止工作
2. 在启动 PTP 之前、eth0 已连接并启动
   1. 在 eth1 上启动 PTP、确保其工作正常
   2. 断开连接的 eth0
   3. PTP 在 eth1 上停止工作
   4. 重新连接 eth0
   5. PTP 在 eth1 上仍然不起作用

如果我们将 eth0 与 eth1 交换、我们将观察到相同的行为（即 eth1 状态将停止 eth0 上的 PTP 操作）。  

对于这些场景、如果我执行以下任一操作、PTP 将开始工作

1. 重新启动 PTP
2. 运行 “ifconfig eth1 up“（请注意，它是 eth1、这个接口已经启动并且 PTP 同步工作）
3. 打开 Promiscuous 模式 “IP link set eth1 promisc on“

---

现在当我尝试改变 eth1 本身的状态（PTP 正在运行）时、我们发现了另一个问题 ( eth0 在此场景中没有任何作用 )：

1. 通过更改 eth1 状态 物理上断开 t 他的电缆
   1. 在 eth1 上启动 PTP、确保其工作正常
   2. 物理断开 eth1 电缆  
   3. 等待 1 分钟 （由于电缆断开连接，PTP 将不工作）
   4. 重新连接 ETH1 电缆
   5. PTP 同步已恢复  
   6. 这里的一切都按预期运行
2.  更改 eth1 状态 通过 CLI（电缆保持连接） ：
   1. 在 eth1 上启动 PTP、确保其工作正常
   2. 使用 CLI“ifconfig eth1 down“关闭 eth1 接口
   3. 等待 1 分钟 （由于电缆断开连接，PTP 将不工作）
   4. 使用 CLI“ifconfig eth1 up“打开 eth1 接口
   5. PTP 从不恢复（这是我上次回复中报告的问题）
   6. 使 PTP 再次工作的唯一方法是重新启动 PTP 过程、 接口状态、混杂模式不起作用

[/quote]

尊敬的 Dipal：

根据你在前一个答复中提出的请求（引述如下）、我虽然希望我通过断开 eth1 进行检查？ 但是、它发现 PTP 永远不会恢复的新问题。

邱道林说：

使用这些 ptp4l 选项时、如果断开 eth1 而不是 eth0、您是否会看到类似的日志输出？ 如果可能、您是否还可以显示此案例的日志？ 我假设 会出现“port1 (eth1)：Delay timeout“、而不是“port0 (eth0)：Delay timeout“之类的内容？

我看,有一个误解。 我的意思是、如果您可以使用“ptp4l –2 -P -H -i“ eth0  -m -q -l 7 -s“并断开 eth1 并准确显示日志。 我知道您已经说过、如果切换了接口、行为是类似的、但我也想看到切换情况下的日志。

感谢您明确了观察您指定的各种问题的步骤顺序。 eth0 和 eth1 接口是在双 Mac 模式下还是配置为交换机？

如果我能重现问题、我将尝试在我的身边进行尝试、很可能直到星期五才会出现此问题。 如果我没有在星期五上回复、请 ping 此主题。

-道林

尊敬的 Dipal：

我还需要在我这边进行测试 但是、我从您的日志中看到“eth0 已（再次）在此处“。 这让我感到困惑,因为有人告诉我, eth1 是被造下来和备份的。 不过、需要说明的是、在上面的日志中只有 eth1 断开连接、并且 eth0 始终保持连接？

-道林

尊敬的 Daolin：

您的理解是正确的、eth0 始终正确。  简而言之、“ipconfig eth0 up“（即使 eth0 接口已经启动）会执行使 PTP 数据包再次流动的操作。  

情况就是这样

1. eth0 启动并且 PTP 按预期工作、eth1 也在此状态下启动
2. eth1 链路状态从“向上“更改为“向下“-> PTP 在 eth0 上停止工作
3. eth1 链路状态从向下更改为向上-> PTP 在 eth0 上仍然不起作用
4. 现在、如果您运行“ ifconfig eth0 up “我们看到 PTP 同步再次发生（eth0 接口始终启动、此命令是冗余的、但它使 PTP 再次工作、而无需重新启动 PTP 过程。） 如您所述、我们没有看到任何与 eth0 相关的日志、但 PTP 开始工作。

在上述步骤 2 之后、可以通过以下方法使 PTP 再次工作  

1. 运行“ifconfig eth0 up“
2. 运行“IP 链路集 eth0 promisc on“
3. 停止 DUT 上的 PTP 过程、然后重新开始。

我的分析是 ALE 中有一些配置可以阻止 PTP 多播数据包到达 CPU、并且这些命令纠正了这种配置、这就是为什么启用了混杂模式时、我们不会看到此问题、因为 ALE 不会丢弃任何内容。  

希望现在已经很清楚了。

此致

-迪帕尔

尊敬的 Daolin：

感谢您的检查和更新、我将尝试使用最新的内核、我将需要几天时间来继续此。

同时、如果您还可以验证以下场景、这将非常有用。

现在当我尝试改变 eth1 本身的状态（PTP 正在运行）时、我们发现了另一个问题 ( eth0 在此场景中没有任何作用 )：

1. 通过更改 eth1 状态 物理上断开 t 他的电缆
   1. 在 eth1 上启动 PTP、确保其工作正常
   2. 物理断开 eth1 电缆  
   3. 等待 1 分钟 （由于电缆断开连接，PTP 将不工作）
   4. 重新连接 ETH1 电缆
   5. PTP 同步已恢复  
   6. 这里的一切都按预期运行
2.  更改 eth1 状态 通过 CLI（电缆保持连接） ：
   1. 在 eth1 上启动 PTP、确保其工作正常
   2. 使用 CLI“ifconfig eth1 down“关闭 eth1 接口
   3. 等待 1 分钟 （由于电缆断开连接，PTP 将不工作）
   4. 使用 CLI“ifconfig eth1 up“打开 eth1 接口
   5. PTP 从不恢复（这是我上次回复中报告的问题）
   6. 使 PTP 再次工作的唯一方法是重新启动 PTP 过程、 接口状态、混杂模式不起作用

此致、

-迪帕尔

尊敬的 Daolin：

非常感谢您查看该内容

注意：我使用了“ip link set dev eth1 down/up“而不是“ifconfig eth1 down/up“、因为 ip 命令（来自 iproute2 软件包）是要使用的最新命令。 Linux 中的 ifconfig 不再是可使用的最新命令。

这是正常和正确的。

我会让你从我这边公布进展情况。

此致、

-迪帕尔

尊敬的 Daolin：

我们仍在研究这个问题、我将在办公室外工作一周、因此我们将在本月底向您提供最新信息。

此致、

-迪帕尔

尊敬的 Dipal：  

感谢您的 当前更新。

附注：如果预计有任何最后期限来解决您的问题、请告知我、以便我做好充分准备。

-道林

尊敬的 Dipal：

回顾我的共享日志、从器件上似乎显示了以下场景的最大偏移消息。

• 通过更改 eth1 状态 物理上断开 t 他的电缆
  1. 在 eth1 上启动 PTP、确保其工作正常
  2. 物理断开 eth1 电缆  
  3. 等待 1 分钟 （由于电缆断开连接，PTP 将不工作）
  4. 重新连接 ETH1 电缆
  5. PTP 同步已恢复  
  6. 这里的一切都按预期运行
•  更改 eth1 状态 通过 CLI（电缆保持连接） ：
  1. 在 eth1 上启动 PTP、确保其工作正常
  2. 使用 CLI“ifconfig eth1 down“关闭 eth1 接口
  3. 等待 1 分钟 （由于电缆断开连接，PTP 将不工作）
  4. 使用 CLI“ifconfig eth1 up“打开 eth1 接口
  5. PTP 从不恢复（这是我上次回复中报告的问题）
  6. 使 PTP 再次工作的唯一方法是重新启动 PTP 过程、 接口状态、混杂模式不起作用

[/报价]

对于另一种情况（下面引用）、我可以看到断开连接后缺少最大偏移消息。  

[报价 userid=“595428" url="“ url="~“~/support/processors-group/processors/f/processors-forum/1468209/am6412-ptp-link-statue-change-on-other-interface-results-in-ptp-sync-loss/5646536 #5646536“]

情况就是这样

1. eth0 启动并且 PTP 按预期工作、eth1 也在此状态下启动
2. eth1 链路状态从“向上“更改为“向下“-> PTP 在 eth0 上停止工作
3. eth1 链路状态从向下更改为向上-> PTP 在 eth0 上仍然不起作用

[/报价]

另一个要尝试的测试是使用“ptp4l -P –2 -H -i eth0 -f gPTP.cfg --step_threshold=1 -m -q -p /dev/ptp0、其中 gPTP.cfg 如下所示。 对于主设备、将“priority1"设置“设置为 100；对于从设备、将“priority1"设置“设置为 240。 当您尝试上述两种情况时会发生什么情况？ 您是否仍然看到相同的问题？

# 802.1AS example configuration containing those attributes which
# differ from the defaults.  See the file, default.cfg, for the
# complete list of available options.
#
[global]
gmCapable               1
priority1               100
priority2               248
logAnnounceInterval     0
logSyncInterval         -3
syncReceiptTimeout      3
neighborPropDelayThresh 800
min_neighbor_prop_delay -20000000
assume_two_step         1
path_trace_enabled      1
follow_up_info          1
transportSpecific       0x1
ptp_dst_mac             01:80:C2:00:00:0E
network_transport       L2
delay_mechanism         P2P

 

您能否在您的设置中对此进行一次验证、如果您以日志级别 6 运行 PTP 跟随者、验证会更容易吗？  [/报价]

明天我将尝试测试。 我明天还将尝试检查 ethtool 丢弃计数器。

-道林

[/quote]

尊敬的 Dipal：

您是否可以试用最新的 SDK 10.1？ 这将是内核版本 6.6。

您是否能够试用 SDK 10.1？ 我假设在此 SDK 版本上观察到了最近的行为？

我明天会尝试测试一下。 明天我还会尝试检查 ethtool 丢弃计数器。

我对它进行了测试、并看到与您的日志类似的结果。 对于 ethtool 丢弃计数器、我注意到只要发生链路建立事件、即使 PTP 未运行、也是如此。 以下是我可以从 AM64x TRM 中找到的一些端口掩码丢弃和 ALE 丢弃信息。 我认为这些不是 PTP 特有的问题。

要尝试的另一项测试是使用“ptp4l -P –2 -H -i eth0 -f gPTP.cfg --step_threshold=1 -m -q -p /dev/ptp0、其中 gPTP.cfg 如下所示。 对于主设备、将“priority1"设置“设置为 100；对于从设备、将“priority1"设置“设置为 240。 当您尝试上述两种情况时会发生什么情况？ 您仍然看到相同的问题吗？

我测试了这种 PTP 配置、当 eth1 断开时、似乎没有出现同样的 PTP 同步丢失问题。 这可能是一个解决方案、您可以尝试一下。

-道林

尊敬的 Daolin：

非常感谢详细信息、很遗憾、我仍然坚持使用 TI AM64-SK 上的内核版本 5.10（我不确定 SDK 版本）、我的 AM64-SK 无法使用最新的 SDK 启动、我们购买了新的 AM64-SK 以加快速度。

在我们的定制设计中、我们使用主线内核版本 6.1.80、这也是我尝试更新到 6.6+、它也能在程序中正常工作。

尽管如此、还是取得了一些进展：

以下命令和配置文件可以防止出现该问题：

ptp4l -P –2 -H -i eth0 -f gPTP.cfg --step_threshold=1 -m -q -p /dev/ptp0

调试后、我发现有助于解决问题的主配置是  

PTP_DST_Mac        01：80：C2：00：00：0E

如果 我删除此项并保持所有内容不变、我仍然会看到问题。

我需要进行更多测试、以确保可以使用此权变措施。

此致、

-迪帕尔

P.S.我需要改变  Neighborhood PropDelayThresh 到 4000、在我的配置中、如果没有这种 PTP 同步、我的设置中永远不会建立。

尊敬的 Dipal：

以下命令和配置文件可以防止出现该问题：

ptp4l -P –2 -H -i eth0 -f gPTP.cfg --step_threshold=1 -m -q -p /dev/ptp0

调试后、我发现有助于解决问题的主配置是  

PTP_DST_Mac        01：80：C2：00：00：0E

如果 我删除此项并保持所有内容不变、我仍然会看到问题。

我需要进行更多测试、以确保可以使用此权变措施。

感谢您分享这段信息。 如果尚未看到、 ptp4l 手册页将“PTP_DST_MAC"描述“描述为“PTP 报文应发送到的 MAC 地址“。 仅与 L2 传输相关。 默认值为 01：1B：19：00：00：00。“ 我猜由于使用了“-2"选项–2选项，“，因此、因此“PTP_DST_MAC"是“是必需的配置。 您看到的问题表明默认的 PTP_DST_Mac 是潜在问题、可能需要具体检查 01：1B：19：00：00：00 MAC 地址是什么。

P.S. 我需要改变  Neighborhood PropDelayThresh 从配置中的 800 到 4000、如果没有此 PTP 同步、我的设置中永远不会建立。

这很有趣、可能值得研究此配置的含义。 根据手册页、在使用 802.1AS 时是相关的、由配置为 0x1 的“transportSpecific"选择“选择。

如果您还有其他问题、敬请告知。

-道林

尊敬的 Daolin：

我们注意到这个问题也与 systemd-networkd 紧密耦合,在我们使用 NetworkManager 的配置中。

我在以下场景中再次发现了这一问题  

1.我们不使用任何网络管理器,即 systemd-networkd 和 NetworkManager 都被禁用

2.我们使用 NetworkManager 来管理接口配置。

我还尝试将 NetworkManager 配置为未改编的接口、从而将其配置为忽略 eth1 接口  

unmanaged-devices=interface-name:eth1 


通过在 AM64-SK 上禁用 systemd-networkd 可以对此进行测试。 

由于我们需要使用 NetworkManger、是否有任何已知问题或建议来解决此问题？

此致、

-迪帕尔

尊敬的 Dipal：

我们注意到这个问题也与 systemd-networkd 紧密耦合,在我们使用 NetworkManager 的配置中。

我在以下场景中再次发现了这一问题  

1.我们不使用任何网络管理器,即 systemd-networkd 和 NetworkManager 都被禁用

[/报价]

为了澄清、您看到哪个 ptp4l 命令存在问题？ 也就是说、使用 gPTP.cfg 的协议还是您之前使用的协议（不使用 gptpt.cfg）？

-道林

gPTP.cfg 上的 ptp4l 出现问题

ptp4l -P –2 -H -i eth0 -f gPTP.cfg --step_threshold=1 -m -q -p /dev/ptp0

您好 Dipal、

由于我们需要使用 NetworkManger、是否有任何已知问题或建议来解决此问题？

遗憾的是、由于我们似乎没有在 Linux SDK 上使用 NetworkManager、因此我们不知道如果 systemd-networkd 未运行、就会出现此问题。  

我建议看看 NetworkManager 和 systemd-networkd 之间的区别,看看它处理被丢弃和重新连接的链路的方式是否有任何区别,看看 NetworkManager 是否有一种与 systemd-networkd 相同的方式。  

您必须使用 NetworkManager 而不是 systemd-networkd 的特殊原因是否存在？

-道林

尊敬的 Daolin：

我们正在使用 NetworkManager、因为它可以帮助我们更好地处理客户所需的不同网络配置。

根据我的调查、根本原因是当任何一个接口经历状态更改时、这些接口上的多播被禁用。

1. systemd-networkd:它的工作原理是因为 systemd-networkd 在接口状态发生更改时专门为 PTP 多个地址 (01:80:C2:00:00:0E) 添加成员身份。  
2. 在接口上运行“ip link set dev ethX up“或“ifconfig ethX up“启用的 IP 多播、类似于运行“ip link set dev eth1 multicast On“

遗憾的是、我们在接口状态下看不到这一点（当丢包时，组播始终显示为启用）

root@ptp_test:~# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 54:3b:30:01:18:ee brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 54:3b:30:01:18:ef brd ff:ff:ff:ff:ff:ff
root@smartnc:~# 

通过如下所示配置 PTP muticast 地址的静态条目、我设法使其与 NetworkManger（或可能独立于任何网络管理）配合使用、我仍然需要为两个接口进行配置、即使我仅在一个接口上运行 PTP。

ip link set dev eth0 down
ip link set dev eth1 down
ip maddr add 01:80:c2:00:00:0e dev eth0
ip maddr add 01:80:c2:00:00:0e dev eth1
ip link set dev eth0 up
ip link set dev eth1 up

我认为 TI 驱动程序在处理方面仍有缺失/可以改进。

此致、

-迪帕尔

您好 Dipal、

 “我不会告你的,因为我不会告你的。“ 如果您没有收到回复、请在 4 月初对该线程执行 ping 操作。

此致、

Nick

您好、Nick、

感谢您的更新。

此致、

-迪帕尔

尊敬的 Daolin：

我觉得 TI 驱动程序处理这一问题的方式仍然存在缺失/可以加以改进。

您是否深入研究了这一点、该问题不仅限于 PTP 多播、还适用于其他多播数据包。 一旦链路状态改变、多播数据包流就会停止。

由于多路广播应用程序可以使用任何多路广播地址、我们将无法为所有这些地址添加静态条目（听起来也不正确）。

要提醒和 提示：启用 Promiscuous 模式可防止所有这些问题。

如果您需要更多信息、请告诉我。

此致、

-迪帕尔

尊敬的 Dipal：

您是否深入研究了这一点、该问题不仅限于 PTP 多播、还适用于其他多播数据包。 一旦链路状态改变、多播数据包流就会停止。

感谢您对此问题的耐心等待。 遗憾的是、我没有机会进一步了解您的调查结果。 明天我将尝试更深入地研究它、并以更新进行响应。

-道林

尊敬的 Dipal：  

调试后、我发现有助于解决问题的主配置是  

PTP_DST_Mac        01：80：C2：00：00：0E

如果 我删除此项并保持所有内容不变、我仍然会看到问题。

您之前提到过、删除此 PTP 配置后、仍然会看到问题。 我想知道这种配置是否在您提到的 PTP 多播地址问题中起着重要作用。 是否仍保持这种 PTP 配置不适合您的应用？

我觉得 TI 驱动程序处理这一问题的方式仍然存在缺失/可以加以改进。

由于 TI SDK 不实现 NetworkManager、而是使用 systemd-networkd、并且使用 NetworkManager 只是您应用的一项要求、因此我们不会在尝试更改 TI 软件以支持客户特定的应用时提供特定支持。  

该问题不仅限于 PTP 多播、还适用于其他多播数据包。 链路状态更改后、多播数据包流停止

您能否共享发现链路状态变化问题的非 PTP 多播数据包情况的日志？

-道林  

您之前提到过、通过删除此 PTP 配置、您仍然会看到该问题。 我想知道这种配置是否在您提到的 PTP 多播地址问题中起着重要作用。 是否保留此 PTP 配置不适合您的应用？

我们需要保留此配置、因为它是 gPTP 配置文件的一部分。

由于 TI SDK 未实现 NetworkManager、而是使用 systemd-networkd、并且您的应用只需要使用 NetworkManager、因此我们不对尝试更改 TI 软件以支持客户特定的应用提供特定支持。

从一开始我就怀疑组播处理/Mac 学习存在基本问题 ,我认为 NetworkManger 只是暴露了这个问题,但没有引入。  

有多种症状表明了这一点。  

1.计数器,它清楚地表明包是由 ALE 丢弃的

ale_drop：1807 年
RX_PORT_MASK_DROP：1807

2. 打开混杂模式解决了以下问题：在这种情况下、ALE 过滤被关闭。  

3.“ IP LINK SET DEV ETH1 多播开启 “这也解决了问题。  

当我提到 TI 驱动程序中缺少一些内容时、我指的是这部分、我认为它不依赖于网络管理器。

即使使用 systemd 联网、如果您不使用 gPTP 配置文件、此操作也会失败、您是否认为这是一个问题？

我将分享其他突变案件的日志,希望这应该说明清楚。

此致、

Dipal

尊敬的 Dipal：

如果这确实是一个与 PTP 和 NetworkManager 应用程序的特定用例无关且与一般多播处理相关的问题、那么我们必须解决这一问题。 但是、作为第一步、我还需要看到测试环境中基本多播测试（没有任何 PTP 运行）发生的问题。 这就是为什么我要求提供日志以及是否可以共享您为测试它是否也适用于其他多播数据包而采取的步骤。 这将帮助我尝试重现问题、特别是表明如果没有 PTP、问题仍然存在、所以如果 CPSW 驱动程序确实有问题、我可以在内部讨论问题所在。

即使使用 systemd 联网、如果您不使用 gPTP 配置文件、也会失败、您认为这不是问题吗？

根据我的理解、我们仅在我们的器件上测试了一项非常基本的 PTP 测试、很可能不包括您在此处测试时断开和重新连接另一个接口。 我们测试过的唯一 PTP 配置是我分享的 gPTP 配置文件、因为我是测试它的主要人员。 但是、由于您提到根本原因可能是一个与 PTP 是否正在运行无关的一般多播问题、如果我可以获得更多有关能够查看这一点的详细信息、我将能够在内部获得更多帮助、以了解问题是否是 CPSW 驱动程序问题。

-道林  

尊敬的 Daolin：

是的,我正在尝试为一般的多播问题创建一个最小的应用程序,可能需要一些时间共享它。

此致、

-迪帕尔

尊敬的 Daolin：

我能够通过简单的多播 ping 生成此问题。  

硬件设置：

软件版本：

SDK：11.00.09.04
内核：6.12.17-ti-RT-00771-gc85877d40f8e
硬件：SK-AM64B

生成通用多播问题的步骤

1. 启用组播 ping

sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=0

2.加入多播组并验证组成员身份

ip addr add 224.10.10.10/24 dev eth1 autojoin
ip maddr show dev eth1

3. 从对等方 ping 多播组 IP：

ping -i enp8s0  224.10.10.10

4.更改其它接口的状态（此设置中的 eth0）

ip link set dev eth0 down

5.遵守这一点  

• 在对等器件/Wireshark 上、ping 响应停止
• 丢弃计数器正在递增
• root@：~# ethtool -S eth1 | grep drop | grep -v 0
  第 61 章
  RX_PORT_MASK_DROP：61.

分辨率保持不变、以下步骤之一可以恢复 ping 响应

1. 启用多播“IP link set dev eth1 multicast On“  
2. 再次强制链路接通（即使已经接通）“IP link set dev eth1 up“
3. 启用混杂模式：“IP link set dev eth1 multicast On“
4. 配置静态组成员资格（在 eth0 和 eth1 上都需要）“ip maddr add 01：00：5e：0A：0A dev eth0“和“ip maddr add 01：00：5e：0A：0A dev eth1“  

也请从我的设置中找到附加的日志。

1. Enable icmp echo for multicast

    root@am64b_sdk11:~# sysctl net.ipv4.icmp_echo_ignore_broadcasts
    net.ipv4.icmp_echo_ignore_broadcasts = 1
    root@am64b_sdk11:~# sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=0
    net.ipv4.icmp_echo_ignore_broadcasts = 0
    root@am64b_sdk11:~# sysctl net.ipv4.icmp_echo_ignore_broadcasts
    net.ipv4.icmp_echo_ignore_broadcasts = 0

2. Join multicast group
    root@am64b_sdk11:~# ip maddr show dev eth1
    3:      eth1
    		link  01:00:5e:00:00:01
    		inet  224.0.0.1
    root@am64b_sdk11:~# 
    root@am64b_sdk11:~# ip addr add 224.10.10.10/24 dev eth1 autojoin
    root@am64b_sdk11:~# ip maddr show dev eth1
    3:      eth1
    		link  01:00:5e:00:00:01
    		link  01:00:5e:0a:0a:0a                                   <<< New group
    		link  01:00:5e:00:00:fc
    		link  01:00:5e:00:00:fb
    		inet  224.0.0.251
    		inet  224.0.0.252
    		inet  224.10.10.10                                        <<< New group
    		inet  224.0.0.1
    root@am64b_sdk11:~# ip addr show dev eth1
    3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
        link/ether 54:3b:30:01:18:ef brd ff:ff:ff:ff:ff:ff
        inet 224.10.10.10/24 scope global autojoin eth1
           valid_lft forever preferred_lft forever
        inet 192.168.1.20/24 scope global eth1
           valid_lft forever preferred_lft forever


3. Change link state of eth0
    root@am64b_sdk11:~# ip link set dev eth0 down
    root@am64b_sdk11:~# [ 1968.291443] am65-cpsw-nuss 8000000.ethernet eth0: Link is Down

4. Observe drop counters

	root@am64b_sdk11:~# ethtool -S eth1 | grep drop | grep -v 0
	 ale_drop: 8
	 rx_port_mask_drop: 8
	root@am64b_sdk11:~# ethtool -S eth1 | grep drop | grep -v 0
	 ale_drop: 11
	 rx_port_mask_drop: 11
	 
5. Enable mutlicast on eth1 to resume packet flow

    root@am64b_sdk11:~# ip link set dev eth1 multicast on
	root@am64b_sdk11:~# ethtool -S eth1 | grep drop | grep -v 0
	 ale_drop: 21
	 rx_port_mask_drop: 21
	root@am64b_sdk11:~# ethtool -S eth1 | grep drop | grep -v 0
	 ale_drop: 21
	 rx_port_mask_drop: 21

除了 具有最新 SDK 的 SK-AM64B 外、我还可以在我们的硬件上看到该问题。

希望这足以让您对多播进行一般性的调查、如果您需要任何其他信息、请告诉我。

此致、

-迪帕尔

P.S.检查 mutlicast 流量的指令取自 gist.github.com/.../2597c23c68f21d938779aa92683d30b2。

尊敬的 Dipal：

非常感谢您分享有关如何使用简单的多播 ping 重现问题的详细步骤。  

3. 从对等方 ping 多播组 IP：

ping -i enp8s0  224.10.10.10

我实际上遇到了上述步骤的问题、无法从主机 PC ping SK-AM64B EVM 以进行测试。 我注意到 ping 的“-i"选项“选项实际上指定了每个数据包之间的秒间隔、因此我将其更改为“-i"，“，指定、指定了接口名称。 即使在那之后、ping 也会挂起。 有关详细信息、请参阅以下内容：

测试设置：

SK-AM64B eth1 <-->以太网交换机<--> enp3s0 主机 Ubuntu PC  

SK-AM64B eth0 <-->（由于主机 Ubuntu PC 上没有另一个接口，因此另一个器件 — 目的只是获取待连接的链路状态）

来自 SK-AM64B 的日志：

root@am64xx-evm:~# ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
       inet6 fe80::1e63:49ff:fe1a:d2a9 prefixlen 64 scopeid 0x20<link>
       ether 1c:63:49:1a:d2:a9 txqueuelen 1000 (Ethernet)
       RX packets 0 bytes 0 (0.0 B)
       RX errors 0 dropped 0 overruns 0 frame 0
       TX packets 16 bytes 2680 (2.6 KiB)
       TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
       inet 172.168.1.21 netmask 255.255.255.0 broadcast 172.168.1.255
       inet6 fe80::72ff:76ff:fe1f:42ef prefixlen 64 scopeid 0x20<link>
       ether 70:ff:76:1f:42:ef txqueuelen 1000 (Ethernet)
       RX packets 6 bytes 926 (926.0 B)
       RX errors 0 dropped 0 overruns 0 frame 0
       TX packets 31 bytes 4605 (4.4 KiB)
       TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
       inet 127.0.0.1 netmask 255.0.0.0
       inet6 ::1 prefixlen 128 scopeid 0x10<host>
       loop txqueuelen 1000 (Local Loopback)
       RX packets 10 bytes 1594 (1.5 KiB)
       RX errors 0 dropped 0 overruns 0 frame 0
       TX packets 10 bytes 1594 (1.5 KiB)
       TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

root@am64xx-evm:~# [  21.473976] platform led-controller: deferred probe pending: leds-gpio: Failed to get GPIO '/led-controller/led-0'
[  21.473999] platform 20000000.i2c: deferred probe pending: (reason unknown)

root@am64xx-evm:~# sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=0
net.ipv4.icmp_echo_ignore_broadcasts = 0
root@am64xx-evm:~# ip addr add 224.10.10.10/24 dev eth1 autojoin
root@am64xx-evm:~# ip maddr show dev eth1
3:     eth1
       link 33:33:00:00:00:01
       link 01:00:5e:00:00:01
       link 01:80:c2:00:00:0e users 2 static
       link 01:80:c2:00:00:03 users 2 static
       link 01:80:c2:00:00:00 users 2 static
       link 33:33:ff:1f:42:ef
       link 01:00:5e:00:00:fb
       link 33:33:00:00:00:fb
       link 01:00:5e:0a:0a:0a
       inet 224.10.10.10
       inet 224.0.0.251
       inet 224.0.0.1
       inet6 ff02::fb
       inet6 ff02::1:ff1f:42ef
       inet6 ff02::1 users 2
       inet6 ff01::1
root@am64xx-evm:~# ifconfig eth1
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
       inet 172.168.1.21 netmask 255.255.255.0 broadcast 172.168.1.255
       inet6 fe80::72ff:76ff:fe1f:42ef prefixlen 64 scopeid 0x20<link>
       ether 70:ff:76:1f:42:ef txqueuelen 1000 (Ethernet)
       RX packets 7 bytes 986 (986.0 B)
       RX errors 0 dropped 0 overruns 0 frame 0
       TX packets 49 bytes 6758 (6.5 KiB)
       TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
root@am64xx-evm:~# ethtool eth1 | grep "Link detected"
       Link detected: yes
root@am64xx-evm:~# ethtool eth1 | grep "Link detected"                                                                                                                                                     
       Link detected: yes
root@am64xx-evm:~# uname -a
Linux am64xx-evm 6.12.17-ti-rt-00771-gc85877d40f8e #1 SMP PREEMPT_RT Tue Mar 25 12:45:29 UTC 2025 aarch64 GNU/Linux

来自 Ubuntu 主机 PC 的日志：

~$ ping -I enp3s0 172.168.1.21
PING 172.168.1.21 (172.168.1.21) from 172.168.1.1 enp3s0: 56(84) bytes of data.
64 bytes from 172.168.1.21: icmp_seq=1 ttl=64 time=0.604 ms
64 bytes from 172.168.1.21: icmp_seq=2 ttl=64 time=0.448 ms
64 bytes from 172.168.1.21: icmp_seq=3 ttl=64 time=0.440 ms
^C
--- 172.168.1.21 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2068ms
rtt min/avg/max/mdev = 0.440/0.497/0.604/0.075 ms
~$ ping -I enp3s0 224.10.10.10
PING 224.10.10.10 (224.10.10.10) from 172.168.1.1 enp3s0: 56(84) bytes of data.
^C
--- 224.10.10.10 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2064ms

即使没有以太网交换机连接、此步骤似乎也失败。 我检查了使用已分配给 eth1 端口的非多播 IP 地址时、从主机到 SK-AM64B 的 ping 是否正常工作。 是否缺少任何使您的设置可以用于此步骤的步骤？

我还有另一个问题：您的 eth0 到 enp6s0 连接是否在每个接口上都有 IP 地址？还是只是链路连接？

-道林

尊敬的 Daolin：

它不适用于以太网交换机（除非我们在其上启用多播切换）、因此 建议您使用直接连接进行检查。  

我还有另一个问题：您的 eth0 到 enp6s0 连接是否在每个接口上都有 IP 地址？还是只是链路连接？

-道林

我在 eth0 链路上使用和不使用 IP 地址进行了测试。 这无关紧要。

您是否为如下所示的广播启用了 ICMP ECHO？

sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=0

我相信这很可能是原因。

编辑： 我交叉检查了 ping 参数、它确实是大写“-I"，“，如果、如果未指定此选项、ping 将失败。  以下是我的设备的日志（请注意，响应仍然是单播 IP 的单播）。

❯ ping -I enp8s0 224.10.10.10
PING 224.10.10.10 (224.10.10.10) from 192.168.1.99 enp8s0: 56(84) bytes of data.
64 bytes from 192.168.1.20: icmp_seq=1 ttl=64 time=0.334 ms
64 bytes from 192.168.1.20: icmp_seq=2 ttl=64 time=0.366 ms
64 bytes from 192.168.1.20: icmp_seq=3 ttl=64 time=0.383 ms
64 bytes from 192.168.1.20: icmp_seq=4 ttl=64 time=0.387 ms
64 bytes from 192.168.1.20: icmp_seq=5 ttl=64 time=0.375 ms
64 bytes from 192.168.1.20: icmp_seq=6 ttl=64 time=0.378 ms
64 bytes from 192.168.1.20: icmp_seq=7 ttl=64 time=0.354 ms
64 bytes from 192.168.1.20: icmp_seq=8 ttl=64 time=0.351 ms
^C
--- 224.10.10.10 ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7164ms
rtt min/avg/max/mdev = 0.334/0.366/0.387/0.017 ms

此致、

-迪帕尔

尊敬的 Dipal：

它不能与以太网交换机一起使用（除非我们在其上启用多播切换）、因此 我建议您通过直接连接进行检查。  

即使没有以太网交换机连接、此步骤似乎失败。

是的、我后来在中间没有使用以太网交换机的情况下尝试了、但该步骤对我来说仍然失败。

您是否为以下广播启用了 ICMP echo？

是的、正如我在上一个响应中分享的日志所示、我确实确保 ICMP 回显已启用。

关于您观察到的这个组播问题、我怀疑的一件事就是您正在使用的测试拓扑。 虽然不直接相关、但当 DUT（受测器件）上的两个处于双 MAC 模式的以太网端口直接连接到另一个器件的两个以太网端口、并且 DUT 上 两个端口的 IP 地址配置为同一子网时、在两个器件之间执行 ping 操作会出现问题。 这与 ARP 数据包是一个广播数据包有关、在某些情况下会导致找到错误的以太网接口的 MAC 地址。 在这种情况下、由于 ARP 广播会返回错误的 MAC 地址、因此每个 ping 应答都会有错误的目的 MAC 地址、从而导致 ping 数据包丢失。

因此、我们建议不要连接您在此方框图中所示的器件。 相反、您能否尝试使用连接到 AM64x 器件的 eth0 和 eth1 的不同器件来测试此多播用例？ 例如、使 Ubuntu PC 保持连接到 eth0、并将多个数据包从 PC 发送到 AM64x 器件、而对于 eth1、则连接到另一个已知正常工作的 PC 或 EVM、确保未配置 IP 地址。

-道林

您好、

 最初在您建议的拓扑上观察到多播和 PTP 问题、这只是我的测试设置。 即使是 PTP、我们也在两种拓扑上尝试过它、但在所有拓扑上都失败。 我们已经按照之前的报告测试了 PTP。

1.我们在以下两种拓扑中对此进行了测试（蓝盒是测试中的设备）,本线程中的所有日志都基于 topo 2。

Topo 1：  

Topo 2：

[/报价]

然而、 我将与使用 Topo1 运行最新 SDK 的 AM64-SK 共享新日志。

此致、

-迪帕尔

尊敬的 Dipal：

 最初在您建议的拓扑上发现了多播和 PTP 问题、这只是我的测试设置。 即使是 PTP、我们也在两种拓扑上尝试过它、但在所有拓扑上都失败。 我们已经按照之前的报告测试了 PTP。

感谢您提醒我们这两种不同的拓扑。 我最担心的是、拓扑 2 会导致问题、正如我在上一个响应中所述。 我的问题是、是否可以在拓扑 1 上测试此多播特定测试（不是您以前所做的 PTP 测试）、以隔离与拓扑 2 相关的任何潜在问题。  

-道林

尊敬的 Daolin：

我再次测试了所有内容、我可以使用运行最新 SDK 的 SK-AM64B 一致地重现问题。 我制作了多播 ping 的截屏视频、以展示发现问题时设备如何交互。

拓扑：

截屏视频（控制台窗口的排列顺序与拓扑相同）：

e2e.ti.com/.../AM64B_5F00_IP_5F00_Multicast_5F00_issue.mp4

来自 SK-AM64B 的原始日志：

root@am64xx-evm:~# hostname
am64xx-evm
root@am64xx-evm:~#
root@am64xx-evm:~# uname -a
Linux am64xx-evm 6.12.17-ti-rt-00771-gc85877d40f8e #1 SMP PREEMPT_RT Tue Mar 25 12:45:29 UTC 2025 aarch64 GNU/Linux
root@am64xx-evm:~#
root@am64xx-evm:~# ifconfig eth0
eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 1c:63:49:1a:d9:b1  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

root@am64xx-evm:~#
root@am64xx-evm:~#
root@am64xx-evm:~# ifconfig eth1
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::72ff:76ff:fe1f:4456  prefixlen 64  scopeid 0x20<link>
        ether 70:ff:76:1f:44:56  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 26  bytes 4842 (4.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

root@am64xx-evm:~#
root@am64xx-evm:~#
root@am64xx-evm:~# clear
root@am64xx-evm:~# ip addr add 192.168.1.20/24 dev eth1             
root@am64xx-evm:~#
root@am64xx-evm:~# ip addr add 224.10.10.10/24 dev eth1 autojoin    
root@am64xx-evm:~#
root@am64xx-evm:~# sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=0 
net.ipv4.icmp_echo_ignore_broadcasts = 0
root@am64xx-evm:~#
root@am64xx-evm:~# Multicast ping is working^C
root@am64xx-evm:~# ^C
root@am64xx-evm:~# ^C
root@am64xx-evm:~# [  206.309907] am65-cpsw-nuss 8000000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx

root@am64xx-evm:~# eth0 link restored, ping stopped^C
root@am64xx-evm:~# ^C
root@am64xx-evm:~# ethtool -S eth1 | grep drop | grep -v ": 0"
     ale_drop: 38
     rx_port_mask_drop: 38
root@am64xx-evm:~#
root@am64xx-evm:~#
root@am64xx-evm:~#
root@am64xx-evm:~#
root@am64xx-evm:~# ethtool -S eth1 | grep drop | grep -v ": 0"
     ale_drop: 41
     rx_port_mask_drop: 41
root@am64xx-evm:~#
root@am64xx-evm:~#
root@am64xx-evm:~# ethtool -S eth1 | grep drop | grep -v ": 0"
     ale_drop: 43
     rx_port_mask_drop: 43
root@am64xx-evm:~#
root@am64xx-evm:~#
root@am64xx-evm:~# ip link set dev eth1 up
root@am64xx-evm:~#
root@am64xx-evm:~#
root@am64xx-evm:~# ethtool -S eth1 | grep drop | grep -v ": 0"
     ale_drop: 53
     rx_port_mask_drop: 53
root@am64xx-evm:~#
root@am64xx-evm:~# ethtool -S eth1 | grep drop | grep -v ": 0"
     ale_drop: 53
     rx_port_mask_drop: 53
root@am64xx-evm:~#
root@am64xx-evm:~#

如果您需要更多信息、请告诉我。

编辑 1:我做了一个有趣的观察:

多播 ping 工作时  

1.如果 我物理断开并重新连接 eth1、ping 将恢复

2.如果 我物理断开并重新连接 eth0 , ping 就会停止并保持停止状态。  

编辑 2:我也测试了所有交换 eth0 到 eth1 和行为 是相同的。  

此致、

-迪帕尔

尊敬的 Dipal：

我将更深入地了解您明天分享的截屏视频、看看我能否让多播测试正常运行。

-道林

尊敬的 Dipal：

更新：我最终能够重现相同的多播特定问题（问题是我在 SK-AM62B 上连接到 eth1 的设备不在同一 IP 地址子网上，必须静态配置）

在尝试进一步调试问题时、我注意到、通过在 SK-AM62B 上添加 eth0 以加入同一多播组 (ip addr 添加 224.10.10.10/24 dev eth0 autjoin)、从连接到 SK-AM62B 上 eth1 的器件 ping 操作没有失败。  

我仍在尝试了解是否使多播数据包接收正常工作、接收器件上的所有链接接口（本例中为 SK-AM64B）是否都需要加入正在使用的多播组？ 如果是这种情况、也许要求确保所有连接的接口都需要加入多播组。

如果不是这种情况、需要注意的另一点是、在接口的链路处、即使没有配置 IP 地址、也会有以太网流量通过。 例如、链接的 eth0 接口在此测试用例中、未配置 IP 地址、但尝试获取 IP 地址时已启动活动流量。 只需建立链路、就可以通过 ethtool -S eth0 的非零 rx_good_frames 看到这一点。 这可能是组播 ping 停止的原因。

我对它进行了测试、并看到与您的日志类似的结果。 对于 ethtool 丢弃计数器、我注意到只要发生链路建立事件、即使 PTP 未运行、也是如此。 以下是我可以从 AM64x TRM 中找到的一些端口掩码丢弃和 ALE 丢弃信息。 我认为这些不是 PTP 特有的问题。

 

邱道林说：

[/报价]

至于 ALE_DROP 和 RX_PORT_MASK_DROP、如 TRM 中的这些片段所示、我共享了多个响应、如果数据包目标地址与源地址和 ALE 因未发送到任何目标端口而丢弃的数据包数量不匹配、则它们会递增。 需要注意的一点是、即使未测试多播 ping、只要将未配置 IP 地址的接口与连接的接口连接到同一子网上、这些计数器也会增加。 例如、在设置中将 eth1 SK-AM62B 与 enp8s0 简单连接、当这些接口未配置 IP 地址时、您会看到这些计数器递增。 一旦配置了 IP 地址、计数器就会停止递增。 至少这是我在设置中观察到的行为。  

下面详细介绍了我为重新创建问题而采取的步骤  

1. 测试拓扑：“主机“ eth0 <keep connected>  eth1 SK-AM64B eth0 <keep disconnected> eth0  “另一个已知正常运行的器件“
   1. SK-AM64B 是 DUT
   2. “主机“可以是任何未连接到互联网且未运行 DHCP 服务器的已知工作设备
      1. 我使用了一个现成的 TMDS64EVM
   3. “另一个已知的工作设备“可以是任何未连接到互联网、未运行 DHCP 服务器且与“主机“不是同一个设备的已知工作设备
      1. 我使用了现成的不同 TMDS64EVM
2. 在“Host"（“（主机（主机）eth0 上设置静态 IP 地址  
   1. ip 地址添加 192.168.1.25/24 dev eth0
3. 开始 ping “主机“eth0 上的多播地址
   1. Ping -i enp3s0 224.10.10.10
4. 在 DUT eth1 上设置静态 IP 地址
   1. ip addr add 192.168.1.20/24 dev eth1
5. 在 DUT eth1 上加入多播地址
   1. ip addr add 224.10.10.10/24 dev eth1 autojoin
6. 禁用忽略 DUT 上的广播
   1. sysctl -w net.ipv4.icmp_echo_ignore_broadcasts=0
7. 在步骤 6 之后、“主机“应立即显示通过发送的 ping 数据包（多播工作）
   1. 必须确保“主机“eth0 与 DUT eth1 在同一子网上具有 IP 地址
8. 在 DUT 和“另一个已知正常工作的设备“之间建立 eth0 链路（连接电缆或使用 IP 链路设置 dev eth0 up）
9. 观察“Host"上“上的 ping 是否停止、并查看 DUT 增量上来自 ethtool -S eth1 的 ALE_DROP 和 rx_PORT_MASK_DROP 计数器

您是否不能简单地将 eth0 添加到同一组播组中以确保组播工作（并最终使 PTP 工作）？

-道林

尊敬的 Daolin：

感谢您的更新、很高兴知道您能够重新创建该问题。

您是否不能简单地将 eth0 添加到同一组播组以确保组播工作（并最终使 PTP 正常工作）？

我们已经尝试过此操作（适用于 PTP 和普通多播） 。  

正常多播请参阅步骤 4：

分辨率保持不变、以下步骤之一可以恢复 ping 响应

1. 启用多播“IP link set dev eth1 multicast On“  
2. 再次强制链路接通（即使已经接通）“IP link set dev eth1 up“
3. 启用混杂模式：“IP link set dev eth1 multicast On“
4. 配置静态组成员资格（在 eth0 和 eth1 上都需要）“ip maddr add 01：00：5e：0A：0A dev eth0“和“ip maddr add 01：00：5e：0A：0A dev eth1“  

PTP、请参阅“即使我仅在一个接口上运行 PTP、我仍然需要为两个接口配置它“

通过如下所示配置 PTP muticast 地址的静态条目、我设法使其与 NetworkManger（或可能独立于任何网络管理）配合使用、我仍然需要为两个接口进行配置、即使我仅在一个接口上运行 PTP。

ip link set dev eth0 down
ip link set dev eth1 down
ip maddr add 01:80:c2:00:00:0e dev eth0
ip maddr add 01:80:c2:00:00:0e dev eth1
ip link set dev eth0 up
ip link set dev eth1 up

我认为 TI 驱动程序在处理方面仍有缺失/可以改进。

对于 PTP 情况、我们可能仍然能够在两个接口上配置静态组、但对于正常的多播应用程序 、这是不可行的、因为两个端口可能都要订阅不同的组。  

此致、

-迪帕尔

尊敬的 Dipal：

对于 PTP 情况、我们仍然可以在两个接口上配置静态组、但对于正常的多播应用程序、这是不可行的、因为两个端口可能都要 订阅不同的组。  [/报价]

感谢您对此进行澄清。 由于我能够重现该问题、因此我已继续对正常的多播问题提出了一个错误、并且似乎该问题更可能是一个错误、而不是用例问题。 我们将负责此问题的软件开发人员将于下周停止工作、因此我预计会在根本原因上出现延迟、从而导致问题并提供修复。

我目前正在研究转储所有 CPSW ALE 条目的方法、以查看 ALE 是否正确注册了多播地址和端口。 ALE_DROP 和 rx_PORT_MASK_DROP 计数器递增这一事实表明由于某种原因未找到多播（目标）地址。

当前看起来像“ethtool -d 这是一种转储 CPSW 寄存器（包括 ALE 寄存器）但似乎会转储所有 ALE 条目的方法。

-道林

尊敬的 Daolin：

感谢您的更新、如果您需要更多信息、请随时回来。

为了进一步说明正常的多播用例、通常由客户编写应用程序。  要加入的多播组和相关接口由应用程序开发人员决定。 同一个应用程序可以在多个设备上使用、因此不可能修改应用程序以订阅所有接口上的相同组。 此外、应用程序还希望订阅不同接口上的不同组。  

此致、

-迪帕尔

尊敬的 Dipal：  

我目前正在寻找一种转储所有 CPSW ALE 条目的方法、以查看 ALE 是否正确注册了多播地址和端口。 ALE_DROP 和 rx_PORT_MASK_DROP 计数器递增这一事实表明由于某种原因未找到多播（目标）地址。

更新：

我能够使用 devmem2 和 CPSW_ALE_TBLCTL（地址 0x0803E020）、CPSW_ALE_TBLW2（地址 0x0803E032）、CPSW_ALE_TBLW1（地址 0x0803E038）、CPSW_ALE_TBLW0（地址 0x0803E03C）寄存器手动读取给定的 ALE 条目。 您可以在 AM64x TRM 中了解有关这些寄存器的更多信息。

在“其他“端口上的链路状态发生变化之前和之后检查这些寄存器、我发现多播地址的 ALE 条目从条目类型“地址条目“更改为“自由条目“（您可以在 AM64x TRM 中找到有关条目类型的更多信息）。 但是、仍然需要跟踪 ALE 入口类型这种变化的根本原因、我需要与软件开发人员合作才能做到这一点。 正如我提到的、该开发人员本周已离开办公室、因此在找到修复方案时会出现延迟。

-道林

尊敬的 Daolin：

这是的、我认为我们正在变得越来越接近 k Ω

感谢您的调试和发布。

此致、

-迪帕尔

尊敬的 Dipal：

以下是我们的开发人员发现的内容：

CPSW 驱动程序中存在错误或者可能存在预期行为（尚未确定）、因为 ALE 表是所有接口（在本例中为 eth0 和 eth1）的通用资源、每当我们关闭其他接口时、它都会清空其他接口的多播条目（不正确）、这就是我们在处理 PTP 或正常多播流量时看到该问题的原因。

暂时的解决方法：

删除多播条目: ip addr del 224.10.10.10/24 dev eth1 autojoin 再添加一次:ip addr add 224.10.10.10/24 dev eth1 autojoin 将解决问题,对于 PTP 我们需要再次同步时钟。

我们将在何时/是否找到此问题的修复程序时进行更新（仍需要根据我们的 ALE 表设计在内部确定这是否是错误或预期行为）。

-道林

尊敬的 Daolin：

感谢您的更新。

删除多播条目：ip addr del 224.10.10.10/24 dev eth1 autojoin 并再次添加：ip addr add 224.10.10.10/24 dev eth1 autojoin 将解决问题、对于 PTP、我们需要再次同步时钟。

这是重现问题的最小示例、以便了解组地址。

遗憾的是 、我认为在实际用例中无法做到这一点、因为要加入的组由最终用户应用程序决定、在系统级别、我们无法静态配置它们、因为每个应用程序都需要加入不同的组、甚至同一个应用程序可以在不同的时间加入不同的组。

它适用于 PTP 、因为我们知道要使用的地址。

此致、

-迪帕尔

尊敬的 Dipal：

不幸的是 、我认为这在实际用例中是不可能的、因为要加入的组是由最终用户应用程序决定的、在系统级别、我们无法静态配置它们、因为每个应用程序都需要加入不同的组、甚至同一个应用程序可以在不同的时间加入不同的组。

感谢您指出这一点。 我会将此注释添加到针对此问题的内部错误标签中。 我也认为这是一个错误、但开发人员需要在内部确定 ALE 应该如何解决此问题。

我们将在何时/是否找到此问题的修复程序时进行更新（仍需要在内部根据 ALE 表设计确定这是一个错误还是预期的行为）。

-道林

尊敬的 Daolin：

感谢您的理解、让我们看看过程。

此致、

-迪帕尔  

尊敬的 Daolin：

谢谢、我将在几天内查看和更新。  

此致、

-迪帕尔

尊敬的 Dipal：  

正如免责声明一样、我在内部收到了反馈、如果这一更改可以正常使用、我们会将其集成到未来的 SDK 版本中。 为了实现稳定性、我们始终建议客户使用 SDK 版本、而不是手动应用更改、因为完整的 SDK 版本已通过内部测试、以确保补丁不会引入其他问题。  

-道林