Gerade nochmal ausprobiert, jetzt läuft es wieder. 
Gleiche Symptomatik heute erneut.
Ping @PetaByteBoy @adorfer @Frank
Edit: ca. 3 Stunden später hat es sich von selbst kuriert, war vielleicht nur ein Fehlalarm? Nachdem wieder Neustarts aller Router keine Besserung brachten, habe ich einfach erstmal nur hier gepostet. Jetzt geht es wieder.
P.S.: Ist es eigentlich normal, dass ich vom reinen Mesh-Node aus keine IPv4-Adressen im Web anpingen kann? Das geht nämlich nach wie vor nicht.
ich sehe in bgl0 nichts, was nungewöhnlich wäre auf dem Supernode in den letzten 12h.
Da ist auch nichts gemacht worden in der Zeit.
IPv4 auf einem Router gibt es nur, wenn Du von Hand einen dhclient startest.
1 „Gefällt mir“
Update 20170515:
Auf allen Servern Updates gemacht, rebooted, neues batman-adv, batctl usw.
Edit 20170518:
RRH war nach dem Update ohne Verbindung aufgrund fehlerhafter Autostarteinstellungen (Copper) und nicht erfolgten Test direkt nach dem Update.
1 „Gefällt mir“
20170613
gl2 geupdated und letsencrypt erneuert
Sind wir um ein Jahr in die Vergangenheit versetzt worden?
Danke…
Zeit ist relativ…
Update 20170810:
Auf allen Servern Updates gemacht, rebooted, neues batman-adv, batctl usw.
2 „Gefällt mir“
Update 20170918:
Auf allen Servern Updates gemacht, rebooted, neues batman-adv, batctl usw.
Update 20170927:
Check_MK Agent 1.4.0p8-1 auf allen VM’s, Konzentrator und Copper (Blech) installiert;
Gdebi auf Copper-Kon und Copper installiert.
Offen: Check_MK auf Silver (Blech)
20171004
Zertifikate auf den Blechen (Silver und Copper) erneuert
1 „Gefällt mir“
20171024
Heute Nacht gab es einen Hardreboot von Silver (2:17 Uhr) laut SoyouStart/OVH.
Auf bgl0 war die dhcpd.leases zu groß, sodaß der DHCP Server nicht automatisch startete.
dhcpd.leases gelöscht, reboot, alles gut…
Daher re-starten einige Leute den isc-dhcp per cronjob, denn außer per echtem Restart räumt der leider nicht auf.
Nein, es ist ein permission issue. Auch dokumentiert: isc-dhcp-server - Community Help Wiki
Es reicht aber eben nicht einfach der dhcp.leases Datei die nötigen Rechte zu geben, wie das hier anscheinend getan wurde. Die noch aktiven Leases werden in eine neue Datei kopiert, und dann als atomare Aktion auf die alte dhcp.leases verschoben. So gibt es keine inkohärenten Zustände. (Siehe auch)
Das macht der DHCPd auch einmal pro Stunde. Die Sache ist, dass es beim Restart halt klappt, weil der da noch nicht seine Rechte gedroppt hat und als Root läuft. (Siehe auch, man beachte: db_startup() kommt vor setuid())
Wenn ihr mir nicht glaubt lasst den halt mal mit strace laufen und schaut nach einer Stunde wo die Syscalls fehlschlagen.
Das ganze ist übrigens ein Distributor-Problem (kaputtes AppArmor-Profil), tritt also ausschließlich bei Ubuntu auf und ist in der aktuellen LTS gefixt. Migrationen funktionieren jedoch laut Bugreport nicht so gut. Also vermutlich einmal purgen und reinstallieren.
Und das Problem sollte eigtl Prio haben, da ein so kaputter DHCP nicht vereinbar mit dem BDSG ist, welches eine Speicherung der IPs für maximal 7 Tage über die technische Notwendigkeit hinaus erlaubt.
1 „Gefällt mir“
8:05 Uhr Ausfall von Eulenfunk-GL (LLN, ODE, BCD, RRH, BGL) durch Ausfall bei OVH, unserem Hoster der Gateways.
10:39 Uhr Link zum Standort unserer GWs (RBX) ist wieder aktiv, unser Netz läuft wieder
1 „Gefällt mir“
Update 20171114:
Auf allen Servern Updates gemacht, rebooted, neues batman-adv, batctl usw.
20171228:
gl2 geupdated und letsencrypt erneuert
20180202:
Ausfall der Namensauflösung auf ffgl.eu
(Alle Router sowie Kartenserver nutzen daruf basierende DNS-Einträge, um die Supernodes zu finden).
Gelöst seit 18.36 Uhr, das Netz stabilisiert sich.
ToDo: Redundanz herstellen
1 „Gefällt mir“
Map-Server down.
Präziser: er ist nicht down (Animation „Lade Karte & Knoten…“ erscheint), führt aber nach einer Weile nur zur Anzeige der Meldung „Error: Network Error“
[edit] 3 Stunden später: geht wieder.