Thanks for pointing the fix/commit. Rebuilt based on master branch and that fixed the issue of using IPv6 in multicast mode. For unicast mode, i can now enter a proper IPv6 address in the UMT table.
Running in IPv6 multicast, came across the dreaded 'tx_timestamp_timeout' when using hardware timestamping (software timestamping is ok). I tried to increase the timeout value but without any success. I assume that the NIC card is having problems returning the timestamp value to the stack when PTP is configured for IPv6 (IPv4 works ok for both sw & hw timestamping). Copied the observed logs below. MULTICAST IPv6 logs: --------------------------------- Software timestamping (logs show everything is ok): ---------------------------------------------------------------------------- ptp4l -i enp25s0f0 -f /root/linuxptp/configs/default.cfg -6 -S -m -l 7 ptp4l[508710.413]: config item (null).uds_address is '/var/run/ptp4l' ptp4l[508710.413]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[508710.413]: port 1: received link status notification ptp4l[508710.413]: interface index 2 is up ptp4l[508713.814]: port 1: setting asCapable ptp4l[508717.426]: port 1: announce timeout ptp4l[508717.426]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES ptp4l[508717.426]: selected local clock 000f53.fffe.572740 as best master ptp4l[508717.426]: port 1: assuming the grand master role ptp4l[508717.427]: port 1: master tx announce timeout ptp4l[508718.426]: port 1: master sync timeout ptp4l[508719.426]: port 1: master sync timeout ptp4l[508719.427]: port 1: master tx announce timeout ptp4l[508720.426]: port 1: master sync timeout ptp4l[508721.426]: port 1: master sync timeout Hardware timestamping (logs show the tx_timestamp_timeout error): -------------------------------------------------------------------------------------------------- ptp4l -i enp25s0f0 -f /root/linuxptp/configs/default.cfg -6 -S -m -l 7 ptp4l[509643.285]: config item (null).uds_address is '/var/run/ptp4l' ptp4l[509643.285]: port 0: INITIALIZING to LISTENING on INIT_COMPLETE ptp4l[509643.286]: port 1: received link status notification ptp4l[509643.286]: interface index 2 is up ptp4l[509645.875]: port 1: setting asCapable ptp4l[509650.186]: port 1: announce timeout ptp4l[509650.186]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES ptp4l[509650.186]: selected local clock 000f53.fffe.572740 as best master ptp4l[509650.186]: port 1: assuming the grand master role ptp4l[509650.187]: port 1: master tx announce timeout ptp4l[509651.186]: port 1: master sync timeout *ptp4l[509656.191]: timed out while polling for tx timestampptp4l[509656.191]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bugptp4l[509656.191]: port 1: send sync failed* ptp4l[509656.191]: port 1: MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED) ptp4l[509656.191]: waiting 2^{4} seconds to clear fault on port 1 On Fri, Mar 27, 2020 at 6:21 AM Richard Cochran <richardcoch...@gmail.com> wrote: > On Thu, Mar 26, 2020 at 08:58:44PM -0700, Michel Ouellette wrote: > > Line 35 is the UDPv6 configuration as shown above. Seems like str2addr > > returns this error. I'm assuming that I'm wrongly entering the IPv6 > > address. I've tried various IP addresses (link-local, unique local, > global) > > without any success. > > What version of ptp4l are you running? > > There is a fix for this issue, commit > d88b4ff2298b9b6588e03fe94c2e7c0263fb4750. > > However, that commit is not contained in the most recently released > 2.0 version. I suggest building the master branch from source. > > Thanks, > Richard >
_______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users