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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250627215804.mcqsav2x6gbngkib@skbuf>
Date: Sat, 28 Jun 2025 00:58:04 +0300
From: Vladimir Oltean <olteanv@...il.com>
To: Lukasz Majewski <lukma@...x.de>
Cc: Oleksij Rempel <o.rempel@...gutronix.de>,
	Richard Cochran <richardcochran@...il.com>,
	Vadim Fedorenko <vadim.fedorenko@...ux.dev>, netdev@...r.kernel.org,
	Arun Ramadoss <arun.ramadoss@...rochip.com>,
	Tristram.Ha@...rochip.com, Christian Eggers <ceggers@...i.de>
Subject: Re: [PTP][KSZ9477][p2p1step] Questions for PTP support on KSZ9477
 device

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.