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

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

On Thu, Dec 15, 2016 at 06:18:33PM +0000, Taber, Alan wrote:
> 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:

Here ptp4l uses the default UDP/IPv4 transport.

> 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


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

Reply via email to