# rpi-connect 2.7.0/2.8.0 — DTLS sessions dying after ~60-75 seconds, UDP responses dropped through router
## Summary
Since around February 18, 2026, rpi-connect sessions consistently drop after approximately 60–75 seconds with DTLS timeouts. The problem started when rpi-connect auto-upgraded to 2.8.0. Downgrading to 2.7.0 did not resolve the issue. No router or network settings were changed.
## Environment
- **Device:** Raspberry Pi 5 8GB, Raspberry Pi OS Bookworm arm64
- **rpi-connect:** 2.7.0 (downgraded from 2.8.0 — same behaviour on both)
- **Network:** Vodafone Ultra Hub router (192.168.1.1), Pi on static DHCP at 192.168.1.4, wired Ethernet
- **Other services on Pi:** Pi-hole (stopped), UniFi Network Application (stopped) — issue persists with both stopped
- **Network manager:** NetworkManager (not dhcpcd)
## Symptoms
Sessions connect successfully but die after ~60–75 seconds. The pattern is always the same:
1. Session starts normally
2. Around 55–70 seconds in, a DNS lookup for `api.connect.raspberrypi.com` times out
3. ~7 seconds later, the DTLS session dies
### Log examples
```
03:56:29 INFO [shell]: Proxy session started
03:57:24 WARN API call unsuccessful error="Get \"https://api.connect.raspberrypi.com/keys?...\":
dial tcp: lookup api.connect.raspberrypi.com on 8.8.8.8:53:
read udp 192.168.1.4:50259->8.8.8.8:53: i/o timeout"
03:57:30 INFO [shell]: Proxy session ended reason="Client->Server proxying cancelled:
dtls timeout: read/write timeout: context deadline exceeded"
```
**Key observation:** The DNS timeout occurs even when DNS is pointed at external resolvers (1.1.1.1, 8.8.8.8) rather than the router — meaning UDP *responses* coming back through the router's NAT are being dropped, not the router's DNS service itself.
## Diagnostics performed
### tcpdump of ICE candidate gathering
When a new Pi Connect session starts, the Pi sends a burst of ~70+ UDP packets in under 200ms across multiple source ports to multiple STUN/TURN servers:
```
03:39:37.554841 IP 192.168.1.4.36229 > 176.126.241.228.62850: UDP, length 100
03:39:37.555696 IP 192.168.1.4.36229 > 176.126.241.228.49317: UDP, length 100
03:39:37.555724 IP 192.168.1.4.36229 > 176.126.241.228.64425: UDP, length 100
03:39:37.555742 IP 192.168.1.4.36229 > 176.126.241.228.54354: UDP, length 100
03:39:37.555764 IP 192.168.1.4.36229 > 90.249.152.204.56372: UDP, length 100
03:39:37.555783 IP 192.168.1.4.36229 > 176.126.241.228.56239: UDP, length 100
[...60+ more packets in rapid succession across ports 36229, 35175, 39447, 49197...]
```
**Zero responses were received** from any of these during the ICE burst. In contrast, a steady-state session shows healthy bidirectional UDP:
```
03:39:28.636354 IP 192.168.1.4.45971 > 90.249.152.204.60181: UDP, length 100
03:39:28.896646 IP 90.249.152.204.60181 > 192.168.1.4.45971: UDP, length 64
03:39:29.799302 IP 90.249.152.204.60181 > 192.168.1.4.45971: UDP, length 112
```
### Router NAT session table
The router's conntrack table shows ~20+ separate UDP NAT entries for Pi Connect (STUN servers at 176.126.241.228, 176.126.241.229, 185.101.97.8; peer at 90.249.152.204) — each on different source ports. The total session count (~100 entries across all devices) is not extreme, but the burst rate of new NAT mappings appears to overwhelm the router.
### What works fine
- TCP connections through the same router: SSH, HTTPS, all stable
- ICMP: ping works perfectly
- `dig` queries to any DNS server: work fine in isolation (0ms)
- Direct peer-to-peer UDP during a steady-state session: bidirectional, healthy
- rpi-connect on two other Pis on a different network/router: rock solid
### What was tested
- Downgraded rpi-connect from 2.8.0 to 2.7.0 — no change
- Verified clean downgrade (no leftover config in ~/.config/rpi-connect, /etc/rpi-connect, /etc/default/rpi-connect)
- Changed DNS from router (192.168.1.1) to Cloudflare/Google (1.1.1.1, 8.8.8.8) — DNS still times out through the router's NAT
- Enabled UPnP on router — no change
- Stopped Pi-hole and UniFi — no change
## Questions
1. Were there any server-side changes to the STUN/TURN relay infrastructure around February 18, 2026? For example, additional relay servers, changed ICE candidate strategies, or modified DTLS keepalive intervals?
2. Is it expected that ICE gathering sends 70+ UDP packets in a sub-200ms burst? Could this be rate-limited or staggered to be friendlier to consumer routers with limited NAT table throughput?
3. Could the mid-session API polling (`/keys?filter=...`) be made resilient to a single DNS timeout, rather than allowing it to cascade into a DTLS session termination?
4. Is there a way to enable verbose logging that might show the specific ICE/DTLS negotiation details? The standard journal output doesn't show which candidates succeed or fail.
Happy to provide any additional diagnostics. The Pi is accessible via SSH so I can run whatever tests would help narrow this down.
## Summary
Since around February 18, 2026, rpi-connect sessions consistently drop after approximately 60–75 seconds with DTLS timeouts. The problem started when rpi-connect auto-upgraded to 2.8.0. Downgrading to 2.7.0 did not resolve the issue. No router or network settings were changed.
## Environment
- **Device:** Raspberry Pi 5 8GB, Raspberry Pi OS Bookworm arm64
- **rpi-connect:** 2.7.0 (downgraded from 2.8.0 — same behaviour on both)
- **Network:** Vodafone Ultra Hub router (192.168.1.1), Pi on static DHCP at 192.168.1.4, wired Ethernet
- **Other services on Pi:** Pi-hole (stopped), UniFi Network Application (stopped) — issue persists with both stopped
- **Network manager:** NetworkManager (not dhcpcd)
## Symptoms
Sessions connect successfully but die after ~60–75 seconds. The pattern is always the same:
1. Session starts normally
2. Around 55–70 seconds in, a DNS lookup for `api.connect.raspberrypi.com` times out
3. ~7 seconds later, the DTLS session dies
### Log examples
```
03:56:29 INFO [shell]: Proxy session started
03:57:24 WARN API call unsuccessful error="Get \"https://api.connect.raspberrypi.com/keys?...\":
dial tcp: lookup api.connect.raspberrypi.com on 8.8.8.8:53:
read udp 192.168.1.4:50259->8.8.8.8:53: i/o timeout"
03:57:30 INFO [shell]: Proxy session ended reason="Client->Server proxying cancelled:
dtls timeout: read/write timeout: context deadline exceeded"
```
**Key observation:** The DNS timeout occurs even when DNS is pointed at external resolvers (1.1.1.1, 8.8.8.8) rather than the router — meaning UDP *responses* coming back through the router's NAT are being dropped, not the router's DNS service itself.
## Diagnostics performed
### tcpdump of ICE candidate gathering
When a new Pi Connect session starts, the Pi sends a burst of ~70+ UDP packets in under 200ms across multiple source ports to multiple STUN/TURN servers:
```
03:39:37.554841 IP 192.168.1.4.36229 > 176.126.241.228.62850: UDP, length 100
03:39:37.555696 IP 192.168.1.4.36229 > 176.126.241.228.49317: UDP, length 100
03:39:37.555724 IP 192.168.1.4.36229 > 176.126.241.228.64425: UDP, length 100
03:39:37.555742 IP 192.168.1.4.36229 > 176.126.241.228.54354: UDP, length 100
03:39:37.555764 IP 192.168.1.4.36229 > 90.249.152.204.56372: UDP, length 100
03:39:37.555783 IP 192.168.1.4.36229 > 176.126.241.228.56239: UDP, length 100
[...60+ more packets in rapid succession across ports 36229, 35175, 39447, 49197...]
```
**Zero responses were received** from any of these during the ICE burst. In contrast, a steady-state session shows healthy bidirectional UDP:
```
03:39:28.636354 IP 192.168.1.4.45971 > 90.249.152.204.60181: UDP, length 100
03:39:28.896646 IP 90.249.152.204.60181 > 192.168.1.4.45971: UDP, length 64
03:39:29.799302 IP 90.249.152.204.60181 > 192.168.1.4.45971: UDP, length 112
```
### Router NAT session table
The router's conntrack table shows ~20+ separate UDP NAT entries for Pi Connect (STUN servers at 176.126.241.228, 176.126.241.229, 185.101.97.8; peer at 90.249.152.204) — each on different source ports. The total session count (~100 entries across all devices) is not extreme, but the burst rate of new NAT mappings appears to overwhelm the router.
### What works fine
- TCP connections through the same router: SSH, HTTPS, all stable
- ICMP: ping works perfectly
- `dig` queries to any DNS server: work fine in isolation (0ms)
- Direct peer-to-peer UDP during a steady-state session: bidirectional, healthy
- rpi-connect on two other Pis on a different network/router: rock solid
### What was tested
- Downgraded rpi-connect from 2.8.0 to 2.7.0 — no change
- Verified clean downgrade (no leftover config in ~/.config/rpi-connect, /etc/rpi-connect, /etc/default/rpi-connect)
- Changed DNS from router (192.168.1.1) to Cloudflare/Google (1.1.1.1, 8.8.8.8) — DNS still times out through the router's NAT
- Enabled UPnP on router — no change
- Stopped Pi-hole and UniFi — no change
## Questions
1. Were there any server-side changes to the STUN/TURN relay infrastructure around February 18, 2026? For example, additional relay servers, changed ICE candidate strategies, or modified DTLS keepalive intervals?
2. Is it expected that ICE gathering sends 70+ UDP packets in a sub-200ms burst? Could this be rate-limited or staggered to be friendlier to consumer routers with limited NAT table throughput?
3. Could the mid-session API polling (`/keys?filter=...`) be made resilient to a single DNS timeout, rather than allowing it to cascade into a DTLS session termination?
4. Is there a way to enable verbose logging that might show the specific ICE/DTLS negotiation details? The standard journal output doesn't show which candidates succeed or fail.
Happy to provide any additional diagnostics. The Pi is accessible via SSH so I can run whatever tests would help narrow this down.
Statistics: Posted by dazzingo — Fri Feb 27, 2026 3:18 pm — Replies 0 — Views 32