FB 6591 verschiedenes

guidox

Neuer User
Mitglied seit
31 Dez 2007
Beiträge
105
Punkte für Reaktionen
4
Punkte
18
Wie sicher ist denn das "might"? Bzw. soll ich mir gleich eine andere FB (hoffentlich diesesmal retail) kaufen und es dann damit versuchen?
Kurz: DVB-C funktioniert, SIP geht nicht bei mir.

Ich habe eben meine 6591 (kdg) von 7.13 auf 7.22 mit der Methode von @fesc (Danke dafür!) aktualisiert und bei meinem Provider (NetCologne) provisioniert. Internet funktioniert.

Thu Apr 1 01:30:22 CEST 2021
uptime: 01:30:22 up 28 min, load average: 0.10, 0.14, 0.14
4.9.199
DMC RTL=y
HWRevision 233
HWSubRevision 8
ProductID Fritz_Box_HW233
SerialNumber N034696XXXXXXXX
annex Kabel
autoload yes
bootloaderVersion 1.3614
country 049
firstfreeaddress 0x3D3C4C00
firmware_info 161.07.22
firmware_version kdg
language de
linux_fs_start 0

Die Firmware 7.13 war zuvor auch auf der Partition 0 installiert. Die Änderung auf "linux_fs_start 1" war allerdings nicht möglich. Die FB startet nicht neu nach einem "quote REBOOT". Nach einem Strom-Reset steht die Box wieder auf "linux_fs_start 0". Ebenso wenig lässt sich die "firmware_version" ändern bzw. ist nach dem Strom-Reset wieder auf "kdg" gestellt. Einzig "DMC RTL=y" ist persistent.

Das Bios war tatsächlich Version "CGM2.86C.627075.R.1910091149 10/09/2019" obwohl die Box relativ neu ist (KW03/21). Sollte sich das Branding nicht entfernen lassen, werde ich wieder meine freie 6590 anschließen. Telefonie hätte ich schon gerne. Btw. habe ich diese FB bei eb*y Kleinanzeigen für 130€ erstanden; von einem ratlosen Verkäufer der eine freie Box kaufen wollte, aber diese FB bekommen hat.

@fesc du schreibst hier:
As i'm being asked, changing firmware_version permanently is possible by editing the SPI flash partitions (see below)
wie riskant ist denn so ein Eingriff? Ich nehme an, ich lade mir den Inhalt vom SPI flash runter, editiere und schreibe es wieder auf den SPI flash? Geht das per ssh oder nur per serieller Schnittstelle?

Grüße
 

gtntdev

Neuer User
Mitglied seit
16 Mrz 2021
Beiträge
15
Punkte für Reaktionen
0
Punkte
1
Hi,

ich habe mir jetzt eine andere 6591 geholt (retail, avm). Leider auch hier wieder kein Wort zur Bios Version in den erweiterten Supportdaten.
Produktionsdatum ist 13.01.2021.
4.9.199
DMC RTL=y,postHSR=9
HWRevision 233
HWSubRevision 8
ProductID Fritz_Box_HW233
annex Kabel
autoload yes
bootloaderVersion 1.3614
country 049
firmware_info 161.07.22
firmware_version avm
language de
linux_fs_start 0
Hab dann auf gut Glück mal folgendes versucht (mit statischer IP, Ubuntu VM):
[email protected]:~/tmp/freetz/ffritz/build/puma7/uimage$ ftp 192.168.178.1
Connected to 192.168.178.1.
220 ADAM2 FTP Server ready
Name (192.168.178.1:strikeback): adam2
331 Password required for adam2
Password:
230 User adam2 successfully logged in
Remote system type is AVM.
ftp> bin
200 Type set to BINARY
ftp> quote MEDIA FLSH
200 Media set to MEDIA_FLASH
ftp> passive
Passive mode on.
ftp> quote GETENV linux_fs_start
linux_fs_start 0
ftp> put part_03_ATOM_ROOTFS.bin mtd;
local: part_03_ATOM_ROOTFS.bin remote: mtd;

