Wie wird das DHCP organisiert und die IP Vergabe, ist das Zugeordnete
Netz nur für Knoten oder auch für die Clients.
Android Geräte ? - Die können kein AD Hoc ab einer bestimmten Version
mehr. gibts da ein Infrastructure Mode?
Ich habe das Bisher so verstanden.
Die Geräte Bilden ein Ad-Hoc Mesh mit BATMAN, also die MAC Adresse wird als MESH Knoten angeboten.
Ein zweites Virtuelles WLAN Device oder ein anderes wird als Infrastructure Gebridget und mit DHCP Forwarder oder eigenem Client DHCP Raum.
Also FF:FF:FF:FF:FF Ad-Hoc und lingen.freifunk.net als Infrastructure-AP
Intern wird der Traffic von dem AP Interface via BATMAN durch das Netz geroutet.
Der VPN Zugang wenn aktiviert connected sich mit einem tinc oder openVPN Server von freifunk, vorzugsweise mit einem für das Netz bereitgestellten, der den anderen VPN Servern bekannt ist und darin hin und her geroutet wird.
Also Benötige ich theoretisch folgende Konfiguration um dies selbst zu Implementieren als Raspberry Pi und Co Image.
Zwei Wifi Geräte, ein zum Meshen, das andere als AP
openVPN und Internetzugang.
openVPN Client ist mit openVPN server von z.b vpn.lingen.freifunk.net verbunden, dieser wiederum kennt die Routen, über welche Software und Konfiguration ich noch nicht herausgefunden hab, von den anderen Netzwerken. dient als Gateway.
Alle Anfragen die nicht aufgelöst werden können werden an den nächsten Knoten mit openVPN Verbindung geschickt und dann nach draußen geroutet.
Irgendwie finde ich das für Laien doch etwas konfus zu verstehen.
Ganz unterschiedlich, von Community/Domain zu Community/Domain verschieden.
Eigentlich ist das gar keine technische Frage, sondern eher eine politische…
Wichtig ist nur dass
a) die Bedingungen des Picopeering-Agreements eingehalten werden
b) dass beim fast zwangsläufigen Einsatz von GNU-GPL-Software die Bestimmungen der GPL respektiert werden
c) der Freifunk-Dachverband (freifunk.net) sich überzeugen lässt, dass es sich wirklich um Freifunk handelt, was da praktiziert wird und das dann (via API…) in dieser Liste einfügt.
P.S. Wenn Du sagst, zu welcher Community Du es wissen möchtest, dann könnte man dazu was sagen.
Oder wenn Dich interessiert, was der Unterschied z.B. zwischen FF-Lübeck und FF-Kiel ist. Oder was zwischen Berlin und Leipzig. Oder Berlin und Kiel…
Ich möchte eine Community Gründen in meinem Ort,
Ich habe schon ein GLUON Build dafür erstellt, doch möchten wir auch mit vorhandener Hardware arbeiten.
Ich denke die Frage war, ob du dich irgendwo andocken möchtest - also z.B. bei Freifunk Rheinland oder Ruhrgebiet oder whatever. Oder baust du komplett neu, auch mit eigener Infrastruktur im Hintergrund?
Generell hindert dich natürlich keiner einen Server mit Rheinland-Firmware in Berlin aufzustellen - ebenso kann ein Freifunk-Berlin Server in Aachen stehen. Macht nur wenig Sinn, da hast du schon recht.
@pierewoehl
Ich kann nur empfehlen, erstmal bei irgeneiner anderen Community mitzumachen und sich dann „bei genügend Masse“ (>20-50 Nodes) sich selbstständig zu machen.
Warum? Weil man wenn man das Rad nochmal neu erfindet sehr viel Lehrgeld zahlt.
(Selbst wenn man in einer Community startet tut man das noch.)
0
So lustig Freifunk auf Raspberries, Fritzboxen und i64/x86 sein mag:
Das Problem ist NICHT die Prozessorarchitektur, sondern die NICs, sowohl ethernet wie auch und gerade wifi.
Warum? Weil man nirgends mit Standardkerneln weiterkommt, sondern ziemlich viel selbst backen muss.
Wenn man der begnadete Build-Environment-Bauer vor dem Herren ist: Wunderbares Projekt.
Wenn man allerdings eine Freifunk-Community anschieben möchte, dann sollte man sich besser nicht im Compilerkeller verschanzen. Dann kommt man nämlich garantiert zu gar nix anderem mehr in den nächsten x Jahren.
Die Hardware veraltet schneller und die Batman-Versionen kommen schneller neu heraus als dass man alle Builds für alle Platformen durch den regression-Test geschleust hat.
Daher: Gluon plus Server aus einem Puppet-Environment mögen Dosen/Tütensuppe sein. Es spart aber den totalen Reinfall…
Das ist mir klar, ich habe mit den Jungs von Nordwest schon gesprochen, da hängenwir uns ran,
Ich möchte die x86 und arm firmware nur mit dem Hinweis das unterstützte HW verwendet wird die out-of-the-box vom Kernel funktionieren entwickeln.
Vlt. werd ich mich da mal ransetzten.
Es geht also um das Setup von „Nordwest“:
Normalerweise ist’s Gluon-basiert.
Mesh via batman/advanced (v14), fastd als Mesh-vpn.
ssidmesh.ffnw für den AP ist „nordwest.freifunk.net“ auf Kanal 6 (für 2.4GHz)
ssid für das Wifi-Mesh ist „mesh.ffnw“.
Herausforderung für einen Selbstbau-Meshnode ist, dass man einen Wifi-nic braucht, der AP-Modus und AdHoc-Modus gleichzeitig fahren kann (was dann z.B. alle mir bekannten AVM-Fritzboxen herauswirft)
Und auch bei dem was man von einem Hersteller (z.B. Dlink oder TP-Link) als USB-NIC bekommt, so wechseln da häufig Revisionsnumern oder gar gleich der ganze Chipsatz. Das ist dem Windows-Treiber egal, weil der gleich „alle Chips“ kann, und der Linux-Kernel kann’s auch irgendwie… aber eben meist irgendwie mit Einschränkungen, wenn eben obiger Simultanbetrieb gefordert wird.
Mein Vorschlag, um die Funktionalität eines meshnodes auf „anderer Hardware“ zu bauen: Einen (oder mehrere) billige TP-Links hinstellen und von dort abschauen.
Und ggf. vergleichen mit den üblichen Debugging-Werkzeugen (tcpdump, wireshark).
Ohne den ständigen direkten Vergleich zu haben ist es sicher möglich. Aber wird nicht leichter.
Schaue mir das auch gerade an da ich gerne ein Android Smartphone per IBSS mit dem Freifunk Netzwerk verbinden würde (unter Verwendung von BATMAN adv).
Da müsste man also theoretisch cyanogenmod selbst kompilieren mit dem BATMAN adv Kernel Modul für ein geeignetes Smartphone, z.B. Nexus 4. Dann sollte es auch als Mesh-Knoten fungieren können.