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 …