Passive mode refused.
ftp> put part_02_ATOM_KERNEL.bin mtd<
local: part_02_ATOM_KERNEL.bin remote: mtd<
200 GETENV command successful
Passive mode address scan failure.Shouldn't happen!
ftp> put part_09_ARM_ROOTFS.bin mtd=
local: part_09_ARM_ROOTFS.bin remote: mtd=
227 Entering Passive Mode (192,168,178,1,176,130)
227 Entering Passive Mode (192,168,178,1,176,130)
ftp> put part_08_ARM_KERNEL.bin mtd>
local: part_08_ARM_KERNEL.bin remote: mtd>
227 Entering Passive Mode (192,168,178,1,176,130)
ftp: connect: Connection refused
ftp> quote SETENV linux_fs_start 1
120 Service not ready, please wait
425 can't open data connection
ftp> quote REBOOT
200 SETENV command successful
ftp>
Dachte es ist einen Versuch wert mal das selbe auf die aktive Partition zu versuchen (linux_fs_start 0) mit:
put part_03_ATOM_ROOTFS.bin mtd0
put part_02_ATOM_KERNEL.bin mtd1
put part_09_ARM_ROOTFS.bin mtd6
put part_08_ARM_KERNEL.bin mtd7
Seitdem bootet die FB nicht mehr richtig, also ftp hab ich noch Zugriff, aber wenn sie hochgefahren ist, kann man sie nicht mal mehr pingen.
Mir war natürlich klar, dass das passieren kann.
Bin auch gern bereit bisschen was mit der Box auszuprobieren und vielleicht dem ein oder anderen so in Zukunft helfen zu können.

Danke für alle Ratschläge und schöne Ostern,
Lukas
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,927
Punkte für Reaktionen
1,298
Punkte
113
Nur mal so aus Interesse ... in welcher Anleitung findet man denn eine Kommando-Reihenfolge, die erst ein GETENV und danach dann ein STOR (nichts anderes ist ein clientseitiges put ja) innerhalb derselben Session bzw. in dieser Abfolge, enthält - zumindest bei Verwendung eines "normalen" FTP-Clients?

Und sollte man nicht irgendwann stutzig werden, wenn innerhalb einer FTP-Session dann Fehlermeldungen auftauchen, die da nicht hingehören? Allerspätestens beim ftp: connect: Connection refused müßte man ja noch einmal nachdenken.

EDIT: Im Protokoll oben kann man ja mal wieder wunderschön sehen, wie eine Antwort des Servers, die sich nicht an den FTP-Standard für mehrzeilige Antworten hält, genau den hier verwendeten FTP-Client so weit "verwirrt", daß danach praktisch gar nichts mehr klappt, weil er die Antworten des Servers nicht mehr sauber seinen eigenen gesendeten Kommandos zuordnen kann. Es gab ja Gründe, warum ich für den Zugriff auf den FTP-Server in EVA spezialisierte Shell-Skripte (oder auch PowerShell) bereitgestellt habe und nicht einfach nur auf die Benutzung eines FTP-Clients verwiesen wurde (das war nicht nur Langeweile, die mich dazu bewog). Wenn man schon einen FTP-Client benutzt, sollte man eben erst mal klären, ob der von einem GETENV durcheinander gebracht wird oder nicht ... ist das der Fall, sollte man nach einem GETENV nichts wirklich Wichtiges mehr machen in dieser FTP-Session.
 
Zuletzt bearbeitet:

gtntdev

Neuer User
Mitglied seit
16 Mrz 2021
Beiträge
15
Punkte für Reaktionen
0
Punkte
1
in welcher Anleitung findet man denn eine Kommando-Reihenfolge ...
Das findest man hier. Genaus so wie den Hinweis, dass es mit einem Standard FTP Ubuntu/Debian client funktionieren sollte.

Und sollte man nicht irgendwann stutzig werden
Doch natürlich, dachte aber fälschlicherweise, wenn "connection refused" kommt, dass dann eh gar nichts übertragen wird.

Liebe Grüße,
Lukas
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,927
Punkte für Reaktionen
1,298
Punkte
113
OK, das ist tatsächlich bei @fesc so beschrieben und - ohne den Hinweis auf das "Session-Problem" - schon ziemlich fehlerträchtig ... denn wie man an Deinem Versuch sieht, ist das eben ein reines Glücksspiel, wenn man nach einem GETENV weitere Kommandos innerhalb derselben FTP-Session verwendet.

