battery usage #198

marix11 · Mar 11, 2016

3.5 hours the phone from full to 15%. 2 hours screen, 2 android system. Nexus 5x new. Seems like previuos build was better but i had it only 1 day before upgrading to 07/03

The Nexus 5X is known to have very bad battery life. It's not due to CopperheadOS. Battery life mostly has to do with your screen brightness and apps polling so it depends on which apps you use and your configured brightness. Tor and I2P are examples of very demanding applications since they're services that are always running and they keep the network active.

CopperheadOS features do add performance overhead but it only really impacts battery life under high load. If you're not running anything demanding in terms of CPU usage it won't really make a difference compared to stock. If you are, then it's still not going to drop battery life more than 5-10%.

thestinger · Mar 11, 2016

The Nexus 5X is known to have very bad battery life. It's not due to CopperheadOS. Battery life mostly has to do with your screen brightness and apps polling so it depends on which apps you use and your configured brightness. Tor and I2P are examples of very demanding applications since they're services that are always running and they keep the network active.

CopperheadOS features do add performance overhead but it only really impacts battery life under high load. If you're not running anything demanding in terms of CPU usage it won't really make a difference compared to stock. If you are, then it's still not going to drop battery life more than 5-10%.

Yes, me using tor. Also for cpu maybe openkeychain. But still 3 hour its weird. My old s4 under cm11 had 6 hours.
I have enabled all security toggles. Do they affect battery much?

marix11 · Mar 11, 2016

Yes, me using tor. Also for cpu maybe openkeychain. But still 3 hour its weird. My old s4 under cm11 had 6 hours.
I have enabled all security toggles. Do they affect battery much?

Page cache memory protection is the most expensive of those features followed by guard pages. They are opt-in because they're too expensive to be enabled by default. I wouldn't expect a large drop in battery life from them though.

thestinger · Mar 11, 2016

Page cache memory protection is the most expensive of those features followed by guard pages. They are opt-in because they're too expensive to be enabled by default. I wouldn't expect a large drop in battery life from them though.

I didnt want to open new topic. I have weid bahaviour of my device. Sometimes its laging for some hours, only reboot fixing it.
Last few days i was testing variuos security settings. I had 2 devices with fresh install identical. After 6 hours one is down to 97%, another to 50%. No activity on both just some identical apps. The one with 50% had androidOs awake all time.
Both are 5x

canary5 · Mar 22, 2016

I didnt want to open new topic. I have weid bahaviour of my device. Sometimes its laging for some hours, only reboot fixing it.
Last few days i was testing variuos security settings. I had 2 devices with fresh install identical. After 6 hours one is down to 97%, another to 50%. No activity on both just some identical apps. The one with 50% had androidOs awake all time.
Both are 5x

Logcat sent by email

canary5 · Mar 23, 2016

Logcat sent by email

I am seeing the same issue. Basically every time I charge the phone, and then disconnect, battery plummets (the battery screen may or may not show that the phone is "awake" but you see the battery plummettng really fast anyway, and the case of the phone gets hot). The only way to prevent this from happening is to literally power off the phone right after done charging, and then powering it back on. Otherwise, no such luck, the phone will kill itself in 6 hours.

Original poster is right.

Rudd-O · Apr 13, 2016

I am seeing the same issue. Basically every time I charge the phone, and then disconnect, battery plummets (the battery screen may or may not show that the phone is "awake" but you see the battery plummettng really fast anyway, and the case of the phone gets hot). The only way to prevent this from happening is to literally power off the phone right after done charging, and then powering it back on. Otherwise, no such luck, the phone will kill itself in 6 hours.

Original poster is right.

There's no indication that it's related to CopperheadOS rather than an Android / Nexus 5X issue. This isn't meant to be a tracker for all issues in Android and the hardware.

thestinger · Apr 13, 2016

There's no indication that it's related to CopperheadOS rather than an Android / Nexus 5X issue. This isn't meant to be a tracker for all issues in Android and the hardware.

I suspect it is CopperheadOS, because this does not happen with stock upstream Nexus 5X Android.

