Firmware für dezentrales Netz


#1

Hi,

wenn ich für ein Freifunk Netz eine Firmware einer beliebigen Freifunk Community wählen könnte, die möglichst dezentral funktioniert, welche würde ich nehmen?

Hintergrund: Es wird eine neue Firmwäre benötigt um aktuelle Router zu unterstützen. Dabei würde ich gerne eine etablierte nehmen und diese verbessern (dem Open Source Gedanke folgend) und nicht selber von Grund auf etwas neues bauen.

Der Wunsch nach Dezentralität kann vielfältige Ursachen haben, in meinem Fall ist es aber ein ganz praktischer. Der Administrationsaufwand bei laufendem Betrieb soll möglichst gering sein. Dafür würde ich höheren Aufwand beim Einrichten eines Routers (z.B. IP irgendwo händisch eintragen) in Kauf nehmen, bzw. auch bei der Benutzung (z.B. verschiedene SSIDs).

Bei meiner Recherche habe ich bisher gefunden, dass es mehrere Initiativen zu dem Thema gibt:

  • Freifunk Dresden: Hört sich sehr dezentral an, ich bin mir aber nicht sicher ob es Sinn macht bei einem Neuanfang ein Routing-Protokoll zu nehmen (bmxd) das nicht mehr weiterentwickelt wird.
  • Freifunk Frankfurt am Main: Experimentieren mit Babel. Könnte ein Kandidat zum “Aufspringen” sein.
  • Freifunk Köln, Bonn und Umgebung: Experimentieren auch mit Babel, da ist mir der aktuelle Stand nicht ganz klar.
  • Freifunk Rostock: Die Opennet Initiative Firmware nimmt OLSRv1, also auch dezentral. Allerdings ist es ein bisschen schwer zu sehen wie der Stand so ist (auch mit Umstellung auf OLSRv2).

Sollte ich was übersehen habe oder jemand Erfahrungen/updates haben, würde ich mich freuen.

Cheers,
Volker


#2

hi

https://wiki.freifunk-franken.de/w/Dezentrale_Hood

hast du vergessen :wink:

https://monitoring.freifunk-franken.de/map?mapcenter=49.47214,11.01448,12

Alle blauen Linien verbinden sog. dezentrale Hoods. Es lohnt sich auch auf das #18fff zu kommen, das ganze wird dort bestimmt auch Thema werden

Ich muss allerdings zugeben, eine richtig fertige Firmware gibts noch nicht. Einige “hingebastelte” Sachen haben wir allerdings:

https://wiki.freifunk-franken.de/w/Gatewayfirmware

mfg

Christian


#3

Hi,

richtig dezentral bedeutet in meinen Augen eigentlich, dass Netzbereiche
einfach autonom weiterlaufen, wenn die verbindung zu Servern wegfällt.
Die Freifunknetze, die ZENTRAL für eine Stadt 1-3 Gateways mit DHCP für
clients (Endnutzer) bereitstellen, sind nicht mehr dezentral.

Layer2 (also übergrosse Switche) haben dazu noch ein
echtes schwerwiegendes DATENSCHUTZ Problem.
Denn bei einem Portscan auf einem Client, können in einer
Freifunk-Community ALLE anderen Nutzer gefunden werden.
Wir haben das mit glueon vor einiger Zeit getestet
(über 1500 Nutzer konnten wir so mit deren MAC sehen und
auf deren offenen Ports und Dienste zu greifen).

In Dresden haben wir einen einfachen aber bewerten Aufbau.
Jeder Router kann mit seiner Firmware bereits ein unabhängiges
Freifunk Netz aufbauen.
Die einzige Abhängigkeit besteht darin, dass jeder Knoten eine
eindeutige Knotennummer benötigt, von der die IP Adresse des
Routers berechnet wird.

Unser Netz besitzt dazu einen “Registrator”, der es jedem Knoten
automatisch erlaubt, eine solche Knotennummer zugeteilt zu bekommen.
Ist dieser nicht erreichbar, wird aus einem reservierten Bereich eine
zufällige Nummer generiert (damit der Knoten erstmal funktioniert und
es keine IP Konflikte gibt). Sobald der Registrierungsserver
(evt. über Nachbarknoten) erreichbar ist, erhält der Knoten seine
Nummer und damit seine IP.

