[Freifunk-Bonn] Hood Köln läuft wieder, aber bitte lesen (temporary bans)

Sa Jan 23 17:51:18 CET 2021

Hallo,

heute nochmal in die ARP Broadcast geguckt. Einmal sieht man ein
"192.168.0.0"er Netz, "192.168.1.0"er Netz, ein eindeutiges FritzBox Netz
(192.168.178.0) und ein 172.217.0.0 Netz. Nicht gut.
Dann noch 169.254.0.0 (afair Auto self IP Windows (passiert wenn keine IP
zugeteilt wird). Dagegen kann man wenig machen.

Den Node mit dem FritzBox Netz dahinter habe ich nun geblacklisted, sorry.
Ich kann diesen Node leider auch nicht auf der Karte mit Kontaktdaten
finden.

Der Fastd Pub Key von dieser Node ist:
4e475e2caf48812a6533f6010d776cf48f640ff36f57dd3364e6ff39c1f11d86

Nochmal zum Hinweis: Checkt eure Konfigurationen!!! Steckt an die LAN Ports
nur Dinge an, wenn ihr wisst was ihr tut. Damit die Geräte auf den LAN
Ports meshen, muss man ZWINGEND im Configmode MeshOnLAN anschalten .
Ansonsten leakt ihr evenutell euer eigenes Netz.
Bitte lasst nicht andere IP Adressbereiche noch extra im Freifunk Layer 2
laufen.

Bitte auch nicht WLAN Repeater nutzen, oder sicher stellen, daß diese in
ihrer IP Konfiguration kein Gateway erwarten.

Warum sind unnötige, vor allem viele ARP Broadcasts schlecht für ein
Freifunk Netz: Diese Pakete werden an alle Nodes in der Hood gesendet (VPN
Serverlast) und gleichzeitig auf dem WLAN in einer niedrigen Datenrate
gesendet (es soll ja alle Clients erreichen können). Die nimmt wiederum
Airtime/Kapazität weg.

Vermutlich wird es bei Neuaufbau der Hoods/Firmware zu einer feineren
Unterteilung in Köln kommen müssen.

Unten stehend mal ein paar exemplarische Auszüge ohne Mac Adressen (tcpdump
-n "broadcast and  multicast" -i bat). Mit -e bekommt ihr auch die Mac
Adressen. Man beachte die Timestamps...

7:16:20.504694 ARP, Request who-has 10.158.40.190 tell 10.158.40.1, length
28
17:16:20.614724 ARP, Request who-has 192.168.178.24 tell 0.0.0.0, length 46
17:16:20.624710 ARP, Request who-has 192.168.178.35 tell 192.168.178.85,
length 46
17:16:20.636472 ARP, Request who-has 192.168.178.24 tell 0.0.0.0, length 46
17:16:20.653991 ARP, Request who-has 192.168.178.24 tell 0.0.0.0, length 46
17:16:20.686002 ARP, Request who-has 192.168.178.24 tell 0.0.0.0, length 46
17:16:20.705733 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request
from c0:4a:00:53:79:f3, length 300
17:16:20.730750 ARP, Request who-has 192.168.178.24 tell 0.0.0.0, length 46
17:16:20.780262 ARP, Request who-has 192.168.178.24 tell 0.0.0.0, length 46
17:16:20.811464 ARP, Request who-has 192.168.178.24 tell 0.0.0.0, length 46
17:16:20.821194 ARP, Request who-has 192.168.178.24 tell 0.0.0.0, length 46
17:16:20.833625 ARP, Request who-has 192.168.178.24 tell 0.0.0.0, length 46
17:16:20.890477 ARP, Request who-has 192.168.178.35 tell 192.168.178.85,
length 46
17:16:20.890521 ARP, Request who-has 192.168.178.24 tell 0.0.0.0, length 46
17:16:20.920713 ARP, Request who-has 192.168.178.24 tell 0.0.0.0, length 46
17:16:20.930985 ARP, Request who-has 192.168.178.24 tell 0.0.0.0, length 46
17:16:20.950445 ARP, Request who-has 192.168.178.24 tell 0.0.0.0, length 46
17:16:21.134905 ARP, Request who-has 192.168.178.35 tell 192.168.178.85,
length 46
17:16:21.273504 ARP, Request who-has 10.158.40.207 tell 10.158.40.1, length
28
17:16:21.420225 ARP, Request who-has 192.168.178.35 tell 192.168.178.85,
length 46
17:16:21.674542 ARP, Request who-has 192.168.178.35 tell 192.168.178.85,
length 46

LG und Sorry, gebt bescheid, wenn ihr wegen dem blacklisten Probleme sieht,
ich kann dies jederzeit auch wieder rausnehmen. Wie gesagt, habe noch nie
was geblocked ausser seit letzter Woche und mir ist da mega unwohl bei,

Rampone

On Thu, Jan 21, 2021 at 5:07 AM Ramon Waldherr <rampone at gmail.com> wrote:

> Hallo zusammen,
>
> ich bin mir immer noch nicht sicher, was es genau war, aber folgende fastd
> keys wurden geblacklistet, da diese ungewöhnlich Last erzeugt haben (und
> das habe ich nicht gerne gemacht, aber der Zustand des kaputt sein war
> schon länger):
> b2618e90aa160e63a6f8f8838e2ba78c15fd346ace10ea3745585aa4c50af67b
> 878e7fbcc9d9d585875afe9b2c7d14fa13f141086313d2c7f4d3d8a3c5346fdf
> 60bd864b7daf93452d2d26a7ceaa5b547ce4d4aa199212888ea2ed21cb761105
> b80a9906955e3469307eba020a77942de6bf8c8fa98e646c5c4f75de978d9f40
> f069c7a9ffc78ec941aba7ebe3f71fe6fae9c9e6fc5e57bda61f2980934fdc87
> 6c75c40ebb88ff01fd967b52d7b8588df1b1987c4df8d8f51e93b8842f729b45
> a249a29b52edcd129477ae10701006de88a11bc15997e7b51013c119cf0444f6
> 91b211317e18c34894b1c694e7d46d1f478544e7dd702075971e4947d9463a10
>
> Wenn einer seine Keys wiedererkennt (im Grunde alle in einer Telekom
> IP-Range), soll er sich bitte melden, ich würde gerne die Setups mit diesen
> Personen durchgehen (Welche Firmware? Selbst gebacken (batman originator
> interval?)? Wie angeschlossen, wieviele nodes dahinter, wie viele Clients
> etc.). Wenn wir das Problem geklärt haben, verschwindet auch die Node
> natürlich wieder von der Blacklist.
>
> Wieso habe ich diese Keys geblacklistet/gebanned:
> Immer nach Fastd Neustart knallt der fastd Daemon von Köln (~277 Nodes)
> auf hohe CPU Last, ohne das Nutztraffic da ist. Der fastd Daemon von Umland
> (~263 Nodes) idled ohne Traffic bei sub 10 Prozent.
> Auch jetzt nach dem Ban ist der Kölner daemon bei 20-25 Prozent.
>
> Also bin ich hingegangen und habe alle Nodes die in kurzer Zeit viele
> Packete und im Schnitt weniger Daten gesendet haben gebanned. Auffällig
> war, daß diese Nodes teilweise zweimal von der selben IP kamen.
> Die schlimmsten Ausreisser sind nun erstmal auf der Banliste, gefühlt gibt
> es auch noch den ein oder anderen Kandidaten, die irgendwie leicht komisch
> sind, aber um Faktor 3 weniger belastend als die obigen Nodes.
>
> Ich habe echt gerungen mit dem blacklisten, definitiv nicht ohne Bedenken
> getan, defacto war es aber unbenutzbar für alle in Hood Köln für afaik
> längere Zeit gewesen.
>
> Auf der anderen Seite wird es Zeit mal alles zu upgraden (neue
> Hoods/batman Version/wireshark, 802.11s, etc.), dürfte sich nur noch um
> Jahre handeln (und wenn es früher geschieht, doch auch schön ;).
>
> LG und wie gesagt: Die Nodebetreiber der Keys oben: bitte melden ;)
>
> Rampone
>
>
>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.kbu.freifunk.net/pipermail/freifunk-bonn/attachments/20210123/839fd8c7/attachment.htm>