Related
This possibly needs to be in the dev section but I will start here.
First off this is not a complaint. What I initially want to do is get an understanding (Technical) of the issues around the PPP dropouts and locks ups.
From where I sit this is the only outstanding issue around the current android builds. Simply the phone rocks on SD card and is ultra stable and fun.
I have noticed various wiki'sstate that internet access is complete however obviously not.
There are a number of issues such as
1: Network dropout. Data connectivity will stop responding. Restart of the radio or mobile data needed
2: Network freeze. Android restart as the radio will not turnoff.
3: console level networking not avail. Eg ping etc simply does not work. DNS does not resolve and ping cannot find a route. Std Android this works fine.
4: Related issues. GPS-A data not downloadable. Only via application layer tool.
Is PPP the default connection type on factory android builds?
What is the difference between the HD2 in dev and a std android with the implementation of the data connection.
How can I help. I have over 20 years in IT and have a thorough understanding of TCP IP layers and routing. I have reasonable understanding of Linux and the kernel IP stack but zero understanding of the android kernel or application layer.
I also have dollars to contribute.
Update:
Currently I am trying all four with isome improvements
1: Updated the Ril WRapper with no luck.
http://forum.xda-developers.com/showthread.php?t=794309
2: Change the phones default connection to GSM PL.
Change the setting found in the menu phone info when you "call" *#*#4636#*#*. There is a option to choose your preferred network. Set to GSM auto (PRL)
3: Update DNS settings.
http://forum.xda-developers.com/showthread.php?t=812930
4: Ensure the correct APN's are being used.
This is no internet versus unstable Internet.
Note. Currently trying all four and things are improving. Had my first dropout after 36 hours versus 2 per day. It happened whilst using the GPS and making a call which always tend to be a stresser anyway. Will try to keep this thread updated.
This thread also has a number of updates http://forum.xda-developers.com/showthread.php?t=813148
I am running a stock WinMo Rom (Latest European release 3.14 I believe). 2.15 radio on a Telstra Network in Australia. My phone is a T8585. Also running [19.10.10]|<<Mdeejay FroYo Sense Series>>|2.25.771.1| cos I like the transparent titlebars
Now I have been running all 4 of the above for around a week now and have to say there is a def improvement. Where it was common to get multiple disconnects per day I have only had 3 in the last week. Mainly when I use the GPS.
I am still searching and have yet to find a 100% fix the stability is now at a point of reasonable reliable. Also noted that the Devs are still hard at work on this.
Update 31-10-2010
A good test is to open google maps while driving. Its about the only time I get a drop out now.
The GPS kicking in always stresses the radio and that combined with the handover of cell sites is a great deal breaker.
This also seems to be consist with my suspicions around the poor handling of corrupt connections.
Eg the system on fresh boot only has a table for handling 50 connections line. This ensures it can handle multiple simultaneous connections as well as background coms.
Now when a connection is damaged or locked normally it should timeout and/or then be deleted from the table. My suspicions is that this is not happening and all the avail connection handling are slowly filling up until there are now free. Frozen this is why it seems to be very unlikely for a freeze to occur straight after a restart but more likely after a day. Also dependent on stress environments. Homes with lots of RF noise, Long way from cell towers, driving, lots of gps use, Wifi cut over.
http://forum.xda-developers.com/showthread.php?t=812930&page=7
http://forum.xda-developers.com/showthread.php?t=794309
Thanks for the response.
I was not looking for work around but more technical information to try and identify where the issue lies. curious to see if ppp is the default and if the ppp implementation should work or is it still a hack/work around.
The steps I have tried are
1: Updated the Ril WRapper with no luck. No improvement
2: Change the phones default connection to GSM PL. No improvement
3: Update DNS settings. Still testing however does not resolve console level network issues and unlikely related to ppp freeze. No logic?
4: Ensure the correct APN's are being used. No improvement
Note. Currently trying all three
This is also separate to a lot of people issues around APN's. From the application layer internet works fine except for the freeze.
I believe rmnet is android's default connection and ppp is winmo's. I think dft reengineered ppp for Android. Remember seeing it some where when ppp first started to appear. Of course this is how I remember it and my life is hectic so it might be the opposite.
Sent from my Mytouch HD2
So I understand that one of the issues with RMNET was dropped packets. Was this due to it not being correctly engineered/implemented or just a nature of the beast?
Also with the issues everyone is having why are we not continuing to investigate RMNET as at least this was initially more stable and more of a native option.
dusty_nz said:
So I understand that one of the issues with RMNET was dropped packets. Was this due to it not being correctly engineered/implemented or just a nature of the beast?
Click to expand...
Click to collapse
That is because it isn't implemented correctly. The radio receiver in our phones was made for PPP, not for RMNET. Latter is standard in native android devices. And there it works very fast and stable. So the devs had to implement PPP in android, which isn't proper working. But they're working on it to improve the stability, I'm pretty sure 'bout that. At least it does work and I had never problems with loosing my connection and bad speeds.
Edit: Those are the known steps to get it at least halfways stable working.
Cheers
Okay.
Did some more playing.
Both RMNET and PPP allow pinging from the console. Just had to enable SU first.
Thanks everyone for your info. Will try my best to be patient.
dusty_nz said:
Okay.
Did some more playing.
Both RMNET and PPP allow pinging from the console. Just had to enable SU first.
Thanks everyone for your info. Will try my best to be patient.
Click to expand...
Click to collapse
But did you also have a delay till it worked? It took me about 20 seconds before any reply came up. And does your ping test work if you try it in the hidden menu when you "call" *#*#4636#*#*?
Aye.
There was a delay and the hidden menu ping does not work either.
Still needs work.
dusty_nz said:
Aye.
There was a delay and the hidden menu ping does not work either.
Still needs work.
Click to expand...
Click to collapse
Right.
Have you seen this thread? It might be a possible solution.
Some people have reported that it works. But I had no time to test it. Had to move servers
That is fix number 3. Update DNS. Testing now. Only been 24 hours however no drops.
Seems strange thou. Hard to imagine it is a DNS issue.
On a side note. Does anyone know what changes to the Rom are needed when installing an RMNET kernel?
Eg If I took the latest MDeejay rom and changed the kernel?
Update
Update on first post.
Def improvements to be found. DNS seems to be the biggest improvement for me but also running all 4 at once.
dusty_nz said:
On a side note. Does anyone know what changes to the Rom are needed when installing an RMNET kernel?
Eg If I took the latest MDeejay rom and changed the kernel?
Click to expand...
Click to collapse
No one who knows cares enough to answer.
As far as I can tell, no 'modern' build uses an rmnet kernel anymore, because apparently the chefs either don't care about data reception, or don't think that there is a problem because they don't leave a build on long enough for it to start developing problems.
enneract said:
No one who knows cares enough to answer.
As far as I can tell, no 'modern' build uses an rmnet kernel anymore, because apparently the chefs either don't care about data reception, or don't think that there is a problem because they don't leave a build on long enough for it to start developing problems.
Click to expand...
Click to collapse
any build that says it uses michyprima r11 is still rmnet based. I don't think the nexus one-based kernels worked with ppp at all.
on another note, I was getting loads of Network Freezes (where flicking airplane mode wouldn't reset the data connection) since last week despite not fundamentally changing anything in my Android setup (see sig). However been doing some research around xda yesterday and may have found something else that's improved my ppp connection stability (so far) and resolved my constant network freeze issue... will update when I've tested this for a few more days.
Some improvment?
APNs are correct, Did the RIL_WRAPPER with no significant improvment. This morning I changed to GSM PRL and noticed an improvment.
Before the GSM PRL, I had many PPP drops, especially when streaming large amounts of data. After the GSM PRL update, I did try streaming youtube, Last.FM, slingpalyer together and NetTest, concurrently, everything is working with no PPP drop.
This is not enough to reach a conclusion, but nevertheless, I never could have done it before
Have a look here.
Stock rom 1.48 WWE, radio 2.15.50 and Froyostone 3.2
Thanks for the support!
BTW: How can I obtain the DNS information for my mobile carrier?
Just report.
I didn't believe change dns will work.
But after I change dns, the data suddenly work ( no need to restart!).
So I think it have something relate to dns.
Same thing. Updating the DNS in the build.pro file seems to have the greatest benefit.
I have a suspicion that the issues are caused with the network driver not flushing dead connections. Eg outgoing requests that to not get a reply. Ideally they should be flushed other wise the connection cache will fill until it can no longer take more connections. Symptom dead/frozen internet
All the symptoms seem to relate to this sort of issue
Things like ppp drop out more likely when on the move (More dropped packets). GPS and wifi but back. etc.
@Dusty_Nz,
Thanks for your help, this is a great thread and its certainly appreciated (the devs are busy enough as it is, xda member contributions are a great help).
As it was asked a few posts up, how do I obtain the DNS settings for my carrier? I am using TMobile US and I'd like to test your observations.
Thanks!
Sent from my HTC HD2 using XDA App
tgtoys said:
@Dusty_Nz,
Thanks for your help, this is a great thread and its certainly appreciated (the devs are busy enough as it is, xda member contributions are a great help).
As it was asked a few posts up, how do I obtain the DNS settings for my carrier? I am using TMobile US and I'd like to test your observations.
Thanks!
Sent from my HTC HD2 using XDA App
Click to expand...
Click to collapse
Follow the link on post 3
will then lead you here.
http://www.opengear.com/faq383-Confi...-APNs.html#USA
We have many different devices here... Galaxy S2, Note 8, S3, Note II , S4 etc... Over the past few weeks we have had our Galaxy S4's start to run jittery, frequently begin displaying a message, "Can't play video" when attempting to play video loops in VideoView and random crashes/device reboots throughout the day. The strange thing was that we had many different S4's that mostly appeared to reboot at the exact same time. It also seemed like at about 4pm every day all of the issues would go away and return the next morning. It really had us banging our heads off a wall since this was effecting so many devices, however only S4's.
Eventually we found out what seems to be going on, although we are still unsure of why it is happening or why the other devices aren't seeing the same symptoms. We are convinced that this is two issue acting together... One with our network and the other with the S4 device itself.
We downloaded the app SystemPanelLite which shows us inbound and outbound network traffic as well as cpu usage. We ran numerous tests on many different networks and what we found was when we were our main company network the inbound traffic on EVERY device would constantly spike from 2.2mb/s - 3.2 mb/s which would cause the cpu to jump to high levels. We put a VideoView on a loop on one device, and on another device we would watch the inbound traffic on the network. Whenever the traffic would spike the video would start getting very jittery and even sometimes throw an OnError event with a what parameter of -1(Error unknown). Eventually if the traffic spiked high enough the device would simply crash and reboot. Occasionally we'd see the inbound traffic fall to 12kb/s and all devices would start functioning perfectly. We have a few developer S4's and we even have a few employees with consumer S4's who reported the issue of their devices rebooting when on the company network.
So we were seeing this traffic on ALL of our devices yet it would only cause the S4's to behave this way.
So I have a few questions:
A) What the heck on our network could be broadcasting in such a way that all android devices would be receiving so much data.
B) How could network data literally crash an entire android system? The system should be protected from such things. (this leads me to believe there is currently an undiscovered bug in a recent software update for the S4, since even my S2 seems to gracefully handle these network spiked without a hitch.)
I'd love to try and set up a test bed to duplicate this issue on a network but I literally have no idea what could possibly be broadcasting in such a way that would cause all android devices to accept such a huge amount of inbound traffic. Any insight into what could be going on here would be very much appreciated!
Thanks for your time!
_Mr_E said:
We have many different devices here... Galaxy S2, Note 8, S3, Note II , S4 etc... Over the past few weeks we have had our Galaxy S4's start to run jittery, frequently begin displaying a message, "Can't play video" when attempting to play video loops in VideoView and random crashes/device reboots throughout the day. The strange thing was that we had many different S4's that mostly appeared to reboot at the exact same time. It also seemed like at about 4pm every day all of the issues would go away and return the next morning. It really had us banging our heads off a wall since this was effecting so many devices, however only S4's.
Eventually we found out what seems to be going on, although we are still unsure of why it is happening or why the other devices aren't seeing the same symptoms. We are convinced that this is two issue acting together... One with our network and the other with the S4 device itself.
We downloaded the app SystemPanelLite which shows us inbound and outbound network traffic as well as cpu usage. We ran numerous tests on many different networks and what we found was when we were our main company network the inbound traffic on EVERY device would constantly spike from 2.2mb/s - 3.2 mb/s which would cause the cpu to jump to high levels. We put a VideoView on a loop on one device, and on another device we would watch the inbound traffic on the network. Whenever the traffic would spike the video would start getting very jittery and even sometimes throw an OnError event with a what parameter of -1(Error unknown). Eventually if the traffic spiked high enough the device would simply crash and reboot. Occasionally we'd see the inbound traffic fall to 12kb/s and all devices would start functioning perfectly. We have a few developer S4's and we even have a few employees with consumer S4's who reported the issue of their devices rebooting when on the company network.
So we were seeing this traffic on ALL of our devices yet it would only cause the S4's to behave this way.
So I have a few questions:
A) What the heck on our network could be broadcasting in such a way that all android devices would be receiving so much data.
B) How could network data literally crash an entire android system? The system should be protected from such things. (this leads me to believe there is currently an undiscovered bug in a recent software update for the S4, since even my S2 seems to gracefully handle these network spiked without a hitch.)
I'd love to try and set up a test bed to duplicate this issue on a network but I literally have no idea what could possibly be broadcasting in such a way that would cause all android devices to accept such a huge amount of inbound traffic. Any insight into what could be going on here would be very much appreciated!
Thanks for your time!
Click to expand...
Click to collapse
So we've actually found that there is a device on our network that is blasting crazy amounts of "Neighbour Advertisement" packets. We've tracked it to an iOS device but are unsure who's it is. Anyway, network traffic should not be able to completely crash devices into a reboot state, not too mention the amount of battery is being used simply by having the device on the network. This seems like a pretty big security flaw to me.
_Mr_E said:
So we've actually found that there is a device on our network that is blasting crazy amounts of "Neighbour Advertisement" packets. We've tracked it to an iOS device but are unsure who's it is. Anyway, network traffic should not be able to completely crash devices into a reboot state, not too mention the amount of battery is being used simply by having the device on the network. This seems like a pretty big security flaw to me.
Click to expand...
Click to collapse
I would start by changing your WiFi keys, that should prevent the traffic. Then - before granting access to WiFi via the new key - All devices should be checked for Malware and anti Malware installed.
This traffic is a warning - what if it was a virus that the iOS device was transmitting?
Bulbous said:
I would start by changing your WiFi keys, that should prevent the traffic. Then - before granting access to WiFi via the new key - All devices should be checked for Malware and anti Malware installed.
This traffic is a warning - what if it was a virus that the iOS device was transmitting?
Click to expand...
Click to collapse
We have actually found out that it was instances of Hyper-V reacting badly together and sending out these packets due to the bug here: [grrr... apparently I'm not allowed to post links as a new user]
Regardless network traffic should not be capable of fully bringing down an Android System. All other devices even as old as the S2 did not crash under this load, why does the S4?
Hi all,
I'm having a very strange issue that I'm hoping someone can shed some light into. For some reason my VS980 as well as my Nexus 7 (2013) and all of the other Android devices in my house appear to be constantly downloading something. This activity gets translated to slightly worse battery life and is manifested in the Android OS process. I'm running CloudyStock 2.2 and have clean flashed it 2 times to see if that is the issue. All of the Android devices on our network have this issue though.
I've checked our router's outbound requests and none of the devices are making outbound requests so it appears as though the issue is purely on the LAN. I have seen other forum posts describing this exact issue in its entirety and nobody has found a solution as of yet.
http://hardforum.com/showthread.php?t=1758079
http://forum.xda-developers.com/galaxy-s3/help/android-os-draining-battery-connected-t1829677
I'm fairly certain the issue is network/router specific as the problem is even more severe at my workplace. At my home I have the Asus rt-N66U (http://www.asus.com/Networking/RTN66U/) running the latest version of Merlin. I've tried to a hard reset on the router as well and still the issue persists.
I'll post battery screenshots and BBS screenshots as well as network logs when I get home. Any advice and suggestions are welcomed!
Usually i switch on WiFi and disable mobile data manually while at home. It turns out that i don't receive any Push Notifications like WhatsApp, Threema, Facebook and GMail/Inbox (those who are using gcm) when the device is connected to WiFi solely and the screen is locked. If i unlock the device after a certain amount of time, a bunch of notifications are popping up. This is reproducable and won't occur on mobile data. Just do the following, while i.e. at home:
Connect to WiFi
Deactivate your Mobile Data
Lock your screen and let your Device rest for a couple of seconds
Tell someone to send you a Mail to your Gmail Account (or on any other GCM-Push related way)
You probably may notice that your device won't wake up to notify you about this incoming message until you pick it up and unlock it. I have tested this since weeks with multiple official nightlies of CM12, custom builds and even unofficial CM12.1 builds, they all show the same behaviour. Even with official CM11s this issue persists, but can be worked around by unchecking "WiFi Optimizations" in advanced WiFi-Settings. Unfortunately Lollipop doesn't have this WiFi Optimization trigger anymore. Ofc "Keep WiFi on during sleep" is set to "always". After all tests i came to the conclusion that the device simply gets no wakelock trigger from notifications if connected to WiFi solely. I've fixed this for me by fiddeling with the configuration files (root needed).
Open /system/etc/wifi/WCNSS_qcom_cfg.ini and change
Code:
hostNSOffload=0
to
Code:
hostNSOffload=1
After this change and a reboot, your device should be able to wake up from incoming notifications instantly while on WiFi. Some custom ROM, like SlimSaber have set this out of the box, while official cm nightlies and other custom ROM, like exodus, haven't.
Have you tested IPv6 over WiFi with 12.1? As that is also broken on 12.
JaY_III said:
Have you tested IPv6 over WiFi with 12.1? As that is also broken on 12.
Click to expand...
Click to collapse
Usually i've disabled ivp6, because of the known problems with it. I've tested it with ipv6 enabled and it worked.
Meanwhile i was able to test a lil bit more on other networks. It seems like this all is router dependant. While having the chance to exessively using another WiFi network yesterday, i was able to check that there are no such problems as described before. After went home, problems reappeared. I have to conclude that there must be some culprit with my router at least (Telekom Speedport W724V).
I noticed such notification flood several times.
I can't say under which circumstances because I didn't care about it yet but your post made me remember this.
I gonna investigate that asap.
As far as I can say this happened only at home yet. My router is an AVM FritzBox 7390.
On my OPO I have usually always one of the newest official CM12 nightlies installed.
I've tested stock settings while connected to a completely different router a few days ago and wasn't able to reproduce the issue. It really turns out that it has something to do with certain routers, in my case a Speedport W724V Type A (by Huawei). It seems like this issues has something to do with ARP Offloading and filtering of Broadcast/Multicast. As far as i understand, Androids MAC Adress isn't hard coded and the router loses the connection to the device if it goes into sleep state. Therefore the router has to broadcast via arp to look for the device, but the device simply doesn't respond to the arp request, coz the wifi driver is configured to ignore that broadcasts and continue sleeping. This issue is, as i read, present since KitKat where it could at least be worked around by disabling the WiFi Optimizations, which seems to be only a checkbox for above mentioned manual method Lollipop.
Currently i've no idea how to fix this in a better way, since my described method works flawlessly, but it's definately a lil battery drainer. Another way to work around this is by setting "Keep Wi-Fi on during sleep" to "never" and let the device handover the data connection to mobile data while sleeping. This, at least, ensures the battery savings which were intended by the developers.
Steve Kondik merged an interesting commit today, which i am not aware of if this will change anything related to this issue. As this commit was merged into cm12.1 branch i doubt that we will see anything related in cm12 based roms, nor the upcoming cm12s. Maybe some nifty dev like @ak or @Lord Boeffla can take a look into this and implement it into their kernel.
I put the interesting commit into my cm12.1 kernel, which comes out tomorrow.
If all goes well I can look to back port it to cm12 and maybe even cm11(s).
Let's see. First we need opinions on the test kernel tomorrow.
Andi
Genericxx said:
I've tested stock settings while connected to a completely different router a few days ago and wasn't able to reproduce the issue. It really turns out that it has something to do with certain routers, in my case a Speedport W724V Type A (by Huawei). It seems like this issues has something to do with ARP Offloading and filtering of Broadcast/Multicast. As far as i understand, Androids MAC Adress isn't hard coded and the router loses the connection to the device if it goes into sleep state. Therefore the router has to broadcast via arp to look for the device, but the device simply doesn't respond to the arp request, coz the wifi driver is configured to ignore that broadcasts and continue sleeping. This issue is, as i read, present since KitKat where it could at least be worked around by disabling the WiFi Optimizations, which seems to be only a checkbox for above mentioned manual method Lollipop.
Currently i've no idea how to fix this in a better way, since my described method works flawlessly, but it's definately a lil battery drainer. Another way to work around this is by setting "Keep Wi-Fi on during sleep" to "never" and let the device handover the data connection to mobile data while sleeping. This, at least, ensures the battery savings which were intended by the developers.
Steve Kondik merged an interesting commit today, which i am not aware of if this will change anything related to this issue. As this commit was merged into cm12.1 branch i doubt that we will see anything related in cm12 based roms, nor the upcoming cm12s. Maybe some nifty dev like @ak or @Lord Boeffla can take a look into this and implement it into their kernel.
Click to expand...
Click to collapse
It fixed my wifi bug so far on euphoria 5.1
Okay guys, i've tried AK's latest experimental kernel (v203). Beside of some small problems which are still under developement, WiFi seems to be fixed completely with the implementation of the new prima drivers for me. This could mean, that they will be automatically fixed with the release of the official cm12.1 nightlies. As for now i will thank everyone, especially @ak and @Lord Boeffla for participating and help to hunt down and solve this annoying issue. You're great guys :good:
Genericxx said:
Okay guys, i've tried AK's latest experimental kernel (v203). Beside of some small problems which are still under developement, WiFi seems to be fixed completely with the implementation of the new prima drivers for me. This could mean, that they will be automatically fixed with the release of the official cm12.1 nightlies. As for now i will thank everyone, especially @ak and @Lord Boeffla for participating and help to hunt down and solve this annoying issue. You're great guys :good:
Click to expand...
Click to collapse
Thanks. With the latest beta kernel for cm12.1 which I released this morning, these drivers are also included.
If they turn out to work better - my other kernel variants (cm11s, cm11, cm12) are also already ready with these new drivers backported. Just have not released them as I want to give it some more testing.
Andi
Anyone else notice the same issue on Oxygen Os? I'm not sure if it's just the router I connect to at work, since this doesn't happen at home. Can't tell yet, will give this a shot.
xxBrun0xx said:
Anyone else notice the same issue on Oxygen Os? I'm not sure if it's just the router I connect to at work, since this doesn't happen at home. Can't tell yet, will give this a shot.
Click to expand...
Click to collapse
Would be an interesting test.
We cannot look into the driver used for Oxygen OS as the kernel code is not yet released as far as I know (if it is, I would be happily be corrected )
Andi
I'll bet that oxygen suffers of the same problems as every cm12 build does (even if it's more aosp) and CyanogenOS 12 (CM12s) will also.
Genericxx said:
I'll bet that oxygen suffers of the same problems as every cm12 build does (even if it's more aosp) and CyanogenOS 12 (CM12s) will also.
Click to expand...
Click to collapse
Let's see.
I backported the new drivers to CM12, CM11s and CM11 already.
Just need to decide whether I ship that or not
Andi
Lord Boeffla said:
Let's see.
I backported the new drivers to CM12, CM11s and CM11 already.
Just need to decide whether I ship that or not
Andi
Click to expand...
Click to collapse
is it already out ?
reyscott1968 said:
is it already out ?
Click to expand...
Click to collapse
Indeed it is.
Andi
Just to report back, this did seem to fix my wifi issues, although I've since switched to Exodus, so I didn't have a ton of time to play with it.
Thanks for taking the time to investigate this issue. I should have done the same I will ago when it started bothering me.
I will try one of the kernels and see if it fixes it. If not I'll try your method once I am back home.
Thanks!
Jur1nator said:
Thanks for taking the time to investigate this issue. I should have done the same I will ago when it started bothering me.
I will try one of the kernels and see if it fixes it. If not I'll try your method once I am back home.
Thanks!
Click to expand...
Click to collapse
You're welcome. I have to admit that the problem reappeared. So the new Wi-Fi drivers have no permanent solution for me. As told in the other thread I found my temporary solution by simply let Wi-Fi auto turn off when device for to sleep. My data plan allows me this easily, but if you're on a 200mb data plan this could be ****ty for you. Let's see if future commits of cm will change anything.
I fortunately have a 3gb lte contract, so this shouldn't be the issue. I just don't want to accept that there might not be a solution without tradeoffs.
I'll let you know if I find anything
Jur1nator said:
I fortunately have a 3gb lte contract, so this shouldn't be the issue. I just don't want to accept that there might not be a solution without tradeoffs.
I'll let you know if I find anything
Click to expand...
Click to collapse
Would be nice. I'm hunting this issue down since January, so far, as said, without any real solution other than using another router. it works anywhere except at home, so i know exactly how annoying this is. It's not that big problem to use mobile data when screen is off, but is pisses me off, if i just forget this sometimes and miss urgend messages from WhatsApp or Threema, coz they're arriving hours later. As desribed above, there is a way to prevent the OnePlus to not filter the WiFi Broadcasts. You just have to edit this one line in the configuration manually, but it comes at the cost of battery.
As some of you may know I've ported the nvidia verson of the bcmdhd WiFi driver from their Tegra X1 reference kernel source code to xceed. What you all probably don't know is that there is a significant difference between nvidia's version, and the one in Google's kernel tree:
Nvidia's bcmdhd driver lacks an API called "GSCAN". What is GSCAN? GSCAN is an Android WiFi driver API for scanning for access points and making the list available to Android. Now you might say: but this works in xceed! Stop the bull, cheepskate, what are you talking about?
Yes, of course it works, because the "naked" bcmdhd driver implements a standard API for scanning for access points. So what is GSCAN really for?
Simple: it's meant to make the gathering of data about access points near your location as thorough and detailed as possible, in order to enable Google to create a mesh of these access points in order to improve their location service based on WiFi data. It's the infamous "Scan for access points even when WiFi is off" option in the Settings. And even if you turn that option off, while your WiFi is enabled so would be GSCAN, gathering data about access points and ruining your battery life.
I've deliberately left this API out of Xceed. First of all, this greatly improves battery life with WiFi. But to be fair to myself, it's not the only reason batterry life is so great: it took a substantial amount of hacking and insights to get to the point where xceed is now.
But secondly, and more importantly, this makes the users of my kernel completely black-boxed towards Google, and Google has no means to interfere with your own control of battery life, or the WiFi and therefore device itself in a manner that you do not condone. It is, really and truly, as much a political as a technical decision, and I intend to keep it that way.
I can only estimate, but if the WiFi drivers of other devices would have the GSCAN API removed (and please note that the WiFi and Android works just fine without it) the battery life would see a substantial boost.
I don't think this was a great decision by Google by any measure, at least from the consumer point of view. Let's hope that maybe in a future Android version it will be possible to turn it off completely without having to remove it from the driver. Does that sound likely? Rather not. But as always, one can hope.
And in the meantime, or for as long as you wish, there's xceed.
Have a nice day.
Very interesting. Would you care to speculate on why Google did this?
Do I understand correctly that GSCAN is a module in the bcmdhd driver that's always active, regardless of "Scan for access points even when WiFi is off"?
To my untrained eye it just looks like GSCAN is a mechanism that pushes the job of constantly polling for accesspoint away from the application processor and letting them firmware of the wifi do the work.
I can even imagine this might be more battery efficient.
How did you measure the effect on consumption?
smitel said:
Do I understand correctly that GSCAN is a module in the bcmdhd driver that's always active, regardless of "Scan for access points even when WiFi is off"?
To my untrained eye it just looks like GSCAN is a mechanism that pushes the job of constantly polling for accesspoint away from the application processor and letting them firmware of the wifi do the work.
I can even imagine this might be more battery efficient.
How did you measure the effect on consumption?
Click to expand...
Click to collapse
GSCAN does not run in the firmware but in the bcmdhd driver. Even if it did, it would be hardly more efficient than it not running at all.
cheep5k8 said:
GSCAN does not run in the firmware but in the bcmdhd driver.
Click to expand...
Click to collapse
It seems like this GSCAN functionality is called "Prefered Network Offload" (PNO) by Broadcom and is also used by Wi-Fi Location Service(WLS).
It offloads the wifi probing from Android to the Wifi firmware.
It seems implemented in dhd_pno.c, which gives commands to the Wifi firmware through dhd_iovar().
Even if it did, it would be hardly more efficient than it not running at all.
Click to expand...
Click to collapse
I can imagine using Wifi for localization requires a lot more data collection/probing than just using Wifi for connecting to networks.
Without kernel-support this would require Android to do a lot of polling and collection.
GSCAN seems an system to collect this data in kernel or in firmware, and produce it batch/event-wise to Android for consumption.
And it's also used for 'preferred network offload'. So it offloads/optimizes the probing for Wifi networks into bcmdhd or firmware instead of doing it through wpa_supplicant in userspace.
So this should also save battery.
Is your issue with the 'Wi-Fi Localization Services'?
I don't know if disabling GSCAN means Android will no longer use Wifi for localization.
If it does, maybe setting 'Location Mode' to 'Device only' would produce the same result?
If it does not, disabling GSCAN would increase power consumption because all the polling would require waking Android instead of just doing it in kernel or even firmware.
smitel said:
Are we talking about the stuff in https://android.googlesource.com/pl...ce4678bcb770359a632/bcmdhd/wifi_hal/gscan.cpp ?
GSCAN seems to get enabled at https://android.googlesource.com/pl...78bcb770359a632/bcmdhd/wifi_hal/gscan.cpp#464
Which does a createFeatureRequest(), which does a vendor-specific nl80211 command (NL80211_ATTR_VENDOR_DATA) to the driver.
Hmmm, which actually confuses me, because I thought I was looking at the part where the driver communicates with the Wifi HAL/Firmware.
Modern stuff is so incredibly layered.
This does speak a lot about how this stuff seems to be implemented on the wifi chip:
https://android.googlesource.com/pl.../+/master/include/hardware_legacy/gscan.h#319
Edit: I looked a little bit extra.
It seems like this GSCAN functionality is called "Prefered Network Offload" (PNO) by Broadcom and is also used by Wi-Fi Location Service(WLS).
It offloads the wifi probing from Android to the Wifi firmware.
Code:
// Therefore, it is acceptable for firmware to store a crc24, crc32 or other short hash of the SSID,
// such that a low but non-zero probability of collision exist. With that scheme it should be
// possible for firmware to keep an entry as small as 4 bytes for each pno network.
// For instance, a firmware pn0 entry can be implemented in the form of:
// PNO ENTRY = crc24(3 bytes) | flags>>3 (5 bits) | auth flags(3 bits)
//
// No scans should be automatically performed by the chip. Instead all scan results from gscan
// should be scored and the
I can imagine using Wifi for localization requires a lot more data collection/probing than just using Wifi for connecting to networks.
Without kernel-support this would require Android to do a lot of polling and collection.
GSCAN seems an system to collect this data in kernel or in firmware, and produce it batch/event-wise to Android for consumption.
I don't know if disabling GSCAN means Android will no longer use Wifi for location.
If it does, maybe setting 'Location Mode' to 'Device only' would produce the same result?
If it does not, disabling GSCAN would increase power consumption because all the polling would require waking Android instead of just doing it in kernel or even firmware.
Click to expand...
Click to collapse
That logic seems sound at first, but it's not what can be observed when GSCAN is disabled in the driver; Android doesn't do what you propose, but feel free to prove me wrong. The GSCAN part of the driver could always be added to nvidia's driver.
cheep5k8 said:
That logic seems sound at first, but it's not what can be observed when GSCAN is disabled in the driver; Android doesn't do what you propose, but feel free to prove me wrong. The GSCAN part of the driver could always be added to nvidia's driver.
Click to expand...
Click to collapse
What do you observe when GSCAN is disabled in the driver?
smitel said:
What do you observe when GSCAN is disabled in the driver?
Click to expand...
Click to collapse
I don't understand the question. What would I observe?
BTW it's 9 AM in the morning here, I'm just barely up. I should have waited before replying, I'm not really able to go into detail with you right now.
cheep5k8 said:
BTW it's 9 AM in the morning here, I'm just barely up. I should have waited before replying, I'm not really able to go into detail with you right now.
Click to expand...
Click to collapse
Same here. But it's a holiday here in the Netherlands, King's Day, so I have all day.
I'm just curious to either the mechanics to what you're claiming or measurements to support these saving.
Because to me it looks like you're just disabling Android-specific optimizations by porting the generic Linux driver to the Android kernel.
smitel said:
Same here. But it's a holiday here in the Netherlands, King's Day, so I have all day.
I'm just curious to either the mechanics to what you're claiming or measurements to support these saving.
Because to me it looks like you're just disabling Android-specific optimizations by porting the generic Linux driver to the Android kernel.
Click to expand...
Click to collapse
You've got a good point, and I've been only somewhat dismissive because of the early time of day, sorry for that in any case.
That's what I thought at first, too. But I'll get back with more detail this evening. Thanks for being inquisitive and observant, without peer review stuff would just not be that good
Ok, so, TTYL :good: