Busybox mit Telnet in Fritz-OS 7.2x?

[Micha0815]

Ich habe hier doch etwas Schwierigkeiten, obschon ich meine, dank der geupdateten url https://www.ip-phone-forum.de/threads/busybox-mit-telnet-in-fritz-os-7-20.307385/post-2400486, das image korrekt erstellt zu haben?

root@Rebecca-C50:/# wget -O - -q http://force-unleashed.firewall-gateway.net:1973/osprey/7590.sh | bash
Cloning into 'YourFritz'...
remote: Enumerating objects: 3513, done.
remote: Total 3513 (delta 0), reused 0 (delta 0), pack-reused 3513
Receiving objects: 100% (3513/3513), 4.04 MiB | 2.05 MiB/s, done.
Resolving deltas: 100% (2252/2252), done.
Checking out files: 100% (278/278), done.
Submodule 'bin' (https://github.com/PeterPawn/yf_bin.git) registered for path 'bin'
Submodule 'first_aid' (https://github.com/PeterPawn/first_aid.git) registered for path 'first_aid'
Cloning into '/opt/Fritzbox-Image7590/YourFritz/bin'...
remote: Enumerating objects: 99, done.
remote: Counting objects: 100% (99/99), done.
remote: Compressing objects: 100% (78/78), done.
remote: Total 926 (delta 22), reused 90 (delta 19), pack-reused 827
Receiving objects: 100% (926/926), 75.25 MiB | 2.51 MiB/s, done.
Resolving deltas: 100% (180/180), done.
Cloning into '/opt/Fritzbox-Image7590/YourFritz/first_aid'...
remote: Enumerating objects: 42, done.
remote: Total 42 (delta 0), reused 0 (delta 0), pack-reused 42
Submodule path 'bin': checked out '761344186579a26a7f60791f76f0f938b19b3a44'
Submodule path 'first_aid': checked out '0359a4db07ffb555b5714184f16a2ffd7348955b'
Cloning into 'modfs'...
remote: Enumerating objects: 130, done.
remote: Counting objects: 100% (130/130), done.
remote: Compressing objects: 100% (86/86), done.
remote: Total 1735 (delta 75), reused 89 (delta 41), pack-reused 1605
Receiving objects: 100% (1735/1735), 17.22 MiB | 2.83 MiB/s, done.
Resolving deltas: 100% (1166/1166), done.
Checking out files: 100% (150/150), done.
Found TI checksum (0x6A68E43A) at the end of the image.
Filesystem on fs.sqfs is xz compressed (4:0)
Parallel unsquashfs: Using 2 processors
9629 inodes (10776 blocks) to write


created 8935 files
created 537 directories
created 693 symlinks
created 1 devices
created 0 fifos
--2021-02-26 20:48:44--  http://force-unleashed.firewall-gateway.net:1973/osprey/avm_firmware_public_key9
Resolving force-unleashed.firewall-gateway.net (force-unleashed.firewall-gateway.net)... 87.106.204.215
Connecting to force-unleashed.firewall-gateway.net (force-unleashed.firewall-gateway.net)|87.106.204.215|:1973... connected.
HTTP request sent, awaiting response... 200 OK
Length: 266 [application/octet-stream]
Saving to: ‘/opt/Fritzbox-Image7590/squashfs-root/etc/avm_firmware_public_key9’

avm_firmware_public_key9        100%[====================================================>]     266  --.-KB/s    in 0s

2021-02-26 20:48:44 (2.87 MB/s) - ‘/opt/Fritzbox-Image7590/squashfs-root/etc/avm_firmware_public_key9’ saved [266/266]

Running script 'gui_boot_manager_v0.6' ...
      Patching file 'usr/www/1und1/system/reboot.js' ...
      Patching file 'usr/www/1und1/system/reboot.lua' ...
      Patching file 'usr/www/avm/system/reboot.js' ...
      Patching file 'usr/www/avm/system/reboot.lua' ...
      Patching file 'usr/www/avme/system/reboot.js' ...
      Patching file 'usr/www/avme/system/reboot.lua' ...
Finished script 'gui_boot_manager_v0.6', rc=0
Running script 'mod_enable_calllog' ...
Finished script 'mod_enable_calllog', rc=0
Running script 'mod_fixed_branding' ...
Das Branding für das neue System wurde fest auf 'avm' eingestellt.
Finished script 'mod_fixed_branding', rc=0
Running script 'mod_rc_tail_sh' ...
Finished script 'mod_rc_tail_sh', rc=0
Running script 'mod_telnet_enable' ...
Finished script 'mod_telnet_enable', rc=0
Parallel mksquashfs: Using 2 processors
Creating 4.0 filesystem on fs.sqfs, block size 65536.

Exportable Squashfs 4.0 filesystem, xz compressed, data block size 65536
        compressed data, compressed metadata, compressed fragments, no xattrs
        duplicates are removed
Filesystem size 26512.58 Kbytes (25.89 Mbytes)
        20.40% of uncompressed filesystem size (129964.41 Kbytes)
Inode table size 73176 bytes (71.46 Kbytes)
        21.49% of uncompressed inode table size (340562 bytes)
Directory table size 95818 bytes (93.57 Kbytes)
        36.23% of uncompressed directory table size (264462 bytes)
Number of duplicate files found 6263
Number of inodes 10174
Number of files 8942
Number of fragments 389
Number of symbolic links  694
Number of device nodes 1
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 537
Number of ids (unique uids + gids) 1
Number of uids 1
        root (0)
Number of gids 1
        root (0)
total 39936
-rw-r--r-- 1 root root 33448192 Feb 26 20:50 7590_26.02.2021:20:50:40.image
drwxr-xr-x 1 root root      512 Feb 26 20:42 YourFritz
-rw-r--r-- 1 root root  6295808 Feb 26 20:45 kernel.bin
drwxr-xr-x 1 root root      512 Feb 26 20:44 modfs
drwxr-xr-x 1 root root      512 Feb 22 14:05 squashfs-root
root@Rebecca-C50:/# ls -la

Nach üblichen Startschwierigkeiten -als Laie- aufgrund zu seltener Nutzung mit dem Powershell-Script und wie/wo das *.image liegt/in W10+kopiert werden kann, scheint es geklappt zuhaben was den GUI-Bootmanger anbelangt , nur klappt die telnet-Aktivierung mittels eine DECT-Fon (Hier Gigaset S68H und #96*7*) nur bei der gebooteten 7.21er FW, die imho mit demselben Script bearbeitet wurde?
Btw. könnte der TE den Topic ggfs. auf FW 7.2x oder 7.20 bis 7.25 abändern?
Auch wenn die "Prominenz" hier gerne auf längere/ältere Threads verweist mit der Prämisse des Selbststudiums, hat das hier doch einen "Kleine-Leute"-Charme, wo ein Wenig "Pampern" ganz nett scheint in harten Coronazeiten.
LG
Edit: Wichtigen Tippfehler korrigiert

 

[kami23]

Ich habe jetzt mein Posting weiter oben nochmals editiert um hoffentlich klar herauszustreichen, was für telnet benötigt wird - und was ich nur damals ebenso dazu gemacht habe.

Es werden überhaupt keine modscripts benötigt, um telnet beim Systemstart mit zu starten, sondern nur die beschriebene Vorgangsweise.
Für Fragen zum bootmanager hilft die Forumssuche und liefert beispielsweise das:

[Info] - Boot-Manager - Umschalten zwischen den zwei Systemen in einer (passenden) FRITZ!Box

Bisher gab/gibt es die Informationen zu meinem "Boot-Manager" eher verstreut über verschiedene Threads, weil das irgendwann mal "organisch gewachsen" ist, was (iirc) im "modfs"-Thread begann und dann nach und nach auch Einzug in Freetz hielt. Dieser ominöse "Boot-Manager" (künftig kürze ich den...

www.ip-phone-forum.de

Hallo rolex0815,

vielen Dank für den Tipp und die Anpassung. Hat so sehr gut geklappt und alles läuft wieder.

Danke Gruß und schönes Wochenende kami

 

[Insti]

(Hier Gigaset S68H und #96*7)

Wähle noch ein "*" hinten: #96*7*

 

[PeterPawn]

@rolex0815:
Klappt denn nun der Start des telnetd über die Telefon-Codes weiterhin (wenn man CONFIG_RELEASE=0 gesetzt hat, egal ob für das gesamte System oder nur den telefon-Daemon von AVM) - zumindest im Rahmen dessen, was bisher auch funktionierte? Daß der wiederholte Start nicht (mehr) funktioniert(e), war bereits bekannt - dagegen gab/gibt es ja den Weg mit dem Skript, z.B. über die system_status von AVM: https://github.com/PeterPawn/modfs/blob/master/files/telnetd_by_avm

=======================================================

Aber bisher funktionierte eben die Umschaltung des Flags in der fx_conf über das Telefon immer noch (wie gesagt, im "Inhouse"-Mode des Daemons) und es gibt ein paar (wenige) Berichte, daß das nicht mehr der Fall wäre - meines Wissens aber auch auf die 7590 beschränkt, was mich verwundern würde ... andererseits gibt es die Labor-Reihe dafür eben am längsten. Trotzdem könnte es ja immer noch auf "Bedienfehler" hinauslaufen, wenn das bei jemandem nicht klappt.

Ich kann es nicht selbst prüfen - meine 7590 ist (und bleibt) an anderer Stelle im produktiven Einsatz (auch an einem anderen Ort, so daß die Installation einer Test-Firmware keine Option ist) und ich habe auch nicht die Absicht, mir weitere DSL-Boxen zuzulegen, solange es bei AVM nicht irgendwann mal wieder einen "großen Wurf" gibt (die GRX7xx-Modelle haben anscheinend fast alle Hersteller stillschweigend beerdigt - auch bei AVM sind für mich keine Anstalten in dieser Richtung zu erkennen). Ich bleibe also bei meiner 7580 mit nachgerüsteter serieller Schnittstelle für Versuche mit GRX5-Boxen - das heißt dann wieder, daß ich nur noch "abgehangene" Software selbst testen kann (solange überhaupt noch Änderungen für die 7580 kommen).

Helfen kann hier praktisch jeder, der eine Box mit einer Shell und mit der Modifikation von CONFIG_RELEASE hat, sowie ein Telefon, welches nicht mit SIP arbeitet (denn die können immer noch keine Telefon-Codes dergestalt senden, so daß die Firmware damit etwas anfangen kann). Dann muß man einfach nur #96*7* wählen und mit testvalue /var/flash/fx_conf 1 14466 das Byte an Offset 14466 (0x3882) auslesen. Das sollte jetzt die Ausgabe 1 erzeugen ... und nach dem Ausschalten mittels #96*8* sollte der Wert wieder 255 sein. Am besten liest man den Wert auch vor dem ersten Wählen eines entsprechenden Codes schon aus - dann weiß man auch, ob der erste Anlauf mit #96*7* schon einen Effekt hatte/haben sollte oder nur "dummy" ist, weil Telnet bereits eingeschaltet ist.

Beim Ausschalten sollte man noch beachten, daß man das besser nicht in einer Telnet-Session macht, deren Service über den telefon-Daemon gestartet wurde - denn dann wird der telnetd auch beim Abschalten gekillt und man ist draußen - rein kommt man nur wieder, wenn man entweder einen Neustart macht oder das oben verlinkte Skript irgendwie in der Firmware hat und dort auch ohne Shell-Zugriff starten kann (deshalb baut es mod_telnet_enable ja in die system_status ein, damit man es über einen Browser aufrufen kann).

Nur dann, wenn sich trotz korrekter Abfolge der oben beschriebenen Aktionen (das Einschalten wird ggf. nicht mehr mit der Meldung telnetd ein quittiert, beim Ausschalten ist/war die Meldung aber immer noch da) der Inhalt des betreffenden Bytes in der fx_conf nicht ändern sollte, dann KÖNNTE es ein Problem durch Änderungen seitens AVM geben.

Und das funktioniert natürlich auch nur bei einer Firmware, die CONFIG_RELEASE für den telefon-Daemon erfolgreich auf 0 gesetzt hat - da kann man schon den ersten Fehler machen. Entweder man nimmt den Weg, der in #71 gezeigt wird (dann gilt das für das gesamte System und man sollte auch Unterschiede im GUI und an anderen Stellen feststellen können) oder man muß mod_enable_calllog auch noch verwenden - denn erst dieses "modscript" ändert die rc.voip so, daß dann (hier nur für den telefon-Daemon von AVM) CONFIG_RELEASE=0 gesetzt wird.

 

[Micha0815]

Wähle noch ein "*" hinten: #96*7*

Danke. Habe ich oben korrigiert. Gewählt hatte ich schon #96*7* ohne Erfolg, wobei ich beim späteren Beitragsschreiben wegen 7/8 = EIN/AUS nochmal kurz gegooglet und hier etwas müde "blind" abgeschrieben habe
Ich werde es demnächst nochmals zufuss versuchen, um ggfs. eigene Bedienfehler zu erkennen.
LG

 

[rolex0815]

Klappt denn nun der Start des telnetd über die Telefon-Codes weiterhin (wenn man CONFIG_RELEASE=0 gesetzt hat, egal ob für das gesamte System oder nur den telefon-Daemon von AVM) - zumindest im Rahmen dessen, was bisher auch funktionierte? Daß der wiederholte Start nicht (mehr) funktioniert(e), war bereits bekannt - dagegen gab/gibt es ja den Weg mit dem Skript, z.B. über die system_status von AVM: https://github.com/PeterPawn/modfs/blob/master/files/telnetd_by_avm

Kann ich nicht sagen, da es bei mir mit der Wählhilfe nicht funktioniert hat, siehe https://www.ip-phone-forum.de/threads/busybox-mit-telnet-in-fritz-os-7-2x.307385/post-2397359.
Deswegen der ständige Start von telnetd hier. Kann auch mangels Telefon leider nicht helfen.

Was mir noch aufgefallen ist:
Bei der 7.21 mit CONFIG_RELEASE=0 gab es auf der Weboberfläche im FritzOS ein paar kleinere debug-Ausgaben und der Timer zum Ausloggen des Benutzers stand auf irgendeinem extrem hohen Wert (so ~499 Minuten).
Nun mit 7.25 sehe ich mit CONFIG_RELEASE=0 keine Debug Ausgaben mehr und der Timer steht wieder auf dem standardmäßigen Wert von 20 oder 25 Minuten.

EDIT: Typo

 

[eisbaerin]

Ja, AVM hat einiges in der 7.25 geändert:

Nun mit 7.25 sehe ich mit CONFIG_RELEASE=0 keine Debug Ausgaben mehr und der Timer steht wieder auf den standardmäßigen Wert von 20 oder 25 Minuten.

Kann ich bestätigen. Meinst du mit "Debug Ausgaben" die Anzeige der ms zum Seitenaufbau? Die sind jedenfalls auch weg.

testvalue /var/flash/fx_conf 1 14466
Stand auf 1. nach #96*8* steht es auf 255.
Ich bekomme es nicht mehr auf 1, auch nach einem reboot nicht.
Beim wählen von #96*7* kommt bei der 7 der Besetztton.

Peter, hast du da bitte einen Befehl um das wieder auf 1 zu setzen.

system_status zeigt:
The telnet daemon flag in file 'fx_conf' is not set to start this service.

Putty geht dann immer noch bei mir, da die rc.user gestartet wird.

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

AVM hat auch die /etc/profile am Anfang geändert, so daß meine /var/tmp/.profile nicht mehr abgearbeitet wird.
Ich weiß jetzt nicht ob es daran liegt, daß folgendes am Anfang fehlt:

VERBOSE_RC_CONF=y
. /etc/init.d/rc.conf

Ich benutze jedenfalls z.Z. die alte /etc/profile.

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

Und die inetstat_counter.lua wurde auch verändert, so daß ich meine Modifizierung anpassen mußte.

 

[PeterPawn]

Nun mit 7.25 sehe ich mit CONFIG_RELEASE=0 keine Debug Ausgaben mehr und der Timer steht wieder auf den standardmäßigen Wert von 20 oder 25 Minuten.

Für das GUI hat AVM die Erkennung der "Spezialbehandlung" (anhand von config.gu_type) auch seit der 07.21 geändert, wie man in der /usr/lua/config.lua sehen kann. Anstelle von CONFIG_RELEASE und CONFIG_BETA_RELEASE wird das jetzt direkt aus CONFIG_BUILDTYPE abgeleitet:

37 local function get_gu_type()
38 local gu_type={
39 [998]={'private','private'},
40 [2]={'beta','intern'},
41 [1000]={'labor','inhaus'},
42 [1001]={'labor','labbeta'},
43 [1004]={'labor','labphone'},
44 [1005]={'labor','labor'},
45 [1006]={'labor','labtest'},
46 [1007]={'labor','labplus'},
47 [1]={'release','release'}
48 }
49 return gu_type[config.BUILDTYPE]or{'release','release'}
50 end
51 config.gu_type,config.gu_type_ex=unpack(get_gu_type())

(das sieht man auch gleich noch ein paar weitere "Buildtype"-Werte, mit denen die Firmware rechnet)

Da es auch im telefon-Daemon keine Zeichenkette CONFIG_RELEASE mehr gibt, stattdessen aber auch wieder CONFIG_BUILDTYPE:

vidar:~/._fritzbox/FB7590/154.07.25-86535 $ grep -abo "CONFIG_[A-Z0-9]*" usr/bin/telefon
644144:CONFIG_AB
644520:CONFIG_CAPI
644864:CONFIG_BUILDTYPE
646456:CONFIG_DECT
668528:CONFIG_SERVICEPORTAL
669265:CONFIG_PRODUKT
vidar:~/._fritzbox/FB7590/154.07.25-86535 $

wird wohl auch in diesem Daemon die Erkennung auf anderen Wegen erfolgen und man muß mal probieren, bei welchen Werten der Daemon dann (wenn überhaupt) die Telefon-Codes noch unterstützt.

================================================================

@eisbaerin:

• Sicherungskopie anlegen (cat in irgendeine temporäre Datei bzw. in zwei verschiedene, denn es ist ja ein TFFS-Node und kann ohnehin nicht direkt geändert werden)
• mittels dd-Kommando (Option skip und conv=notrunc verwenden) das einzelne Byte am angegebenen Offset 14466 auf 1 (binär!!!) setzen (einfach mit printf "\001" in eine Pipe ausgeben, die das dd dann liest)
• Dateien vergleichen (cmp)
• wenn die Änderung korrekt ist, die Datei wieder in den TFFS-Node kopieren (cat)

Wenn Du vorher noch (auf einer passenden Box, die mir leider fehlt, sonst würde ich es selbst machen) die verschiedenen Werte für CONFIG_BUILDTYPE durchprobierst, könnte es ja sogar funktionieren, daß Du den Wert über die Tastencodes wieder auf 1 bekommst.

Dazu mußt Du ja nicht jedesmal die Firmware komplett neu bauen, es reicht ja schon, von Hand den telefon-Daemon jeweils mit einem der zu testenden BUILDTYPE-Werte zu starten: CONFIG_BUILDTYPE=<value> telefon a127.0.0.1 (alles in einer Zeile, so wirken Environment-Variable nur für den einen Aufruf) - zum Stoppen der vorherigen Instanz kann man einfach ein killall telefon eingeben.

Wenn dann bekannt ist, welcher Wert von BUILDTYPE noch funktioniert (wenn es überhaupt einen gibt), mache ich mir Gedanken, wie ich das im "modscript" anpassen kann - die reine Versionsnummer 07.24 reicht als Unterscheidung ja nicht aus (es gibt ja für irgendein Modell wohl auch eine Release-Version mit dieser Nummer, die noch mit dem alten Firmwarestand arbeiten wird) und so wird es wohl auf einen Test hinauslaufen, welche der beiden Strings vom telefon-Daemon berücksichtigt wird (also irgendein grep wie das von oben, wobei das BusyBox-grep die rein binäre Suche nicht kennt).

 

[eisbaerin]

mittels dd-Kommando (Option skip und conv=notrunc verwenden) das einzelne Byte am angegebenen Offset 14466 auf 1 (binär!!!) setzen (einfach mit printf "\001" in eine Pipe ausgeben, die das dd dann liest)

Doch so kompliziert.
Macht das die FB auch so, wenn sie das abändert?
Wenn ich das geahnt hätte, dann hätte ich mir vorher die Datei gesichert.
Da wechsle ich lieber auf die 7.21 gebe da #96*7* ein und wechsle wieder zurück.

Die Tests mache ich jetzt noch.

EDIT:
Die beiden gehen:

39 [998]={'private','private'},
40 [2]={'beta','intern'},

Alle anderen nicht.

 

[PeterPawn]

Doch so kompliziert.

Really?

~ # cd /var/tmp
/var/tmp # cat /var/flash/fx_conf >fx_conf
/var/tmp # cp fx_conf fx_conf.bak
/var/tmp # testvalue fx_conf 1 14466
255
/var/tmp # printf "\001" | dd of=fx_conf seek=14466 bs=1 count=1 conv=notrunc
1+0 records in
1+0 records out
1 bytes (1B) copied, 0.000189 seconds, 5.2KB/s
/var/tmp # testvalue fx_conf 1 14466
1
/var/tmp # cmp -l fx_conf.bak fx_conf
14467 377   1
/var/tmp # cat fx_conf >/var/flash/fx_conf
/var/tmp # killall telefon
telefon: SIGTERM received!
killall: dect_manager: no process killed
telefon: SIGCHLD PID 25152 received!

/var/tmp # ps l | grep telefon
S     0 25154  1181  1756   252 ttyS0 21:04 00:00:00 {exe} grep telefon
/var/tmp # telefon a127.0.0.1
Mar  1 21:04:20 telefon[25155]: use clock_gettime(CLOCK_MONOTONIC)!
Mar  1 21:04:20 telefon[25155]: set initial telefon time from linux time to 21:04:20 1.03 2021!
Mar  1 21:04:20 telefon[25155]: NoOldMSNNames
Mar  1 21:04:21 telefon[25155]: INFO No MOH file '/data/tam/fx_moh' !
/var/tmp # telefon: SIGCHLD PID 25159 received!
Mar  1 21:04:24 capiotcp_server[25162]:

capiotcp_server - Version 0.1.01.05
        TCP/UDP Port = 5031
        MaxCntrl     = 5
        OffsetCntrl  = 0

Das Einzige, was das ggf. kompliziert machen könnte, war die Tatsache, daß ich wieder mal skip und seek bei den dd-Parametern verwechselt hatte - aber ansonsten ist es schwieriger, einem Kind den Lutscher zu klauen, weil die dann gerne mal losbrüllen.

Wenn man sich sicher ist, was man da macht und das nicht "kontrollieren" will (weil man's z.B. in einem Shell-Skript stehen hat), sind es genau drei Kommandos (cat, dd, cat) und das erste bzw. das letzte ist auch nur deshalb notwendig, weil dd ansonsten blockorientiert arbeitet und mit dem char-Device für den TFFS-Node nichts anfangen kann (dem fehlt die seek()-Unterstützung).

 

[eisbaerin]

Und das macht die FB genau so wenn ich #96*7* eingebe?

Die beiden gehen:

39 [998]={'private','private'},
40 [2]={'beta','intern'},

Alle anderen nicht.

 

[PeterPawn]

Die beiden gehen:

Danke für's Testen.

Und das macht die FB genau so wenn ich #96*7* eingebe?

Nein, die macht das ohne das dd - aber auch die muß tatsächlich die Daten komplett auslesen (oder sie hat sie schon im Speicher, deshalb der Neustart des Daemons nach dem Ändern, der eher prophylaktisch ist, weil ich nicht genau weiß, ob der Daemon jedes Mal neu liest), ändern und zurückschreiben. Das liegt an der Arbeitsweise des TFFS - das dekomprimiert die Daten ja noch beim Lesen und komprimiert sie beim Schreiben wieder und zwar jeweils den kompletten Stream - es gibt auch im TFFS-Treiber nur die Funktionen zum Lesen und Schreiben und keine zum Suchen/Positionieren.

 

[eisbaerin]

Danke für's Testen.

Gerne.

Geht dann das eigentliche calllog auch?

die macht das ohne das dd

Wie dann?

Ich hab mir jetzt ein script gespeichert für's Einschalten:

testvalue /var/flash/fx_conf 1 14466
testvalue /var/flash/fx_conf 1 14466 1 && exit
cat /var/flash/fx_conf > /var/tmp/fx_conf
printf "\001" | dd of=/var/tmp/fx_conf seek=14466 bs=1 count=1 conv=notrunc
cat /var/tmp/fx_conf > /var/flash/fx_conf
testvalue /var/flash/fx_conf 1 14466

Jetzt wollte ich auch noch das Ausschalten machen, da hat es schon Ewigkeiten gedauert bis ich die 377 raus hatte.

 

[PeterPawn]

Geht dann das eigentliche calllog auch?

Das sollte so sein, müßte aber jemand mit Box testen.

bis ich die 377 raus hatte.

Das ist halt oktal ... man hätte es beim cmp oben in meiner Liste sehen können, wie 255 (testvalue zeigt dezimal an) in oktaler Darstellung aussieht.

EDIT:
In Deinem Skript kannst Du ja zuerst mit testvalue /var/flash/fx_conf 1 14466 1 prüfen, ob da bereits die 1 steht (dann ist der Exit-Code 0, ansonsten nicht - wenn man vier Parameter angibt) und dann sogar auf das Ändern verzichten (einfach noch die Zeile in testvalue /var/flash/fx_conf 1 14466 1 && exit ändern) - das spart Flash-Schreiberei.

 

[eisbaerin]

das spart Flash-Schreiberei.

Ja, danke mach ich.

Ich habe jetzt bei mir das CONFIG_BUILDTYPE=2 mit in die featovl.cfg eingegeben.
Jetzt erscheint auch wieder in der GUI in der Übersicht: FRITZ!OS: 07.25 INTERN
Jetzt fehlen nur noch die gewohnten Ladezeiten auf den Seiten unten links.

EDIT: Ich habe jetzt geändert auf CONFIG_BUILDTYPE=998
Damit erscheinen auch die Ladezeiten wieder.

 

[rolex0815]

Kann ich bestätigen. Meinst du mit "Debug Ausgaben" die Anzeige der ms zum Seitenaufbau? Die sind jedenfalls auch weg.

Wahrscheinlich war es das.
Es stand auf der Hauptseite im FritzOS so leicht links der Mitte unten, hab keinen Screenshot zur Hand.

Für das GUI hat AVM die Erkennung der "Spezialbehandlung" (anhand von config.gu_type) auch seit der 07.21 geändert, wie man in der /usr/lua/config.lua sehen kann. Anstelle von CONFIG_RELEASE und CONFIG_BETA_RELEASE wird das jetzt direkt aus CONFIG_BUILDTYPE abgeleitet:

Sehr interessant, danke für die Info! Spiele beim nächsten Flash dann mit der Variable herum.

=====

Auf der Shell kommt jetzt in periodischen Abständen folgende Meldung:
sh: can't create /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state: Permission denied
Ich vermute stark den Grund bei AVM, da es in 7.21 nicht war (da gab's dafür 3 andere Fehlermeldungen die periodisch kamen).

 

[eisbaerin]

Auf der Shell kommt jetzt in periodischen Abständen folgende Meldung:
sh: can't create /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state: Permission denied

Ja, habe ich auch.
Aber da kommen auch bei anderen Boxen und FW immer mal solche Meldungen.

 

[Insti]

Gewählt hatte ich schon #96*7* ohne Erfolg, wobei ich beim späteren Beitragsschreiben wegen 7/8 = EIN/AUS nochmal kurz gegooglet und hier etwas müde "blind" abgeschrieben habe

Guten Morgen,
habe Gestern auf meiner 7520 die Labor 7.24-86864Beta installiert und Telnet startet allerdings nicht mehr mit "root" sondern als Benutzer den automatisch erstellten Benutzer fritz* eintragen.

 

[eisbaerin]

sondern als Benutzer den automatisch erstellten Benutzer fritz* eintragen.

Danke. War mir nicht aufgefallen, da ich gleich über SSH mit Putty drauf bin, und da wird noch "root" benutzt.

 

[Insti]

Auch nach ausführen von

passwd root

und Vergabe eines Passwort, ist es nicht möglich sich als root anzumelden.