Modaco - Tether won't end, reboot needed

[GoogleCodeExporter]

Which device (manufacturer, type)?
HTC Hero

Which firmware is installed?
Modaco 2.9 core

What version of wireless tether are you using?
1.60 final

What steps will reproduce the problem?
1.Start tether (default wifi mode)
2.Connect to it from laptop (works)
3.Try to stop tether

What is the expected output? What do you see instead?
Expected: Tether to stop
What I see: It shows the working ring indefinitely, I have to press Back
for it to disappear. But it never works again until reboot. It always hangs
on the progress message.

Please provide any additional information below.
Shell (./tether stop) freezes too, can be exited by Ctrl+C.
Log doesn't contain anything! (Only when trying to stop the second time
after the first freeze, "Removing wlan.ko failed", then always empty until
reboot.
When trying to rmmod wlan.ko, it complained that `uname -r` (kernel
version) directory doesn't exist, so I recreated it in /system/lib/modules,
but even though rmmod wlan.ko succeeded, the bug stayed the same.

I think that the new kernel is to blame, it worked in modaco 2.8.

Original issue reported on code.google.com by zwzser...@gmail.com on 14 Nov 2009 at 2:15

[GoogleCodeExporter]

Now I have noticed that all the tether processes since the first tether stop 
keep
hanging in ps.

Original comment by zwzser...@gmail.com on 14 Nov 2009 at 2:24

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Oh ... hero-roms are making troubles all the time. "tether stop" is not able to 
remove
the module and hangs - that could probably be solved by creating symbolic links.

Where is the wlan.ko module located? What is the output of "uname -r" (i don't 
even
have the uname-binary installed on my phones)?

Original comment by harald....@gmail.com on 14 Nov 2009 at 2:45

[GoogleCodeExporter]

I have found out that it only freezes when done through the GUI. If I keep
start-stopping it from the shell, it will work (with symlink). I have an idea 
why
this might happen - a nested run of sh, see the PS output:

  746 10108      740 S    sh -c su -c "/data/data/android.tether/bin/tether stop
  747 0          740 S    sh -c /data/data/android.tether/bin/tether stop
  750 0          676 D    /data/data/android.tether/bin/tether stop
  754 0         2072 R    ps

uname -r returns 2.6.27-mck-teknologist-1.8
 - the kernel version. It helps to add this symlink to /system/lib/modules.
ln -s /system/lib/modules /system/lib/modules/`uname -r`
With this, it works from the shell at least. Please see to the double sh.

Original comment by zwzser...@gmail.com on 14 Nov 2009 at 2:51

[GoogleCodeExporter]

  856 0          740 S    sh -c wlan_loader -f /system/etc/wifi/Fw1251r1c.bin -
  857 0         2652 D    wlan_loader -f /system/etc/wifi/Fw1251r1c.bin -e /pro
  862 0          740 S    /system/bin/sh -
  875 0          740 S    sh -c wlan_loader -f /system/etc/wifi/Fw1251r1c.bin -
  876 0         2652 D    wlan_loader -f /system/etc/wifi/Fw1251r1c.bin -e /pro
  886 0          740 S    sh -c wlan_loader -f /system/etc/wifi/Fw1251r1c.bin -
  887 0         2652 D    wlan_loader -f /system/etc/wifi/Fw1251r1c.bin -e /pro

The ordinary client wifi is also broken until restart. These hang and cannot be 
killed.

Original comment by zwzser...@gmail.com on 14 Nov 2009 at 3:21

[GoogleCodeExporter]

