Lange hat es gedauert, aber wir sind nun auf dem Weg zur ›magischen‹ Versionsnummer 1.0 unserer Firmware.

Wer kürzlich mal wieder auf unseren Firmwareserver geschaut hat, dem mag aufgefallen sein, daß im »Bastelzweig« (»rawhide«) erste Versionen einer Firmware mit der Versionsnummer »1.0.0« aufgetaucht sind.

Parallel ist auch die Liste der prinzipiell unterstützten Geräte länger geworden, u. a. werden wir demnächst z. B. TP-Link TL-WR1043N v5 und TP-Link Archer C7 v4 unterstützen können.

Möglich wird dies durch die gewissenhafte und zeitaufwendige Arbeit fleißiger Firmwaretüftler, die die Freifunk-Basisfirmware »Gluon« erstellen.
In der jüngst veröffentlichten Version »v2018.1« sollen viele Probleme, die in den 2017er Versionen noch vorhanden waren – und deren Existenz der Grund für uns war, nicht von der 2016er-Basis auf eine 2017er-Version zu wechseln –, nun ausgemerzt sein. Außerdem ermöglicht es jene neue Basisversion, eine Firmware für verschiedene Communities zu erstellen — etwas, was wir in unserer Firmware in den letzten zwei Jahren schon eingebaut und mit Geolokalisierung verknüpft haben.

Nachdem aber einige Zeit ins Land gegangen ist seit der Veröffentlichung der v2016.2 Anfang 2017 und nun der v2018.1, und das aktuelle »Gluon« bei manchen Geräten tiefgreifende Änderungen voraussetzt (Änderung der Partitionierung des Festspeichers bei manchen Geräten, Änderung der Partitionsgröße bei x86, …), haben wir uns entschlossen, einen harten Schnitt zu machen: es gibt unsererseits *keinen* Migrationspfad von unserer alten Firmware (0.7.x oder älter) und der kommenden Version 1.0.x.

Für die noch immer ausstehende Netzwerkteilung (von einem Netz über den ganzen Kreis GT zu getrennten Netzen für Gütersloh Stadtgebiet, Nord- und Südkreis GT sowie Rheda-Wiedenbrück Stadtgebiet) werden wir folglich noch eine entsprechende 0.7er sowie 1.0er Firmware erstellen und per Autoupdate verteilen. Das wird dann wohl auch die letzte 0.7er Firmware sein. Auch alte Knoten können im Grunde auf die Version 1.0.x gebracht werden, aber eben nur durch manuelle Neuinstallation, nicht per einfachem Upgrade — jener Weg ist uns einfach zu fragil.

Mit Firmware 1.0 möchten wir auch endlich von der überholten Tunnellösung »fastd« zu »L2TP« wechseln, mit weniger Last – und mehr Durchsatz – auf beiden Seiten der Leitung dann.

Dies erst einmal als »Appetizer«, als Info, daß es bald wieder Freifunk-Firmware für tatsächlich noch kaufbare Router geben wird — kurz, daß Freifunk im Kreis Gütersloh und der Müritz-Region »noch zuckt« ;-)

Firmware 1.0

Bisherige Kommentare

  1. Dient sowieso nur als Türstopper :wink: . Denn der C7 wird bei mir wird auch nur noch als Offloader eingesetzt. Habe Unifi APs installiert, da mit meinen eigenen WLAN mit drei verschiedenen APs Probleme hatte.

  2. Nö … :thinking: ich hatte bisher in der Vergangenheit keine Probleme auch mal die Factory zu verwenden - vorallem beim Switchen zwischen unterschiedlichen Communities bzw. LEDE/OpenWRT und zurück und bei Wiederbelebungsversuchen. Nun war das hier wirklich der Fehler. :+1:

  3. Mir ist das erst jetzt mit der 1.0~73 aufgefallen.
    Diese Version scheint auch nicht richtig in den Konfig-Modus nach einem Sysupgrad von 0.7.9 (CPE210v1.0) zu kommen … cgi-bin-Fehler - ~72 ging ohne Probleme.
    :sleeping:

  4. wusel says:

    1.0.0~95 baut gerade und sollte die beiden Flüchtigkeitsfehler behoben haben.

  5. wusel says:

    Wie Montag abend auch besprochen, versuche ich mal, das Szenario deutlicher zu beschreiben. Ich bediene mich da mal einer Skizze der Pinneberger:

    Das ein Wunschszenario, klar — meist gibt’s ja nur einen AP, sowas wie „FF1“. FF1 hat eine Internetverbindung (blau), darüber kann er eigentlich dauernd auf unseren Firmwareserver zugreifen; FF1 hat also quasi nie ein Problem.

    Anders sähe es z. B. aus, wenn wir mit einem Firmwareupdate die batman-adv-Version von derzeit 2013.irgendwas, Kompatibilitätsversion 14, auf 2015.x oder gar 2018.x, Kompatibilitätsversion 15, änderten.
    Wir erinnern uns, v14 und v15 sind zueinander inkompatibel; selbst wenn also ein Kabel läge: batman-adv mit v15 auf FF1 – alle anderen Knoten mit batman-adv v14 – führte dazu, daß FF2, FF3 und FF4 vom Freifunknetz abgeschnitten würden. Das ist der Grund, warum wir seit Jahren mit v14 rumkrebsen; es müßten wahrscheinliche viele Knoten „gerettet“, d. h. manuell aktualisiert werden. Das kriegen wir aber nicht gestemmt …

    Ähnliches Problem ergibt sich, wenn wir die WLAN-Parameter änderten, um z. B. endlich unsere viel zu große Layer-2-Wolke in kleinere Segmente aufzuteilen: Wir würden dabei die AP-SSID beibehalten („KreisGT.freifunk.net“), aber die Mesh-SSID würde in jedem Segment anders sein, damit wir keine ungewollten Brücken zwischen jenen bauen.

    Im Beispiel beziehen FF2, FF1 und FF3 in beliebiger Reihenfolge das Firmwareupdate, welches die Knoten z. B. in das Rheda-Wiedenbrücker-Segment ziehen würde; FF4 hängt nur per Mesh dran und hat eine schlechtere Verbindung, daher dauert’s da länger/klappt nicht beim ersten Mal …

    Als Resultat hätten wir erneut Knoten, die a) das wichtige, grundlegende Parameter ändernde, Update zu spät geladen haben und dies auch nicht mehr nachholen können, weil sie b) nun nicht mehr Teil des Netzes sind. Soweit klar?

    Die Lösung ist an sich so genial wie einfach: Freifunk ist ja ein offenes Netz, d. h. ein Knoten, der die Verbindung zum Netz über Zeitraum X verloren hat, probiert periodisch, ob er über ein WLAN mit „Freifunk“ im Namen (beliebige Schreibweise) als Client ins Netz kommt. Klappt das, wird ein Autoupdate erzwungen und, falls es eine neuere Firmware gibt als die, die installiert ist, hoffentlich die korrekte, den Knoten lösende, Firmware eingespielt.

    Das war auch in der Vorgängerfirmware schon angedacht, dort fehlten aber Programmteile in „iw“, weshalb es dort nicht klappte. Kritisch ist auch das Timing, denn im Falle des Verbindungsverlustes ins Mesh ändern unsere Knoten ja ihre AP-SSID. Dann den AP-Modus abzuschalten und es als Client zu probieren, bedarf eines sauberen Timings; die Check-Skripte sollten sich nicht gegenseitig Sachen wegkonfigurieren … Kurzum: das muß noch getestet werden. (Falls das wie erhofft klapp, würden auch die meisten 4 MB-Geräte Firmware 1.0 bekommen.)

    Fragen? Fragen!

Weitere Diskussion über diesen Beitrag bitte im Forum forum.freifunk-kreisgt.de

99 more replies

Diskussionsteilnehmer