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, however, for an off-the-shelf PTP server (NTS Pico3). Le 28/01/2020 à 08:55, Eric Poquillon a écrit : > 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 impact of the > promiscuous mode). > > I didn't succeed to get a management answer using pmc from the outside > (I mean from another PC connected on the switch) although it was fine > when pmc runs on the same computer as ptp4l. > > So I will dig into those two clues : promiscuous mode and firewall. > > 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 ? > > > Thanks again for the help > > Eric > > Le 27/01/2020 à 21:49, Jacob Keller a écrit : >> 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 slave passing on the network, following the SYNC and >>> FOLLOWUP frames from the master, the master never responds to them by a >>> Delay_Response. The slave remains in the Listenning state. >>> >> How are you checking with wireshark? from the slave? from the master? >> are you ensuring to check without enabling promicuous mode on the devices? >> >>> If I change the transport protocol from L4 (UDP) to L2 (ethernet), then >>> the exchange seems normal and the whole set of SYNC, FOLLOWUP, >>> DELAY_Request and Delay_Response are visible on the network. >>> >>> Any idea of misconfiguration that may result in this abnormal behaviour >>> with L4 ? >>> >> In my experience, this usually is the result of a firewall blocking the >> L4 UDP packets. It's not the only explanation but it's fairly common. >> >> I would rule that out first. You should also be able to increase the log >> level on ptp4l to get it to print more data about what it's seeing. You >> might also check with pmc to see if ptp4l is noticing the packets. >> >> I believe there is a statistics command that got added recently, I >> believe GET_PORT_STATS_NP. >> >> best of luck! >> >> Thanks, >> Jake >> >>> Eric >>> >>> >>> >>> _______________________________________________ >>> Linuxptp-users mailing list >>> Linuxptp-users@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/linuxptp-users >>> >> _______________________________________________ >> Linuxptp-users mailing list >> Linuxptp-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/linuxptp-users > > _______________________________________________ > Linuxptp-users mailing list > Linuxptp-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxptp-users _______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
