Hi Richard, On Sun, 17 Mar 2019 at 11:16, Richard Cochran <richardcoch...@gmail.com> wrote:
> > Unfortunately there are networks (GMs?) in the wild which appear to do > > this, and in not all cases do ptp client users have control over the > > master. The first time we saw this an iptables rule to drop unusually > > tiny frames was deemed sufficient, but it's come up again so I looked > > to a more general solution. > > I'm not familiar with zero length mcast UDP on the PTP ports. Can you > explain more about how this happens? > You have seen this twice? Who is sending such traffic? > Unfortunately, I have no idea how or why this happens - I don't have access myself to the networks in question and have only learned this much through emailed .pcap files on the afflicted client interfaces. Additionally, the GM's are operated by the network operators, who are separate to the folks running ptp4l (I guess they get PTP as part of a connectivity package). In both cases they come at regular intervals and appear to sandwiched between GET CURRENT_DATASET and GET TIME_PROPERTIES_DATASE management queries so possibly some quirk of a centralised client monitoring system. The frames look as below[1]. Both cases are identical looking in the relevant parts, except the other case has a Mellanox OUI. I suspect the originator may be an GPS/PTP appliance-type box and just use different network cards. > > Are there situations where recvmsg could return zero to indicate an > > actual "error" as opposed to "successfully received the empty string"? > > I guess we could pay closer attention to errno if so. > > Yes, if we need to. > If we can trust the manpage, zero should not be an error so am cautiously optimistic that <0 is sufficient for UDP error detection. The closest to authoritative I can find is in "UNIX Network Programming, Volume 1"[2], which states 0 is acceptable for a datagram protocol I'm still working out exactly where & why they come from but it's pretty clear they exist and it would be good not to barf too hard regardless of the source, even to prevent anyone on the subnet desynching clients for laughs. Cheers, David PS: [1] Example taken from a pcap Frame 26: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) Ethernet II, Src: SuperMic_xx:yy:zz (ac:1f:6b:xx:yy:zz), Dst: IPv4mcast_01:81 (01:00:5e:00:01:81) Internet Protocol Version 4, Src: 192.168.12.100, Dst: 224.0.1.129 0100 .... = Version: 4 .... 0101 = Header Length: 20 bytes (5) Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT) Total Length: 28 Identification: 0xc717 (50967) Flags: 0x4000, Don't fragment Time to live: 1 Protocol: UDP (17) Header checksum: 0x042c [validation disabled] [Header checksum status: Unverified] Source: 192.168.12.100 Destination: 224.0.1.129 User Datagram Protocol, Src Port: 320, Dst Port: 320 Source Port: 320 Destination Port: 320 Length: 8 Checksum: 0x4ed0 [unverified] [Checksum Status: Unverified] [Stream index: 0] <and some zero-padding to make up a 64-byte minimum Ethernet frame> [2] https://books.google.com.au/books?id=ptSC4LpwGA0C&pg=PA241&dq=%22This+also+means+that+a+return+value+of+0+from+recvfrom+is+acceptable+for+a+datagram+protocol%22&hl=en&sa=X&ved=0ahUKEwinj4CT-IrhAhWGbysKHR_IBZAQ6AEIKjAA#v=onepage&q=%22This%20also%20means%20that%20a%20return%20value%20of%200%20from%20recvfrom%20is%20acceptable%20for%20a%20datagram%20protocol%22&f=false
_______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel