maemo.org Bugzilla – Full Text Bug Listing
|Summary:||g_ether / RNDIS is broken in kernel 2.6.21|
|Product:||[Maemo Official Platform] Core||Reporter:||Andrew Zabolotny <anpaza>|
|Status:||RESOLVED FIXED||QA Contact:||linux-kernel-bugs|
|Priority:||Medium||CC:||andre_klapper, bugzilla, carsten.munk, dufkaf, eero.tamminen, maemo, rupert.schlick, trippin1|
|Version:||4.1 (4.2008.23-14)||Keywords:||community-diablo, patch|
A log of the USB data flow when connecting/enabling the gadget to Windows
modified usb-helper as described
SOFTWARE VERSION: 2.2007.51-3 STEPS TO REPRODUCE THE PROBLEM: 0. become root 1. rmmod g_file_storage 2. insmod /mnt/initfs/lib/modules/2.6.21-omap1/g_ether.ko 3. Download the INF file mentioned on this page: http://maemo.org/community/wiki/USBnetworkingWinXP/ 4. connect n810 to a windows XP machine 5. when it asks, feed it the INF file 6. Open the network connections and try to enable "Linux USB Ethernet/RNDIS Gadget" EXPECTED OUTCOME: Should enable the connection and then be able to communicate with the device. ACTUAL OUTCOME: After a few seconds it tells you "Connection failed" REPRODUCIBILITY: always EXTRA SOFTWARE INSTALLED: n/a OTHER COMMENTS: I think that this kernel patch will fix it: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6-stable.git;a=commit;h=a086bcfa9947a04075f446fe4ee435070ced9bb9 The RNDIS part of g_ether in 2.6.21 was broken because of this patch: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6-stable.git;a=commit;h=0cf4f2de0a0f4100795f38ef894d4910678c74f8 User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; ru-RU; rv:1.9b5) Gecko/2008043010 Fedora/3.0-0.60.beta5.fc9 Firefox/3.0b5
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 <firstname.lastname@example.org> 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 <email@example.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 <firstname.lastname@example.org> 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 <email@example.com> 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 <firstname.lastname@example.org> 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 <email@example.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 <firstname.lastname@example.org> 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 <email@example.com> 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 :-(
...so this is a valid bug that isn't fixed upstream? Could be WONTFIX to not fix it downstream in Maemo, yeah.
(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.
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?
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.
(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.
(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. ***
> 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 <firstname.lastname@example.org> Thu, 21 Aug 2008 14:51:00 +0000 (19:51 +0530) committer Greg Kroah-Hartman <email@example.com> 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 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.
(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.
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... >
(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.
Mer 2.6.21 kernels now have the RNDIS patch, thanks to qwerty12 and the patcher.
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.
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.