[Problem] 7490: seltsames Verhalten mit Firmwareversionen 7.xx und Downgrade nicht möglich

[Massa]

Hallo zusammen,

ich baue mir schon seit Ewigkeiten meine freetz-Versionen für meine 7490-Box aus dem trunk selber.

Ich war immer noch bei AVMs Firmwareversion 6.93 - weil jede 7.xx Version, die ich versucht habe, Probleme gemacht hat.
Jetzt habe ich wieder einmal einen Versuch gestartet und mit 7.12 eine Freetz-Version gebaut (freetz-master-20191030-e1bda347b) - nach Einspielen auf die Box habe ich aber leider.wieder dieses seltsame Verhalten, das ich mir überhaupt nicht erklären kann.

Bisher war dann, nachdem ich wieder einen Downgrade auf eine auf 6.93 basierte Freetz-Version aufgespielt habe, wieder Ruhe und alles hat funktioniert.
Diesmal kommt erschwerend hinzu, dass ein Downgrade auch nicht mehr möglich ist.
Es kommt zuerst ein Syntax-Error für "/etc/version":

/etc/version: line 17: syntax error: unexpected ";;" (expecting "fi")

und am Schluss dann

ERLEDIGT – Rückgabewert des Installationsskripts: 2 (INSTALL_WRONG_HARDWARE)

Von /var/post_install generierter Inhalt:

Fehler: Nach-Installationsskript nicht gefunden oder nicht ausführbar.

So, jetzt zu meinen Problemen mit den Firmwareversion 7.x:
hier bekomme ich zu 99% keine IP-Adresse per DHCP mehr, falls ich mich über das normale WLAN verbinde; manchmal bekomme ich zwar eine IP-Adresse, komme dann aber trotzdem nicht ins Internet und die Namensauflösung funktioniert auch nicht.
Per LAN-Verbindung ist alles O.K. und auch der Internet-Zugang über's WLAN-Gastnetz funktioniert (wenn ich das richtig interpretiere aber nur per IPv6).
In den Logs der Fritzbox ist m.E. eigentlich nichts besonderes zu finden - für mich ist das ganze ein Rätsel.
Zumal die Freetz-Konfiguration der auf Firmwareversion 6.93 aufsetzenden Versionen gleich sind.

Das Verhalten hatte ich schon mit den 7.0er Firmwareversionen und das hat sich auch mit 7.1er Versionen nicht verändert.
Ist da irgendwas in den 7.x-Versionen, was ich noch anders einstellen muss?

Wie bekomne ich heraus, was da schief läuft?

Und wie kann ich wieder einen Downgrade auf 6.93 durchführen?

 

[PeterPawn]

Bug: unable to downgrade via Freetz GUI, ... · Issue #187 · Freetz/freetz

if a FRITZ!OS version is running, where the file /etc/version had get the latest changes (regarding the new way to store version values in /etc/init.d/rc.conf). Only for the records, 'cause no-one ...

github.com

No internet using wifi on 7490 with 7.xy firmware · Issue #87 · Freetz/freetz

I just built 07.01-freetz-devel-15014.en and when I upgrade from 06.84-freetz-devel-14887.en the wifi does not have any connection to internet. Ethernet connection works fine. If you need further d...

github.com

Die Installation über den Bootloader funktioniert aber weiterhin und wenn man seine Images signiert (und die installierte Version den Key enthält), lassen sich Images auch über das AVM-GUI installieren, solange es sich nicht um ein Downgrade handelt. In diesem Falle müßte man die "/var/install" in der AVM-Firmware modifizieren, damit sie die Versionsprüfung übergeht. Wie man in den oben verlinkten Quellen nachlesen kann, scheitert es bei Freetz auch genau an diesem "Verändern" der Versionsnummer, was nicht mehr zu aktueller AVM-Firmware paßt.

 

[Massa]

Hmm, habe jetzt gerade gesehen, dass es inzwischen mehrere freetz-Varianten gibt.
Ich bin da sehr verwirrt - welche ist denn jetzt zu empfehlen / verwenden?
Die "alte" aus dem svn (http://svn.freetz.org/trunk)?
Die "neue" aus dem svn (https://svn.boxmatrix.info/freetz-ng/trunk)? (die finde ich aber sehr verwirrend in den Menüoptionen..- vielleicht, weil sie ungewohnt ist).
Die aus dem git (https://github.com/Freetz/freetz.git)? (das ist die, die ich in letzter Zeit verwendet habe)
Der git-Fork von PeterPawn (https://github.com/PeterPawn/YourFreetz.git)? (der bricht aktuell allerdings bereits bei "make menuconfig" mit einer Fehlermeldung ab)

Sonst noch irgendwelche Optionen ?

 

[PeterPawn]

Mein Fork ist nicht primär für die Nachnutzung gedacht ... wobei er trotzdem funktionieren sollte; bei mir tut er das jedenfalls (der "YourFritz"-Branch, der ist dort auch der führende und nicht "master").

Deine Probleme sind m.W. in keiner der beiden Versionen (freetz (GitHub) oder freetz-ng (SVN)) gelöst ... nimmt sich also nichts, Du mußt (afaik) bei beiden selbst Hand anlegen.

 

[Massa]

Bug: unable to downgrade via Freetz GUI, ... · Issue #187 · Freetz/freetz

if a FRITZ!OS version is running, where the file /etc/version had get the latest changes (regarding the new way to store version values in /etc/init.d/rc.conf). Only for the records, 'cause no-one ...

github.com

No internet using wifi on 7490 with 7.xy firmware · Issue #87 · Freetz/freetz

I just built 07.01-freetz-devel-15014.en and when I upgrade from 06.84-freetz-devel-14887.en the wifi does not have any connection to internet. Ethernet connection works fine. If you need further d...

github.com

Danke PeterPawn - ich hatte das inzwischen auch bereits bei meiner Suche gefunden - aber was ist denn jetzt die Lösung / Workaround dafür? Auf die Box gehen und /etc/version von Hand editieren?
Das Problem besteht ja anscheinend schon eine ganze Weile...
Auf den ersten Blick sieht es nach einem "kleinen" Scriptfehler aus - aber wahrscheinlich ist das komplizierter als es aussieht?!

Und v.a. hat jemand eine Idee was da bei mir mit den 7.x-Firmwareversionen los ist? Wenn die funktionieren würden, bräuchte ich keinen Downgrade

Mein Fork ist nicht primär für die Nachnutzung gedacht ... wobei er trotzdem funktionieren sollte; bei mir tut er das jedenfalls (der "YourFritz"-Branch, der ist dort auch der führende und nicht "master").

Ja, den "YourFritz"-Branch hatte ich bereits verwendet.
Ist das Downgrade-Problem denn in Deinem Fork gelöst?

Das hier kommt, wenn ich "make menuconfig" aufrufe:

Cannot open include file make/privatekeypassword/Config.in.libs in make/libs/Config.in
No such file or directory at tools/parse-config line 22, <$fh> line 250.
<none>:40864: syntax error
config/.cache.in:24477: missing end statement for this entry
Makefile:374: recipe for target 'menuconfig' failed
make: *** [menuconfig] Error 1

 

[PeterPawn]

Das hier kommt, wenn ich "make menuconfig" aufrufe:

Ich denke mal, das liegt am "unvollständigen" Klonen des Repos - das muß hier inkl. "submodules" erfolgen, damit die zwei anderen Projekte, die als separate Repositories existieren (decoder und privatekeypassword), auch auf der eigenen Platte landen. Wie das geht, verrät die man-page von "git" bzw. irgendwo habe ich das auch mal aufgeschrieben (bei der Telnet-Geschichte zur 7580, iirc).

Ansonsten habe ich ja geschrieben, daß man bei einem geplanten Downgrade problemlos über den Bootloader installieren kann ... dieses Vorgehen funktioniert praktisch IMMER und ist wohl auch der Grund dafür, daß sich niemand diesem Thema widmet - soll heißen, es ist in meinem Fork erst recht nicht gelöst, weil der sich mit nichts befaßt, was mit einem Freetz-Image zu tun hat; bei den Paketen ist "Ende Gelände" und ich lasse i.d.R. nicht mal mehr Images erstellen bei meinen eigenen Build-Läufen.

Wenn ich daran tatsächlich mal etwas machen sollte/wollte, würde ich ohnehin nur diese "downgrade"-Option entfernen - in meinen Augen braucht die niemand und der Aufwand, das auf die Änderungen bei "/etc/version" und "/etc/init.d/rc.conf" umzustellen, wäre komplett verschenkte Zeit.

Und das WLAN-Problem sollte ja ebenfalls nicht mehr existieren, wenn man einfach noch einmal das "ifup wlan" beim Start aufruft, nachdem der Rest der Interfaces bereit ist - dazu habe ich ja auch den anderen Link geliefert, da findet sich bestimmt auch noch der eine oder andere Thread im IPPF zu diesem Problem.

Nach dem, was ich dazu bisher gelesen habe, landen dann die WLAN-Interfaces auch wieder in der "lan"-Bridge und das war - bei dem, was ich bisher selbst gesehen oder von anderen gelesen habe - der Knackpunkt. Es ist also alles lange nicht sooo kompliziert, wie Dir das jetzt vielleicht erscheinen mag und andere benutzen (so zumindest die Sage) die neuen Versionen ja auch.

EDIT: Das mit dem Klonen läuft nur suboptimal ... da gibt es tatsächlich ein Problem im Repository und ich muß mir erst mal etwas überlegen, wie ich das besser löse. Zwar enthält die ".gitmodules" die beiden anderen Projekte, aber ein "git clone --recurse-submodules" funktioniert trotzdem nicht wie erwartet (und wie es früher schon funktionierte).

EDIT2: OK, das Klon-Problem habe ich jetzt hoffentlich behoben - wie man das Kommando richtig eingibt, steht hier: https://github.com/PeterPawn/YourFreetz
Ursache der Probleme waren die unterschiedlichen Services beim Zugriff - ich verwende SSH für die Verwaltung des Repos, aber die URLs zum Klonen müssen auf HTTPS basieren, weil ansonsten jeder Benutzer erst sein eigenes GitHub-Konto einrichten müßte, um SSH verwenden zu können. Mit den jetzt benutzten relativen URLs sollte für die "submodules" dasselbe Protokoll zum Klonen genutzt werden, wie für das Haupt-Repo und es sollte sowohl mit SSH als auch mit HTTPS funktionieren.

 

[Massa]

Ansonsten habe ich ja geschrieben, daß man bei einem geplanten Downgrade problemlos über den Bootloader installieren kann ... dieses Vorgehen funktioniert praktisch IMMER und ist wohl auch der Grund dafür, daß sich niemand diesem Thema widmet

Das mag sein - aber alles, was über den Bootloader zu machen ist (und nicht über das bestehende Netzwerk machbar ist), ist bei mir immer mit größerem Aufwand verbunden, weil ich physisch nicht so einfach an die Box rankomme.

soll heißen, es ist in meinem Fork erst recht nicht gelöst, weil der sich mit nichts befaßt, was mit einem Freetz-Image zu tun hat; bei den Paketen ist "Ende Gelände" und ich lasse i.d.R. nicht mal mehr Images erstellen bei meinen eigenen Build-Läufen.

Bei mir ist dir Fritzbox mit Freetz nach wie vor Dreh- und Angelpunkt in meinem Home-Netzwerk; soll heißen: DNS, DHCP, OpenVPN, ntpd, Firewall, ... alles läuft über die Box (und freetz) - von dem her bin ich nach wie vor an guten und funktionierenden freetz-Versionen interessiert.
Für was machst Du denn Deinen Fork / für was benutzt Du ihn (die Unterschiede zum upstream habe ich gelesen, nur nicht den Grund verstanden)?

Wenn ich daran tatsächlich mal etwas machen sollte/wollte, würde ich ohnehin nur diese "downgrade"-Option entfernen - in meinen Augen braucht die niemand und der Aufwand, das auf die Änderungen bei "/etc/version" und "/etc/init.d/rc.conf" umzustellen, wäre komplett verschenkte Zeit.

das sehe ich (s.o.) anders...

Und das WLAN-Problem sollte ja ebenfalls nicht mehr existieren, wenn man einfach noch einmal das "ifup wlan" beim Start aufruft, nachdem der Rest der Interfaces bereit ist - dazu habe ich ja auch den anderen Link geliefert, da findet sich bestimmt auch noch der eine oder andere Thread im IPPF zu diesem Problem.

Ja, den habe ich zuerst irgendwie übersehen

Ich habe jetzt mal beim Issue-Eintrag etwas dazu geschrieben - vielleicht hilft es, dem Problem weiter auf die Spur zu kommen.

EDIT2: OK, das Klon-Problem habe ich jetzt hoffentlich behoben - wie man das Kommando richtig eingibt, steht hier: https://github.com/PeterPawn/YourFreetz

Ja, das "make menuconfig" funktioniert jetzt - weiter habe ich noch nicht probiert

Vielen Dank Peter für Deine schnelle Hilfe!

 

[PeterPawn]

Für was machst Du denn Deinen Fork

1. Weil es eben ein paar Änderungen gibt, die es erlauben, dynamisch Erweiterungen der Firmware nachzuladen, die nicht von Beginn an in das Image eingebaut werden. Damit kann man den direkten Zusammenhang zwischen der AVM-Firmware und den Erweiterungen aufheben und sie unabhängig voneinander aktualisieren. Zwar muß man dabei noch viel Hand anlegen und in die originale Firmware ein paar Hooks einfügen (also Punkte, an denen diese Erweiterungen eingehangen werden können), aber man muß nicht bei jedem Paket-Update in Freetz bzw. bei jeder neuen AVM-Version das Ganze komplett austauschen - es reicht der jeweils betroffene Teil.

2. Da ich auch noch einiges an vorkompilierten Programmen (mit Signatur für die Sicherung der "Urheberschaft" dieser Binaries) für diejenigen bereitstelle, die entweder "modfs" benutzen oder irgendein anderes "Angebot" aus meinem YourFritz-Repository (wo diese Binaries als "bin"-Unterverzeichnis eingebunden sind), bin ich nach GPL auch verpflichtet, die entsprechenden Quelltexte für diese Programme bereitzustellen und kann mich dabei nicht auf andere berufen - (a), weil es einige Änderungen (und nicht nur an den Freetz-Dateien, sondern auch an den Paketquellen beim Übersetzen) gibt und (b) weil es kein Angebot eines "Vorleisters" gibt (anders als bei den AVM-Komponenten), mit dem man die GPL-Bestimmungen aus §3 Buchstabe b oder c alternativ erfüllen könnte. Also bleibt für mich nur §3 Buchstabe a und die Bereitstellung dieser Quellen an einem frei zugänglichen Ort im Internet - das dürfte GitHub leisten. Soo ganz 100% ist das allerdings auch noch nicht ... theoretisch müßte ich wohl auch noch die Quelltext-Pakete der jeweils genutzten Pakete selbst in Kopie bereitstellen. Aber für ein nicht-kommerzielles Projekt sollte es auch ausreichend sein, daß die jeweiligen Freetz-Pakete (zumindest bei den Programmen, die ich auch als Binary bereitstelle) sich beim Download aus den originalen Paketquellen bedienen.

3. Weil es Änderungen gibt, die ich benötige, die aber (aus verschiedensten Gründen) keinen Einzug in das Upstream-Projekt gehalten haben - ein erheblicher Teil aus meinem Fork ist ja auch in den anderen beiden Versionen (bei "freetz-ng" dann über die "Verwandschaft" mit "freetz") zu finden.

4. Weil der Besitz eines "eigenen Forks" (des Upstream-Repos) nun mal bei Git zu den Voraussetzungen einer Zusammenarbeit gehört - aus diesem werden dann die entsprechenden Pull-Requests erzeugt (wenn man es systematisch richtig angeht und seine Änderungen in passenden Branches organisiert), mit denen das Upstream-Projekt (i.d.R. konfliktfrei) geändert werden kann.

Ich denke mal, das sind drei Gründe mehr für den eigenen Fork, als es bräuchte ...

---------------------------------------------------------------------------------------

Da Du auch problemlos Deinen eigenen Fork (zumindest in GitHub) erzeugen kannst, ist es auch kein (echtes) Problem, Deine Aufgabenstellung "Downgrade ohne Vor-Ort-Präsenz" selbst einer Lösung zuzuführen.

Wie man das machen könnte bzw. wie man das (neue) "install"-Skript von AVM doch zu einem Downgrade veranlaßt, habe ich hier: https://www.ip-phone-forum.de/threads/sammelthema-für-fb-7490-mit-labor-firmware-intern.281201/post-2307607 notiert.

Man muß also nur dafür sorgen, daß der (merkwürdige) Freetz-Ansatz, die "/etc/version" des laufenden Systems zu modifizieren (partiell kann ich die Intention dabei nachvollziehen und es funktioniert(e) damit auch über mehrere Versionsnummern hinweg), unterlassen wird und stattdessen das erwähnte Skript mit der Option "-d" aufrufen.

Das sind wenige Zeilen ... da bei Freetz aber die heilige Kuh der Rückwärtskompatibilität nur selten geschlachtet wird, würde so eine "schlanke Lösung" vermutlich (in diesem Falle auch zu Recht, weil die 06.8x-Versionen das anders handhaben müßten) keinen Einzug in das Projekt halten können.

Man müßte also erst für den Upstream noch eine Unterscheidung einbauen, um welche Firmware-Variante es sich handelt (zumal das jeweilige "install"-Skript auch noch aus der neu zu installierenden Version stammt und der andere Code aus der laufenden) - die Änderungen an anderen Stellen erfolgten ja nach einem ähnlichen Schema (Bsp.: https://github.com/Freetz/freetz/pull/118).

EDIT: Verzichtet man auf die Installation OHNE das Löschen der alten Einstellungen, kann man auch einfach das "install"-Skript mit "-f" aufrufen ... das kann auch schon das Skript in älterer Firmware leisten, nur die "-d"-Option zum Downgrade ohne Löschen ist neu. Wobei ein solches "Downgrade" mit der "-f"-Option für eine Box, an die man ansonsten nicht herankommt, ja wohl ebenfalls keine Option darstellt ... man kann dort ja dann nicht mal die 2FA so ganz ohne Probleme ausschalten, solange man kein ISDN- oder Analog-Telefon an der Box hängen hat (was aus der Ferne auch nichts nutzt). [Ende der Einfügung]

Aufgrund der ohnehin wieder zu erwartenden unterschiedlichen Ansichten, wie und wo man das nun implementieren müßte, spare ich mir jedenfalls diese Arbeit (inzwischen) gleich ganz - der Mangel an Notwendigkeit in meinen Augen ist da nur noch ein zweiter Faktor.

Ähnliches gilt für das WLAN-Problem ... es wäre ja keine Hürde, bei den 7490- und 3490-Modellen (iirc tritt das nur bei diesen auf und würde auch bei anderen kaum schaden, außer daß es ggf. noch einmal die WLAN-Verfügbarkeit kurzzeitig unterbricht) noch einen zusätzlichen Start für das "wlan"-Interface als Workaround in irgendeine Skript-Datei von Freetz einzubauen ... zu diesem Zeitpunkt ist der Rest des Systems i.d.R. schon bereit.

Ich habe nur keine Lust auf die zu erwartenden Diskussionen, ob das dann richtig oder gerechtfertigt oder was auch immer ist bzw. ob man nicht lieber die Ursache untersuchen müßte, usw. - das ist ebenfalls die Zeit nicht wert, das habe ich bei anderen "Problemen" in mehreren Anläufen lernen müssen.