Firmware installieren
Der wichtigste Hinweis zuerst
Einen Freifunkrouter stellt man nicht einfach hin und überlässt ihn sich selbst – wie es eigentlich für sämtliche am Internet angeschlossene Geräte gilt, wenn es auch oft genug nicht beachtet wird –, sondern man übernimmt langfristig Verantwortung, v. a. was regelmäßige Updates und Übernahme größerer Änderungen im Netzwerk angeht. Diese werden mit hinreichend großem Vorlauf angekündigt. Wenn diese trotzdem nicht beachtet werden, läuft man Gefahr, dass der Router irgendwann nicht mehr funktioniert oder, wenn er Störungen im Netz produziert, gesperrt wird. Das gilt gerade auch für Freifunkrouter, wo eigene Modifikationen – die wir explizit unterstützen, solange sie das Netz nicht stören und kompatibel zu unseren Netz sind – vorgenommen wurden.
Der Routeraufsteller/Betreiber ist für seinen Router verantwortlich. Dies gilt auch für die Einstellungen wie z. B. Sendeleistung.
Auch sollte man zumindest grundlegendes Interesse an der Technik mitbringen. Aber keine Panik: Freifunkrouter sind im Allgemeinen sehr pflegeleicht.
Durch das Betreiben eines Freifunkrouters stimmt man dem Pico Peering Agreement (PPA) zu.
Die richtige Hardware auswählen
Das Portal Hardware enthält eine Liste unserer unterstützten Geräte.
Auch finden sich dort Empfehlungen für Einsteigergeräte.
Die richtige Firmware Variante auswählen
Seit dem Release 20192412 gibt es nun 2 verschiedene Firmwareversionen. Die ganz normale Node Firmware für zentrale Nodes sowie die Layer 3 Firmware für dezentrale Router. Mehr Infos zur Layer 3 Variante findet man hier:
- https://wiki.freifunk-franken.de/w/Gatewayfirmware
- https://wiki.freifunk-franken.de/w/Dezentrale_Hood
Da Freifunk den Charakter hat dezentral zu arbeiten und nicht von zentralen Instanzen abhängig zu sein, empfielt es sich die Layer 3 Variante zu nehmen.
Firmware-Installation
Firmware-Download
Die aktuelle Version findet man hier: https://dev.freifunk-franken.de/node/current/
Für den er-x(-sfp) fehlt in der offiziellen Firmware noch das initramfs. Dieses kann zum aktuellen Zeitpunkt von Fabian bezogen werden: https://fw.sgstbr.de/tools/ (inoffizieller build!)
Adrian Schmutzler stellt verschiedene alternative Firmwares auf seiner Seite zur Verfügung: https://freifunk.jubt.org/fff-firmware.php
Eine Anleitung, wie die aktuelle Firmware gebaut wird oder an der Entwicklung teilgenommen werden kann, gibt es hier.
Firmware-Installatiom
Dies ist je nach Modell sehr unterschiedlich, hier eine Liste div. Modelle:
Nach der Installation
Bitte melde dich bei unserer Mailingliste an! Die Infos dazu gibt es unter Kommunikation. Dort gibt es auch Hilfe und Support bei der Installation. Danke!
Firmware-Update
Versionierung
Beim Techniktreffen vom 06.02.2016 wurde ein neues Versionierungsschema beschlossen. Am 10.02.2016 wurden noch einige Details geklärt.
Begründung
Wir haben leider nicht die Men-Power um immer sicherzustellen, dass die Kompatibilität nach einem Release noch oder eben nicht mehr vorhanden ist. Dadurch ist der Interpretationsspielraum bei regulären Versionsnummern sehr hoch. Um diesen Spielraum abzuschaffen, steigen wir auf das Datumsschema um.
Schema
Die Versionsnummer orientiert sich grundsätzlich am Commit-Datum des letzten Commits. Auf diesen Commit wird dann entsprechend das Git-Tag gesetzt. Daraus ergibt sich folgendes Schema:
Build ohne release Tag: YYYYMMDD-[Anzahl commits seit vorherigem Release]-[Commit-ID]
Alpha: YYYYMMDD-alpha
Beta: YYYYMMDD-beta
Release: YYYYMMDD
Sonderfall
Für den seltenen Fall, dass es mehrere Tags an einem Tag geben muss, wird der Präfix entsprechend angepasst. Daraus ergibt sich folgendes Schema:
Build ohne release Tag: YYYYMMDD.[1-n]-[Anzahl commits seit vorherigem Release]-[Commit-ID]
Alpha: YYYYMMDD.[1-n]-alpha
Beta: YYYYMMDD.[1-n]-beta
Release: YYYYMMDD.[1-n]
Beispiele
Folgendes Beispiel geht davon aus, dass es eine Alpha und eine Beta Version auf dem selben Commit gegeben hat. In der Beta wurde am selben Tag ein massives Problem festgestellt, deshalb gab es eine neue Beta. Diese basiert auf einem neueren Commit und wird später auch so released.
20160130-alpha
20160130-beta
20160130.1-beta
20160130.1
Das nächste Beispiel geht davon aus, dass es auf dem selben Commit eine Alpha, Beta und Stable gibt:
20160130-alpha
20160130-beta
20160130
