FB 6591 verschiedenes

Kann es sein, daß andere 6591 in "DMC" kein "RTL=n"
Richtig, daran liegt es. Wenn RTL=n drinsteht (so wie das bei den gebrandeten boxen der fall ist) dann ist u.A. firmware-update deaktiviert. Das lässt sich auch nicht via EVA/ftp ändern.

Edit: man kann natürlich ein modifiziertes image installieren, dann geht auch wieder der update. Nur würde dann halt wiederum das per update installierte image das gleiche Problem haben. Eine halbwegs sichere variante "DMC" zu modifizieren habe ich nicht gefunden, allerdings auch nicht intensiv danach gesucht.
 
Hallo zusammen,

danke für die Analyse. Wenn ich alles richtig verstanden habe dann habe ich hier zwar keine gebrandete Fritz!Box, dafür aber eine bei der das Online Update kastriert ist.

Was wäre denn die "einfachste" (evtl sicherste) Möglichkeit ein halbwegs aktuelles (stabiles) os hier drauf zubekommen? Wenn auch ohne Online Update Möglichkeit... Oder halt mit einem einfachen :-D

Gruß,
teufel2k
 
Zuletzt bearbeitet:
Was wäre denn die "einfachste" (evtl sicherste) Möglichkeit ein halbwegs aktuelles (stabiles) os hier drauf zubekommen
Aus meiner Sicht .. erst mal haengt es von der UEFI version der box ab, aber anhand dem format der support-daten gehe ich davon aus dass du eine hast die nicht per EVA/ftp updatebar ist. Genauere info bekommt man wenn man (relativ zeitnah nach dem start der box) erweiterte supportdaten erstellt und nach dem BIOS versionsstring sucht, etwa

[ 0.000000] DMI: Intel Corporation PUMA 7 C0 PLATFORM/TBD, BIOS CGM2.86C.597968.R.1809251311 09/25/2018

