Hi, Thanks to the sniffs you provided I've now analysed the sniffs, and can't say I see any big differences. So to sum it up:
Working: HTC Wizard - TI OMAP 850 (Ole Andre, Richard) HTC Charmer - TI OMAP 850 (Volker Christian) Not working: HTC Universal - Intel XScale PXA270 (Peter) Dell Axim X51v - Intel XScale PXA270 (Jimmy) Needless to say, the common thing is the CPU, so it's probably safe to assume that the RNDIS implementation is different and might be more picky. Anyhow I've updated usbhound, my usb traffic analysis tool, to properly parse all of the RNDIS protocol. Screenshot showing Peter's sniff analyzed: http://projects.collabora.co.uk/~oleavr/usbhound.png It supports exporting the RNDIS transactions (summary and full), and exporting all Ethernet-frames to .pcap, for opening it with Ethereal. The source code for 0.2.0 is here: http://projects.collabora.co.uk/~oleavr/usbhound-0.2.0.tar.bz2 It includes two of my sniffs, plus Peter's and Jimmy's, under the sample/ subdirectory. The only real difference I've noticed so far is that we (the Linux-driver, rndis_host) don't query for OID_GEN_MEDIA_CONNECT_STATUS, but I don't think this is of any relevance. However, short put, RNDIS uses two "channels", one control channel and one data channel. The control channel is where the initial communication starts, and basically just tells the device to initialize itself, gets the MAC address so that it can be assigned to the local interface, and sets a non-zero packet filter so that packets can start flowing. After the packet filter has been set data starts flowing on the data channel, which uses two BULK endpoints, IN and OUT. So, on to the point: The the official RNDIS spec states that after submitting an RNDIS message to the control channel endpoint the host should NOT poll the endpoint, but instead listen for a message on the interrupt endpoint. The message expected there when a reply is ready should be "0x00000001 0x00000000", 8 bytes long (conveniently also the same size as that endpoint's wMaxPacketSize), in little-endian, where only the first DWORD is relevant (the second one is reserved), and has only one value defined, which is RESPONSE_AVAILABLE -- 0x00000001. When it receives this, it should read the reply from the control endpoint. However, what rndis_host does is just ignore the interrupt endpoint and instead it polls the control channel endpoint until it gets a reply (or times out). This works fine for the devices mentioned above, but I'm not sure whether it is what's causing the issues with the other devices. I'll try changing rndis_host to use the interrupt endpoint, so we can see if it makes any difference. I'd appreciate it if you could study the rndis transactions as well (in the usbhound .tar.bz2 above), I might have been blinded of some details after having looked at it for too long. :) Regards, Ole André ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642 _______________________________________________ Synce-devel mailing list Synce-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/synce-devel
