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/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://forum.xda-developers.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!
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.
Click to expand...
Click to collapse
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
I recently got a Nexus 7 and i can definitely see a difference in wifi performance. I wish i could fix it
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
Click to expand...
Click to collapse
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.
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.
Click to expand...
Click to collapse
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
The ini change just made wifi fail to start for me, unfortunately.
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
Click to expand...
Click to collapse
adamase said:
The ini change just made wifi fail to start for me, unfortunately.
Click to expand...
Click to collapse
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:
[email protected]:/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.
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.
Updated first post with CWM installable files to make ini file changes. Please let me know if anyone has any problems installing these.
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.
Click to expand...
Click to collapse
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
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 flashed the n4-wifi-sleepfix-mcast_and_bcast.zip but the problem still exists. Gmail and whatsapp notification takes about 5 minutes...
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.
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
Click to expand...
Click to collapse
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?
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...
Click to expand...
Click to collapse
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.
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.
Click to expand...
Click to collapse
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.
I've had the exact same issues with my nexus 4....thanks
Sent from my Nexus 7 using Tapatalk HD
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?
Click to expand...
Click to collapse
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.
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.
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.
Click to expand...
Click to collapse
Try changing to 0 so it is not filtering anything
Sent from my Nexus 4 using Tapatalk 2
I'm having a strange issue with my Exhibit . I'm running CyanogenMod 11 20140714-UNOFFICIAL although I think I saw this earlier too. When I'm home on my WiFi, battery use it great. Under 2%/hour. When I'm at work on the WiFiit is pretty bad, around 6-7% per hour. If I turn off WiFi, it gets much better (maybe 3% per hour). Same thing if I forget the WiFi network at work. Sometimes in my battery use graph I can see it get flat for and hour and then get bad again -- I think this is losing the WiFi connection for a bit and then reconnecting.
Work recently moved and the results didn't change enough though my data service strength changed a lot. So I'm pretty sure it has to do with the WiFi network. Other people at work don't notice a drain when using WiFi, so I'm guessing it is a combination of the work WiFi and the phone.
The work WiFi is running tomato 1.27, which I administer. I sniffed the WiFi traffic with my laptop and saw a lot of ARP requests for 'who has address' for address not on the WiFibut on our unsecured network. So I separated that with a VLAN and that helped a bit but not a ton, and the ARP requests are much lower (maybe a ~1 / minute). Signal strength is as good or better at work than at home and at home there is way more congestion of neighbor's WiFi.
I know it isn't my phone usage as I would reboot my phone and not touch it for 3 hours and look at the battery drain at both work and at home and see these differences.
Any ideas on what makes the WiFi at work with a tomato router (vs some netgear wifi router) worse on battery than my home network. Work has maybe 7 clients connected at a time, vs probably just the phone at home. Any ideas on how to troubleshoot / debug. Packet sniffing on the WiFi didn't show anything that stood out.
Thanks!
exhibit679 said:
I'm having a strange issue with my Exhibit . I'm running CyanogenMod 11 20140714-UNOFFICIAL although I think I saw this earlier too. When I'm home on my WiFi, battery use it great. Under 2%/hour. When I'm at work on the WiFiit is pretty bad, around 6-7% per hour. If I turn off WiFi, it gets much better (maybe 3% per hour). Same thing if I forget the WiFi network at work. Sometimes in my battery use graph I can see it get flat for and hour and then get bad again -- I think this is losing the WiFi connection for a bit and then reconnecting.
Work recently moved and the results didn't change enough though my data service strength changed a lot. So I'm pretty sure it has to do with the WiFi network. Other people at work don't notice a drain when using WiFi, so I'm guessing it is a combination of the work WiFi and the phone.
The work WiFi is running tomato 1.27, which I administer. I sniffed the WiFi traffic with my laptop and saw a lot of ARP requests for 'who has address' for address not on the WiFibut on our unsecured network. So I separated that with a VLAN and that helped a bit but not a ton, and the ARP requests are much lower (maybe a ~1 / minute). Signal strength is as good or better at work than at home and at home there is way more congestion of neighbor's WiFi.
I know it isn't my phone usage as I would reboot my phone and not touch it for 3 hours and look at the battery drain at both work and at home and see these differences.
Any ideas on what makes the WiFi at work with a tomato router (vs some netgear wifi router) worse on battery than my home network. Work has maybe 7 clients connected at a time, vs probably just the phone at home. Any ideas on how to troubleshoot / debug. Packet sniffing on the WiFi didn't show anything that stood out.
Thanks!
Click to expand...
Click to collapse
try adjusting some of the settings in the wireless advance settings also make sure your wifi is using the least crowed possible channel and 1,6,and 11 can overlap without interference. easy way to find the best channels is to use an app on a laptop or smartphone with wifi.
Android Wifi Analyzer Free in app store
windows insidder 3 free
Linux LinSSID free
*NOTE too much interfernce may cause network delays which in turn force rechecking connection due to lost packets. also it after trying the above the second thing it could be is possible routers wifi is slowly going out. I've had a linksys router do that. new ping was awesome for e.g playing league of legends 81 when wifi notice her wifi connection kept droping. rebooted router and it worked fine for a a while then did it again and slowly became more frequent ping also increased to 106. replaced router with a new one and ping dropped to 73 and 0 wifi drops or slow downs. hope this helps
I'm pretty sure it isn't interference. At home there are 15 strong WiFi stations across all channels. At work, there are only 2 other WiFi stations and mine is at a channel far from them, so the X-talk from WiFi is way better at work. Also when work moved, I saw no change (although WiFi wasn't crowded at only location either) so I think it has to do with the WiFi network and not the environment.
did you test to make sure wifi isnt dropping packets either as well as check routers wifi intervals
did you test to make sure wifi isnt dropping packets either as well as check routers wifi intervals
Click to expand...
Click to collapse
How would you test if wifi is dropping packets? Just a ping on my phone? I can ping wireless consistently from my desktop, but that is over ethernet.
What do you mean by "wifi intervals"? Is that a setting I should see on my tomato firmware? "Beacon Interval" is set to 100, but I don't claim to understand that. "DTIM Interval" is set to 1.
Thanks,
exhibit679 said:
How would you test if wifi is dropping packets? Just a ping on my phone? I can ping wireless consistently from my desktop, but that is over ethernet.
What do you mean by "wifi intervals"? Is that a setting I should see on my tomato firmware? "Beacon Interval" is set to 100, but I don't claim to understand that. "DTIM Interval" is set to 1.
Thanks,
Click to expand...
Click to collapse
yes that is correct for wifi intervals in the tomato firmware. look at This for better info for what each setting is for. the 3 main ones i would be adjusting as needed is Beacon Interval , Fragmentation Threshold and Interference Mitigation.To test pack loss anything thats on wifi and can ping router. So yeah your phone will work. just make sure you ping the routers ip address e.g for linksys 192.168.1.1
I haven't changed any of the wireless settings yet, but I do have more data. My phone sometimes is on the wifi and has normal (low) battery usage. Today from 9:30 - 12:30 it was great, but after 12:30 there was a discontinuity in the battery vs time graph as the slope decreased by over a factor of 3. Not sure what changed -- I don't see different devices on the wireless or higher wireless utilization. I'm thinking something in the wifi trips a setting or something on the wifi isn't completing on the phone and is draining the battery.
Anybody else having issue with wifi being dropped?
A status will pop up saying "Wifi network available" then disconnect my wifi. I literally have to go to wifi settings and disable/enable for it to work again, then drops gain. It's connecting to a home Netgear router. Haven't tried wifi else where (cafe's/shops) as my 4G works superbly.
I'm sure the issue is worse with a bluetooth headset connected.
It's a D5803 on firmware 23.0.A.2.93 UK EE.
Thanks
I'm guessing I'm the only one experiencing this lol. I've tried searching for more info, even other brands/models. Maybe a software glitch..I would doubt its hardware.
Wifi dropped
Hi, i'm getting the same issue - connects then drops immediately but my wifes phone has no problems and exactly the same phone!
I don't really have that issue here. Never had it with Bluetooth.
Sometimes my WiFi does drop tho, but after a few seconds it tries to reconnect, but that's only because my router's coverage sucks...
i don't really have that issue. but usually if you're connecting to the 2.4ghz band and you use BT (which also uses 2.4ghz), you get problems with them interference. I only notice occasional interference/static when i'm using my bt headphones and my wifi is scanning. I don't get connection drops though.
Try to look into your router log, there you can basically see if it is a problem with your router or not.
What are your wifi options?
I have : Notifications: off
leave activated in standby: only when connected to ac.
scanning always available: off
Wifioptimization: on
auto ip: off
passpoint: off
I also have BT headphones and no problems with interference whatsoever.