Spannender wird es jedoch, wenn nicht mehr alle Teilnehmer jeden anderen sehen und das Ad-hoc-Netzwerk als ein Mesh-Netzwerk<\/a> zu betrachten ist. Ein Projekt, was sich mit dem Betrieb solcher Mesh-Netzwerke besch\u00e4ftigt, ist Freifunk<\/a>, dass in einer ganzen Reihe von St\u00e4dten bereits meist kleinere, teils aber auch gr\u00f6\u00dfere Ad-hoc-Netzwerke aufzuweisen hat. In diesen Netzen muss typischerweise jeder am Routing teilnehmen, um ein Datenpaket vom Absender zum Empf\u00e4nger zu bef\u00f6rdern, da es im Gegensatz zu Infrastruktur-Netzwerken kein zentrales Routing gibt und daher sich die Clients untereinander kooperativ um alle Verwaltungsaufgaben k\u00fcmmern m\u00fcssen. Die Aufgabe des Routings ist dabei relativ unproblematisch \u00fcber eine Reihe von Protokollen geregelt, von denen OSPF<\/a>, OLSR<\/a> und BATMAN<\/a> die am H\u00e4ufigsten eingesetzten sind. Diese funktionieren aber allesamt nur, wenn alle zu routenden Clients sich auch am Protokoll beteiligen und regelm\u00e4\u00dfig ihre Informationen dem Netz mitteilen.<\/p>\n Ein relativ neuer Weg, der derzeit vom Freifunk Chemnitz<\/a> beschritten wird, ist es nun, auch Clients ohne Routing-Software den Zugang zum Netz zu erm\u00f6glichen. Die hierf\u00fcr eingesetzte Technik des ARP-Roaming \u00e4hnelt ein wenig dem Vorgehen in Infrastruktur-Netzwerken<\/a>, denn der Client wird von den Routern „verwaltet“ und wenn n\u00f6tig zwischen diesen umgezogen, wenn sich seine Position im Netzwerk \u00e4ndert. Damit dies auch ohne Infrastruktur-Modus in einem Ad-hoc-Netzwerk funktioniert, m\u00fcssen jedoch eine Reihe von Bedingungen erf\u00fcllt sein.<\/p>\n Eine der wichtigsten Bedingungen, damit man einen Client ohne Probleme von einem zum anderen Router umziehen kann, ist, dass der Client m\u00f6glichst wenig davon mitbekommt. Insbesondere der Standard-Gateway sollte aus Sicht des Clients an jeder Stelle des Netzes identisch sein. Zu diesem Zweck wird beim Freifunk Chemnitz im Ad-hoc-WLAN-Teil des Netzes mit einer Anycast-IP<\/a> f\u00fcr den Standard-Gateway gearbeitet, die unabh\u00e4ngig vom Router, der die Anfrage des Clients empf\u00e4ngt immer identisch ist. Somit entf\u00e4llt bei einem Handover<\/a> eines Clients die Umkonfiguration von Netzwerk-Parametern.<\/p>\n Ein weiteres Problem, was sowohl mit dem Routing zusammenh\u00e4ngt, aber auch die Verwaltung der Clients betrifft ist zudem die IP-Adress-Vergabe. Man k\u00f6nnte theoretisch zwar einen zentralen DHCP<\/a>-Server nehmen und auf Layer 2 (Ethernet-Ebene) routen, h\u00e4tte dann aber sofort einen Netzausfall, wenn der Client sich in einem Teil des Netzwerkes anmeldet, der gerade keine Verbindung zum DHCP-Server besitzt. Der gegenteilige Weg, also dass jeder Router auch gleichzeitig DHCP-Server spielt, scheint zwar \u00fcbertrieben, birgt aber andererseits einen Reihe essentieller Vorteile, die man f\u00fcr die Netzwerk-Verwaltung benutzen kann. Damit nun auch ein einzelner, nicht gerade mit dem Rest des Netzwerkes verbundener Knoten noch operativ bleibt, muss jeder der DHCP-Server autark und autoritiv entscheiden k\u00f6nnen. Da er dies f\u00fcr den gesamten im Netzwerk verwendeten Adressbereich nicht autark tun kann, muss jedem DHCP-Server ein eigener Adressbereich zugeteilt werden, den dieser autonom verwalten darf. Zu diesem Zweck wird der gesamte f\u00fcr das WLAN vorgesehene Adressbereich noch einmal in Subnetze unterteilt. Im Fall von Freifunk Chemnitz handelt es sich hierbei um ein \/17-Netz f\u00fcr WLAN, welches in \/28-Netze f\u00fcr jeden Router aufgeteilt wird. Da sich einige Clients etwas zickig haben, wenn der DHCP-Server aus einem anderen Subnetz kommt, ist eine der IPs dieses \/28-Netzes f\u00fcr den DHCP-Server des Routers zugewiesen.<\/p>\n W\u00e4re noch ein letzter Aspekt kurz zu erw\u00e4hnen: N\u00e4mlich das Backbone-Netzwerk, welches von den Nodes untereinander verwendet wird, um das Netz auch beim Zusammenbruch direkter Funkstrecken (z.B. Sichverbindungen, Richtfunk) \u00fcber alternative Wege, wie eine VPN-Verbindung \u00fcber UMTS) am Leben zu halten. Da auch diese Struktur sehr dynamisch sich \u00e4ndert, wird dieser gesamte Netzbereich (beim Freifunk Chemnitz ein \/21) mit OLSR verwaltet.<\/p>\n Somit besitzt jeder Node, der am Routing teilnimmt folgende 4 Angaben:<\/p>\n Diese geh\u00f6ren zu den folgenden 2 Netzwerken:<\/p>\n Betrachtet man sich das Netzwerk bisher, so ist dieses noch sehr unflexibel: M\u00f6chte ein Client umziehen, muss er, trotz dem er an jedem Router Pakete in das Netzwerk senden kann, zum Empfang der Antwort immer in Reichweite des Knotens bleiben, der ihm seine IP zugeteilt hat, da bedingt durch die im Routing bekanntgegebenen Subnetze alle Pakete des WLAN immer wieder zu dem Knoten, der die IP vergeben hat, zur\u00fcck geroutet werden.<\/p>\n Soviel zum Vorgepl\u00e4nkel; tut mir echt leid, dass ich etwas ausholen musste, aber der spannende Teil kommt nun!<\/p>\n OLSR bietet nun die M\u00f6glichkeit, die an jedem Knoten angeschlossenen „Netzwerke“ – sogenannte Host-Network Associations – bekanntzugeben. Neben ganzen Subnetzen funktioniert dieser Mechanismus nun auch f\u00fcr einzelne IPs, womit es m\u00f6glich wird, einen Client, der von seinem Heimat-Knoten entfernt im Netzwerk lebt – \u00e4hnlich dem Roaming im Telefonnetzen – an seiner fremden Basisstation zu erreichen. Dies funktioniert, weil Hostrouten immer Vorrang vor Netzwerk-Routen haben und diese somit \u00fcberschreiben.<\/p>\n Wenn man nun einen Client von einem zum anderen Knoten im Netzwerk umziehen kann, ist als letzter Schritt f\u00fcr eine Automatisierung dieses Vorgangs zu sorgen, da der Client m\u00f6glichst nichts davon mitbekommen soll. Damit man aber von Seite der WLAN-Knoten wei\u00df, dass nun pl\u00f6tzlich ein Knoten in Reichweite ist, muss eine M\u00f6glichkeit gefunden werden, die Clients der Umgebung zu beobachten und die Verbindungsqualit\u00e4t zu bewerten. Ein einfacher Ansatz ist derzeit bereits im Netz von Freifunk Chemnitz umgesetzt und betrachtet den Inhalt der ARP<\/a>-Tabelle der Router als Quelle f\u00fcr neue Clients. Wird dort ein neuer Client entdeckt, wird durch einen ARP-Ping<\/a> gepr\u00fcft, ob dieser wirklich in der N\u00e4he ist und im Erfolgsfall als Client im OLSR registriert, um dem Netzwerk Bescheid zu geben, dass dieser Knoten den neu gesichteten Client empfangen kann. Schlegt ein ARP-Ping fehl, so wird nach einem Timeout erneut versucht diesen Client zu erreichen bzw. nach einer einstellbaren Anzahl Fehlversuche der Client als unerreichbar wieder entfernt.<\/p>\n Auch wenn dieser bisher noch recht passive Versuch der Client-Erkennung beim Umzug von Clients eine Reihe kleinerer Nebenwirkungen besitzt, was sich i.d.R. durch Nicht-Erreichbarkeit des Clients \u00e4u\u00dfert, funktioniert dieser Ansatz in der Praxis bereits vergleichsweise gut f\u00fcr das noch sehr fr\u00fche Entwicklungsstadium: Immerhin wird hier auf Software-Ebene nachgebildet, was typischerweise die Netzwerk-Hardware erledigt. Weitere Ausbaustufen umfassen daher auch Dinge wie eine verbesserte Erkennung neuer Clients bereits anhand ihres Traffics<\/a>, bzw. ein dem ARP-Spoofing<\/a> entlehntes zwangsweises Umziehen des Standard-Gateway f\u00fcr einzelne Clients. Auch eine proaktive Erkennung der Bewegung eines Clients zwischen den Routern und eine dieser Bewegung angepasste vorausschauendes Handover des Clients sind Dinge, die auf der Wunschliste bereits hei\u00df diskutiert werden und in sp\u00e4tere Versionen durchaus einflie\u00dfen werden. Mehr dazu aber in einem gesonderten Beitrag, da jedes dieser Themen eine ganze Menge Aspekte ber\u00fchrt, die weit \u00fcber den Umfang dieses Eintrags hinausgehen w\u00fcrden.<\/p>\n\n
\n
![\"Flattr](\"http:\/\/blog.benny-baumann.de\/wp-content\/plugins\/flattr\/img\/flattr-badge-large.png\"){kind=icon}
<\/a><\/p>","protected":false},"excerpt":{"rendered":"