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  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:	Sun, 23 Nov 2014 17:19:59 +0000
From:	Ben Hutchings <>
To:	Richard Cochran <>
Cc:, David Miller <>,
	Stefan Sørensen 
Subject: Re: [PATCH net-next] vlan: Pass ethtool get_ts_info queries to real

On Sun, 2014-11-23 at 17:05 +0100, Richard Cochran wrote:
> On Sun, Nov 23, 2014 at 03:15:12AM +0000, Ben Hutchings wrote:
> > This assumes that the same PTP capabilities apply to VLAN-tagged frames.
> > I don't think it's at all safe to assume that RX filter modes other than
> > HWTSTAMP_FILTER_ALL will include VLAN-tagged frames.  I think it is
> > necessary to define additional modes that explicitly include VLAN-tagged
> > frames.
> Unsafe? How?

I mean that the assumption is wrong in general.  So these changes will
result in silent failure to enable RX timestamps, on some devices.

> Do you mean that some HW cannot identify and time stamp PTP frames
> when VLAN tagged? That is surely disappointing for people who shell
> out money for such cards, but it is hardly unsafe.
> > I also disagree in general that reconfiguring a VLAN device should make
> > changes to the underlying device that affect more than just that VLAN,
> > i.e. SIOCSHWTSTAMP should not be passed through.  SIOCGHWTSTAMP could be
> > passed through, but rx_filter would need adjustment (VLAN-tagged modes
> > on the underlying devices become untagged modes on the VLAN device).
> The whole filter list with every last combination (at least, the ones
> at the time) came directly from a early, limited HW design.  Sane,
> modern PTP hardware provides time stamps regardless of whether a frame
> is VLAN tagged or not.

I would hope so.  However, this is non-standard - IEEE802.1AS
*explicitly forbids* the use of VLAN tags.  Linux's software PTP
classifier also doesn't yet handle 802.1ad VLAN tags.

> I don't see any reason not to make our stack even more ugly just to cater
> to broken hardware.

So failure to implement a non-standard extension is now 'broken'?

> I have nothing against adding VLAN to the SIOCGHWTSTAMP list, because
> the hardware people *really* use all have:
> So adding more won't hurt. (But it won't help either. If your HW
> cannot time stamp Layer2 and you transmit Layer2, you simply never get
> a time stamp.)
> But please don't hold up progress just for this sort of thing.

This is progress for some devices, false advertising for others.


Ben Hutchings
Never put off till tomorrow what you can avoid all together.

Download attachment "signature.asc" of type "application/pgp-signature" (812 bytes)

Powered by blists - more mailing lists