6:32 a.m.
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