netdev - RE: [PATCH 4/4] asix: C1 DUB-E100 double rx_urb

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:	Wed, 11 Dec 2013 11:30:54 -0000
From:	"David Laight" <David.Laight@...LAB.COM>
To:	"Dean Jenkins" <Dean_Jenkins@...tor.com>, <netdev@...r.kernel.org>,
	<davem@...emloft.net>
Subject: RE: [PATCH 4/4] asix: C1 DUB-E100 double rx_urb_size to 4096

> From: Dean Jenkins
> It seems that for the C1 hardware variant of the D-Link DUB-E100
> that the rx_urb_size of 2048 is truncating IP fragmented packets due
> to multiple Ethernet frames being present in a single URB.
> 
> A simple ping test shows a loss of ping responses
> ping 172.17.0.10 -f -c 200 -s 1965
> (172.17.0.1 is the IP address of the target)
> 
> In the worse case, this test requires a 2049 byte data buffer size
> to hold the IN bulk transfer but the URB is 2048 in size so the last byte
> of the Ethernet frame is lost and the Ethernet frame is truncated.
> 
> This modification resolves "asix_rx_fixup() Bad Header" errors caused by
> truncation of the Ethernet frame due to the URB buffer being too small.
> 
> Therefore, increase the rx_urb_size to 4096 to accommodate
> multiple Ethernet frames being present in a single URB.

I don't think this will help - you've only moved the error.
If the hardware manages to feed over 4k of ethernet frame data
into a single usb bulk data frame it will still go wrong.

The rx code needs to keep the partial ethernet frame until the
next usb bulk data urb arrives.
(This only applies if the urb is a multiple of the usb packet size
and isn't known to have been terminated by a zero length block.)

This should work provided the urb size is a multiple of the usb
packet size - I don't know if a 1536 (3*512) skb fits into a 4k page.
If it doesn't you should probably allocate a 5k skb (8k memory).
(I don't believe there is any point allocating a size inbetween?)

USB3 devices (on USB3 ports) need to allocate buffers that are
multiples of 1k so that they can process very long bulk rx usb data.

	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