So Leute. Endlich.

Habe mich gerade anhand weiter unten beschriebener Methode durch den täglichen Hoodkurzschluss delmenhorst <-> default02 gegraben. Mein Dank geht an Robin -- er weiß, wieso :) Die Ursache ist (aus Ursachenforschungsgründen immer noch, aber keine Sorge, das Symptom wird weiterhin per iptables auf dem default02.sn.ffn.de weggemacht) ein Kabelmeshrouter mit festgefahrenem hoodselector.

Konnte mich gerade noch zurückhalten, den Router zu fixen. bitte den Router erstmal in seinem Fehlerzustand belassen. Nicht rebooten, keine Kabel abziehen. wir wollen die Ursache für das Problem herausfinden. Habe mir erlaubt, Tareks sshkey auf dem Router zu hinterlegen, damit er sich das Problem mal live anschauen kann.

root@Wuesting-Raiffeisenstrae-I1:~# hoodselector The hoodselector is still running.

root@Wuesting-Raiffeisenstrae-I1:~# ls -l /var/run/hoodselector.pid -rw-r--r-- 1 root root 0 Sep 27 19:28 /var/run/hoodselector.pid

root@Wuesting-Raiffeisenstrae-I1:~# cat /tmp/hoodselector_error Command failed: Not found Command failed: Not found Command failed: Not found ifconfig: SIOCGIFFLAGS: No such device ifconfig: SIOCGIFFLAGS: No such device Command failed: Not found Failed to parse json data: unexpected end of data /usr/bin/lua: /usr/sbin/hoodselector:110: attempt to index local 'a' (a nil value) stack traceback: /usr/sbin/hoodselector:110: in function 'h' /usr/sbin/hoodselector:181: in function 'r' /usr/sbin/hoodselector:481: in main chunk [C]: ? root@Wuesting-Raiffeisenstrae-I1:~#

root@Wuesting-Raiffeisenstrae-I1:~# batctl gwl [B.A.T.M.A.N. adv 2017.2, MainIF/MAC: primary0/8e:83:b2:79:67:3b (bat0/84:16:f9:c8:ac:f2 BATMAN_IV)] Router ( TQ) Next Hop [outgoingIf] Bandwidth 52:15:c8:12:c6:a8 (251) 52:15:c8:12:c6:a8 [ mesh-vpn]: 59.5/32.3 MBit * ce:d3:06:0a:17:bf (179) 1a:e5:c9:ac:bb:58 [br-mesh_lan]: 1000.0/1000.0 MBit

das andere Ende des Kabels steckt im br-wan eines entsprechend konfigurierten Routers (Wuesting-Raiffeisenstraße-O2)

LG Lorenz

-------- Weitergeleitete Nachricht -------- Am 03.10.2018 um 12:06 schrieb lrnzo:

moin,

ich will dir die Idee kurz umreißen:

ssh -A FF_OS_Martinistr_Lager_10feedc260a2

den Welcome-screen erspare ich uns mal .... mit "batctl gwl" kannst du das bzw die Supernodes/Gateways eines routers sehen. Normalerweise ist dort ein Supernode aufgeführt. Eine gesunde Ausgabe sieht zb aus:

root@FF-OS-Martinistr-Lager:~# batctl gwl [B.A.T.M.A.N. adv 2017.2, MainIF/MAC: primary0/3e:ff:38:f1:d6:2b (bat0/10:fe:ed:c2:60:a2 BATMAN_IV)] Router ( TQ) Next Hop [outgoingIf] Bandwidth

• 82:f2:bd:50:be:33 (235) 0a:1d:84:d2:73:11 [ mesh0]: 1000.0/1000.0 MBit

nun kennt man also die MAC des BATMAN-Interfaces des Supernodes. Dieses kann man nun tracen:

root@FF-OS-Martinistr-Lager:~# batctl tr 82:f2:bd:50:be:33 traceroute to 82:f2:bd:50:be:33 (82:f2:bd:50:be:33), 50 hops max, 20 byte packets 1: 0a:1d:84:d2:73:13 7.091 ms 1.119 ms 2.687 ms 2: 82:f2:bd:50:be:33 30.561 ms 34.256 ms 33.654 ms

man sieht also die MACs der BATMAN-Interfaces der Mesh-hops bis zum Supernode, in diesem Fall einer. Nun habe ich mir mal die link-local Adressen meiner mesh-nachbarn angeschaut. Eine davon hat eine ziemliche Ähnlichkeit mit der MAC des nächste BATMAN-Hops in Richtung Supernode. Habe die Zeile mit nem Pfeil markiert.

root@FF-OS-Martinistr-Lager:~# ping ff02::1%mesh0 PING ff02::1%mesh0 (ff02::1%mesh0): 56 data bytes 64 bytes from fe80::3cff:38ff:fef1:d629: seq=0 ttl=64 time=0.467 ms 64 bytes from fe80::885:8ff:fe28:be31: seq=0 ttl=64 time=10.509 ms (DUP!) 64 bytes from fe80::cca6:51ff:fe65:a099: seq=0 ttl=64 time=13.085 ms (DUP!) 64 bytes from fe80::81d:84ff:fed2:7311: seq=0 ttl=64 time=13.697 ms (DUP!) <- 64 bytes from fe80::a889:48ff:fed0:d211: seq=0 ttl=64 time=14.859 ms (DUP!) 64 bytes from fe80::d05c:c1ff:fefe:40b9: seq=0 ttl=64 time=15.959 ms (DUP!) ^C --- ff02::1%mesh0 ping statistics --- 2 packets transmitted, 2 packets received, 10 duplicates, 0% packet loss round-trip min/avg/max = 0.467/7.148/15.959 ms

Aus 0a:1d:84:d2:73:13 wurde fe80::81d:84ff:fed2:7311. Die Bildungsvorschrift scheint zu sein:

1. und 6. Oktett (0a bzw 13) um 2 reduzieren (gibt 08, die führende Null verschwindet dann in der ::-Abkürzung, bzw 11), zwischen 3. und 4. Oktett ein "ff:fe" einfügen (wird meistens so gemacht, wenn man aus einer MAC eine v6 ableiten will, vergleiche mal die Primary-MACs in der map in den dort gelisteten v6-Adressen) und dann noch zwei benachbarte Oktett zu einem "hextett" (heißt das so?) zusammenfassen (zB 84:ff -> 84ff). und sieht da, man landet über diese linklocal-Adresse auf dem nächsten Hop Richtung Supernode.

root@FF-OS-Martinistr-Lager:~# ssh root@fe80::81d:84ff:fed2:7311%mesh0

root@FF-OS-Martinistr-84:~# batctl gwl [B.A.T.M.A.N. adv 2017.2, MainIF/MAC: primary0/0a:1d:84:d2:73:13 (bat0/10:fe:ed:f4:07:2a BATMAN_IV)] Router ( TQ) Next Hop [outgoingIf] Bandwidth

• 82:f2:bd:50:be:33 (254) 2e:65:38:c4:88:e2 [ mesh-vpn]: 1000.0/1000.0 MBit

in der Spalte outgoingIf steht nun auch mesh-vpn

Alles klar? Also Idee ist, mit "batctl gwl" und "batctl tr" die Fährte aufnehmen und sich dann von node zu node durchhangeln, bis man das ist, wo der falsche vpn-tunnel aufgebaut ist.

Sobald du startklar bist, würde ich auf dem default-supernode die Anschluss-ip entblocken (damit es eine Spur zum verfolgen gibt) und mit etwas Glück kommen wir mit deinem key ist zum fraglichen Router. zumindest können wir ihn auf diese Weise herausfinden.

LG Lorenz