[CallMeTechie]

Worum es geht

Aus dem App-Log (04.11., ~10:50–11:45): Dutzende UnknownHostException: DNS lookup failed for … (system DNS returned only VPN-internal addresses, no cache) und Connect-Timeouts von der Tunnel-Adresse 10.8.0.6 zur öffentlichen Server-IP. Dazu: Bilder per GateDrop an „FEC Laptop“ – sie kamen an, aber die App zeigte gar nichts, und der Verlauf („Geteilt“) war nicht zu finden.

1. Server bei aktivem Tunnel erreichbar (core/network)

Ursache: Der Server beantwortet seinen eigenen Namen im Tunnel absichtlich mit der Gateway-Adresse (dnsmasq host-record=<API-Host>,10.8.0.1, Split-Horizon, siehe entrypoint.sh des Servers): API-Verkehr eines getunnelten Clients soll über wg0 zu Caddy gehen. Die App selbst geht durch den Tunnel, wenn sie nicht per Split-Tunnel ausgenommen ist (WireGuard excludeApplications/includeApplications, es gibt keine automatische Ausnahme für GateControl). vpnSafeDns verwarf die VPN-Adresse trotzdem immer:

• ohne Cache (Neustart der App bei aktivem Tunnel, Always-on mit Sperre, Vor-Auflösung bei schon laufendem Tunnel) → jeder API-Aufruf UnknownHostException;
• mit Cache → Verbindung zur öffentlichen IP durch den Tunnel → Timeouts/ECONNABORTED von 10.8.0.6 (im Log).

Fix: VpnSafeDns (rein, getestet) entscheidet nach dem tatsächlichen Weg des eigenen Verkehrs:

• Standardnetz der App ist ein VPN (TRANSPORT_VPN) → VPN-Adresse zuerst, bekannte öffentliche Adressen dahinter (OkHttp Fast-Fallback probiert beide);
• App ausgenommen / kein Tunnel → VPN-Adresse verworfen; Auflösung über ein Netz außerhalb des VPN (Network.getAllByName, validierte Netze zuerst), dann Adressen dieses Laufs, dann die dauerhaft gespeicherten zuletzt bekannten öffentlichen Adressen (SharedPreferences, nur IP-Literale).
• clearDnsCache() beim Trennen vergisst nur den Lauf; die zuletzt bekannte Adresse bleibt als letzter Ausweg.

2. Connect-Timeouts / NAT64

OkHttp 5.5.1 mit Fast-Fallback (Happy Eyeballs) ist aktiv – im Log laufen IPv6 (64:ff9b::…) und IPv4 (192.0.0.4, CLAT) parallel (Suppressed). Beide Wege laufen über NAT64 des Mobilfunknetzes und scheiterten gleichzeitig nach 15 s; die Timeouts von 192.168.27.19 (WLAN) ebenso – der Server war von dort zeitweise nicht erreichbar. Kein App-Fehler, 15 s Connect-Timeout angemessen, daher unverändert.

3. GateDrop: Rückmeldung beim Senden und auffindbarer Verlauf

• Keine Rückmeldung: Beim Senden an Geräte/Personen (ohne Link) schloss sich das Blatt sofort mit einem kurzen Toast; danach gab es nur Mitteilungen (ohne Mitteilungsberechtigung: nichts; „Gesendet“ leise im Kanal geringer Wichtigkeit, nach 20 s weg). Jetzt bleibt das Blatt offen und zeigt Fortschritt („Wird gesendet … n %“, „An FEC Laptop“), dann „Gesendet – An …“ oder den Fehler. Schließen geht jederzeit, das Senden läuft im Worker weiter.
• Stilles Warten: War der Server nicht erreichbar (z. B. durch Punkt 1), wartete der Worker mit exponentiellem Backoff bis zu Stunden ohne jede Anzeige. Jetzt: Zustand Retrying im Blatt und Mitteilung „Noch nicht gesendet – GateControl versucht es von selbst erneut“ (wird durch „Gesendet“/„Nicht gesendet“ ersetzt).
• Nicht lesbare geteilte Dateien werden genannt statt still ausgelassen.
• Verlauf: Die Ansicht „Geteilt“ (Empfangen / Gesendet / Links) gab es, aber nur unter Einstellungen › „Teilen“ › „Geteilt“ – ohne das Wort GateDrop. Jetzt: Gruppe heißt „GateDrop“, und das Teilen-Blatt hat „Gesendet und Empfangen ansehen“ (auch nach dem Senden und im Fehlerfall).

Plugin-seitig (nur beschrieben, nicht geändert)

• targets.devices listet jede App-Installation (gc.devices.list), unabhängig davon, ob deren Client GateDrop kann; eine Zustellung über den Server wird bei online-Geräten als delivered markiert, auch wenn der Client sie nie abholt.
• transfers/<id>/result: Meldet der Empfänger ok bevor alle Teile eines Mehrdatei-Push angekommen sind und scheitert danach der Sender, gibt es keinen Ausweichweg mehr (Lieferung schon delivered). Hängt am Windows-Empfänger (meldet er erst nach allen Teilen?).

Tests

• VpnSafeDnsTest (13 Fälle: getunnelt/ausgenommen, Neustart ohne Cache, Auflösung außerhalb des VPN, gespeicherte Adresse, gemischte Antworten, Fehler der Netzabfrage, Literal-Speicherung)
• lokal: :core:network:testDebugUnitTest, :app:testDebugUnitTest (1640 Tests grün), :app:lintRelease

---

Generated by Claude Code