Mesh-on-LAN auf Offloader ausgefallen

Technik
1

Ich habe hier einen Offloader in Betrieb bei dem am 07.11. gegen 10:40 Uhr aus heiterem Himmel Mesh-on-LAN ausgefallen und nicht mehr in Gang zu bekommen ist.
Der Offloader sieht seine Nachbarn zwar noch (Verbindung sollte also OK sein), aber diese haben keinen Netzzugriff (Karte offline, nicht erreichbar, kein Internet).

Am gesamten Setup wurde nichts geändert. Ein Reboots aller Geräte hat nichts gebracht.

Inzwischen bin ich auf dem Experimental Gluon, was aber leider ebenfalls nichts geändert hat. Meiner Meinung nach sieht alles richtig aus …

# brctl show
bridge name             bridge id               STP enabled     interfaces
br-mesh_lan             7fff.821612d8e504       no              eth0
br-wan                  7fff.821612d8e500       no              eth1
br-client               7fff.001999749da1       no              bat0

# batctl n
[B.A.T.M.A.N. adv 2016.2, MainIF/MAC: primary0/82:16:12:d8:e5:03 (bat0 BATMAN_IV)]
           IF        Neighbor      last-seen
     mesh-vpn   2a:b1:99:71:2f:9f    3.630s
   br-mesh_lan   a6:2c:b0:ad:a5:32    0.700s
   br-mesh_lan   ee:09:6b:ec:3c:60    3.420s
   br-mesh_lan   a6:2c:b0:ad:a5:d6    3.360s
   br-mesh_lan   62:e4:27:9a:b6:b6    4.230s

Auf der Statusseite des Offloaders werden keine Nachbarn angezeigt:
http://[2a01:4f8:100:57ff:219:99ff:fe74:9da1]/

Ein Knoten hinter dem Offloader ist z. B.
https://map.ffrn.de/#!v:m;n:a42bb0ada5d6

Ich vermute ein Routing-Problem, aber komme leider nicht weiter. Wurde Netz-seitig etwas geändert, was könnte passiert sein und wo kann ich mit dem Debugging ansetzen?

(Das die Geräte hinter dem Offloader zwischendurch mal auf der Karte online waren liegt daran, dass ich Mesh-on-LAN deaktiviert hatte und die Knoten dann als Clients online gingen - aber ohne Internet mangels Mesh-on-VPN).

2

Läuft auf den Knoten hinter dem Offloader alfred?

Habe bei mir praktisch dasselbe Problem, meine Knoten hinter dem Offloader starten aus irgendeinem Grund alfred nicht und sind daher in der Karte unsichtbar. Clients kommen jedoch darüber ins Netz. Wenn ich alfred manuell starte, tauchen die Knoten in der Karte auf.

Mal einloggen und mit

ps w | grep [a]lfred

schauen ob alfred noch läuft. Falls nicht:

/usr/sbin/alfred -i br-client -b bat0 &
3

Der Knoten hinter dem Offloader ist nicht pingbar und auf die Statistikseite komme ich auch nicht.

Was sagt denn
batctl if

und

batctl o | grep br-mesh_lan

?

Seltsam ist dass laut Deiner Ausgabe batman die anderen Nodes zwar sieht, diese aber aktuell durch batman nicht anpingbar sind - sind sie abgeschaltet?

4

Von außen erreiche ich die Geräte nicht. Ich bin ausserdem gestern Vor-Ort nicht ins Internet gekommen.

Gegen einen defekten Alfred spricht ausserdem, dass sie auf der Karte erscheinen, sobald ich auf dem LAN-Port des Offloaders Clientnetz auswerfe. Dann gehen die Geräte als Clients des Offloader online und sind auf der Karte erreichbar (aber sind weiterhin nicht erreichbar, weil sie kein Mesh-on-VPN machen).

# batctl if  (Neue 0.6.1 Firmware)
mesh-vpn: active
br-mesh_lan: active
primary0: active

# batctl if (0.5.13 / Hier ist der Fehler zuerst aufgetreten)
mesh-vpn: active
eth0: active

Für mein Verständnis hat hier die mesh_lan-Brücke gefehlt. Mit dem Update auf 0.6.1 ist sie von selbst wiedergekommen. Aber wieso könnte sie gefehlt haben?

# batctl o | grep br-mesh_lan
[Kein Ergebnis]

Alle Zeilen von batctl o haben mesh-vpn als outgoingIF

