Add automatic DNS re-resolution and connection state monitoring #82
Conversation
Implements periodic monitoring of tunnel handshakes to automatically re-resolve DNS endpoints when handshakes become stale (>135 seconds old). This is useful for dynamic DNS endpoints where the IP address may change while the tunnel is running. Key changes: - Added handshake monitor in TunnelManager that checks every 30 seconds - Monitor detects stale handshakes and triggers DNS re-resolution via setState() - Added user preference toggle (enabled by default) - Leverages existing GoBackend DNS resolution logic with retry mechanism - Comprehensive implementation documentation in IMPLEMENTATION_DNS_RERESOLVE.md Based on the reresolve-dns.sh script from wireguard-tools, adapted for Android with Kotlin coroutines and user preferences. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Implement warning notifications that alert users when WireGuard connections fail to establish or become stale. This provides immediate feedback when tunnels show as "UP" but aren't actually working. Features: - Show persistent notification after 30 seconds when no handshake completes - Show notification after 135 seconds when handshake becomes stale - Notification is persistent (ongoing) until issue resolves - Add DUMP_DIAGNOSTICS broadcast intent for debugging - Request POST_NOTIFICATIONS permission on Android 13+ - Remove permission requirement for DUMP_DIAGNOSTICS action The notification helps identify connection problems at networks that block WireGuard, where the tunnel appears connected but no traffic flows. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
…l stop - Remove setSingleLine() call to allow log lines to wrap naturally - Clean up unused isSingleLine field and broken click handler - Dismiss stale handshake notifications when tunnel is turned OFF - Clear notifications when no tunnels are running - Clear tracking state to prevent incorrect warnings
Add connection state text suffixes to tunnel names in the list view for better visibility. Create monochrome notification icon to fix transparency and display issues in the notification tray. - Add displayName property to ObservableTunnel with state-based suffixes: (Connecting), (Connected), (Not connected) - Update tunnel_list_item.xml to display the new displayName property - Create ic_stat_disconnected.xml with monochrome white fills for notifications - Fix notification icon in TunnelManager to use ic_stat_disconnected 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
|
AI generated PRs are not welcome. |
|
@msfjarvis I completely hear you. But hear me out: if you take a look at the implementation and you welcome the results (not necessarily the code as-is), then I would be willing to learn how to write Android code properly and make sure that this PR is as human as it gets. Behind "the AI" you're seeing are hundreds of hours of my work—troubleshooting, testing, and solving a real problem with the current app. This is genuine human effort, just not exerted at the coding level but at the problem-solving and architecture level. You may have felt insulted by my PR (because of the mischaracterization of human-AI collaboration in social media as machine-led rather than human-led), but I can be equally insulted by your quick dismissal of this vital improvement without even building and running the app. Please think about this before closing the PR without at least testing what it does. LLMs are tools intended to make our lives and software better. In this context, it allowed me to fix something I need critically in my practice, despite not having Android expertise (note: I'm an experienced programmer and software architect, just not in Android specifically). The fact I was able to prototype what I needed quickly doesn't insult you or mean the end result can't be valued—at minimum as a working demo of functionality that's genuinely missing from this app. This PR was born out of my 100% human contribution here: WireGuard/wireguard-tools#28, which solved the same problem for wireguard-tools when dealing with peers behind NAT+DynDNS. TL;DR: Please run the app and evaluate the concept. If you approve the functionality, I will re-implement it without using any LLMs—but I need your commitment not to dismiss it after I invest that time. My time is worth money, and I won't contribute 50+ hours only to be rejected anyway. If that's the outcome, I'll just maintain my patched version privately rather than contributing back to the community. Please make up your mind and let me know. Thank you.@msfjarvis I completely hear you. But hear me out, if you take a look at the implementation and you welcome the results (not necessarily the code), then I would be willing to learn how to write Android code and make sure that this PR is as human as it gets. Behind "the AI" you are describing are hundreds of hours of work from myself, troubleshooting and ensuring that this sound, this is real human effort not exerted at coding per se but a one that still counts as it is solving a real human problem with the current app. You may have felt insulted by my PR (because of the mischaracterisation of human-AI collaboration in social media as a machine led, rather than a human-led, process) but I can be equally insulted by your quick and thoughtless dismissal of this vital improvement to the app. Please think about this before you close the PR without at least building and running the app. I have attached two screenshots. LLM's are intended to make our life and to make our software better, and in this context it allows me to fix something that I need very much in my practice, but which I do not necessarily have the expertise to do (note that I am an excellent programmer and a software architect, but in this case have little Android knowledge). The fact I was able to prototype what I needed quickly does not come to insult you or necessarily mean that the end result cannot be honoured at least as a demo of what I personally needed and missed in this app. Please think about that before dismissing my PR. This PR was born out of my 100% human contribution here WireGuard/wireguard-tools#28 which allowed me to achieve reliable WireGuard connectivity when dealing with a Peer behind NAT+DynDNS. TL;DR: Please run the app and approve the concept of it and I will re-attempt without using any LLM's if this is what you would need to accept it, in which case I would ask for your commitment not to dismiss me once the code is written by me. My time is worth money and the last thing I would want to happen is contribute 50 hours only to be dismissed at the end by you. If this would happen then I would just use this patched version without contributing back to the community. Please make up your mind and let me know. Thank Screenshots
|
2 participants
Summary
This PR adds automatic DNS re-resolution for stale handshakes and comprehensive connection state monitoring with visual feedback. The implementation addresses connection reliability issues when peer endpoints change IP addresses due to DNS updates.
Key Features
Automatic DNS Re-resolution
Connection State Monitoring
Enhanced User Feedback
Log Viewer Improvements
Technical Implementation
Handshake Monitoring (
TunnelManager.kt):Backend.setState()Connection States (
ConnectionStateenum):DOWN: Tunnel is offCONNECTING: First 30s or waiting for initial handshakeCONNECTED: Active handshakes within 135sDISCONNECTED: No handshake after 30s, or stale handshakes >135sVisual Feedback:
Configuration
Added to Settings screen:
Testing
Tested with:
Commits
🤖 Generated with Claude Code