David,
finally, here is our RNDIS USB Gadget Driver - see the attached patch
against the gadget-2.4 BK tree as of now. It shouldn't be too difficult
to port this to 2.6.
The patch adds support for Microsoft's RNDIS protocol to the standard
g_ether driver. This makes it possible to connect a Linux USB gadget to
any standard Windows machine and <*PALIM!*> there is a new USB network
interface on the Windows side on which you can speak TCP/IP :-)
Unfortunately, although it works with the original Microsoft driver, you
need an inf file on the windows side; you can download the template for
that directly from M$.
Thanks to Auerswald GmbH for sponsoring this work!
Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hornemannstra?e 12, 31137 Hildesheim, Germany
Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4
Robert Schwebel wrote:
> David,
>
> finally, here is our RNDIS USB Gadget Driver - see the attached patch
> against the gadget-2.4 BK tree as of now. It shouldn't be too difficult
> to port this to 2.6.
Yowsza! I've been looking forward to this ... :)
I'll look it over and see how the 2.6 merge goes, and probably run
some revisions by you. The autoconfiguration updates will make this
more complicated, since g_ether is starting to support a more dynamic
configuration model; the HH.org crew need that, so PDA Linux distros
don't need to hard-wire as much knowledge about hardware targets
into their kernels.
> The patch adds support for Microsoft's RNDIS protocol to the standard
> g_ether driver. This makes it possible to connect a Linux USB gadget to
> any standard Windows machine and <*PALIM!*> there is a new USB network
> interface on the Windows side on which you can speak TCP/IP :-)
Which is exactly what a lot of Linux solution providers need to see;
I'm sure this will get a lot of use. Applause!
(Although I personally would prefer that Microsoft adopt vendor-neutral
protocols, instead of pushing the rest of the industry to adopt things
that are MSFT-biased ... for some reason, they haven't listened to almost
anyone on such topics. Oh well. ;)
> Unfortunately, although it works with the original Microsoft driver, you
> need an inf file on the windows side; you can download the template for
> that directly from M$.
>
> Thanks to Auerswald GmbH for sponsoring this work!
I'll add them to the official "thank you" list on the
http://www.linux-usb.org/gadget webpage.
- Dave
> Robert
>
>
On Thu, 2004-03-25 at 14:52 -0800, David Brownell wrote:
> (Although I personally would prefer that Microsoft adopt vendor-neutral
> protocols, instead of pushing the rest of the industry to adopt things
> that are MSFT-biased ... for some reason, they haven't listened to almost
> anyone on such topics. Oh well. ;)
Out of interest -- have they (or has anyone else) invented a 'file
system' USB device yet? For exporting some file systems, pretending to
be a block device really isn't very useful.
--
dwmw2
On Thu, Mar 25, 2004 at 11:11:45PM +0100, Robert Schwebel wrote:
> Unfortunately, although it works with the original Microsoft driver, you
> need an inf file on the windows side; you can download the template for
> that directly from M$.
I don't understand this comment, it would probably be very wise to add
something to Documentation/ about this.
> - .bDeviceClass = DEV_CONFIG_CLASS,
> + .bDeviceClass = 0x02,
Is this wise?
Thanks for this work, looks cool!
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
On Fri, Mar 26, 2004 at 12:59:47PM +0100, bert hubert wrote:
> > Unfortunately, although it works with the original Microsoft driver, you
> > need an inf file on the windows side; you can download the template for
> > that directly from M$.
>
> I don't understand this comment, it would probably be very wise to add
> something to Documentation/ about this.
You need such an .inf file on the windows side; M$ has a template where
you simply need to insert your vendor/device ID and other stuff. I'm not
sure about the license for these files, so I don't know if it is allowed
to distribute them.
> > - .bDeviceClass = DEV_CONFIG_CLASS,
> > + .bDeviceClass = 0x02,
>
> Is this wise?
Until now DEV_CONFIG_CLASS was 0xFF, which results in Windows getting
hickup. If you directly set this to 0x02 (Network Device) Win is happy.
Might be a good idea anyway.
Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hornemannstra?e 12, 31137 Hildesheim, Germany
Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4
On Fri, Mar 26, 2004 at 01:19:28PM +0100, Robert Schwebel wrote:
> You need such an .inf file on the windows side; M$ has a template where
> you simply need to insert your vendor/device ID and other stuff. I'm not
> sure about the license for these files, so I don't know if it is allowed
> to distribute them.
And that .inf describes 'Linux'? No matter what the license is, you can link
to it and instruct people on how to change it. You could even show pieces of
the .inf with the linux data filled in ('fair use').
I ask about this because I know that to get adequate testing coverage,
experimenting with this code should be as easy as possible. Something like
'visit this URL and paste in the following: (...) and now do such and such
in windows and you should be set'.
I'll happily write this for you if you provide the pointers.
Good luck!
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
David Woodhouse wrote:
>
> Out of interest -- have they (or has anyone else) invented a 'file
> system' USB device yet? For exporting some file systems, pretending to
> be a block device really isn't very useful.
There's a file system protocol used by many digital still cameras,
which isn't actually camera-specific. Not MSFT-specific either.
Originally called "Picture Transfer Protocol" (PTP) it's actually
more of a remote hierarchical filesystem protocol ... with an event
channel (handy for "new picture" or "inserted new flash memory")
and some built-in search capabilities ("what JPGs do you have").
The strangest capability was a file type tag, which isn't actually
that bizarre.
As with RNDIS, and USB Mass Storage, I understand that support for
PTP is part of MS-Windows since about Win2K. So a PTP gadget
driver would probably be a useful contribution to Linux.
- Dave
Robert Schwebel wrote:
> On Fri, Mar 26, 2004 at 12:59:47PM +0100, bert hubert wrote:
>
>>>- .bDeviceClass = DEV_CONFIG_CLASS,
>>>+ .bDeviceClass = 0x02,
>>
>>Is this wise?
>
>
> Until now DEV_CONFIG_CLASS was 0xFF, which results in Windows getting
> hickup. If you directly set this to 0x02 (Network Device) Win is happy.
Actually I suspect setting it to USB_CLASS_COMM would be preferred, in
RNDIS-specific config descriptors....
- Dave
On Fri, Mar 26, 2004 at 07:58:04AM -0800, David Brownell wrote:
> >>>- .bDeviceClass = DEV_CONFIG_CLASS,
> >>>+ .bDeviceClass = 0x02,
> >>
> >>Is this wise?
> >
> >
> >Until now DEV_CONFIG_CLASS was 0xFF, which results in Windows getting
> >hickup. If you directly set this to 0x02 (Network Device) Win is happy.
>
> Actually I suspect setting it to USB_CLASS_COMM would be preferred, in
> RNDIS-specific config descriptors....
We have tried that, Windows does not like it. The only constellation
where it worked was setting the device descriptor's bConfigClass=0x02.
RNDIS is a sensitive beast. Do one bit different results in that uggly
"Error 10" message on the Windows side. We saw it when we started with
the driver, we saw it when the driver was half way finished and we will
see it again if somebody tweaks the driver without exactly knowing what
the guys at Microsoft smoked when they designed that protocol :-)
Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hornemannstra?e 12, 31137 Hildesheim, Germany
Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4
Robert Schwebel wrote:
> On Fri, Mar 26, 2004 at 07:58:04AM -0800, David Brownell wrote:
>
>>>>>- .bDeviceClass = DEV_CONFIG_CLASS,
>>>>>+ .bDeviceClass = 0x02,
>>>>
>>>>Is this wise?
>>>
>>>
>>>Until now DEV_CONFIG_CLASS was 0xFF, which results in Windows getting
>>>hickup. If you directly set this to 0x02 (Network Device) Win is happy.
>>
>>Actually I suspect setting it to USB_CLASS_COMM would be preferred, in
>>RNDIS-specific config descriptors....
(since: #define USB_CLASS_COMM 2)
> We have tried that, Windows does not like it. The only constellation
> where it worked was setting the device descriptor's bConfigClass=0x02.
Sorry, I meant "device" descriptors. Yes, I noticed their "spec"
had strange things to say. Is there some reason you're not including
the CDC header and union descriptors? That spec does talk about those,
and the erratum I found also talks about better CDC ACM conformance.
> RNDIS is a sensitive beast. Do one bit different results in that uggly
> "Error 10" message on the Windows side. We saw it when we started with
> the driver, we saw it when the driver was half way finished and we will
> see it again if somebody tweaks the driver without exactly knowing what
> the guys at Microsoft smoked when they designed that protocol :-)
I thought it was "just say no to vendor-neutral protocols" crack ...
although that close to BC they would have much better options! ;)
The purist in me is annoyed that rather than just defining a purely
vendor-specific protocol, they re-used bits and pieces of the USB-IF
CDC-ACM spec. It's not like they needed _any_ of it. (Unless maybe
subtle sabotoge of CDC was a goal?)
Different topic: I noticed that on PXA you were using "ep5-int".
That's documented as always using DATA0 -- data toggle not working.
Was that making any trouble for you? I've never actually tried
using those endpoints, because of that functional limitation.
Also it looks like you've only tested this on PXA hardware.
Most of the patch is the (R)NDIS support code, which is easy
to merge, but the "g_ether" updates will take longer.
- Dave
> Robert
On Fri, Mar 26, 2004 at 09:45:15AM -0800, David Brownell wrote:
> >We have tried that, Windows does not like it. The only constellation
> >where it worked was setting the device descriptor's bConfigClass=0x02.
>
> Sorry, I meant "device" descriptors. Yes, I noticed their "spec"
> had strange things to say. Is there some reason you're not including
> the CDC header and union descriptors? That spec does talk about those,
> and the erratum I found also talks about better CDC ACM conformance.
USB_CLASS_COM is surely ok. The descriptors may be a relict from the
time where the CDC equivalents where not in the driver...
The problem is that, as it is now, it works. The whole RNDIS stuff is
extremely time intensive to debug: when you have one odd value in some
place, Windows just says "Error 10" and you have to guess what you did
wrong. No further information available. So the best way to be
successful may be to check it in as it is, maybe add some FIXMEs, and
let the masses test the code. Then cleanup the remaining issues step by
step and wait until nobody crys any more :-)
> Different topic: I noticed that on PXA you were using "ep5-int".
> That's documented as always using DATA0 -- data toggle not working.
> Was that making any trouble for you? I've never actually tried
> using those endpoints, because of that functional limitation.
Well, there is no other interrupt endpoint on the PXA, and it somehow
works :-)
> Also it looks like you've only tested this on PXA hardware.
It was hard enough :-)
> Most of the patch is the (R)NDIS support code, which is easy
> to merge, but the "g_ether" updates will take longer.
Ok. We have tried to make the design as minimal-invasive as possible...
Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hornemannstra?e 12, 31137 Hildesheim, Germany
Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4
Robert Schwebel wrote:
> ...
>
> The problem is that, as it is now, it works. The whole RNDIS stuff is
> extremely time intensive to debug: when you have one odd value in some
> place, Windows just says "Error 10" and you have to guess what you did
> wrong. No further information available. So the best way to be
> successful may be to check it in as it is, maybe add some FIXMEs, and
> let the masses test the code. Then cleanup the remaining issues step by
> step and wait until nobody crys any more :-)
Well, what I merge is necessarily going to work on more
hardware than just PXA ... it'll work over net2280 (at high
speed), goku, and surely other hardware. In most cases
that'll just require sanity testing. Maybe I can get Julian
to test on SH3, and it sounds like Andrew is getting close
on the MediaQ.
Once I can see it work, then it'll be ready for that more
widespread testing. (Do penguins actually cry?)
>>Different topic: I noticed that on PXA you were using "ep5-int".
>>That's documented as always using DATA0 -- data toggle not working.
>>Was that making any trouble for you? I've never actually tried
>>using those endpoints, because of that functional limitation.
>
>
> Well, there is no other interrupt endpoint on the PXA, and it somehow
> works :-)
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.
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?
Also, which versions of MS-Windows did you test against? Some of
the MSFT docs suggest version-specific protocol quirks. That's
where I expect most of the end-user problem reports to appear!
Which is why I'd like to have all the documented protocol quirks
(including the other CDC descriptors) resolved before this starts
to get really broad testing.
- Dave
On Fri, Mar 26, 2004 at 11:45:58AM -0800, David Brownell wrote:
> Well, what I merge is necessarily going to work on more hardware than
> just PXA ... it'll work over net2280 (at high speed), goku, and surely
> other hardware. In most cases that'll just require sanity testing.
> Maybe I can get Julian to test on SH3, and it sounds like Andrew is
> getting close on the MediaQ.
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.
> Once I can see it work, then it'll be ready for that more widespread
> testing. (Do penguins actually cry?)
Only if they have to read Microsoft specifications :-)
> 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...
> 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...
> 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 ;)
Robert
--
Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hornemannstra?e 12, 31137 Hildesheim, Germany
Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4
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
On Fri, Mar 26, 2004 at 07:44:10AM -0800, David Brownell wrote:
> There's a file system protocol used by many digital still cameras,
> which isn't actually camera-specific. Not MSFT-specific either.
>
> Originally called "Picture Transfer Protocol" (PTP) it's actually
> more of a remote hierarchical filesystem protocol ... with an event
> channel (handy for "new picture" or "inserted new flash memory")
> and some built-in search capabilities ("what JPGs do you have").
> The strangest capability was a file type tag, which isn't actually
> that bizarre.
>
> As with RNDIS, and USB Mass Storage, I understand that support for
> PTP is part of MS-Windows since about Win2K. So a PTP gadget
> driver would probably be a useful contribution to Linux.
A host driver "USB PTP Storage" would be really nice too. First
as a generic camera interface, second to access a gadget with the
PTP interface.
(Please embarrass me by saying there already is one, I'll be so happy
I won't care :-) ).
I have a PTP camera and would certainly be happy to test such a driver.
Time to write it is a different matter.
Don Reid
>>There's a file system protocol used by many digital still cameras,
>>which isn't actually camera-specific. Not MSFT-specific either.
>>...
>
> A host driver "USB PTP Storage" would be really nice too. First
> as a generic camera interface, second to access a gadget with the
> PTP interface.
>
> (Please embarrass me by saying there already is one, I'll be so happy
> I won't care :-) ).
There isn't one. There are two. No need to be embarrassed ... ;)
They're both user-mode drivers. "gPhoto2", and "jPhoto". The
author of jPhoto (moi) hasn't had time to update that code in
ages.
- Dave
On Sat, Mar 27, 2004 at 09:02:18AM -0800, David Brownell wrote:
> >>There's a file system protocol used by many digital still cameras,
> >>which isn't actually camera-specific. Not MSFT-specific either.
> >>...
> >
> >A host driver "USB PTP Storage" would be really nice too. First
> >as a generic camera interface, second to access a gadget with the
> >PTP interface.
> >
> >(Please embarrass me by saying there already is one, I'll be so happy
> >I won't care :-) ).
>
> There isn't one. There are two. No need to be embarrassed ... ;)
>
> They're both user-mode drivers. "gPhoto2", and "jPhoto". The
> author of jPhoto (moi) hasn't had time to update that code in
> ages.
These are applications, not file system interfaces like USB Mass Storage.
I want to mount the camera or gadget file system and access it from any
program, not run a separate app to fetch files like Mass Stor. mounts
a memory device.
Why create a dedicated app like a camera interface instead of using your
favorite image browser on some files?
--
Don Reid
On Sat, 2004-03-27 at 18:47 -0800, don wrote:
> These are applications, not file system interfaces like USB Mass Storage.
> I want to mount the camera or gadget file system and access it from any
> program, not run a separate app to fetch files like Mass Stor. mounts
> a memory device.
>
> Why create a dedicated app like a camera interface instead of using your
> favorite image browser on some files?
Bear in mind also that the reason I asked is because I want to export
_real_ file systems this way, so you can plug your iPAQ in and access
its file system without having to do it over NFS.
--
dwmw2
don wrote:
>>>A host driver "USB PTP Storage" would be really nice too. First
>>>as a generic camera interface, second to access a gadget with the
>>>PTP interface.
>>
>>There isn't one. There are two. No need to be embarrassed ... ;)
>>
>>They're both user-mode drivers. "gPhoto2", and "jPhoto". The
>>author of jPhoto (moi) hasn't had time to update that code in
>>ages.
>
>
> These are applications, not file system interfaces like USB Mass Storage.
> I want to mount the camera or gadget file system and access it from any
> program, not run a separate app to fetch files like Mass Stor. mounts
> a memory device.
As Andrew Zabolotny commented, NFS _does_ work today from those
devices. Except that it doesn't work to MS-Windows hosts, unless
they've been taught other parts of the protocol stack.
Presumably Samba over RNDIS would work from Windows, but that
would need extra work from many Linux hosts. Tradeoffs...
> Why create a dedicated app like a camera interface instead of using your
> favorite image browser on some files?
Well, PTP should take less memory inside the device/gadget than
a network stack, though it'd be less flexible. And there's
also something to be said for less code in the kernel, and a
simpler device setup model ... especially for the kinds of
products that'd be considering something like PTP.
But I think the basic answer to your question is probably just
that nobody's yet written, or at least submitted, PTP client
or server kernel code for Linux.
- Dave
Robert Schwebel wrote:
>>Most of the patch is the (R)NDIS support code, which is easy
>>to merge, but the "g_ether" updates will take longer.
>
>
> Ok. We have tried to make the design as minimal-invasive as possible...
And that pretty much worked ... I've sent Greg a 2.6
version, tested with net2280 and goku_udc, so I hope
that'll appear in some "-mm" patch soonish (and then
presumably in 2.6.6-early).
It does need testing on PXA though.
- Dave