On Thursday, 12 November 2020, 16:28:44 CET, Christian Eggers wrote:

Hi Vladimir,

On Tuesday, 10 November 2020, 20:32:45 CET, Vladimir Oltean wrote:

quoted

But something is still wrong if you need to special-case the negative
correctionField, it looks like the arithmetic is not done on the correct
number of bits, either by the driver or by the hardware.

I got it! 

I got it not!

While keeping the (negative) correction field works perfect when using
PTP over L2 (what I did the last weeks), this causes an unwanted side effect
when using UDP:

...

User Datagram Protocol, Src Port: 319, Dst Port: 319

    Source Port: 319
    Destination Port: 319
    Length: 62
 
 Checksum: 0x2285 incorrect, should be 0x2286 (maybe caused by "UDP checksum offload"?)

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    [Checksum Status: Bad]
    [Stream index: 0]
    [Timestamps]

Precision Time Protocol (IEEE1588)

    0000 .... = transportSpecific: 0x0
    .... 0011 = messageId: Peer_Delay_Resp Message (0x3)
    0000 .... = Reserved: 0
    .... 0010 = versionPTP: 2
    messageLength: 54
    subdomainNumber: 0
    Reserved: 0
    flags: 0x0000
    correction: 5579788,000000 nanoseconds
    Reserved: 0
    ClockIdentity: 0x849000fffe0980f7
    SourcePortID: 1
    sequenceId: 785
    control: Other Message (5)
    logMessagePeriod: 127
    requestreceiptTimestamp (seconds): 0
    requestreceiptTimestamp (nanoseconds): 0
    requestingSourcePortIdentity: 0x849000fffe0980f6
    requestingSourcePortId: 2

While correction field is ok (residential delay ~5ms, using one printk...),
the UDP checksum is off by one in all PDelay_Resp messages.

The KSZ device offers on option to set the UDP checksum to zero, but this also
didn't help and additionally wouldn't work for IPv6.

It seems that I should return to "moving T2 from the correction field to the
tail tag" on tx.
 
regards
Christian