Unable to gain full data/3G after being on wifi for a while

ravilov commented 12 years ago

Sometimes when I'm on wifi for a day or two, turning wifi off does not enable 3G fully. The signal is there, the indicator shows 3G or sometimes even H/H+, but no network app can connect anywhere. Tried turning data off and on, tried using airplane mode, nothing helped. The only thing that helps is a reboot.

After a bit of research I realized it comes down to DNS servers not being set properly after switching to 3G. Here's roughly how my system properties look like right after the switch to 3G (I cannot reproduce the exact result right now since my wifi/3G is not glitchy at the moment):

# getprop | grep dns
<>[net.change]: [net.dnschange]
<>[net.rmnet0.dns1]: [8.8.8.8]
<>[net.rmnet0.dns2]: [8.8.4.4]
<>[net.dns1]: []
<>[net.dns2]: []
<>[net.ppp0.dns1]: []
<>[net.ppp0.dns2]: []
<>[net.dnschange]: [9]
<>[net.dns1.2020]: []
<>[net.dns2.2020]: []
<>[dhcp.eth0.dns1]: []

I figure the values of net.dns1 and net.dns2 should not be empty like that. So I tried setting them to the two IP addresses for rmnet0. After a while things seem to settle and everything is back in working order.

As a temporary fix, I made a small shell script that I run every time I lose connectivity in this weird way. Here's the script.

#! /system/bin/sh
setprop 'net.dns1' "`getprop 'net.rmnet0.dns1'`"
setprop 'net.dns2' "`getprop 'net.rmnet0.dns2'`"

Note that this method is NOT CORRECT as I normally use DNS servers of my carrier, while after this fix I'm using generic Google's DNS servers. But it'll have to do for now.

Hope this helps.

mmontuori commented 12 years ago

Thanks for submitting, will check this out on how to provide a way to re-assign DNS.

ravilov commented 12 years ago

A little correction. It happened again this morning, so I took the opportunity to see how the system properties actually look like.

# getprop | grep -i dns
<>[net.change]: [net.dnschange]
<>[net.rmnet0.dns1]: [8.8.8.8]
<>[net.rmnet0.dns2]: [8.8.4.4]
<>[net.dns1]: []
<>[net.dns2]: []
<>[net.dnschange]: [5]
<>[dhcp.eth0.dns1]: []
<>[dhcp.eth0.dns2]: []
<>[dhcp.eth0.dns3]: []
<>[dhcp.eth0.dns4]: []

So not much different, except there are no DNS entries for ppp0, eth0 has 4 entries instead of 1 (all empty though), and dnschange has a value of 5 instead of 9. This last one might actually be significant, I can't tell. Anyway, hope this helps.

ravilov commented 12 years ago

Hm, another weird thing. I just ran my litle dnsfix script and this time it didn't help. Then I played a little with the data toggles (wifi, 3g, airplane) and after a while I got it back. No idea what exactly fixed it though. What's weird though is that everything works even though net.dns1 and net.dns2 properties are still empty! So now I'm no longer sure it's about the DNS entries at all... Another thing, now net.dnschange has a value of 13. No idea what to think of that. Everything else is exactly the same as in the post above.

One more weird thing - if wifi is off when I enter airplane mode, once I exit airplane mode the wifi will turn on automatically.

mmontuori commented 12 years ago

I think this could be related to APN settings, next time this happens, try to go to APN settings and reset...

ravilov commented 12 years ago

Thanks for the response. It happened again this morning and I deleted all APNs and selected Reset to default. After some messing around with data off/on and airplane mode off/on the signal seemed to be back to "fully connected", but the DNS entries were still empty and I still had to run my dnsfix script. So the issue is still present.

Should I open a new issue regarding the second part (if wifi is off when I enter airplane mode, once I exit airplane mode the wifi will turn on automatically)?

mmontuori commented 12 years ago

Ravilov,

You mentioned previously that the dns fix script does not always fix the problem... is this still the case? and no. keeping this issue open is fine until we find a solution one way or another...

Thanks for using my ROM...

ravilov commented 12 years ago

Oh no, I just thought that running the script is sometimes not necessary, but it turns out I was wrong. Running the script always fixes the problem though.

And no, I meant, should I open a new issue for what seems an unrelated problem, or is it okay to keep them together like this?

ravilov commented 12 years ago

Seems the problem is getting worse. Usaed to it would only happen when switching from wifi to data aftet wifi has been active for some (longer) time. Now it happens EVERY time I switch from wifi to data. No idea what's causing this but I hope you/we come up with a fix soon!

mmontuori commented 12 years ago