I have discovered that it isn't the act of charging the phone that makes the phone stay awake or warm. Sometimes after many hours of having excellent battery life, the phone just begins to burn CPU and burn through its battery. No installed app appears as a culprit in the battery life applet.

Is there an adb way to determine what is causing the issue? I would gladly collect more information.

Rudd-O · Apr 14, 2016

I suspect it is CopperheadOS, because this does not happen with stock upstream Nexus 5X Android.

I have discovered that it isn't the act of charging the phone that makes the phone stay awake or warm. Sometimes after many hours of having excellent battery life, the phone just begins to burn CPU and burn through its battery. No installed app appears as a culprit in the battery life applet.

Is there an adb way to determine what is causing the issue? I would gladly collect more information.

First, you need to be able to replicate the issue. Then, you could use adb logcat to check for errors or at least helpful information. Alternatively, perhaps there's a clear culprit in adb shell top. The output of adb shell dumpsys power could be helpful. If you can't reliably replicate the issue, it would be difficult to gather any useful information.

You would need to make a userdebug build to get more valuable information than those options, but that would really only be useful to follow up on a trail provided by those easier options. It's not possible to do much profiling or debugging on production builds, especially since CopperheadOS exec spawning is currently incompatible with one of the workflows for debugging apps.

Your inability to replicate it on another device / install doesn't mean much in terms of whether it's also present on stock. Most people aren't running into this issue on CopperheadOS, so it doesn't always happen. There are lots of issue reports like this upstream, so my assumption has to be that it's an upstream issue unless there's a good reason to think otherwise. Unless something is repeatedly crashing due to a memory corruption issue caught by a feature like OpenBSD malloc, there's little room for it being caused by CopperheadOS (and that would be extremely noisy in the logs). It doesn't do anything like adding services or changing anything related to hardware. It's really nearly the same thing as the raw Android Open Source Project.

thestinger · Apr 14, 2016

First, you need to be able to replicate the issue. Then, you could use adb logcat to check for errors or at least helpful information. Alternatively, perhaps there's a clear culprit in adb shell top. The output of adb shell dumpsys power could be helpful. If you can't reliably replicate the issue, it would be difficult to gather any useful information.

You would need to make a userdebug build to get more valuable information than those options, but that would really only be useful to follow up on a trail provided by those easier options. It's not possible to do much profiling or debugging on production builds, especially since CopperheadOS exec spawning is currently incompatible with one of the workflows for debugging apps.

Your inability to replicate it on another device / install doesn't mean much in terms of whether it's also present on stock. Most people aren't running into this issue on CopperheadOS, so it doesn't always happen. There are lots of issue reports like this upstream, so my assumption has to be that it's an upstream issue unless there's a good reason to think otherwise. Unless something is repeatedly crashing due to a memory corruption issue caught by a feature like OpenBSD malloc, there's little room for it being caused by CopperheadOS (and that would be extremely noisy in the logs). It doesn't do anything like adding services or changing anything related to hardware. It's really nearly the same thing as the raw Android Open Source Project.

I think its Cos issue as well, but 2016/04/06 build seems fixed it for me. Me even afraid to update, that build working very nice, except some system reboots;)

canary5 · Apr 15, 2016

I think its Cos issue as well, but 2016/04/06 build seems fixed it for me. Me even afraid to update, that build working very nice, except some system reboots;)

MHC19Q.2016.04.06.11.37.02 was the first build based on the new branch for the 5X, so the underlying code is a different AOSP codebase. In the previous month, we still used the main Marshmallow branch since they provided factory images for the 5X with the security updates only alongside the release from the new branch. So CopperheadOS was not the same AOSP as stock Android last month, but it is the same base again.

thestinger · Apr 15, 2016

MHC19Q.2016.04.06.11.37.02 was the first build based on the new branch for the 5X, so the underlying code is a different AOSP codebase. In the previous month, we still used the main Marshmallow branch since they provided factory images for the 5X with the security updates only alongside the release from the new branch. So CopperheadOS was not the same AOSP as stock Android last month, but it is the same base again.

