meldestelle/docs/ToDo/ToDo-Firewall_2026-7-5.md

🎨 [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).