Wifi network connectivity issues and a possible fix
: 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.
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 22.214.171.124.
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!