FORUMS
Remove All Ads from XDA

Wifi network connectivity issues and a possible fix

47 posts
Thanks Meter: 131
 
By bganley, Member on 30th December 2012, 01:55 AM
Post Reply Email Thread
13th January 2013, 01:50 PM |#101  
floepie's Avatar
Senior Member
Flag Amsterdam
Thanks Meter: 449
 
More
Quote:
Originally Posted by iammudd

Some crude STANDBY testing results (on Faux kernel 04 beta 6 and PA 2.99 11JAN):

How do you arrive at the conversion factor between awake times and % battery loss?
 
 
13th January 2013, 03:12 PM |#102  
iammudd's Avatar
Senior Member
Thanks Meter: 60
 
More
Quote:
Originally Posted by mobilehavoc

The problem is the almost infinite number of hotspots I can't control that I might connect to. Hence why a fix on the phone for all situations with a battery sacrifice makes more sense than a fix for just one situation.

Yes, true...but when you are connected to a free hotspot, your phone will likely NOT be in deep sleep. For a several hour unattended situation (say, WiFi at work), it doesn't take that much effort/time to re-enable broadcasts.

---------- Post added at 07:12 AM ---------- Previous post was at 06:57 AM ----------

Quote:
Originally Posted by floepie

How do you arrive at the conversion factor between awake times and % battery loss?

I didn't perform any conversions. They're simply the stats from BetterBatteryStats

BTW, awake is not necessarily equal to screen on time. It includes when the phone is awoken from deep sleep to process events. Screen on would consume more power.

Also, FYI, bganley's mod is still required with Faux kernel 004m.

Purely speculation... but I suspect that the broadcast filter issue was known to Android devs as a conscious choice to conserve battery. When they included options like "WiFi optimization" and "leave WiFi on during sleep", someone would have surely tested by pushing data to the N4. But while ignoring broadcasts, perhaps they forgot to switch from push mail to polling (before going to deep sleep). (Polling would have at least reset the arp cache timer. Perhaps their testers had polled exchange mail, etc running which hid the problem.)
13th January 2013, 04:31 PM |#103  
floepie's Avatar
Senior Member
Flag Amsterdam
Thanks Meter: 449
 
More
Quote:
Originally Posted by iammudd

I didn't perform any conversions. They're simply the stats from BetterBatteryStats

Well, I still don't see where bbs would report that 32 minutes of awake time, for instance, as you show on the first line of your data would result in a 4% battery loss. Unless, there is a setting I'm overlooking.


Quote:
Originally Posted by iammudd

(Polling would have at least reset the arp cache timer. Perhaps their testers had polled exchange mail, etc running which hid the problem.)

Yes, but even if polling were to reset the arp cache timer at the router, by definition, the arp timer would have to be shorter than 15 minutes in order for the GMail push feature problem to be present. Even if you have set your device to "push" setting instead of regular polling, the device restores the port 5228 connection every 15 minutes in order to retrieve mail. And, after a few minutes, presumably this arp cache is cleared, preventing any pushed messages getting to your device. So, I don't see how polling would be any better than just letting your device retrieve its mails every 15 minutes.
13th January 2013, 05:44 PM |#104  
iammudd's Avatar
Senior Member
Thanks Meter: 60
 
More
Quote:
Originally Posted by floepie

Well, I still don't see where bbs would report that 32 minutes of awake time, for instance, as you show on the first line of your data would result in a 4% battery loss. Unless, there is a setting I'm overlooking.

In BBS, choose "OTHER". It will show battery loss as a % (edit: since unplugged for example) and awake time.

Quote:

Yes, but even if polling were to reset the arp cache timer at the router, by definition, the arp timer would have to be shorter than 15 minutes in order for the GMail push feature problem to be present.

The arp timer on your router? Yes, sadly, the timers are incredibly short. On mine, it's prob no more than 2 mins.So even having the N4 poll mail at 5 mins isn't enough to keep it active in the arp cache.

Quote:

Even if you have set your device to "push" setting instead of regular polling, the device restores the port 5228 connection every 15 minutes in order to retrieve mail.

I'm not familiar with how Google push mail is actually implemented... but if it is simply a case of having an open TCP session with Google servers, then that won't necessarily refresh arp caches. Perhaps my memory is failing me but TCP connections can remain open indefinitely (if desired) without having any traffic for a long time (certainly longer than 2 minutes). (Otherwise, there'd be no need for explicit TCP keep-alives.)

At the very least, the N4 needs to wake and send something. Even then, most routers won't necessarily maintain the arp entry based on traffic alone. An arp request/reply is normally required. (That is another example of where you DON'T want long or static arp entries. You actually want the N4 to arp.)

