After update from 0.5.5u to 0.5.6 I noticed that the wireguard connection to my opnsense server no longer worked. The connection started, showed briefly "connected", but the switched to "failed".
After testing several versions I can now confirm that the regression happened between 0.5.5u (good) and 0.5.5v (bad).
I extracted logs (attached) and let Claude look into them. Maybe the analysis can help.
Summary
On v0.5.6, the WireGuard proxy (wg2)
repeatedly fails because getUnderlays()
always returns an empty/null underlying-network list
(null-underlay? true),
which in turn causes no
network to bind, who: wg2 on every single connection attempt.
As a result the tunnel never completes a usable handshake and
never relays a single packet, even though the UI briefly
flashes "Connected" before erroring out again.
Rolling back to v0.5.5u, with the exact same WireGuard
configuration and the same endpoint, fixes the issue immediately
— the tunnel connects and passes traffic normally.
Environment
Broken version: v0.5.5v - v0.5.6 (679)
Working version: v0.5.5u
Install source: F-Droid / GitHub & Play
Android version / device: Google Pixel 9 Pro
WireGuard config: single proxy wg2,
endpoint reachable via a DynDNS hostname (<hostname>:51820)
pointing at a self-hosted WireGuard server behind a home
router/firewall
Network condition during capture: Wi-Fi and mobile data both
active and "VALIDATED" at the same time (dual
connectivity). Also reproduced with mobile data fully disabled
(Wi-Fi only) — no change, so this does not appear
to be a dual-network ambiguity issue by itself.
Steps to reproduce
Configure a WireGuard proxy pointing at a self-hosted WG
server reachable via a DynDNS hostname.
Enable the WireGuard proxy on v0.5.6.
Observe the Home tab / proxy status: briefly "connecting"
→ "connected" → error, within seconds.
Check Configure ->
Logs: see pattern below repeating indefinitely.
Expected behavior
WireGuard proxy establishes a handshake and relays traffic,
exactly as it does on v0.5.5u with the identical configuration
and the identical network.
Actual behavior (v0.5.6)
Immediately after the proxy is added:
RethinkDnsVpn: getUnderlays: use active? true; fail-open? true; null on lockdown? false; networks: null; null-underlay? true
RethinkDnsVpn: no network to bind, who: wg2, fd: 97, addr: [::]:51932
This pair repeats on every attempt — 16/16 occurrences of
null-underlay? true
across a ~4h session, spanning multiple disable/enable cycles
and multiple network transitions (Wi-Fi only, Wi-Fi+mobile,
mobile only, signal strength changes).
Every subsequent outbound UDP attempt from wg2
fails immediately:
proxy: no route to host for 10284 to udp:1.1.1.1:53 among [wg2]
DNS-over-wg2 requests
(used for Rethink's own connectivity checks) time out repeatedly:
dns53: sendRequest: (wg2) for dl.rethinkdns.com. (elapsed: 15.001118s); err: read udp 172.17.200.1:46354: i/o timeout
The proxy is eventually marked unresponsive
→ paused, then
automatically disabled/re-enabled, and the whole cycle repeats:
proxy: wg: wg2:... onNotOK: paused; status proxy: paused
proxy: refresh (wg2/wg/<ip>:51820) failed: proxy: paused
ProxyLogs: disable wg config: 2, ...
ProxyLogs: enable wg config: 2, ...
Not a single TOK: read
ok / TOK: write ok
/ TOK: ok (i.e. an
actual successfully relayed WireGuard packet) appears anywhere
across >4 hours of v0.5.6 logs.
Side-by-side comparison (same device, same
WireGuard config, same endpoint)
| |
v0.5.5u (working) |
v0.5.6 (broken) |
| getUnderlays / null-underlay? true |
0 occurrences (path not hit / never null) |
16 / 16 attempts |
| no network to bind |
0 |
11 |
| TOK: read ok / write ok / conn ok (successful relayed WG traffic) |
17 |
0 |
| wg: bind: recv: wg2 ... use of closed network connection (harmless socket-rebind noise) |
present |
present |
Note on that last row: this "closed network connection"
message appears in both logs and does not correlate with
success or failure — it shows up around normal socket rebinds and
is not, by itself, a sign of the underlying bug. Flagging this
so it isn't chased as a red herring; the actual signature of the
regression is the getUnderlays/null-underlay/no
network to bind triplet, which is entirely absent from the
working v0.5.5u log.
Additional notes
Server-side: tcpdump
on the WireGuard server's WAN interface shows the client's
UDP/51820 handshake packets arriving, but they are never
observed on the wg0
interface itself. Not certain whether this is downstream of the
client never completing a proper bind, or a separate issue —
flagging in case it's relevant to how the client selects the
source network/port for outbound WireGuard packets.
Willing to provide full logs, a stability-program capture, or
test intermediate nightlies/alphas if that helps narrow down
which change between v0.5.5u and v0.5.6 introduced the
getUnderlays
regression.
Attachments
rethink_app_logs_v0_5_6.zip
— broken, ~4h capture, multiple reconnect cycles
rethink_app_logs_v0_5_5u.zip
— working, same device/config, captured immediately
after downgrading
After update from 0.5.5u to 0.5.6 I noticed that the wireguard connection to my opnsense server no longer worked. The connection started, showed briefly "connected", but the switched to "failed".
After testing several versions I can now confirm that the regression happened between 0.5.5u (good) and 0.5.5v (bad).
I extracted logs (attached) and let Claude look into them. Maybe the analysis can help.
Summary
On v0.5.6, the WireGuard proxy (wg2) repeatedly fails because getUnderlays() always returns an empty/null underlying-network list (null-underlay? true), which in turn causes no network to bind, who: wg2 on every single connection attempt. As a result the tunnel never completes a usable handshake and never relays a single packet, even though the UI briefly flashes "Connected" before erroring out again.
Rolling back to v0.5.5u, with the exact same WireGuard configuration and the same endpoint, fixes the issue immediately — the tunnel connects and passes traffic normally.
Environment
Broken version: v0.5.5v - v0.5.6 (679)
Working version: v0.5.5u
Install source: F-Droid / GitHub & Play
Android version / device: Google Pixel 9 Pro
WireGuard config: single proxy wg2, endpoint reachable via a DynDNS hostname (<hostname>:51820) pointing at a self-hosted WireGuard server behind a home router/firewall
Network condition during capture: Wi-Fi and mobile data both active and "VALIDATED" at the same time (dual connectivity). Also reproduced with mobile data fully disabled (Wi-Fi only) — no change, so this does not appear to be a dual-network ambiguity issue by itself.
Steps to reproduce
Configure a WireGuard proxy pointing at a self-hosted WG server reachable via a DynDNS hostname.
Enable the WireGuard proxy on v0.5.6.
Observe the Home tab / proxy status: briefly "connecting" → "connected" → error, within seconds.
Check Configure -> Logs: see pattern below repeating indefinitely.
Expected behavior
WireGuard proxy establishes a handshake and relays traffic, exactly as it does on v0.5.5u with the identical configuration and the identical network.
Actual behavior (v0.5.6)
Immediately after the proxy is added:
This pair repeats on every attempt — 16/16 occurrences of null-underlay? true across a ~4h session, spanning multiple disable/enable cycles and multiple network transitions (Wi-Fi only, Wi-Fi+mobile, mobile only, signal strength changes).
Every subsequent outbound UDP attempt from wg2 fails immediately:
DNS-over-wg2 requests (used for Rethink's own connectivity checks) time out repeatedly:
The proxy is eventually marked unresponsive → paused, then automatically disabled/re-enabled, and the whole cycle repeats:
Not a single TOK: read ok / TOK: write ok / TOK: ok (i.e. an actual successfully relayed WireGuard packet) appears anywhere across >4 hours of v0.5.6 logs.
Side-by-side comparison (same device, same WireGuard config, same endpoint)
Note on that last row: this "closed network connection" message appears in both logs and does not correlate with success or failure — it shows up around normal socket rebinds and is not, by itself, a sign of the underlying bug. Flagging this so it isn't chased as a red herring; the actual signature of the regression is the getUnderlays/null-underlay/no network to bind triplet, which is entirely absent from the working v0.5.5u log.
Additional notes
Server-side: tcpdump on the WireGuard server's WAN interface shows the client's UDP/51820 handshake packets arriving, but they are never observed on the wg0 interface itself. Not certain whether this is downstream of the client never completing a proper bind, or a separate issue — flagging in case it's relevant to how the client selects the source network/port for outbound WireGuard packets.
Willing to provide full logs, a stability-program capture, or test intermediate nightlies/alphas if that helps narrow down which change between v0.5.5u and v0.5.6 introduced the getUnderlays regression.
Attachments
rethink_app_logs_v0_5_6.zip — broken, ~4h capture, multiple reconnect cycles
rethink_app_logs_v0_5_5u.zip — working, same device/config, captured immediately after downgrading