On Sat, Mar 12, 2022 at 06:07:11PM -0500, [email protected] wrote:
> However, because there is no checking of received unicast master to configured > unicast table, ptp4l is quite content with packets from previous master > 10.64.10.13. This patch doesn't actually fix the root cause. If the cancel request fails or is ignored by the remote master, then the master will continue to send Sync messages, and the issue persists. In general, there is no way for a program to enforce good behavior from another networked computer. The proper fix would be to check the source address of the received messages. Thanks, Richard _______________________________________________ Linuxptp-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
