Re: [ANNOUNCE] RNDIS Gadget Driver

[David Brownell <david-b@pacbell.net>]

Robert Schwebel wrote:

> A broader variety of controllers would indeed be helpful. When you have
> the stuff integrated the way you think it's right, just tell me and I'll
> test if it still works on our testbed. 

OK, that'll work fine.  Probably next week sometime.


>>It's not as if the protocol actually _needs_ an interrupt endpoint,
>>though the MSFT spec says it does. It's actually simpler for the host
>>to poll for completion on the control endpoint; none of the requests
>>should take very long to finish anyway. An RNDIS host might not even
>>notice those "toggle broken" issues.
> 
> 
> You probably underestimate the mental sensibility of Windows machines.
> We have seen cases where the Windows host just floods you with
> interrupts when it is not happy with things like these... 

Any system where BSOD is anything other than a screensaver is
lacking many kinds of sensibility ... :)

That question was mostly for curiousity.  The issue with interrupt
endpoints and data toggle is trivially resolved by using ep6in-bulk
instead of ep5in-int.  Which is what the autoconfig version will
likely end up doing, since default quality-of-service model for
interrupt endpoints includes having working data toggle.  PXA is
wierd in that way, but it's got endpoints to burn.


>>Did you have any evidence that the MSFT host was actually using that
>>interrupt endpoint? Like CATC snooping showing it never tried to
>>collect responses until the interrupt packet arrived?
> 
> 
> We have seen the packets with the protocol analyzer. I think we agree
> that using an interrupt endpoint just to announce that the gadget has a
> message for the host available, but that's how M$ designed it... 

Sure it gets sent, but does it get used?  If it does,
does the data toggle matter, or is MSFT by default
ignoring the toggle (and hence letting that needless
data stream be undetectably corrupted)?


>>Also, which versions of MS-Windows did you test against? Some of the
>>MSFT docs suggest version-specific protocol quirks.
> 
> 
> Win 98, XP, 2000. Auerswald currently tests all available other
> variants, and the tests they invented are _really_ crazy ;)

OK, so good basic coverage.  Modulo bugs introduced by
various service packs or national releases ... ;)

- Dave