Firmware: Unterschied zwischen den Versionen

Aus Freifunk Potsdam | Wiki
Zur Navigation springen Zur Suche springen
K (→‎Voreinstellungen: Kanal: 13 → 5)
 
(10 dazwischenliegende Versionen von 2 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
= Offizielles =
An dieser Stelle ein paar Links zur Freifunk-Firmware …
* Imagebuilder – http://imagebuilder.augsburg.freifunk.net/
** Doku – http://wiki.freifunk.net/Freifunk_Firmware/ImageBuilder
** Bugs/Tickets – https://trac.augsburg.freifunk.net/report/1
* LuCI – http://luci.subsignal.org
** 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. ==
* freifunk-policyrouting
** http://wiki.freifunk.net/Kamikaze/freifunk-policyrouting
** http://luci.subsignal.org/trac/browser/luci/trunk/contrib/package/freifunk-policyrouting
= FFP-Firmaware =
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)
* 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
* Netmask 255.255.0.0
* Netmask 255.255.0.0
* 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).


== 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 ==
=== 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) (--[[Benutzer:Melle|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 (--[[Benutzer:Sokai|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 ;) (--[[Benutzer:Melle|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 <code>"ffp-firmware-$original_fff_version.$ffp_revision.$router_version.$dateiendung"</code> wäre...
: Der Dateiname <code>"ffp-firmware-1.6.32-a.g.bin"</code> bedeutet dann also:
:* <code>$original_fff_version</code> = 1.6.32
:* <code>$ffp_revision</code> = a
:* <code>$router_version</code> = g (& gl)
:* <code>$dateiendung</code> = bin  (--[[Benutzer:Sokai|sokai]] 15:48, 21. 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))
=== Buildprozess ===
* 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 ;)  
Der sollte möglichst Deutsch, Englisch, G+GL, TRX ausspucken. (--[[Benutzer:Melle|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 (?).
: Alles kein "Problem"! :)
* Buildprozess: der sollte möglichst Deutsch, Englisch, G+GL, TRX ausspucken.
: 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 "[http://buildbot.net/trac Buildbot]" gefunden. Außerdem ist "[https://wikitech.leuksman.com/view/ExtensionDistributor 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 .) (--[[Benutzer:Sokai|sokai]] 15:48, 21. Sep. 2008 (CEST))


== 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 33: Zeile 69:


Anhand der e-Mail Adressen können ''wichtige'' Announcements rumgeschickt werden.
Anhand der e-Mail Adressen können ''wichtige'' Announcements rumgeschickt werden.
[[Kategorie:Projekte]]
[[Kategorie:Technik]]
[[Kategorie:Router]]

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.