Firmware: Unterschied zwischen den Versionen
Melle (Diskussion | Beiträge) |
Sokai (Diskussion | Beiträge) K (→Voreinstellungen: Kanal: 13 → 5) |
||
(9 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 | * 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 11: | Zeile 30: | ||
== 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)) | |||
=== Buildprozess === | |||
Der sollte möglichst Deutsch, Englisch, G+GL, TRX ausspucken. (--[[Benutzer:Melle|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 "[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 34: | 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 …
- Imagebuilder – http://imagebuilder.augsburg.freifunk.net/
- 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
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.