On Sunday 15 July 2007, Aras Vaichas wrote: > Hi, > > I can't seem to Google any information or precedents on anyone who has > obtained > WHQL certification for the Linux RNDIS USB gadget host drivers? I understand > that the actual binary drivers are provided by Windows anyway. So, can anyone > shed some light on this? > > Has anyone obtained a valid catalog file for linux.inf? Surely the catalog > file > should be the same for all installation, so all we need is one "linux.cat" > file, right?
I've not heard of anyone who's done that, but that sounds like it's the way it "should" be. > The problem I wish to solve are customers who complain that Windows throws up > the WHQL certification "error" when they plug our device into a Windows PC. > It > would certainly help to increase our customer's confidence in the product if > Windows didn't put up this error so we are looking in to getting the driver > "certified". That's Microsoft's racket: you've got to pay them for each product you ship. (Of course, they want to do it with Linux too...) In this case, one issue is that Microsoft's RNDIS driver, and for that matter their whole TCP/IP and USB stacks, appears to be rather buggy, and Microsoft has seemed unwilling (or is it unable?) to fix their own bugs. Many folk have reported such problems, but appended is one person's unusually detailed (and informative!!) summary of test failures he has personally observed ... all in MS-Windows, never Linux. As I recall, this person was one of several who's also noted that the Linux peripheral never needed rebooting/reconfiguring ... but that the Microsoft code will usually "recover" after a 3-finger-salute of that MSFT environment. (Which as any developer knows, points the finger of blame squarely at state held inside the Microsoft software.) It's theoretically possible that Linux could do something differently, to avoid making MS-Windows misbehave ... something not covered in the public RNDIS protocol specifications. I don't think that WHQL is expected to resolve that class of issues; though if it could do so, I think various Linux users would be happier! For the moment, the preferred solution appears to be to use some drivers from MCCI on the MS-Windows side, using the "CDC Subset" mode of that USB gadget network driver. - Dave (The following comments were sent to me by one Linux developer, who shall remain nameless here for the moment:) RNDIS: If we unplug and plug in USB between the Linux device and Windows and do this a lot we see (and I say this as someone who has personally unplugged and plugged in USB in my test environment thousands of times): 1) USB UDP packet streams coming from our Linux device will stop making it into our app but still make it to the Windows side as viewable by Ethereal. Somewhere in a layer above where [Wireshark] watches MS will decide to throw out the packets. Sometimes the steady stream of UDP packets suddenly starts getting transmitted back up into application. Stopping and starting applications does not help and so it is not a problem with the specific Winsock. I even used some freeware UDP writer and reader test apps to prove that our app code was not to blame. 2) Plugging and unplugging USB dozens of times occasionally causes UDP packets coming from Linux devices into the ethernet interface to stop getting up into the user space application. You heard me right: Pulling the USB interface up and down messes up UDP on the ethernet interface. I can keep telnet sessions going on the ethernet interface while some ethernet UDP packet stream from Linux to Windows stops. I've even seen pairs of UDP packet streams from two Linux devices stop coming into a PC due to events on the USB interface. 3) We see these problems with both Win2K and WinXP. 4) If I go to the latest hot fix version of RNDIS from MS (this is only available from MS tech support) that fixes some USB bug that crashes XP (which crashes I've had) then the time it takes for the USB driver on Linux to report "full speed" goes up from 1-2 seconds with occasional 16-20 sec waits to over half the time taking over 20 seconds. Why (and how) should the presence of this fix (which changes other USB-related drivers as well) cause Windows to do something that slows down bus speed negotiation on USB? I do not know. 5) We can make our RNDIS problems much less severe by setting a static IP address on the Windows USB interface and by using multicast rather than broadcast messages. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
