Ich würde vorschlagen, das in der ICVPN zu integrieren. Noch eine Stelle, wo man sich absprechen muss, das wird nicht funktionieren.
1 „Gefällt mir“
Hi. Ich habe meine Meinung zwar schon in den [Issue des freifunk-ssids Repository][1] geschrieben aber ich erwähne sie hier trotzdem nochmal.
Ich halte es für keine gute Idee, die Mesh-SSIDs im [freifunk-ssids Repository][2] zu sammeln. Dieses Repository wurde von mir erstellt, weil es zuvor keine zentrale Sammlung der Freifunk-SSIDs gab und ich eine einfache Möglichkeit brauchte, die SSID-Liste in der [Freifunk Auto Connect App][3] zu aktualisieren. Dazu lädt die App die Liste direkt aus dem Github-Repository herunter. Daher sollte die ssids.json Datei in diesem Repository so klein wie möglich gehalten werden. Da die Münsterland Community alleine schon 65 verschiedene Mesh-SSIDs nutzt, befürchte ich, dass die Dateigröße explodiert, wenn alle Mesh-SSIDs jeder Community dort eingetragen werden.
Wenn ihr wollt, könnt ihr das Repository aber auch in ein separates Repository forken und dort die Mesh-SSIDs in die Liste integrieren.
Edit: Die Mesh-SSIDs in einer separaten Datei im freifunk-ssids Repository zu sammeln wäre auch noch eine Möglichkeit.
[1]: Mesh SSIDs · Issue #15 · WIStudent/freifunk-ssids · GitHub
[2]: GitHub - WIStudent/freifunk-ssids: A collection of SSIDs used by the Freifunk community.
[3]: GitHub - WIStudent/FreifunkAutoConnectApp: An Android app that can show you the nearest Freifunk nodes and add multiple Freifunk SSIDs to your device at once.
Problematisch wird es auch, wenn die SSID verschieden sind, die BSSID jedoch identisch.
Den die SSID wird beim Wechsel zu .11s wegfallen, und wenn dann mehrere einfach nur „batbone“ heissen, dann hat man -so nicht andere Maßnahmen schlimmes verhindern- dort einen Domainbridge.k
1 „Gefällt mir“
Nein, normalerweise kommt es da zu keinen Problemen. Deshalb haben viele ältere Freifunk-Communities gleiche Einstellungen. Damit kann einen Freifunk-Router auch in einer anderen Stadt betreiben und er mesht dort auch mit.
Einzige Ausnahme ist da die Gluon-Firmware (falls am Internet angeschlossen) durch die zentralistische Struktur des VPNs und der ausschliesslichen Verwendung von einem Layer2-Routingprotokoll (batman-adv). Es gibt zwar auch die Möglichkeit, diese Netze durch unterschiedliche VLAN-Einstellung zu trennen (so wie im Freifunk-Meshkit oder mit der Libremesh Firmware), die meisten Gluon-Admins haben sich aber leider für unterschiedliche WLAN-Einstellungen entschieden 
Prinzipiell ist es also durchaus wünschenswert, Freifunk mit gleichen WLAN-Einstellungen zu betreiben!
p.s. die ad-hoc-SSID ist prinzipiell der unwichtigste Wert von allen. Dieser kann auch auf JEDEM Router unterschiedlich sein. Wichtig sind die anderen WLAN-Einstellungen, BSSID, Channel, VLAN-ID, …
Dann schiebe ich das mal nach Gluon herüber, weil der Threadstarter sich ja darauf bezogen hat.
Deine Erläuterung hilft zum Verständnis, was da „knallt“, wenn da Communities sich nicht absprechen.
(Und bei MoL „ohne Vlan“ hilft auch das nicht. Ist ja leider auch shcon mehrfach passiert.)
Dort gehört es allerdings auch nicht hin. Gluon könnte auch mit einheitlicher SSID/BSSID betrieben werden (zb mit Wahl unterschiedlichem WLAN-VLAN). Somit ist auch der Titel des Thread etwas irreführend.
Leider haben auch viele nicht-Gluon-Communities unterschiedliche WLAN-Einstellungen, oft historisch bedingt. (Bspw. der erste Freifunk-Admin einer Stadt macht einen WLAN-Scan zuhause und entscheidet dann über den stadtweit (!) zu verwendenden Kanal).
Eine Auflistung in der Freifunk-API würde also durchaus Sinn machen. So könnte man beim Wechsel der Stadt seine Freifunk-Router entsprechend konfigurieren, ohne gleich die Firmware der Stadt verwenden zu müssen. (Ja, ich weiss dass es in einigen Städten einen Zwang zur Verwendung einer bestimmten Firmware gibt bzw. das Verwenden oder Testen anderer Firmware „verboten“ ist bzw die Admins davon „abraten“ )
Bei Gluon-Firmwares stehen die Werte (ch, ssid, bssid, vlan) meist bei github
Nee macht es nicht, da gerade bei geographisch benachbarten Communities keine API-Listing möglich ist. (Was aber das Problem der API ist, dass für eine „Stadt“ nur eine Community gelistet werden darf.
jedoch verschieden >> jedoch gleich, oder ? (und nicht umgekehrt, nur fuer mein Verstaendnis)
Hallo,
wäre es nicht sinnvoll für das MESH so was wie batman.´%community%.freifunk.net zu verwenden dann kann die BSSID gleich sein.
Nein, wäre es nicht.
Da diese Netze zu „lecker“ aussehen. Wenn die Namen nicht ultra-kryptisch sind, versuchen sich da ständig iphones und androids einzubuchen, weil sie hoffen, dort „das Freifunk“ zu bekommen.
3 „Gefällt mir“
du meinst damit nutzer die das versuchen, das device sollte das sicher nicht von selber machen
Ich plane innerhalb einer Community bewust verschiedene Mesh BSSIDs zu nutzen. Hintergrund ist, dass man an gewissen Stellen eben nicht mit jedem meschen will, weil das ein „Design“ zerstören würde. Hab es noch nicht zu Ende gedacht, aber so könnte es gehen:
Ich habe für eine Wolke einen zentralen (aber redundten) Exit ins Internet (am besten ohne VPN Gedöns). Darin läuft DHCP/RA. Ein neuer „achtlos dabei gestellter“ Knoten würde die Konstruktion zerstören.
Das Problem mit den Loopenden Routern durch mehrere Hoods haben wir aktuell ab und zu. Da werden dann beide Nutzer angeschrieben Frist gesetzt und nach der Frist die VPN Zugänge oder zumindest ein Zugang gesperrt, Ist nicht schön aber funktioniert bisher
Abseits von Sonderkonstellationen wie Flüchtlingsunterkünften fände ich so ein Setup doof. Es ist doch gerade toll an Freifunk, dass man nicht zentral planen muss, sondern irgendjemand einen weiteren Router nur nah genug an eine bestehende Wolke ranschieben muss und schon fällt zwar kein hochperformanter Breitbandzugang aber immerhin für noch mehr Menschen nutzbares Netz raus.
1 „Gefällt mir“
wenn man aber unterschiedliche „Hoods“ hat die über OLSR miteinander verbunden sind, dann entstehen so loops, die das Netz beeinträchtigen und das kann nur durch unterschiedliche BSSIDS vermieden werden.
1 „Gefällt mir“
Angenommen, ich habe in einem Mesh einen 1 GBit/s Ausgang. Dieser wird von 200 Menschen genutzt. Ein wohlmeinender Nachbar hängt sich mit seinem 6 MBit/s ins Mesh und zieht den gesamten Verkehr an: nicht noch mehr Menschen haben ein nutzbares Netz, sondern niemand hat noch nutzbares Netz. „Gut gemeint“ ist nicht immer gut gemacht.
1 „Gefällt mir“
Du könntest auf deinem Knoten dann die hop penality auf 1 runter setzen. Das macht deinen Exit dann attraktiver.
Nein, ich müsste auf all meinen Knoten die hop penalty auf 1 runter setzen, oder den auf dem Knoten zum meshenden Nachbarn auf 255 erhöhen, immer in der Hoffnung, dass der Nachbar das nicht auch für eine total coole Idee hält. Auch mit batman kommt man bei komplexeren Netzen wohl kaum um eine „Planung“ drumherum.
1 „Gefällt mir“
Gibt es so ein Setup irgendwo außerhalb von wirklich atypischen Umgebungen? Dass Flüchtlingsunterkünfte u. ä. Situationen Planung jenseits von „einfach Hinstellen“ erfordern, ist klar.
Klar.
Nachbarschaften mit einem VPN-Verhältnis von 5:1 und Uplinks im Bereich ADSL16, VDSL50 und UM200.
Da kann es -insbesondere wegen der niedrigen Latenz bei UM- sinnvoll sein, über 2 FF-Hops mehr zu gehen, nur um zum 200er-Unitymedia-Uplink zu kommen, selbst wenn das „nach Hop-Penalty“ nicht gerechtfertigt wäre.
Ist aber hier eigentlichkein Thema, da es nichts mit AdHoc/BSSID zu tun hat. (Daher spare ich mir auch weitere Ausführungen zu den sinnvollen HP-Settings an welchen Stellen.)