Hi, so musste mich erstmal mit einer richtigen email Adresse anmelden.. @fsfe.org ist ja nur ne Weiterleitung :( Ich hatte mit Stephan beim ersten Fellowship Treffen über eure Freifunk Aktivitäten gesprochen. Dabei fiel die Idee einer Funkwolkenverbindung über eine Internet-basierte Verbindung. Vor einiger Zeit war beim wavelöten (das ist das regelmäßige, quasi-berlinweite Freifunk Treffen auf der c-base[0]) jemand aus Leipzig da. Die Leipziger kämpfen neben uneinheitlicher IP-Bereiche und nicht zentralisierter IP-Vergabe mit schlechten Links. Diese bessern sie zur Zeit mit einer Vielzahl von VPN-Verbindungen aus. Da ich in meinem Kiez Teil einer kleinen Funkwolke (3 Nodes) bin, die leider nicht mit dem großen Ganzen verbunden ist und wir in meiner WG eine dauerhafte Internetverbindung haben, wollte ich das auch mal ausprobieren. Eine passende Gegenstelle hat sich schon gefunden, OpenVPN (ohne starke Verschlüsselung) existiert für die FreiFunkFirmware. Als nächstes* folgt die Umsetzung und dann ein Erfahrungsbericht. (* nach dem FOSDEM) Die in einer anderen Mail genannten Probleme mit einer zu hohen Auslastung der 125 MHz Geräte sind richtig, aber auch nicht mehr so zeitgemäß. Die aktuelle FFF 1.1.3 aktiviert von vorneherein das sogenannte FishEye Routing. Dies ist eine Performance-verbessernde Maßnahme, die dafür sorgt, dass ein Knoten nur noch die Routen seiner Nachbarschaft (~3-4 Hops) schnell aktualisiert. Motto: Was interessiert es einen Knoten in Prenzlauer Berg, wie in Kreuzberg geroutet wird. Die Details kann euch Elektra veraten. Bei Interesse kann ich auch ihre entsprechende Erläuterung auf der berliner Freifunk-ML weiterleiten. Wegen der Subnetz-Frage: In Berlin haben wir für jeden Postleitzahlenbereich ein Klasse-B Netz aus 104.0.0.0 reserviert. Falls es Interesse bei euch gibt, davon einige zu bekommen, dann meldet euch. Zum Routing: Eine VPN-Verbindung aufbauen und den beteiligten Rechner zu sagen, man fände zB. 104.202.0.0 (ein Bereich in Kreuzberg) dahinter, funktioniert leider nicht, da OLSR momentan mit Host-Routen arbeitet. Die Lösung besteht darin das Tunnel Interface einfach dem OLSR Daemon zur Verwaltung zu übergeben. Dadurch überträgt der Tunnel Routinginformationen und verhält sich praktisch wie eine Funkstrecke. Weil das frickelig, bandbreitenfressend und so weiter ist, betrachte ich das als Experiment (im Experiment ;) ). Um nochmal auf die IP-Vergabe zurück zu kommen. Ich halte es nicht für unmöglich die Adressen einer Region zu ändern. Genau genommen ist die Nutzung von 104.0.0.0 völlig willkürlich und nichts anderes als eine virtuelle Hausbesetzung, die leider nicht skaliert. Wenn jemand eine funktionierende (deutschland oder europaweite) Lösung präsentieren kann - vielleicht sogar eine die Verwendung von IPv6 ermöglicht, ist genügend Argumentationspotential zusammen, um uns Berliner von dem derzeitigen Treiben abzubringen. Ein günstiger Zeitpunkt wäre es, wenn der geplante & rundumerneuerte OLSR Daemon 0.5 in Betrieb geht, da dieser nicht mehr mit der alten Implementierung zusammen laufen wird. cya Robert [0] - de.wikipedia.org/wiki/C-base Stephan Uhlmann wrote:

Hallo,

ich habe eben Robert Schuster mit auf diese Liste eingetragen. Er kommt zwar aus Berlin, ist aber auch an unserer Potsdamer Initiative interessiert.

Wir sprachen gestern über Vernetzung von Freifunkaktivitäten verschiedener Städte. Ob es z.B. Sinn macht das gleich von Anfang an auch technisch mit einzuplanen. Indem man z.B. ein Class-B-Netz aus dem 104er Subnetz der Berliner für den Potsdamer Raum in Beschlag zu nehmen. Oder vielleicht macht ja auch genau das Gegenteil Sinn (ich könnt mir denken, dass ein Tunnel über verschiedene Subnetze einfacher ist, als wenn alles in einem hängt).

Aber vielleicht kann Robert das besser erklären. ;)

Ciao, Stephan