feat(desktop, network): Fehlerhandling verbessert, Tools-Menü erweitert und mDNS-Discovery optimiert
Signed-off-by: Stefan Mogeritsch <stefan.mo.co@gmail.com>
This commit is contained in:
@@ -0,0 +1,37 @@
|
||||
---
|
||||
type: Journal
|
||||
status: ACTIVE
|
||||
owner: Curator
|
||||
last_update: 2026-05-07
|
||||
---
|
||||
|
||||
# 2026-05-07 — Session Log (Frontend Networking, Discovery, Connectivity)
|
||||
|
||||
## Kontext
|
||||
- Fokus: Stabilisierung der lokalen Host/Client‑Kommunikation (mDNS, WS‑Chat), robuste Connectivity‑Checks, UX für Backup‑Pfad, Session‑Abschluss mit Dokumentation.
|
||||
|
||||
## Summary
|
||||
- ConnectivityCheck robuster gemacht (Fallbacks, schneller Erstcheck) und Logs (Base‑URL, WS‑Port) korrigiert.
|
||||
- Discovery/Registration zentralisiert und entdoppelt; Interface‑Bindung und Logging verbessert.
|
||||
- Datei‑Picker auf `JFileChooser` umgestellt; editierbares Pfadfeld mit Validierung integriert.
|
||||
- Firewalld/mDNS‑Ursache für fehlende Sichtbarkeit zwischen Host/Client identifiziert und als ToDo/Guide dokumentiert.
|
||||
|
||||
## Changes
|
||||
- ConnectivityTracker: Fallback‑Kaskade readiness → health → /api/ping/simple; Intervalle angepasst; Debug‑Logs ergänzt.
|
||||
- main.kt: korrekte String‑Interpolation; Start‑Log der `NetworkConfig.baseUrl`; WS‑Port 8090 konsistent.
|
||||
- JmDnsDiscoveryService: Interface‑Filter (ohne docker/br/veth, private IPv4 priorisiert), Debounce/De‑Dup der Registrierung, Log‑Noise reduziert.
|
||||
- Navigation: Guard gegen Navigation auf gleichen Screen; Top‑Bar Tools erweitert (Reset/Backup/Settings‑Ordner öffnen).
|
||||
- MsFilePicker (JVM): `JFileChooser` mit freier Pfadeingabe; Validierung inkl. Schreib‑Probe; automatische Ordnererstellung bei Auswahl.
|
||||
- conveyor.conf: JVM‑Flag `--enable-native-access=ALL-UNNAMED` ergänzt (Netty‑Warnung mitigiert).
|
||||
|
||||
## Verification
|
||||
- Build (Gradle): erfolgreich ✓
|
||||
- Laufzeit/Netzwerk: Verifikation ausstehend (mDNS nach Firewall‑Freigaben; KDE‑Picker unter Fedora 44; Host/Client‑Sichtbarkeit LAN/WLAN) — Anti‑Halluzinations‑Protokoll beachtet.
|
||||
|
||||
## Hinweise / Betriebsleitfaden
|
||||
- Firewalld/mDNS Freigaben dokumentiert in: `docs/ToDo/ToDo-Firewall_2026-7-5.md` (mdns + Ports 8090/8080; Reload/Kontrolle; Avahi/Tcpdump Checks).
|
||||
|
||||
## Nächste Schritte
|
||||
1. KDE‑Directory‑Picker: auf `OPEN_DIALOG` im `DIRECTORIES_ONLY`‑Modus wechseln; präzisere Fehlermeldungen; HOME‑Fallback.
|
||||
2. Guard gegen mehrfachen P2P‑Start ergänzen.
|
||||
3. Conveyor/Windows‑Installer in CI (Runtime‑Flags; optional SLF4J‑Binding), danach erneute Laufzeit‑Verifikation.
|
||||
@@ -0,0 +1,72 @@
|
||||
🎨 [Frontend Expert]
|
||||
|
||||
### Kurzfazit
|
||||
- Die beiden Rechner sehen sich über mDNS höchstwahrscheinlich wegen Firewall‑Regeln/Zonen nicht. JmDNS registriert korrekt auf 192.168.0.124:8090, aber der Client (192.168.0.167, WLAN) empfängt keine mDNS‑Antworten → Fedora/Firewalld blockiert UDP 5353 Multicast in der aktiven Zone (WLAN/Public) sehr häufig standardmäßig.
|
||||
- Der Datei‑Picker unter Fedora KDE hakt im Verzeichnis‑Modus vermutlich wegen der Kombination DIRECTORIES_ONLY + SAVE_DIALOG und/oder wegen unserer „schreibbar“-Validierung.
|
||||
|
||||
### Sofortmaßnahmen (auf beiden Geräten, Host + Client)
|
||||
1) Firewalld freischalten (mdns + Ports) und neu laden
|
||||
```
|
||||
sudo firewall-cmd --get-active-zones
|
||||
# notieren, in welcher Zone das aktive Interface liegt (z. B. public, home)
|
||||
ZONE=public # ggf. anpassen
|
||||
|
||||
# mDNS erlauben (UDP 5353 Multicast)
|
||||
sudo firewall-cmd --zone=$ZONE --add-service=mdns --permanent
|
||||
|
||||
# unsere Dienste öffnen
|
||||
sudo firewall-cmd --zone=$ZONE --add-port=8090/tcp --permanent # WS-Chat
|
||||
sudo firewall-cmd --zone=$ZONE --add-port=8080/tcp --permanent # P2P-Server (PoC)
|
||||
|
||||
# Regeln anwenden
|
||||
sudo firewall-cmd --reload
|
||||
|
||||
# Kontrolle
|
||||
sudo firewall-cmd --zone=$ZONE --list-all
|
||||
```
|
||||
Hinweis: WLAN und Ethernet können in unterschiedlichen Zonen liegen (z. B. public vs. home). Bitte in beiden relevanten Zonen freischalten.
|
||||
|
||||
2) Optional: Avahi als Indikator prüfen (nicht zwingend für JmDNS, aber gut für mDNS‑Baseline)
|
||||
```
|
||||
systemctl status avahi-daemon
|
||||
```
|
||||
|
||||
3) mDNS‑Pakete verifizieren (nur wenn es nach 1) noch nicht klappt)
|
||||
```
|
||||
# Auf dem Client (WLAN‑Interface anpassen):
|
||||
sudo tcpdump -n -i wlp0s20f3 port 5353
|
||||
# Auf dem Host (Ethernet‑Interface anpassen):
|
||||
sudo tcpdump -n -i <eth-iface> port 5353
|
||||
```
|
||||
Erwartung: Bei App‑Start siehst du Multicast an 224.0.0.251. Wenn auf einer Seite „Stille“ herrscht, blockiert noch etwas.
|
||||
|
||||
4) WS‑Konnektivität direkt testen (um Networking unabhängig von mDNS zu prüfen)
|
||||
```
|
||||
# vom Client auf den Host
|
||||
websocat ws://192.168.0.124:8090/chat
|
||||
# oder wscat: wscat -c ws://192.168.0.124:8090/chat
|
||||
```
|
||||
Wenn das klappt, ist der WS‑Pfad ok; dann bleibt nur mDNS/Firewall als Ursache.
|
||||
|
||||
### Erklärung zu deinen Logs
|
||||
- „[Discovery] Dienst 'fedora-stefan' … (Port 8090)“ → Host hat korrekt via mDNS veröffentlicht.
|
||||
- „Discovery Update: 0 Dienste gefunden“ am Client → keine mDNS‑Antworten angekommen (typisches Firewall‑Symptom bei Fedora/KDE, vor allem in Zone „public“).
|
||||
- Mehrfach „[P2P Server] Gestartet auf Port 8080“ → Wir haben noch einen Trigger, der den P2P‑Start mehrfach feuert. Funktional unkritisch für den aktuellen Befund; ich bereinige das im nächsten Patch mit einem zusätzlichen Guard.
|
||||
|
||||
### Fedora KDE Datei‑Picker (JFileChooser) – Workarounds jetzt, Fix als Patch im Anschluss
|
||||
- Mögliche Ursache 1: `SAVE_DIALOG` im Ordner‑Modus unter KDE verhält sich zickig. Besser: `OPEN_DIALOG` im `DIRECTORIES_ONLY`‑Modus + eigener Bestätigungs‑Button‑Text.
|
||||
- Mögliche Ursache 2: Unsere Validierung „Ordner existiert und ist beschreibbar“ verhindert die Übernahme (z. B. externer Stick nur lesbar, NTFS ohne Schreibrechte, Netzwerkpfad ohne Rechte). Teste bitte einmal mit einem lokalen Pfad wie `~/MeldestelleBackup`.
|
||||
- Quick‑Test jetzt: Tippe im editierbaren Feld manuell `~/MeldestelleBackup`, bestätige → sollte grün werden. Falls rot: bitte den Text der Fehlermeldung nennen.
|
||||
|
||||
Geplanter Fix (nach deiner Bestätigung):
|
||||
- Directory‑Picker: Wechsel auf `showOpenDialog(null)` mit `JFileChooser.DIRECTORIES_ONLY`, `approveButtonText = "Auswählen"`, `acceptAllFileFilterUsed=false`. Fallback auf HOME, wenn `currentDirectory` ungültig. Beibehalt der freien Texteingabe.
|
||||
- Validierung: Fehlermeldung präziser („existiert nicht“ vs. „keine Schreibrechte“) und angebotene Auto‑Erstellung, wenn der User bestätigt.
|
||||
|
||||
### Bitte liefere kurz zurück
|
||||
- Nach Schritt 1 (firewalld): Finden sich Host (192.168.0.124) und Client (192.168.0.167) gegenseitig? Tauchen Services in der UI/Logs auf?
|
||||
- Falls noch nicht: kurzer Ausschnitt aus `tcpdump` beider Seiten (je 3–5 Zeilen genügen).
|
||||
- Datei‑Picker auf dem Client: Was passiert bei manuellem Pfad `~/MeldestelleBackup`? Erscheint eine Fehlermeldung? Wenn ja, welcher Text?
|
||||
|
||||
### Nächste Schritte (nach Feedback)
|
||||
- Ich liefere: Patch für den KDE‑Picker (OPEN_DIALOG) und einen zusätzlichen Guard gegen mehrfachen P2P‑Start; außerdem noch etwas Discovery‑Logging (Interface/Zonen‑Hinweis).
|
||||
- Danach kümmern wir uns um Conveyor (Windows‑Installer aus CI, inkl. JVM‑Flag gegen die Netty‑Warnung).
|
||||
Reference in New Issue
Block a user