> list.linux-usb-devel #6211 (0 + 0 more) > [1] > [1] [linux-usb-devel] USB driver might not generate a zero length packet > (2) > Date: Tue Mar 05 16:56:34 PST 2002 > Lines: 93 > Distribution: local > Reply-To: "yang xiaoyong" <[EMAIL PROTECTED]> > > Hi all gurus, > > I notice "USB driver might not generate a zero length packet" when I am > using a bluetooth stack called Bluez 2.0 -pre6 with Transilica Bluetooth USB > modules on REdhat7.2 (kernel 2.4.17 and 2.4.9) to try the Bluez utility > l2ping. > > If I take the default package size 20 value to send it to my bluethooth > device through USB, it fails because the Linux > driver doesn't properly terminate a USB OUT transfer with a zero length > packet when the transfer size is an integer multiple of the packet size. Use > it with size 10, or size 40 though, and it works, because that produces a > USB transfer size that terminates with a partial packet. So far only size 20 > i.e. the default value does not for me. i tried changing the default value > to 10 or 40 but size does not work for me yet. > > At the end I am have drawn the following conclusion: > > "The problem is not with using the default size for l2ping. The problem lies > with using any size that results in a USB transfer length that is an integer > multiple of the packet size supported by a particular device. (In our case, > the packet size for the bulk endpoint is 32 bytes. ** the size 20 in > decimal plus > 12 bytes of Bluetooth protocol overhead. is 32**.) > > In the case , specifying a size of 20 bytes results in a 32 byte > transfer when all the overhead is added. I could find other > size choices that resulted in transfer sizes of 64, 96, ... once the proper > allowances for overhead bytes added by the protocol is accounted for, and > which would show the same problem. > > **The USB spec. stipulates that a transfer consists of one or more packets. > It is terminated either by a partial length packet or, when the transfer > size is an integer multiple of the packet size, a zero length packet.** > > In both spec USB 1.1(page187) and 2.0 (page 228) by using > the "zero length" to search. "If the data structure is an exact multiple of > wMaxPacketSize for the pipe, the function will return a zero-length packet > to indicate the end of the Data stage." > > So I believe that **the Linux USB driver (as of kernel 2.4.17) does not > generate a zero length > packet when it should.**" > > Neither usb-uhci not uhci make the problem better. The problem has been > verified by direct inspection of the bus using a protocol analyzer. Firmware > is also verified OK.
The spec is correct, but a lot of hardware have problems with zero length packets. You may be able to get around this by inserting an additional byte of data if your outgoing bulk transfer is a multiple of the packet length and then ignoring it at the receiving end. If you are sending network frames the upper levels will ignore it for you. Otherwise you will need to have a length in your protocol wrapper so that you can determine how much valid data you should keep (i.e. discard the extra trailing byte). > I also heard from Greg KH <[EMAIL PROTECTED]> > "The usb driver should not have to do anything special to cause a 0 > length packet to be sent, if you are correct about this being necessary. > So I do not this this would be a problem with the BlueZ driver. > > Do you have any bus traces from looking at a USB protocol analyzer that > show this problem? > > And don't count out there still being problems in usb.c or hub.c, we > found another one just a short while ago :)" > > So the problem is very likely in the usb.c or hub.c, right? > Any one encountered and solved the similar problem ? Any hit? tips? > comments? -- [EMAIL PROTECTED] _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