Das Problem ist durchaus bekannt ... und es hängt tatsächlich auch von der Implementierung des Clients ab, wie er mit dem, vom RFC-Inhalt abweichenden, Verhalten des FTP-Servers dann umgeht. Das kann sich aber mit der nächsten Version des FTP-Clients schon wieder ändern ... oder auch mit einem Update des verwendeten OS kann sich der genutzte FTP-Client ändern, etc.

Offenbar hat @fesc selbst dieses Problem noch nicht gehabt ... oder er hat das nur noch nicht in dieser Abfolge innerhalb einer Session ausgeführt. Die "Ansage", daß das mit dem CLI-Client von Ubuntu/Debian funktionieren sollte, bezieht sich offenbar eher auf die Frage, ob der Client den benötigten "passive mode" bei Datenübertragungen beherrscht oder nicht.

Im RFC (https://tools.ietf.org/html/rfc959) ist für FTP-Replies nun mal festgelegt:
A reply is defined to contain the 3-digit code, followed by Space <SP>, followed by one line of text (where some maximum line length has been specified), and terminated by the Telnet end-of-line code.

There will be cases however, where the text is longer than a single line. In these cases the complete text must be bracketed so the User-process knows when it may stop reading the reply (i.e. stop processing input on the control connection) and go do other things.

This requires a special format on the first line to indicate that more than one line is coming, and another on the last line to designate it as the last. At least one of these must contain the appropriate reply code to indicate the state of the transaction. To satisfy all factions, it was decided that both the first and last line codes should be the same.
Eine standardkonforme Antwort des Servers auf ein (erfolgreiches) GETENV müßte also so aussehen:
Rich (BBCode):
ftp> quote GETENV linux_fs_start
200-GETENV response:
linux_fs_start 0
200 GETENV command successful
, wobei der Text in der ersten Zeile nach dem Bindestrich nicht relevant ist, weil erst die zweite Zeile, die mit 200 beginnt, die Antwort abschließt. Nur fehlt bei AVM eben genau diese erste Zeile und damit ist das linux_fs_start 0 "außerhalb des Protokolls". Je nachdem, wie der FTP-Client damit umgeht/umgehen kann, kommt dann etwas wie oben bei Dir heraus. Eine neue Session hilft hier, weil damit auch die State-Machine für die Interpretation der Server-Responses im FTP-Client zurückgesetzt wird.

Und falls jetzt jemand denken sollte, das wäre auch irgendeine Spezialität der Puma7-Boxen ... weit gefehlt. Der FTP-Server in EVA verhält sich überall so (zumindest die, die ich bisher gesehen habe) und um genau dieses "Glücksspiel", welcher Client daraus nun was macht, nicht betreiben zu müssen, gibt es die Skript-Files in meinem YourFritz-Repo: https://github.com/PeterPawn/YourFritz/tree/master/eva_tools - diese bedienen die FTP-Session "von Hand" und sind darauf vorbereitet, daß nach einem GETENV-Kommando diese nicht-standardkonforme Antwort kommen kann.
 
Zuletzt bearbeitet:

Flole

Mitglied
Mitglied seit
23 Dez 2013
Beiträge
235
Punkte für Reaktionen
18
Punkte
18
Du kannst mal versuchen WLAN und DECT zu deaktivieren um so dmesg Ausgaben zu reduzieren. Schau am besten mal was am Ende kommt und ob das vielleicht irgendwie deaktiviert werden kann.
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,927
Punkte für Reaktionen
1,298
Punkte
113
Ist wohl doch was falsch
Hast Du es selbst noch einmal (mit dem erwähnten/empfohlenen FTP-Client) probiert? Kommt der tatsächlich auch sofort beim GETENV durcheinander?
 

fesc

Mitglied
Mitglied seit
14 Mai 2016
Beiträge
317
Punkte für Reaktionen
65
Punkte
28
Habs eben gemacht, und wenn man es in der Reihenfolge durchführt wie bei mir beschrieben (getenv vor put) dann kommt der client durcheinander und das Fehlerbild ist wie geschildert ("Passive mode refused.").
Das hatte ich wohl mal so reingeschrieben ohne die Konsequenzen zu beachten.

@gtntdev : also vor dem put das getenv weglassen (oder gleich Peters skripte nehmen). Mir ist eigentlich noch keine Box untergekommen die sich bei funtionierendem ftp server nicht mehr recovern lassen konnte (ich hoffe das bleibt so).
 
  • Like
Reaktionen: gtntdev und PeterPawn

gtntdev

Neuer User
Mitglied seit
16 Mrz 2021
Beiträge
15
Punkte für Reaktionen
0
Punkte
1
@fesc diese gehört auch nicht dazu, also ssh ist aktiv und FB bootet von neuer aktiven Partition. Wie gesagt, danke für die tolle Arbeit hier!

EDIT: ssh pw ändern über telnet, freetz-ng compilieren, übertragen auf den NAS Speicher und anschließend installieren hat auch wunderbar funktioniert:)
Für alle die den Post hier lesen, wie ich vor ein paar Tagen: keine Erfahrungen mit dem Firmware Flashen einer FB sind in Ordnung, aber wenn ihr euch nicht sicher fühlt mit Linux (shell usw.), dann lasst es besser bleiben:)

