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
| ||
|
Date: Thu, 30 May 2019 17:57:30 +0300 From: Vladimir Oltean <olteanv@...il.com> To: Richard Cochran <richardcochran@...il.com> Cc: Florian Fainelli <f.fainelli@...il.com>, Vivien Didelot <vivien.didelot@...il.com>, Andrew Lunn <andrew@...n.ch>, "David S. Miller" <davem@...emloft.net>, John Stultz <john.stultz@...aro.org>, Thomas Gleixner <tglx@...utronix.de>, Stephen Boyd <sboyd@...nel.org>, lkml <linux-kernel@...r.kernel.org>, netdev <netdev@...r.kernel.org> Subject: Re: [PATCH net-next 0/5] PTP support for the SJA1105 DSA driver On Thu, 30 May 2019 at 17:30, Richard Cochran <richardcochran@...il.com> wrote: > > On Thu, May 30, 2019 at 12:01:23PM +0300, Vladimir Oltean wrote: > > In fact that's why it doesn't work: because linuxptp adds ptp_dst_mac > > (01-1B-19-00-00-00) and (01-80-C2-00-00-0E) to the MAC's multicast > > filter, but the switch in its great wisdom mangles bytes > > 01-1B-19-xx-xx-00 of the DMAC to place the switch id and source port > > there (a rudimentary tagging mechanism). So the frames are no longer > > accepted by this multicast MAC filter on the DSA master port unless > > it's put in ALLMULTI or PROMISC. > > IOW, it is not linuxptp's choice to use these modes, but rather this > is caused by a limitation of your device. > Didn't want to suggest otherwise. I'll see how I'm going to address that. > > If the meta frames weren't associated with the correct link-local > > frame, then the whole expect_meta -> SJA1105_STATE_META_ARRIVED > > mechanism would go haywire, but it doesn't. > > Not necessarily. If two frames that arrive at nearly the same time > get their timestamps mixed up, that would be enough to break the time > values but without breaking your state machine. > This doesn't exactly sound like the type of thing I can check for. The RX and TX timestamps *are* monotonically increasing with time for all frames when I'm printing them in the {rx,tx}tstamp callbacks. > > I was actually thinking it has something to do with the fact that I > > shouldn't apply frequency corrections on timestamps of PTP delay > > messages. Does that make any sense? > > What do you mean by that? Is the driver altering PTP message fields? No. The driver returns free-running timestamps altered with a timecounter frequency set by adjfine and offset set by adjtime. I was wondering out loud if there's any value in identifying delay messages in order to not apply this frequency adjustment for their timestamps. -Vladimir > > Thanks, > Richard
Powered by blists - more mailing lists