Well I would like for you try something, this is not final, but at least it should get you over the hump, while I final fix is built... install Llama location profiles and locale execute plugin. Configure Llama to run your script through the locale execute plugin when Wi-Fi gets disconnected our another trigger closer to your exact problem.. let me know if that takes care of it or not... it will give me an idea on how to fix it permanently...

mmontuori commented 12 years ago

Can you run the command "getprop | grep dns" when you have proper connectivity? I would like to see the results... thanks

ravilov commented 12 years ago

Here you go. This is right after switching from wifi to data (yeah, this time it worked right):

# getprop | grep -i dns
<>[net.change]: [net.dnschange]
<>[net.rmnet0.dns1]: [8.8.8.8]
<>[net.rmnet0.dns2]: [8.8.4.4]
<>[net.dns1]: [212.91.97.3]
<>[net.dns2]: [212.91.97.4]
<>[net.ppp0.dns1]: [212.91.97.3]
<>[net.ppp0.dns2]: [212.91.97.4]
<>[net.dnschange]: [9]
<>[dhcp.eth0.dns1]: []
<>[dhcp.eth0.dns2]: []
<>[dhcp.eth0.dns3]: []

And this is after a reboot:

# getprop | grep -i dns
<>[net.change]: [net.dnschange]
<>[net.rmnet0.dns1]: [8.8.8.8]
<>[net.rmnet0.dns2]: [8.8.4.4]
<>[net.dns1]: [212.91.97.3]
<>[net.dns2]: [212.91.97.4]
<>[net.ppp0.dns1]: [212.91.97.3]
<>[net.ppp0.dns2]: [212.91.97.4]
<>[net.dnschange]: [1]

I didn't try this Llama thing yet, I've finally upgraded to 9/25 so now I'm checking if that will somehow magically fix it.

mmontuori commented 12 years ago

I think what we need to figure out is when the net.ppp0.dns1 and net.ppp0.dns2 DNS property go away, is that when Wi-Fi connects? or disconnects? That could also help in identify the problem...

mmontuori commented 12 years ago

Let me know is this is still happening...

ravilov commented 12 years ago

Sadly yes, it is apparently still happening. Trying to figure out a pattern so I can at least test it more quickly. I will try out the Llama app that you suggested next.

This is what I figured out so far, not much but hopefully it's something:

ppp0 is the mobile data interface, eth0 is the wifi interface, not sure what rmnet0 is
net.[iface].dnsX entries hold the DNS IP address that were assigned to a specific interface when it was used last
net.dns1 and net.dns2 hold the currently used DNS IP addresses and are a copy of interface-specific entries
net.dnschange appears it's just a counter that gets increased every time a DNS change occurs, makes for easier tracking, other than that holds no special value
net.change holds the name of the DNS change handler (?)
for some strange reason, switching from wifi to mobile data clears out the eth0 DNS servers but sometimes fails to set the ppp0 servers which then consequently doesn't set the main net.dnsX entries

ravilov commented 12 years ago

I think I've noticed something. I think this only ever happens when the phone is powered up or power-cycled when it was on wifi last. Like when I'm on wifi and then I reboot. Not quite sure though, need to do more research on this.

mmontuori commented 12 years ago

Keep me posted please...

On Mon, Oct 1, 2012 at 1:18 AM, ravilov notifications@github.com wrote:

I think I've noticed something. I think this only ever happens when the phone is powered up or power-cycled when it was on wifi last. Like when I'm on wifi and then I reboot. Not quite sure though, need to do more research on this.

— Reply to this email directly or view it on GitHubhttps://github.com/mmontuori/atrix-mrom/issues/5#issuecomment-9022099.

ravilov commented 12 years ago

Ok, I tried the Llama app like you suggested and I set it up to trigger my script on wifi disconnect and... it didn't help. It triggers the script IMMEDIATELY after disconnect which is too soon. When mobile data finally connects, its DNS entries still end up empty and I need to run my script anyway.

Also, seems my theory is wrong - it doesn't seem to matter whether the phone boots on wifi or on data.

I hope this helps some.

ravilov commented 12 years ago

New discoveries.

So for some reason now I'm having problems switching from mobile data to my home wifi. The problem is yet again DNS servers not being set. It happened the other day and then again yesterday.

After poking around for a while, here's what I discovered.

Apparently for some strange reason some properties are just not being set. Here's an example:

# setprop dhcp.eth0.dns1 192.168.50.160
# getprop dhcp.eth0.dns1
[empty line here]
# setprop dhcp.eth0.dns1 blah
# getprop dhcp.eth0.dns1
[empty line here]
# _

So apparently even when I try to set the property manually, it doesn't stick. But it doesn't report an error either.

