On the other hand, when #ptpd is bound to an #Ethernet bridge member in #Linux where an IPv4 address is not assigned, it refuses to run and complains.
#ptpd can't therefore use hardware #timestamping on a Linux bridge member,
as it knows nothing about bridges, and must be manually configured for
software timestamping on the bridge itself as a fallback. Moreover, ptpd2
lacks logging for which #SO_TIMESTAMPING or #SO_BINTIME mode it is using.
PSA for people doing network #protocol development in 2026: If you bridge your laptop's #Ethernet port for #KVM guests to run in bridge mode, you can't use hardware timestamping directly for time synchronization, unless you run #IEEE #1588 in Annex F (Ethernet) mode. This applies to #chrony, #ptp4l and #ptpd equally. None of them know anything about bridged operation.
I now have a working #IEEE #1588 hardware-corrected #time sync setup using an #Intel #I226V card. No #Arista switch required. FreeBSD #ptpd slave sees #linuxptp master. Yet to test with the #NVidia #Mellanox #ConnectX-4 LX clients in #FreeBSD though. #BeagleBone Black support appears broken. Awaiting a #SiRFStar IV USB #GPS with alleged #PPS capability, and yet to recover my #GPSDO unit from my aunt's attic in Fife.