Viele Grüße,
Lukas
 
Zuletzt bearbeitet:

guidox

Neuer User
Mitglied seit
31 Dez 2007
Beiträge
105
Punkte für Reaktionen
4
Punkte
18
Hallo,
hier noch ein kleines Feedback zu meiner 6591 mit (ehemals) kdg branding. Wie in meinem Beitrag #401 geschrieben, hat das Update und setzen des RTL-flag funktioniert und die FB lief die letzten 5 Tage stabil und auch mit DVB-C. Wegen des kdg-Branding war allerdings das Hinzufügen von Rufnummern nicht möglich.
Dank Unterstützung von @fesc habe ich nun das kdg-Branding entfernt.
Die FB verhält sich normal, Telefonie funktioniert einwandfrei und der Hinweis auf der Benutzeroberfläche (vom Hersteller nicht unterstützte Änderungen....) ist auch verschwunden.
Die Firmware selbst enthält noch den user-oem.patch von fesc. Diesen könnte ich doch eigentlich jetzt weglassen? Außerdem dürfte jetzt auch das automatische Update durch AVM funktionieren, oder? (auch wenn ich dadurch den ssh-Zugang verliere)

UPDATE:
Habe gerade das Update von v7.22 auf v7.26 über die Update Funktion der Fritz!Box durchgeführt. Läuft weiterhin ohne Probleme; der ssh-Zugang ist logischerweise weg.

LG
 
Zuletzt bearbeitet:

teufel2k

Neuer User
Mitglied seit
16 Okt 2006
Beiträge
38
Punkte für Reaktionen
1
Punkte
8
Danke @guidox und @fesc

So, das hat bei mir auch funktioniert und aus einer Intl. Version eine RTL = Y Version gemacht... super und das auch noch permanent!

SSH Zugang ist nach einem normalen Update über die Weboberfläche auf 07.26 natürlich weg, allerdings bekomme ich wider erwarten noch immer die Meldung "Vom Hersteller nicht unterstützte Änderungen Weitere Informationen"

Merkwürdig?!?!
 

guidox

Neuer User
Mitglied seit
31 Dez 2007
Beiträge
105
Punkte für Reaktionen
4
Punkte
18
[...]allerdings bekomme ich wider erwarten noch immer die Meldung "Vom Hersteller nicht unterstützte Änderungen Weitere Informationen"
Hast du die Box einmal auf Werkseinstellungen gesetzt?
 
  • Like
Reaktionen: teufel2k

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,927
Punkte für Reaktionen
1,298
Punkte
113

Chatty

Aktives Mitglied
Mitglied seit
13 Mrz 2006
Beiträge
1,777
Punkte für Reaktionen
33
Punkte
48
Was Peter wirklich sagen wollte ist, dass nur eine Recovery hilft, die es damals zur 7.04 gab. Aber die wurde ja relativ schnell entfernt.

Alternativ muss man die Stelle finden, wo die Firmware diese Info speichert und dann dort anpacken. Gefunden habe ich diese Stelle auch noch nicht...
 
Zuletzt bearbeitet:

Flole

