Das Setup ist Standard, ohne Offloader, alle meshen Freifunk über WLAN. Alle Geräte verteilen das eigene Heimnetz per Wifi. Bei einigen habe ich noch die LAN-Ports mit dem WAN-Port gebridgt, damit ich lokal noch Geräte per Ethernet ins Heimnetz bringen kann.
Es gibt folgende Probleme:
Drei der Knoten waren in der Karte offline gekennzeichnet. Bei zweien habe ich ein Upgrade auf das Testing-Image der Community gemacht, was bei einem nur für ein paar Tage half, dann war er wieder offline. Es sind derzeit zwei Knoten offline.
Keiner meiner Knoten hat von der Kommandozeile Internetverbindung. Das war früher (letztes Jahr) einmal anders, meine ich. Ich kann also z.B. keinen autoupdater ausführen, außerdem laufen (evtl. wegen der fehlenden Möglichkeit, die Zeit zu stellen) die Uhrzeiten auf den Geräten größtenteils völlig aus dem Ruder:
root@sirius:~/freifunk# ./check_time.sh
ssh root@ff-1 date:
Sat Jun 15 09:44:52 CEST 2019
ssh root@ff-2 date:
Sat Mar 16 05:34:53 CET 2019
ssh root@ff-3 date:
Tue Mar 12 21:46:41 CET 2019
ssh root@ff-4 date:
Sun Mar 10 12:22:30 CET 2019
ssh root@ff-5 date:
Tue Jun 4 06:18:05 CEST 2019
ssh root@ff-6 date:
Wed Jul 3 08:45:19 CEST 2019
Was sonst noch so auffällt:
Die Router 2, 3 und 4 haben nur eine Link-Local ipv6 Adresse
Alle Router können den next_node per IPv4 anpingen
DNS löst auf keinem der FF-Geräte auf (connection timed out; no servers could be reached)
ping auf Google IPV4 8.8.8.8 ist kein Problem. Läuft gemäß traceroute über das Heimnetz
ping6 auf 2001:4860:4860::8888 geht auf keinem (allerdings habe ich im Heimnetz kein IPv6)
ip a show dev bat0 zeigt mir bei allen Geräten nur eine Link-Local Adresse (fe80…)
ip a show dev br-client gibt mir bei manchen Geräten (2, 3, 4) nur eine Link-Local Adresse, bei den Geräte 1, 5, 6 zusätzlich auch eine globale, wie im Web-Interface der Map auch angezeigt.
Knoten 3 hat keine globale IPv6, wird aber als online angezeigt.
Ich sehe keinen eindeutigen Unterschied zwischen den Geräten, die online angezeigt sind und den anderen …
Alle Geräte hängen mit dem WAN-Port in demselben 192.168.2.0/24 Segment und verteilen dieselbe SSID, auch völlig problemlos. Die FF-Router haben im DHCP-Server eine statische IP. Das Gateway ist ein Opnsense, der auch DHCP und DNS macht.
Nein geht auf keinem:
root@sirius:~/freifunk# ./check_ff_cmd.sh nslookup www.google.com
ff-1: ssh root@ff-1 nslookup www.google.com
;; connection timed out; no servers could be reached
ff-2: ssh root@ff-2 nslookup www.google.com
;; connection timed out; no servers could be reached
ff-3: ssh root@ff-3 nslookup www.google.com
;; connection timed out; no servers could be reached
ff-4: ssh root@ff-4 nslookup www.google.com
;; connection timed out; no servers could be reached
ff-5: ssh root@ff-5 nslookup www.google.com
;; connection timed out; no servers could be reached
ff-6: ssh root@ff-6 nslookup www.google.com
;; connection timed out; no servers could be reached
Gebe ich allerdings beim nslookup den Heimnetz-DNS (der auch per DHCP verteilt wird) an, ist die Auflösung kein Problem:
Das weiß ich ehrlich gesagt nicht. An den Standard-Einstellungen der Community-Images habe ich nichts gedreht. Wahrscheinlich ist es so wie du sagst, dass im FF-Client-Netz nur IPv6 vergeben wird.
Edit: Habe mal nachsehen lassen: Ein Freifunk-Client bekommt in der Tat auch eine IPv4 Adresse, aber auf den br-client Interfaces gibt es keine solche. Nur IPv6, wie oben beschrieben z.T. nur Link-Local und nicht Global.
Das ist auch das Standard-Szenario in Gluon.
Die DNS-Tests (ipv4) und traceroutes (z.B. zu 8.8.8.8) solltest Du von einem Client (egal ob wired oder wireless) am Freifunk-Knoten durchführen.
Meiner Vermutung hat der Supernode seine Verbindung zwischen „Batman-Gateway“ und „IP-Gateway/NAT/Router“(wie auch immer man das jetzt umschreiben mag) verloren.
Das kann sich dabei um zwei bis x verschiedene VMs oder Container in einer Virtualisierung handeln. oder schlicht um ein halb abgestürztes BatmanAdv-Kernelmodul, was nicht mehr auf das äußere Interface ausleitet, da die Routingtabellen kaputtgegangen sind.
(Vermutlich löst es irgendein Admin mittels „so lange rebooten bis es wieder läuft. Ursachenforschung zu aufwändig“.)
Umgekehrt gibt es Communities, die bei solchen latenten Problemen schlecht gewarteter/schlecht monitorter Supernodes einfach 4-7 Supernodes in die Domain stecken. Und bei Beschwerden den Tipp geben „Plasterouter rebooten“ (damit die Router sich dann mit etwas Glück einen anderen, funktionsfähigen Supernode suchen)
Und wenn es häufig notwendig ist, dann verfestigt sich die Illusion, dass der Freifunk schlecht laufe „weil die Router instabil seien“, und dass „bessere Router das Problem lösen“.)
Nach Hinweis eines Community-Admins habe ich das Sysupgrade-Image erneut eingespielt.
Ein Router war danach gleich wieder online sichtbar, er hat aber seine Config (z.B. Bridge WAN auf LAN-Ports) verloren. Ich kam aber über die IPv6 vom Client-Netz noch dran und habe ihn i.O. zurückkonfiguriert.
Der zweite 1043 war zwar nach Einspielen des Image auch wieder online, aber nach Umkonfiguration in einer Reboot-Schleife. Konfig-Modus ging nicht mehr. Per TFTP-Recovery über Stock-Image und neuem Freifunk-Image konnte ich ihn wiederbeleben.
Leider noch offen ist, dass von der Shell eigentlich nichts läuft, was DNS braucht, z.B.:
Das ist sehr schwer zu sagen, da Du damit mitten in der Diskussion „was ist Freifunk“ bist. Es gibt selbst unter den Communities die Gluon verwenden verschiendene Ansätze.
Aber nehmen wir mal an, es handelt sich um Gluon in der Standardkonfiguration:
Das ist genau so. Auf der Shell des Plasterouters geht IPv4 auf den WAN-Port. Und wenn dort nichts angeschlossen ist, dann eben halt gar nicht.