Attend XDA's Second Annual Developer Conference, XDA:DevCon 2014!
5,786,599 Members 38,618 Now Online
XDA Developers Android and Mobile Development Forum

Wifi network connectivity issues and a possible fix

Tip us?
 
bganley
Old
(Last edited by bganley; 27th July 2013 at 01:41 AM.) Reason: Updates with latest info
#1  
Member - OP
Thanks Meter 130
Posts: 47
Join Date: Aug 2010
Default Wifi network connectivity issues and a possible fix

4.3 Update: It looks like Android 4.3 (JWR66V) did not fix the Nexus 4 delayed notifications on wifi issue. New wifi drivers with ARP offload support are included but for some unknown reason, Google disabled ARP offload in this release (even though ARP offload was enabled in the leaked 4.3 version). Interestingly, ARP offload is now re-enabled in AOSP JSS15J.

If you are on JWR66V and still have delayed notifications on wifi, then check this post for instructions on how to enable ARP offload either manually or with a flashable ZIP: http://forum.xda-developers.com/show...&postcount=601. Only do this if you are running 4.3 JWR66V.

An alternative option is to try disabling wifi optimization. Some people have found this fixes the delayed notification problem but also causes an increased battery drain.


----------------------------
Below is for Android 4.2 builds only

Update: Android 4.2.2 is out and despite a comment from a Google rep that this was fixed and the fix was scheduled to be included in 4.2.2, it appears that isn't the case. This same rep from Google just confirmed as much in post 34 - https://code.google.com/p/android/is...l?id=42272#c34.

I've confirmed the workaround described in this thread does still work on 4.2.2. Also, the ini file that this workaround changes was untouched between 4.2.1 and 4.2.2 so the same zip files posted here will work on either version.

