[Synce-devel] USB RNDIS compatibility issues

[<ol...@gm...>]

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=E9