Ausfall von drei Supernodes

Wenn der alfred auch den fastd-key mit übertragen würde, dann würde auch vieles andere sehr viel einfacher werden
(beim Blacklisting… Die Fälle werden zukünftig nicht seltener werden.)

Mein Vorschlag wäre nach wie vor eine „Not-Teilung“ der Rheinufer-Domain in z.B. Rheinturm, Aachen, Bergisches Land, Niederrhein. (Namen sind Schall und Rauch… irgendwie „in Viertel“ halt.)

Zum einen wird es so oder so früher oder später notwendig werden, zum anderen muss ja nicht ein Config-Fehler gleich in Halb-NRW die Lichter ausgehen lassen.

Um ein Splitting werden wir wohl nicht rumkommen, aber die momentane Situation würde auch bei kleinen Kollisionsdomänen arge Probleme verursachen.

Momentan suchen wir die Node „a2:f7:c1:48:cf:2a“
Diese spammt das Netz mit dem ICMP6 traffic zu:

14:36:45.977407 BAT 04:be:ef:ca:fe:07: BCAST, orig a2:f7:c1:48:cf:2a, seq 105893921, Warning - packet contains unknown ether type: 0x86dd

Diese MAC Adresse ist ja scheinbar nicht einmal ganz korrekt. Bzw finde ich keinen Hersteller dieser Hardware. Ist es möglich das Absicht hinter der Störung liegt?

Meine Nodes von tp-Link fangen ja mit C4 an.

Und per alfred meldet sich der nicht?

Kleinere Kollisionsdomainen würde so eine(r) trotzdem noch in den Untergang reißen. Klar.
Aber das wäre dann eine von z.B. vier. Die drei anderen könnten normal arbeiten.

Ich denke mal, dass es sich um irgendeine Form von virtueller hardware handelt (fastd-offloader…), bei deren Einrichtung etwas gewaltig schief gelaufen ist. Und dass der/die Betreiber gar nicht ahnen, dass es ihr Equipment ist, was da das Netz in den Abgrund reisst.

ca. 500m vom mir entfernt steht ein TP-Link TL-WR1043N/ND v1,
dessen Adressen beginnen mit a0:f3:c1: bzw. a2:f7:c1:
daher kann das durchaus ein (älterer) TP-Link Router sein.

1 „Gefällt mir“

Lässt sich der Traffic von der MAC-Adresse nicht irgendwie mittels iptables/ebtables über das Batman-Interface sperren?
Oder ist es da schon zu spät?

Deshalb ist unsere Idee dazu (für die wir nach lokalen Ressourcen suchen und bereits angefangen haben umzusetzen) die Domänen in sinnvolle Segmente (Community bis Kreisgröße) zu zerlegen.

Diese Idee ergibt jedoch erst dann noch mehr gesteigerten Sinn, wenn man die Arbeit, die hierdurch wieder anfällt, sinnvoll dazu nutzt, um zu bildende lokale Admin Teams gleichzeitig einzuweisen und möglichst schon auf lokaler Hardware die neuen Gateway Server dafür installiert.

Kein Unterfangen das nächste Woche fertig ist, zumal der Zuspruch bislang eher gering ist.

Ich habe zwar nur „Gefährliches“ Halbwissen, aber ist es nicht einfach möglich die IP von dem in den iptables auf DROP zu setzen? Notfalls sollte das ja auch über das WebIF vom Hoster laufen. Dort direkt über den Router sperren, oder wie man das Ding im Rechenzentrum auch nennen mag.

Ich gehe einfach mal davon aus das ihr das schon versucht habt. Doch geht es mir ja nur darum zu helfen.

Den gab es um den 1. Januar mal in ffnw (Freifunk-Nordwest)
http://webcache.googleusercontent.com/search?q=cache:EAxYoxc4UUcJ:netmon.freifunk-ol.de/show_crawl_data.php%3Fip_id%3D27641+&cd=3&hl=de&ct=clnk&gl=de
Mit Kontakt „nexthop“ „ae:ee:1a:b0:3d:12“