Ja nachdem ob alt oder neu brauchst du eine serielle konsole oder es geht via FTP (siehe https://bitbucket.org/fesc2000/ffritz/src/6591/README-6591.md, sorry, englisch).

Edit: Ob du das für dich als "sicher" beurteilst musst Du entscheiden ..
 
Ja. Dein verlinkter Beitrag von @fesc ist veraltet. Er hatte sich dbzgl. etwas später revidiert.

Wenn ich alles richtig verstanden habe dann habe ich hier zwar keine gebrandete Fritz!Box, dafür aber eine bei der das Online Update kastriert ist.
Da es keine Retail-Version zu sein scheint würde ich jetzt mal kühn behaupten, dass es doch eine gebrandete Box ist. Zumindest eine die wohl ursprünglich mal von irgendeinem (kleineren?) Kabelnetzbetreiber stammte. Eine "freie" ist es offensichtlich nicht.
 
[ 0.000000] DMI: Intel Corporation PUMA 7 C0 PLATFORM/TBD, BIOS CGM2.86C.597968.R.1809251311 09/25/2018

Also dein Beispiel passt genau... so schaut es auch bei mir aus.

Das heißt ich kaufe mir jetzt erstmal nen Adpater... Spontan den "FTDI FT232RL USB-zu-TTL-UART-Adapter" und versuche damit auf die noch zu öffnende Box zuzugreifen.

Ich melde mich wenn ich soweit bin.

Danke für eure Hilfe
 
  • Like
Reaktionen: mvoege
Also lässt sich sozusagen bei der 6591 ausschließlich linux_fs_start im ENV via FTP rebootfest ändern?

Ich meine vor nicht all zu langer Zeit den Tipp mal bei einem Problem einer 6591 (oder war es die 6590?) gegeben zu haben und es wurde imo geantwortet, dass es nicht rebootfest ist.

Aber schön das man zumindest ohne Handstände die FW so wechseln kann. (Oder liegt es am UEFI ob rebootfest oder nicht [bei dieser Variable]?)
 
@stoney
Nein. Es sollte sich bspw. auch "firmware_info" (wobei das von der startenden Firmware ggf. wieder überschrieben wird) oder "language" rebootfest ändern lassen.
 
FTDI FT232RL USB-zu-TTL-UART-Adapter
Er sollte 1.8V können.

Die Kombination "firmware_version=avm" und nicht-retail ist übrigens durchaus vorgesehen. In dem Fall wird (genauso wie bei lgi und kgd firmware_version) tr069 managed upgrade aktiviert.
 
  • Like
Reaktionen: teufel2k
Neues Beta Image ahead! *yay*

-> FRITZ.Box_6591_Cable-07.19-78763-LabBETA.image
 
loock here:
 
Wieder 'mal ein unnützer Post von @eisbaerin - wo genau liegt denn Dein Problem daran, dass nun in einem solchem Thread wie diesen hier, einfach auch Deiner bereits publizierte "Info" ohne das Du selbst dorthin zitiert wurdest, wiederholt wurde?

Ich glaube es reicht nun langsam mit diesem Verhalten (ebenso wie das "Und nun mal komplett..." - in den Sammelthreads zu Labor/Inhouse für mehrere Modelle, sowie die indirekte Nötigung anderer User, weil Du diverse Infos/Changlogs noch nicht vorliegen hast - ein Anderer dies "nachliefert" und Du diese dann zum löschen ihrer Posts veranlasst, nur weil Du 1st sein willst und dann Deinen "voreiligen" Post um diese Infos ergänzt/editierst? - Wir sind hier nicht im SozialNetwork, Deutschkurs - wie du es ja auch oft öffentlich "breittrittst - sondern im IPPF - mit all den so lange "gepredigten" Werten, was das Board ausmacht)
 
  • Like
Reaktionen: Bauernliste88
Was hast du denn für ein Problem? Schlechten Tag gehabt?
Ich finde den Post #151 noch viel unnützer. Ohne den hätte ich hier nicht geantwortet.
Ich wollte einfach nur, daß hier nicht über die Labor diskutiert wird.
Deshalb der Link zur richtigen Stelle.
Was du da aber wieder alles hinein interpretierst ...

Und der Rest von dir ist ja völliger Quatsch.
Vielleicht verstehst du meine Logik nicht.
Ich versuch immer positiv zu denken und gutes zu tun, versuche du das auch mal!

BTW: Den Doppelpost, den du von mir zusammengefügt hast, den hätte ich noch zusammengefügt. Du warst nur schneller.
 
Zuletzt bearbeitet:
@fesc:
Hast Du eigentlich mal getestet, ob die 6591 sich wie die GRX-Modelle verhält und den FTP-Server im Bootloader nur dann zugänglich macht, wenn es auch ein "Power-On-Reboot" war? Bisher hatte ich das nur bei den GRX-Boxen (selbst) beobachtet und es da als "Errungenschaft" gefeiert, weil damit ein wichtiger Teil der Möglichkeiten zur Manipulation einer FRITZ!Box entfällt, wenn es nicht mehr bei jeder Aktivierung von EVA möglich ist, auf den FTP-Server zuzugreifen.

Danach gab es zwar auch noch die 7520/7530 (als weitere Plattform), wo ich das ebenfalls nicht weiß, aber die Puma7-Reihe (denn ich vermute mal, daß sich hier 6591 und 6660 identisch verhalten würden) ist "noch neuer" und so würde mich mal interessieren, ob das nicht bei den GRX-Boxen doch nur auf einem Problem beim Initialisieren des internen Switches beruht (bei irgendeinem anderen Grund als "Power-On-Reboot", wo der Switch dann sicherlich beim Power-On automatisch "in Grundstellung" geht, was bei anderen Ursachen vermutlich nicht der Fall sein wird), was die zweite Erklärung für dieses Phänomen sein könnte.

Wenn das wirklich "Absicht" von AVM war, müßte es sich ja über die neueren Modelle hinweg fortsetzen.

EDIT: Ich habe das gerade noch mal genauer gemessen/untersucht bei einer 7580 - wenn es sich nicht um ein "Power-On-Reboot" handelt, wartet der Loader gar nicht erst, bevor er mit dem Entpacken des Kernels beginnt - da ist keinerlei "Karenzzeit" zu sehen auf der Seriellen. Damit verfestigt sich bei mir der Eindruck, daß es sich um ein absichtliches Feature handelt - zumal ja auch diese Verwaltung der ganzen Reboot-States irgendeinen Sinn machen sollte. Da wird extra ein Bereich im RAM reserviert, in dem diese Info abgelegt wird und damit auch den Neustart überdauert und auch unter "/proc/sys/urlader/reboot_status" kann man den im laufenden System auslesen.
 
Zuletzt bearbeitet:
BTW:
Danach gab es zwar auch noch die 7520/7530 (als weitere Plattform), wo ich das ebenfalls nicht weiß, ...
Bei einer 7520 mit Bootloader-Ver. 1.10733 (Serien-Nr. M053*) ist dieses Verhalten (Bootloader nur nach einem Kaltstart erreichbar) ebenfalls zu beobachten gewesen. Wie das bei älteren 7520ern oder der 7530 aussieht entzieht sich dagegen meiner Kenntnis.
 
  • Like
Reaktionen: PeterPawn
Bei meiner "entfesselten" 7520 (7530 mit 7.12) antwortet der Bootloader auf ein Pingpaket dann verstummt er wieder, nach einem Neustart via GUI - Nach POR verhält er sich wie gewohnt.
Code:
SerialNumber    L0457*
bootloaderVersion    1.10211
 
@PeterPawn
Kann es sein, daß andere 6591 in "DMC" kein "RTL=n" (sondern ein "RTL=y") stehen haben? Das könnte in der "/etc/init.d/rc.conf" zur Unterscheidung der Retail-Version (mit Update-Möglichkeit) verwendet werden, wenn man mal einen Blick in die Firmware wirft.
Also ich habe eine "freie" 6591 (Artikelnummer 20002857) am Laufen und zwei weitere "freie" 6591 die ich zum Testen habe. Alle hatten tatsächlich in der Variablen DCM den Wert "RTL=y".
 
Hast Du eigentlich mal getestet, ob die 6591 sich wie die GRX-Modelle verhält und den FTP-Server im Bootloader nur dann zugänglich macht, wenn es auch ein "Power-On-Reboot" war?
Habe ich eben mal gemacht. Ich habe es geschafft auch nach einem software-reboot (aus Linux) auf den bootloader zu kommen. Allerdings ist das die "alte" UEFI/eva version, ob sich die aktuelle genauso verhält weiss ich nicht.
 
  • Like
Reaktionen: PeterPawn
Kennt eigentlich jemand die Unterschiede zwischen den Providerboxen Vodafone (20002858) und Unitymedia (20002827)?

Ich habe hier 2 Versuchskannichen - jeweils eine VF und eine UM...

Gestartet habe ich mit der Vodafone Edition --> lt. Supportdaten BIOS CGM2.86C.627075.R.1910091149 10/09/2019 --> also erreichbar über EVA, löten nicht notwendig
Image gebaut, wie auf Seite 2 geschrieben, den "user-oem-patch" bei ARM und Atom eingefügt und das Image auf Basis von der 7.19 Beta erstellt (in der conf angepasst).

Via EVA eingeloggt, und nach dieser Anleitung vorgegangen: https://bitbucket.org/fesc2000/ffritz/src/6591/README-6591.md
Verwendet habe ich eine ältere Linux Mint Distri und den dazugehörigen FTP-Client

Partionset 1 war aktiv, also wollte ich die Files auf die Partionen von Partionset 0 schreiben --> das war nicht möglich, ist immer abgebrochen und ich musste mich darauf hin erneut einloggen!
Umschalten des PS mit "quote SETENV linux_fs_start 0" ging augenscheinlich, nach einem Neustart war jedoch wieder "1" aktiv

Kurzerhand (no risk, no fun) habe ich Partionenset 1 benutzt, die 4 Partionen aktiven Partitionen beschrieben und die Box neu gestartet.

Die Box lief auf Anhieb problemlos mit der Labor-Firmware hoch und verhält sich wie eine Retail. An meinem VF-Anschluss lässt sie sich natürlich trotzdem nicht aktivieren...

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

Heute das gleich mit einer ehemaligen Unitymedia Providerbox - lt. Supportdaten gleicher BIOS-Stand, auch erreich- und flashbar via EVA
Im ersten Versuch das gleiche Image genommen, hab mir das Neukompilieren gespart (wusste ja, dass das Image läuft und passend gepatched ist)

Gleiches Verhalten mit den Partitionsets, 1 aktiv, Umschalten nicht persistent, auf 0 lässt sich nicht schreiben.
Wieder das aktive PS benutzt, Schreiben ging problemlos, seit dem ist die Box im Bootloop.

Images neu gebaut, verschiedene Versionen benutzt (neuste 7.19er Labor, 7.13er) - immer das Selbe - komme aus dem Bootloop nicht mehr raus...

EVA ist einmalig nach HW-Neustart erreichbar, von daher bin ich noch guter Hoffnung, dass das Teil irgendwie zu retten ist.

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

Kennt jemand die Unterschiede und kann sich das Verhalten erklären. Gleiches BIOS, gleiches gepatchtes Image, auf einer läufts, auf der anderen nicht...
Warum kann man die Partionensets nicht umschalten und kann auf das nicht-aktive nicht schreiben?

Die VF-Box hatte vorher das kastrierte 7.03 OS drauf, die UM war schon auf 7.13 - gibts da evtl. einen Zusammenhang?


--------- EDIT / Update

Bricked Box ist gerettet, habe nicht den "normalen" FTP-Client, sondern NCFTP verwendet, damit lassen sich beide Partionsets beschreiben (?) und die Box bootet jetzt fehlerfrei wie eine Retail hoch. Seltsam ist jedoch, dass es mit dem Onboard-FTP-Client mit der VF-Box zuvor funktioniert hat....
 
Zuletzt bearbeitet:
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

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.