fwmod 7390 6.51

[oelidoc]

Hallo BurningCrash,
das gleiche hier (s.o) Eine 6.51 mit telnet läuft, eine 6.51 mit telnet und debug.cfg killed die Telefonie. Das lange Wochenende ist vorbei, jetzt muss die FB erst mal wieder funktionieren, deshalb z.Zt. 6.30.
Wenn ich dazu komme, mache ich aber gerne noch ein paar Versuche mit.

Gruß

oelidoc

 

[Riverhopper]

Hallo oelidoc, hallo BurningCrash,
ich denke hier sind irgendwie ein freetz-patches reingelaufen.

Lösungsvorschlag, siehe PP #18:

Ich stelle mal die Behauptung auf (ohne das belegen zu können, das dauert mir jetzt zu lange), daß man bei der Verwendung von fwmod zum Entpacken und Packen der Firmware auch wirklich nach jedem Packen der Firmware das temporär verwendete Verzeichnis (also sowohl "original" als auch "modified") komplett löschen sollte (am besten sogar die eigentliche Basis - hier also "unpacked_firmware") ... ich habe bei einem Test da mal sehr sehr merkwürdige Ergebnisse erzielt, wenn man nach dem ersten Packen noch weitere Änderungen an der "modified"-Struktur vornehmen und diese dann erneut packen wollte. Damals habe ich das auf die Verwendung von "fakeroot" geschoben ... ob das absolut richtig war oder wo der beobachtete Effekt ansonsten herkommen könnte, habe ich nie wieder richtig untersucht - ich führe solche Aktionen halt nur noch als Benutzer "root" aus (und nicht auf Ubuntu, wo das ja eigentlich immer über "sudo" laufen soll) und dann traten/treten diese Phänomene nicht mehr auf.

d.h. Verzeichnis "unpacked_firmware" wegmoven oder löschen

freetz@freetz-vm:~/freetz-devel$ mv unpacked_firmware unpacked_firmware._save_

und dann fwmod (Schritt 5. aus #7) nochmals anstarten.

LG Riverhopper

 

[oelidoc]

Hallo Riverhopper,

getreu der Empfehlung von PeterPawn in einem älteren Thread http://www.ip-phone-forum.de/showthread.php?t=280058&p=2110386&viewfull=1#post2110386 lösche ich schon immer das gesamte Verzeichnis unpacked_firmware vor jedem Auspacken, Modifizieren und erneutem Packen der FW. Daran sollte es also eigentlich nicht liegen.

Gruß

oelidoc

- - - Aktualisiert - - -

Hallo,
darf ich freundlicherweise diese naive Frage noch einmal in den Raum stellen, hatte bisher dazu noch nix gehört:

Kann ich die debug.cfg nicht auch mit

sed -i '/echo 1 > \/proc\/sys\/kernel\/panic_on_oops/ a\
if [ -z "$CPU_NR" ] || [ "$CPU_NR" = "1" ] ; then\
mknod /var/flash/debug.cfg c $tffs_major $((0x62))\
if ! /usr/bin/checkempty /var/flash/debug.cfg 2>/dev/null; then\
. /var/flash/debug.cfg\
fi\
fi' "unpacked_firmware/original/filesystem/etc/init.d/rc.tail.sh"

rein kriegen. Ich meine, das hätte letzte Woche bei der 6.51. geklappt.

Gruß
oelidoc

 

[PeterPawn]

@oelidoc:
Ja, das geht auch (hat halt etwas andere Möglichkeiten bzw. Einschränkungen zur Folge, was man in der debug.cfg alles anstellen kann und darf) ... sollte das aber damit anstelle des anderen Kommandos funktionieren, wäre das extrem überraschend. Es ist nur ein abgewandelter Aufruf der Befehle in der "debug.cfg" (oder meinetwegen der rc.user) und der sollte keinerlei Auswirkungen auf die Abarbeitung der Kommandos an sich haben.

Auch der Zusammenhang zwischen "debug.cfg" und der Telefonie ist irgendwie alles andere als einleuchtend - bei Telefonie und telnetd hätte man ja noch über den Start des Telnet-Daemons durch den "telefon"-Daemon einen Zusammenhang konstruieren können ... das fällt bei der "debug.cfg" und der "Telefonie generell" eher schwer. Abgesehen davon ist natürlich "Telefonie geht nicht" als Fehlerbeschreibung recht dünn ... schon der Umstand, ob der "telefon"-Daemon wirklich gestartet ist (das zeigt die Prozessliste in den Support-Daten selbst bei originaler Firmware), wäre das erste Fragezeichen und das zieht sich bis zum aktuellen "Zustand" des Telnet-Flags in der "fx_conf" weiter.

Aber wenn die Kombination "Telnet-Daemon" und "Telefonie" einwandfrei funktioniert (so habe ich BurningCrash verstanden), dann ist das ohnehin die falsche Baustelle und ich würde (ohne jemandem zu nahe treten zu wollen, mir fällt halt keine andere ausreichend wahrscheinliche Erklärung ein) eher auf ein Problem bei Erstellen des neuen Firmware-Images tippen.

Ich probiere gerade mal selbst aus, was man wie bei der 7390 machen könnte ... ich habe gerade erst festgestellt, daß bei der 7390 (ist eine der wenigen NOR-Boxen, die ich noch habe/verwende) eine erhebliche Zeit (knapp 20 Sekunden) zwischen dem "STOR MTD1"-Kommando und der Reaktion in Form von "150 Opening BINARY data connection" liegt. Das ist vermutlich der Zeitraum, in dem EVA erst einmal den Flash-Speicher an der Stelle löscht, wo anschließend hineingeschrieben werden soll und das braucht natürlich etwas (kein Vergleich zu den "kleinen Partitionen" mit den TFFS-Images) - ich muß also erst einmal ein paar Skript-Dateien so anpassen, daß da lange genug auf die Nachricht der Box gewartet wird. Ich hatte bisher halt nicht so oft einen Anlaß, eine 7390 über den Bootloader zu flashen und bin erst jetzt (als ich das mal von Beginn an nachvollziehen wollte) über diese Pause gestolpert.

 

[oelidoc]

Hallo zusammen,
ich habe jetzt noch mal alles durchgespielt:

mkdir -p unpacked_firmware

./fwmod -u -d unpacked_firmware dl/fw/FRITZ.Box_Fon_WLAN_7390.AnnexB.84.06.51.image


sed -i '/echo 1 > \/proc\/sys\/kernel\/panic_on_oops/ a\
if [ -z "$CPU_NR" ] || [ "$CPU_NR" = "1" ] ; then\
mknod /var/flash/debug.cfg c $tffs_major $((0x62))\
if ! /usr/bin/checkempty /var/flash/debug.cfg 2>/dev/null; then\
. /var/flash/debug.cfg\
fi\
fi' "unpacked_firmware/original/filesystem/etc/init.d/rc.tail.sh"


[COLOR=#333333][ -x unpacked_firmware/original/filesystem/usr/sbin/telnetd ] || ln -s  ../../bin/busybox unpacked_firmware/original/filesystem/usr/sbin/telnetd

[/COLOR][COLOR=#333333]
./fwmod -p -d unpacked_firmware FRITZ.Box_Fon_WLAN_7390.84.06.51.image[/COLOR]

und erhalte eine funktionierendes Image, mit dem ich die FB 7390 problemlos von 6.30 auf 6.51 per webinterface updaten kann.

Telnet funktioniert

nach Reboot und Eingabe von

[COLOR=#333333]ls -la /var/flash/debug.cfg[/COLOR]

erhalte ich

crw-r--r--    1 root     root      250,  98 Jan  1  1970 /var/flash/debug.cfg

Demnach müsste die debug.cfg vorhanden sein, oder?
Leider bin ich zu blöd, den LCR von Harald Becker reboot-fest in die debug.cfg zu bekommen. Ich habe mit dem shell Befehl aus seiner Anleitung den LCR erfolgreich installieren können (die Installation per FW update geht ja bei der 6.51 nicht mehr). Allerdings übersteht der LCR ein Reboot der FB nicht.
Vielleicht könnte mich ja noch mal jemand auf den richtigen Weg schubsen...

Gruß

oelidoc

 

[BurningCrash]

@oelidoc

klappt das jetzt auch mit der Telefonie?

 

[Riverhopper]

Hallo oelidoc,
congratulations!!!

crw-r--r--    1 root     root      250,  98 Jan  1  1970 /var/flash/debug.cfg

es freut mich, dass telnetd und debug.cfg nun so wie es aussieht funktionieren ;-)

ich werde den debug.cfg-Reaktivierungs-Befehl

sed -i '/echo 1 > \/proc\/sys\/kernel\/panic_on_oops/ a\
if [ -z "$CPU_NR" ] || [ "$CPU_NR" = "1" ] ; then\
mknod /var/flash/debug.cfg c $tffs_major $((0x62))\
if ! /usr/bin/checkempty /var/flash/debug.cfg 2>/dev/null; then\
. /var/flash/debug.cfg\
fi\
fi' "unpacked_firmware/original/filesystem/etc/init.d/rc.tail.sh"

in die Dokumentation aufnehmen.

Allerdings übersteht der LCR ein Reboot der FB nicht.
Vielleicht könnte mich ja noch mal jemand auf den richtigen Weg schubsen...

Vorschlag: TSB bei FW 06.30 installieren und dann den Update mit dem gemoddeden FW 06.51 per Web-IF durchführen.
Alternativ wäre denkbar folgende Zeilen in debug.cfg aufnehmen.

##############################################################
while [ x$(ctlmgr_ctl r connection0 status/connect) != x"5" ]; do sleep 1; done
#
wget -O - http://telefonsparbuch.de/software/fritzbox/installflash | sh 
##############################################################

siehe auch http://www.ip-phone-forum.de/showthread.php?t=284075&p=2153601&viewfull=1#post2153601


LG Riverhopper

 

[PeterPawn]

Ich will noch etwas zum Starten der Kommandos in der "debug.cfg" anmerken ... früher war es so, daß bei "falschen" Kommandos in der "debug.cfg" nur relativ unbedeutende weitere Teile der Firmware betroffen waren (die hinter dem Aufruf der "debug.cfg" kamen), wie z.B. der Power-Monitor.

Inzwischen wird aber nach der "alten Stelle" der Abarbeitung der "debug.cfg" noch der "ctlmgr" darüber informiert, daß nunmehr die Initialisierung beendet ist und theoretisch (so ganz klar ist das - wohl auch den maßgeblichen Leuten bei AVM - nicht, wie wir anhand der tatsächlich ausgeführten Aufrufe von "/sbin/start_plugin.sh" irgendwann zu Beginn des Jahres festgestellt haben) startet dann die Initialisierung der Plugins. Da dazu jetzt auch das WLAN gehört, ist es vermutlich wirklich wichtig, daß man nicht durch unbedachte Kommandos in der "debug.cfg" die Abarbeitung dieser Kommandos "abwürgt". Ein schönes Beispiel für einen solchen Fehler wäre z.B. die Verwendung von "exit" in der "debug.cfg", wenn diese - wie oben zu sehen - über "source" (bzw. den Punkt, was dasselbe bewirkt) eingebunden wird. Dann wird nämlich nicht nur die Abarbeitung der Befehle in der "debug.cfg" beendet, sondern die komplette "rc.tail.sh" bzw. tatsächlich sogar die komplette "/etc/init.d/rc.S" (das ist die Schleife über die Dateien in "/etc/init.d"). Das hat am Ende ungeahnte/unerwartete Konsequenzen.

Daher rate ich dringend davon ab, die "debug.cfg" wieder an der alten Stelle einzubinden ... es sei denn, man ist wirklich sattelfest, wenn es um Subshells und "detached processes" geht, denn das ist eine weitere Auswirkung dieses Aufrufs, daß jeder Prozess, der ohne entsprechende Gegenmaßnahmen gestartet wird aus der "debug.cfg" (das wäre z.B. auch irgendein gesondertes Skript, das in einer Schleife ewig laufen soll) am Ende der "rc.tail.sh" (denn da hat AVM ein "exit 0" untergebracht) gnadenlos mit abgeräumt wird, was nicht wenige als "wurde gar nicht gestartet" interpretieren, wie die Vergangenheit mehrfach gezeigt hat (s. entsprechende Tickets in Freetz, wo das aber auch schon etwas anders gelöst ist als bei AVM).

Bindet man die eigenen Kommandos in dieser Datei so ein, wie ich es beim 7490-modscript "empfehle", hat der Inhalt der Datei keine Chance mehr, den Initialisierungsprozeß irgendwie zu beeinflussen (und selbst eine mäßig falsche "debug.cfg" kann keinen Schaden mehr anrichten).

Ich kann mir auch beim besten Willen nicht vorstellen, inwiefern der (sichere) Weg des Aufrufs am Ende der "rc.tail.sh" (und dann auch noch als "detached process" über das "delay"-Kommando) irgendeine Auswirkung auf die Telefoniefunktionen haben sollte ... insofern gehe ich (bis zum Beweis des Gegenteils) immer noch von einem Fehler beim Modifizieren der Firmware aus, der dann halt bei der Verwendung des anderen Kommandos zum Editieren der "rc.tail.sh" nicht gemacht wurde.

Also bitte nicht das Kind mit dem Bade ausschütten ... der "Vorschlag" zur Einbindung der Kommandos aus der "rc.user"/"debug.cfg" hatte schon gute Gründe - zumindest kann man dann als Benutzer auch nicht mehr so sehr viel falsch machen durch die Verwendung ungeeigneter Kommandos in der "debug.cfg".

- - - Aktualisiert - - -

Ich habe eine Testbox mit Telnet-Daemon und aktivierter (aber bis auf ein "eventadd" leerer) "rc.user" auf einer 7390 getestet und habe keine Ausfälle bei der Telefonie bemerkt ... allerdings habe ich auch nicht so richtig verstanden, was da nun genau nicht funktionieren soll.

 

[oelidoc]

@BurningCrash

klappt das jetzt auch mit der Telefonie?

ja, da ich von der 6.30 aus upgedated habe, hat er sämtliche Einstellungen übernommen - ich brauchte nix ändern / ergänzen - alles lief wie immer. Nur der LCR hat unter 6.51 noch ein Problem mit der Darstellung oder der Anlage der Wahltabelle. Aber das muss Harald Becker fixen...

@Riverhopper

Alternativ wäre denkbar folgende Zeilen in debug.cfg aufnehmen.
Code:
##############################################################
while [ x$(ctlmgr_ctl r connection0 status/connect) != x"5" ]; do sleep 1; done
#
wget -O - http://telefonsparbuch.de/software/fritzbox/installflash | sh

Tja, aber wie kriege ich das in die debug.cfg rein. Mit

[COLOR=#333333]nvi /var/flash/debug.cfg[/COLOR]

bekomm ich unter putty immer no such file or directory

Gruß
oelidoc

- - - Aktualisiert - - -

@PeterPawn
auch wenn ich als Laie nur einen kleinen Teil deiner Ausführungen unter #48 verstanden hab, so will ich doch gerne versuchen, etwas davon umzusetzen. M.E. ist der Fehler mit der Telefoniestörung reproduzierbar und bei zwei Nutzern unabhängig voneinander aufgetreten. Er besteht darin, dass nach dem Flashen kein Telefonieren möglich ist, weil in der FB keine Telefonnummern hinterlegt sind (in meinem Fall Telekom VOIP). Der Versuch, die Nummern im Webinterface einzutragen, scheitert: nach Übernahme der Eingaben wird die Seite zwar verlassen, ist aber beim nächsten Aufruf wieder leer.

Wie ich dir schon einmal erzählt habe, habe ich von Linux, Freetz, modfs, Scripten etc so gut wie keine Ahnung - ich kann nicht kochen, nur Rezepte nachkochen. Morgen (oder bei Zeiten) werde ich mich noch mal etwas weiter einlesen, vielleicht versteh ich ja dann wieder ein klein bisschen mehr....
Und ich kann gerne noch mal nach deinen Anweisungen ein Image mit Telnet, debug.cfg und am liebsten auch gleich TSB LCR erstellen und auf meiner Box testen.
Hab bitte Geduld
Gruß
oelidoc

 

[Riverhopper]

Nur der LCR hat unter 6.51 noch ein Problem mit der Darstellung oder der Anlage der Wahltabelle.

Hallo oelidoc,
Frage: kann es sein, dass die Telefonie-Störung mit der LCR-Installation zusammenhängt;

Vorschlag: FB7390 mit gemoddeder FW 06.51 mal ganz ohne LCR-Installation inbetriebnehmen und dann Telefonie-Funktion testen,

Ich habe mit dem shell Befehl aus seiner Anleitung den LCR erfolgreich installieren können (die Installation per FW update geht ja bei der 6.51 nicht mehr).

Welchen CLI-Befehl verwendest Du ? was wird hier gemacht ?
wird hier am Verzeichnis /usr/www/avm/assis was geändert ?

mount -o bind /usr/www/avm/assis /var/tmp/tsb/var/orgwww/assis

siehe http://www.ip-phone-forum.de/showthread.php?t=261969&p=1938486&viewfull=1#post1938486

LG Riverhopper

 

[PeterPawn]

@oelidoc:
Ok, das ist jetzt die Beschreibung eines Fehlers bei der Telefonie, wobei mir auch noch unklar ist, ob der nun bei der älteren (falschen) Kommandofolge von @Riverhopper auftrat oder erst danach.

Damit daraus jetzt zwei identische Fehlerbilder werden, müßte aber schon bei BurningCrash genau dasselbe Problem auftreten und dann verstehe ich immer noch nicht, warum eine (bei Dir ja offenbar leere) "debug.cfg" (die ja dann gar keine Kommandos enthält, die da abgearbeitet werden könnten und damit die Telefonie irgendwie behindern würden) zu dem "Telefonie-Problem" führen sollte. Das dürfte dann eher ein - im Resultat - falsches Kommando zum Aufruf der "rc.user" sein - wobei selbst das keinen Einfluß haben dürfte.

Wie oft hast Du denn ein entsprechendes Image für die Verwendung von Telnet und "debug.cfg" erstellt und wie oft hast Du genau dasselbe Image noch einmal auf die Box übertragen? Womit hast Du das gemacht und ist das tatsächlich jedesmal fehlerfrei absolviert worden (ich tippe mal auf das ruKernelTool für die modifizierte Firmware)?

Ich will - ehrlich gesagt - noch nicht so richtig der Behauptung, es handele sich um ein reproduzierbares Verhalten, zustimmen ... wenn das tatsächlich so wäre (die Fehlerbeschreibung von BurningCrash kenne ich ja noch nicht), würde ich auch hier am ehesten auf die Verwendung der gleichen - falschen - Kommandos beim Modifizieren tippen. Ich konnte/kann jedenfalls auch bei einem nur minimal modifizierten 7390-Image (Telnet-Daemon aktiviert und die letzte Zeile der rc.tail.sh durch

rcuser=/var/tmp/rc.user;mkconfigfile $rcuser.tffs 98;cat $rcuser.tffs >$rcuser;rm $rcuser.tffs;test -s $rcuser && delay -d 1 RCUSER "/bin/sh $rcuser"

ersetzt - es gibt da also kein "exit 0" mehr) problemlos Internet-Nummern hinzufügen, ändern, löschen (auch ISDN habe ich getestet zu konfigurieren) ... es wäre auch sehr komisch, wenn das nicht ginge.

Am ehesten sehe ich noch einen Zusammenhang zwischen den "verschwundenen Telefonnummern" und der Unmöglichkeit, da neue und richtige Nummern einzutragen. Das kann aber ganz simpel auch an falschen Einstellungen in den Telefoniedateien liegen (die sind binär ... z.B. die fx_conf) und so ein Problem würde man dann durch das Recovern mit der originalen Firmware von AVM mit anschließendem Wiederherstellen der eigenen gespeicherten Einstellungen auch gleich wieder korrigieren (womit dann die Erfolgsmeldung "mit 06.30 geht es" an Wert verliert). Wenn man nur mittels FTP-Session zum Bootloader das vorherige System wiederherstellt (ohne MTD3/MTD4 anzufassen - egal ob mit ruKernelTool oder von Hand), wäre das - in gewissen Grenzen - wieder etwas anderes ... aber das sind eben alles reine Spekulationen, die man hier anstellen kann/muß, weil die Informationen zum genauen Vorgehen (und damit die Möglichkeit der Reproduktion des Fehlverhaltens) fehlen (oder ich finde sie nur nicht, was auch denkbar wäre).

Jedenfalls sagt so ein Fehler dann auch eher etwas über den Weg des Applizierens der Firmware (ob nun mit oder ohne Löschen von Einstellungen, usw.) aus als über den Inhalt der dabei verwendeten Firmware-Datei. Solange man also die Ursache nicht sauber ermittelt, bleibt es in meinen Augen fahrlässig/unbewiesen, wenn man da einen Zusammenhang zwischen "Telefonie-Versagen" und Aktivierung der "rc.user" über das oben gezeigte Kommando postuliert.

Wenn meine Vermutung mit einer geschroteten (ich meine "schroten" und nicht "schrotten") Telefoniekonfiguration stimmen sollte, würde schon das Wiederherstellen der vorher gesicherten Konfiguration das Problem wieder beheben ... ob solche Versuche überhaupt stattgefunden haben bzw. welches Ergebnis sie erbrachten, kann ich aber auch nicht finden.

PS: "debug.cfg" und "rc.user" sind praktisch dieselbe Datei, ich verwende den ersten Namen immer dann, wenn es um das Einbinden an der "alten Position" geht und den zweiten nur dann, wenn es sich um die asynchrone Abarbeitung in einem "detached process" dreht.

 

[BurningCrash]

Also bei mir war es so das mit dem "Waschzettel" von Riverhopper von Seite 1 ich ein valides Image bekam was ich mit dem ruKernelTool flashen konnte. Die Box hat auch brav gebootet, jedoch lies sich keine Rufnummer (egal ob VoIP oder ISDN einrichten).
Habe mich jetzt noch nicht weiter durch die restlichen Post gegraben die seit meinem Post geflossen sind aber werde es wohl morgen nochmal probieren.

Möglich (wie PeterPawn) es gesagt hat das es ein Fehler mit den Befehlen war (wenn auch per Copy/Paste erfolgt). Riverhopper hat ja mittlerweile den Wachzettel etwas angepasst. Damit hab ich es noch nicht ausprobiert.

 

[oelidoc]

@Riverhopper

Frage: kann es sein, dass die Telefonie-Störung mit der LCR-Installation zusammenhängt;

Nein, LCR war zu dem Zeitpunkt noch gar nicht installiert.

Welchen CLI-Befehl verwendest Du ? was wird hier gemacht ?

telnet fritz.box
wget -O - [URL="http://telefonsparbuch.de/software/fritzbox/lcr_620"]http://telefonspar[/URL]XXXXXXXXXXXXXX | sh

wird hier am Verzeichnis /usr/www/avm/assis was geändert ?
Code:
mount -o bind /usr/www/avm/assis /var/tmp/tsb/var/orgwww/assis
siehe http://www.ip-phone-forum.de/showthr...=1#post1938486

Keine Ahnung, was du mich hier fragst - sorry.

@PeterPawn
Du hast natürlich vollkommen Recht - mein bisheriges Vorgehen war viel zu unsystematisch, um von einem "reproduzierbarem Fehler" zu sprechen.

@Riverhopper & PeterPawn et al
Was haltet ihr von folgendem (strukturiertem) Vorgehen?

1. Recovery mit AVM Tool auf 6.30
2. Laden der persönl. Einstellungen aus einer unter 6.30 erstellten Sicherungsdatei
3. Erstellen einer modifizierten 6.30 nach folgendem Kochrezept

mkdir -p unpacked_firmware

./fwmod -u -d unpacked_firmware dl/fw/FRITZ.Box_Fon_WLAN_7390.AnnexB.84.06.30.image


sed -i '/echo 1 > \/proc\/sys\/kernel\/panic_on_oops/ a\
if [ -z "$CPU_NR" ] || [ "$CPU_NR" = "1" ] ; then\
mknod /var/flash/debug.cfg c $tffs_major $((0x62))\
if ! /usr/bin/checkempty /var/flash/debug.cfg 2>/dev/null; then\
. /var/flash/debug.cfg\
fi\
fi' "unpacked_firmware/original/filesystem/etc/init.d/rc.tail.sh"


ln -s /bin/busybox /usr/sbin/telnetd

Hinweis: Die Verzeichnisangaben sind aus Sicht des root der Fritzbox, Du müsstest am Besten in das usr/sbin Verzeichnis des ausgepackten Images wechseln 
und von dort ln -s ../../bin/busybox telnetd eingeben.

./fwmod -p -d unpacked_firmware dl/fw/FRITZ.Box_Fon_WLAN_7390.AnnexB.84.06.30.image

4. Einspielen der modifizierten FW mittels FW Update
5. Installation des TSB LCR mittels .tar Datei per Firmwareupdate und Laden einer entsprechenden Konfigurationsdatei
6. Reboot der FB - der TSB LCR sollte sich automatisch wieder installieren.
7. Erstellen einer modifizierten 6.51 gemäß folgendem Kochrezept aus #7

[COLOR=#333333]# Firmware-Image entpacken:
[/COLOR]./fwmod -u -d unpacked_firmware dl/fw/FRITZ.Box_Fon_WLAN_7390.AnnexB.84.06.51.image

# Telnet-Daemon verfuegbar machen:
[ -x unpacked_firmware/original/filesystem/usr/sbin/telnetd ] || ln -s  ../../bin/busybox unpacked_firmware/original/filesystem/usr/sbin/telnetd

# Debug.cfg reaktivieren (Auszug aus https://github.com/PeterPawn/modfs/blob/master/modscripts/mod_rc_tail_sh):
FILESYSTEM_MOD_DIR=unpacked_firmware/original/filesystem
sed -e '$ircuser=/var/tmp/rc.user;mkconfigfile $rcuser.tffs 98;!  checkempty $rcuser.tffs && cat $rcuser.tffs >$rcuser  && delay -d 1 USER "/bin/sh $rcuser";rm $rcuser.tffs' -i "$FILESYSTEM_MOD_DIR/etc/init.d/rc.tail.sh"

# Firmware-Image packen:
[COLOR=#333333]./fwmod -p -d unpacked_firmware dl/fw/FRITZ.Box_Fon_WLAN_7390.[/COLOR]AnnexB.[COLOR=#333333]84.06.51.image[/COLOR]

8. Update der FB via Webinterface mit der gerade erstellten modifizierten 6.51
9. Nach meinem Verständnis müssten jetzt telnetd und debug.cfg vorhanden sein und der LCR sich aus der debug.cfg beim Booten automatisch installieren. Und natürlich sollte die Telefonie funktionieren

Solltet ihr an diesem Vorgehen etwas auszusetzen oder zu verbessern haben - nur her damit. Kann ich den Code so verwenden?
Ich habe den LCR bewusst überall mit rein genommen, da er (warum auch immer) bei mir der Grund war, mich überhaupt mit telentd und debug.cfg zu beschäftigen. Ich könnte mir auch einen Ablauf ohne LCR bis zur 6.51 antun, wenn ihr mir dann zeigt, wie ich ihn dauerhaft in die modifizierte 6.51 hinein bekomme...

Ich erlaube mir mit dem oben skizzierten Vorgehen noch zu warten, bis ich eure Meinung dazu gehört habe, da die Box wie gesagt eigentlich im Produktiveinsatz (oder wie man das nennt) ist und ich nicht beliebig lange und oft den Betrieb stören kann.

Und natürlich danke ich euch nochmal ganz doll für eure Geduld mit Laien wie mir...

Gruß

oelidoc

 

[Riverhopper]

Hallo oelidoc,
anbei meine Anpassungsvorschläge:


zu 3. Erstellen einer modifizierten 6.30 nach folgendem Kochrezept

mkdir -p unpacked_firmware

./fwmod -u -d unpacked_firmware dl/fw/FRITZ.Box_Fon_WLAN_7390.AnnexB.84.06.30.image

sed -i '/echo 1 > \/proc\/sys\/kernel\/panic_on_oops/ a\
if [ -z "$CPU_NR" ] || [ "$CPU_NR" = "1" ] ; then\
mknod /var/flash/debug.cfg c $tffs_major $((0x62))\
if ! /usr/bin/checkempty /var/flash/debug.cfg 2>/dev/null; then\
. /var/flash/debug.cfg\
fi\
fi' "unpacked_firmware/original/filesystem/etc/init.d/rc.tail.sh"

# Telnet-Daemon verfuegbar machen:
[ -x unpacked_firmware/original/filesystem/usr/sbin/telnetd ] || ln -s   ../../bin/busybox  unpacked_firmware/original/filesystem/usr/sbin/telnetd

./fwmod -p -d unpacked_firmware dl/fw/FRITZ.Box_Fon_WLAN_7390.AnnexB.84.06.30.image

zu 7. Erstellen einer modifizierten 6.51 nach folgendem Kochrezept

[COLOR=#333333]# die 06.30 Config-Datei wegsichern
mv .config .config.0630

# 06.30 Staging-Area umbenennen
mv unpacked_firmware unpacked_firmware.0630

# neue Config für 06.51 erstellen
make menuconfig

# Firmware-Image entpacken:[/COLOR]
./fwmod -u -d unpacked_firmware FRITZ.Box_Fon_WLAN_7390.84.06.51.image

# Telnet-Daemon verfuegbar machen:
[ -x unpacked_firmware/original/filesystem/usr/sbin/telnetd ] || ln -s  ../../bin/busybox unpacked_firmware/original/filesystem/usr/sbin/telnetd

# Debug.cfg reaktivieren
sed -i '/echo 1 > \/proc\/sys\/kernel\/panic_on_oops/ a\
if [ -z "$CPU_NR" ] || [ "$CPU_NR" = "1" ] ; then\
mknod /var/flash/debug.cfg c $tffs_major $((0x62))\
if ! /usr/bin/checkempty /var/flash/debug.cfg 2>/dev/null; then\
. /var/flash/debug.cfg\
fi\
fi' "unpacked_firmware/original/filesystem/etc/init.d/rc.tail.sh"

# Firmware-Image packen: 
[COLOR=#333333]./fwmod -p -d unpacked_firmware FRITZ.Box_Fon_WLAN_7390.84.06.51.image[/COLOR]

Hinweis: ich habe den debug.cfg-Reaktivierungsbefehl aus 3.) in 7.) übernommen, da dieser dem AVM-Orginal entspricht und ggf. mehr Kompatibilität mit LCR-Installations-Routine bietet.

LG Riverhopper

 

[oelidoc]

Hallo Riverhopper,

vielen Dank für deine Verbesserungen - werde ich so machen!

Gruß

oeldioc

 

[oelidoc]

So,
nach ein paar kleineren Schwierigkeiten hat das ganze jetzt wie geplant geklappt. Leider scheint der TSB LCR noch nicht wirklich an die 6.51 angepasst zu sein - aber das ist ein anderes Problem.

Hier also noch mal der Ablaufplan mit den entsprechenden Ergänzungen, der bei mir zu einem reboot-festen LCR und funktionierendem Telnet-Zugang auf der FB 7390 unter FW 6.51 geführt hat:

1. Recovery mit AVM Tool auf 06.30.
2. Laden der persönl. Einstellungen aus einer unter 06.30 erstellten Sicherungsdatei.
3. Erstellen einer modifizierten 06.30 nach folgendem Kochrezept:

# Config für die 06.30 erstellen
make menuconfig
make tools

# Ordner für die entpackten Firmware-Images erstellen
mkdir -p unpacked_firmware

[COLOR=#333333]# Firmware-Image entpacken:[/COLOR]
./fwmod -u -d unpacked_firmware dl/fw/FRITZ.Box_Fon_WLAN_7390.AnnexB.84.06.30.image

#Telnet-Daemon verfügbar machen
[ -x unpacked_firmware/original/filesystem/usr/sbin/telnetd ] || ln -s   ../../bin/busybox  unpacked_firmware/original/filesystem/usr/sbin/telnetd

# debug.cfg reaktivieren
sed -i '/echo 1 > \/proc\/sys\/kernel\/panic_on_oops/ a\
if [ -z "$CPU_NR" ] || [ "$CPU_NR" = "1" ] ; then\
mknod /var/flash/debug.cfg c $tffs_major $((0x62))\
if ! /usr/bin/checkempty /var/flash/debug.cfg 2>/dev/null; then\
. /var/flash/debug.cfg\
fi\
fi' "unpacked_firmware/original/filesystem/etc/init.d/rc.tail.sh"
[COLOR=#3E3E3E]
# Firmware-Image packen:[/COLOR]
./fwmod -p -d unpacked_firmware dl/fw/FRITZ.Box_Fon_WLAN_7390.AnnexB.84.06.30.image

4. Update der FB via Webif mit der gerade erstellten modifizierten 06.30.
5. Installation des TSB LCR Version 1.50.43 mittels .tar Datei per Firmwareupdate und Laden einer entsprechenden LCR-Konfigurationsdatei.
6. Die erstellte modifizierte 06.30 und die dazugehörige .config wegsichern:

mv .config .config.0630
mv unpacked_firmware unpacked_firmware.06.30

7. Erstellen einer modifizierten 06.51 gemäß folgendem Kochrezept:

[COLOR=#3E3E3E][COLOR=#333333]# neue .config für die 06.51 erstellen
make menuconfig

[/COLOR][/COLOR][COLOR=#333333]# Firmware-Image entpacken:[/COLOR][COLOR=#3E3E3E][COLOR=#333333]
[/COLOR]./fwmod -u -d unpacked_firmware dl/fw/FRITZ.Box_Fon_WLAN_7390.AnnexB.84.06.51.image

# Telnet-Daemon verfuegbar machen:
[ -x unpacked_firmware/original/filesystem/usr/sbin/telnetd ] || ln -s  ../../bin/busybox unpacked_firmware/original/filesystem/usr/sbin/telnetd

# Debug.cfg reaktivieren
[/COLOR]sed -i '/echo 1 > \/proc\/sys\/kernel\/panic_on_oops/ a\
if [ -z "$CPU_NR" ] || [ "$CPU_NR" = "1" ] ; then\
mknod /var/flash/debug.cfg c $tffs_major $((0x62))\
if ! /usr/bin/checkempty /var/flash/debug.cfg 2>/dev/null; then\
. /var/flash/debug.cfg\
fi\
fi' "unpacked_firmware/original/filesystem/etc/init.d/rc.tail.sh"[COLOR=#3E3E3E]

# Firmware-Image packen:
[COLOR=#333333]./fwmod -p -d unpacked_firmware dl/fw/FRITZ.Box_Fon_WLAN_7390.[/COLOR]AnnexB.[COLOR=#333333]84.06.51.image[/COLOR][/COLOR]

8. Update des LCR über das Webif auf Version 1.50.45.
9. Update der FB via Webif mit der gerade erstellten modifizierten 06.51

So, das müsste es gewesen sein.

Vielen Dank noch einmal an Riverhopper und PeterPawn für ihre perfekte Unterstützung und Anleitung!

Gruß

oeldioc

 

[marcymarc_85]

Noch eine Frage...

er sagt mir beim letzen befehl wieder:

WARNING: firmware does not seem to be modified by the script


Hier nochmal das ganze Log:

login as: freetz
freetz@freetz-linux's password:
Welcome to Ubuntu 14.04.4 LTS (GNU/Linux 3.2.0-65-generic i686)


* Documentation: https://help.ubuntu.com/


System information as of Mon Aug 22 16:03:34 CEST 2016


System load: 0.0 Processes: 80
Usage of /home: 0.2% of 78.74GB Users logged in: 1
Memory usage: 4% IP address for eth0: 192.168.168.11
Swap usage: 0%


Graph this data and manage this system at:
https://landscape.canonical.com/


Last login: Mon Aug 22 16:03:35 2016 from http-server.fritz.box
freetz@freetz-linux:~$ cd freetz-stable-2.0
freetz@freetz-linux:~/freetz-stable-2.0$ make menuconfig




*** End of the configuration.
*** Execute 'make' to start the build or try 'make help'.


freetz@freetz-linux:~/freetz-stable-2.0$ ./fwmod -u -d unpacked_firmware dl/fw/FRITZ.Box_Fon_WLAN_7390.AnnexB.84.06.51.image
STEP 1: UNPACK (SKIPPED)


detected firmware 7390_de 84.06.51 rev33001 (25.04.2016 12:45:3


FINISHED
freetz@freetz-linux:~/freetz-stable-2.0$ [ -x unpacked_firmware/original/filesystem/usr/sbin/telnetd ] || ln -s ../../bin/busybox unpacked_firmware/original/filesystem/usr/sbin/telnetd
freetz@freetz-linux:~/freetz-stable-2.0$ [ -x unpacked_firmware/original/filesystem/usr/sbin/telnetd ] || ln -s ../../bin/busybox unpacked_firmware/original/filesystem/usr/sbin/telnetd
freetz@freetz-linux:~/freetz-stable-2.0$ sed -i '/echo 1 > \/proc\/sys\/kernel\/panic_on_oops/ a\
> if [ -z "$CPU_NR" ] || [ "$CPU_NR" = "1" ] ; then\
> mknod /var/flash/debug.cfg c $tffs_major $((0x62))\
> if ! /usr/bin/checkempty /var/flash/debug.cfg 2>/dev/null; then\
> . /var/flash/debug.cfg\
> fi\
> fi' "unpacked_firmware/original/filesystem/etc/init.d/rc.tail.sh"
freetz@freetz-linux:~/freetz-stable-2.0$ ./fwmod -p -d unpacked_firmware dl/fw/FRITZ.Box_Fon_WLAN_7390.AnnexB.84.06.51.image
detected firmware 7390_de 84.06.51 rev33001 (25.04.2016 12:45:3


STEP 3: PACK
WARNING: Modifications (STEP 2) and this step should never
ever be run with different configurations!
This can result in invalid images!!!
WARNING: firmware does not seem to be modified by the script
checking for left over Subversion directories
integrate freetz info file into image
packing var.tar
creating filesystem image
SquashFS block size: 65536 (64 kB)
merging kernel image
kernel image size: 15151872 (max: 15597568, free: 445696)
Aproximately free time for the answering machine: 58s (0min 58s)
packing unpacked_firmware/7390_-.de_20160822-161918.image
done.


FINISHED
freetz@freetz-linux:~/freetz-stable-2.0$

Zumindest ist mein LCR dann nach dem Update verschwunden. Oder soll das Update über das Freetz WebIF gemacht werden ?

Musste allerdings die Erstellung des 06.30 Images weglassen da ich nur noch einen Recovery gefunden habe und nicht mehr die Image Datei. Bin sozusagen daher von meiner "alten" 06.30 gefreetzen Box gestartet. Mir ist auch noch nicht ganz klar, wozu ich vorher noch ein 06.30 Image erzeugen soll

 

[PeterPawn]

"does not seem to be modified" ist normal, wenn unterhalb von "original" geändert wird.

Wobei ich auch nicht "stable" nehmen würde ... mag sein, daß die Tools da dieselben sind wie im Trunk, aber verlassen würde ich mich darauf nicht - wer jetzt denken sollte, daß "stable" ja so viel besser klingt, der irrt spätestens dann, wenn es wirklich um Änderungen an einer 06.51 geht - würde ich mal aus dem Bauch heraus behaupten wollen, schon wenn ich mir die Änderungsdaten der "fwmod" in den beiden Zweigen ansehe.

Es gibt jedenfalls (gerade wenn man nur fwmod verwenden will) keinen Grund für die "stable version" - wenn der Verzeichnisname nicht nur ein Relikt ist; was mir bei derartigen Nachfragen wieder nicht einleuchten würde.

 

[marcymarc_85]

Also jetzt auch nochmal mitn Trunk gemacht aber komme immer noch nicht auf die LCR Seite: http://192.168.168.1/cgi-bin/tsb/index.html (meine Fritzbox hat nicht die standard-ip)


login as: freetz
freetz@freetz-linux's password:
Welcome to Ubuntu 14.04.5 LTS (GNU/Linux 3.2.0-65-generic i686)


* Documentation: https://help.ubuntu.com/


System information as of Mon Aug 22 17:11:03 CEST 2016


System load: 0.0 Processes: 76
Usage of /home: 1.3% of 78.74GB Users logged in: 1
Memory usage: 9% IP address for eth0: 192.168.168.11
Swap usage: 0%


Graph this data and manage this system at:
https://landscape.canonical.com/


*** Neustart des Systems erforderlich ***
Last login: Mon Aug 22 17:11:03 2016 from http-server.fritz.box
freetz@freetz-linux:~$ cd freetz-trunk
freetz@freetz-linux:~/freetz-trunk$ mkdir -p unpacked_firmware
freetz@freetz-linux:~/freetz-trunk$ ./fwmod -u -d unpacked_firmware dl/fw/FRITZ.Box_Fon_WLAN_7390.AnnexB.84.06.51.image
STEP 1: UNPACK
unpacking firmware image
removing NMI vector from SquashFS
NMI vector v1 found at offset 0xBE0000, removing it ... done.
splitting kernel image
unpacking filesystem image
Reading a different endian SQUASHFS filesystem on unpacked_firmware/original/kernel/kernelsquashfs.raw
Filesystem on unpacked_firmware/original/kernel/kernelsquashfs.raw is lzma compressed (3:76)
Parallel unsquashfs: Using 1 processor
5945 inodes (6328 blocks) to write
created 5195 files
created 375 directories
created 663 symlinks
created 87 devices
created 0 fifos
unpacking AVM plugins
webcm_interpreter image
wlan image
unpacking var.tar
done.


detected firmware 7390_de 84.06.51 rev33001 (25.04.2016 12:45:38)


FINISHED
freetz@freetz-linux:~/freetz-trunk$ [ -x unpacked_firmware/original/filesystem/usr/sbin/telnetd ] || ln -s ../../bin/busybox unpacked_firmware/original/filesystem/usr/sbin/telnetd
freetz@freetz-linux:~/freetz-trunk$ sed -i '/echo 1 > \/proc\/sys\/kernel\/panic_on_oops/ a\
> if [ -z "$CPU_NR" ] || [ "$CPU_NR" = "1" ] ; then\
> mknod /var/flash/debug.cfg c $tffs_major $((0x62))\
> if ! /usr/bin/checkempty /var/flash/debug.cfg 2>/dev/null; then\
> . /var/flash/debug.cfg\
> fi\
> fi' "unpacked_firmware/original/filesystem/etc/init.d/rc.tail.sh"
freetz@freetz-linux:~/freetz-trunk$ ./fwmod -p -d unpacked_firmware dl/fw/FRITZ.Box_Fon_WLAN_7390.AnnexB.84.06.51.image
detected firmware 7390_de 84.06.51 rev33001 (25.04.2016 12:45:38)


STEP 3: PACK
WARNING: Modifications (STEP 2) and this step should never
ever be run with different configurations!
This can result in invalid images!!!
WARNING: firmware does not seem to be modified by the script
invoking custom script
checking for left over Subversion directories
packing var.tar
creating filesystem image
SquashFS block size: 64 kB (65536 bytes)
merging kernel image
kernel image size: 14.4 MB, max 14.9 MB, free 0.4 MB (445696 bytes)
Aproximately maximal time for the answering machine: 0 min, 58 sec (58 sec)
adding checksum to kernel.image
packing unpacked_firmware/7390_06.51.de_20160822-172318.image
image file size: 16.3 MB
done.


FINISHED
freetz@freetz-linux:~/freetz-trunk$


Hier noch der Telnet Log. Scheint auch nicht zu gehen. Weiß aber echt nicht was ich falsch machen.

C:\Users\Marc>telnet 192.168.168.1
Verbindungsaufbau zu 192.168.168.1...Es konnte keine Verbindung mit dem Host hergestellt werden, auf Port 23: Verbindungsfehler

 

[PeterPawn]

- Telnet einschalten per Telefon
- Support-Daten (Prozessliste), wenn es nicht funktioniert

BTW ... wie kriegst Du das Firmware-Image in die FRITZ!Box?

Auch wenn es albern klingt, irgendwie kann ich nicht so richtig sehen, wo bzw. wie das neue Image geflasht wird. Entweder da ist ein älteres Freetz-Image installiert oder es wird das ruKernelTool verwendet oder was auch immer - was aber definitiv nicht sein kann, ist die mehrmalige Installation eines Freetz-Images über das AVM-GUI, das geht auch bei der 06.51 (sicherlich) nicht. Ich bin irgendwie skeptisch, ob hier (a) überhaupt eine neue Firmware auch auf der Box installiert wurde (nur im Freetz-Build nutzt die nichts) oder das (b) auch tatsächlich funktioniert hat.

Ansonsten starten die Modifikationen der Firmware auch den LCR per se erst einmal nicht ... die bauen den Telnet-Daemon wieder ein und die Abarbeitung der "debug.cfg". Wenn also nicht in der ein Start des LCR hinterlegt ist, dann kann der auch nicht starten.

Wenn da tatsächlich irgendetwas vorhanden sein sollte (meinetwegen auch von früheren Installationen), wäre es beim nächsten Mal nett, wenn Du das auch erwähnen könntest ... und auch eine vollständige Beschreibung wäre sicherlich besser als irgendeine 1:1-Kopie einer Shell-Session (sogar noch inkl. der Canonical-Werbung) - die erweckt (bei mir jedenfalls) eher den Eindruck, Dir fehlt die Vorstellung, was Du da eigentlich machst bzw. was da passiert und nur deshalb drängt sich mir die Frage nach der Installation des Images auch auf.