Firmware: Unterschied zwischen den Versionen

Aus Freifunk Potsdam | Wiki
Zur Navigation springen Zur Suche springen
(+ offizielle Links)
K (→‎Voreinstellungen: Kanal: 13 → 5)
 
(2 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 7: Zeile 7:
* LuCI – http://luci.subsignal.org
* LuCI – http://luci.subsignal.org
** Bugs/Tickets – http://luci.subsignal.org/trac/report/1
** Bugs/Tickets – http://luci.subsignal.org/trac/report/1
** Dokumentation: http://luci.subsignal.org/api/luci/
** UCI (LuCI-CLI): http://wiki.openwrt.org/doc/uci


== misc. ==
== misc. ==
Zeile 20: Zeile 22:
* 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)
* Kanal 13 (?)
* Kanal 5
* ESSID www.freifunk-potsdam.de
* ESSID www.freifunk-potsdam.de
* BSSID 02:CA:FF:EE:BA:BE
* BSSID 02:CA:FF:EE:BA:BE
Zeile 26: Zeile 28:
* 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 ==

Aktuelle Version vom 7. Juli 2013, 22:30 Uhr

Offizielles

An dieser Stelle ein paar Links zur Freifunk-Firmware …

misc.

FFP-Firmaware

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 5
  • 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.