NOTE: This apparently only ever happens when the network subsystem gets in this weird state that I keep talking about. If I boot the phone with wifi only (mobile data disabled), then everything is fine, the DNS entries are set properly, but also I can change them using setprop to anything I like and it'll work (getprop will return the value I just set).

After some more poking around I figured it comes down to the init process because the system property service (the service that getprop and setprop connect to) is running within that process.

I examined the init source code here: https://github.com/CyanogenMod/android_system_core/blob/gb-release-7.2/init/property_service.c#LC314 Looking at this I think it should definitely work, since according to the check_perms() function I do have permission to set the above property ("if (uid == 0) return 1;", and I'm running as root/superuser), and my property name and value are well within length limits (PROP_NAME_MAX, PROP_VALUE_MAX). And yet, it doesn't work. I'm kinda lost at this point, I would expect at least some error reported either on command line or in logcat but there's nothing anywhere.

Just for the reference, the property length limits are defined elsewhere as follows:

#define PROP_NAME_MAX   32
#define PROP_VALUE_MAX  92

I'm really baffled by all this, I can't even begin to understand why this would be happening the way it does. Any help, comments or pointers are more than welcome, maybe I can try taking it from there or something.

mmontuori commented 12 years ago

What happened with this bug, any news?

ravilov commented 12 years ago

Sadly no news, still misbehaving a lot. I think I've nailed it to the property service (a part of init) not accepting certain properties under some circumstances for some reason, but that's as far as I got, now I'm stuck here. I tried increasing the debug level ("on init loglevel 100" in /system/etc/init.local.rc) and that did results in some more messages from init but nothing related to setting properties. What's most confusing is that when it comes to such state, it neither sets the property (getprop reports the property is still empty) nor it reports any kind of error/warning/anything.

It would probably help if I had a boot image with an init that is loaded with debug stuff, but sadly I am not yet at a stage where I would know how to compile and build a boot image. Maybe you can help here, if you feel up to it let me know and I'll provide the new (debug) source code for init.

Short of that, I'm thinking about making a nandroid backup, wiping everything and making a fresh install (I've only ever done upgrades so far, ever since the very first build), see if that will help any.

mmontuori commented 12 years ago

I can help, but exactly what init are you referring to init.rc?

ravilov commented 12 years ago

No no, I meant the init process itself, the init binary in the kernel ramdisk, since that's the one holding the system property service. See my previous comments for links.

However, before we try that, here's a new discovery - yesterday I made a nandroid backup and then completely wiped /data. Turns out not only this weird bug no longer exists, but the phone seems to connect to wifi significantly faster too. So apparently this really is specific only to my particular system. Next I restored my nandroid and then I tried removing all installed apps (used a script so as to make sure every single one is gone) and the issue is still there. So the problem is obviously somewhere within my system tweaks. I will investigate this some more. I feel the final answer is close.

ravilov commented 12 years ago

Believe it or not, I think I might have fixed this issue finally. So far so good, I'll keep an eye on it for a few more days, if nothing changes I'll close this issue.

For future reference, after a LOT of digging around, analyzing, backing up, deleting, restoring etc. it turned out the problem were some "undesirable" entries in my /data/property. I deleted a few of them and rebooted, and from then on things work right again!

Entries that I removed [brackets indicate the value that was in them]:

persist.sys.localevar []
persist.sys.notif-attn [6]
persist.sys.notif-speaker [0]
persist.sys.purgeable_assets [1]
persist.sys.vm.heapsize [64m]

mmontuori commented 12 years ago

That is great news... let me know if it's fixed, maybe you could post something on xda for people having the same problem... On Nov 6, 2012 11:31 AM, "ravilov" notifications@github.com wrote:

Believe it or not, I think I might have fixed it finally. So far so good, I'll keep an eye on it for a few more days, if nothing changes I'll close this issue.

For future reference, after a LOT of digging and analyzing, it turned out there were some "undesirable" entries in my /data/property. I deleted a few of them and rebooted, and things miraculously started working properly again!

Entries that I removed were [brackets indicate the value that was in them]:

persist.sys.localevar []

persist.sys.notif-attn [6]

persist.sys.notif-speaker [0]

_persist.sys.purgeableassets [1]

persist.sys.vm.heapsize [64m]

— Reply to this email directly or view it on GitHubhttps://github.com/mmontuori/atrix-mrom/issues/5#issuecomment-10117091.

ravilov commented 12 years ago

If this proves to be a permanent fix, I will definitely make a post about it, although from what I've seen I'm probably the only one who's managed to get this weird issue...

ravilov commented 12 years ago

Seems all is good, no problems encountered at all. I'll close this and make a post on xda.

mmontuori / atrix-mrom

Unable to gain full data/3G after being on wifi for a while #5