Jeder Knoten hat die gleiche Funktionalität wie ein Server
(ausser dass der Server kein WLAN hat).
Dadurch ist es einfach einen eigenen Server aufzubauen.
Knoten können sich mit diesen verbinden, um einfach dem Netz beizutreten.
Sind aber eigentlich nicht notwendig, da die Knoten sich untereinander via
Dyndns/Internet direkt verbinden können.

Dresden hat aktuell ca 15 Server und insgesamt etwa 21 Gateways.

Die Firmware beinhaltet alle Funktionen. Router mit 8MB flash können openvpn einfach nachinstallieren und ein zertifikat einspielen.
Damit sind diese automatisch selber Störerhatungssichere Gateways.
Ich würde vermuten, dass das den “Hoods” in Franken entspricht.
Aber auch ein 4MB Router kann als Gateway arbeiten, entweder direkt (ohne Störerhaftung)
oder via einem vorgeschalteten Rechner, der gegen die Störerhaftung absichert.

Jeder Knoten vergibt in einem extra IP Bereich via eigenem DHCP IP Adressen an den Client.
Gateways und DNS werden durch das routing protokoll gesetzt und nutzen dabei Leitungsqualitäten zur ständigen Anpassung.
Das hat aber auch einen Nachteil, da eine Verbindung unterbrochen werden kann wenn auf ein anderes Gateway gewechselt wird (ein bevorzugtes Gateway kann aber konfiguriert werden).

Layer2 ist für ein solches Netz eigentlich garnicht benötigt. Denn aus unserer Erfahrung wird Roaming garnicht gebraucht. Geräte merken sich die bereits verwendeten Knoten und verbinden
sich automatisch. Hat den Vorteil, dass diese sich nicht automatisch anderorts unbewusst
verbinden und so unötigen undbenutzen Traffik erzeugen. Und wir werden nicht so schnell
“vergessen” da die Leute immer wieder nach “Freifunk” wifi scannen :wink:

Die Firmware in Dresden nutzt bmxd. dieses ist die “expermimentelle” Variante, da diese einige Funktionalitäten bezüglich verschiedener Routingtablellen unterstützt. Es wird vom Author nicht mehr weiterentwickelt, da es die Funktionen ausführt, die es machen soll. Alles was meistens
als Weiterentwicklung angesehen wird, ist dass Programme immer mehr können und damit größer werden. Auch wenn nix davon benötigt wird.
Wir haben allerdings einige Bugfixes einpflegen müssen, damit es stabil läuft. Und wir haben einige ungenutzte Funktionen ausgebaut, um dieses Protokoll klein und schneller zu bekommen.
Leider gibt es aber noch keine “kernel-modul” Lösung für den Upload. Damit ist der Datendurchsatz im Upload begrenzt. Aber es ist eh meist der Download gefragt :wink:

VG Stephan


#4

Hallo ddmesh,

gehört dazu ist in meinen Augen aber noch nicht alles:

Dieser “Registrator” hört sich für mich nach einen recht zentralen Punkt an, auch wenn er anscheinend optional ist (wenn ich es richtig verstehe) ist er dennoch erstmal “zentral” oder?

Grundsätzlich ist mir an der dezentrlität auch noch wichtig, das jeder sein Netz so bauen kann, wie er möchte. Es sollte nahezu nichts (bis aufs PPA vielleicht) vorgegeben werden. Es sollte technisch jedem selbst überlassen sein was er baut und nicht die Community was vorgeben was man machen muss (was leider sehr oft der Fall ist). Freifunk ist auch irgendwo noch ein Experiementiernetz und das sollte man den Leuten zugestehen

