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. 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? Just for the infomation, the Transilica bluetooth USB modules used to has the firmware problem but fixed. Messages from the vendor: "I used to get the error complained about the "buffer over flow" or "pipe broken", due to the incompatibility of the firmware with Linux. I have found the problem by using a USB protocol analyzer, and directly observed the bus traffic. During enumeration, and to read data on the control endpoint in general, the host first has to send a setup packet which contains the length of the data that the host expects to get the next time it reads from the control endpoint. When enumerating for Microsoft, that host always specified the maximum size, which is 255. We would respond with 16 bytes, which is the maximum size our specific device supports on that endpoint. This allowed us to get by with ignoring the length field. So when Linux specified that it wanted 8 bytes, say, on the next read, we would go ahead and send 16 bytes, causing the driver to complain. So now we've changed the firmware to use the lesser of the maximum packet size or the requested length." Is it related to the current problem? Thanks in advance. rgs, yxy _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