Quote:

So, I don't see how polling would be any better than just letting your device retrieve its mails every 15 minutes.

Sorry, perhaps I missed your point...but that was the original reason for the bcast mod or static arp, Without these workarounds, the N4 doesn't send anything to Google servers and unsolicited data from the servers can't reach the N4.

If the N4 was connected with bcast enabled to a large WiFi network with many other devices, I suspect that the N4 will be awake most of the time (due to the very short arp timeout of PCs, etc.) With the power and functionality of smartphones, it's easy to forget that they start out as phones and phones aren't in a broadcast domain so I can understand why a dev would consider ignoring bcasts.

I only used polled email as an example of a potential workaround but I really wouldn't want to poll mail (or weather) that frequently. (It actually requires quite a bit of processing for session creation/tear-down ... especially if retries are required.) I suspect that a compromise solution would be to have the N4 issue gratuitous arps every minute or two. (No connection establishment. No waiting for ack's. So the device can resume deep-sleep quicker.)
13th January 2013, 09:18 PM |#105  
floepie's Avatar
Senior Member
Flag Amsterdam
Thanks Meter: 449
 
More
Quote:
Originally Posted by iammudd

In BBS, choose "OTHER". It will show battery loss as a % (edit: since unplugged for example) and awake time.

Oh, you are referring to total % battery loss. "OTHER" only reports total battery loss, and I was under the assumption that you were attributing the % loss to a specific wakelock. Even still, on the third line of your table you show over 7 hours of standby with no battery loss, despite 2-3 minutes of awake time? Surely your wifi radio had been turned on which would have consumed more power than that?


Quote:
Originally Posted by iammudd

I'm not familiar with how Google push mail is actually implemented... but if it is simply a case of having an open TCP session with Google servers, then that won't necessarily refresh arp caches. Perhaps my memory is failing me but TCP connections can remain open indefinitely (if desired) without having any traffic for a long time (certainly longer than 2 minutes). (Otherwise, there'd be no need for explicit TCP keep-alives.)

The TCP connection with Google's servers renews itself after 15 minutes, even if a static arp has been established. That, according to my router logs at least. It always goes over TCP 5228. And, along with that there is a port 443 connection that's maintained and marked ESTABLISHED as well.

Quote:
Originally Posted by iammudd

Sorry, perhaps I missed your point...but that was the original reason for the bcast mod or static arp, Without these workarounds, the N4 doesn't send anything to Google servers and unsolicited data from the servers can't reach the N4.

I only used polled email as an example of a potential workaround but I really wouldn't want to poll mail (or weather) that frequently. (It actually requires quite a bit of processing for session creation/tear-down ... especially if retries are required.) I suspect that a compromise solution would be to have the N4 issue gratuitous arps every minute or two. (No connection establishment. No waiting for ack's. So the device can resume deep-sleep quicker.)

OK, I thought you were making the argument that Google should have at least ensured that polling would have been used as a fallback mechanism in the case of short arp timeouts. But, even in the absence of broadcast replies (no static arp entries or no wifi "fixes"), the device seems to wake itself and reconnect over port 5228, and once established, one receives email. This is presumably why, before I had created a static IP (and arp entry) at the router, I had never (or rarely) received email later than 15 minutes after they were received at Google. Perhaps it can be considered "polling" after all if the net result is the same.
13th January 2013, 11:12 PM |#106  
iammudd's Avatar
Senior Member
Thanks Meter: 60
 
More
Quote:
Originally Posted by floepie

Even still, on the third line of your table you show over 7 hours of standby with no battery loss, despite 2-3 minutes of awake time? Surely your wifi radio had been turned on which would have consumed more power than that?
...
But, even in the absence of broadcast replies (no static arp entries or no wifi "fixes"), the device seems to wake itself and reconnect over port 5228, and once established, one receives email ... Perhaps it can be considered "polling" after all if the net result is the same.

