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  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:	Thu, 30 Jan 2014 10:03:02 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Sarah Sharp' <sarah.a.sharp@...ux.intel.com>,
	Mark Lord <mlord@...ox.com>
CC:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: Help testing for USB ethernet/xHCI regression

From: Sarah Sharp
> On Tue, Jan 28, 2014 at 11:30:51PM -0500, Mark Lord wrote:
> > On 14-01-28 03:30 PM, Sarah Sharp wrote:
> > ..
> > > Can you please pull this branch, which contains a 3.13 kernel with
> > > David's patch reverted, and test whether your USB ethernet device works
> > > or fails?
> >
> > Fails.  dmesg log attached.
> 
> It's funny, because there's certainly data transferred over endpoint
> 0x82, even though there were link TRBs in the middle of transfers.  Did
> the "untransferred" messages stop when the device stopped working, or
> did they continue?

What I saw was that the USB transfers continued, but the ethernet
transmits stopped.
This rather changes the packets generated by TCP at both ends.
The effect can be seen in the timestamps (etc) in the USB trace.
There are still tx and rx packets, after a while they'll only
happen on ever-increasing timeouts.

That was the point where I wrote the NOP patch just to see if
it made a difference. I didn't really expect one!

I think that the LINK trb splits a 1k usb message in two.
This well and truly confuses the ethernet part of the ax88179_178a
hardware to the point where it doesn't even reset itself on the
next sub 1k message.

It might be that other targets (eg the smsx95xx) is more resilient
and only loses the single packet - which won't be immediately obvious.

	David


--
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

Powered by blists - more mailing lists