netdev - Re: [DSA] fallback PTP to master port when switch does not support it

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]

Date:   Tue, 5 Apr 2022 16:21:47 +0200
From:   Matej Zachar <zachar.matej@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org
Subject: Re: [DSA] fallback PTP to master port when switch does not support it

Hi Andrew,
thank you for the quick response.

> On 5. 4. 2022, at 0:04, Andrew Lunn <andrew@...n.ch> wrote:
> 
> 
> Did you try just running PTP on the master device? I'm wondering if
> the DSA headers get in the way?

Yes this is exactly the problem as the master device is used as “conduit interface”
so the switch is dropping the frames as there are no correct DSA headers present.

So running ptp4l on eth0 (master) interface configures the hardware time-stamping correctly but no traffic is received.
running it on lan1 (slave) interface you get the packets but no hardware time-stamping support.

I though this should be in a way similar to the case when you run ptp4l over vlan interfaces (without dsa switch) - it fallbacks to the master port.

> 
> What i don't like about your proposed fallback is that it gives the
> impression the slave ports actually support PTP, when they do not. And
> maybe you want to run different ports in different modes, one upstream
> towards a grand master and one downstream? I suspect the errors you
> get are not obvious. Where as if you just run PTP on the master, the
> errors would be more obvious.
> 

I’m using switch ports in “single port” configuration so there is lan1 lan2 interfaces connected to different network segments.
So it can behave as you described in upstream/downstream configuration as “boundary” PTP clock or as a redundancy where
lan1 & lan2 are connected to physically separate networks - including switches and cables. 

> 
> And this is another advantage of just using master directly. You can
> even use master when the switch ports do support PTP.

I do not see how is that possible as the DSA headers are in the way and packets get dropped by the switch but maybe I am missing something.

My second idea was to check the return values and fallback based on that so the switch driver could still implement
.get_ts_info and .port_hwtstamp_get/set from dsa_switch_ops struct. This was just quick proof to test if it would work over slave interface.

If there is better approach I could explore I’m happy to try.

Matej.