[Linuxptp-users] PTP packets not being acted upon by RHEL 7 server

[Taber, Alan]

I have a SecureSync 9400 GrandMaster clock that is appropriately putting out PTPv2 Sync and Announce packets (verified by Wireshark listening on a different network node). I have run tcpdump -i enp9s0 -v to check to see that the packets are getting through to my RHEL 7 server, and they are showing up.

Yet, when I run ptp4l -i enp9s0 -m, I get the following:

Selected /dev/ptp1 as PTP clock
driver changed our HWTSTAMP options
tx_type 1 not 1
rx_filter 1 not 12
port 1: INITIALIZING to LISTENING on INITIALIZE
port 0: INITIALIZING to LISTENING on INITIALIZE
port 1: link up
port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
selected best master clock 0cc47a.fffe.acbaf7


at this point I can see sync and announce packets on the network from both my GrandMaster clock and this RHEL 7 server.

What indicators should I be looking at to see why the local ptp daemon isn't listening to the packets the server is receiving?

Thanks in advance for any insight you can share.

Best regards,

Alan Taber

[Richard Cochran]

Post by Taber, Alan
I have a SecureSync 9400 GrandMaster clock that is appropriately putting out PTPv2 Sync and Announce packets (verified by Wireshark listening on a different network node). I have run tcpdump -i enp9s0 -v to check to see that the packets are getting through to my RHEL 7 server, and they are showing up.

Here ptp4l uses the default UDP/IPv4 transport.

Post by Taber, Alan
What indicators should I be looking at to see why the local ptp daemon isn't listening to the packets the server is receiving?

Possibly the server is configured for Layer2 or IPv6?

HTH,
Richard

[Richard Cochran]

Thanks, Richard. We're running IPv4 only. I'll check into Layer2 and report back.
Since my previous email I've tried the same ptp4l -i enp9s0 -m on a second server on the network, and it also is ignoring the other two asserting sources and declaring itself as the master clock, and I see announce and sync packets from all three sources on Wireshark. So there's something in the setup of the servers that is preventing them from listening for those packets.

Firewall?

Thanks,
Richard

[Taber, Alan]

Did check that - shows as installed but inactive, which is what I expected having disabled it via systemctl.

Also tried using ptp4l -i enp9s0 -m -2, no change to the results.

Best regards,
Alan

-----Original Message-----
From: Richard Cochran [mailto:***@gmail.com]
Sent: Thursday, December 15, 2016 2:50 PM
To: Taber, Alan (US) <***@lmco.com>
Cc: linuxptp-***@lists.sourceforge.net
Subject: EXTERNAL: Re: EXTERNAL: Re: [Linuxptp-users] PTP packets not being acted upon by RHEL 7 server

Thanks, Richard. We're running IPv4 only. I'll check into Layer2 and report back.
Since my previous email I've tried the same ptp4l -i enp9s0 -m on a second server on the network, and it also is ignoring the other two asserting sources and declaring itself as the master clock, and I see announce and sync packets from all three sources on Wireshark. So there's something in the setup of the servers that is preventing them from listening for those packets.

Firewall?

Thanks,
Richard

[Keller, Jacob E]

Post by Taber, Alan
-----Original Message-----
Sent: Thursday, December 15, 2016 12:03 PM
Subject: Re: [Linuxptp-users] PTP packets not being acted upon by RHEL 7 server

Post by Taber, Alan
I have a SecureSync 9400 GrandMaster clock that is appropriately putting out

PTPv2 Sync and Announce packets (verified by Wireshark listening on a different
network node). I have run tcpdump -i enp9s0 -v to check to see that the packets
are getting through to my RHEL 7 server, and they are showing up.
Here ptp4l uses the default UDP/IPv4 transport.

Post by Taber, Alan
What indicators should I be looking at to see why the local ptp daemon isn't

listening to the packets the server is receiving?
Possibly the server is configured for Layer2 or IPv6?
HTH,
Richard

Additionally, check that wireshark and tcpdump are not running in promiscuous mode when you test. It is possible that you have a firewall (firewalld for example) disabling the packets, but when you run tcpdump in promiscuous mode it will be bypassing the firewall. This I believe is the default firewall settings for RHEL 7 so you should make sure you change that in firewalld to enable the traffic.

Thanks,
Jake

[Dale Smith]

On Thu, Dec 15, 2016 at 7:27 PM, Keller, Jacob E

Post by Keller, Jacob E
Additionally, check that wireshark and tcpdump are not running in promiscuous mode when you test. It is possible that you have a firewall (firewalld for example) disabling the packets, but when you run tcpdump in promiscuous mode it will be bypassing the firewall. This I believe is the default firewall settings for RHEL 7 so you should make sure you change that in firewalld to enable the traffic.

Yep.. Something very similar happened to me before. mdns was just not
working and when I fired up wireshark, it *magically* got fixed. I
needed to all "allmulti" to the iface.

Check the interface with either ifconfig or ip link and make sure
MULTICAST is enabled....

-Dale

[Keller, Jacob E]

Post by Taber, Alan
-----Original Message-----
Sent: Thursday, December 15, 2016 12:07 PM
Subject: Re: [Linuxptp-users] EXTERNAL: Re: PTP packets not being acted upon by
RHEL 7 server
Thanks, Richard. We're running IPv4 only. I'll check into Layer2 and report back.
Since my previous email I've tried the same ptp4l -i enp9s0 -m on a second server
on the network, and it also is ignoring the other two asserting sources and
declaring itself as the master clock, and I see announce and sync packets from all
three sources on Wireshark. So there's something in the setup of the servers that
is preventing them from listening for those packets.
Best regards,
Alan

Try running tcpdump without it setting the promiscuous flag. This smells suspiciously of a firewall issue, so maybe it's not the same thing you checked earlier? in RHEL 7 that should be firewalld but it might just iptables...

What I suggest:

run ptp4l and simultaneously run tcpdump but set the flag that prevents tcpdump from enabling promiscuous mode. If tcpdump still indicates that it sees packets but ptp4l does not then that is a different issue. You could also try running tcpdump in promicuous mode at the same time as ptp4l and see if that causes ptp4l to start seeing the packets.

Thanks,
Jake

[Taber, Alan]

Hi Stan,

Thanks for the reverse path filtering "relaxed" setting. That did the trick! Linux boxes are now listening to the GrandMaster clock.

And everyone else, thanks for all your suggestions! I know a lot more now than I did before about how to set up PTP here, and I appreciate you taking the time to respond.

Best regards,
Alan

-----Original Message-----
From: Moravec, Stanislav (ERT) [mailto:***@hpe.com]
Sent: Friday, December 16, 2016 2:51 AM
To: Keller, Jacob E <***@intel.com>; Taber, Alan (US) <***@lmco.com>; Richard Cochran <***@gmail.com>
Cc: linuxptp-***@lists.sourceforge.net
Subject: EXTERNAL: RE: [Linuxptp-users] EXTERNAL: Re: PTP packets not being acted upon by RHEL 7 server

Another option, besides firewall, is Reverse Path filtering. Setting rp_filter to relaxed (=2) may help in some situations.

regards
Stan