Mmmmh ... the command-line rmmod makes use (most likely) of the busybox which 
can
probably handle if the modules are not located in /system/lib/modules. If I 
remember
correctly we had an issue with the madoco busybox (rmmod) some weeks ago (rmmod 
was
looking into /system/lib/modules`uname -r` but the module was located in
/system/lib/modules. That was one reason why I have integrated loading/unloading
modules into the "tether"-binary (which was previously a shell-script). 

If that changed now AGAIN ... I don't know what to say. This should be fixed by 
the
rom-cook! I'm not able to do all those changes on weekly-basis.

Looks like that "capnbry" has figured out why tethering does not work on stock 
roms -
see issue 188. If those troubles with madoco-rom continues I would recommend to 
use a
rom with less modifications (a hero-version of our app will probably come soon).

Original comment by harald....@gmail.com on 14 Nov 2009 at 7:15

[GoogleCodeExporter]

I understand that it is hard to work without proper assistance from modaco's 
part,
but I am not a Linux coder myself, I am learning from what I see here. All I 
know is
that the tether program freezes on stop without any error in the log. Could you
possibly make the logging more verbose near the beginning? Can you get some 
clues
from the processes hung?
I didn't understand all that much from thread 188, but if it helps you find the
problem, it will be okay.
Also, I might have not put it the right way, but once the freezing occurs, 
1) Tether will always freeze on any action, and
2) WiFi will be useless for anything until restart.

Original comment by zwzser...@gmail.com on 14 Nov 2009 at 7:30

[GoogleCodeExporter]

I have tried all of the previous versions of your application and also some 
older
wlan.ko files, but I'm desperate. Every time I think it's already fixed, it 
does the
error again. (I's unpredictable, happens about 60% each try). I have PM'd the 
Modaco
admin, but I don't think this will change anything.
It seems that wlan.ko is to blame, it won't unload, but who knows, it might 
depend on
something else which races to be unloaded first. Could you please make sure that
dnsmasq and network interface complete before trying the rmmod?

Original comment by zwzser...@gmail.com on 15 Nov 2009 at 1:12

[GoogleCodeExporter]

Issue 166 has been merged into this issue.

Original comment by harald....@gmail.com on 15 Nov 2009 at 1:57

[GoogleCodeExporter]

Seeing two different topics getting merged, have you possibly found the common 
cause?

Original comment by zwzser...@gmail.com on 15 Nov 2009 at 2:02

[GoogleCodeExporter]

It looks to me that issue 166 (wep-encryption not working) and this issue are 
both 
related to the wlan.ko-module - at least that's what I think.

You could try to install a rooted stock-image (or a rom with less 
modifications). That 
might help - the rooted stock cdma hero-rom (sprint htc hero) for instance 
works now 
(issue 188) with version 1.61-pre1.

Original comment by harald....@gmail.com on 15 Nov 2009 at 2:10

• Changed title: Modaco - Tether won't end, reboot needed

[GoogleCodeExporter]

Can you please explain to me why wlan.ko from different versions won't work? 
Can I
take wlan.ko from said pre-rooted stock ROM?
The killer application for me is now compcache. If it was possible to install 
it in
the stock ROM, I might consider switching to it. But I happen to use dropbear 
too...
Ahhh. This is bad. Do these people compile those modules themselves?

Original comment by zwzser...@gmail.com on 15 Nov 2009 at 2:16

[GoogleCodeExporter]

If you build a new kernel (with new modules) you have to recompile the 
wlan-module as
well! compcache are kernel-modules - you have to patch a kernel, recompile the 
kernel
itself and the wlan-module. 

dropbear can be installed without recompiling the kernel ... maybe the boot.img 
has
to be modified (scripts which allow to extract/pack these files exist) but yeah 
...
that's it.

Anyway ... I do think that this issue is because the recompiled wlan.ko module 
- I'm
pretty sure that this issue won't exist on the original kernel (including 
wlan.ko).

Original comment by harald....@gmail.com on 15 Nov 2009 at 2:47

[GoogleCodeExporter]

Is there any other way to forcibly remove the module than rmmod -rf? 
As for the kernel compilation, no thanks, I am trying to get ARM Ubuntu working 
and
it is working 6 hours straight and not finished... very frustrating (previous 
attempt
failed after 10 hours of run!). Do you think that "Paul" from modaco is the one
responsible for fixing wlan.ko?

Original comment by zwzser...@gmail.com on 15 Nov 2009 at 2:55

[GoogleCodeExporter]

Even the rmmod -f command (force) is dangerous and could lead into a 
system-crash! 
That's already something really evil.

Original comment by harald....@gmail.com on 15 Nov 2009 at 11:27

[GoogleCodeExporter]

It didn't do anything anyway. Now that I think about it, modaco doesn't 
actually compile, he has it done 
by others. Teknologist is the name of the current kernel developer. Hoping 
he'll fix it.

