Wifi network connectivity issues and a possible fix

bganley · Dec 30, 2012

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://xdaforums.com/showpost.php?p=43940926&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/issues/detail?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://xdaforums.com/showpost.php?p=38598963&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/issues/detail?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!

mobilehavoc · Dec 30, 2012

bganley said:
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

miicho85 · Dec 30, 2012

I recently got a Nexus 7 and i can definitely see a difference in wifi performance. I wish i could fix it

bganley · Dec 30, 2012

mobilehavoc said:
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.

Lucena04 · Dec 31, 2012

bganley said:
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 · Dec 31, 2012

The ini change just made wifi fail to start for me, unfortunately.

bganley · Dec 31, 2012

Lucena04 said:
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 said:
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 · Dec 31, 2012

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 · Dec 31, 2012

Updated first post with CWM installable files to make ini file changes. Please let me know if anyone has any problems installing these.

mobilehavoc · Dec 31, 2012

bganley said:
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

defnz · Jan 2, 2013

How does this impact battery life e.g. will it cause wakeups when responding to broadcast/multicast requests?

Whilst my Nexus 4 seems to stop responding to pings when the screen is off I still seem to get notifications in a timely manner, even with mobile data turned off just to test

antih3ro · Jan 2, 2013

I flashed the n4-wifi-sleepfix-mcast_and_bcast.zip but the problem still exists. Gmail and whatsapp notification takes about 5 minutes...

floepie · Jan 2, 2013

How do the default settings on the N4 differ when it comes to this line in the INI when compared to other devices? Are other devices able to capture GMail messages almost instantly despite having a value of '3' in this line? I know that my One X was fantastic when it came to receiving messages quickly, whereas this N4 takes a long time to get messages.

bganley · Jan 2, 2013

defnz said:
How does this impact battery life e.g. will it cause wakeups when responding to broadcast/multicast requests?

Whilst my Nexus 4 seems to stop responding to pings when the screen is off I still seem to get notifications in a timely manner, even with mobile data turned off just to test

I've been testing the battery life impact the last few days and so far it appears the ini file patch has an impact. This is expected as the phone now has to process incoming broadcast/multicast packets. With the patch applied, it appears to really aggravate the msm_hsic_host wakelock nonsense and in turn cause the phone to spend less time in deep sleep according to BBS. In my case, this hasn't resulted in that much of a difference in battery life but I'm continuing to monitor.

I did try out Franco's latest kernel as he has some patches for the wakelock issue and with his kernel there was a huge improvement in deep sleep time both with and without this patch applied. Battery usage per hour also improved from about 1.2% with the stock kernel to about 0.5% with Franco's kernel.

Interesting that you still receive notifications in a timely manner. What amount of time do you consider timely? For me, it was taking anywhere from instant notification (rare) to 15 minutes at the worst without this patch. What router do you use? Are you running any custom firmware on your router? Is your phone assigned a static or DHCP address? Are you using a static DHCP reservation for your phone?

bganley · Jan 2, 2013

antih3ro said:
I flashed the n4-wifi-sleepfix-mcast_and_bcast.zip but the problem still exists. Gmail and whatsapp notification takes about 5 minutes...

Your sig says your are running CM? I'm not sure how this patch would work with that ROM. I've only tested with stock JOP40D.

bganley · Jan 2, 2013

floepie said:
How do the default settings on the N4 differ when it comes to this line in the INI when compared to other devices? Are other devices able to capture GMail messages almost instantly despite having a value of '3' in this line? I know that my One X was fantastic when it came to receiving messages quickly, whereas this N4 takes a long time to get messages.

The other devices I've looked at don't have the same wifi chip and therefore don't have this INI file. I did a bunch of testing with my Galaxy Nexus and Nexus 7 to try and determine how they were behaving in regards to multicast/broadcast traffic during sleep. I was able to show that both devices process and respond to both broadcast and multicast traffic during sleep.

This makes sense as certain network functions (such as ARP) rely on broadcast traffic. If a device isn't processing broadcast traffic, then those things break as we've seen with this phone.

I have a GNex, a N7, and an Atrix all running alongside the Nexus 4. All of those phones respond to incoming gmail notifications within seconds and now with this patch, so does my N4.

theltrj · Jan 2, 2013

I've had the exact same issues with my nexus 4....thanks

Sent from my Nexus 7 using Tapatalk HD

defnz · Jan 3, 2013

bganley said:
Interesting that you still receive notifications in a timely manner. What amount of time do you consider timely? For me, it was taking anywhere from instant notification (rare) to 15 minutes at the worst without this patch. What router do you use? Are you running any custom firmware on your router? Is your phone assigned a static or DHCP address? Are you using a static DHCP reservation for your phone?

I've been doing comparisons with a SGS2 and sometimes the N4 receives it before the SGS2, sometimes after, it's anywhere from instant ~5 seconds for gmail, sometimes it can take longer but the delay is seen on both the N4 and the SGS2. However with gTalk its pretty much instant on both.

I'm running an Asus RT-N66U w/ Asuswrt-Merlin 3.0.0.4.264.22 firmware
DHCP, no DHCP reservations, no static arp entry either

In saying that, I don't disagree with your findings though. The phone should have multicast/broadcast enabled so that it doesn't break things like ARP.

floepie · Jan 3, 2013

I'd like to get this to work, but unfortunately, things haven't changed a bit. Permissions are correct, rebooted, etc. I'm running DD-WRT and have reserved a static IP at the router by MAC association, which I do for everything on the network by the way. I've even changed DHCP to static on the device. Gmails show instantly at the PC, but appear up to 15 minutes later on the device. The device is ping-able when the screen is off.

mobilehavoc · Jan 3, 2013

floepie said:
I'd like to get this to work, but unfortunately, things haven't changed a bit. Permissions are correct, rebooted, etc. I'm running DD-WRT and have reserved a static IP at the router by MAC association, which I do for everything on the network by the way. I've even changed DHCP to static on the device. Gmails show instantly at the PC, but appear up to 15 minutes later on the device. The device is ping-able when the screen is off.

Try changing to 0 so it is not filtering anything

Sent from my Nexus 4 using Tapatalk 2

Wifi network connectivity issues and a possible fix

Member

Attachments

Senior Member

Senior Member

Member

Member

Member

Member

Member

Member

Senior Member

Senior Member

Member

Senior Member

Member

Member

Member

Member

Senior Member

Senior Member

Senior Member

Similar threads

Top Liked Posts