[ff-firmware-devel] einheitliche wifi einstellungen städte- und firmwareübergreifend

Jan Lühr ff at jluehr.de
Mo Jun 2 17:29:22 CEST 2014


Hallo Ufo,


Am 06/02/2014 02:09 AM, schrieb Ufo:
> Nochmal schriftlich hier, obwohl wir seit Jahren daraufhin arbeiten:
> 
> Es sollte eigentlich möglich sein, als normaler Nutzer sein Freifunk
> Equipment auch mal in einer anderen Stadt aufzustellen oder in den
> Urlaub mitzunehmen!
> Und auch wenn man andere Freifunker aus anderen Städten trifft sollten
> sich unseren Geräte auch auf Anhieb "verstehen" können.
> 
> Ich verweise auf eine Diskussion von 2005:
> http://comments.gmane.org/gmane.org.freifunk.wlanware/1081 mit
> erstaunlichen Antwortenthread, Popcorn..


Zunächst: fup2wlan-talk? Firmware-Devel für Freifunk <-> OpenWRT belange
gedacht (evtl. ist ist der Name etwas unpassend).

Hintergrund für diese Liste ist die Diskussion zwischen Freifunk und
OpenWRT Leuten auf den WCW 2013 und 2014. Konsens war jedes mal, einen
Austauschkanal für übergreifende Belange (OpenWRT-Dinge in Bezug auf
Freifunk) zu schaffen. Dein Post hat nichts mit OpenWRT-Dingen zu tun
und ist damit Off-Topic.

Evtl. wäre es sinnvoll Beschreibung und Adresse dieser Liste in
freifunk-openwrt at freifunk.net zu ändern. (@Listadmin: Ist das einfach
möglich?)

Vor 9 Jahren hast Du auf wlanware geschrieben - mglw. ist der Post dort
auch besser aufgehoben.

> 
> Die Problematik der IP-Adressen haben wir ja mittlerweile auch quasi
> schon gelöst, also sollten wir BITTE auch einheitliche BSSSIDs und
> WLAN-Kanäle verwenden!
> 
> Was haltet ihr davon, einige BSSIDs wurden ja jetzt schon bewusst
> unterschiedlich je Stadt spezifiziert wegen VPN-Problemen? Bei uns in
> Leipzig funktioniert das zb super, wenn ihr Freifunk Gadow besuche!
> 
> Die Nodes funktionieren dort dann vor Ort, allerdings teilw. komme ich
> nicht auf andere bundesweiten IPv4 Freifunk Ips, weil ich im icvpn die
> falsche IP habe. Aber, derzeit bei ipv4 ist das okay, kann ich mich
> damit abfinden..
> 

Inhaltlich (das ist wesentlich länger ...)
Aktuell muss der Benutzer bei vielen Communities keine Konfiguration der
Geräte vornehmen. Das ist gut und soll so bleiben!

Wie soll ein Gerät jetzt aber erkennen, in welcher anderen Community es
sich befindet und bspw. VPN-Server für das Backbone korrekt setzen?
Selbst Google verlegt meinen Standort gerne nach Norwegen (weil ich dort
häufig bin) oder Aachen (dort plumpst mein ISP heraus) - während ich in
Köln sitze.

Ein weiteres Problem ist meshing: Die Backbones verschiedener batman-adv
Netze zu verbinden ist Wahnsinn (Mesh <-> VPN). Dies verdoppelt schnell
den Broadcast-Traffic und sorgt für erheblich Routing-Störungen bis hin
zu Teilausfällen (1/3 aller Geräte erhalten ein nicht nutzbares Ergebnis)
=> Die Definition des Standorts muss bei Verwendung gleicher SSIDs im
Mesh korrekt sein.

Damit muss der Benutzer also auswählen in welcher Stadt er sich gerade
befindet und welche VPN-Server / BSSID hier angewendet werden muss.
Hierzu brauchen wir irgend eine Art von User-Interface.

Ich möchte dem Benutzer ungern zumuten, wesentlich Daten der Community,
in der er sich gerade befindet zu kennen (Adressen / Public-Keys der
VPN-Server, etc.). Die Sofrware muss ihn also dabei unterstützten, die
passenden Parameter zu ermitteln. Wie machen wir das am besten?

