Re: [Linuxptp-users] Multicast group (re)join issue vs IGMP snooping

[Jakub R. <j.r...@el...>]

> 21.02.2022 09:43 Miroslav Lichvar <mli...@re...> wrote:
> It might help if you could post some logs that show the problem with
> corresponding packet capture.

Sure thing.
So here is a setup - device 10.10.2.236 is PTP Master, 10.10.2.237 is PTP Slave, 10.10.4.1 is switch with IGMP snooping. There is also simple switch used in use, connected to 10.10.4.1 switch and PC with wireshark.

Case 1:
Both PTP Master and Slave are connected to simple switch. PTP Slave is started first, then later PTP Master.
As intended, PTP Slave keeps sending IGMP join request until it connects to any PTP Master.

Case 2:
PTP Master and PTP Slave are running, PTP Master is connected to simple switch, PTP Slave is behind turned off IGMP switch. PTP Master packets are visible in wireshark. After that switch with IGMP is started.
UNINTENDED - ptp4l Master nor Slave will ever send IGMP join so multicast is blocked.

Case 3:
Reversed connection between PTP Master & Slave - monitoring PTP Slave, PTP Master was turned off and turned on later.
UNINTENDED - as in case 2.

Case 4:
Both PTP Slave & Master are running, monitoring PTP Master, restarting IGMP switch. None of PTP packets can make it through switch.

Case 5:
Continuation of case 4, but we plug out and then plug in both PTP Master and Slave. Both devices send IGMP and can synchronize through IGMP switch.

I believe this whole behavior is combination of ethernet driver and kernel.
But I want to ask, should ptp4l monitor this rather than send only IGMP join packets at the start? Because I can see devices blatantly ignoring 'Membership queries' under specific circumstances (showed in the logs). So should ptp4l really depend on kernel or other drivers to work in such cases?

Best regards
Jakub Raczynski