Protokolle/20141102

Firmware Entwickler Treffen 02.11.2014

Zeit: Sonntag 02.11.2014 / 14 Uhr Örtlichkeit: http://www.fablab-nuernberg.de/content/anfahrt

Wer wird (vorrausichtlich) kommen:

1. delphiN (wahrscheinlich bin ich dabei)
2. Tobias(nur so bis 4)
3. Andreas
4. RedDog
5. Philipp
6. Cornelius

Themenvorschläge

Lasst uns erstmal treffen und gucken wer so dabei ist und wer was kann. Darauf aufbauend würde ich vorschlagen einen groben Fahrplan aufzubauen. [RedDog] Einführung in die jetzige Firmware Struktur Pro/Contra Umstellung auf GLUON einfaches Einrichten von Gateways/eventuell automatisiert

Protokoll

Wer war da

1. Tobias: Will Wissen vertiefen. Was kann GLUON was nicht? Wie können wir Probleme lösen. Doku für Anfänger ist verbesserungsfähig. Würde im Wiki mitmachen. Will eigenen Gateway aufsetzen und dokumentieren. Ist Puppet sinnvoll?
2. Andreas: Wie läuft das alle so? Wie kann ich helfen? Was muss gemacht werden?
3. Mose: (FabLab) Was treibt ihr hier überhaupt?
4. Tim: Will nicht alleine basteln, wir brauchen Konzepte! Treffen sind wichtig! Moexe baut übrigens auch grade Gateway!
5. Corny: Wollt auch einfach mal die Firmware verstehen.
6. delphiN: Umstellung auf GLUON wär interessant zu besprechen. Wir sollten was schaffen!
7. Patrick: Bin vom FabLab und will sich das mal anschauen.
8. Phillipp: Bin eher Theoretiker; Freifunk soll sich weitereintwickeln! Hab interesse mitzumachen.

• Tim zeigt kurz Bielefelder Lösung
• Nur IPv6, Router verteilt IPv4 für "alte" Geräte
• OpenWRT ist Basis, Erweiterungen per Patches
• Tim findet die Bielefelder Firmware-Lösung sehr interesannt --> Bitte mal Anschauen und Meinung bilden

• Tim erklärt kurz die jetzigen Strukturen und aktuelle Probleme anhand der Folien
  • Seite:25: fastd wird kurz erklärt
  • Seite:27: Netzwerkstruktur kurz erklärt
  • Seite:28: Das Skript started fastd und fragt beim KeyExchange
  • KeyExchange ist eine zentrale komponente --> Hier muss eine Lösung her
  • Server Nürnberg: 2xCPU Intel® Xeon® E5, 4G RAM, ca. 10 TB Traffic
  • Server Rumänien: 1xCPU, 1G RAM, ca. 6TB Traffic
  • Für einen Gateway braucht man: min. 500MB RAM, CPU auch nicht die langsamste
  • Wichtig ist für einen Gateway nicht ungedingt die Hardwareausstattung sondern der Traffic (10-20 TB pro Monat sollten drin sein)
  • Neuer Gateway: Man sollte einfach mal anfangen und seine Versuche Dokumentieren und bei Problemen Tim fragen.
  • Seite:45: Was ist Netmon, Nodewatcher...Details sind auf den Slides beschrieben
  • Knoten sollten eigentlich Ihre Daten (Name, Standort, Status usw.) selbst speichern und an das Monitoring senden statt zentral abgefragt zu werden.
  • Ein Problem ist auch wie man "Hoods" per Funk untereinander verbindet (Layer2/Layer3) Konflikt

• Tobias: Warum kann ich mir OpenWRT nicht einfach zu einem Freifunk-Knoten umkonfigurieren?
  • Tim: Es gibt Platzprobleme und Abhängigkeiten
  • Die Anpassungen für unser Netz sind nicht unbedingt trivial und eher was für Experten
  • Besonders für schwache Geräte ist eine sehr speziell angepasste Firmware sinnvoll

• Firmware: Welche Anforderungen haben wir an eine Firmware:
  • Alex: GLUON wird sehr breit eingesetzt
  • Tim: "GLUON ist nur ein Hype"
  • Konsens: Es muss sich ein Firmware-Entwicklungs-Team finden (Welche Firmware dann die Basis ist ist nicht soo wichtig)

