yashsingh1/xdaforums huggingface dataset:
[Nexus 4 General] Strider Nemesis:
I've been running 4.4 from the OTA, and I can say that the pinging issue is most certainly resolved, even with Wi-Fi optimization enabled. The first ping request will take a while (1-2 seconds) or just time out as if it's "waking" the device up, but the following ones will be successful in the order of a few tens to hundreds of milliseconds.

Some of you may be experiencing other issues that are delaying your notifications, like the one PNF fixes (low "heartbeat" frequency). When I was experiencing the "pinging" issue, PNF made no difference at all with my router, though. Now that this issue is gone, PNF should be able to make a difference in Nexus 4 devices.
[Nexus 4 General] Fatherboard:
I don't know if it's the device's fault or kitkat, but everytime i try to tether a device (via wifi) to my n4, it takes it a minute or two to connect.
[Nexus 4 General] genevois26:
[MENTION=584916]ziddey[/MENTION]

4.4.1 has the new drivers?

Thanks!
[Nexus 4 General] amir_psp:
sorry to make this up after Months...

but I'm really gana get crazy with push notifications delay especially in line and viber, I've tested lots of roms and kernels which 4.4.2 stock flashed with toolkit was included, but it didn't make any sense :( I still get my messages in viber, line and others when I turn the display on :(

I should notice that changing the McastBcastFilter to 0 answered but the battery drained like Ferrari 550 acceleration :'( i mean 5% by half an hour with the display off
[Nexus 4 General] Dynamole:
I still have this problem with 4.4.2. Damn, any solutions?! :'(
[Nexus 4 General] Blockberd:
[MENTION=3501473]amir_psp[/MENTION] and [MENTION=4855224]Dynamole[/MENTION]:

Try changing said values in ini file back to 3 and disable wifi optimization.
[Nexus 4 General] rancatoco:
There is any kernel with prima drivers to KitKat?

Enviado de meu Nexus 4 usando Tapatalk
[Nexus 4 General] rancatoco:
????????????????????
[Nexus 4 General] xda_emanuel:
You can try ak kernel, but the oldest prima drivers doesnt help much with wifi drops in deep sleep.
[Nexus 4 General] rancatoco:
Ok, thanks. I really bored with this issue. Push notification fixer don't work for me since KitKat. The only solution was the motley kernel in jelly bean, but to KitKat, nothing fix this issue. My notifications always suffer delays. I change my router with hope but not working too.

Enviado de meu Nexus 4 usando Tapatalk
[Nexus 4 General] droverto:
Try this:

Go to:

/system/etc/wifi/

Edit this archive with the text editor you want:

WCNSS_qcom_cfg.ini

Seek the line:

gEnableBmps=1

and change to:

gEnableEBmps=0

Save and exit.

This works for me, before I was stuck like you, but I've forgotten that problem,

no matter what Rom or Kernel put, always works.

My other problem is the speed with wifi connections, is not stable,

low after a few minutes. I have to disconnect-connect and it works well
[Nexus 4 General] bmt25:
Im having delay connecting to wifi even though im beside the wifi router
[Nexus 4 General] rancatoco:
Thanks bro but, don't work for me. I very bored with this stupid issue.

Nexus 5 have this same issue?

Enviado de meu Nexus 4 usando Tapatalk
[Nexus 4 General] brsclkr:
it looks work for me on 4.4.3, does this change affect battery life badly?
[Nexus 4 General] droverto:
I have found that it does affect the battery life, you decide now: more battery or better notifications...
[Nexus 4 General] xda_emanuel:
With that setting your phone will not going in deep sleep anymore

Inviato dal mio Nexus 4 utilizzando Tapatalk
[Nexus 4 General] bipinbaglung:
Is mac changing with "su busybox ifconfig wlan0 hw ether xx:xx:xx:xx:xx:xx" affected by this setting

gEnableMacAddrSpoof=2
[Nexus 4 General] biffsmash:
Very true. I guess it's just annoying to have stuff like this crop up and having to put settings in routers is difficult considering I can't touch the router settings at work or at friends houses.

Newest CM10 roms have fixed this issue some how, at least I didnt have the problem occur once on latest CM10 so it must be fixable.