Anything fixed or broken by MHC19Q.2016.04.06.11.37.02 was an upstream change, there were no CopperheadOS changes in that release.

thestinger · Apr 15, 2016

Anything fixed or broken by MHC19Q.2016.04.06.11.37.02 was an upstream change, there were no CopperheadOS changes in that release.

I have begun shutting off Wi-Fi when I am not in range of a Wi-Fi router
I want to use. This alone substantially improved battery life, and
stopped the phone from getting warm to the touch.

This is some baffling shit, for sure.

Rudd-O
http://rudd-o.com/

Rudd-O · Apr 18, 2016

I have begun shutting off Wi-Fi when I am not in range of a Wi-Fi router
I want to use. This alone substantially improved battery life, and
stopped the phone from getting warm to the touch.

This is some baffling shit, for sure.

Rudd-O
http://rudd-o.com/

Just to inform you, I have updated to 04/15 and again huge battery drain. And apps laging for example chronium. 04/06 was working perfect

canary5 · Apr 18, 2016

Just to inform you, I have updated to 04/15 and again huge battery drain. And apps laging for example chronium. 04/06 was working perfect

No changes beyond introducing the legacy permission toggle. It's not related to the version, and probably not CopperheadOS.

thestinger · Apr 18, 2016

No changes beyond introducing the legacy permission toggle. It's not related to the version, and probably not CopperheadOS.

On 04/18/2016 12:56 PM, Daniel Micay wrote:

No changes beyond introducing the legacy permission toggle. It's not
related to the version, and probably not CopperheadOS.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#198 (comment)

I am very sure that Wi-Fi is the huge battery drain and hand warmer. If
I turn it off, and go back to 4G, then the phone cools off, and the
Awake bar in the battery details stops. VERY strange.

Rudd-O
http://rudd-o.com/

Rudd-O · Apr 20, 2016

On 04/18/2016 12:56 PM, Daniel Micay wrote:

No changes beyond introducing the legacy permission toggle. It's not
related to the version, and probably not CopperheadOS.

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#198 (comment)

I am very sure that Wi-Fi is the huge battery drain and hand warmer. If
I turn it off, and go back to 4G, then the phone cools off, and the
Awake bar in the battery details stops. VERY strange.

Rudd-O
http://rudd-o.com/

I have reported the bug upstream:

https://code.google.com/p/android/issues/detail?id=209170

Rudd-O · May 5, 2016

I have reported the bug upstream:

https://code.google.com/p/android/issues/detail?id=209170

Hello. After upgrading to 28/05 again huge battery drains

canary5 · Jun 1, 2016

Hello. After upgrading to 28/05 again huge battery drains

There haven't been changes to CopperheadOS that would impact battery life, and there weren't any changes from upstream either. I doubt it's a problem that's coming and going with the updates. It probably hasn't changed at all.

You should try going to Backup and reset and using the Network settings reset though.

thestinger · Jun 1, 2016

There haven't been changes to CopperheadOS that would impact battery life, and there weren't any changes from upstream either. I doubt it's a problem that's coming and going with the updates. It probably hasn't changed at all.

You should try going to Backup and reset and using the Network settings reset though.

Tnx for the hint. Reseting network fixed drain

canary5 · Jun 2, 2016

Tnx for the hint. Reseting network fixed drain

It was probably caused by the Nexus 5X WiFi driver bugs then. They were triggered by MAC address randomization, but not consistently. Maybe it only happens on specific boots, so updating happened to cause it by rebooting.

thestinger · Jun 2, 2016

It was probably caused by the Nexus 5X WiFi driver bugs then. They were triggered by MAC address randomization, but not consistently. Maybe it only happens on specific boots, so updating happened to cause it by rebooting.

Resetting my network did not fix the drain.

Rebooting the device temporarily solves the drain, but then it comes back.

Rudd-O · Jul 10, 2016

Resetting my network did not fix the drain.

Rebooting the device temporarily solves the drain, but then it comes back.

