lukas/nixos-config
Archived
1
0
Fork 1
Code Issues Pull requests Releases Wiki Activity
This repository has been archived on 2026-09-17. You can view files and clone it, but you cannot make any changes to its state, such as pushing and creating new issues, pull requests or comments.
nixos-config/docs/tnix-ssh-mango.md
pijukka d7698b26e7 docs(tnix): WLAN-Fehlschlag korrekt zuordnen, PSK-Verdacht war falsch 
Korrektur zu 7f54fb4. Ursache war nicht das Schluesselformat, sondern
zwei gleichzeitig auf wlan0 laufende wpa_supplicant-Instanzen: die
manuelle aus /tmp/iphone.conf und die per switch gestartete Unit. Das
Journal zeigt "SME: Trying to authenticate" gefolgt von "Authentication
request to the driver failed" und reason=CONN_FAILED -- der Treiber
lehnt ab, weil die Schnittstelle belegt ist. Ein falscher PSK ergaebe
WRONG_KEY, und ext_password_backend akzeptiert auch eine Passphrase von
8 bis 63 Zeichen, also greift der Verdacht auf pskRaw nicht.

Ob die Deklaration allein verbindet, ist weiter offen: nach dem Beenden
der Handinstanz blieb wlan0 DOWN, die neu gestartete Unit kam nicht mehr
ueber die Initialisierung hinaus. Vorgehen fuer den naechsten Versuch
steht jetzt als Reihenfolge im Dokument.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Aw4viUJyXGP8ANocHiF15q
2026-09-12 17:37:51 +02:00

4.1 KiB
Raw Permalink Blame History

tnix SSH ueber Mango

Stand: 12.09.2026. Vom iPhone erfolgreich bestaetigt.

ssh -p 2223 builder@ipv6-test.0ff.space

Mango leitet TCP 2223 auf tnix' Ethernet-SLAAC-Adresse fdee:3c40:44f0:0:ca5b:76ff:fe96:e24, Port 22, weiter. Vorher zeigte die Regel auf die nicht mehr vorhandene Mango-WLAN-Adresse von tnix.

Die gezielte SNAT-Regel tnix_ssh_return ersetzt globale IPv6-Quelladressen bei TCP 22 zu diesem Ziel durch Mangos LAN-Adresse fdee:3c40:44f0::1. Damit gehen SSH-Antworten ueber Ethernet zurueck, waehrend tnix den iPhone-Hotspot als Internetzugang behaelt. Im SSH-Log erscheint fuer diese Verbindungen Mango als Client.

Umsetzung: scripts/configure-mango-ipv6-ssh.sh mit HOSTS=tnix. Nur Firewall-Reload, kein Router-Reboot, kein Netzwerk-Neustart und kein NixOS-Rebuild. Pinix-Regeln unveraendert.

Validierung: fw4 check erfolgreich; Mango erreicht das Internet; oeffentlicher SSH-Login auf Port 2223 liefert tnix, Host-Key gegen den lokalen ED25519-Key geprueft; Nutzer bestaetigt Login vom iPhone.

Backup auf Mango: /root/ipv6-ssh-firewall-backup.CKoKpD/firewall. Fuer einen unmittelbaren Rueckbau diese Datei nach /etc/config/firewall kopieren und die Firewall neu laden. Spaetere Firewall-Aenderungen dabei nicht ueberschreiben.

WLAN deklarativ: gescheiterter Versuch am 12.09.2026

Der Versuch, tnix' Hotspot-Verbindung deklarativ zu machen, ist fehlgeschlagen und hat tnix vom Netz genommen:

wireless.networks.iPhone.pskRaw = "ext:psk_iphone";

Die Aenderung ist zurueckgenommen. Der Grund ist aber nicht die Konfiguration, sondern der Ablauf beim Umstellen -- das ist der eigentliche Merkposten.

Ursache: zwei wpa_supplicant-Instanzen auf wlan0

Die Verbindung lief zu diesem Zeitpunkt ueber eine von Hand gestartete Instanz (wpa_supplicant -B -i wlan0 -c /tmp/iphone.conf), weil wpa_supplicant.service gar nicht lief. Der switch startete die Unit zusaetzlich, und beide Instanzen hielten wlan0 gleichzeitig:

wlan0: SME: Trying to authenticate with ea:3b:f5:d2:bc:67 (SSID='iPhone' freq=5220 MHz)
wlan0: SME: Authentication request to the driver failed
wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=1 ssid="iPhone" auth_failures=1 duration=10 reason=CONN_FAILED

Die deklarative Instanz hat den AP also gefunden und die Authentifizierung angefordert; der Treiber hat sie abgelehnt, weil die Schnittstelle bereits belegt war. Das wiederholte sich dreimal mit steigendem Backoff, danach war das Netz temporaer deaktiviert.

Wichtig zur Abgrenzung: das ist kein Schluesselproblem. Ein falscher PSK ergibt WRONG_KEY bzw. einen gescheiterten 4-Way-Handshake, nicht Authentication request to the driver failed. Der zuerst naheliegende Verdacht -- pskRaw verlange den rohen 32-Byte-PSK, im Secrets-File liege aber eine Klartext-Passphrase (psk_iphone 9 Zeichen) -- trifft nicht zu: wpa_supplicant akzeptiert ueber den ext_password_backend auch eine Passphrase von 8 bis 63 Zeichen, und die Logzeilen belegen, dass es bis zur Authentifizierungsanfrage gekommen ist.

Was offen bleibt

Ob die Deklaration allein auf der Schnittstelle sauber verbindet, ist nicht erwiesen. Nach dem Abschiessen der manuellen Instanz blieb wlan0 DOWN, und die daraufhin neu gestartete Unit kam ueber Initialisierung und Regulatory-Domain nicht hinaus -- ohne einen einzigen weiteren Authentifizierungsversuch. Der Zustand war zu kaputt, um daraus etwas zu schliessen.

Vorgehen fuer den naechsten Versuch

  1. Ethernet zum Mango stecken. Schlaegt das WLAN fehl, ist der Hotspot sonst die einzige Uplink-Quelle und die Maschine isoliert.
  2. Erst die manuelle Instanz beenden, dann die Unit starten -- nicht beide gleichzeitig laufen lassen. pgrep -a wpa_supplicant vorher und nachher pruefen; es darf genau eine Instanz uebrig bleiben.
  3. Nach dem Beenden der Handinstanz wlan0 explizit hochholen (ip link set wlan0 up), bevor Schluesse aus einem DOWN-Interface gezogen werden.
  4. Erst wenn es dann noch scheitert, das Schluesselformat verdaechtigen und wpa_passphrase iPhone '<passphrase>' in secrets/wirelessSecretsFile.age hinterlegen.