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: <20200705232656.ztf465cffu3hn7g4@lion.mk-sys.cz>
Date:   Mon, 6 Jul 2020 01:26:56 +0200
From:   Michal Kubecek <mkubecek@...e.cz>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     netdev <netdev@...r.kernel.org>, Chris Healy <cphealy@...il.com>
Subject: Re: [PATCH ethtool v4 0/6] ethtool(1) cable test support

On Sun, Jul 05, 2020 at 06:24:21PM +0200, Andrew Lunn wrote:
> On Sun, Jul 05, 2020 at 02:44:47AM +0200, Michal Kubecek wrote:
> > On Wed, Jul 01, 2020 at 03:07:37AM +0200, Andrew Lunn wrote:
> > > Add the user space side of the ethtool cable test.
> > > 
> > > The TDR output is most useful when fed to some other tool which can
> > > visualize the data. So add JSON support, by borrowing code from
> > > iproute2.
> > > 
> > > v2:
> > > man page fixes.
> > > 
> > > v3:
> > > More man page fixes.
> > > Use json_print from iproute2.
> > > 
> > > v4:
> > > checkpatch cleanup
> > > ethtool --cable-test dev
> > > Place breakout into cable_test_context
> > > Remove Pair: Pair output
> > 
> > Hello Andrew,
> > 
> > could you please test this update of netlink/desc-ethtool.c on top of
> > your series? The userspace messages look as expected but I'm not sure if
> > I have a device with cable test support available to test pretty
> > printing of kernel messages. (And even if I do, I almost certainly won't
> > have physical access to it.)
> 
> Hi Michal
> 
> Currently there are three PHY drivers with support: Marvell, Atheros
> at803x, and bcm54140. And you can do some amount of testing without
> physical access, you can expect the test results to indicate the cable
> is O.K.
> 
> However, i will give these a go.
> 
> Some sort of capture and reply would be interesting for this, and for
> regression testing. The ability to do something like
> 
> ethtool --monitor -w test.cap
> 
> To dump the netlink socket data to a file,  and
> 
> ethtool --monitor -r test.cap
> 
> to read from the file and decode its contents. Maybe this is already
> possible via nlmon?

Such feature would definitely be useful. It should be possible to
capture the data using nlmon and tcpdump but whenever I tried to use
nlmon to capture netlink data, I found it rather difficult to capture
only the traffic I was interested in. For the second part (feeding the
captured data to ethtool), we would probably need some tool which would
work like tcpreplay. Having support in ethtool makes very good sense and
it shouldn't require too much extra code, perhaps a dependency on
libpcap.

In the long term, I would like to write a packetdrill-like framework for
selftests where testcases would be scripts consisting of statements
saying e.g. "run with this command line", "expect this netlink message",
"reply with this netlink message", "expect this output" etc. But that
would be more complex and ability to capture into a file and replay it
would b useful independently of that.

Michal

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