jein, wir haben eine “Spezialfirmware” die das gleiche kann wie eure aber halt Babel statt bmx (ohne Registator, man muss IPs, Peerings und Kram manuell rein klopfen bzw. über ein Script), die ist aber optional (aber besser weil schneller und dezentral) wer das nicht nutzen will, kann unser “altes” übliches Netz nutzen, Knoten anschließen, macht Batman und dann sehr ähnlich zu Gluon. Wir bieten also beides an. Ich nenne diese “Standartknoten” immer gerne “Tante Emmas Knoten” da sie bei “Tante Emma die sich mit dem Zeug nicht beschäftigen will hinter dem Sofa stehen können”.

Jeder Router mit “Spezialfirmware” ist eine eigene “Hood” genauso ist das zentrale “alte” Zeug auch nochmal in Hoods unterteilt (pro Hood 2 Gateways)

https://monitoring.freifunk-franken.de/map?mapcenter=49.45000,11.10000,10

wenn man rechts oben über den Papierstapel fährt, kann man sich recht gut das Zeug ein/ausblenden wobei v1 noch viel älter ist und aktuell am aussterben ist. Mit v2 hat man im Hoodaufbau viel Zeug behoben das früher falsch war z.b. gleiche SSID, gleiche MeshID usw. zudem wenn man eh kompatibiltät bricht, auch auf neues Batman und so geupdatet. “Local Routers” ist dann unser “Spezialfirmware” von der ich hier spreche.
Da wir keinen Autoupdater haben (und auch nicht wollen, jeder soll für seinen Kram selbst verantwortlich sein und nicht 2 oder 3 Leute 3000 Knoten updaten, aber das isn anderes Thema wobei das auch irgendwie zur dezentralität dazu gehört), läuft halt vieles pararell bis die Leute geupdatet haben.

kann ich nur so bestätigen, kein Mensch braucht ein Roaming von einer Seite der Stadt in die andere (10KM…), dafür wurde WLAN nie gemacht.

Allgemein würde ich sagen, ihr macht es sehr sehr ähnlich zu unseren, nur das “wir” (einzelne Leute aus der Community) noch eine alternative anbieten für Leute die einfach “nur” einen Knoten aufstellen wollen. Das einzige was mir bei euch nicht gefällt ist dieser “Registrator” da ich aber nicht weiß wie tief er eingebunden ist mach ich mir da vllt. auch zuviele sorgen :wink: Sonst gefällt mir dein Text richtig richtig gut. Vielleicht könnte man sagen, unser manueller Registrator ist das hier:

Portal:Netz – Freifunk Franken bzw. Portal:Netz/IPv6 – Freifunk Franken

Da darf sich jeder IPs herausnehmen wie er sie für sein Netz benötigt.

mfg

Christian


#5

Das größte Problem mit der Dezentralität in Freifunknetzen besteht darin, das Router sich im Internet nicht ohne zentrale Instanz finden. Ich meine damit jetzt nicht mal Gatewayserver, das sind Dienste im Freifunknetz, die normalerweise auch ausfallen können, ohne dass das Netz kaputt geht (auch wenn Leuten das vielleicht so sehen - weil facebook nicht geht :P). Oft sind aber diese Server zum verbinden der Router auch Gatewayserver.

Ein weiteres Problemfeld ist die IPv4 Adressvergabe. Die Adressen werden oft von den Gateways vergeben.
Allerdings lassen sich IPv6 komplett dezentral vergeben. Jeder Router gibt das identische Prefix an die Clients. Hoffentlich kann in nicht allzu ferner Zukunft auf IPv4 verzichten…


#6

Der hat eigentlich hauptsächlich die Aufgabe, aufgrund einer Anfrage mit einem neuen Key eine Knotennummer herauszusuchen die frei ist und jene zurück zu senden, daraus errechet sich dann die Knoten IP.

In regelmäßigen Abständen “registriert” sich der Knoten neu, wenn das (zur Zeit ein Jahr) lange nicht passiert ist oder der Key zur Nummer gelöscht wird, wird die Knotennummer neu vergeben.

Ich bin mir sicher, dass kann man mit etwas (viel?) Aufwand auf Server und Knotenseite zwar nicht vollständig dezentralisieren, aber ausfallsicherer (x mal Co-Registrator, z.B. in einem anderen Land) gestallten.

Für den eigentlichen Betrieb wird er nicht benötigt.


#7

