On Mon, Oct 30, 2017 at 08:07:49PM -0700, Gary E. Miller wrote: > Miroslav Lichvar <mlich...@redhat.com> wrote: > > Is there a "LISTENING to UNCALIBRATED on RS_SLAVE" message in the log? > > If not, ptp4l is probably not receiving master's messages, e.g. due to > > firewall or switch configuration. > > Nope. Can you suggest a working configuration or a howto? I thought > it used to work.
A minimal configuration using software timestamping and the NTP SHM segment #2 would be: 1. on master run: ptp4l -S -i eth0 -m 2. on slave run: ptp4l -s -S -i eth0 -m --clock_servo NTPSHM --ntpshm_segment 2 The slave ptp4l should print something like this: ptp4l[3444911.527]: port 1: INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[3444911.528]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[3444916.592]: port 1: new foreign master xxxxxx.xxxx.xxxxxx-1 ptp4l[3444918.313]: selected best master clock yyyyyy.yyyy.yyyyyy ptp4l[3444920.592]: selected best master clock xxxxxx.xxxx.xxxxxx ptp4l[3444920.592]: foreign master not using PTP timescale ptp4l[3444920.592]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE ptp4l[3444922.592]: master offset -333886 s0 freq +0 path delay 87021 ptp4l[3444923.592]: master offset -335317 s0 freq +0 path delay 89726 For each "master offset" message there should be an update of the SHM segment. # ntpshmmon ntpshmmon version 1 # Name Seen@ Clock Real L Prec sample NTP2 1509446684.245300996 1509446683.444564513 1509446683.444868882 0 -30 sample NTP2 1509446684.445200649 1509446684.444584459 1509446684.444876828 0 -30 sample NTP2 1509446685.444777467 1509446685.444555127 1509446685.444893429 0 -30 sample NTP2 1509446686.444997907 1509446686.444603946 1509446686.444903255 0 -30 sample NTP2 1509446687.445353599 1509446687.444604192 1509446687.444912416 0 -30 sample NTP2 1509446688.445426052 1509446688.444619136 1509446688.444923429 0 -30 If the slave does not synchronize, you can try on slave # tcpdump -i eth0 -n port ptp-event or port ptp-general 11:47:10.446485 IP 192.168.101.1.ptp-event > 224.0.1.129.ptp-event: UDP, length 44 11:47:10.446503 IP 192.168.101.1.ptp-general > 224.0.1.129.ptp-general: UDP, length 44 11:47:10.446508 IP 192.168.101.1.ptp-general > 224.0.1.129.ptp-general: UDP, length 64 11:47:11.446489 IP 192.168.101.1.ptp-event > 224.0.1.129.ptp-event: UDP, length 44 11:47:11.446515 IP 192.168.101.1.ptp-general > 224.0.1.129.ptp-general: UDP, length 44 If there are some ptp message from the master, it's likely a firewall rule which blocks the messages from reaching ptp4l. UDP ports 319 and 320 need to be allowed. If no messages appear, the switch (if it's a managed switch) might need to be configured to allow multicast traffic between the hosts. -- Miroslav Lichvar ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users