The concept of Multicast membership is owned by the kernel. ptp4l does not, and
can not, send IGMP packets.
Denny
> On Feb 22, 2022, at 08:10, Jakub Raczyński
> wrote:
>
> But I want to ask, should ptp4l monitor this rather than send only IGMP join
> packets at the start? Because I can see
For use case orientation: Embedded system installed on a remote (no
internet) infrastructure, receives GPS w/PPS, sets time from power-up
(e.g. 1970) and acts as PTP grandmaster for the entire local
infrastructure. Hardware includes intel i210 with PPS input to SDP3
(this cannot be changed, hardwa
> -Original Message-
> From: Jakub Raczyński
> Sent: Tuesday, February 22, 2022 6:59 AM
> To: linuxptp-users@lists.sourceforge.net
> Subject: [Linuxptp-users] ntpd synchronization issue to ptp source
>
> So first question - I checked linuxptp source and it seems that once PTP has
> eve
> -Original Message-
> From: Jakub Raczyński
> Sent: Tuesday, February 22, 2022 8:10 AM
> To: Miroslav Lichvar
> Cc: linuxptp-users@lists.sourceforge.net
> Subject: Re: [Linuxptp-users] Multicast group (re)join issue vs IGMP snooping
>
> > 21.02.2022 09:43 Miroslav Lichvar wrote:
> >
On Tue, Feb 22, 2022 at 05:10:06PM +0100, Jakub Raczyński wrote:
> > 21.02.2022 09:43 Miroslav Lichvar 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
On Tue, Feb 22, 2022 at 03:59:00PM +0100, Jakub Raczyński wrote:
> So first question - I checked linuxptp source and it seems that once PTP has
> ever synchronized, it will always synchronize ntpd, whether linuxptp is
> connected to Master device or is in holdover. Is it indented behavior? Is it