Wann man wirklich auf den Vorteil eines “Registrators” verzichten möchte, kann man auch manuell eine Liste pflegen und dann seine Knotennummer in ein config-file auf dem router eintragen oder ne einfache gui dafür bastlen. damit wäre diese Abhängigkeit weg.

Aber wir haben gemerkt, dass viele leute garnicht sich den Aufwand machen möchten und manuell eine Nummer erfragen wollen. Und unsererseits die Nummern zu vergeben, war ungewollter aufwand. Ist also kein absolut kritisches Element in dem Netzwerk.

IPv6 machen wir deswegen nicht, weil einfach der Kernel mit jeder openwrt version größer wird. Freifunk wäre auf 4MB Geräten absolut nicht mehr möglich. Und die meisten wollen keine 30Euro dafür ausgeben. Es ist ja auch nicht notwendig. IPv6 finde ich zwar sehr interessant und auch die möglichkeiten, aber für das was das Netz leisten soll, absolut nicht notwendig.

Ich stimme zu, dass es Server oder Treffpunkte geben muss, damit einzelne Router überhaupt zugang zum Netz finden. Aber je mehr es solche Punkte gibt, umso mehr dezentral wird das netz. und auch ausfallsicherer.
Zumal die eine firmware (die alles beinhaltet) ebenso einfach als solch ein Punkt arbeite (via dyndns und backbone).


#8

Hi @ChrisD,

vielen Dank für die ganzen Infos. Mal sehen ob ich das alles richtig verstanden habe

Hoods funktionieren autonom. Wenn also einer mal weg ist, dann funktionieren die anderen weiter. Selbst ein einzelner Hood funktioniert weiter auch wenn die Verbindung zu anderen weg ist (natürlich hat der dann nur Internet wenn er direkt eine Verbindung dazu hat).

Im Extremfall könnte mal also ein Netz aufbauen, dass aus lauter Hoods besteht die jeweils nur aus einem Knoten bestehen? Nicht dass ich das will, oder dass es unbedingt sinnvoll ist, es geht mir hier nur ums Verständnis.

Der Vorteil an Hoods ist dann, dass ich innerhalb des Hoods eine SSID usw. habe. Wenn ich also z.B. ein großes Gebäude, das mehrere Router braucht anschließe, könnten die zu einem Hood zusammengefasst werden und der Nutzer würde sich freuen, weil es wie ein Größes WLAN ist.

Sollte dieser Hood kein Zugang zum Internet haben, das aber gewünscht sein, könnte ich ihn z.B. über eine Richtfunkstrecke mit einem anderen Hood verbinden, der Internet Zugang hat.


#9

Hi @ddmesh,

auch dir vielen Dank für die ausführliche Antwort. Euer Setup hört sich ziemlich einfach an, das find ich gut.

Noch zwei Fragen:

  • Verstehe ich das richtig, dass jeder Knoten seine eigene SSID hat?
  • Ist ein Server ein Knoten der einfach nur mit-mesht? Im Gegensatz zu einem Gateway, der eine Verbindung zum Internet hat?

Cheers,
Volker


#10
  • Verstehe ich das richtig, dass jeder Knoten seine eigene SSID hat?

Ja, das ist notwendig, da die Endgeräte sonst eine Art vereinfachtes “Roaming” versuchen. Heisst, dass diese sich mit einem Accesspoint mit gleicher SSID aber stärkerem Signal verbinden. Dann hat das Gerät eine IP von Router A zugewiesen bekommen, den Router B nicht kennt oder bereits vergeben hat (IP Konflikt)

  • Ist ein Server ein Knoten der einfach nur mit-mesht? Im Gegensatz zu einem Gateway, der eine Verbindung zum Internet hat?
    Es gibt nur einen Typ von Server. Das System ist Ubuntu, wo die grundsätzlichen Netzwerk/Routing Funktionalität für Freifunk Netz nachinstalliert ist (via github und scripten nach installiert).
    Optional kann einfach openvpn installiert werden und die Zertifikate des Openvpn-Anbieters mit einem script unter /etc/openvpn/gen-config.sh (oder so ähnlich), so angepasst wird, dass die Openvpn Verbindung mit Freifunk Netzwerk/Routing zusammen arbeitet.
    Der Server (also die nachträgliche Freifunkinstallation) beinhaltet schon den support dafür.
    Grundsätzlich hat der Server dann folgende Bestandteile:
  • fastd (Backbone vpn)
  • bmxd (Routing protokol deamon)
  • Scripte zum Konfigurieren: firewall, Routingtabellen, bmxd, openvpn
  • Scripte für den laufenden betrieb: DNS, Routing, Gatewaycheck
  • Webserver: bereitstellung einer einfachen Knotenübersicht und wichig einer “sysinfo.json” welche jeder Knoten haben muss. über diesen werden die Kartendaten,Statistiken,Kontaktinfos vom knoten abgefragt.

