[Freifunk-Bonn] Grüße aus Lübeck / Bad Schwartau

[Jan Lühr]

Hallo zusammen,

gerade steht mein IC in Osnabrück - also hab' ich kurz UMTS (und Netz) um eine E-Mail zu senden:
Ich habe wieder Zeit gefunden, bei den Lübecker Freifunkern vorbeizusehen und im Meute-Keller zu hocken.
Alles in allem war es ein netter, gemütlicher Abend, bei dem wir einige Punkte diskutieren konnten:

1) L2TP / Dynamische bridging / bridge-loop-avoidance (bla):
Wir denken, dass es prinzipiell mgl. wäre, die dynamisches Bridging-Architektur mit L2TP umzusetzen. Hierbei könnte eine "VPN-Routing" Variante erweitert werden. 
Vorteil von L2TP + routing (im Gegensatz zu tinc oder vlan-ids): Einfachere Handling (kein Key-Austausch nötig) sowie die bessere Skalierbarkeit (L2TP-Pakete gehen nur an die Hosts im Bridge-Verbund und nicht an das gesamte Netz)
Weiterhin gibt es von L2TP eine Kernel-Implementation, die eine gute Performance liefern soll.
Nachteil (im vgl. zu tinc): l2tp verläuft zwischen 2 Nodes, d.h. die VPN-Last wird zentral verteilt, während tinc p2p arbeitet. Ebenfalls haben die Lübecker Freifunker Kernel Panics bei l2tp beobachtet (es gibt jedoch eine userland l2tp-Implementierung, bei der dieses Problem nicht existieren soll)
Denkbar wäre auch, das Netz via bla zu skalieren: Werden VPN und bat0 bridged, so werden keine (praktisch gesehen: einige wenige) batman-Pakete über das VPN abgewickelt, s.d. hier weniger management-Overhead entsteht.
Diese Alternative haben die Oldenburger vor kurzem getestet - jedoch nur mit mäßigem Erfolg (Details: Lübecker Freifunk-Mailingliste). Zudem kommt, dass der Code selbst zur Zeit "im Fluss" ist und noch nicht alle Bedenken ausgeräumt sind. Hier werden wir die Experimente aus Oldenburg weiter verfolgen.
Grundsätzlich sind wir zuversichtlich, die Skalierungsprobleme / -bedenken auf die eine oder andere Art in den Griff zu bekommen. Da sich beide Ansätze parallel  zur aktuell KBU-Netzarchitektur betreiben lassen (insb. integriert), sind sie für uns kein Blocker.

2) GIT-Repository-Design / LFF statt OpenWRT Upstream
Linus überlegt, die Repository-Struktur / Submodul-Aufteilung der Lübecker Firmware zu überarbeiten, s.d. wir für KBU keinen OpenWRT-Fork maintainen müssen. Dies ist aktuell notwendig, der Lübecker OpenWRT-Fork die Repositories für Konfiguration, Infopage,etc. direkt referenziert).
Darüber hinaus denke ich, dass es weiterhin sinnvoll ist, den LFF-Fork statt Vanilla OpenWRT zu verwenden: Die Abweichungen sind minimal, aber dafür erprobt :-)
Nichts desto trotz wird Neuorganistation des Repos dazu führen, dass wir einfacher auf Vanilla OpenWRT als Upstream umschalten können.

3) Paketierung der Config
LFF plant aktuell keine Paketierung ihrer Konfiguration

4)  Weitere Hardware / mac80211 für WRT54GL
Die Lübecker haben keine Tests im Freifunk-Netz mit dem WRT54GL gefahren. Es könnte zwar grundsätzlich möglich sein, den wlan-Karte mit OpenWRT (trunk!) und mac82011-Modul multi-mode zu fahren, jedoch gibt es hier keine Erfahrung. Die Lübecker beschränken sich (ähnlich wie wir) auf einige wenige Plattformen (insb. TP Link 1043ND)

5) FrosCon
LFF hat Interesse an der FrosCon, ggf. auch an einem Stand - es wäre cool, wenn wir einen gemeinsamen auf die Beine stellen. Wir freuen uns hier auf ein Wiedersehen :-)

6) Aufkleber / Sticker
Für LFF gibt es schöne Sticker, mit denen AP-Aufsteller für Freifunk werben können. Ich bringe ein Exemplar mit.

Alles Gute
Jan