Yes it was temporary fix. Next day same problems. I need reboot to fix it. But thats temo solution. Weird all May versions worked good for me

canary5 · Jul 10, 2016

Yes it was temporary fix. Next day same problems. I need reboot to fix it. But thats temo solution. Weird all May versions worked good for me

Seems i have same problem on nexus 6p. First 3 days after install it was perfect, now i have drain again

canary5 · Jul 13, 2016

Seems i have same problem on nexus 6p. First 3 days after install it was perfect, now i have drain again

Battery drain without further information isn't going to be considered a valid issue. If it's the netmgrd issue, then it belongs in that issue report.

thestinger · Jul 13, 2016

Battery drain without further information isn't going to be considered a valid issue. If it's the netmgrd issue, then it belongs in that issue report.

I had the same issue. Phone "awake" all the time when on wi-fi, battery graph says android system is keeping the phone awake, poor battery life (nexus 5x), warm, didn't have these issues on cm13 or stock.

I started uninstalling apps one by one and k9 mail turned out to be the problem, further to that, its IMAP IDLE (push) feature. (Stock and cm13 had exchange support, I believe stock uses gmail and cm13 backports an old version of the mail app that has exchange, which is why I turned to k9 mail and IMAP IDLE) Turned that off and now my battery life is actually better than it was on cm13 / stock (about 30% per day vs. 50%).

This isn't really a bug report so if it's not appropriate please delete or let me know. I just wanted to post so people browsing and seeing this thread would see a good experience with CopperheadOS and a possible solution

poisonsnak · Aug 9, 2016

I had the same issue. Phone "awake" all the time when on wi-fi, battery graph says android system is keeping the phone awake, poor battery life (nexus 5x), warm, didn't have these issues on cm13 or stock.

I started uninstalling apps one by one and k9 mail turned out to be the problem, further to that, its IMAP IDLE (push) feature. (Stock and cm13 had exchange support, I believe stock uses gmail and cm13 backports an old version of the mail app that has exchange, which is why I turned to k9 mail and IMAP IDLE) Turned that off and now my battery life is actually better than it was on cm13 / stock (about 30% per day vs. 50%).

This isn't really a bug report so if it's not appropriate please delete or let me know. I just wanted to post so people browsing and seeing this thread would see a good experience with CopperheadOS and a possible solution

CopperheadOS is very close to AOSP and the only battery life impact would come from exploit mitigations making the code a bit slower. It only causes a tiny hit to battery life when the CPU is churning away, not during idle. Any other kind of problem is likely an app or simply an upstream bug in AOSP. I've worked around various AOSP bugs that are not present in stock due to them replacing components and having Qualcomm sources in-tree for their internal builds.

thestinger · Aug 9, 2016

CopperheadOS is very close to AOSP and the only battery life impact would come from exploit mitigations making the code a bit slower. It only causes a tiny hit to battery life when the CPU is churning away, not during idle. Any other kind of problem is likely an app or simply an upstream bug in AOSP. I've worked around various AOSP bugs that are not present in stock due to them replacing components and having Qualcomm sources in-tree for their internal builds.

On 08/09/2016 07:47 PM, Daniel Micay wrote:

CopperheadOS is very close to AOSP and the only battery life impact
would come from exploit mitigations making the code a bit slower. It
only causes a tiny hit to battery life when the CPU is churning away,
not during idle. Any other kind of problem is likely an app or simply
an upstream bug in AOSP. I've worked around various AOSP bugs that are
not present in stock due to them replacing components and having
Qualcomm sources in-tree for their internal builds.

It's worthy of note that I don't have K-9 Mail on my phone.

The apps I had when I started experiencing the problem:

Barcode scanner, CatLog, Document Viewer, Conversations, Ghost
Commander, OsmAnd~.

End list.

A quick read of what is going on right now:

The phone came off the charger 7pm yesterday. It's 12:43 AM and it
already has 27% battery, with a projected life of 2 more hours before it
dies. The battery view makes it clear none of my apps are consuming CPU
or keeping the phone active. The phone has been awake most of the time,
whether screen on or off. Screen has been on for 52 minutes, but CPU
has been awake for 4h 4m (Android OS is the second biggest consumer).
Mobile radio (the biggest consumer) has been active for 4h 45m.
However, the phone has been on Wi-Fi all the time and it's specifically
told to remain on Wi-Fi during sleep, so mobile radio usage should be
minimal. Wi-Fi running time is 0s even though the graph shows Wi-Fi
active since the phone powered on.

It's not even funny. I don't know what's up anymore.

Rudd-O
http://rudd-o.com/

Rudd-O · Aug 9, 2016

On 08/09/2016 07:47 PM, Daniel Micay wrote:

CopperheadOS is very close to AOSP and the only battery life impact
would come from exploit mitigations making the code a bit slower. It
only causes a tiny hit to battery life when the CPU is churning away,
not during idle. Any other kind of problem is likely an app or simply
an upstream bug in AOSP. I've worked around various AOSP bugs that are
not present in stock due to them replacing components and having
Qualcomm sources in-tree for their internal builds.

It's worthy of note that I don't have K-9 Mail on my phone.

The apps I had when I started experiencing the problem:

Barcode scanner, CatLog, Document Viewer, Conversations, Ghost
Commander, OsmAnd~.

End list.

A quick read of what is going on right now:

The phone came off the charger 7pm yesterday. It's 12:43 AM and it
already has 27% battery, with a projected life of 2 more hours before it
dies. The battery view makes it clear none of my apps are consuming CPU
or keeping the phone active. The phone has been awake most of the time,
whether screen on or off. Screen has been on for 52 minutes, but CPU
has been awake for 4h 4m (Android OS is the second biggest consumer).
Mobile radio (the biggest consumer) has been active for 4h 45m.
However, the phone has been on Wi-Fi all the time and it's specifically
told to remain on Wi-Fi during sleep, so mobile radio usage should be
minimal. Wi-Fi running time is 0s even though the graph shows Wi-Fi
active since the phone powered on.

It's not even funny. I don't know what's up anymore.

Rudd-O
http://rudd-o.com/

Try temporarily removing Conversations or perhaps signing out.

thestinger · Aug 9, 2016

Try temporarily removing Conversations or perhaps signing out.

On 08/09/2016 10:49 PM, Daniel Micay wrote:

Try temporarily removing Conversations or perhaps signing out.

I have tried that, and that did not help. I will try again in the hopes
that today's update to Copperhead may have made a difference. Wish me
luck.

Rudd-O
http://rudd-o.com/

Rudd-O · Aug 10, 2016

On 08/09/2016 10:49 PM, Daniel Micay wrote:

Try temporarily removing Conversations or perhaps signing out.

I have tried that, and that did not help. I will try again in the hopes
that today's update to Copperhead may have made a difference. Wish me
luck.

Rudd-O
http://rudd-o.com/

It made no difference to disable Conversations. The phone still decided to insufflate its battery as if was a bag of coke.

I DID track the problem down, though. The permanent transmissions from my phone to the router are of the form:

22:18:49.998760 IP6 <MAC> > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
22:18:50.329467 IP6 <MAC> > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
22:18:50.329514 IP6 <MAC> > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
22:18:51.175207 IP6 <MAC> > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
22:18:51.175258 IP6 <MAC> > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
22:18:51.472169 IP6 <MAC> > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
22:18:51.472215 IP6 <MAC> > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
22:18:52.439179 IP6 <MAC> > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
<tons more, constantly, two or three per second, nonstop>

This is despite the fact that the router has VERIFIABLY disabled IPv6.

This means I need to request one of several things to kill this cancer:

Ability to root my phone while preserving signatures (so I can disable IPv6).
Ability to completely disable IPv6 in the security settings, so the kernel stops being idiotic about this (no, there will be no IPv6, that is a deliberate policy decision to be revised in a few years).
Ability to firewall the phone to my liking so it stops sending requests (likely to provide me with only modest battery savings, since the kernel will still want to send traffic).