Original comment by zwzser...@gmail.com on 16 Nov 2009 at 5:23

[GoogleCodeExporter]

I have an idea. By plain observation of the phone behavior around the failure, I
suspect some kind of race condition. Could you add a 1-second (configurable?) 
pause
before the unloading of the wlan.ko module? Also, a CPU-load monitoring that 
would
continue on low load would be quite good.
Teknologist replied that all the related files are from the original source, so 
he's
not likely fixing them.
This looks like hope, at least. Please try it.

Original comment by zwzser...@gmail.com on 17 Nov 2009 at 6:28

[GoogleCodeExporter]

Hi, I am Teknologist, the guy who compiled the kernel mentioned in this topic.

I have been looking for the reason to this and can't find it.
I use the original HTC Hero sources patched with compache/ext4 and a few others.

I use the original wlan module source from android ti/sta_dk_4_0_4_32

From the modaco forums topic, a part of my response:

Well got the reboots occasionally again when stopping wifi tether (and it's not 
happening always) and don't 
know why...don't even see anything in logcat when it happens...

I have tried recompiling the kernel to match initial configs to see if it was 
caused by my config customization 
and it seems it is not.

Again, don't know where it is coming from but don't think it's coming from the 
kernel/modules as *everything 
else* runs smoothly...I turn on/off wifi all the time (using Y5 battery saver) 
and have no issue whatsoever ... so 
it's a total mystery to me....

Also sometimes I see wpa_supplicant at 100% CPU when starting tether...

I am willing to help you guys sort this out in any manner I can.

Please let me know should you need anything...

Original comment by teknolog...@gmail.com on 26 Nov 2009 at 10:32

[GoogleCodeExporter]

You can also check the discussion int this thread
http://android.modaco.com/content-page/294951/gsm-03-11-1-8-teknologist-kernel-w
ith-tun-ko-
ext4-cifs-and-compache-ramzswap/page/280/

Please let me know what you need in order to pinpoint the problem ?
 I don't have anything appearing in the logs before the auto reboot of the phone (doesn't happen all the time 