I should mention that I have gTalk frozen.
(Since it was 4% for 30 mins awake, then 3 mins awake should be ~0.4% ... so I'm not totally surprised by a 0% being displayed.)

With gTalk frozen, I wasn't expecting any sustained connections to be maintained with Google servers so I never bothered to look. All I noticed was that the arp entry for the N4 was either incomplete or non-existent for >20 mins. Only when I enabled an IMAP client, did I see a complete arp entry for the N4. But as I said, any polling solution is not really viable. It's not lightweight and most of the time unsolicited connection requests would still receive "dest unreachable".
14th January 2013, 05:11 AM |#107  
OP Member
Thanks Meter: 131
 
More
Quote:
Originally Posted by iammudd

Purely speculation... but I suspect that the broadcast filter issue was known to Android devs as a conscious choice to conserve battery. When they included options like "WiFi optimization" and "leave WiFi on during sleep", someone would have surely tested by pushing data to the N4. But while ignoring broadcasts, perhaps they forgot to switch from push mail to polling (before going to deep sleep). (Polling would have at least reset the arp cache timer. Perhaps their testers had polled exchange mail, etc running which hid the problem.)

This would imply that all android devices ignore broadcasts/multicasts while in deep sleep. I have a Galaxy Nexus and N7 running 4.2.1 which both always responds to ARP requests no matter how long the screen is off. Intentionally filtering broadcast traffic would also break Google's Cloud to Device Messaging (push notifications) which I would hope they wouldn't knowingly do. Of course, this is only a problem in environments with shorter ARP timers.

Responding to the followup's of your post, TCP connections can stay up indefinitely but a problem comes in when you have a stateful firewall in the path. Modern firewalls track all connections through them and automatically allow the return traffic from the untrusted interface for current valid connections. This connection tracking applies timers to everything being tracked. If a timer expires without seeing any traffic for that connection, the firewall will time out that connection and no longer allow the return traffic. In the case of push notifications, that means the notification coming from Google will get stopped at the firewall.

The way around this is to send keepalive's. In the case of Google's Cloud to Device Messaging, it appears that google uses a keepalive timer of 15 minutes. This means that every 15 minutes, the phone will send a packet to Google which will refresh the state of the connection in the firewall thus keeping the connection open. If the connection had timed out during those 15 minutes, it will open a new connection which is why you never see notifications taking more than 15 minutes to show up.

The TCP Established timer is the timer that applies here and would need to be set to greater than 15 minutes for the connection to remain alive with keepalives.

Hopefully that helps explain things.
14th January 2013, 08:05 AM |#108  
Junior Member
Thanks Meter: 0
 
More
I have noticed with my nexus 4 that even though the wifi connection setting states 'always on', when I have my phone connected to the outlet and idle, that I have no connection issues connecting to ssh on my nx4. However, on the battery and idle, connection issues persist.
14th January 2013, 11:47 AM |#109  
mobilehavoc's Avatar
Senior Member
Thanks Meter: 356
 
More
Quote:
Originally Posted by zitstif

I have noticed with my nexus 4 that even though the wifi connection setting states 'always on', when I have my phone connected to the outlet and idle, that I have no connection issues connecting to ssh on my nx4. However, on the battery and idle, connection issues persist.

That's because android doesn't let the phone sleep while charging so even though the screen is off the phone is awake. This is expected behavior with all Android phones.

Sent from my Nexus 4 using Tapatalk 2
14th January 2013, 12:12 PM |#110  
Senior Member
Thanks Meter: 17
 
Donate to Me
More
Hi, I dont understand one thing:
In this thread are few people who have problem that our phone not responding to ARP requests when the screen is off...
And what about many others Nexus4 users? This is only issue a few pieces of phone N4 (ours), and other are OK? Because the vast majority of Nexus users dont have any issues with wifi connectivity described in this thread and this isnt issue of Nexus4 whole community ... Why few has this wifi issue, and many others not? ?softwares of phones must be the same! - cant be a differences in wifi behavior. (few users eg on stock ROM have this issue and many on the same ROM not; this fix help someone, someone not...)
therefore begins to have suspicions whether it is not a hardware issue of router, or something similar... I dont known, but I'm frustrated of this...
14th January 2013, 12:42 PM |#111  
iammudd's Avatar
Senior Member
Thanks Meter: 60
 
More
Quote:
Originally Posted by bganley

This would imply that all android devices ignore broadcasts/multicasts while in deep sleep. I have a Galaxy Nexus and N7 running 4.2.1 which both always responds to ARP requests no matter how long the screen is off.

My most recent standby results are below. I would be curious to see what the awake % are for Gnex and N7 as a comparison... because it looks like one would be better off (battery-wise) using 3G while on standby.

(Mind you, on my home network, I see Dropbox polling every few seconds and an old NDAS device polling every second... On the other hand, it's prob not unrealistic to see a bcast every second on a public network either.)

Code:
Broadcast  On Battery   Awake          Battery% (Total Drop)
Disallowed   7h50       3 mins ( 0.6%)   ~0
  3G         7h56       7 mins ( 1.5%)   ~1%
--- previously (with the prev version of kernel)
 Allowed     5h59      32 mins ( 8.9%)   -4%
 Allowed     5h50      36 mins (10.3%)   -5%
The Following User Says Thank You to iammudd For This Useful Post: [ View ] Gift iammudd Ad-Free
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes