Obsolete
Status Update
No update yet.
Comments
su...@twofortyfouram.com
Have this issue and modifying the cfg file solved issue.
en...@google.com
kr...@android.com
Best way to identify this issue will be to stream music on Radio Apps like TuneIn or Pandora where the music cuts out exactly at sleep time.
Example : Display Sleep time set to Lock time to 30 sec and then Display Sleep time to 1 mins, the Wifi breaks at 1 mins.
This has something to do with the Sleep time.
Also, as long as the phone is unlocked or in use, the wi fi doesn't break.
Nexus 4 with 4.2.1.
Thanks
Avik
Example : Display Sleep time set to Lock time to 30 sec and then Display Sleep time to 1 mins, the Wifi breaks at 1 mins.
This has something to do with the Sleep time.
Also, as long as the phone is unlocked or in use, the wi fi doesn't break.
Nexus 4 with 4.2.1.
Thanks
Avik
su...@twofortyfouram.com
@2 It sounds as if you simply have set your wifi to turn off when the screen turns off. Have you checked your settings in "advanced wifi settings"? The ARP issue is does not manifest itself simply by turning your screen off. Streaming would certainly just continue even with the issue present when you lock your device.
kr...@android.com
Hello,
Thanks for your insights. But this is not the case.
The setting says keep the Wi Fi alive.
The way I see it, the code never receives the instruction to keep the Wifi alive even when the display goes to sleep.
The streaming is interrupted because the Wi Fi drops and starts again. This indicates there is a problem with the code. Changing Router settings is not an option.
I can tweak the phone codes myself but then I want Google to wake up.
It is a pure mismatch of understanding user requirement and finalizing technical specifications. It happens all the time in softwares.
The end users want Wi Fi to be alive even when the Display is on Sleep.
But in 4.2.1, the Sleep setting puts the Wi Fi on sleep too.
You will not observe this problem if you keep the phone awake. The Wi Fi works flawlessly.
I believe it can be fixed.
So far, there are 5 friends of mine who have taken the N4 and all of them have the same problem.
Thanks for your insights. But this is not the case.
The setting says keep the Wi Fi alive.
The way I see it, the code never receives the instruction to keep the Wifi alive even when the display goes to sleep.
The streaming is interrupted because the Wi Fi drops and starts again. This indicates there is a problem with the code. Changing Router settings is not an option.
I can tweak the phone codes myself but then I want Google to wake up.
It is a pure mismatch of understanding user requirement and finalizing technical specifications. It happens all the time in softwares.
The end users want Wi Fi to be alive even when the Display is on Sleep.
But in 4.2.1, the Sleep setting puts the Wi Fi on sleep too.
You will not observe this problem if you keep the phone awake. The Wi Fi works flawlessly.
I believe it can be fixed.
So far, there are 5 friends of mine who have taken the N4 and all of them have the same problem.
le...@googlemail.com
@4 Thanks for explanation. From your own words, I still see what you're seeing as an entirely different issue. Even with the issue being discussed in the bug report here, the device maintains an active connection with the router at some level, whereas with you, it seems that the entire connection (read: all ports and communication with the router) becomes inactive when you turn the screen off. Almost sounds like a hardware issue of some sort rather than the device not responding to broadcast/multicast requests.
In any case, back to the topic, I can confirm this issue. The fix presented in the OP restores broadcast responses from the device. However, it can be noted that reserving a static IP at the router negates the need for requests and replies as far GMail services go, so I have chosen to keep the wifi INI at its default values, allowing Gmail to operate as it should (receving emails instantly). But, I still run the risk of various other services not working as expected in the future if the device cannot respond accordingly to broadcast/multicast requests.
In any case, back to the topic, I can confirm this issue. The fix presented in the OP restores broadcast responses from the device. However, it can be noted that reserving a static IP at the router negates the need for requests and replies as far GMail services go, so I have chosen to keep the wifi INI at its default values, allowing Gmail to operate as it should (receving emails instantly). But, I still run the risk of various other services not working as expected in the future if the device cannot respond accordingly to broadcast/multicast requests.
nu...@gmail.com
Hey, this is being fixed in the Qualcomm driver to support ARP offload when filtering broadcast packets
ma...@gmail.com
Thanks, I thought as much as I've been following 40065
Cheers :)
Cheers :)
lu...@gmail.com
same issue here. Wifi fails to respond when the device sleep. please provide a solution for same.
ak...@gmail.com
Also these are the issue I got:
1. Wifi worked fine at home, whereas the same didnt work at my office network. I had HTC Desire S previously and didnt face any problem both at Office and home.
1. Wifi worked fine at home, whereas the same didnt work at my office network. I had HTC Desire S previously and didnt face any problem both at Office and home.
st...@gmail.com
I have this issue, so says isher in 40065, I can't modify that config file I presume because I am not rooted. What are my options, would buying a new router help? Is there a whitelist of good routers? It's there an eta on Qualcomm fix and can it be delivered ota?
Thanks. I do not want to root my phone, that is not an option for me.
Thanks. I do not want to root my phone, that is not an option for me.
ha...@gmail.com
A current workaround for this is to add a static ARP entry on your router (if it supports it). Unfortunately, No ETA yet on the qualcomm fix but it will go out at some point.
zh...@gmail.com
@isher - I was able to add a static ARP in my dd-wrt router. After router reboot, I set the phone down for an hour. When I pick it up after the hour the problem is back. Both the wifi and cell bars are full and blue but there is no internet, the emails I can see on my computer are not received on the nexus 4 and chrome will not load a web page. Do I belong back on 40065 and what other advice can you offer?
Startup command for reference: arp -i br0 -s 192.168.1.254 FF:FF:FF:FF:FF:FF
Startup command for reference: arp -i br0 -s 192.168.1.254 FF:FF:FF:FF:FF:FF
ol...@gmail.com
More information - I reproduced this on a second Nexus 4, the first runs 4.2.1 the second one runs 4.2. Once the problem starts toggling airplane mode will not fix it. Turning off WiFi forcing cellular data does fix it. Turn wifo back on, you get blue wifi bars but still no internet.
[Deleted User] <[Deleted User]>
@tantdy, I suspect that your problem is not related to this issue of ARP broadcast requests, as the symptoms of your problem are not consistent with what others report, nor with my experiences. Could be an entirely different bug or a finicky wifi connection, an over taxed router, TCP timeouts, or any variety of bugs.
But, instead of setting a static ARP using a command, why don't you just reserve a static IP address on your router? In so doing, it appears that a static ARP is also created and it has allowed me to sidestep the problem a dd-wrt router.
But, instead of setting a static ARP using a command, why don't you just reserve a static IP address on your router? In so doing, it appears that a static ARP is also created and it has allowed me to sidestep the problem a dd-wrt router.
[Deleted User] <[Deleted User]>
@tantdyalf, appears you are not hit by ARP, can you let know what your current WMM & APSD settings on thte router are ?
You could try changing these to see if it makes a difference
You could try changing these to see if it makes a difference
sk...@gmail.com
Thank @rsry, I added a static IP, won't be home long enough to test for a while but will get back to you if that works.
@isher -
Wireless Multimedia Support Settings -
WMM Support Enable (Default: Enable)
No-Acknowledgement Disable (Default: Disable)
(Both are on default, which do you suggest changing)
ASPD:
Can't find this setting, also mostly striking out searching for it on internet with respect to dd-wrt routers, looks like it is associated with WMM, but its not listed under Wireless > Advanced Settings.
I did change last night to WEP2 / AES by the way, that doesn't seem to have changed behavior at all. I look forward to your next suggestion.
@isher -
Wireless Multimedia Support Settings -
WMM Support Enable (Default: Enable)
No-Acknowledgement Disable (Default: Disable)
(Both are on default, which do you suggest changing)
ASPD:
Can't find this setting, also mostly striking out searching for it on internet with respect to dd-wrt routers, looks like it is associated with WMM, but its not listed under Wireless > Advanced Settings.
I did change last night to WEP2 / AES by the way, that doesn't seem to have changed behavior at all. I look forward to your next suggestion.
he...@gmail.com
APSD is automatic power save. You can probably find a setting called power save may be.
[Deleted User] <[Deleted User]>
Also, You could try disabling WMM to see if it helps
ax...@gmail.com
Some routers support "proxy arp" where the router will answer ARPs on behalf of the phone. This may provide a router-based solution util the patch goes live. Of course this won't help when you;re not home but trying to use a hostspot you can't control.
So maybe the best solution is still to use the patches provided on xda-dev, still not sure about battery impact since the phone will now process every broadcast and multicast, so it could be a lot more processing in busy environments (university, coffee shop....)
isher, how do you/Qualcomm intend to deal with high broadcast/multicast traffic? are we going to see poor battery life when Wi-Fi is on, or does the Qualcom offer MAC/chip level filtering that will not wake the entire phone?
So maybe the best solution is still to use the patches provided on xda-dev, still not sure about battery impact since the phone will now process every broadcast and multicast, so it could be a lot more processing in busy environments (university, coffee shop....)
isher, how do you/Qualcomm intend to deal with high broadcast/multicast traffic? are we going to see poor battery life when Wi-Fi is on, or does the Qualcom offer MAC/chip level filtering that will not wake the entire phone?
[Deleted User] <[Deleted User]>
@19 isher said Qualcomm are releasing a driver which will support ARP offload, offload I assume means on the WLAN chip so there should be no/immeasurable battery impact.
dd...@gmail.com
Actually since oyu mention ARP offload, it implies it would be handled on-chip, not wake up the phone, so sounds like the right fix.
sa...@google.com
ARP offload will allow the WLAN chip to respond to ARP requests without waking the host up
Description
Changing the component enabled state of any component will break running background services.
STEPS TO REPRODUCE
1. Create an app with an Android Manifest registered BroadcastReceiver and a foreground service (e.g. it calls startForeground() to display an ongoing notification)
2. Start the service and verify the notification icon appears
3. Programmatically set the BroadcastReceiver's state to be enabled or disabled (this will move the receiver's component state from DEFAULT to either ENABLED or DISABLED), like the following getPackageManager().setComponentEnabledSetting(new ComponentName(getApplicationContext(), TestReceiver.class), PackageManager.COMPONENT_ENABLED_STATE_ENABLED, PackageManager.DONT_KILL_APP);
4. Watch the service's notification icon
RESULTS
Actual: The service's ongoing notification icon disappears shortly after the BroadcastReceiver's component state is changed
Expected: The notification icon should not disappear
REGRESSION
This bug reproduces in the SDK 14 emulator. This bug does not reproduce on the SDK 10 emulator or on an SDK 12 device.
NOTES
This bug reproduces if any component--BroadcastReceiver, Service, etc.--enabled state is changed. This bug does not occur if no state change occurs (e.g. if a component is already ENABLED, then setting ENABLED again will not cause the bug to reproduce).