but most of the time when I stop tethering) BTW tethering works great until I 
stop it, then  phone 
automatically reboots... :-(

Lets try to solve this together !

Original comment by teknolog...@gmail.com on 26 Nov 2009 at 10:42

[GoogleCodeExporter]

FYI:

./adb shell wpa_supplicant -version
wpa_supplicant v0.5.10

This is in Modaco 2.9 ROM

Original comment by teknolog...@gmail.com on 26 Nov 2009 at 10:44

[GoogleCodeExporter]

The link above got truncated:
Here it is:

http://bit.ly/5nctUE

Original comment by teknolog...@gmail.com on 26 Nov 2009 at 10:45

[GoogleCodeExporter]

We could try what zwzerver suggested in post #17. I will put something together 
the 
next days (I'm currently very busy with other stuff) - maybe this helps to 
solve the 
rmmod-problem (wlan.ko). Where are kernel-modules now located? Is a symlink 
still 
required (see post #4)? Why are modules located under 
/system/lib/modules/[kernel-
version] and NOT /system/lib/modules?

Regarding wep-encryption. The method which is used for wifi tether works 
flawlessly 
for htc dream/magic and samsung galaxy. So, I would say we are doing nothing 
worg. It 
looks to me that this is wlan-driver or wpa_supplicant related.

Original comment by harald....@gmail.com on 27 Nov 2009 at 9:34

[GoogleCodeExporter]

Modules are located in /system/lib/modules but when you do a modprobe/rmmod 
etc. it looks for them 
under /system/lib/modules/kernel-version , it seems modutils in MCR 2.9 looks 
for them in 
/system/lib/modules/kernel-version

Doing the symlink solves it.

Now, what I really don't understand is that unless I use wifi tether,  rmmod 
wlan.ko /insmod wlan.ko works 
flawlessly...weird...even under heavy load...that's why I am not very sure it 
has something to do with race 
coniditon...

Why do you need to remove the kernel module anyway ? Anyway, I am strongly 
against rmmod -f as it is not 
recommended and don't know of the possible side effects it would have on other 
components of the ROM...In 
my case the problem is not that the wifi is unavailable after wifi tether stop. 
It's the whole system crashing 
and rebooting with no errors posted at all...

To be honest, MCR is not that customized compared to HTC's official ROM and my 
kernel is not far from HTC's 
stock...just a few patches (compache/ext4 etc.) and a highly tweaked kernel 
config.

Maybe we could try compiling a wpa-supplicant 0.5.11 and testing with it...have 
tried but haven't had any 
luck so far...compile fails in tls-openssl file...

For wep-encryption I am pretty sure it's wpa-supplicant related as it seems we 
have 0.5.10 here whereas 
other devices seem to have a 0.5.11

Again the wlan I compile is straight from android sources and compiled with 
official android toolchain 4.4.0 
and everything else involving wifi works perfectly with MCR 2.9. Actually I 
even stop/start wifi Many times 
through the day with the usage of Y5 battery saver and haven't had any single 
issue....just wifi tether...

Original comment by teknolog...@gmail.com on 27 Nov 2009 at 10:56

[GoogleCodeExporter]

I may have an idea...after testing I figured out it may have something to do 
with the inability to remove the 
wlan module because wifi tether failed to kill wpa_supplicant...
Could you, instead of rmmod -f wlan, trying to kill -9 wpa-supplicant prior to 
rmmod wlan ?

That could also explain the fact that I sometimes see wpa-supplicant going 
ballistic with 100% CPU after wifi 
tether use...would also make sense considering that we are using 0.5.10 instead 
of 0.5.11 which is on other 
devices...

We could also try the cleaner method I pointed out above, which would be 
compiling wpa-supplicant 0.5.11 
for MCR 2.9...

In your code, how do you proceed to rmmod wlan ?

I

Original comment by teknolog...@gmail.com on 27 Nov 2009 at 11:35

[GoogleCodeExporter]

Also, seems that when I rmmod wlan, then I modprobe wlan, I can't start wifi 
again neither with the wifi toggle 
widget nor with the settings/wireless controls...

That's a bit weird and as the module loads perfectly when modprobing... don't 
want to reject the blame but I 
really don't think it has to do with my kernel...

Original comment by teknolog...@gmail.com on 27 Nov 2009 at 11:39

[GoogleCodeExporter]

Could we avoid the rmmod ?

Original comment by teknolog...@gmail.com on 27 Nov 2009 at 11:39

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

that is in /init.hero.rc

Original comment by teknolog...@gmail.com on 27 Nov 2009 at 11:50

[GoogleCodeExporter]

I managed to restart wifi without rebooting after modprobing the wlan 
module...I just had to manually relaunch 
wpa_supplicant with the params above and as wifi user...

Hope all this infos help you out understand how MCR 2.9 and HTC Hero work...

Original comment by teknolog...@gmail.com on 27 Nov 2009 at 11:54

[GoogleCodeExporter]

To be clear here: The tether-binary has a rmmod-method (extracted from the 
toolbox) 
included. The tether-binary (previously a shell-script) was introduced because 
some 
really weired behavior of the busybox (different "ps" output than other 
firmwares for 
instance) on earlier MODACO releases - see issue 145.
If you are testing rmmod from commandline use the toolbox-rmmod AND NOT the 
busybox 
one. 

Why I need to remove the kernel-module? If you deactivate wifi the module will 
be 
unloaded! So, I have to load the module manually and start the interface with a 
"special" configuration to enable tethering! If you stop tethering the module 
must be 
unloaded again otherwise the phone can't overtake control over the 
wifi-interface 
anymore!!!

I wonder what would happen if you replace your kernel (and wlan.ko) with the 
stock 
one - the rmmod-issue doesn't seem to occur on stock cdma hero-roms!

Original comment by harald....@gmail.com on 27 Nov 2009 at 11:54

[GoogleCodeExporter]

Where do I find that toolbox-rrmod ?

Original comment by teknolog...@gmail.com on 28 Nov 2009 at 12:02

[GoogleCodeExporter]

The toolbox is installed on every stock android-device! I don't know if it 
comes with 
modaco. Something like "toolbox rmmod ..." might work if the toolbox-binary is 
installed!

Original comment by harald....@gmail.com on 28 Nov 2009 at 12:06

[GoogleCodeExporter]

# lsmod
wlan 416024 0 - Live 0xbf00c000
ramzswap 6856 1 - Live 0xbf009000
xvmalloc 2976 1 ramzswap, Live 0xbf007000
lzo_compress 1664 1 ramzswap, Live 0xbf005000
lzo_decompress 2144 1 ramzswap, Live 0xbf003000
tun 6916 0 - Live 0xbf000000

# toolbox rmmod wlan
# lsmod
ramzswap 6856 1 - Live 0xbf009000
xvmalloc 2976 1 ramzswap, Live 0xbf007000
lzo_compress 1664 1 ramzswap, Live 0xbf005000
lzo_decompress 2144 1 ramzswap, Live 0xbf003000
tun 6916 0 - Live 0xbf000000
# toolbox insmod /system/lib/modules/wlan.ko
# lsmod
wlan 416024 0 - Live 0xbf00c000
ramzswap 6856 1 - Live 0xbf009000
xvmalloc 2976 1 ramzswap, Live 0xbf007000
lzo_compress 1664 1 ramzswap, Live 0xbf005000
lzo_decompress 2144 1 ramzswap, Live 0xbf003000
tun 6916 0 - Live 0xbf000000

Original comment by teknolog...@gmail.com on 28 Nov 2009 at 12:06

[GoogleCodeExporter]

seems to work with no problems 

Original comment by teknolog...@gmail.com on 28 Nov 2009 at 12:07

[GoogleCodeExporter]

Maybe the rmmod-issue only occurs if you have tried to enable encryption with 
wpa_supplicant (which will fail)?

By the way ... why you don't try the wpa_supplicant binary (version 0.5.11) 
from any 
other HTC device/rom?

Original comment by harald....@gmail.com on 28 Nov 2009 at 12:18

[GoogleCodeExporter]

also after the modprobe if I launch wpa_supplicant Dtiwlan0 -itiwlan0 
-c/data/misc/wifi/wpa_supplicant.conf

as root
I get:

# dir[ctrl_interface]: Read-only file system
# iled to initialize control interface 'tiwlan0'.
# u may have another wpa_supplicant process already running or the file was
# ft by an unclean termination of wpa_supplicant in which case you will need
#  manually remove this file before starting wpa_supplicant again.
# 
# RL-EVENT-STATE-CHANGE id=-1 state=0
# a_driver_tista_unload called

So I did a su wifi and tried again and got this:

$ wpa_supplicant -Dtiwlan0 -itiwlan0 -c/data/misc/wifi/wpa_supplicant.conf
socket: Address family not supported by protocol
[1] + Stopped (signal)        wpa_supplicant -Dtiwlan0 -itiwlan0 
-c/data/misc/wifi/wpa_supplicant.conf
$ 
[1]   Segmentation fault      wpa_supplicant -Dtiwlan0 -itiwlan0 
-c/data/misc/wifi/wpa_supplicant.conf

Any ideas ?

Original comment by teknolog...@gmail.com on 28 Nov 2009 at 12:21

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

except I can't scan wifi:

E/SettingsWifiLayer(  338): Unable to scan for networks
I/NotificationService(  133): enqueueToast pkg=com.android.settings 
callback=android.app.ITransientNotification$Stub$Proxy@44097760 duration=1
D/SettingsWifiEnabler(  338): Received wifi state changed from Enabling to 
Enabled
I/AudioHardwareMSM72XX(  111): AudioHardware pcm playback is going to standby.
D/dalvikvm(  330): GC freed 154 objects / 8432 bytes in 186ms
D/SettingsWifiLayer(  338): MESSAGE_ATTEMPT_SCAN call attemptScan()
E/SettingsWifiLayer(  338): Unable to scan for networks

Original comment by teknolog...@gmail.com on 28 Nov 2009 at 12:43

[GoogleCodeExporter]

definetely something wrong with wpa_supplicant 0.5.10

Look at the change log in adnroid git:

2008-11-28 - v0.5.11
+       * fixed race condition between disassociation event and group key
+         handshake to avoid getting stuck in incorrect state [Bug 261]
+       * updated D-Bus usage to avoid deprecated functions
+       * silence SIOCSIWAUTH ioctl failure message (these can be ignored in
+         most cases and are now only shown in debug output)
+       * increase timeout for IBSS connection
+       * driver_wext: do not overwrite BSS frequency if channel was already
+         received
+       * driver_wext: set interface down for mode switches, if needed (e.g.,
+         for mac80211)
+       * driver_wext: fixed re-initialization of a removed and re-inserted
+         interface (e.g., USB dongle or on resume if driver was unloaded for
+         suspend)
+       * improve per-SSID scanning for drivers that report background scan
+         results frequently
+       * fixed scanning behavior after a failed initial association
+       * driver_wext: fixed processing of invalid event messages from kernel
+         not to crash wpa_supplicant (this could happen when using 64-bit
+         kernel with 32-bit userspace)
+       * fixed EAP-AKA to use RES Length field in AT_RES as length in bits,
+         not bytes
+       * fixed canceling of PMKSA caching when using drivers that generate
+         RSN IE and refuse to drop PMKIDs that wpa_supplicant does not know
+         about
+

Original comment by teknolog...@gmail.com on 28 Nov 2009 at 12:45

[GoogleCodeExporter]

would you be kind enough to send me wpa_supplicant 0.5.11 binary so I can try 
it here ?

TIA

Original comment by teknolog...@gmail.com on 28 Nov 2009 at 12:48

[GoogleCodeExporter]

email ...

Original comment by harald....@gmail.com on 28 Nov 2009 at 12:53

[GoogleCodeExporter]

Thx, this one doesn't work at all...

It hangs....

# modprobe wlan
# /system/bin/wlan_loader -f /system/etc/wifi/Fw1251r1c.bin -e 
/proc/calibration -i 
/system/etc/wifi/tiwlan.ini
# wpa_supplicant -Dtiwlan0 -itiwlan0 -c/data/misc/wifi/wpa_supplicant.conf -dd

and nothing happens

Original comment by teknolog...@gmail.com on 28 Nov 2009 at 12:58

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

never got this with wpa_supplicant 0.5.10 though...

Original comment by teknolog...@gmail.com on 28 Nov 2009 at 1:01

[GoogleCodeExporter]

I recompiled the whole kernel and the wlan module adding some debug options 
that I had removed and 
switching back from deadline to anticipatory I/O scheduler and doesn't seem to 
have any problems anymore...

I'll do more testing tomorrow...to confirm and pinpoint the exact source of the 
problem.

Do you think any of these could be the reason ?

I though kernel hacking/debugging options were meant to debug... ;-) Seems 
maybe it has something to do 
with the deadline I/O scheduler...

Original comment by teknolog...@gmail.com on 28 Nov 2009 at 2:05

[GoogleCodeExporter]

1.9 Teknologist kernel update released on Nov 28 fixes these problems.

Newt Modaco Custom Rom (v 3.0) will include this new kernel.

Thanks to all of you for your help in pinpointing the source of the 
problem....wasn't that easy at first ! Still don't 
understand the real wlan bug behind...

Original comment by teknolog...@gmail.com on 28 Nov 2009 at 10:49

[GoogleCodeExporter]

BTW, MCR 3.0 is supposed to be released next weak including new busybox and 
this new 1.9 kernel.

Original comment by teknolog...@gmail.com on 28 Nov 2009 at 10:51

[GoogleCodeExporter]

So ... what is/was the problem now? Does kernel-module-unloading and 
wep-encryption
work for you?

Original comment by harald....@gmail.com on 28 Nov 2009 at 11:11

[GoogleCodeExporter]

Loading unloading works great! Seems had yo do with I/O scheduler ... Moved 
back to anticipatory

Wep doesn't and don't know why but don't think its related to kernel...

Do you?

Original comment by teknolog...@gmail.com on 28 Nov 2009 at 11:15

[GoogleCodeExporter]

Wep never worked for me on Mcr even with stock kernel on early mcr roms

might be related to wpa_supplicant

Original comment by teknolog...@gmail.com on 28 Nov 2009 at 11:18