Android: 4s ICE keepalive prevents the device from ever reaching deep sleep (~8x idle battery drain)

[Klos54]

Before posting

• I searched existing discussions and issues, including closed ones, and checked the relevant docs.
• I believe this is a product bug rather than a configuration or setup question.
• I can reproduce this issue, or for intermittent issues I've included trigger, frequency, and timing details below.
• I removed or anonymized sensitive data from logs, screenshots, and configuration.

Affected area

Client / Agent, Mobile app

Deployment type

Self-hosted - advanced/custom deployment

Operating system or environment

Linux, Android

NetBird version and upgrade status

netbird: v0.76.3-18-gdb9fcf39e
Client: JetBird (third-party Android front-end built on client/android)
Device: OnePlus 9 Pro (LE2123), Android 16, LineageOS-based, rooted (KernelSU Next)
Management: self-hosted, same version
Peers: 2 (this phone + one Linux routing peer on the same LAN)
Connection: direct, host/host ICE candidate pair, no relay

Did this work before?

Not sure

Regression details

N/A — I have no older netbird version to compare against on this device.
My baseline is the plain WireGuard Android app on the same phone, same night
pattern, two days earlier: 10.8 mAh/h idle versus 89 mAh/h with netbird.

Summary

On Android, the unconditional 4-second ICE keepalive (iceKeepAliveDefault in
client/internal/peer/ice/agent.go) wakes the device roughly every 4 seconds
while the screen is off. The CPU never stays suspended, Doze never becomes
effective, and idle battery drain goes from ~11 mAh/h to ~89 mAh/h — a factor
of 8.

NB_ICE_KEEP_ALIVE_INTERVAL_SEC can override it, but that key is not exported in
client/android/env_list.go, so Android front-ends are not given the knob.

Current behavior

With the client connected, screen off, unplugged and no user activity, the
phone suspends and resumes continuously instead of sleeping.

Kernel suspend counter (/sys/power/suspend_stats/success) over a ~3 minute
window, screen off and unplugged, same device and session:

client running, Rosenpass enabled -> 847 suspends / 1854 s = 1 every 2.2 s
client running, Rosenpass disabled -> 38 suspends / 180 s = 1 every 4.7 s
client stopped (am force-stop) -> 1 suspend / 180 s = sleeps through

Each cycle is ~320 ms awake. Every wake carries the same kernel reason, 1:1
with the suspend count, from dumpsys batterystats --history:

+running wake_reason=0:"Abort: Pending Wakeup Sources: [timerfd]"
-running
+running wake_reason=0:"Abort: Pending Wakeup Sources: [timerfd]"
-running

Over a full night: 34 % awake time with the screen off (3 h 53 out of 11 h 21),
against roughly 6 % on the same device without the client. Doze never reaches
deep idle - dumpsys deviceidle reports mState=ACTIVE after 12 minutes with the
screen off.

ftrace on power:wakeup_source_activate filtered to [timerfd], captured during
the loop, shows the wakeup source taken from ep_poll_callback and drained by
system_server's AlarmManager thread. So Android's own alarm/epoll machinery is
being spun; the VPN app is not holding a wakelock itself:

-0 wakeup_source_activate: [timerfd]
=> __pm_stay_awake
=> ep_poll_callback
AlarmManager-2716 wakeup_source_activate: [timerfd]
=> __pm_stay_awake
=> ep_send_events_proc

The ~4.7 s cadence with Rosenpass off matches iceKeepAliveDefault = 4 s.
Rosenpass adds a second beat on top, roughly halving the interval.

I have not proven the exact path from the ICE keepalive to the AlarmManager
timerfd. What is established: the cadence matches the configured keepalive, and
stopping the client removes the wakes entirely.

Expected behavior

An idle Android peer with no traffic should let the device reach deep sleep for
minutes at a time. A 4-second keepalive is a reasonable desktop default for
holding a NAT binding, but on a battery-powered handset it is far more
aggressive than needed - WireGuard's own PersistentKeepalive default, which
netbird itself uses for the data plane (defaultWgKeepAlive = 25 * time.Second
in client/internal/peer/endpoint.go), is 25 seconds and is empirically low
enough for the device to sleep normally.

Steps to reproduce

1. Connect an Android client to one peer (direct P2P, no relay needed).
2. Screen off, unplugged, no user activity.
3. Read the kernel suspend counter:
   adb shell su -c 'cat /sys/power/suspend_stats/success'
4. Wait 3 minutes, read it again.
5. Stop the client (am force-stop ) and repeat steps 2-4.

Observed: hundreds of suspend/resume cycles with the client running, versus
one with it stopped.

• Trigger: client connected, screen off, device unplugged
• Frequency: 100 %, every time, from the moment the client connects
• Timing: one wake every ~4.7 s (Rosenpass off) or ~2.2 s (Rosenpass on)

Environment and topology

• Peer A: Android 16 handset (OnePlus 9 Pro), JetBird client, Wi-Fi
• Peer B: Linux routing peer (Alpine container), kernel WireGuard, wired
• Same LAN or different networks: same LAN
• NAT/CGNAT/corporate firewall/mobile network: consumer NAT, no CGNAT
• Other VPN software: none active during the tests
• Firewall, DNS, or endpoint security software: none on the handset
• Routes, DNS, policies, posture checks, or SSH rules involved:
  one 0.0.0.0/0 exit-node route advertised by Peer B, distributed to Peer A
  (the behaviour is identical with the route disabled)