VG
Stephan


#11

hi vmx

ich antworte mal auf alle Fragen mit der “Spezialfirmware” für dezentrale Hood und lass unseren zentralen Kram mal außen vor:

Technisch gesagt, ist jede Hood ein eigenes Layer 2 Netz. Dieses Layer 2 Netz ist per Routingprotokoll das Layer 3 macht (Babel) angebunden. Je mehr Verbindungen eine Hood (=Layer 2 Netz) zum großen Layer 3 Netz hat (z.b. 2x per RF 1x per Tunnel) desto unwarscheinlicher ist ein kompletter Ausfall. Natürlich kann der Babelrouter der meist auch dhcp/RA macht ausfallen, dann ist genau diese eine Hood tot und natürlich alles was über diese Hood geroutet wird.

Und ja, auch eine Hood funktioniert autonom weiter wenn sie gar keine Layer 3 Verbindung mehr hat. Es ist vor Ort ein DHCP/RA Server und somit werden Clients IP Adressen gegeben. Wenn aber kein Transit mehr Richtung Internet besteht, kommt man natürlich auch nicht ins Internet weiter. Theoretisch könnte man auch einfach vor Ort auf einen DSL Anschluss NATten (Fall der Störerhaftung, oder auch nicht…) und die Hood funktioniert komplett autonom weiter inkl. Internet. Technisch alles möglich, ob und wie man es will muss man natürlich für sich entscheiden.

tatsächlich haben wir solche Hoods z.b.:

  1. Standorte/Fuerth/StPaul – Freifunk Franken ; FFF Monitoring :: r0stpaul.fff.community
  2. Standorte/Fuerth/Hardhöhe/Heilig Geist Kirche – Freifunk Franken ; FFF Monitoring :: fff-gw-hgk

Es gibt hier also sehr viele verschiedene Fälle und man kann nicht alles nach Schema F machen. Der Fall nur ein Router der allein eine Hood bildet gibt es also durchaus auch aber nicht nur.

wir gehen sogar soweit (Beispiel Sportplatz oben ist ein klassisches Beispiel) das man neben den Babelrouter Accesspoints mit Originalfirmware betreibt. Diese funktionieren deutlich besser und man hat nicht den 5GHz Outdoor Geschiss mit OpenWrt/Gluon/whatever, der Hersteller hat sich schon um alles gekümmert.
Wer das Netz erweitern will, kann uns ansprechen und es kommen mehr sinnvolle 5GHz Antennen an den Mast mit Layer 3 Routing. Wer uns nicht ansprechen will kann immer noch einen Repeater dran hängen. In diesem Sinne in meinen Augen das PPA erfüllt. Natürlich ist das keine Pflicht, wer in seiner Hood Batman-adv (Layer 2) spielen will kann dies natürlich auch tun, das ist jedem selbst überlassen.
Innerhalb eines Layer 2 Netzes nutzt man natürlich die gleiche SSID und hat dann auch Roaming. So kann man wunderbar einen ganzen Sportplatz mit einer Hand voll Accesspoints abdecken, hat über den gesamten Sportplatz Roaming, bindet diesen aber per Layer 3 an die “Backbone” an wo es dann kein Roaming mehr gibt (aber zum 6,6KM entfernten Hochhaus wo es nicht mal ein Clientnetz gibt weil sinnlos will eh niemand roamen ;))

