Re: [PTP][KSZ9477][p2p1step] Questions for PTP support on KSZ9477 device

[Vladimir Oltean <olteanv@gmail.com>]

On Thu, Jun 26, 2025 at 11:33:25PM +0200, Lukasz Majewski wrote:
> The second problem which I've found after some debugging:
> - One device is selected as grandmaster clock. Another one tries to
>   synchronize (for the simpler setup I've used two the same boards with
>   identical kernel and KSZ9477 setup).
> 
> - tshark from host on which we do have grandmaster running:
>   IEEEI&MS_00:00:00 PTPv2 58 Sync Message
>   LLDP_Multicast PTPv2 68 Peer_Delay_Req Message
>   IEEEI&MS_00:00:00 PTPv2 58 Sync Message
>   LLDP_Multicast PTPv2 68 Peer_Delay_Req Message
> 
> So the SYNC is send, then the "slave" responds correctly with
> Peer_Delay_Req_Message.

Peer delay measurement is an independent process, not a response to Sync
messages.

> But then the "grandmaster" is NOT replying with PER_DELAY_RESPONSE.
> 
> After some digging into the code it turned out that
> dsa_skb_defer_rx_timestamp() (from net/dsa/tag.c) calls
> ptp_classify_raw(skb), which is a bpf program.
> 
> Instead of returning 0x42 I do receive "PTP_CLASS_NONE" and the frame is
> dropped.
> 
> That is why grandmaster cannot send reply and finish the PTP clock
> adjustment process.
> 
> The CONFIG_NET_PTP_CLASSIFY=y.
> 
> Any hints on how to proceed? If this would help - I'm using linux
> kernel with PREEMPT_RT applied to it.

Which frame is classified as PTP_CLASS_NONE? The peer delay request?
That doesn't sound convincing, can you place a call to skb_dump() and
show the contents of the PTP packets that don't pass this BPF filter?
Notably, the filter matches for event messages and doesn't match for
general messages, maybe that confused your debugging process in some way.