• IdP, reverse proxy, or browser involved: N/A for this issue

Self-hosted details, if available

• Deployment method: single self-hosted container, custom
• Management/signal/relay/dashboard versions: all v0.76.3-18-gdb9fcf39e
• Reverse proxy: yes, TLS terminated in front of management/signal/relay
• IdP/provider: built-in
• STUN/TURN/coturn/relay details: self-hosted STUN + netbird relay, same host.
  Not exercised in this reproduction - the peers connect host/host, directly
  on the LAN, with no relay in the path.
• Relevant component logs: nothing abnormal; the peer link is healthy
  throughout (handshakes fine, no reconnects)

Logs, status output, or debug evidence

netbird status -dA from the Linux peer, manually redacted further (see note
below):

Peers detail:
 <android-peer>.netbird.selfhosted:
  NetBird IP: 100.x.x.x
  Public key: <redacted>
  Status: Connected
  -- detail --
  Connection type: P2P
  ICE candidate (Local/Remote): host/host
  ICE candidate endpoints (Local/Remote): <v6>:51820/<v6>:51820
  Relay server address: rels://<redacted>:443
  Last connection update: 20 minutes, 36 seconds ago
  Last WireGuard handshake: 15 seconds ago
  Transfer status (received/sent) 125.4 KiB/233.7 KiB
  Quantum resistance: false (remote didn't enable quantum resistance)
  Networks: -
  Latency: 31.086153ms

The link is healthy the whole time - this is not a reconnect loop. The battery
evidence is on the Android side and is quoted in "Current behavior" above:
/sys/power/suspend_stats, dumpsys batterystats --history wake reasons, and an
ftrace of power:wakeup_source_activate.

Note: `netbird status -A` did not fully anonymize its output - it left the peer
public key, the overlay IP, the device hostname, and part of the relay domain
in clear. Worth a separate look.

No debug bundle attached: JetBird does not expose `netbird debug`, and the
Linux peer is not the one exhibiting the problem. I can produce anything
specific you want from the handset.

Related issues or discussions

• Related issue/discussion: Memory leak after 0.40.0 update #3678 (RSS climb from repeated
  net.InterfaceByName polling on non-Linux platforms)
• Why this may be the same or different: different symptom and different code
  path, but the same underlying theme - a fixed-interval poll that is fine on a
  desktop and expensive on a constrained platform. Memory leak after 0.40.0 update #3678 was fixed by making
  the Linux watcher event-driven; this report is about the ICE keepalive, which
  is still a fixed interval everywhere.

Impact

• Affected users/peers: every Android peer, as far as I can tell - the keepalive
  is unconditional and there is no way to change it from an Android front-end
• Business or production impact: personal device; the phone loses roughly a
  third of its standby battery. Enough that I switched back to plain WireGuard.
• Workaround available: partial. Disabling Rosenpass roughly halves the wake
  rate but still leaves a wake every ~5 s. A front-end could set
  NB_ICE_KEEP_ALIVE_INTERVAL_SEC by hardcoding the string, since
  exportEnvList() calls os.Setenv on arbitrary keys - but the key is not in
  client/android/env_list.go, so it is not discoverable, and it requires
  rebuilding the app.

Additional context

Relevant code:

client/internal/peer/ice/agent.go
iceKeepAliveDefault = 4 * time.Second
iceDisconnectedTimeoutDefault = 6 * time.Second
iceFailedTimeoutDefault = 6 * time.Second

agentConfig := &ice.AgentConfig{
...
KeepaliveInterval: &iceKeepAlive,
DisconnectedTimeout: &iceDisconnectedTimeout,
...
}

pion sends a STUN binding indication on the selected pair every
KeepaliveInterval. There is no adaptation to GOOS == "android", to screen
state, or to the platform idle mode.

client/android/env_list.go exports EnvKeyNBForceRelay, EnvKeyNBLazyConn and
EnvKeyNBInactivityThreshold, but none of the ICE tuning keys.

Suggested fixes, roughly in order of how much they help:

1. Adapt the keepalive on mobile. Something in the 15-25 s range on
   android/ios would match what WireGuard considers sufficient to hold a NAT
   mapping, at 6x fewer wakes.

2. Export the existing knob to Android:

   // EnvKeyNBICEKeepAlive Exported for Android java client to tune the ICE keepalive
   EnvKeyNBICEKeepAlive = ice.EnvICEKeepAliveIntervalSec

3. Suspend or stretch keepalives while the platform reports idle. The Android
   front-end knows when the device enters Doze; a hook to pause on idle and
   resume on wake would remove the drain rather than reduce it.

Secondary: enabling Rosenpass roughly doubles the wake rate on top of the ICE
keepalive. The same idle adaptation would probably be worth applying there.

[lionking102]

Great findings! This is a big problem with the netbird-mobile apps. Thanks for investigating, hope some developer sees it an can provice a fix, this would be awesome!