so hab ich es beschrieben, tatsächlich haben ALLE Beispiele oben keinen Zugang zum Internet. Dies wären dann andere Hoods (bei uns aktuell nur in Privathaushalten) z.b.:

FFF Monitoring :: r0reddog.fff.community oder FFF Monitoring :: fff-gw-cdhome oder FFF Monitoring :: fff-gw-fbl das sind dann 3 Hoods wo in unsere RF Standorte (Hoods) das “Internet” eingespeist wird, meist über wireguard gelöst wobei auch das hier keine Pflicht ist, zumindest ein Kollege nutzt glaub ich GRE.
Diese Layer 3 Backbone zieht sich dann auch durchs Rechenzentrum so das jeder (kann muss aber nicht) seine Server betreibt die ebenfalls im Layer 3 Backbone hängen und vielleicht dann schlussendlich den Traffic zum Internet aus dem Freifunknetz ins Internet zu kippen (z.b. direkt weil man es kann und sich traut oder weiter über einen Vereinsserver oder oder…). Um das ganze mal anhand eines Tracesrouts zu zeigen:

pi@ttn-gateway:~ $ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 fff-gw-knobl.fff.community (10.50.140.1) 4.293 ms 4.141 ms 4.237 ms
2 fff-gw-hh.fff.community (10.50.130.1) 7.819 ms 8.308 ms 8.491 ms
3 fff-gw-cdhome.fff.community (10.50.138.1) 20.819 ms 20.506 ms 20.243 ms
4 fff-jupiter.gw.fff.community (10.83.252.3) 51.073 ms 52.074 ms 52.227 ms
5 fff-nue2-gw1.gw.fff.community (10.83.252.2) 54.224 ms 53.955 ms 53.687 ms
6 81.95.4.185 (81.95.4.185) 53.046 ms 47.378 ms *
7 31.7.185.81 (31.7.185.81) 63.639 ms 50.691 ms 52.392 ms
8 ae1-4012.nbg30.core-backbone.com (81.95.15.65) 50.106 ms 49.846 ms ae0-4011.nbg20.core-backbone.com (81.95.15.45) 51.204 ms
9 ae1-2003.fra20.core-backbone.com (80.255.14.82) 56.492 ms ae10-2021.fra20.core-backbone.com (80.255.14.6) 55.818 ms ae1-2003.fra20.core-backbone.com (80.255.14.82) 55.947 ms
10 72.14.197.230 (72.14.197.230) 55.236 ms 55.377 ms 54.723 ms
11 108.170.251.193 (108.170.251.193) 54.452 ms 108.170.252.65 (108.170.252.65) 55.089 ms 108.170.251.193 (108.170.251.193) 57.958 ms
12 209.85.243.211 (209.85.243.211) 58.029 ms 216.239.59.123 (216.239.59.123) 57.377 ms 216.239.59.115 (216.239.59.115) 53.313 ms
13 google-public-dns-a.google.com (8.8.8.8) 52.996 ms 52.313 ms 52.061 ms
pi@ttn-gateway:~ $

Das ist ein Raspberry Pi in der Hood "Knoblauchsland und steht ca. bei dem Router:
https://monitoring.freifunk-franken.de/routers/4391
Dann gehts erstmal innerhalb des Layer 2 Netzes (ist im Layer 3 Traceroute natürlich nicht zu sehen) bis zum Gateway dort vor Ort, das ist der 1. Hop:
https://monitoring.freifunk-franken.de/routers/4394
Von dort geht es weiter per Layer 3 Richtfunk (da kümmert sich ab jetzt unser Babel darum) zum nächsten Hop (2.):
https://monitoring.freifunk-franken.de/routers/4400
Auch hier gibts noch keinen Internetendpunkt, also gehts weiter zum 3. Hop (mein Zuhause):
https://monitoring.freifunk-franken.de/routers/6518
Von hier geht es dann per wireguardtunnel zu meinen priv. Server im RZ bei Hetzner, 4.Hop
fff-jupiter bzw.
Simple Babelweb
da ich privat natürlich keine Haftung übernehmen kann, kann ich diese Daten auch so nicht ins Internet lassen, also hat mein Server keine eigene default Route. Da kommt nun unser Verein ins Spiel, mit dem ich einen GRE Tunnel habe und das ist dann Hop 5. Dieser Server kann es dann ins große weite Internet per NAT rausblasen (ab Hop 6).

