Wifi network connectivity issues and a possible fix

Search This thread

tracerit

Senior Member
Jan 7, 2008
1,212
129
Orange County, CA
My wifi disconnect issues were solved by flashing Franco r53 kernel. Soo happy :) I was going to replace my phone via rma but then my friends nexus 4 also has the same wifi issues.
 

Ma7moud90

Member
Apr 13, 2011
34
14
Cairo
Temporary solution

I have a Galaxy Nexus with the same problem, and I found a solution that works on all the Nexus phones of my friends
Assuming the network is remembered by your phone, from Wifi settings, turn wifi off and on 2 or 3 times quickly, don't let the phone complete the connection while doing that, then let it connect normally.
connection still drops when I forget to do this trick after getting home, but no dropped connection if I do it
Works for me on stock 4.2 and 4.2.1 and CM10.1 nightlies so far
 

gregb882

Senior Member
Jan 23, 2010
268
25
Fenton
My wifi disconnect issues were solved by flashing Franco r53 kernel. Soo happy :) I was going to replace my phone via rma but then my friends nexus 4 also has the same wifi issues.

That's odd. I didn't notice WiFi disconnect issues until franco kernal r53. I just downloaded r70 and I'm hoping that corrects it.
 

tracerit

Senior Member
Jan 7, 2008
1,212
129
Orange County, CA
That's odd. I didn't notice WiFi disconnect issues until franco kernal r53. I just downloaded r70 and I'm hoping that corrects it.

i only had the wifi disconnects with my hospitals wifi. at home and at my other job, no issues. as long as i don't get it at those three places i'm fine :) looks like i'll have to keep r53 on hand as a backup if further revisions might change things.
 

newuser02

Senior Member
Oct 17, 2010
74
11
Concord, CA
wifi will work for play store, web browsers etc but will not download updates and application installations.

I tried the OP's file in the first post and it did not help.

Flashed cm10 nightly - same problem.

Flashed franko r9 - same problem.

Made my home router - an open router, no passwords, etc..... still not working....

The only way for the wifi to stay connected and successfully install anything from play store is connecting to another phone's open wifi tether.

:crying::crying:

This really sucks as I would like to be able to use wifi calling instead when I'm home! Any suggestions??
 

bganley

Member
Aug 26, 2010
47
130
No way, the problem is the same with both kernels. When I wake up the phone the signal bar is gray, then it returns blue and get the notifications... I have an Italian virtual operator (poste mobile). Other ideas?

This fix is for the problem you describe, but only on WiFi. If you are seeing the same behavior on 3G, then it might have something to do with your provider's network config. It sounds like they might be passing your traffic through a stateful firewall or NAT with a low TCP Established timer. If they have this set to less than 15 minutes, this can cause the bars to go gray. Just a guess.

You can try testing this by seeing how long the screen has to be off for the bars to go gray. Then, send yourself an email from a computer a minute before that amount of time elapses while the screen is off. That would cause google to send you a notification which should reset the timer on your providers side. Then wait a minute so the same amount of time has elapsed that caused the bars to be gray before and turn the screen on. If the bars are gray, then it's probably something else going on.

Not a 100% conclusive test but would be interesting to know the results.
 

bganley

Member
Aug 26, 2010
47
130
My wifi disconnect issues were solved by flashing Franco r53 kernel. Soo happy :) I was going to replace my phone via rma but then my friends nexus 4 also has the same wifi issues.

I have a Galaxy Nexus with the same problem, and I found a solution that works on all the Nexus phones of my friends
Assuming the network is remembered by your phone, from Wifi settings, turn wifi off and on 2 or 3 times quickly, don't let the phone complete the connection while doing that, then let it connect normally.
connection still drops when I forget to do this trick after getting home, but no dropped connection if I do it
Works for me on stock 4.2 and 4.2.1 and CM10.1 nightlies so far

wifi will work for play store, web browsers etc but will not download updates and application installations.

I tried the OP's file in the first post and it did not help.

Flashed cm10 nightly - same problem.

Flashed franko r9 - same problem.

Made my home router - an open router, no passwords, etc..... still not working....

The only way for the wifi to stay connected and successfully install anything from play store is connecting to another phone's open wifi tether.

:crying::crying:

This really sucks as I would like to be able to use wifi calling instead when I'm home! Any suggestions??


Just so you guys know, this fix is for one specific issue with WiFi on the N4. Apparently there's a number of other wifi issues which you guys are probably running in to that will hopefully be fixed with an OTA soon.

This particular issue is where you stop receiving notifications while the screen is off and the phone is connected via wifi. You may also notice the wifi bars turning gray when you turn the screen on and then turning blue again after a few moments. Google has confirmed this problem and has a fix for it. Please see comment 535 from a Google employee here: https://code.google.com/p/android/issues/detail?id=40065#c535.
 

mobilehavoc

Senior Member
Mar 12, 2006
2,172
356
4.2.2 has started rolling out. Let's hope it fixes these wifi issues. Fingers crossed!

Sent from my Nexus 4 using Tapatalk 2

Just installed 4.2.2 and can confirm they've fixed the issue. Not rooted so not sure if they changed the config which I doubt or fixed the driver for the wifi. Either way I'm happy. :D

Sent from my Nexus 4 using Tapatalk 2
 
  • Like
Reactions: zstoichev

bganley

Member
Aug 26, 2010
47
130
just flashed 4.2.2 and kept root.

the config ini file looks the same with it still = 3

Ideally the ini file would still be set to 3 combined with the ARP offload setting being changed to a 1 to enable. This would filter all broadcasts and multicasts from reaching the CPU while the screen is off and let the ARP offload feature handle responding to ARP requests. The problem in 4.2.1 was ARP offload was very buggy so they disabled it which combined with the filtering of broadcasts, broke ARP.
 

bganley

Member
Aug 26, 2010
47
130
Just installed 4.2.2 and can confirm they've fixed the issue. Not rooted so not sure if they changed the config which I doubt or fixed the driver for the wifi. Either way I'm happy. :D

Sent from my Nexus 4 using Tapatalk 2

I just updated and did some basic testing and I'm not having any luck so far. I still have the exact same problem. Are you able to ping the phone from another device (which hasn't talked to the phone at all) while the screen is off?

I'll play with this some more tomorrow.
 

PikkonX

Senior Member
Oct 8, 2009
398
65
Chesapeake, VA
The update certainly fixed my Wi-Fi issue. I'm on a 60/30mbps connection, but the N4 would never go above 7mbps in Speedtest for some reason. After 4.2.2 it seems to be working normally and hits 19mbps which seems to be what the Speedtest app maxes out at.

Sent from my Nexus 4 using xda premium
 
  • Like
Reactions: rogerski1

mobilehavoc

Senior Member
Mar 12, 2006
2,172
356
I just updated and did some basic testing and I'm not having any luck so far. I still have the exact same problem. Are you able to ping the phone from another device (which hasn't talked to the phone at all) while the screen is off?

I'll play with this some more tomorrow.

Didn't try pinging but I'm getting notifications while on wifi and asleep just fine. Could be that the phone doesn't respond to pings for some reason? Have you tested to see if notifications work? I'll test more but so far it seems to be working fine.

Sent from my Nexus 4 using Tapatalk 2
 

sl4y3r88

