netdev - Re: [PATCH net-next 0/5] PTP support for the SJA1105 DSA driver

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:   Wed, 29 May 2019 23:41:22 +0300
From:   Vladimir Oltean <olteanv@...il.com>
To:     Richard Cochran <richardcochran@...il.com>
Cc:     f.fainelli@...il.com, vivien.didelot@...il.com, andrew@...n.ch,
        davem@...emloft.net, john.stultz@...aro.org, tglx@...utronix.de,
        sboyd@...nel.org, linux-kernel@...r.kernel.org,
        netdev@...r.kernel.org
Subject: Re: [PATCH net-next 0/5] PTP support for the SJA1105 DSA driver

On 5/29/19 7:52 AM, Richard Cochran wrote:
> On Wed, May 29, 2019 at 02:56:22AM +0300, Vladimir Oltean wrote:
>> Not all is rosy, though.
> 
> You can sure say that again!
>   
>> PTP timestamping will only work when the ports are bridged. Otherwise,
>> the metadata follow-up frames holding RX timestamps won't be received
>> because they will be blocked by the master port's MAC filter. Linuxptp
>> tries to put the net device in ALLMULTI/PROMISC mode,
> 
> Untrue.
> 

I'm sorry, then what does this code from raw.c do?

> 	mreq.mr_ifindex = index;
> 	mreq.mr_type = PACKET_MR_ALLMULTI;
> 	mreq.mr_alen = 0;
> 	if (!setsockopt(fd, SOL_PACKET, option, &mreq, sizeof(mreq))) {
> 		return 0;
> 	}
> 	pr_warning("setsockopt PACKET_MR_ALLMULTI failed: %m");
> 
> 	mreq.mr_ifindex = index;
> 	mreq.mr_type = PACKET_MR_PROMISC;
> 	mreq.mr_alen = 0;
> 	if (!setsockopt(fd, SOL_PACKET, option, &mreq, sizeof(mreq))) {
> 		return 0;
> 	}
> 	pr_warning("setsockopt PACKET_MR_PROMISC failed: %m");


>> but DSA doesn't
>> pass this on to the master port, which does the actual reception.
>> The master port is put in promiscous mode when the slave ports are
>> enslaved to a bridge.
>>
>> Also, even with software-corrected timestamps, one can observe a
>> negative path delay reported by linuxptp:
>>
>> ptp4l[55.600]: master offset          8 s2 freq  +83677 path delay     -2390
>> ptp4l[56.600]: master offset         17 s2 freq  +83688 path delay     -2391
>> ptp4l[57.601]: master offset          6 s2 freq  +83682 path delay     -2391
>> ptp4l[58.601]: master offset         -1 s2 freq  +83677 path delay     -2391
>>
>> Without investigating too deeply, this appears to be introduced by the
>> correction applied by linuxptp to t4 (t4c: corrected master rxtstamp)
>> during the path delay estimation process (removing the correction makes
>> the path delay positive).
> 
> No.  The root cause is the time stamps delivered by the hardware or
> your driver.  That needs to be addressed before going forward.
> 

How can I check that the timestamps are valid?

Regards,
-Vladimir

> Thanks,
> Richard
>