On 1/29/2020 1:14 AM, Eric Poquillon wrote:
> Thanks Jacob and Richard
>
> The PTP server was configured with the firewalll active as I could check
> with iptables -L -v and was droping all the incoming udp traffic.
>
> By opening port 319 and 320 for udp, I recovered a normal behaviour and
> co
Thanks Jacob and Richard
The PTP server was configured with the firewalll active as I could check
with iptables -L -v and was droping all the incoming udp traffic.
By opening port 319 and 320 for udp, I recovered a normal behaviour and
could also pass pmc commands.
This is a bit strange, howeve
On Tue, Jan 28, 2020 at 08:55:12AM +0100, Eric Poquillon wrote:
> A side question : I didn't find how to target a specific clock with pmc.
> Are all the clocks on the network supposed to answer to a single query ?
There is a pmc command:
TARGET [portIdentity]
TARGET *
Thanks,
Ric
On Fri, Jan 24, 2020 at 07:26:30PM +0100, Eric Poquillon wrote:
> Any idea of misconfiguration that may result in this abnormal behaviour
> with L4 ?
Check that the configured domainNumber does match.
Also check the transportSpecific attribute.
Thanks,
Richard
_
Hi
Thanks for the answer.
I use WireShark from a third computer on a switch. Purpose was also to
check that the switch was not filtering UDP frames (and it does not).
However, I may have also launched a wireshark session on one of the PTP
clocks so I will check again (I didn't thought about the i
On 1/24/2020 10:26 AM, Eric Poquillon wrote:
> Hi,
>
> I am using two instances of ptp4l on two computers. One is running as
> slave and the other as master following initial series of annoucement
> messages.
>
> Despite the fact I can see, using WireShark, DelayRequest UDP frames
> sent by the s