Please, can we get (2) on the docket?

Rudd-O · Aug 10, 2016

It made no difference to disable Conversations. The phone still decided to insufflate its battery as if was a bag of coke.

I DID track the problem down, though. The permanent transmissions from my phone to the router are of the form:

22:18:49.998760 IP6 <MAC> > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
22:18:50.329467 IP6 <MAC> > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
22:18:50.329514 IP6 <MAC> > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
22:18:51.175207 IP6 <MAC> > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
22:18:51.175258 IP6 <MAC> > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
22:18:51.472169 IP6 <MAC> > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
22:18:51.472215 IP6 <MAC> > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
22:18:52.439179 IP6 <MAC> > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
<tons more, constantly, two or three per second, nonstop>

This is despite the fact that the router has VERIFIABLY disabled IPv6.

This means I need to request one of several things to kill this cancer:

Ability to root my phone while preserving signatures (so I can disable IPv6).
Ability to completely disable IPv6 in the security settings, so the kernel stops being idiotic about this (no, there will be no IPv6, that is a deliberate policy decision to be revised in a few years).
Ability to firewall the phone to my liking so it stops sending requests (likely to provide me with only modest battery savings, since the kernel will still want to send traffic).

Please, can we get (2) on the docket?

Those messages, I have deciphered, are sent by Android as part of IPv6 multicast. Looks like there's some crap bug in Android. It only happens after the phone has been on for a while. The multicast listener reports stop happening after the phone is rebooted, but resume after a while of the phone being on. I do not know which circumstance triggers that issue.

Rudd-O · Aug 11, 2016

Those messages, I have deciphered, are sent by Android as part of IPv6 multicast. Looks like there's some crap bug in Android. It only happens after the phone has been on for a while. The multicast listener reports stop happening after the phone is rebooted, but resume after a while of the phone being on. I do not know which circumstance triggers that issue.

I can confirm that I am having this issue as well. I was good after uninstalling k-9 mail for a couple days and now it's back, it just starts up part way through the day while connected to wifi and with wireshark I see the same broadcast messages on my LAN that Rudd-O is seeing. I have 4 other android devices on the same wireless AP and they are not doing this, so I'm not sure if the bug is specific to the AOSP on the Nexus 5X, or CopperheadOS. I have been using the phone for about 6 months and this is the first time I've experienced it, but I'm no expert. I would think it would appear quickly on a google search for "android multicast ipv6" for example if it was widespread and affected stock Nexus 5Xs but I haven't found much: https://www.reddit.com/r/Nexus6P/comments/41cutc/disabling_ipv6_may_improve_your_battery_life/

Some of the guys there think it is related to certain wifi access points. I'm using a Ubiquiti ER-X router and UAP-AC-LITE access point. What are you using Rudd-O?

This was interesting as well. https://code.google.com/p/android/issues/detail?id=197460&q=wifi%20drain&sort=-opened&colspec=ID%20Status%20Priority%20Owner%20Summary%20Stars%20Reporter%20Opened I will try disabling 5GHz and report back... in a few days

poisonsnak · Aug 12, 2016

I can confirm that I am having this issue as well. I was good after uninstalling k-9 mail for a couple days and now it's back, it just starts up part way through the day while connected to wifi and with wireshark I see the same broadcast messages on my LAN that Rudd-O is seeing. I have 4 other android devices on the same wireless AP and they are not doing this, so I'm not sure if the bug is specific to the AOSP on the Nexus 5X, or CopperheadOS. I have been using the phone for about 6 months and this is the first time I've experienced it, but I'm no expert. I would think it would appear quickly on a google search for "android multicast ipv6" for example if it was widespread and affected stock Nexus 5Xs but I haven't found much: https://www.reddit.com/r/Nexus6P/comments/41cutc/disabling_ipv6_may_improve_your_battery_life/

Some of the guys there think it is related to certain wifi access points. I'm using a Ubiquiti ER-X router and UAP-AC-LITE access point. What are you using Rudd-O?

This was interesting as well. https://code.google.com/p/android/issues/detail?id=197460&q=wifi%20drain&sort=-opened&colspec=ID%20Status%20Priority%20Owner%20Summary%20Stars%20Reporter%20Opened I will try disabling 5GHz and report back... in a few days

I'm using an OpenWrt access point with IPv6 entirely disabled (the interfaces themselves have the disable_ipv6 sysctl enabled), but I also can confirm that the problem happened at the AP of my previous employer, where IPv6 was enabled.

My phone is connected to the 5 GHz band.

Rudd-O · Aug 12, 2016

I'm using an OpenWrt access point with IPv6 entirely disabled (the interfaces themselves have the disable_ipv6 sysctl enabled), but I also can confirm that the problem happened at the AP of my previous employer, where IPv6 was enabled.

My phone is connected to the 5 GHz band.

Changing to 2.4GHz did not help, it started up on me already this morning.
Do you know these are coming from the kernel in android and are not caused by an app somehow? It just seems weird to me that the CopperheadOS devs know nothing about this, there must be a combination of things causing this. What do you have installed for apps? This is my list:
AirOS Mobile
Amaze
AutHomationHD
Authy
FreeOTP
IceCatMobile
inSSIDer
K-9 Mail (after I found it wasn't the cause, I reinstalled it)
MuPDF
Steam
WhatsApp

When I have time, hopefully this weekend, I'm going to wait for the bug to appear and then try using netstat in adb to find out where they are coming from http://stackoverflow.com/questions/14229816/how-to-use-adb-shell-to-find-the-ports-which-a-process-is-using

poisonsnak · Aug 12, 2016

Changing to 2.4GHz did not help, it started up on me already this morning.
Do you know these are coming from the kernel in android and are not caused by an app somehow? It just seems weird to me that the CopperheadOS devs know nothing about this, there must be a combination of things causing this. What do you have installed for apps? This is my list:
AirOS Mobile
Amaze
AutHomationHD
Authy
FreeOTP
IceCatMobile
inSSIDer
K-9 Mail (after I found it wasn't the cause, I reinstalled it)
MuPDF
Steam
WhatsApp

When I have time, hopefully this weekend, I'm going to wait for the bug to appear and then try using netstat in adb to find out where they are coming from http://stackoverflow.com/questions/14229816/how-to-use-adb-shell-to-find-the-ports-which-a-process-is-using

It is 100% certainly coming from the kernel, because it's the kernel
that is responsible for IPv6 address negotiation, and those absurdly
repetitive packets are part of the IPv6 address configuration process.

Rudd-O
http://rudd-o.com/

Rudd-O · Aug 12, 2016

It is 100% certainly coming from the kernel, because it's the kernel
that is responsible for IPv6 address negotiation, and those absurdly
repetitive packets are part of the IPv6 address configuration process.

Rudd-O
http://rudd-o.com/

CopperheadOS doesn't do much that's relevant to this. It only adds a couple netfilter rules (reverse path filtering and dropping INVALID packets) and changes a few sysctl settings. Perhaps that's triggering this for you, but it's not doing anything wrong. I can't replicate this, so I can't debug it.

thestinger · Aug 12, 2016

CopperheadOS doesn't do much that's relevant to this. It only adds a couple netfilter rules (reverse path filtering and dropping INVALID packets) and changes a few sysctl settings. Perhaps that's triggering this for you, but it's not doing anything wrong. I can't replicate this, so I can't debug it.

I no longer believe it's CopperheadOS that's causing this. This must be
some sort of complex grand mal seizure that the Android kernel is
experiencing. Clearly there is no reason, regardless of netfilter
rules, that the kernel would need to bombard the LAN with this idiotic
series of packets.

I will have to take this up to the Android folks, who are epic in their
unresponsiveness.

It is, however, a problem for the users of your technology, given that
it's not just me, and that it doesn't seem to affect just Nexus 5X
users. Might be worthwhile to try and set up a reproducer, then debug
the kernel. I could probably do it myself using some perf goodness or
something like that, if my phone was not limited to non-root apps.
Right now, I'm limited to whatever is non-root that I can to diagnose
the issue... and that's not much I can do.

This is why I prefer open Linux systems over the nonsense that is modern
locked-down "Linux".

Rudd-O · Aug 12, 2016

I no longer believe it's CopperheadOS that's causing this. This must be
some sort of complex grand mal seizure that the Android kernel is
experiencing. Clearly there is no reason, regardless of netfilter
rules, that the kernel would need to bombard the LAN with this idiotic
series of packets.

I will have to take this up to the Android folks, who are epic in their
unresponsiveness.

It is, however, a problem for the users of your technology, given that
it's not just me, and that it doesn't seem to affect just Nexus 5X
users. Might be worthwhile to try and set up a reproducer, then debug
the kernel. I could probably do it myself using some perf goodness or
something like that, if my phone was not limited to non-root apps.
Right now, I'm limited to whatever is non-root that I can to diagnose
the issue... and that's not much I can do.

This is why I prefer open Linux systems over the nonsense that is modern
locked-down "Linux".

It could be a bug triggered by the netfilter rules.

thestinger · Aug 12, 2016

It could be a bug triggered by the netfilter rules.

On 08/12/2016 09:02 PM, Daniel Micay wrote:

It could be a bug triggered by the netfilter rules.

Well, yes, that's true, but

(1) would that not cause the issue unconditionally and at all times I'm
on Wi-Fi?
(2) if that was true, then I would still have no way to actually
diagnose the issue, because I do not have root on the phone.

Rudd-O
http://rudd-o.com/

Rudd-O · Aug 13, 2016

On 08/12/2016 09:02 PM, Daniel Micay wrote:

It could be a bug triggered by the netfilter rules.

Well, yes, that's true, but

(1) would that not cause the issue unconditionally and at all times I'm
on Wi-Fi?
(2) if that was true, then I would still have no way to actually
diagnose the issue, because I do not have root on the phone.

Rudd-O
http://rudd-o.com/

It started up again today. Here's a brief history of what I did to trigger it:
friday, 8AM - unplug phone, at 100%, set wifi during sleep to disabled as I needed the phone to last
saturday, 11:30 PM - set wifi during sleep to enabled. Battery at 75% (no charging in between)
sunday, 1:45 PM - left the range of my wifi AP
sunday, 2:55 PM - returned to within range of my wifi AP
sunday, 3:45 PM - noticed phone was hot, had been awake for some time.

From 2:55 to 3:35 you can see netmgrd crashing over and over in the log. It seems to stop crashing (or does this get suppressed in the log after a while?) but the wakelock persists until the phone is restarted.

I think this leaving and returning to the AP may trigger the issue. The last time it happened, I was at work, ran out to pick something up, came back, and noticed my phone was hot a little while later.
adb logcat.txt

adb shell dumpsys batterystats shows netmgrd with 30 minutes of wakelock
All kernel wake locks:
Kernel Wake lock netmgr_wl : 30m 54s 463ms (4 times) realtime
adb shell dumpsys batterystats.txt

adb netstat had only one connection
udp 0 0 192.168.11.117:68 192.168.11.1:67 ESTABLISHED -
which I believe is for DHCP? Seems odd for it to be connected for more than a few seconds. I ran it again after 5 minutes and the connection was still established.
adb netstat.txt

adb shell top had this for usage
User 4%, System 5%, IOW 0%, IRQ 0%
User 74 + Nice 1 + Sys 109 + Idle 1653 + IOW 0 + IRQ 2 + SIRQ 4 = 1843
adb shell top.txt

adb shell dumpsys power had this to say about wakelocks
Wake Locks: size=1
DOZE_WAKE_LOCK 'DreamManagerService' (uid=1000, pid=4278, ws=null)
adb shell dumpsys power.txt

I've attached the full output of these commands. Hopefully this helps track down the source. I won't restart my phone for the rest of the day in case you want me to try something else.

poisonsnak · Aug 15, 2016