Comment 1 Andre Klapper 2008-06-12 13:42:34 UTC

Thanks for the report!

Developers also see e.g.
http://www.internettablettalk.com/forums/showthread.php?t=17977
http://lists.maemo.org/pipermail/maemo-developers/2008-March/015008.html

the patch is a trivial one-liner.

Created an attachment (id=779) [details]
A log of the USB data flow when connecting/enabling the gadget to Windows

Just in case; I downloaded some shareware tool that can spy on USB devices and
tried it with N810. The attached log shows what happens on the bus when the
device is connected to the PC. The last request goes from PC to N810, and
there's no response.

I tried building a kernel for the reporter, using the supplied patch.

The one-liner does not apply to the latest 2.6.21 nokia sources though. I tried
also applying some of the changes from the patch series that
0cf4f2de0a0f4100795f38ef894d4910678c74f8 is from, but it just started getting
messy.

I looked through changelogs of the kernels 2.6.22-2.6.25 and I can see there
are more fixes to RNDIS, especially the following:

[ 2.6.22 ]

commit 4149b72eaa74583c361e3aaf5804eb74b72c51f1
Author: David Brownell <david-b@pacbell.net>
Date:   Sun Apr 29 10:09:47 2007 -0700

    USB: handle more rndis_host oddities
...
    Fix a bug where a seeming RNDIS device returns a bogus response during
    device initialization.

commit 178398dca00b276aaa1aded7cded89921f710365
Author: Wu, Bryan <bryan.wu@analog.com>
Date:   Thu Apr 26 00:38:01 2007 -0700

    USB gadget rndis: fix struct rndis_packet_msg_type unaligned bug
...


[ 2.6.23 ]
commit 39d1f8c9fcb241c526efa5fff5869cad7beba98e
Author: Li Yang <leoli@freescale.com>
Date:   Fri Aug 17 08:36:44 2007 -0700

    USB: fsl_usb2_udc: fix bug in processing setup requests

    Kim Liu found that in the original code certain class setup requests
    are wrongly recognized and processed as standard setup requests.
    For that reason gadget ether can't work in RNDIS mode with Windows host.
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(!!!)

[ 2.6.25 ]

commit 41566bcf35a8b23ce4715dadb5acfd1098c1d3e4
Author: Jan Altenberg <jan.altenberg@linutronix.de>
Date:   Tue Feb 19 01:44:50 2008 +0100

    USB: gadget: queue usb USB_CDC_GET_ENCAPSULATED_RESPONSE message
....
    commit 0cf4f2de0a0f4100795f38ef894d4910678c74f8 introduced a bug, which
    prevents sending an USB_CDC_GET_ENCAPSULATED_RESPONSE message. This
    breaks the RNDIS initialization (especially / only Windoze machines
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    dislike this behavior...).
     ^^^^^^^^^^^^^^^^^^^^^^^^
(!!!)

Maybe the driver could be just copied over from latest kernel, sometimes such
tricks work, sometimes don't.

Ugh :-(

Bad news.

I tried today different versions of g_ether.

g_ether backported from 2.6.23 still exhibits same behavior.
g_ether backported from 2.6.25-9 still exhibits same behavior.

Sharp Zaurus with Angstrom kernel 2.6.23 works without problems both with Linux
(CDC) and with Windows (RNDIS).

So problem is not in g_ether like I was thinking, but seems to be in musb. I
get lots of strange errors from musb while I load/remove the g_ether driver,
and besides g_ether works only once - you plug it once into a Windows machine,
it "works" (e.g. you see a new network connection, but when trying to "enable"
it, Windows reports something like "I can't"). If you plug the USB connector
out, you can't make it "work" anymore - even if you rmmod g_ether, Windows will
see it in the best case as a "Unknown device".

I will try to
a) get the kernel sources from ITOS2007 which reportedly has a working NDIS and
use the musb and/or g_ether drivers from it.
b) will look if it's possible to get the latest musb driver from TI and see if
it fixes this problem.

That's it so far.

And regarding my notes above about g_ether patches, I took a deeper look into
the patches:

commit 4149b72eaa74583c361e3aaf5804eb74b72c51f1
Author: David Brownell <david-b@pacbell.net>
Date:   Sun Apr 29 10:09:47 2007 -0700

This patch is for the host-side of RNDIS, not for g_ether.