2 „Gefällt mir“

@bjo ping Kannst Du vielleicht irgendwas in alten Logfiles finden? Ich finde leider keine alte fe80er mehr, die dazu gehört.

Ich habe nun den Public Key der Node in den Supernodes gesperrt, warten wir mal ab :wink:

Wie hast Du ihn denn herausgefunden?
Bin nur neugierig :smile:.

Kleine Korrektur es handelt sich um: a2:f7:c1:4e:8a:e2
Die andere Mac ist wieder entsperrt.

Problem ist das diese Node keine direkte VPN Verbindung hat und sogar in der Wolke wo meine Node steht vorhanden ist, allerdings gibt es dort mehrere Uplinks.

root@Cyrus-Foxden01:~# batctl o |grep wlan0
fa:d4:12:61:c0:70   12.100s   (231) fa:d4:12:61:c0:70 [     wlan0]: 04:be:ef:ca:fe:00 ( 97) fa:d4:12:61:c0:70 (231)
12:01:ee:89:d2:aa    9.050s   ( 56) a2:f6:c2:4e:8a:e2 [     wlan0]: a2:f6:c2:4e:8a:e2 ( 56)
a2:f6:c2:48:cf:2a    8.430s   ( 53) a2:f6:c2:4e:8a:e2 [     wlan0]: a2:f6:c2:4e:8a:e2 ( 53)
a2:f6:c2:4e:8a:e2    0.490s   (143) a2:f6:c2:4e:8a:e2 [     wlan0]: a2:f6:c2:4e:8a:e2 (143)
a2:f7:c1:4e:8a:e2   40.050s   (135) a2:f6:c2:4e:8a:e2 [     wlan0]: 04:be:ef:ca:fe:00 ( 53) a2:f6:c2:4e:8a:e2 (135)

Das geht mittels des Fastd Status Sockets :wink:

Update:

Die Node ist direkter Nachbar von mir, ich vermute Hinterhof Linkes Zentrum die Node auf dem Dach:

Station a2:f6:c2:4e:8a:e2 (on wlan0)
	inactive time:	30 ms
	rx bytes:	682808149
	rx packets:	4339592
	tx bytes:	31225031
	tx packets:	309342
	tx retries:	193452
	tx failed:	0
	signal:  	-65 [-67, -72] dBm
	signal avg:	-66 [-67, -72] dBm
	tx bitrate:	27.0 MBit/s MCS 1 40MHz
	rx bitrate:	39.0 MBit/s MCS 4
	authorized:	yes
	authenticated:	yes
	preamble:	long
	WMM/WME:	yes
	MFP:		no
	TDLS peer:	no
1 „Gefällt mir“

Anscheinend gibt es auch hier bei der Mac-Adresse leichte Unterschiede:

Neighbor: a2:f 6:c2:4e:8a:e2

Logmeldung: a2:f 7:c1:48:cf:2a

Entschuldigung für das Durcheinander, kann langsam keine Mac Adressen mehr sehen :smiley:

1 „Gefällt mir“

Wen suchen wir den nun wirklich und wer sind die Nachbarn?
(Sorry, ich bin derzeit nicht in der Domain und komme mangels IPv6 auch auf keinen der Nodes. Bitte keine kryptischen BatCtl-Ausgaben, sondern einfach ein paar mac-adresse oder ggf. auch ULAs, nach denen gefahndet wird.)

Es sind zwei Nodes, daher auch meine Verwirrung mit den Macs:

  • a2:f7:c1:4e:8a:e2
  • a2:f7:c1:48:cf:2a

Beide sollten jetzt gesperrt sein

Auf die Gefahr hin, wieder die Diskussion um die „zentralen Strukturen“ zu bekommen:
Wäre es eine Option, eine zentrale (signierte?) MAC-blacklist zu führen, die auf die ebtables aller Nodes wirkt?

1 „Gefällt mir“