Cheers.
[Nexus 4 General] floepie:
So they made CM10 to allow your device to respond to pings? Have you tested this? I kind of doubt it, but you never know.

---------- Post added at 04:23 PM ---------- Previous post was at 04:09 PM ----------

Thanks for the reply. I guess I was previously driving at how and why ARP timers can be set so short, while on some routers, setting a reserved IP address can set a static ARP entry apparently. You mention that your own router, while its default ARP timeouts are very short presenting connectivity issues, can be set to issue a static IP address and in so doing apparently also creates a static ARP entry allowing you to bypass the Nexus 4's default deficiency.

It seems as if the design of these linux-based systems is so inefficient as to rely on these short ARP timeouts by creating seemingly unnecessary overhead. You mention that the DHCP server has no communication or shares resources with the ARP table. It seems to me that ARP entries can (and should?) be maintained until a new device with a new MAC address comes along and requests an IP address. It seems that these two protocols overlap to a certain extent, that is, both are involved with binding a physical address to a link layer address (IP). Or, am I not seeing things the way they really are?
[Nexus 4 General] bganley:
If a router automatically creates a static ARP entry based on a static DHCP reservation, then this is a feature that was intentionally added. I am currently running a version of Tomato on my router and it does not do this automatically. Instead, it has a checkbox next to each DHCP reservation that if checked will also create a static ARP entry. This was implemented for security reasons though (http://tomatousb.org/forum/t-323624).

The problem here isn't the short ARP timers, the problem is the phone not answering ARP requests while the screen is off. Linux isn't alone in having short timers by default. There are advantages to this such as keeping the cache fresh. For example, think about what would happen if you had a long ARP timeout on your router and the MAC address of a device with a static IP changed.

DHCP and ARP are two completely independent protocols. In most cases, DHCP isn't even running on the router (this is mainly found in home networks) so there wouldn't be any way for them to tie into each other. I don't see any benefit to the added complexity of trying to tie them together anyways as a few devices on a home network aren't going to generate enough ARP overhead to make any kind of difference. BTW, you can set the ARP timers to whatever you like on Linux.
[Nexus 4 General] Stryder5:
Making the change manually by following the OP's instructions worked perfectly on Paranoid Android. I can finally use Airdroid when phone is sleeping again. Thank you so much!
[Nexus 4 General] zitstif:
The mentioned mod works wonderfully on my Nexus 4! I am able to ping my phone while it is idle with practically no issues.

However, one issue I've noticed is that sshdroidpro when the phone is idle is listening and according to netcat the port is open but there are long delays. Is there a TCP idle setting that is conflicting with this? It's really annoying because I want to ssh into my phone when it is idle, and I can but there are long delays between each process (Connecting, authenticating, and then running commands at the terminal). If I turn my screen on I have no delay and no issues connecting to the service whatsoever.

If you need any additional information please let me know and I appreciate the effort you guys have put into resolving this issue.
[Nexus 4 General] iammudd:
Actually, if I recall correctly, the arp cache should be updated whenever the client (with the static IP) issues an arp request. So static IPs are fine. It's static ARPs that present problems. If the MAC was wrong or if the client station dies, then that IP would be locked out. If the IP was wrong, some other unsuspecting client could be locked out.

You've already mentioned that if the DHCP server was not on the same LAN segment, the server would not need to have an arp entry at all but it would be the DHCP helper / router that needs it. Another point worthy of note is that a static arp entry on the router will only allow traffic to flow from the "outside". Devices on the "inside" would also need static arp entries (say, for streaming or FTP).

Thx for your zip, modifying WCNSS_qcom_cfg.ini works for me... but at first glance my N4 appears to be awake 2x as often (at 8.9%). So I will revert the changes and re-test with static arp tonight to determine the effect of broadcasts destined for other devices on the network.
[Nexus 4 General] bganley:
Depends on implementation. I've seen cases where it does not get updated from an ARP request. Clearing the ARP cache or waiting for the now incorrect entry to expire restores connectivity.

That's correct. On an Ethernet network, any time a device wants to send a packet to another device on the same network segment (and only that device), it will need to know the MAC address of the device it is sending the packet to. This is needed because devices on an Ethernet network are addressed via MAC address.

Glad to hear it worked for you. I had a higher level of battery drain as well accompanied by a lot more hsic wakelocks. At one point I tried running Franco's kernel along with this patch and it made a pretty big difference. Static ARP will definitely help with the battery but of course the negative is you have to add a static ARP to every adjacent device you wish to speak to.
[Nexus 4 General] bganley:
I've never run sshdroidpro but I would fully expect there to be delays while the screen is off unless the app is keeping the phone awake. I just looked up the app in the market and found the following in the description....

FAQs:
q: Why my transfer speed decrease when I turn off the screen?
a: Enable the option 'Lock Wifi'. If your device is running at least
Android 2.3.x, you should get full speed transfer even when the
screen is off, otherwise enable the option 'Lock screen' too.
[Nexus 4 General] zitstif:
I have this option enabled but it doesn't make a difference.. :confused::eek:
[Nexus 4 General] Stryder5:
Did you try rebooting?
[Nexus 4 General] zitstif:
I sure have tried rebooting. I have tried different kernels as well. I am currently using the motley_anykernel_nexus_4_build_57. (I'm also running the android os 4.2.1)

I even had a coworker with his samsung s3 install sshdroid and let his phone go idle on our wireless network and I was able to connect to it with no lag issues.

This has to be a driver/os issue.
[Nexus 4 General] defnz:
Try turn off wifi optimisation too, see if that makes a difference?
[Nexus 4 General] mobilehavoc:
Use stock kernel. Most custom kernels use a different wifi driver that doesn't work as well. I get best resulted with this modification combined with stock kernel.
[Nexus 4 General] crunde85:
'N-Only Mode' - DDWRT

Good news fellas. If any of you have custom firmware on your router (maybe even people with stock F/W) like DD-WRT goto Wireless -> Basic Settings -> Change your physical interface to 'Mixed' mine was set to 'N-Only' which is still on a 2.4GHz frequency, and all my other devices don't mind it, except the Nexus 7. I attached a picture.
[Nexus 4 General] floepie:
Cool, but what does this have to do with the connectivity issue as discussed in this topic?
[Nexus 4 General] crunde85:
I just wanted to share this fix... I spent days looking for a solutiuon. Tried static IPs, DNS, Rebooting router, messing with Nexus settings..

If there are as many people out there as I suspect with no WiFi after 4.2 OTA upgrade then I figured this would be appreciated.
[Nexus 4 General] danielvc:
But that's not the topic here. But thanks anyways.
[Nexus 4 General] zitstif:
For me it doesn't make a difference if I'm using a stock or custom kernel, I get the same results.

I have also done this and it makes no difference. :eek:
[Nexus 4 General] iammudd:
Some crude STANDBY testing results (on Faux kernel 04 beta 6 and PA 2.99 11JAN):

Broadcast Allowed vs Static Arp on router

Broadcast On Battery Awake Battery%
Allowed 5h59 32 mins ( 8.9%) -4%
Disallowed 3h33 2 mins ( 0.9%) ~0
Disallowed 7h31 3 mins ( 0.7%) ~0
Allowed 5h50 36 mins (10.3%) -5%

~8 to 9% difference in awake times or 4% battery drop. So it's probably worthwhile to filter broadcasts / multicast with the aid of static arp entries if that is a viable option for people concerned with battery drain.

Edit: (Obviously, YMMV depending on the number of devices and traffic pattern on your network.)

The zip makes it easy enough to re-allow bcast when required but for those who prefer to leave bcast on:

(Despite not being a fan of static arps...) a compromise would be to enable static arps on/for most/all devices behind the router to minimize the amount of bcast traffic (not targeted at the N4).
[Nexus 4 General] mobilehavoc:
The bigger issue isn't my home wifi I already found a way to get my device to work without enabling broadcasts using ddwrt. The problem is the almost infinite number of hotspots I can't control that I might connect to. Hence why a fix on the phone for all situations with a battery sacrifice makes more sense than a fix for just one situation. :D
[Nexus 4 General] floepie:
How do you arrive at the conversion factor between awake times and % battery loss?
[Nexus 4 General] iammudd:
Yes, true...but when you are connected to a free hotspot, your phone will likely NOT be in deep sleep. For a several hour unattended situation (say, WiFi at work), it doesn't take that much effort/time to re-enable broadcasts.

---------- Post added at 07:12 AM ---------- Previous post was at 06:57 AM ----------

I didn't perform any conversions. They're simply the stats from BetterBatteryStats

BTW, awake is not necessarily equal to screen on time. It includes when the phone is awoken from deep sleep to process events. Screen on would consume more power.

Also, FYI, bganley's mod is still required with Faux kernel 004m.

Purely speculation... but I suspect that the broadcast filter issue was known to Android devs as a conscious choice to conserve battery. When they included options like "WiFi optimization" and "leave WiFi on during sleep", someone would have surely tested by pushing data to the N4. But while ignoring broadcasts, perhaps they forgot to switch from push mail to polling (before going to deep sleep). (Polling would have at least reset the arp cache timer. Perhaps their testers had polled exchange mail, etc running which hid the problem.)
[Nexus 4 General] floepie:
Well, I still don't see where bbs would report that 32 minutes of awake time, for instance, as you show on the first line of your data would result in a 4% battery loss. Unless, there is a setting I'm overlooking.

Yes, but even if polling were to reset the arp cache timer at the router, by definition, the arp timer would have to be shorter than 15 minutes in order for the GMail push feature problem to be present. Even if you have set your device to "push" setting instead of regular polling, the device restores the port 5228 connection every 15 minutes in order to retrieve mail. And, after a few minutes, presumably this arp cache is cleared, preventing any pushed messages getting to your device. So, I don't see how polling would be any better than just letting your device retrieve its mails every 15 minutes.
[Nexus 4 General] iammudd:
In BBS, choose "OTHER". It will show battery loss as a % (edit: since unplugged for example) and awake time.

The arp timer on your router? Yes, sadly, the timers are incredibly short. On mine, it's prob no more than 2 mins.So even having the N4 poll mail at 5 mins isn't enough to keep it active in the arp cache.

I'm not familiar with how Google push mail is actually implemented... but if it is simply a case of having an open TCP session with Google servers, then that won't necessarily refresh arp caches. Perhaps my memory is failing me but TCP connections can remain open indefinitely (if desired) without having any traffic for a long time (certainly longer than 2 minutes). (Otherwise, there'd be no need for explicit TCP keep-alives.)

At the very least, the N4 needs to wake and send something. Even then, most routers won't necessarily maintain the arp entry based on traffic alone. An arp request/reply is normally required. (That is another example of where you DON'T want long or static arp entries. You actually want the N4 to arp.)

Sorry, perhaps I missed your point...but that was the original reason for the bcast mod or static arp, Without these workarounds, the N4 doesn't send anything to Google servers and unsolicited data from the servers can't reach the N4.

If the N4 was connected with bcast enabled to a large WiFi network with many other devices, I suspect that the N4 will be awake most of the time (due to the very short arp timeout of PCs, etc.) With the power and functionality of smartphones, it's easy to forget that they start out as phones and phones aren't in a broadcast domain so I can understand why a dev would consider ignoring bcasts.

I only used polled email as an example of a potential workaround but I really wouldn't want to poll mail (or weather) that frequently. (It actually requires quite a bit of processing for session creation/tear-down ... especially if retries are required.) I suspect that a compromise solution would be to have the N4 issue gratuitous arps every minute or two. (No connection establishment. No waiting for ack's. So the device can resume deep-sleep quicker.)
[Nexus 4 General] floepie:
Oh, you are referring to total % battery loss. "OTHER" only reports total battery loss, and I was under the assumption that you were attributing the % loss to a specific wakelock. Even still, on the third line of your table you show over 7 hours of standby with no battery loss, despite 2-3 minutes of awake time? Surely your wifi radio had been turned on which would have consumed more power than that?

The TCP connection with Google's servers renews itself after 15 minutes, even if a static arp has been established. That, according to my router logs at least. It always goes over TCP 5228. And, along with that there is a port 443 connection that's maintained and marked ESTABLISHED as well.

OK, I thought you were making the argument that Google should have at least ensured that polling would have been used as a fallback mechanism in the case of short arp timeouts. But, even in the absence of broadcast replies (no static arp entries or no wifi "fixes"), the device seems to wake itself and reconnect over port 5228, and once established, one receives email. This is presumably why, before I had created a static IP (and arp entry) at the router, I had never (or rarely) received email later than 15 minutes after they were received at Google. Perhaps it can be considered "polling" after all if the net result is the same.
[Nexus 4 General] iammudd:
I should mention that I have gTalk frozen.

(Since it was 4% for 30 mins awake, then 3 mins awake should be ~0.4% ... so I'm not totally surprised by a 0% being displayed.)

With gTalk frozen, I wasn't expecting any sustained connections to be maintained with Google servers so I never bothered to look. All I noticed was that the arp entry for the N4 was either incomplete or non-existent for >20 mins. Only when I enabled an IMAP client, did I see a complete arp entry for the N4. But as I said, any polling solution is not really viable. It's not lightweight and most of the time unsolicited connection requests would still receive "dest unreachable".
[Nexus 4 General] bganley:
This would imply that all android devices ignore broadcasts/multicasts while in deep sleep. I have a Galaxy Nexus and N7 running 4.2.1 which both always responds to ARP requests no matter how long the screen is off. Intentionally filtering broadcast traffic would also break Google's Cloud to Device Messaging (push notifications) which I would hope they wouldn't knowingly do. Of course, this is only a problem in environments with shorter ARP timers.

Responding to the followup's of your post, TCP connections can stay up indefinitely but a problem comes in when you have a stateful firewall in the path. Modern firewalls track all connections through them and automatically allow the return traffic from the untrusted interface for current valid connections. This connection tracking applies timers to everything being tracked. If a timer expires without seeing any traffic for that connection, the firewall will time out that connection and no longer allow the return traffic. In the case of push notifications, that means the notification coming from Google will get stopped at the firewall.

The way around this is to send keepalive's. In the case of Google's Cloud to Device Messaging, it appears that google uses a keepalive timer of 15 minutes. This means that every 15 minutes, the phone will send a packet to Google which will refresh the state of the connection in the firewall thus keeping the connection open. If the connection had timed out during those 15 minutes, it will open a new connection which is why you never see notifications taking more than 15 minutes to show up.

The TCP Established timer is the timer that applies here and would need to be set to greater than 15 minutes for the connection to remain alive with keepalives.

Hopefully that helps explain things.
[Nexus 4 General] zitstif:
I have noticed with my nexus 4 that even though the wifi connection setting states 'always on', when I have my phone connected to the outlet and idle, that I have no connection issues connecting to ssh on my nx4. However, on the battery and idle, connection issues persist.
[Nexus 4 General] mobilehavoc:
That's because android doesn't let the phone sleep while charging so even though the screen is off the phone is awake. This is expected behavior with all Android phones.
[Nexus 4 General] zdenoh1975:
Hi, I dont understand one thing:

In this thread are

few

people who have problem that our phone not responding to ARP requests when the screen is off...

And what about many others Nexus4 users? This is only issue a few pieces of phone N4 (ours), and other are OK? Because the vast majority of Nexus users dont have any issues with wifi connectivity described in this thread and this isnt issue of Nexus4 whole community ... Why few has this wifi issue, and many others not? ?softwares of phones must be the same! - cant be a differences in wifi behavior. (few users eg on stock ROM have this issue and many on the same ROM not; this fix help someone, someone not...)

therefore begins to have suspicions whether it is not a hardware issue of router, or something similar... I dont known, but I'm frustrated of this...
[Nexus 4 General] iammudd:
My most recent standby results are below. I would be curious to see what the awake % are for Gnex and N7 as a comparison... because it looks like one would be better off (battery-wise) using 3G while on standby.

(Mind you, on my home network, I see Dropbox polling every few seconds and an old NDAS device polling every second... On the other hand, it's prob not unrealistic to see a bcast every second on a public network either.)

Broadcast On Battery Awake Battery% (Total Drop)
Disallowed 7h50 3 mins ( 0.6%) ~0
3G 7h56 7 mins ( 1.5%) ~1%
--- previously (with the prev version of kernel)
Allowed 5h59 32 mins ( 8.9%) -4%
Allowed 5h50 36 mins (10.3%) -5%
[Nexus 4 General] floepie:
How the heck are you getting such low awake times? What did you do to quell that MSM_HSIC_HOST wakelock? Even my "Radio-interface" wakelock would be greater than your total awake times.