Ich denke wir sollten endlich begreifen das alles was mit der Firmware zusammenhängt von wenigen sehr fähigen Menschen weltweit abhängt.
Denen unseren Willen aufdrängen zu wollen und auf 4/32 zu beharren funktioniert nicht.
Bereits 2016 hat man deutlich erkennen können das dies Auslaufmodelle sind. Das ist bald 5 Jahre her. Man hatte also genug Zeit sich um Alternativen zu kümmern.
Sicher die 15€ für einen 841 war eine kleine Hürde die viele zum mitmachen animierte das darf man nicht vergessen.
Aber die Zeit ist vorbei.
Wer 4/32 weiter nutzen möchte kann dies tun muss aber einfach damit leben dass sie ist nicht mehr ordentlich funktionieren weil die Freifunk Netze zu groß geworden sind und auch die Communities nicht immer die nötige Personaldicke haben um sie wieder klein zu machen. Auch nichts neues.
Also bitte bedankt sich bei der alten Hw für ihre Dienste und führt Sie der Verwertung zu oder rüstet sie auf.
Alte gebrauchte Geräte (siehe Freifunk Router gebraucht kaufen Thread) tun auch ihren Dienst und sind günstig.
Der große Wurf von „Backport-Kerneln“ wird nicht funktionieren.
Aber wenn man heute Probleme mit dem aktuellen 4er-Kernel hat, dann haben wir genügend Spielraum, um es zumindest DERZEIT erträglicher zu machen.
Es geht darum, Router wieder vernünftig nutzbar zu machen, die heute mit aktueller Firmware an Leistungsgrenzen kommen (diverse Speicherdruck- und Flash-Grenzen).
Und dafür gibt es ganzbare Möglichkeiten, die sind hier aufgezeigt.
Deine Behauptungen zum Thema „Aufzwingen“ und „beharren“ sind schlicht falsch. Wenn Du diese Themen diskutieren möchtest, dann steht es Dir frei, einen eigenen Thread dazu aufzumachen oder einen der vielen zu nutzen, die dafür bereits existieren statt diesen hier zu hijacken.
Natürlich, es ist mir bekannt. Aber soll nicht 4.4 Super lts werden, um eben solche Geschichten abzudecken? Und spart man sich eben nicht Arbeit? Mir scheint es doch besser zu sein, als z.B. Arbeit bei den Änderungen von 4.9 ar71xx auf 4.14 ath79 branch zu stecken. Oder wenn etwas kaputt geht weil der Kernel „zu neu“ wird.
Nach den Motto: Patches für die Sicherheit und Bugs und gut ist.
Heute haben wir GEräte mit im AR71xx-tiny-Target, die bereits am RAnde ihrer Leistungsfähigkeit angekommen sind.
Hier sollte es darum gehen, Möglichkeiten durchzuprobieren, die dafür heute(!) eine Entlastung bringen.
Auch der von MPW vorgeschlagene Backport eines 3er-Kernels auf Gluon2018 könnte interessant sein.
Das ist aber halt wirklich Arbeit und nicht nur ein „Einzelmaßnahme“, die sich auf die Schnelle (oder zumindest an einem Wochenende für die hier Anwesenden) evaluieren lässt.
Herauswerfen der Debug-Symbols, Sortierung des Dateien im Filesystem, Busybox ohne Hilfetexte… das bringt meiner Ansicht nach genug, um zumindest bei den Routern wieder Platz zu schaffen für lokal benötigte Packages, bei denen es -z.B. wegen kniffeliger mehrstufiger Bootloader- kneift.
Wir hatten zu Zeiten, als 2017.x wirklichunbefriedigend war hinsichtlich [lange Liste], eine BuildProzedur bei das 2016er mit 3er-Kernel und das 2017 mit 4er Kernel beides auf der gleichen internen Versionsnummer gebaut wurde.
Und vor dem Erstellen des Manifest wurden die Verzeichnisse von „sysupgrade“ und „factory“ gemerged, damit nur die Targets, die in 2016 fehlenen die 2017er bekommt.
Erst danach dann Signatur und rsync auf die FW-Server.
Unter dem Aspekt „Ram-Druck“ wäre das für die 4/32er-Geräte heute evtl. wieder lohnenswert, sofern sich jemand findet, der 2016.2.x forked und dann dort einen neueren Batman hineinbastelt. (Was durchaus machbar sein sollte meiner Meinung nach. Es muss ja nicht unbedingt 2019.2 sein, ein 2018.4 würde es ggf. auch tun… irgendwo gab es da mal einen breaking-change für 3er-Kernel, weiss aber nicht mehr genau wo.)
Kernel 4.4 ist in LEDE 17.01.x, was als EOL markiert wurde.
Wenn man dort nun nur den Kernel aktualisiert, bleiben Dinge im Userspace offen.
Davon abgesehen zielt das SuperLTS Projekt eher auf Industrieanlagen, Kraftwerke, Züge, etc. - da werden nicht unbedingt Bugs behoben die für Internet/Wifi relevant sind…
Ich glaube vielen hier ist nicht bewusst, was backporting für ein Job ist.
Eine Redhat oder SuSe haben nicht umsonst hunderte Kernelhacker die nichts anderes den ganzen Tag lang machen außer Backports.
Denn es ist eben nicht damit getan mit ich „mache da mal nen alten Kernel rein“, sondern die Module müssen dazu passen, die Userspace Tools wie „ip“, „ifconfig“ etc.
Für ein Opensource Projekt, welches noch dazu eine Nische bedient sehe ich das als unschafbar an.
Und ja, das mag auch meine schwarze Brille sein die ich in ein paar Jahren Berufserfahrung angesammelt habe, denn auch da war ein Fork oder eine Abweichung zum Upstream spätestens nach 2-3 Jahren immer ein Disaster, weil die Pflege immer ein viel zu großer Aufwand wurde.
Ich weiss nicht, wo Du hier „viele“ siehst, denen das nicht bewusst sei.
Mag sein, dass wir jetzt über stille Mitlesende sprechen.
Aber der Vorschlag eines Backportings (egal ob jetzt „alten Kernel in neues Gluon“ oder „neues Batman plus security-fixes in altes Gluon“) ist hier ernsthaft nur von einer Person vorgeschlagen worden. Alle anderen haben es als unrealistisch eingestuft.
Wenn sich Menschen finden, die das ernsthaft in Angriff nehmen möchten und dabei auch mindestens erste Erfolge vorzuweisen haben: Schön.
Aber bis dahin führt die Diskussion zu nichts. (Das ist wie mit „L2TP via IPv6“): Menschen müssen es tun. Es lässt sich aber nicht herbeidiskutieren.
Daher ist es heute schlicht sinnvoller, bestehende Optimierungsmöglichkeiten auszuschöpfen.
Falls also jemand ein Gluon-Patchset bauen sollte, um die von den Weimarern vorgeschlagenen Optimierungen (also jetzt vielleicht nicht „IPv6 abschalten“…) drüberzulegen: Da würde ich mich als Testkandidat melden. Buildsystem plus TestVMs können auch gestellt werden.
Gluon braucht dringend mehr Leute, die sich einbringen. Einen weiteren Branch zu verwalten, ist einfach nicht drin. Dafür wie viele Leute Gluon nutzen, kommt wenig zurück. Wenn ihr irgendwas in Gluon geändert haben wollt, dann lernt wie das funktioniert und bringt euch aktiv ein. Dann werdet ihr auch sehen, dass es wichtigere Themen gibt, die einfach nicht umgesetzt werden.
Wir haben hier ein Memory-Problem mit vielen Clients das auch im Verdacht steht, allgemein Speicherprobleme zu begünstigen. Da muss gerade was geschrieben werden, um die Stelle ausfindig zu machen, wo der ganze Speicher alloziiert wird. ath9k devices run out of memory above certain client count · Issue #1768 · freifunk-gluon/gluon · GitHub
Seit Jahren laufen die Ubiquiti-AirMax-Geräte mit zu viel Sendeleistung.
AR71XX ist bald Geschichte und es muss auf ATH79 umgestellt werden.
Immer weniger Leute haben einen Computer mit Netzwerkport. Gluon muss über WLAN konfigurierbar werden.
Die immer komplexer werdene Netzwerkkonfiguration erfordert viele Änderungen.
Es muss einiges an Dokumentation gemacht werden.
Die Dokumentation soll übersetzt werden, um Nutzer im Ausland anzusprechen.
Keine Ahnung.
Hier geht es darum, was man in Gluon 2018.x machen kann, damit man mehr Ram und Flash freigeschaufelt bekommt. Es geht nicht um zusätzliches Branches.
Um es nochmal zu wiederholen: Wir haben nun mehrfach festgestellt:
Es bringt nichts, gegen Dinge zu argumentieren, die nicht getan werden und für die es auch keine Ansätze gibt, sie zu tun.
Ansonsten könnte ich Dir auch ausführlich begründen, warum es ziemlicher Unsinn ist, Gluon auf VAG-Navis zu portieren.
Sich dem Problem annehmen und ausschließen, dass das eine relevante Auswirkung hat.
Langfristig muss man die sowieso umbauen. Und bis dahin hilft nur, das Netz zu segmentieren. In Hannover haben wir auch noch 600 4/32MB-Geräte und die laufen problemlos, weil wir das Netz segmentiert haben. Trotzdem haben wir jetzt schon 120 Stück umgebaut, weil wir wissen, dass wir langfristig nicht drumherum kommen. 1/6 haben wir also geschafft. Es kostet uns mehr Kraft, eine auswegslose Diskussion zu führen und an der Software rumzufuhrwerken. Wir haben drei Heißluftlötstationen und fähige Leute, das zu machen. Hiermit biete ich Communities bis auf Widerruf an, uns ihre 841er zuzuschicken und die Rückportokosten zu übernehmen. Von 5 umgebauten Routern behalten wir dann 2.
Hi!
Ich habe hier mit Interesse die Beträge verfolgt. Habe selbst noch eine v11 TL-WR814N, die ich vor drei Jahren in meiner alten Wohnung als Knoten betrieben habe. Jetzt hab ich – dank Corona – etwas Zeit und wollte sie mal wieder an den Start bringen und sehe, dass Hannover scheinbar die einzige Community ist, die sich noch um die alten Geräte kümmert.
Meine bescheidene Frage: gibt es jemanden bei euch, der die Kiste auf 16M Flash/64MB RAM gegen Spesen aufrüsten kann?
„scheinbar“ ist vermutlich das richtige Wort.
Mag sein, dass einige 841er-Hater in SocialMedia&Co ziemlich laut sind, es sollte sich jedoch 841er-Firmware in so ziemlich den meisten FF-Domains noch finden lassen.
Da gab es mal Bestrebungen zu, aber der Aufrust-Thread ist woanders. Hier geht’s ja darum, wie/was man mit den bestehenden 4/32MB-Limits machen kann, ohne Aufrüstung.
