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

Reply via email to