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
Using a Nexus 6 with NP5.
I frequently walk in and out of Wi-Fi range near my home. The Wi-Fi signal gets weak, and data communications start to suck. If I turn off Wi-Fi the phone switches to LTE and everything is fine.
There is an option in Developer options labeled "Aggressive Wi-Fi to Cellular handover." If I enable this option my data connection remains stable because as the Wi-Fi gets weak the phone switches to LTE sooner.
The difficulty is that this setting reverts to "Off" every time the phone reboots.
I have recently started using Tasker and have another task that runs a shell command on boot. That task is working great.
I am trying now to figure out how to change this setting for aggressive cell handover in dev options using a tasker task that I can assign to the same Device Boot event and I am running into difficulty. I simply do not see how to flip this device setting toggle within a tasker task.
Am I missing something? This seems like it would be a simple thing to do, straightforward, and the type of thing Tasker is designed for, but my noob-ness is showing.
I go to Tasks, add a task, name it, add an action, select Settings, but I don't see anything matching "Developer options." If I go to "All Settings" i just get a prompt to enter a variable name. I have no idea what to type to select the variable represented by the "Aggressive Wi-Fi to Cellular handover" toggle option, or if its range is 0/1, true/false, whatever.
Any guidance would be greatly appreciated.
Thanks!
No suggestions? Not possible? Wrong tool?
rgraville said:
No suggestions? Not possible? Wrong tool?
Click to expand...
Click to collapse
on s7 its a built in feature to switch to mobile data when a wifi network is unstable
Hi. I have made a location based profile that uses my location to to switch on do not disturb on my OnePlus 3t but want to switch it to cell near as it is supposedly uses less battery. The profile works but it seems like the cell tower it uses isn't strong enough. Is there a way of adding a second cell if the scanning shows one or do I need to scan for longer moving about so more is picked up?
From the Tasker User guide - location without tears:
Create a*state context, select*Phone*then*Cell Near. Click Update and walk around a bit to scan for cell towers nearby.
About
Uses information about the cell towers the phone uses for telephony to record and match a location.
When the display is off, frequency of checks is controlled by*Prefs / Monitor / Display Off All Checks.
If your profile keeps deactivating, go back to the Cell Near state and click the magnifying glass icon to check for cells you may have missed in your scan.
Click to expand...
Click to collapse
That is what I have done but the profile switches off all the time. It seems like the tower my phone detect isn't the right one. Tried two different scans with the same result. (The scans identifies different signals but neither seems to be able to run the profile)
Eggstones said:
That is what I have done but the profile switches off all the time. It seems like the tower my phone detect isn't the right one. Tried two different scans with the same result. (The scans identifies different signals but neither seems to be able to run the profile)
Click to expand...
Click to collapse
Did you do the second part, involving the magnifying glass? If you're bouncing off different towers while moving throughout your home, all of the towers will need to be selected.
ktmom said:
Did you do the second part, involving the magnifying glass? If you're bouncing off different towers while moving throughout your home, all of the towers will need to be selected.
Click to expand...
Click to collapse
Sorry I missed that. I'll try that and see what happens.
The profile also seems to deactivate when the screen goes off but not 100% about that
It seems to have sorted it!
Every time it stops working in have to add a new cell tower but that's fine as it works!!!
Have about ten now for this work based profile.
Is anyone able to access the global wfc_ims_mode in the Pixel 4 or any later versions of android than 9? Here is the method I am referring to.
I need to know this because I am currently using an OG pixel and I manually set the Wifi Calling to Wifi Preferred as we know the toggle button verizon offers inside settings is a dud.
Without forcing the global wfc_ims_mode to 2, my phone is essentially a paperweight as all data and more importantly calls and text will always default to cellular which I have 0-0.5 bars of service at my home.
Thanks!
Deeper explanation and rant - cynicism and blame incoming.
A quick summary of Wifi Calling Preferred - There is Wifi Calling, yes I know, that toggle works and is on. Then there is Wifi Preferred, a separate setting that tells the phone it what connection to default to. This is a toggle that was inside of the the Wifi Calling settings that has been confirmed to do absolutely nothing regarding your phones affinity for wifi or celluar. It is not tied to anything on the side of the android ROM, it is just there to create the illusion that it works. It was supposed to allow people to force the phone you have to use the wifi connection over the mobile connection which really help people on the edge of a service area or, in my case, in .5 miles from a Cal State University with a partially obstructed view of a cell tower.
"But I see "Wifi calling" in the top of my phone sometimes and I have never had problems."
1. Yes, Verizon does allow calls to sometimes initiate through wifi and even stay on wifi for several minutes. However, Verizon has set conditions on what a "good connection" means in order to keep wifi routing of calls AND data to an absolute minimum regardless of how this effects the end users call and data quality. Simply put, if we rate our wifi and cell connections from 1-20 with 20 being spectacular and 1 being awful; Verizon has effectively written boundary rules that say a cellular signal rating of 1 is ALWAYS preferred over wifi signal 20. You could be standing next to a brand new gigabit router with google fiber and full signal, but if Verizon thinks it has .005 % of a bar, then guess what? No call! However, Verizon knows that it must initiate the call with good quality so they use the "wifi calling" (comes up on the top of the screen) to start the call, but as soon as the call has begun, and the phone has detected a signal of 1 on the cellular it will perform a hand-off to the cellular network. Icing on the cake?This is a mono-directional hand-off, meaning wifi MUST handover to the cellular but going from cell to wifi requires the phone disconnecting the call. Outstanding move Verizon!
2. I have 0-1 bars of service where I am so if you have more than that you wont notice the hand-off. I run my business through my phone and I was so tired of missed calls, missed texts, dropped calls, garbled sound, echo. Most people will see the "wifi calling" icon in the top of the phone and assume the entire call took place over wifi. Not the case at all. Just trying to avoid the "I have wifi calling on and everything is fine for me". Yeah, how long do you talk on the phone? How many calls are you getting? How sure are you after reading what I just wrote that the entire call, and every call that takes place in your house just simply because you are home and connected to wifi and one time saw wifi calling on the top is actually using wifi maintaining the call through your ISP??
To get around this, here is a method that I still use on my original pixle XL. I am still running android 9 as the move to 10 seems to have move the wfc_ims_mode select.
This is one of the main reasons I still use this phone. Without Wifi Calling being forced as "Preferred", I know everything will route through Verizons service which is virtually 0 where I am. This results in missed calls, dropped calls, and video qualities jumping around between 144p and 360p.
Would like to know also.
i have tried this method on my Pixel 3 android 10 stock and it didnt work.
Hi there,
I'm looking to create a profile that will trigger every time I'm having my weekly train commute and will compile different useful tasks for train riding like launching the Wi-Fi hotspot (so I can go online on my laptop) and mute the ringer, and some other stuff. I'm looking for some aid about about how to manage this through.
I thought about triggered this profile by using the speed data, but in that case it will launch on every ride I have, even when I'm riding my motorbike. So now I'm looking for something more sophisticated. Because I depart and arrive on regular stations and on regular times each week I want to have four new profiles - two for the the each of the two station I'm getting to and from of, for each commute occasion, setting one for the time window when I'm usually departure and one for arriving occasion. Those four will be used only as a platform. The train ride profile (a fifth one) will triggered by both of the departure profiles when I'll get to the station at the desired time and will turned off by the arriving stations profiles when I'll reach my destination station at the right time.
Doe's it make any sense? How can I pull this through?
Try WiFi near if the stations have a specific WiFi. That way, you don't need a time context.
You can use location with a time window you describe. That way, the device isn't trying to identify your location continuously outside of the time window you set.
ktmom said:
Try WiFi near if the stations have a specific WiFi. That way, you don't need a time context.
You can use location with a time window you describe. That way, the device isn't trying to identify your location continuously outside of the time window you set.
Click to expand...
Click to collapse
Thanks for the answer but you didn't got me. completely. I don't have a problem to detect the station location, the problem starts when the train leave the station and I want the profile to keep going on until I arrive at my destination station.
So use a speed evaluation combined with having the WiFi in proximity.
ktmom said:
So use a speed evaluation combined with having the WiFi in proximity.
Click to expand...
Click to collapse
It makes no sense, two reasons why:
1) When the train leave the station I'm loosing contact with any Wi-Fi
2) One of the reason I'm using Tasker to begin with is that I want my Wi-Fi to operate only when I'm in my home or in my workplace. The profile I want to operate on my train ride includes turning on my phone's hotspot (so I can use my laptop online during the ride). So I can't use any Wi-Fi network even if I want to.
3) I simply need to figure out a way how to trigger the "train ride" profile I want to have by other profile (station location profile in this case).
Yoghev
You can detect whether a WiFi network is nearby without connecting to it. You can use the WiFi's presence as the initial step to your process. Set a variable, them the exit task waits some time and a second profile looks for the variable to be set and some movement to be achieved.
Or not ¯\_(ツ)_/¯
You could always use a shortcut, or an NFC tag or location as I suggested before.
Create four profiles based on time and location.
One that's triggered at the train station A and in the average departure time of your commute to work.
Add an enter task which sets the variable $TrainStationCommute to A.
One that's triggered at the train station B and in the average arrive time of your commute to work.
Add an enter task which sets the variable $TrainStationCommute to B.
One that's triggered at the train station B and in the average departure time of your commute to home.
Add an enter task which sets the variable $TrainStationCommute to B.
One that's triggered at the train station A and in the average arrive time of your commute to home.
Add an enter task which sets the variable $TrainStationCommute to A.
Add another profile which is triggered as soon as variable $TrainStationCommute is set.
Add an new task "Commute" to this profile. Start with an IF action and check if variable $CommuteSettingsActive is not 1. Add your actions (enable hotspot, enable silent mode, etc.) to the IF loop and at the end, set the variable $CommuteSettingsActive to 1.
Add an IF ELSE action and check if variable $CommuteSettingsActive is not 0. Add your actions (disable hotspot, disable silent mode, etc.) to the IF ELSE loop and at the end, set the variable $CommuteSettingsActive to 0.
So every time the variable $TrainStationCommute is set, the task "Commute" will be executed. Based on variable $CommuteSettingsActive it will enable or disable your favorite settings.