Firmware: Unterschied zwischen den Versionen

K
Kat.korr.
K (-Hauptkategorien)
K (Kat.korr.)
Zeile 1: Zeile 1:
Wir wollen eine eigene Firmware backen.  Hier ein paar erste Ideen dazu. Ansprechpartner für das Projekt FFP-Firmware ist [[Benutzer:sokai|Kai]].
Wir wollen eine eigene Firmware backen.  Hier ein paar erste Ideen dazu. Ansprechpartner für das Projekt FFP-Firmware ist [[Benutzer:sokai|Kai]].


== Voreinstellungen ==
== Voreinstellungen ==
* IP-Adresse  
* IP-Adresse  
* OLSR-DHCP: 10.22.X.Y/27,255.255.0.0 (je nach IP)
* OLSR-DHCP: 10.22.X.Y/27,255.255.0.0 (je nach IP)
Zeile 11: Zeile 11:
* WLAN-Modus: ad-hoc
* WLAN-Modus: ad-hoc
* die URL-Whitelist sollte beim booten geleert/überschrieben werden (damit das beim gateway-plugin nicht immer schief geht).
* die URL-Whitelist sollte beim booten geleert/überschrieben werden (damit das beim gateway-plugin nicht immer schief geht).


== Ideen ==
== Ideen ==
* bestimmte Pakete vorinstallieren? freifunk-recommended-de, snmp, dieses statistik-Paket z.B.?
* 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)
* 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.
* 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 ==
== Offene Fragen ==
* Was ist das Ziel einer eigenen 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 --[[Benutzer:Melle|Melle]] 18:26, 19. Sep. 2008 (CEST))
* Was ist das Ziel einer eigenen 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 --[[Benutzer:Melle|Melle]] 18:26, 19. 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 ;)  
* 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 ;)  
* Versionierung: es sollte klar sein, auf welcher Originalversion unsere Version basiert. Original 1.6.32 -> FFP 1.6.32.a (?).
* Versionierung: es sollte klar sein, auf welcher Originalversion unsere Version basiert. Original 1.6.32 -> FFP 1.6.32.a (?).
* Buildprozess: der sollte möglichst Deutsch, Englisch, G+GL, TRX ausspucken.
* Buildprozess: der sollte möglichst Deutsch, Englisch, G+GL, TRX ausspucken.


== IP-Vergabe ==
== 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:
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:


Zeile 37: Zeile 37:
Anhand der e-Mail Adressen können ''wichtige'' Announcements rumgeschickt werden.
Anhand der e-Mail Adressen können ''wichtige'' Announcements rumgeschickt werden.


[[Kategorie:FFP]]
[[Kategorie:Projekte]]
[[Kategorie:Router]]
694

Bearbeitungen