netdev - Re: [PATCH net-next v4 0/3] Linn Ethernet Packet Sniffer 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]

Message-ID: <5500251B.8010900@linn.co.uk>
Date:	Wed, 11 Mar 2015 11:20:59 +0000
From:	Stathis Voukelatos <stathis.voukelatos@...n.co.uk>
To:	Richard Cochran <richardcochran@...il.com>
CC:	<linux-kernel@...r.kernel.org>, <netdev@...r.kernel.org>,
	<devicetree@...r.kernel.org>
Subject: Re: [PATCH net-next v4 0/3] Linn Ethernet Packet Sniffer driver

Hi Richard,

On 06/03/15 15:22, Richard Cochran wrote:
> I don't really know what the problem here is.  Yes, there is some
> networking configuration that you need to do when administering a
> network using PTP protocols.  But these protocols (1588 aka PTP, and
> 802.1AS aka gPTP) do offer means for dealing with this.  In
> particular, there is no danger mixing 1588 devices with audio devices,
> because the gPTP protocol uses a different transport flag.
>
> In any case, this has nothing at all to do with the kernel interface.

Our feeling is that we will have to test and verify that a move to gPTP
will fit with the use cases that we have to support and that will
require a fair amount of effort and rewrite of application software.
If the driver is not acceptable with the current interface we may need
to maintain it as a private patch until we are ready to move to gPTP
as you recommend.

>
> If you want to try and integrate your custom protocols into the
> networking stack, by all means please post them.  I would certainly
> support expanding the time stamping interface to include your
> protocol's packet types (like adding them to hwtstamp_rx_filters).
> Maybe that would be enough for you?

I was referring to the Songcast protocol we are using which is part
of the OpenHome suite (www.openhome.org) and runs on top of UDP.
It could be filtered by testing the first 5 bytes of the payload.
In our implementation we also add the destination IP and port to
the filter to make it more reliable, but hwtstamp_rx_filters cannot
accept parameters. However, I will test that and maybe come back with
a patch to expand the hwtstamp_rx_filter enum initially?

>
> Thanks,
> Richard
>

Thank you,
Stathis
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html