linux-kernel - Re: [Patch] Increase USBFS Bulk Transfer size

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:	Fri, 14 Oct 2011 21:21:53 +0200
From:	Johannes Stezenbach <js@...21.net>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Markus Rechberger <mrechberger@...il.com>,
	Greg KH <gregkh@...e.de>, USB list <linux-usb@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [Patch] Increase USBFS Bulk Transfer size

On Thu, Oct 13, 2011 at 10:58:39AM -0400, Alan Stern wrote:
> On Thu, 13 Oct 2011, Markus Rechberger wrote:
> 
> > And for those who are curious about the logfiles:
> > Not working one as proposed by Alan that the full buffer size should
> > be split into 2 requests:
> > 
> > ffff8800b38d9f00 1231540351 S Bi:2:013:1 -115 12288 <
> > ffff8800b38d96c0 1231540404 S Bi:2:013:1 -115 11776 <
... 
> This is very interesting.  There are only two things that could be
> happening: Either the device sends different data during the two tests,
> or there's a bug in the kernel.
> 
> Now, it is possible the device is sending bad data.  The initial parts
> of the two logs do not agree exactly; there are numerous small
> differences in the control data sent by the device and by the program.  
> I don't know whether they are significant, but if they aren't, there's
> no reason for the device to send different bulk data.  The transfer
> size certainly cannot account for it.  Indeed, even if the transfer
> size were only 512 bytes, the first data packet should still be the 
> same.

I don't really want to help Markus with his proprietary, binary-only
userspace driver crap, but I wonder why nobody seems to remember
how the USB protocol works on the wire?  The transfer size is
never seen by the device, thus it cannot matter if two small URBs
or one large URB are queued.  What matters is the packet size.
Apparently the device can only handle fixed size packets
of either 188 or 2*188 byte, thus it breaks with 12288 or 11776.
The endpoint's wMaxPacketSize might reflect this.
I guess a transfer size of e.g. 188*60=11280 would work.
See the first mail of this thread.

See also Sergei's comment in
http://lkml.org/lkml/2011/10/12/183


Johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/