Also, thanks to thesebastian for finding this - it looks like Qualcomm is finally getting ARP Offload fixed (http://forum.xda-developers.com/show...&postcount=267). Hopefully they will get this pushed out sometime soon.
------------------

Since the Nexus 4 was released, there have been many reports of various problems with wifi. Everything from slow speeds to delayed notifications to not being able to connect to certain APs at all. With the release of Android 4.2.2, a lot of these problems have been fixed. Unfortunately, a number of issues still remain.

One issue that has yet to be fixed as of 4.2.2 is the ability for the phone to respond to ARP requests while the screen is off. This results in the phone being unable to receive network traffic over wifi under certain circumstances while asleep. The most noticeable effect of this issue is notifications being delayed for up to 15 minutes while the screen is off. During this time, turning the screen on will result in these delayed notifications flooding in all at once. You may also notice the wifi signal indicator turning gray immediately after turning the screen on followed a few seconds later by it turning blue. Another symptom that some have had is incoming VoIP calls not ringing the phone while the screen is off but working fine while the screen is on.

This issue has been confirmed by Google (https://code.google.com/p/android/is...etail?id=42272) and is related to a buggy implementation of ARP Offload in the Nexus 4 wifi driver. Due to this, ARP Offload is disabled on the N4. In addition, the N4 wifi driver is set to filter all incoming broadcast and multicast traffic during sleep. Since ARP is broadcast (usually), the combination of these settings will prevent the phone from hearing and responding to ARP requests while the screen is off. If a neighboring network device (such as your router) is unable to obtain the MAC address of the phone, it will be unable to send any traffic to the phone.

Please note that this issue only affects the Nexus 4 (and possibly other devices with the Prima wifi chip). Wifi issues on other devices are not affected by this particular issue. Also note, this is one particular issue with the N4 wifi. There are lots of other issues. The workarounds described here will not help with those issues.

Also, even though all Nexus 4's are affected by this issue, not everyone will be affected in the same way. One of the main reasons for this is due to varying router configurations (in particular, the ARP cache timers). Some will even be lucky enough to have this problem completely masked due to their router configuration. If you are so lucky, you can still see the effect of this issue - turn the screen off, wait a few minutes, and ping the phone from your PC. While doing this run Wireshark and notice the unanswered ARP queries being sent to your phone.

----------------

Until Google releases a proper fix (ARP Offload), there are a couple of options to work around this issue.

Option 1 - Static ARP
The easiest fix is to add a static ARP entry for your N4 to your router. This allows the router to communicate with the phone without having to bother with the ARP process (thereby bypassing the issue completely). On some routers, there is an option to directly add a static ARP entry. On some, you have to do it via the CLI. On some, adding a static DHCP lease also adds a static ARP entry. And of course some just don't allow you to set this.

There are a couple of negatives. First, you may not have access to all routers that you connect to. Even if you do have access, you may not be able to set a static ARP depending on the firmware on the router. Also, you would have to add a static ARP to every device on the same network segment that you would want to communicate with. Say for example you used wireless ADB. In that case you would have to add a static ARP to both the router and the PC that you ran ADB on.

The positive to adding a static ARP entry is you don't have to muck with a system file on the phone and this option is the most battery efficient.

Option 2 - Disable filtering on the N4
Another solution is to disable the unicast and/or multicast filtering on your N4 by modifying an ini file on the phone. This will allow the phone to see all broadcast traffic (including ARP) during sleep. As a result the phone will be able to properly respond to ARP requests.

The positive is once you make this change, the phone will properly respond to ARP requests without having to make any other changes. It will work with any wifi network that you connect to.

The negative is making this change will cause a negative impact on battery life. How much of an impact depends entirely on how much broadcast and multicast traffic exists on your network. The more traffic, the more the phone is woken up, the more the battery hit will be. The only way to know how much of a battery impact you will have is to test it out.

To make the ini file change manually (see below for installable zip files):
  • Make sure your phone is rooted
  • Remount /system as RW
  • Make a backup of file /system/etc/wifi/WCNSS_qcom_cfg.ini
  • Edit the file /system/etc/wifi/WCNSS_qcom_cfg.ini
  • Change the line "McastBcastFilter=3" to "McastBcastFilter=0"
  • Save the file and double check file permissions (-rw-r--r-- root root)
  • Reboot the phone

To undo this change, simply change the "0" back to the original value of "3". If you want to prevent the the phone from hearing multicast traffic while the screen is off but still allow broadcast traffic, you could change the value to "1". This may help with battery life and will keep most things working.

Please remember, this changes a system file so 2 things. First, I'm not responsible if you break something. Second, this will likely prevent the phone from being able to get an OTA. You would need to revert the change before applying an OTA.

--------------------

One other router setting that can cause the same type of issue that some have run into is related to the TCP Established timer. If you are still having this problem after making the ini file change (or static ARP), make sure that the TCP Established timer on your router is set to at least 1200 seconds.

------------------------------------------

Edit 12/31: I attached CWM installable zip files to make changing the ini file easier and help prevent file permission problems, etc. I tested all 3 files with my Nexus 4 using CWM 6.0.2.3.

n4-wifi-sleepfix-restore-original.zip -- This restores the ini file to the original one from stock 4.2.1 JOP40D / 4.2.2 JDQ39.
n4-wifi-sleepfix-mcast_and_bcast.zip -- This sets McastBcastFilter to 0, allowing the phone to hear multicast and broadcast traffic during sleep. Only for 4.2.1 JOP40D / 4.2.2 JDQ39.
n4-wifi-sleepfix-bcast_only.zip -- This sets McastBcastFilter to 1, allowing the phone to hear broadcast traffic during sleep, but not multicast. Only for 4.2.1 JOP40D / 4.2.2 JDQ39.

Don't forget to make a CWM backup first!
The Following 86 Users Say Thank You to bganley For This Useful Post: [ Click to Expand ]
 
mobilehavoc
Old
#2  
mobilehavoc's Avatar
Senior Member
Thanks Meter 296
Posts: 2,052
Join Date: Mar 2006
Quote:
Originally Posted by bganley View Post
Since getting the Nexus 4, I've had problems with wifi network connectivity while the screen is off. The phone will stay associated to the AP (as can be verified by looking at the AP itself), but after a couple minutes of screen-off time, incoming network traffic seems to be ignored by the phone. I also have a Nexus 7, a Galaxy Nexus, and an Atrix - none of which have this problem.

The symptoms are things like gmail notifications taking up to 15 minutes to arrive while the screen is off. Another symptom is seeing the wifi indicator turn gray followed a few seconds later by the indicator turning blue again immediately after turning the screen on.

An easy way to see the issue is to ping the phone from another device connected to the same network segment. Turn the screen on, ping the phone and you should get a response as expected. Turn the screen off, wait a few minutes and try to ping the phone again and you will likely get a timeout. The amount of time you have to wait depends on the OS of the device you are sending the ping from (more specifically the ARP cache timeout).

Doing a network capture, I found the issue that I've been having is the phone doesn't respond to ARP requests while the screen is off. One easy fix that I've been using for a couple of days is to add a static ARP entry. I added one to my router so that it doesn't need to perform an ARP request when sending traffic to the phone. Since doing this I've had 0 problems. Gmail notifications now come in faster on my Nexus 4 than any other android device I own. I also never see the wifi indicator turning gray any more.

I've been doing some more digging and I think I found a better solution to the issue. There is an ini file that allows you to set parameters for the wifi driver on the phone. One of these parameters controls the filtering of multicast and broadcast traffic during power save. The default on the Nexus 4 is to filter all broadcast and multicast traffic. Since ARP requests are broadcast, this is obviously an issue.

I tried changing the parameter to only filter multicast traffic and so far so good. The phone takes a couple of seconds to respond to ARP requests while the screen is off (which is expected during low power states) but it now does respond. Now I just need to run this for a couple of days and see what kind of impact it will have on the battery.

To make the ini file change:
  • Make sure your phone is rooted
  • Remount /system as RW
  • Make a backup of file /system/etc/wifi/WCNSS_qcom_cfg.ini
  • Edit the file /system/etc/wifi/WCNSS_qcom_cfg.ini
  • Change the line "McastBcastFilter=3" to "McastBcastFilter=1"
  • Save the file and reboot

To undo this change, simply change the "1" back to the original value of "3". If you want the phone to hear multicast traffic while the screen is off, you could change the value to "0".

Please remember, this changes a system file so 2 things. First, I'm not responsible if you break something. Second, this will likely prevent the phone from being able to get an OTA. You would need to revert the change before applying an OTA.

I just wanted to pass this along and see if anyone else has been experiencing this issue. If so, hopefully this info will help prevent others from wanting to smash their phone into a million bits.
You're my hero. I'm not rooted and don't want to mess with this yet but curious about static ARP. Assuming you do this by turning on Mac address filtering and adding the N4 Mac address to router. I don't see any way to edit the ARP table on my Cisco E4200

Sent from my Nexus 4 using Tapatalk 2
---------------------------------------------------------------------------------------------------
HTC One - 2.17 Stock (4.2.2) || Nexus 4 - CyanogenMod 10.1 Stable ||
 
miicho85
Old
#3  
Member
Thanks Meter 4
Posts: 99
Join Date: Aug 2012
Location: Chicago
I recently got a Nexus 7 and i can definitely see a difference in wifi performance. I wish i could fix it
 
bganley
Old
#4  
Member - OP
Thanks Meter 130
Posts: 47
Join Date: Aug 2010
Quote:
Originally Posted by mobilehavoc View Post
You're my hero. I'm not rooted and don't want to mess with this yet but curious about static ARP. Assuming you do this by turning on Mac address filtering and adding the N4 Mac address to router. I don't see any way to edit the ARP table on my Cisco E4200

Sent from my Nexus 4 using Tapatalk 2
MAC address filtering is different from a static ARP entry. MAC filtering just defines which MAC addresses are allowed to associate to an access point. A static ARP entry is a way to manually define the MAC address associated with a specific IP address. Normally, the ARP protocol takes care of this for you by broadcasting an ARP request. The device which has the IP address in question sees that broadcast and replies back with its MAC address. Since the phone isn't listening to broadcast traffic while the screen is off, it will never see the ARP request and thus will not respond to an ARP request while the screen is off. Setting a static ARP entry just bypasses the need for the normal ARP processing as the sending device will always know the MAC address of the device it is trying to send a packet to.

I don't have an E4200 so I'm not sure what options it has. On my router, I can telnet to a linux shell on it which allows me to add a static ARP entry with the command "arp -s ip-address mac-address". This adds a static entry to the ARP cache which will be lost on reboot. Of course, you could just add it to a startup script so that it would be added every time the router reboots.

I've heard reports that some routers will effectively add a static ARP entry if you define a static DHCP reservation. You could try that. Somewhere in your router you should be able to say that the MAC address of your phone should always get assigned a specific IP address from DHCP. Actually, I would highly recommend that anyone who wants to try the static ARP method do this regardless. If you specify IP address X equals MAC address Y, it would be a good idea that it always does

Let us know if you have any luck figuring out how to do this on an E4200.
The Following 3 Users Say Thank You to bganley For This Useful Post: [ Click to Expand ]
 
Lucena04
Old
#5  
Member
Thanks Meter 2
Posts: 30
Join Date: Dec 2012
Quote:
Originally Posted by bganley View Post
Since getting the Nexus 4, I've had problems with wifi network connectivity while the screen is off. The phone will stay associated to the AP (as can be verified by looking at the AP itself), but after a couple minutes of screen-off time, incoming network traffic seems to be ignored by the phone. I also have a Nexus 7, a Galaxy Nexus, and an Atrix - none of which have this problem.

The symptoms are things like gmail notifications taking up to 15 minutes to arrive while the screen is off. Another symptom is seeing the wifi indicator turn gray followed a few seconds later by the indicator turning blue again immediately after turning the screen on.

An easy way to see the issue is to ping the phone from another device connected to the same network segment. Turn the screen on, ping the phone and you should get a response as expected. Turn the screen off, wait a few minutes and try to ping the phone again and you will likely get a timeout. The amount of time you have to wait depends on the OS of the device you are sending the ping from (more specifically the ARP cache timeout).

Doing a network capture, I found the issue that I've been having is the phone doesn't respond to ARP requests while the screen is off. One easy fix that I've been using for a couple of days is to add a static ARP entry. I added one to my router so that it doesn't need to perform an ARP request when sending traffic to the phone. Since doing this I've had 0 problems. Gmail notifications now come in faster on my Nexus 4 than any other android device I own. I also never see the wifi indicator turning gray any more.

I've been doing some more digging and I think I found a better solution to the issue. There is an ini file that allows you to set parameters for the wifi driver on the phone. One of these parameters controls the filtering of multicast and broadcast traffic during power save. The default on the Nexus 4 is to filter all broadcast and multicast traffic. Since ARP requests are broadcast, this is obviously an issue.

I tried changing the parameter to only filter multicast traffic and so far so good. The phone takes a couple of seconds to respond to ARP requests while the screen is off (which is expected during low power states) but it now does respond. Now I just need to run this for a couple of days and see what kind of impact it will have on the battery.

To make the ini file change:
  • Make sure your phone is rooted
  • Remount /system as RW
  • Make a backup of file /system/etc/wifi/WCNSS_qcom_cfg.ini
  • Edit the file /system/etc/wifi/WCNSS_qcom_cfg.ini
  • Change the line "McastBcastFilter=3" to "McastBcastFilter=1"
  • Save the file and reboot

To undo this change, simply change the "1" back to the original value of "3". If you want the phone to hear multicast traffic while the screen is off, you could change the value to "0".

Please remember, this changes a system file so 2 things. First, I'm not responsible if you break something. Second, this will likely prevent the phone from being able to get an OTA. You would need to revert the change before applying an OTA.

I just wanted to pass this along and see if anyone else has been experiencing this issue. If so, hopefully this info will help prevent others from wanting to smash their phone into a million bits.
Thank you, but edit "WCNSS_qcom_cfg.ini" not works for me. WiFi simbol nether apears, even when I return to option "3". I used cwm restore and it returned like before (conect but transfer data only for 15 seconds).

Enviado de meu Nexus 4 usando o Tapatalk 2
 
adamase
Old
#6  
Junior Member
Thanks Meter 0
Posts: 23
Join Date: May 2011
The ini change just made wifi fail to start for me, unfortunately.
 
bganley
Old
#7  
Member - OP
Thanks Meter 130
Posts: 47
Join Date: Aug 2010
Quote:
Originally Posted by Lucena04 View Post
Thank you, but edit "WCNSS_qcom_cfg.ini" not works for me. WiFi simbol nether apears, even when I return to option "3". I used cwm restore and it returned like before (conect but transfer data only for 15 seconds).

Enviado de meu Nexus 4 usando o Tapatalk 2
Quote:
Originally Posted by adamase View Post
The ini change just made wifi fail to start for me, unfortunately.
Sorry to hear you guys are having problems. Make sure the file editor you are using isn't changing the permissions. After modifying the file, it should look exactly like this:

shell@android:/system/etc/wifi # ls -l WCNSS_qcom_cfg.ini
-rw-r--r-- root root 5577 2012-12-29 19:17 WCNSS_qcom_cfg.ini

Make sure the permissions (-rw-r--r--), the owner (root), and the group (root) are identical to this. If the permissions, owner, or group are different, you can reset them with:
chmod 644 WCNSS_qcom_cfg.ini
chown root.root WCNSS_qcom_cfg.ini

I've been running this change for 2 days and my wifi has been 100% stable. It has fixed all the problems I was having.
 
bganley
Old
#8  
Member - OP
Thanks Meter 130
Posts: 47
Join Date: Aug 2010
I just wanted to add that I've read about a lot of various wifi problems that people have been experiencing. This fix is specifically to address the problem with the phone not being able to properly maintain an active network connection while the screen is off. The most noticeable symptom is incoming notifications (like new gmail alerts) taking minutes (sometimes up to 15 in my case) instead of seconds to appear.

If you have other problems like slow wifi speeds or not being able to connect to wifi, this patch is still applicable to your Nexus 4 but there are additional problems you are likely encountering. I personally have not experienced any of these other issues.

Also just to clarify, how noticeable the problem is to you will depend on the settings of your router, in particular the ARP cache timeout. For example, enterprise level Cisco gear uses a 4 hour timeout by default whereas linux (which most home routers run) defaults to 60 seconds. The quicker the cache times out, the more noticeable the problem.
 
bganley
Old
#9  
Member - OP
Thanks Meter 130
Posts: 47
Join Date: Aug 2010
Updated first post with CWM installable files to make ini file changes. Please let me know if anyone has any problems installing these.
The Following User Says Thank You to bganley For This Useful Post: [ Click to Expand ]
 
mobilehavoc
Old
#10  
mobilehavoc's Avatar
Senior Member
Thanks Meter 296
Posts: 2,052
Join Date: Mar 2006
Quote:
Originally Posted by bganley View Post
Updated first post with CWM installable files to make ini file changes. Please let me know if anyone has any problems installing these.
Please contact Google so they know about this. I'll be applying the patch tomorrow when I'm back home. Happy New Year!

Sent from my Nexus 7 using Tapatalk 2
---------------------------------------------------------------------------------------------------
HTC One - 2.17 Stock (4.2.2) || Nexus 4 - CyanogenMod 10.1 Stable ||

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes