linuxptp-users — Open discussion on using the linuxptp software.

Re: [Linuxptp-users] Alert for Ubuntu 22.04

[Marco D. (SIDN) <mar...@si...>]

Update:

The bug seems fixed (there is a 3.1.1-3 now):

https://bugs.launchpad.net/ubuntu/+source/linuxptp/+bug/1959825

-- 
Marco


Op 11-02-22 om 08:15 schreef Marco Davids (SIDN) via Linuxptp-users:


> This is a heads-up for those planning to move to Ubuntu 22.04.
> 
> There was a change in the LinuxPTP package that will prevent it to 
> coexist with other time daemons such as chrony, ntp and ntpsec, even 
> though this is a common use case.
> 
> The issue is mentioned here:
> 
> https://bugs.launchpad.net/ubuntu/+source/linuxptp/+bug/1959825

[Linuxptp-users] LinuxPTP in unicast

[Marco D. (SIDN) <mar...@si...>]

Hi,

I created a unicast setup. It was an experiment to verify if I could 
make my PTP-service more resilient against 'rogue' masters on the same 
VLAN that (falsy) claim to be the best master.

The setup works fine. However, I noticed that when the real (unicast) 
master(s) become(s) unavailable, the slave is still sensitive to 
multicast packages. So, when a 'roque' master is transmitting via 
multicast, the slave will sync to it. That is precisely what I was 
hoping to prevent, so I was surprised.

Disabling multicast on the ethernet interface isn't a trivial thing to 
do ("ifconfig eth0 -multicast" has no effect), so I solved it by 
blocking port 319/320 multicast with iptables.

But I was wondering; isn't it a bit strange for ptp4l to pick up 
multicast packets, even when it is configured to do unicast?

Is this a bug or a feature?

-- 
Marco

[Linuxptp-users] ptp4l unicast losing sync after reaching s2 state

[<nil...@sr...>]

Hello everyone!

I am new to the PTP topic and I am wrapping my head around a problem 
which I am not sure how to solve. I try to get a unicast PTP master 
slave example to work and I am running into the following issue:

root@arria10:/usr/linuxptp# ./ptp4l -f configs/user_gen.cfg -l 6 -m
ptp4l[11164.204]: selected /dev/ptp0 as PTP clock
ptp4l[11164.240]: port 0: hybrid_e2e only works with E2E
ptp4l[11164.242]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[11164.243]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[11165.370]: port 1: new foreign master 1c697a.fffe.a60c6e-1
ptp4l[11181.370]: selected best master clock 1c697a.fffe.a60c6e
ptp4l[11181.372]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[11182.372]: master offset  157635964 s0 freq     +47 path 
delay      7465
ptp4l[11183.372]: master offset  157635896 s0 freq     -75 path 
delay      7458
ptp4l[11184.372]: master offset  157635916 s0 freq     -28 path 
delay      7458
ptp4l[11185.372]: master offset  157635866 s0 freq     -35 path 
delay      7458
ptp4l[11186.372]: master offset  157635912 s0 freq     -16 path 
delay      7452
ptp4l[11187.372]: master offset  157635887 s0 freq     -18 path 
delay      7452
ptp4l[11188.372]: master offset  157635788 s0 freq     -33 path 
delay      7441
ptp4l[11189.371]: master offset  157635861 s0 freq     -20 path 
delay      7428
ptp4l[11190.372]: master offset  157635776 s0 freq     -28 path 
delay      7428
ptp4l[11191.372]: master offset  157635672 s0 freq     -37 path 
delay      7427
ptp4l[11192.372]: master offset  157635718 s2 freq     -31 path 
delay      7406
ptp4l[11192.405]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[11193.372]: master offset  157635673 s0 freq     -45 path 
delay      7406
ptp4l[11193.372]: port 1: SLAVE to UNCALIBRATED on SYNCHRONIZATION_FAULT
ptp4l[11194.372]: master offset  157635638 s0 freq     -40 path 
delay      7406
ptp4l[11195.372]: master offset  157635593 s0 freq     -42 path 
delay      7406
ptp4l[11196.372]: master offset  157635583 s0 freq     -34 path 
delay      7406
ptp4l[11197.371]: master offset  157635618 s0 freq     -20 path 
delay      7406
ptp4l[11198.372]: master offset  157635563 s0 freq     -26 path 
delay      7406
ptp4l[11199.372]: master offset  157635496 s0 freq     -31 path 
delay      7413
ptp4l[11200.372]: master offset  157635481 s0 freq     -29 path 
delay      7413
ptp4l[11201.372]: master offset  157635554 s0 freq     -18 path 
delay      7410
ptp4l[11202.372]: master offset  157635469 s2 freq     -25 path 
delay      7410
ptp4l[11202.405]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[11203.372]: master offset  157635479 s0 freq     +10 path 
delay      7410
ptp4l[11203.372]: port 1: SLAVE to UNCALIBRATED on SYNCHRONIZATION_FAULT
ptp4l[11204.372]: master offset  157635541 s0 freq     +45 path 
delay      7428
ptp4l[11205.371]: master offset  157635451 s0 freq      +0 path 
delay      7428
ptp4l[11206.372]: master offset  157635476 s0 freq      +2 path 
delay      7413
ptp4l[11207.372]: master offset  157635501 s0 freq     +10 path 
delay      7428
ptp4l[11208.372]: master offset  157635556 s0 freq     +18 path 
delay      7428
ptp4l[11209.372]: master offset  157635571 s0 freq     +17 path 
delay      7428
ptp4l[11210.372]: master offset  157635523 s0 freq     +10 path 
delay      7436
ptp4l[11211.372]: master offset  157635631 s0 freq     +21 path 
delay      7438
ptp4l[11212.372]: master offset  157635574 s2 freq     +14 path 
delay      7440
ptp4l[11212.405]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED
ptp4l[11213.371]: master offset  157635624 s0 freq     +50 path 
delay      7440
ptp4l[11213.371]: port 1: SLAVE to UNCALIBRATED on SYNCHRONIZATION_FAULT
ptp4l[11214.372]: master offset  157635624 s0 freq     +25 path 
delay      7440
ptp4l[11215.372]: master offset  157635603 s0 freq     +12 path 
delay      7446

I use linuxptp v2.0 on the client side and v2.0.1 on the server side. I 
tried with Debian 9 and Ubuntu 2004 on two different machines. I am not 
sure where the error is coming from!

I attached some more detailed info. Any ideas what it can be or how I 
can debug this problem? Any advice is appreciated! Thanks in advance!

Client config: https://pastebin.com/YJGhzmAd
Server config: https://pastebin.com/NRAnm6vu
Client debug output: https://pastebin.com/D2f56EYN
Server debug output: https://pastebin.com/NvmCLvn8

Best Nils

Re: [Linuxptp-users] ntpd synchronization issue to ptp source

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

> 23.02.2022 12:56 Miroslav Lichvar <mli...@re...> wrote:
> > Should this be reason for that strange behavior?
> 
> Yes, without -a phc2sys is not monitoring the port state. It doesn't
> matter if it's phc2sys or ntpd via SHM correcting the clock.
> 
> -- 
> Miroslav Lichvar

Ok, that makes sense. Thanks for your help.

Jakub

Re: [Linuxptp-users] ntpd synchronization issue to ptp source

[Miroslav L. <mli...@re...>]

On Wed, Feb 23, 2022 at 12:49:37PM +0100, Jakub Raczyński wrote:
> Actually no, this device is set with slaveOnly flag thus -a for phc2sys was deemed as not needed. I run phc2sys with following parameters "phc2sys -s lan1 -E ntpshm -M 4 -w" and '-w' flag is said to be incompatible with '-a' flag.
> Should this be reason for that strange behavior?

Yes, without -a phc2sys is not monitoring the port state. It doesn't
matter if it's phc2sys or ntpd via SHM correcting the clock.

-- 
Miroslav Lichvar

Re: [Linuxptp-users] ntpd synchronization issue to ptp source

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

> 23.02.2022 08:55 Miroslav Lichvar <mli...@re...> wrote:
> 
>  
> 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 targeted for custom PTP devices that have much better holdover than ntpd could ever have?
> 
> No, ntpd should be getting samples only when the port is in the slave
> state. Did you start phc2sys with the -a option?
> 
> -- 
> Miroslav Lichvar

Actually no, this device is set with slaveOnly flag thus -a for phc2sys was deemed as not needed. I run phc2sys with following parameters "phc2sys -s lan1 -E ntpshm -M 4 -w" and '-w' flag is said to be incompatible with '-a' flag.
Should this be reason for that strange behavior?

Best regards
Jakub

Re: [Linuxptp-users] ntpd synchronization issue to ptp source

[Miroslav L. <mli...@re...>]

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 targeted for custom PTP devices that have much better holdover than ntpd could ever have?

No, ntpd should be getting samples only when the port is in the slave
state. Did you start phc2sys with the -a option?

-- 
Miroslav Lichvar

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

[Miroslav L. <mli...@re...>]

On Tue, Feb 22, 2022 at 05:10:06PM +0100, Jakub Raczyński wrote:
> > 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.

In the captures you have attached, I don't see any packets from the
slave or any igmp packets related to the PTP multicast groups.

-- 
Miroslav Lichvar

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

[Keller, J. E <jac...@in...>]

> -----Original Message-----
> From: Jakub Raczyński <j.r...@el...>
> Sent: Tuesday, February 22, 2022 8:10 AM
> To: Miroslav Lichvar <mli...@re...>
> Cc: lin...@li...
> Subject: Re: [Linuxptp-users] Multicast group (re)join issue vs IGMP snooping
> 
> > 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.
> 

All the evidence I found points to Linux re-sending IGMP packets between 0 to 10 seconds since Linux 2.6

If that's not happening in your system, you'd best be debugging the kernel, not ptp4l.

> 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?

ptp4l has to depend on the kernel. There is no control other than socket option to request to join and leave multicast groups. Its not up to the application to control re-send behavior.

Again, as far as I can tell, Linux has properly re-sent multicast IGMP packets periodically since 2.6 kernels. In addition, the time to resend is configurable since somewhere in the 3.x kernels.

At the very least its clear the Linux kernel *intends* to resend these periodically and if its not then you need to debug at the kernel level to figure out why.

Best of luck :)

-Jake 

Re: [Linuxptp-users] ntpd synchronization issue to ptp source

[Keller, J. E <jac...@in...>]

> -----Original Message-----
> From: Jakub Raczyński <j.r...@el...>
> Sent: Tuesday, February 22, 2022 6:59 AM
> To: lin...@li...
> Subject: [Linuxptp-users] ntpd synchronization issue to ptp source
> 
> 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 targeted for custom
> PTP devices that have much better holdover than ntpd could ever have?
> 

I would expect most PTP devices to have a better holdover time than ntpd.

[Linuxptp-users] GPS + PPS PTP master - confusion about ts2phc, phc2sys, ptp4l options and interdependencies

[David J. <sil...@gm...>]

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, hardware already exists).  Occasional loss of
GPS signal for a few seconds (< 10) at a time is expected, but no
sophisticated clocks (e.g. TCXO or atomic) needed for better
hold-over.

General query: With linuxptp 3.1 and newer (since ts2phc was added),
it has become a bit confusing how to stitch together all the bits and
how they interact. I see a caution in the ts2phc man page about
sharing config files and overlapping options.  Seems like
clarification is needed.  Are these assumptions below correct?

Assumption #1:  ts2phc and associated config file is how I configure
the input (e.g. SDP3 on the i210) and some very basic options
regarding pulse width.  ts2phc also has a NMEA option - stick a pin in
that (see below).  ts2phc doesn't seem to have anything for actually
configuring servo loops other than some step options.  Correct?  Is
this why ts2phc run all by itself (no phc2sys running) has a bunch of
(null) for clock related config items (e.g. "(null).clock_servo",
"(null).pi_proportional_cont", etc.)? Am I missing something?

Assumption #2:  phc2sys and associated config file is how I configure
servo loops (how do those interact w/ts2phc that's actually getting
the pulses?)?  It looks like phc2sys is how to link the phc to system
time, and there are options for *sys* to set PHC Time of Day, or PHC
to set *sys*, depending on the architecture's end goal and use case,
right?

Assumption #3: ptp4l and associated config file handles the actual ptp
sourcing - configuring the phc's timestamping mechanisms and driving
ptp packets across the network, using time of day from a source.  See
my question about direction in #2 (linux clocks as source or the time
in the PHC as source)

Assumption #4: Prior to the NMEA stuff in ts2phc, I thought the way to
do this was to have a gps program (gpsd or equivalent) capture the GPS
Time of Day, which is then used to set the local system clock.  Then
phc2sys is used to push that from the system clock to the phc
("sys2phc" if you will), and then somehow either phc2sys or ts2phc
would align the least significant time digits (e.g. < 1 usec) using
the inbound PPS to tweak the PHC clock to be aligned to exactly 1
second, by reaching in to the PHC itself and stepping or frequency
tweaking.   Is that (was that?) correct?

Assumption #5: Now that ts2phc has a NMEA option in it, does it now
set the ToD in the PHC directly?  If so, is phc2sys still used to push
that GPS-based (via NMEA) time that was pushed into the PHC by ts2phc
up to the system? Does it still need to be there for servo config?

Hopefully this can help drive clarity for myself or others.

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

[Denny P. <den...@me...>]

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 <j.r...@el...> wrote:
> 
> 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?

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

[Linuxptp-users] ntpd synchronization issue to ptp source

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

Greetings,

I would like to ask a question/report an issue.
Our setup: PTP Master & Slave based on imx6ul module, connected via simple switch. We set ptp4l to synchronize ntpd.

Issue:
When we synchronize PTP device to Master and then disconnect ethernet cable from PTP Slave (from device, not from switch), the PTP Slave device changes portState to 'Faulty' and time gets stuck, but still synchronized ntpd.

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 targeted for custom PTP devices that have much better holdover than ntpd could ever have?

Second question - is this bug caused by ethernet driver or is it linuxptp issue? I am not asking to check imx6ul driver but rather answer whether it should have been prevented by linuxptp. 
It is related to first question a bit, as it would not happen if linuxptp marked 'Faulty' Master as invalid ntpd source.

Attaching log and explanation - i used command 'watch' to log PTP and ntpd state before/during/after ethernet cable was disconnected. When cable is disconnected portState switches to 'Faulty' and time gets stuck; it gets unstuck when cable in reconnected (all included in log file)

Thanks for the help.

Best regards
Jakub Raczynski

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

[Richard C. <ric...@gm...>]

On Mon, Feb 21, 2022 at 06:53:09AM -0800, Richard Cochran wrote:

> 1. Ask the vendor to fix their switch FW.
> 
> 2. Don't re-start the switch when snooping is enabled.
> 
> 3. Don't make snooping a persistent setting, but rather enable it via
>    scripting after restarting the switch.
> 

4. Disable snooping on your switch.

Thanks,
Richard

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

[Richard C. <ric...@gm...>]

On Sun, Feb 20, 2022 at 05:52:17PM +0100, Jakub Raczyński wrote:
> You misunderstand. I am gonna repeat myself:
> "So basically ptp4l will only work on switch with IGMP snooping if it has been started after the switch, while any restart of switch will cause all PTP traffic to be blocked permanently."

You have described a bug in the switch.  You have three choices:

1. Ask the vendor to fix their switch FW.

2. Don't re-start the switch when snooping is enabled.

3. Don't make snooping a persistent setting, but rather enable it via
   scripting after restarting the switch.

I really don't see any linuxptp or kernel issue at all.  I definitely
will not accept hacks in my project for this kind of switch misbehavior. 

Sorry,
Richard

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

[Miroslav L. <mli...@re...>]

On Sun, Feb 20, 2022 at 05:52:17PM +0100, Jakub Raczyński wrote:
> So whatever you are blaming for that issue is not my concern, maybe kernel or some module should react to that but does not. Saying that, ptp4l is UNUSABLE on switches with IGMP snooping (many vendors tried and few kernel versions) on devices with older kernels. More tests are required for newer kernels.

It might help if you could post some logs that show the problem with
corresponding packet capture.

If this was a linuxptp or kernel issue impacting a large number of
switches, I think we would know about it much sooner.

-- 
Miroslav Lichvar

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

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

> 19.02.2022 19:24 Richard Cochran <ric...@gm...> wrote:
> You are mistaken.  ptp4l closes its sockets on link down and then
> opens new sockets (joining once again) on link up.

You misunderstand. I am gonna repeat myself:
"So basically ptp4l will only work on switch with IGMP snooping if it has been started after the switch, while any restart of switch will cause all PTP traffic to be blocked permanently."

So whatever you are blaming for that issue is not my concern, maybe kernel or some module should react to that but does not. Saying that, ptp4l is UNUSABLE on switches with IGMP snooping (many vendors tried and few kernel versions) on devices with older kernels. More tests are required for newer kernels.

Best regards
Jakub Raczynski

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

[Richard C. <ric...@gm...>]

On Sat, Feb 19, 2022 at 12:05:29AM +0100, Jakub Raczyński wrote:

> I cannot say on which precisely, would need more studying of Linux kernel. Seems that newer version of 4.9 has this implemented.  
> Basically, problem originates from this
> https://unix.stackexchange.com/questions/523529/should-the-linux-kernel-perform-an-igmp-rejoin-on-link-up
> And ptp4l does not take care of that and neither are some kernel versions.

You are mistaken.  ptp4l closes its sockets on link down and then
opens new sockets (joining once again) on link up.

> The question is whether ptp4l should worry or that or not. I must
> agree that would be a bit of "voodoo engineering". But some products
> seem to have locked kernel version, that is EOL for some time, yet
> no updated are available. For user, it is hard to debug why is it a
> case (why PTP multicast, both L2 and L4, is blocked on switch), so
> at least some big warning about this would be appreciated.

It isn't my job to debug your switches.  Please take the issue up the
switch vendors.

Thanks,
Richard

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

[Richard C. <ric...@gm...>]

On Fri, Feb 18, 2022 at 11:05:05PM +0000, Keller, Jacob E wrote:

> As far as I can tell, the default settings since a long time is to
> re-transmit an unsolicited join request with a random interval
> between 0 and 10 seconds as of the 2.6 git history. I couldn't find
> any data from before that.

IOW, there is no kernel bug and no linuxptp bug either.

Thanks,
Richard

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

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

> On Fri, Feb 18, 2022 at 10:08:20AM +0100, Jakub Raczyński wrote:
> 
> > I disagree. As far as I can tell, IGMP resending is done by kernel
> > from version 4.9 upon notification. So basically, ptp4l will not
> > work with any switch using IGMP in any way on older kernels.
> 
> What do you mean?
> 
> Are kernels 4.10+ working correctly, but 4.9 and earlier not working?


I cannot say on which precisely, would need more studying of Linux kernel. Seems that newer version of 4.9 has this implemented.  
Basically, problem originates from this
https://unix.stackexchange.com/questions/523529/should-the-linux-kernel-perform-an-igmp-rejoin-on-link-up
And ptp4l does not take care of that and neither are some kernel versions. So basically ptp4l will only work on switch with IGMP snooping if it has been started after the switch, while any restart of switch will cause all PTP traffic to be blocked permanently.

The question is whether ptp4l should worry or that or not. I must agree that would be a bit of "voodoo engineering". But some products seem to have locked kernel version, that is EOL for some time, yet no updated are available. For user, it is hard to debug why is it a case (why PTP multicast, both L2 and L4, is blocked on switch), so at least some big warning about this would be appreciated.

Best regards
Jakub

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

[Keller, J. E <jac...@in...>]

> -----Original Message-----
> From: Richard Cochran <ric...@gm...>
> Sent: Friday, February 18, 2022 2:13 PM
> To: Jakub Raczyński <j.r...@el...>
> Cc: lin...@li...
> Subject: Re: [Linuxptp-users] Multicast group (re)join issue vs IGMP snooping
> 
> On Fri, Feb 18, 2022 at 10:08:20AM +0100, Jakub Raczyński wrote:
> 
> > I disagree. As far as I can tell, IGMP resending is done by kernel
> > from version 4.9 upon notification. So basically, ptp4l will not
> > work with any switch using IGMP in any way on older kernels.
> 
> What do you mean?
> 
> Are kernels 4.10+ working correctly, but 4.9 and earlier not working?
> 
> Thanks,
> Richard
> 

FWIW, it looks like there are some sysctls for this, from ip sysctl documentation:

igmpv2_unsolicited_report_interval - INTEGER
        The interval in milliseconds in which the next unsolicited
        IGMPv1 or IGMPv2 report retransmit will take place.

        Default: 10000 (10 seconds)

igmpv3_unsolicited_report_interval - INTEGER
        The interval in milliseconds in which the next unsolicited
        IGMPv3 report retransmit will take place.

        Default: 1000 (1 seconds)

It looks like the default for IGMPv3 was changed from 10 to 1second in cab70040dfd9 ("net: igmp: Reduce Unsolicited report interval to 1s when using IGMPv3") and made configurable in 2690048c01f3 ("net: igmp: Allow user-space configuration of igmp unsolicited report interval")

As far as I can tell, the default settings since a long time is to re-transmit an unsolicited join request with a random interval between 0 and 10 seconds as of the 2.6 git history. I couldn't find any data from before that.

So I think Richard is quite right, if there is a bug, it is in the kernel, and as far as I can tell it is at least intended that the kernel will re-transmit these as necessary.

Thanks,
Jake

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

[Richard C. <ric...@gm...>]

On Fri, Feb 18, 2022 at 10:08:20AM +0100, Jakub Raczyński wrote:

> I disagree. As far as I can tell, IGMP resending is done by kernel
> from version 4.9 upon notification. So basically, ptp4l will not
> work with any switch using IGMP in any way on older kernels.

What do you mean?

Are kernels 4.10+ working correctly, but 4.9 and earlier not working?

Thanks,
Richard

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

[Richard C. <ric...@gm...>]

On Fri, Feb 18, 2022 at 05:42:57PM +0000, Keller, Jacob E wrote:

> (in fact, there is no real interface to do this in the socket
> options.. There's simply a join and leave group option, but no
> mention of needing to re-join periodically or what attempting to
> join an already joined group would do).

Exactly.

You can't expect user space to blindly retry joining a group with zero
feedback as to whether the join was successful or not.  Doing so is
voodoo engineering.

If there is a bug, then it is a kernel bug.

Thanks,
Richard

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

[Keller, J. E <jac...@in...>]

> -----Original Message-----
> From: Jakub Raczyński <j.r...@el...>
> Sent: Friday, February 18, 2022 1:08 AM
> To: lin...@li...
> Subject: Re: [Linuxptp-users] Multicast group (re)join issue vs IGMP snooping
> 
> > 18.02.2022 00:51 Richard Cochran <ric...@gm...> wrote:
> > On Thu, Feb 17, 2022 at 05:26:15PM +0100, Janusz Użycki wrote:
> >
> > > From our observations for IPv4 (L4) E2E it still applies to ptp4l. On Cisco
> > > and Netgear switches (even L3 set as L2 switch) IGMP snooping must be
> > > disabled for proper PTP multicast work.
> >
> > So their "IGMP snooping" feature is broken.  Ask them to fix it.
> 
> I disagree. As far as I can tell, IGMP resending is done by kernel from version 4.9
> upon notification. So basically, ptp4l will not work with any switch using IGMP in
> any way on older kernels. We probably should assume that devices with older
> kernel are all EOL but it is not uncommon for them to be still used. So maybe
> some annotation on what kernel version will ptp4l work or what are required
> kernel modules.
> 
> > Cisco's PTP switch has issues.  Have you looked at the residence
> > times?  I don't feel like implementing workarounds for buggy >hardware.
> 
> And is depending on kernel features for ptp4l to work properly a good way? I do
> not think it is hardware issue here, but rather dependence on kernel version
> and/or modules.
> 

ptp4l already has a lot of "it works better on newer kernel" bits, due to interfacing with Linux kernel interfaces so directly.  I think the earliest technically working version is something from the 3.x series (3.5?) but I don't see a problem with documenting a newer version as recommended with the justifications of which features we rely on.

I think I agree with Richard that this is the kernel's problem, and that we shouldn't try to forcibly re-send IGMP messages ourselves (in fact, there is no real interface to do this in the socket options.. There's simply a join and leave group option, but no mention of needing to re-join periodically or what attempting to join an already joined group would do).

Thanks,
Jake

> Best regards
> Jakub
> 
> 
> _______________________________________________
> Linuxptp-users mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users