Zentraler Punkt “der Verein”? Nö sollte es den nicht mehr geben, klick ich mir schnell nen Mullvad Account, richte den auf meinen Server (Hop 4) ein und leite da einfach per Mullvad wieder aus (und wer das sowieso ohne Verein tun will, kann es tun, wenn es einen 2. Verein gibt, kann er es tun, wenn eine Firma Exitkapazitäten sponsort kann sie es direkt tun, wenn ein Privatmensch das Risiko eingehen will, na? na? natürlich kann er es auch tun ;)), MEIN Netz (und allen die dran hängen und in irgendeinerweise mit mir peeren/denen ich Transit gebe) läuft wunderbar weiter, vielleicht durch den Mullvad bisschen langsamer aber es tut -> dezentral ich bin von niemand Abhängig und genau da fängt für mich dezentralität an, niemand kann mein Netz ausschalten weil er

  1. auf einen Server off Knopf drückt
  2. mit dem Autoupdater eine kaputte Firmware einspielt
  3. […]

Ich allein bin für mein Netz verantwortlich und verwalte es selbst.

Tatsächlich hat das Traceroutebeispiel noch einen Haken, der Hop 2) gehört mir gar nicht sondern einen anderen Freifunker. Tatsächlich könnte er also den Off Knopf drücken, ich hab aber an den Standort wovon der Traceroute los lief auch einen DSL Zugang so das ich den Notfalls hernehmen kann (allerdings nur 16/2,4Mbit, über RF geht da aktuell was im Bereich 30/15Mbit drüber wobei ich immer noch den Engpass suche, eigentlich sollten um die 100Mbit drüber gehen. Daher ist das DSL dort nur ein Notnagel und ich route aktuell alles über RF)

Kleiner Hint noch, weil ich immer wieder das Monitoring verlinkt habe:

  • blaue Linien sind Layer 3 Verbindungen (Babel) und somit Verbindungen von Hoods untereinander, aktuell alles per RF
  • grün über gelb bis rote Linien sind Batman Verbindungen (Layer 2 und somit INNERHALB einer Hood)
  • Verbindungen ins RZ werden nirgens angezeigt (auf der Karte, beim Router selbst unter Neighbours sieht man sie).

Wow viel Text, ich hoffe ich hab niemand erschlagen :wink:

P.S. am #18fff kann man gerne persönlich drüber quatschen, ich werde die Richtfunkstandorte dort auch vorstellen und danach findet sich auch bestimmt Zeit über die Technik und so zu quatschen, es lohnt sich also unbedingt zu kommen.

mfg

Christian


#12

Vielen Dank @ChrisD für die megaausführliche Antwort. Danke auch dass du auch immer auf den dezentralen Aspekt eingehst. Wie gesagt, mein Ziel ist es nicht 100% dezentral zu sein, aber eben schauen was geht. Ich will eben möglichst wenige Single Points of Failure haben. Soetwas wie VPN (das das ganze ja etwas zentralisiert) wird es schon geben, oder eben Hoods die kein Internet haben und sich dann zu anderen verbinden müssen.

Cheers,
Volker


#13

Die der lokal nähesten Community …

Das mit dem “moglichst dezentral funktioniert” ist halt so eine Sache. Das eine Extrem ist Berlin, wo jeder Knoten eine eigene SSID hat (haben muß) und ggf. lokal ausleitet, das andere ist eine größere Gluon-basierte Community, wo im Grunde alle Knoten auf Layer 2 verbunden sind.

Im Grunde “will” man https://libremesh.org/ ein- und umsetzen, denn dort wird genau die Unterscheidung gemacht zwischen “Roaming” und “Routing”. Allein, das funktioniert eben nicht in einem Umfeld, wo jeder nach Gutdünken einen Freifunk-Knoten aufstellen können soll. Glaube ich zumindest …


#14

Was genau soll das Netz denn leisten?