• • Tobias spricht sich für Webinterface aus
  • Konsens: Alle hätten gerne ein dauerhaftes Webinterface (Nicht nur Konfigurations-Modus)

• • Alex: Autoupdater soll standardmäßig deaktiviert sein aber sollte vom Nutzer aktivierbar sein.
  • Tim: Auf jeden Fall aus! z.B. bei Funkstrecken sollte das Ding aus sein!
  • Konsens: Optionaler Autoupdater (default aus) mit einem StableRepository wäre gut. (Signaturen!)

• • Tim: Jeder Knoten sollte eine (IPv6) Adresse haben
  • IPv6 ist momentan experimentier Phase - schön wäre es (in Zukunft) ein IP-Range von Berlin local (z.B. über Wavecon) zu announcen.
  • Tim hat gute Erfahrungen mit IPv6 (außer auf Android)
  • Bielefeld hat Erfahrungen mit IPv6
  • Konsens: Eine neue Firmware sollte IPv6 Support haben (evtl. IPv6 only). Jeder Knoten soll eine eigene IPv6 Adresse bekommen.

• • Alex: Weitere Hardware Unterstützung wäre sinnvoll (z.B. auch Ubiquity)
  • Tobias: Die Hardware Auswahl des Users sollte je nach seinen Anforderung erfolgen. Es muss relativ einfach sein eine neue Harware zu untersützen.
  • Tim: Bei Einstellung von Harware-Support (durch den Hersteller) sollte eine neue Harware schnell gebaut werden können.
  • Tim, Alex: Die Switch-Configuration mit den BATMAN-Ports kann für die Standart Firmware abgeschafft werden.
  • Konsens: Es wäre schön, wenn die Switch-Config über Webinterface möglich wäre
• Corny: evtl. wär es möglich die LEDs der Schnittstellen blinken lassen um sie zu konfigurieren

• • Tim: Die jetzige Firmware muss mit dem heutigen Netmon klar kommen
  • Konsens: Um nicht zu viele Baustellen gleichzeitig aufzumachen soll der bestehende Netmon erstmal erhalten beleiben

• • Mose: Firmware sollte durch möglichst viele Entwickler erweiterbar konfigurierbar sein.
  • Mose: GLUON hat aufgrund größerer Verbreitung evtl. mehr Doku
  • Tim: Bei GLUON schrecklich ist die Site-Config: Keine Abhängigkeiten
  • Tim: Wär schön, wenn die Firmware auch gleich Gateway/Hood managen könnte.
  • Alex: Wir brauchen Super-Nodes die eine Verbindung zwischen Layer2 und Layer3 machen:
  • Mose: Speicher ist ein Problem -> Tim: Stimmt aber man bekommt es hin
  • Alex: Es reicht, wenn die Konfiguration eines SuperNode ausführlich dokumentiert ist
  • Mose: Warum nicht eine eigene Supernode Firmware
  • Mose: SuperNodes stellen eine Gefahr da, weil man das Netz in seiner Umgebung stören kann
  • Tim: Wie stellt man einen Knoten um, wenn z.B. die Hood aufgeteilt wird.
  • Tim: Schön wäre wenn der Knoten scannt welche Knoten in der Nähe sind. Dann kann er in der Konfiguration eine geeignete Hood vorschlagen
  • Konsens: Thema Layer3-Routing/Supernodes/Backbonenetz ist noch nicht voll verstanden und ausdikutiert. Weitere Treffen und Diskussionen sind nötig.

• Konsens: Das Key-Exchange Skript soll automatisiert werden (Wenn sich ein Knoten beim Key-Exchange meldet wird dieser anhand seiner netmon Standortdaten in eine Hood eingeteilt); Alex übernimmt die Implementierug bis zum 12.11.14

• Mose-Konzept (KeyXchange für nächste Firmware):
  • Die Knoten landen am Anfang in der default Hood.
  • In jeder Hood wird eine Liste von Hood-Standorten propagiert.
  • In dieser Liste stehen die ESSID/Channel/BSSID Daten der Hood sowie die IP Adressen der VPN Gateways.
  • Jeder Knoten baut dann seine VPN Verbindung zu der Hood auf, welche am nächsten dran ist.
  • Schöne wäre eine Signatur-Prüfung dieser Liste.