commit 178398dca00b276aaa1aded7cded89921f710365
Author: Wu, Bryan <bryan.wu@analog.com>
Date:   Thu Apr 26 00:38:01 2007 -0700

This is a one-line patch, which is present (at least) in 2.6.25-9.

commit 39d1f8c9fcb241c526efa5fff5869cad7beba98e
Author: Li Yang <leoli@freescale.com>
Date:   Fri Aug 17 08:36:44 2007 -0700

This patch is for some unrelated UDC, so it doesn't affect the Nokia tablet.

commit 41566bcf35a8b23ce4715dadb5acfd1098c1d3e4
Author: Jan Altenberg <jan.altenberg@linutronix.de>
Date:   Tue Feb 19 01:44:50 2008 +0100

This is the patch I've started my research from (posted in the first message).

So 2.6.25-9 doesn't contain a lot of important changes compared to 2.6.21,
mostly indentation/code style changes.

Yesterday I got the latest kernel from MontaVista with the freshest musb_hdc
driver (something like 2.6.26rc1 level). Then I copied over the whole musb_hdc
to 2.6.21 diablo tree and adapted the code so that it compiles cleanly under
2.6.21.

Unfortunately, this does not help. g_file_storage works fine, but g_ether still
exhibits same problems.

Then I tried the musb_hdrc driver from kernel 2.6.18 (ITOS2007). After booting
the desktop it suddenly crashes and reboots. Looks like it's not quite
straightforward to make it work under 2.6.21.

Overall, it does not look possible to easily make g_ether work in ITOS2008.
Perhaps this bug can be closed :-(

Comment 8 Andre Klapper 2008-07-01 01:41:55 UTC

...so this is a valid bug that isn't fixed upstream? Could be WONTFIX to not
fix it downstream in Maemo, yeah.

Comment 9 Frantisek Dufka 2008-07-02 17:33:00 UTC

(In reply to comment #7)
> Overall, it does not look possible to easily make g_ether work in ITOS2008.
> Perhaps this bug can be closed :-(

Huh? Closing bug because solution is not easy? Interesting concept :-)

BTW, Nokia is using highly customized kernel not mainline or linux-omap so
closing as WONTFIX because of upstream is not appropriate IMO. Also using usb
networking is documented in Maemo SDK
http://maemo.org/development/documentation/pc_connectivity/ so it should be
definitely fixed.

Please try to be fair, maemo.org is not an official Nokia site and Ethernet
peripherial is not advertised by Nokia as a feature of the Internet Tablet. To
enable it you have to gain root first, which is against tablet usage rules ;-)

Sure, it would be nice if somebody at Nokia would find some time to look into
it... but it's all about good will and free time.

Comment 11 Andre Klapper 2008-09-22 14:50:28 UTC

According to the internal ticket,

"the kernel driver in Diablo should be ok.
There is no need to patch g_ether.ko - it can be used with windows. One needs
to change /etc/network/interfaces.
You should put something like:

allow-hotplug usb0
iface usb0 inet static
        address 192.168.2.15
        netmask 255.255.255.0
        network 192.168.2.0
        gateway 192.168.2.1

Don't forget to use linux.inf for installing the driver. You can get linux.inf
in any linux kernel source under Documentation/usb/linux.inf"

Thanks for your hint, I added the line "allow-hotplug usb0" (the rest were
already in place) and now the tablet reboots as soon as desktop appears :-)
Looks like I got a new occupation for this evening...

However, I'm pretty sure I tried pairing diablo with XP in the past, with
absolutely same result as with chinook. Can the guy who says that demonstrate a
working network connection with chinook/diablo and XP?

Comment 13 Frantisek Dufka 2008-09-30 14:46:38 UTC

Still doesn't work for me with newest kernel in 4.2008.36-5. Can we have more
information about working setup? I use usb networking as part of
http://fanoush.wz.cz/maemo/#initfs and it works fine for 770 and N800 with
OS2007 (2.6.18) but fails with any OS2008 (both N800 and N810) including the
latest one. The code is simple
insmod /lib/modules/current/g_ether.ko
ifconfig usb0 $USB_IP up
see usbnet() in
https://garage.maemo.org/plugins/scmsvn/viewcvs.php/trunk/bootmenu/files/bootmenu.sh?revision=32&root=bootmenu&view=markup

This is all with same XP machine. device was installed with linux.inf and
connection appears when connected but it is disabled. When trying to enable it
I see same result as in commment #1.

Comment 14 Andre Klapper 2008-10-21 00:23:03 UTC

(In reply to comment #13)
> Still doesn't work for me with newest kernel in 4.2008.36-5. Can we have more
> information about working setup?

I've quoted all I know already in comment 11.
Let me ping Felipe to get more info.

Comment 15 Frantisek Dufka 2008-10-21 10:47:06 UTC

(In reply to comment #14)
> Let me ping Felipe to get more info.
> 

Well, I may be wrong but I am tracking Nokia kernel sources and keep diffs
between versions and there appears to be no change in g_ether code since this
bug was reported for 2.2007.51-3. Can Felipe provide info when it was fixed or
whether it always worked for him? The information in comment #11 may fix some
userspace problem in configuration but not bug in kernel and also does not help
when bringing up connection by hand via ifconfig (like I do in usb network
recovery mode in modified initfs, comment #13).

*** This bug has been confirmed by popular vote. ***

Comment 17 Andre Klapper 2008-11-26 15:16:28 UTC

> When you load g_ether (modprobe g_ether) do you give it an ip before
> attaching the cable to the windows machine ?
> 
> Without an ip it won't work since there's no socket opened.

(In reply to comment #11)
> Don't forget to use linux.inf for installing the driver. You can get linux.inf
> in any linux kernel source under Documentation/usb/linux.inf"

linux.inf seems to refer to multiple usb8023X.sys and mdismpX.sys files, every
time i download a new copy..  perhaps if it's working for andre, he could
specify which of these, in particular, his machine is using?

(In reply to comment #17)
> > When you load g_ether (modprobe g_ether) do you give it an ip before
> > attaching the cable to the windows machine ?
> > 
> > Without an ip it won't work since there's no socket opened.
> 

Do you mean on the tablet or in XP? On the tablet, usb0 is configured in
/etc/network/interfaces and I do an ifup usb0 before connecting.

On XP, there is no interface to edit unless the cable is connected. The
interface stays deactivated until I activate it (with an ip address set both
for the tcp-ip parameters and in the interface-configuration, "extended" tab -
the latter has two entries, one german, one english! and tends to hang at
closing), but then comes up with the above mentioned error.

what are the chances this answers the problem?

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=fb85d991616046f1b640ed9c4eab9b44908dab74

-----------------------------------------------------------------------
MUSB: Fix index register corruption seen with g_ether and Windows host

author    Anand Gadiyar <gadiyar@ti.com>
    Thu, 21 Aug 2008 14:51:00 +0000 (19:51 +0530)
committer    Greg Kroah-Hartman <gregkh@suse.de>
    Thu, 21 Aug 2008 17:26:34 +0000 (10:26 -0700)
commit    fb85d991616046f1b640ed9c4eab9b44908dab74

If Indexed Mode register accesses are enabled, the ep0_rxstate()
function calls musb_g_ep0_giveback() before writing to the CSR
register. When control returns to this ep0_rxstate, the index
register contents are over-written. This causes the CSR register
write to fail.

Fixed by writing the correct value into the index register before
writing to the CSR.

This was observed only in ep0_rxstate() with g_ether loaded and
the device connected to a MS Windows host PC. Anticipatively fixed
ep0_txstate() as well.
----------------------------------------------------------------------

(this being from linux/kernel/git/torvalds/linux-2.6.git)

hope it might help - i desperately need this to work, and in the meantime could
someone please explain which of the OS200[78] builds has an old enough kernel
to still work, as per the initial description of this problem?  i'm new to all
this, and i apologise for the out-of-band chatter, but where could i find the
version/subversion details for the various builds?

ok, the above (#20) works for me - patched and rebuilt kernel in scratchbox,
flashed new zImage, updated g_ether.ko (probably not necessary, i'm pretty sure
musb stuff is on the kernel side, but didn't check) and suddenly i can talk to
both linux and windows boxes without problems - no code tens, plug and unplug
no problem, all that...

but - i can't tell, unfortunately, if this actually fixed the problem, or the
_other_ issue i've been fighting with is the cause - something (i'm assuming
ke-recv is involved) was absolutely insisting on reloading g_file_storage over
top of g_ether every time the cable is connected.  i fixed this by hacking out
the osso-usb-mass-storage scripts in /usr/sbin because i cannot sort out what
mechanism is involved.

sigh... then i made the mistake of downloading the latest 'features' upgrade,
and now my kernel is back to october...  usb ether still works against linux,
but it'll be a while before i can test against windows again.  figure i might
as well leave the official kernel in place, and see if i can sort out whether
it was the musb patch that fixed the issue, or just the script hacking i did.

am i talking to myself here?  is anyone else still working on this?

(In reply to comment #21)

> sigh... then i made the mistake of downloading the latest 'features' upgrade,
> and now my kernel is back to october...  usb ether still works against linux,
> but it'll be a while before i can test against windows again.  

Hopefully I can try the upgrade with windows within the next 24 hours.

> am i talking to myself here?  is anyone else still working on this?

Not really working, but desperately hoping for a solution. If you can give more
details, I can also tryout your script hacking .

re #22:

there are three scripts /usr/sbin:

osso-usb-mass-storage-enable.sh,
osso-usb-mass-storage-disable.sh
osso-usb-mass-storage-is-used.sh

i just hacked all three to "exit 0" at the top of the script - this seems to
disable g_file_storage module loading completely.  none of them check to see if
g_ether module is loaded, they only know about g_file_storage, and will blindly
shove g_file_storage in there, even when g_ether is loaded.

after this point i get lost - ke-recv also seems to be called when the usb
cable is connected, and i'm assuming there's a matching event on disconnect,
and this is where things seem to be getting hooped. g_ether has just begun
getting connected to the host, and suddenly g_file_storage is trying to take
over.

i'm still looking for where all this gets configured, because i assume all that
really needs to be done is to have these two events check the "usb ethernet
mode" flag, and call a parallel set of three scripts that will set up and tear
down the interface appropriately.

note that this only solves the point to point connection issue - getting out
onto the net via the usb interface is another story, and i suspect it's going
to be much the same problem - trying to get the wireless connection support to
sit back and play ball properly.

postscript - you might want to check out bug #1375 - they're talking about the
same issue there.

(In reply to comment #24)
> postscript - you might want to check out bug #1375 - they're talking about the
> same issue there.

I tried out the new SSU, also with the changes on the three scripts - still the
same: connection to linux works, windows doesn't. I didn't look deeper into
#1375.

Created an attachment (id=1077) [details]
modified usb-helper as described

(i'm not sure how best to attach things to these reports, but it's showing that
 my edited usb-helper script is in there somewhere - in case useful)

i got the same results as rupert when i tried testing the latest ssu kernel
against windows RNDIS, so i downloaded the kernel sources again, noting that
the patch i mentioned in #20 hadn't been applied, re-applied the patch, and
reflashed with the resultant zImage.  unfortunately i did this _before_ i
realised that the ke-recv source was available, so i'm still not sure if the
patch helps, but at least i'm quite certain it's necessary - it's really not a
good idea to be writing on an uninitialised pointer, especially when you're the
kernel.

anyway - on studying the ke-recv source, i discover that all these usb-cable
events are actually hardcoded in there, and that the only conditioning is an
environment variable (OSSO_KE_RECV_IGNORE_CABLE) that is set in the etc rc
scripts that start and stop ke-recv.

this variable is pendant on a grep against lsmod that checks for g_ether, and
really only gets set when the system is booted.

the hacks i suggested before (#21, #23) aren't a good idea...

and nothing i've found seems able to convince the device to boot in network
mode - it always comes up with g_file_storage insmodded.  if anyone can explain
what i'm missing there, i'd be most grateful...

so instead i've modified usb-helper (as attached) to shut down ke-recv before
making the switches to storage or network mode, and then start it again, after
the appropriate module has been loaded.  this ensures that IGNORE_CABLE is set
properly, and therefore that ke-recv will behave as it should.

this WORKS (for me) and i can happily switch between storage and network modes
without having to reboot anything, provided i disconnect the usb cable first.

i've tested (fairly brutally) against both linux and windows XP, and thus far
have not been able to make anything fail.

my heartfelt thanks to whomever approved opening the ke-recv source - without
that information i would probably _still_ be searching for an external config
file, and i have little enough hair left as it is.

Comment 28 Eero Tamminen 2008-12-30 16:26:38 UTC

(In reply to comment #27)
> i got the same results as rupert when i tried testing the latest ssu kernel
> against windows RNDIS, so i downloaded the kernel sources again, noting that
> the patch i mentioned in #20 hadn't been applied, re-applied the patch, and
> reflashed with the resultant zImage.  unfortunately i did this _before_ i
> realised that the ke-recv source was available, so i'm still not sure if the
> patch helps, but at least i'm quite certain it's necessary - it's really not
> a good idea to be writing on an uninitialised pointer, especially when you're
> the kernel.

Added patch keyword & put link to this patch to URL field.


> anyway - on studying the ke-recv source, i discover that all these usb-cable
> events are actually hardcoded in there, and that the only conditioning is an
> environment variable (OSSO_KE_RECV_IGNORE_CABLE) that is set in the etc rc
> scripts that start and stop ke-recv.
> 
> this variable is pendant on a grep against lsmod that checks for g_ether, and
> really only gets set when the system is booted.
> 
> the hacks i suggested before (#21, #23) aren't a good idea...
> 
> and nothing i've found seems able to convince the device to boot in network
> mode - it always comes up with g_file_storage insmodded.  if anyone can
> explain what i'm missing there, i'd be most grateful...
[...]
> my heartfelt thanks to whomever approved opening the ke-recv source - without
> that information i would probably _still_ be searching for an external config
> file, and i have little enough hair left as it is.

If somebody can come up with a Diablo patch that makes ke-recv to support
network mode cleanly, please check that it applies also against the Fremantle
version (there are some changes compared to Diablo version):
https://stage.maemo.org/svn/maemo/projects/haf/trunk/ke-recv/

And please file a bug with that patch about integrating this support to
Fremantle ke-recv.  It helps when community looks into backporting Fremantle
stuff to Diablo.

Comment 29 Faheem Pervez 2009-02-28 18:44:04 UTC

Many thanks for your work into this! 

I have yet to patch my kernel (will do so after writing this...) but some
notes:

I don't know if actually editing osso-usb-mass-storage-disable.sh &
osso-usb-mass-storage-is-used.sh is required as those scripts don't actually do
any insmodding of anything. For osso-usb-mass-storage-enable.sh, I've settled
with at the top:

/sbin/lsmod | grep g_ether > /dev/null
if [ $? = 0 ]; then
 exit 0
fi

(If grep finds g_ether in the lsmod output, it exits with 0. Seeing that
g_ether is loaded in that case, the script exits and g_file_storage is not
loaded. If grep returns 0+, then g_ether isn't loaded and we may as well let
g_file_storage have its moment ;). It's a slightly cleaner hack than just a
plain "exit 0" because g_file_storage will then be inserted if g_ether isn't
there)

g_file_storage is loaded automatically by the /etc/init.d/ke-recv script which
will insist upon loading it *if* g_ether isn't present. To circumvent this, if
you wish, a simple script at /etc/rc2.d/S29-gether saying:
insmod /mnt/initfs/lib/modules/`uname -r`/g_ether.ko

will work because that script will be ran before ke-recv and then ke-recv will
check for g_ether's existence. (but only if we're booting without the charger -
I've only said for this script to be saved in rc2)

(In reply to comment #27)
> and nothing i've found seems able to convince the device to boot in network
> mode - it always comes up with g_file_storage insmodded.  if anyone can explain
> what i'm missing there, i'd be most grateful...
>

Comment 30 Frantisek Dufka 2009-03-16 22:11:45 UTC

(In reply to comment #21)
> ok, the above (#20) works for me

works for me too, the patch is also available here
http://tablets-dev.nokia.com/maemo-dev-env-downloads.php?f=diablo_kernel_usbnet_patch_windows_v0.4.zip
together with binary kernel image. Did not try the kernel image but the patch
indeed solved this issue for me.

Comment 31 Carsten Munk 2009-04-09 12:21:02 UTC

Mer 2.6.21 kernels now have the RNDIS patch, thanks to qwerty12 and the
patcher.

Comment 32 Andre Klapper 2009-04-23 16:57:37 UTC

This is probably a WONTFIX. As far as I know Nokia won't fix this for Diablo,
and I assume that Fremantle uses a different kernel version.

Comment 33 Andre Klapper 2009-05-25 13:56:27 UTC

Closing as FIXED in Fremantle as 2.6.28 is shipped in Fremantle.
The upstream commit listed in comment 20 works as commented in comment 21 and
this patch has been already integrated into Mer, the community backport of
Fremantle for N8x0 devices.
WONTFIX for Nokia's official Diablo releases as already written.

Marking patches of interest to Diablo (Maemo4) community updates, please excuse
the noise.