Eine Möglichkeit wäre, das Gerät neu zu flash'n. Die Option hat den
Charme, dass sie vergleichsweise einfach ist (wenig Klicks im UI / LuCI,
der Vorang ist idR dokumentiert). Bei gleichen OpenWRT-Releases können
config-files idR auch übernommen werden (ausgn. Settings, die zwischen
Communities abweichen ;-) ).

Problematisch ist jedoch, dass der Benutzer nach seinem Umzug zunächst
recherchieren muss, welche Community er am nächsten ist, welche Firmware
wie installiert werden muss, etc. Kurz: Er steht von dem gleichen
Problem wie ein Benutzer der dort völlig neu anfängt.
Das Problem existiert i.A. auch unabh. davon, ob der Benutzer das Gerät
neu flashed oder configs "irgendwie" setzt.

Wie schaffen wir es also, die Firmware passend zu vereinheitlichen? S.d.
der Benutzer einfach "auswählen" kann, welche Variante installiert
werden soll? Die Antwort wäre etwa die gleiche wie:
Wie schaffen wir es, den Einstieg für neue Freifunker / Communities
möglichst einfach zu halten und auf "freifunk.net", Community-Unabh.
Firmware-Images zu haben, d.h. "eine Firmware" für alle
Freifunk-Communities?

Hierzu hab' ich leider kein Patentrezept. Mein Vorschlag wäre im ersten
Schritt, die Freifunk-API dafür zu verwenden, dass jede
Freifunk-Community angibt, welche Geräte mit welcher Firmware verwendet
werden können. D.h. ein Community-Eintrag publiziert die Hardware die
sie haben möchte. Form
[
{platform: 'wr741nd-v4', //OpenWRT-Code!
firmware: 'https://download.url/fw.bin',
info: 'Kein Upgrade',
details:
'@https://downloud.url/fw_weitere_json_dinge_wie_gluon_configuration',
doc; 'https://download.url/doku_zum_Gerat_wird_im_Browser_angezeigt'
},.....
]

Die Daten können wir dann auf freifunk,net auch so bereit stellen, dass
wir eine zentrale Einstiegs /Download-Seite für alle Communities haben.

> In meinem Beispiel würde ich da übrigens auch Nodes mitnehmen, die olsr
> und batman-adv gleichzeitig verwenden (standardeinstellung in leipzig).
> Da in Gadow derzeit nur OLSR laeuft, funktioniert natürlich auch nur
> das.. aber immerhin.
>
> Und wenn jemand aus Hamburg mal ein Gerät in Leipzig aufstellt, dann
> sollte das halt nur via batman-adv kommunizieren, und olsr geht nicht.
> Das wäre auch nicht schlimm, denn das Gerät ist dann trotzdem
> Bestandteil der lokalen Freifunk-Wolke und funktioniert!?
>
> für adv. user: batman-adv dhcp-server koennte ich mir dann natürlich
> spotan auf Reisen selbst installieren. aber wenn ich zurück nach Hause
> komme, ist das wieder zurück in den Ausgangszustand zu versetzen.
> Gleiches gilt für vorhandene VPN-Tunnel: auf Reisen oder mit mobilem
> UMTS-Freifunk VPN muss man einiges beachten.
>
>
>
> Das sollte uns aber nicht davon abhalten, Freifunk so einfach wie
> möglich zu bauen, halt auch überregional!
>

Hier herrscht immer noch kreative Anarchie - fordern allein bringt
niemanden weiter.
Wenn Du meinst, dass alle technischen Problem gelöst sind - ich sehe das
nicht so - bau einen Proof-Of-Concept. Bau eine Firmware, die überall
funktioniert, submitte Pull-Requests, wo es nicht passt oder fork' die
Firmware anderer gemäß Deiner Ideen!

Möglicherweise ... erkennst Du dabei aber auch, warum selbst Gluon (als
sehr einheitlicher Firmware verschiedener Communites) verschiedene
Builds für verschiedene Städte hat...

Gruß, Jan


Mehr Informationen über die Mailingliste firmware-devel