Wenn ein Kennwort, oder besser ein Schüssel hinterlegt wurde kannst du immer auf den Knoten von Überall auf der Welt (Voraussetzung dafür ist IPv6 Netzwerk)
Nein auch dauerhaft.
(Hier ein paar Beispiel Befehle, die ich mal zusammen geschrieben habe. Es gibt aber noch bedeutend mehr möglichkeiten Gluon Konsolen Befehle )
Im Configmode ohne PW, aber nur aus ›lokalen‹ Adressbereichen (IPv4: RFC1918, IPv6: ULA), im Meshmodus nur per (globalem) IPv6 und daher vorzugsweise per SSH-Key, da es kein fail2ban/ssh-guard gibt und somit unendliche Versuche möglich sind, das Password zu erraten.
Der Configmode ist prinzipiell ›nur‹ 'ne GUI für die Grundeinstellung (und man kommt per setup.4830.org auf die Weboberfläche des/der lokalen Knoten im Configmode). Wer weiß, was bzw. wie er (d/m/w) Parameter ändert, kann auch alles über die Kommandozeile tun, Dokumentation ist aber eher spärlich. Für einige Änderungen ist auch ein Reboot den Knotens notwendig.
Hey vielen Dank Leute. 
Das hilft mir wirklich sehr weiter.
Ich werde mich dann auch aktiv mit den FF-Knoten auseinandersetzen und die Beiden einmal neu aufsetzen um langfristigen Zugriff zu bekommen.
Mein Plan ist wie Thomas es beschrieben hat einfach den Update-Checker zu ändern.
Ich würde den auf alle 24 Stunden stellen. Ist mir egal ob die Kisten Nachts kurz offline sind. 
root@33378-a42bb0f43a87:~# cat /usr/lib/micron.d/autoupdater-wifi-fallback
16 3 9 9 * /usr/sbin/autoupdater-wifi-fallback
root@33378-a42bb0f43a87:~# ^C
root@33378-a42bb0f43a87:~# /usr/sbin/autoupdater-wifi-fallback
autoupdater-wifi-fallback: connectivity check failed
autoupdater-wifi-fallback: going to fallback mode
autoupdater-wifi-fallback: connecting to radio0 KreisGT.freifunk.net 7E:8A:20:28:73:CB
autoupdater-wifi-fallback: executing the autoupdater...
Retrieving manifest from http://firmware.ipv6.4830.org/experimental/sysupgrade/experimental.manifest ...
autoupdater: warning: error downloading manifest: Connection failed
autoupdater: error: no usable mirror found
autoupdater-wifi-fallback: going back to standard mode
root@33378-a42bb0f43a87:~#
Hier wie gestern abend gesagt, einmal die Ausführung des Fallbackmodes. Die Cron Einstellungen habe ich auf diesen Knoten schon geändert, so das er quasi nie ausgeühfrt wird.
Moin,
hier im Freifunkbereich Uelzen (außerhalb der Stadt UE) habe ich leider auch jede Menge Abbrüche. VPN-Verbindungen brechen alle 1-2 Stunden ab, und das schon seit Monaten.
Es wäre toll, wenn es bald eine Lösung gäbe… 
Wir werden uns das im Laufe der nächsten zwei Wochen noch einmal ansehen …
Moin,
gibt es wg. der dauernden Ausfälle/Abbrüche von Neuigkeiten?
Eine VPN-Verbindung wird aktuell ca. alle 30 Minuten unterbrochen…
Moin.
Ich habe hier zwei Screenshots von zwei Knoten, die über unterschiedliche Gateways rausgehen. Die Störungen sehen ziemlich synchron aus. Dies Ausfälle betrifft das ganze Mesh an der Müritz. 
Der Autoupdater ist deaktiviert.
Für normales Sürfen »kleines Problem«… für Webinare u.ä. sehr problematisch.
Viele Grüße aus der Müritz-Region
Matthias
Im Rahmen des heutigen Freifunktreffens haben wir (@igami, @Cord und @Klaus.P) uns dem Knoten-verliert-periodisch-Verbindung-Problem mal systematisch genähert.
Problem 1:
/sys/kernel/debug/batman_adv/bat0/gateway, was in unserem WiFi-Autoupdater genommen werden sollte, um die batman-Gateways anzupingen – vgl. Sourcecode – existiert nicht:
root@33330-FES70:~# cat /sys/kernel/debug/batman_adv/bat0/gateways
cat: can't open '/sys/kernel/debug/batman_adv/bat0/gateways': No such file or directory
Das ist schlecht, denn /usr/sbin/autoupdater-wifi-fallback wird stündlich aufgerufen und hat auch auf Offloadern ohne WiFi im Fehlerfalle einen Netzwerkneustart zur Folge. Denn wenn der Code meint, mit keinem Batman-Gateway verbunden zu sein, versucht er einen normalen Ping auf alle hinterlegten Updateserver. Bei 4830.org-Firmware ist das firmware.ipv6.4830.org.
Wenn ein klassischer ping auf eine der Adressen funktioniert, wäre der Code happy. Falls kein ping funktioniert hat, wird ein WiFi-Autoupdate getriggert — Geräte mit WLAN fallen vom Accesspoint- in den Stationsmodus und versuchen sich, zu allen empfangenen SSIDs mit ›Freifunk‹ im Namen zu verbinden und darüber ein Autoupdate zu machen, danach geht’s zurück in den AP-Modus, falls kein Reboot via Autoupdate erfolgt. Geräte ohne WLAN, also z. B. Offloader-VMs, machen dennoch einen Netzwerkneustart, d. h. die Verbindung zu den Gateways und zum lokalen Router entfällt und muß jeweils wieder aufgebaut werden, dies dauert insgesamt ca. 5 Minuten …
Und aus dem Internet als auch aus dem AS206813, also unserem eigenen Teils des Internets, war firmware.ipv6.4830.org nicht erreichbar, unser …
Problem 2:
Das IPv6-Subnetz, in dem die firmware.ipv6.4830.org-VM, wurde fälschlicherweise noch in meinen Keller in Gütersloh geroutet — denn da lief die entsprechende Hardware bis Anfang Februar.
Um es kurz zu machen – hat bestimmt bis hier schon ca. 45 Minuten gedauert –, dem Router bei mir im Keller wurde das Announcement des Subnetzes abgewöhnt (Hotfix) und siehe, es gibt noch ein …
Problem 3:
Denn nun stellt sich das interne Routing quer, 2a06:e881:1709:1111::/64, das besagte Subnetz, wird innerhalb des Autonomen Systems 206813 nicht korrekt geroutet
Dies nahm sicherlich weit über eine der insgesamt drei Stunden, die wir an dem Problem saßen, ein. Und eine wirkliche Lösung haben wir ehrlicherweise nicht gefunden.
Kernproblem: anders als bei IPv4, wo OSPF – soweit wir sehen – korrrekte Pfade auch ohne direkte Verbindungen zwischen den Routern erzeugt, werden bei IPv6 ohne direkte Verbindung OSPF-Phantasierouten erzeugt, konkret zu fe80-Adressen von Gateway-VMs, via VM-Bridge, die selbst weder diese Route ins OSPF exportieren noch mehr Wissen zur konkreten Route haben als »::/0 via fe80::1« (fe80::1 hat der Hypervisor/Router auf der VM-Bridge).
Was wir in der Analyse des IST-Zustands fanden, war ein dysfunktionaler Tunnel von IN-Berlin, blackstar, zu n@work, conquest, well die IPv6-Defaultroute in Routingtabelle 1 auf conquest fehlte (für IPv4 war sie existent). Nach dem Fix es Planzustandes funktioniert augenscheinlich generell das Routing, auch explizit von den Gateways aus:
root@ngw-fra05 ~ # ping -w2 -c1 -6 -I 2001:bf7:170:64::53 firmware.ipv6.4830.org
PING firmware.ipv6.4830.org(2a06:e881:1709:1111:0:57ff:fefd:bc94 (2a06:e881:1709:1111:0:57ff:fefd:bc94)) from 2001:bf7:170:64::53 : 56 data bytes
64 bytes from 2a06:e881:1709:1111:0:57ff:fefd:bc94 (2a06:e881:1709:1111:0:57ff:fefd:bc94): icmp_seq=1 ttl=57 time=26.8 ms
--- firmware.ipv6.4830.org ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 26.848/26.848/26.848/0.000 ms
root@ngw-ber01 ~ # ping -w2 -c1 -6 -I 2001:bf7:1310:144::46 firmware.ipv6.4830.org
PING firmware.ipv6.4830.org(2a06:e881:1709:1111:0:57ff:fefd:bc94 (2a06:e881:1709:1111:0:57ff:fefd:bc94)) from 2001:bf7:1310:144::46 : 56 data bytes
64 bytes from 2a06:e881:1709:1111:0:57ff:fefd:bc94 (2a06:e881:1709:1111:0:57ff:fefd:bc94): icmp_seq=1 ttl=57 time=14.4 ms
--- firmware.ipv6.4830.org ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 14.419/14.419/14.419/0.000 ms
Falls jemand noch Probleme sieht: bitte melden. Dito, falls jemand das OSPFv6-Thema erhellen kann …
Hallo zusammen,
erstmal vielen Dank für die Analyse des Ganzen.
Ich muss zu meiner Schande zugeben, dass ich das Freifunk für mich ehrlich gesagt etwas aufgegeben hatte.
Umso mehr freue ich mich, dass es hier ein Update bzw. offensichtlich eine Lösung zum Thema gibt.
Hier sieht es nun viel besser aus. Bis gestern sieht man die immer wiederkehrenden Abbrüche durch die waagerechten grünen Linien.
Hier der Usercount der letzten vier Tage.
Heute sind solche Abbrüche weder durch die Grafik noch durch die Nutzung bemerkbar.
Ich war heute mindestens 3 Stunden ohne Abbruch online.
Ich beobachte das nun ne Woche, doch aufgrund der ausführlich beschriebenen Analyse, bin ich mir sicher, dass der Fehler nun gefunden wurde.
Danke für die Arbeit daran.
Wünsch allen nen schönes Wochenende. 
Moin an alle,
auch hier bei mir im Mesh 24 läuft jetzt alles top, ich habe seit 24 Stunden keinen einzigen VPN-Abbruch.
Vielen Dank für die Arbeit.
Gruß aus dem Raum Uelzen,
Karsten