Mitglied
Mitglied seit
23 Dez 2013
Beiträge
235
Punkte für Reaktionen
18
Punkte
18
... beeindrucken den TFFS-Node 87 nicht wirklich.
Hmmm, reden wir bei den Puma 7 Modellen wirklich noch über das Node? Clearen kann man es nicht mehr (bzw. es bringt nichts). Die Stelle zu finden ist nicht sonderlich schwierig, /var/flash/fw_attrib ;) Das kann nun natürlich durch irgendwelche komischen Umbiegungen wieder als TFFS Node 87 enden, aber ich glaube nicht.
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,927
Punkte für Reaktionen
1,298
Punkte
113
Clearen kann man es nicht mehr (bzw. es bringt nichts).
Sicher? Ich kann mir nur schwer vorstellen, daß AVM diesen Mechanismus noch einmal gesondert "nachgebaut" haben soll ... irgendwo müssen ja auch die anderen Daten aus dem TFFS gespeichert sein. Wenn ich mich richtig erinnere (ich habe keine 6591, wo ich nachsehen könnte), betreibt AVM da eine MTD-Emulation auf einem Block-Device (mit block2mtd?), um dann in diesem MTD wieder das NAND-Format des TFFS zu speichern.

Wobei ich zugegebenermaßen geschlafen hatte, was das Modell angeht, welches in diesem Thread Thema ist ... ich bin mir nur ziemlich sicher, daß dieser "Marker" auch bei der 6591 nicht einfach durch das Zurücksetzen auf die Werkseinstellungen gelöscht wird.

Jedoch kann das jemand MIT der Box und deren Support-Daten ja leicht herausfinden - was wäre denn /var/flash/fw_attrib für eine Datei, falls die tatsächlich existiert? Bei anderen Modellen wird da ja gar kein Dateiname für den TFFS-Node gemappt ... das geht (beim Eintragen (m.W. von mehreren Stellen) und beim Auslesen durch den ctlmgr) alles auch ohne den Zugriff auf eine Datei im FS - das regelt die libboxlib.so (aus dem Kopf, ggf. selbst prüfen) alles alleine mit irgendwelchen boxutil_fwattrib_*-Funktionen.

Ich würde mal mutmaßen (ohne mir jetzt die Firmware der 6591 zu entpacken), daß diese Funktionen auch bei der 6591 noch existieren - ob die aber in die emulierte TFFS-Partition schreiben, weiß ich tatsächlich nicht. Aber auch wenn da ggf. der TFFS-Treiber kein procfs-Interface haben sollte und damit ein clear_id nicht funktioniert ... zumindest das Schreiben einer leeren Datei (ÉDIT: also ein cat mit 0 Byte Länge) hätte ich als erfolgreich erwartet.

Nun ist das ja wohl eine Client-Server-Installation des TFFS3 bei der 6591 ... ein System verwaltet den physikalischen Speicher (also die MTD-Emulation auf dem Block-Device - wenn das oben stimmt, was ich in Erinnerung habe) und dieses stellt den Zugriff auf die TFFS-Nodes dem anderen System dann nur noch über das Netzwerk bereit.

Ich weiß nicht wirklich, welcher Kern da welche Aufgaben übernimmt ... aber das wäre ggf. noch ein Tipp meinerseits für einen alternativen Versuch - halt auf dem System, was tatsächlich den Zugriff auf das MTD hat (und wenn da auch kein clear_id geht, dann eben mit der leeren Datei) und dem anderen als TFFS-Server dient. Das sollte über die armconsole (auch aus dem Kopf und ohne Garantie für korrekte Wiedergabe) ja auch vom x86-System aus machbar sein.
 
Zuletzt bearbeitet:

Chatty

Aktives Mitglied
Mitglied seit
13 Mrz 2006
Beiträge
1,777
Punkte für Reaktionen
33
Punkte
48
Code:
# ls -al /var/flash/fw_attrib
-rw-r--r--    1 root     root             6 Jan  2 23:37 /var/flash/fw_attrib
# cat /dev/null >/var/flash/fw_attrib
# ls -al /var/flash/fw_attrib
-rw-r--r--    1 root     root             0 Apr 22 08:47 /var/flash/fw_attrib
... und der Hinweis verschwindet. Vielen Dank!
 

Erhalten Sie 3CX für 1 Jahr kostenlos!

Gehostet, in Ihrer privaten Cloud oder on-Premise! Ganz ohne Haken. Geben Sie Ihren Namen und Ihre E-Mail an und los geht´s:

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.
oder via