On Wednesday 13 December 2006 2:17 pm, Ole André Vadla Ravnås wrote: > Great work!
You did most of it, I just did cleanup. :) > I found some time to test the revised driver this > evening, and I came up with the following proposed changes: Exactly what this needed. I don't have any of these devices ... ;) > 1) ActiveSync RNDIS devices don't have the USB_CDC_HEADER, so I had to > change the ActiveSync-specific checks in usbnet_generic_cdc_bind to > ignore cdc_state.info. Tested and works just fine (it's not used > anywhere in the code as far as I can tell). > > Patch (attached): linux-2.6.19-git-cdc_ether-rndis-ignore-header.patch Right, I realized I shouldn't have added that after I sent it. I merged this into the (updated) patch. > 2) It turns out there aren't any batched IN packets as I said earlier. That's good, since the host explicitly says "don't batch packets". :) > After debugging this issue further I discovered that RNDIS_MSG_INIT's > MaxTransferSize, sent by the host, is the value that > usbnet.rx_urb_size should be set to. If this is set to something lower > the device will (obviously) prepare larger URB payloads than what we > expect, and thus we'll fetch partial ones. This results in horrible > performance and makes the device stop responding after attempting a > few transfers. > > Patch (attached): linux-2.6.19-git-rndis_host-rx_usb_size-fix.patch This patch looks wrong. Instead, how about this theory: the peripheral is using the "pad with zeroes to end of packet" option on packets it sends, but the rndis_host code wasn't expecting that. The reason your patch worked was because it was creating HUGE rx buffers, which also coincidntally happened to allow that padding. I've updated the patch to allow padded RX buffers like that. > 3) To better mimic the Windows driver's behavior I changed > CONTROL_BUFFER_SIZE from 1024 to 1025 bytes. It's highly unlikely that > any devices actually discriminate on this, it just makes for less > differences when comparing the two drivers' traffic. OK. I commented the motivation for that strange number though. > I also lowered > the control timeout from 10 to 5 seconds, though on second thought it > would probably make more sense to have the driver set this depending > on whether it's an ActiveSync device or not (RNDIS 1.0 vs RNDIS > post-1.0). 10 seconds is absurd, and the USB 2.0 spec says 5 seconds even if the RNDIS spec has all kinds of crazy-talk. I commented the issue more completely and just left the more standard value; we'll see if it's a problem. > I also removed the list of curious issues from one of the comments as > it's not currently known exactly what causes those other devices to > not work, as I've proven myself wrong on every single one of my > earlier assumptions. OK. If you have time, or know someone who does, it would be a Good Thing to see if the documentation that Microsoft handed over to help address its antitrust issues with the European Commisisson can help clarify just WTF this protocol really _is_ ... and to tell them if the documents don't answer such questions. (As I strongly suspect they won't, but I can be cynical.) > After writing a userspace network driver, usb-rndis-ng [1], for the > ActiveSync RNDIS devices, not doing anything special at all, one of > the devices not working with rndis_host just worked (without correct > peripheral alignment, keepalives, using the status endpoint, etc.). > This leads me to believe that it's a timing-issue -- I'll try to find > some time one day to look at this in detail, using my cheezy hardware > USB sniffer to compare the traffic. Somehow that level of driver bug in MSFT code would not surprise me. Thanks for helping move this forward! - Dave ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
