Firmware

Wir wollen eine eigene Firmware backen. Hier ein paar erste Ideen dazu. Ansprechpartner für das Projekt FFP-Firmware ist Kai.

Voreinstellungen

IP-Adresse
OLSR-DHCP: 10.22.X.Y/27,255.255.0.0 (je nach IP)
Kanal 13 (?)
ESSID www.freifunk-potsdam.de
BSSID 02:CA:FF:EE:BA:BE
Netmask 255.255.0.0
WLAN-Modus: ad-hoc
die URL-Whitelist sollte beim booten geleert/überschrieben werden (damit das beim gateway-plugin nicht immer schief geht).

Ideen

bestimmte Pakete vorinstallieren? freifunk-recommended-de, snmp, dieses statistik-Paket z.B.?
vordefinierten Public key für den Notfall (damit das Passwortproblem gelöst ist)
kann man die IP-Adresse in das Firmware-Image "injezieren" oder das Image "live" auf dem Server bauen? Der User soll möglichst nichts mehr einstellen müssen.

Offene Fragen

Ziel einer FFP-Firmware?

Wollen wir Features (das wäre das Leipziger Modell) oder möglichst nahe an der originalen Firmware sein und nur bestimmte Voreinstellungen einbringen, die mehr Konfort für den User bringen (mein Favorit) (--Melle 18:26, 19. Sep. 2008 (CEST))

Um das Ganze "so einfach wie möglich" zu halten/gestalten, sollten wir (erst einmal) "nur" bestimmte Voreinstellungen einbringen und ggf. schon einige FFP-Standardpakete (bspw. "DHCP-Splash" und "snmp") integrieren (--sokai 15:48, 21. Sep. 2008 (CEST))

Source-Repository

Klar, wir haben ein SVN, da kommen die Sourcen rein. Wie können wir die Anpassungen aus dem CVS der Original-Firmware übernehmen? Stichwort "vendor branch", Sven-Ola wäre der Vendor in dem Falle ;) (--Melle 18:26, 19. Sep. 2008 (CEST))

Versionierung

Es sollte klar sein, auf welcher Originalversion unsere Version basiert. Original 1.6.32 -> FFP 1.6.32.a (?).

*zustimm* Ich hatte mich an der FFF der Leipziger orientiert, die (umgesetzt für uns) dann eben "ffp-firmware-$original_fff_version.$ffp_revision.$router_version.$dateiendung" wäre...

Der Dateiname "ffp-firmware-1.6.32-a.g.bin" bedeutet dann also:

$original_fff_version = 1.6.32
$ffp_revision = a
$router_version = g (& gl)
$dateiendung = bin (--sokai 15:48, 21. Sep. 2008 (CEST))

Buildprozess

Der sollte möglichst Deutsch, Englisch, G+GL, TRX ausspucken. (--Melle 18:26, 19. Sep. 2008 (CEST))

Alles kein "Problem"! :)

1. Was meinst du denn mit den Sprachen? (Die des FFF-Interfaces, oder die des Online-Builders?)

Solltest du den Online-Builder meinen, dann liegt das ja "in unserer Hand". Ich habe mal geschaut und "Buildbot" gefunden. Außerdem ist "ExtensionDistributor" fürs Mediawki auch ne QLe Sache! :)

2. Der build-Prozess kann Versionen für jeden existierenden Router generieren. (Im Moment sind das: g|gs|gs40|g3g|a|moto|se505|trx .) (--sokai 15:48, 21. Sep. 2008 (CEST))

IP-Vergabe

Wir brauchen ein Webinterface für die IP-Adressenvergabe incl. einer Userverwaltung. Damit soll die Vergabe von doppelten IPs im Netz vermieden werden, gleichzeitig gibt es zu jedem Node zumindest eine Kontakt-eMail-Adresse (die für die Anmeldung angegeben werden muss). Der Ablauf könnte ungefähr so aussehen:

User meldet sich mit seiner e-Mail / open-id an (e-Mail muss aber ein Pflichtfeld sein).
bei der ersten Anmeldung muss die e-Mail bestätigt werden (confirm-Link in der e-Mail anklicken).
Freiwillige Angaben wie Telefon und Standort
er kann sich dann eine IP reservieren
ggf. gleich eine Firmware mit dieser IP runterladen (bzw. aus der Liste "seiner" IPs eine für ein fertiges Image auswählen)

Anhand der e-Mail Adressen können wichtige Announcements rumgeschickt werden.