Senior Member
Mar 8, 2012
139
6
I know im posting in the wrong section, but I have the same issue with the wifi on my Gnex(Stock 4.2.2). The wifi bars havent been going grey(Like on 4.2.1) but im not getting notifications when the phone is asleep, sure that translates to not being able to ping the device. Really disappointing.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 86
    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!
    18
    Ok guys something weird is happening.
    I reported a few days ago that I was running the 4.3 leaked rom and that this problem was fixed.

    Well today, I flashed the official factory images for 4.3 and the problem has come back.
    Anytime with screen off now, pinging my phone with my computer will instantly drop packets again (same as 4.2.2 problem).

    Once again, my settings are static ip, wifi optimization ON.

    Now here is the weird part: I compared the WCNSS_QCOM_CFG.ini file from the leaked 4.3 rom and the official factory image and they are identical except for two lines:
    gEnableActiveModeOffload
    hostArpOffload

    Both flags are set to =0 on the factory 4.3 image; while in the leaked rom they are set to =1.

    Since this discovery, I have changed both settings to mimic the leaked 4.3 rom (ie. to =1 for both settings) and NOW my problem is FIXED again.

    Anyone else notice this? Is this a mistake on Google's part for not enabling these two flags on the factory images? Does anyone that got the OTA want to check their wcnss_qcom_cfg.ini file?

    tldr: change gEnableActiveModeOffload AND hostARPOffload in the wcnss_qcom_cfg.ini file to =1 and the problem should be fixed...at least for me so far..


    As jeffwei8 found, the options in the ini file for ARP offload were enabled in the leaked 4.3 image, and disabled in the official 4.3 image. I have no idea why Google has these settings disabled now - there very well may be a good reason for it. Either way it is interesting that some people are reporting that their wifi issue is now fixed with 4.3, and some are still having the same problem with delayed notifications.

    I don't have an N4 anymore, so I can't test this but since re-enabling ARP offload in the ini file seemed to fix jeffwei8's delayed notifications on wifi, I put together a CWM zip update to enable ARP offload in the wifi ini file.

    Flash this patch using CWM at your own risk - this is untested. Also attached to this post is a CWM zip to restore the ini file to what was included in the official 4.3 image.
    6
    Is this related to Nexus 4 "WiFi driver"?

    https://www.codeaurora.org/gitweb/external/wlan/?p=prima.git;a=shortlog

    I'm seeing recently changes, but i don't know if it's for a totally different device. (I saw this folder on nexus 4: /vendor/firmware/wlan/prima/ )

    I also saw that they now use McastBcastFilter=0 like in the OP.

    What about this one? (26-FEB-2013)


    https://www.codeaurora.org/gitweb/e...it;h=b8ddf46808da1267b35086b478884bed27360e5c
    6
    OK, So how does your fix work?

    It is a workaround to let the phone hear and respond to ARP requests. It does this by telling the wifi driver to not filter broadcast/multicast traffic during sleep. The negative of course is the CPU needs to process every broadcast/multicast packet received during sleep which prevents the phone from staying in deep sleep. On busy networks, this can really add up.

    This is why they filter broadcast/multicast traffic during sleep. Problem is if you don't respond to ARP requests (which are normally broadcast) then other devices won't be able to send any traffic to your phone. This is what is causing the late notifications issue that this workaround addresses.

    The real solution is to use ARP offload. This basically offloads the processing of ARP to the wifi driver. With this enabled, the wifi driver can still filter broadcast/multicast traffic to save battery during sleep and at the same time receive and respond to ARP requests so network connectivity isn't broken (all without hitting the CPU).

    The issue on the N4 is ARP offload is broken - pretty badly. So it is disabled which in conjunction with the filtering is what is causing the issue.

    Once Google pushes a patch that fixes and enables ARP offload, then this workaround won't be needed any more. Supposedly it was schedule to be in 4.2.2 but so much for that....
    6
    Nice!!

    It seems that we can also download these new drivers. But i have no idea how to install them...(for instance: WCNSS_cfg.dat ). There are a lot of folders with those files in the N4. (Probably a lot of them are symlinked or whatever; but they have different permissions).

    To check this, i downloaded and extracted: wlan: cs release 3.2.0.70.

    I am rewriting this post for clarity and because what I wrote previously is incorrect.

    The specific file linked before is a firmware that is located in /etc/wifi/ in our device, however simply swapping the files will not work and is not recommended.

    Good news is that this does look like the problem we're having is being worked on. As a matter of fact if the change log is accurate the fix is implemented already we just have to wait for the update.

    Even better news is that someone might be able to make this available sooner if all the source code is available.

    EDIT: This is the code change that allegedly fixes the ARP offload issue we are having, for anyone curious: https://www.codeaurora.org/gitweb/e...ff;h=b8ddf46808da1267b35086b478884bed27360e5c

    Sent from my Nexus 7 using Tapatalk HD