Ja, sie sind angeschaltet und man bekommt auch eine WLAN-Verbindung.

5

Hier noch mal vom LB aus gepingt:

# batctl n
[B.A.T.M.A.N. adv 2016.2, MainIF/MAC: primary0/82:16:12:d8:e5:03 (bat0 BATMAN_IV)]
           IF        Neighbor      last-seen
     mesh-vpn   2a:b1:99:71:2f:9f    3.350s
   br-mesh_lan   a6:2c:b0:ad:a5:32    0.420s
   br-mesh_lan   ee:09:6b:ec:3c:60    3.060s
   br-mesh_lan   a6:2c:b0:ad:a5:d6    2.950s
   br-mesh_lan   62:e4:27:9a:b6:b6    4.600s

# batctl p 2a:b1:99:71:2f:9f
PING 2a:b1:99:71:2f:9f (2a:b1:99:71:2f:9f) 20(48) bytes of data
20 bytes from 2a:b1:99:71:2f:9f icmp_seq=1 ttl=50 time=32.21 ms
20 bytes from 2a:b1:99:71:2f:9f icmp_seq=2 ttl=50 time=32.02 ms

# batctl p a6:2c:b0:ad:a5:32
PING a6:2c:b0:ad:a5:32 (a6:2c:b0:ad:a5:32) 20(48) bytes of data
From a6:2c:b0:ad:a5:32: Destination Host Unreachable (icmp_seq 1)
From a6:2c:b0:ad:a5:32: Destination Host Unreachable (icmp_seq 2)
6

D.h., deine Knoten haben auf dem WAN-Interface sowohl Mesh als auch DHCP-Client laufen? Ist fastd deaktiviert oder aktiviert?

7

Ich habe via Config-Interface auf Routern hinter dem LoadBalancer folgendes eingestellt:

     Internet-Verbindung Nutzen (Mesh-VPN) aus
     WLAN-Mesh aus
     Nutzungart mesh-only
     Mesh-on-WAN an

Damit läuft der dhcp-Client vermutlich noch, ja. Aber am Offloader gibt es ja im Normalfall nur Mesh und bis Montag hat das auch einwandfrei funktioniert. :-/

8

Nein, sie hat nicht gefehlt. Stattdessen wurde direkt eth0 verwendet.

Der Unterschied zwischen den beiden Versionen ist dass in 0.6.1. eth0 in die Bridge gepackt wurde und dann die Bridge batman zugewiesen, anstatt direkt eth0. Beides geht und funktioniert. Letzteres ist etwas praktischer.

Ich kann den offloader über batman von außen anpingen, er hängt also korrekt am Netz.
Der Batman da drauf sagt (batctl n), dass er die anderen Nodes an br-mesh_lan sieht.
Er sagt aber auch (batctl o | grep …) dass er nicht weiss, wie er diese Nodes erreichen soll. Folgerichtig kann er sie dann auch nicht anpingen.
Ich vermute die Adressen sind bei batctl o nicht mit drin, also ein batctl o | grep a6:2c:b0:ad:a5:32 findet nichts?
Irgendwie scheint da was auf batman-Ebene schief zu laufen. Es kann nicht sein, dass er zwar die Nachbarn kennt die einen Hop entfernt sind er aber nicht weiß wie er die erreichen kann.

Was sagt denn batctl n und batctl o auf den Nodes?

Sind die Batman-Versionen unterschiedlich? Mein Node sagt:

batctl -v
batctl 2015.1 [batman-adv: 2015.1]

Der Offloader scheint aber 2016.2 zu haben? Sind die kompatibel?

9

Korrekt.

Gute Idee, aber das muss ich Vor-Ort testen. Vielleicht schaffe ich das später noch.

Ich glaube nicht, dass es daran liegt, denn der Fehler trat bereits mit der 0.5.13 aus stable auf. Die Installation von 0.6.1 experimental war nur der Versuch den Fehler zu lösen. Geändert hat sich an den Symptomen aber nichts.

Aber kann natürlich sein, dass es jetzt ein anderes Problem ist …

10

Sieht so aus als ob die Richtfunkstrecke zwischen Offloader und Switch ein Problem hat. Ein Router direkt am Offloader funktioniert ohne Probleme.

Aber schon eigenartig, denn dort sind 4 Nanostation Loco5 verbaut und symmetrisch konfiguriert und die eine Hälfte funktioniert. :-/

Zumindest ist jetzt erst mal Schluss mit Offloader und batman-Debugging.