[ gelöst ] 6490 per ftp/bootloader flashen

nein vorher habe ich nicht versucht zu löschen (kam mir allerdings auch schon in den Sinn) - also liegts auf jeden Fall mal nicht an der Bootloaderversion 1.2567
 
also liegts auf jeden Fall mal nicht an der Bootloaderversion 1.2567
Das unterschreibe ich noch nicht ... die Vermutung war ja, daß der Bootloader "etwas speziell" ist und ein paar Probleme enthält. Eines könnte sich so äußern, daß dieses - Dir ja auch bekannte - Problem mit der falschen MAC-Adresse auftaucht. Der Rest der Behandlung im TCP-Stack des Bootloaders kann davon aber total unabhängig sein und wenn bei @noob_noob die von seinem PC gesendeten Pakete "normgerecht" waren, dann sagt das Fehlen von entsprechenden Problemen bei seinen Zugriffen noch nichts darüber aus, wie es da bei irgendwelchen "Abartigkeiten" im TCP-Protokoll aussehen würde.

Du wolltest ja nur aus der Tatsache, daß es mit der anderen Box und Deinen existierenden Rechnern vielleicht problemlos klappt, unmittelbar darauf schließen, daß dann automatisch mit dem Rechner alles "in Ordnung" wäre und es auch mit dem Problembären funktionieren müßte. Diese Schlußfolgerung hat sich aber in meinen Augen ohnehin erledigt, da nunmehr ja feststeht, daß die andere Box eine andere Bootloader-Version verwendet und damit kannst Du das gerne noch probieren (wenn es ebenfalls schiefgehen sollte, wäre das zumindest ein Zeichen, daß die andere Bootloader-Version ebenfalls Probleme mit dem Rest Deiner Technik hat) ... aber ich verstehe nicht so ganz, was Du von dieser Feststellung am Ende hättest.

Na gut, es wäre die "Gewißheit", daß es am PC (in der Kombination von Hardware und Betriebsystem, auch wenn Du das mit mehreren versucht hast - zumindest wohl beim System, ob das auch mehrere Rechner waren, weiß ich schon wieder nicht mehr) liegt - aber das kannst Du ja auch damit testen, daß da ein anderes Gerät erfolgreich die Problembox beschreibt ... ich weiß halt nicht, wie Deine Auswahlmöglichkeiten da aussehen.

Aber ich würde tatsächlich nicht erwarten, daß ein Versuch des Beschreibens einer inaktiven Partition über EVA das aktive System zerstört (wenn der Bootloader korrekt arbeitet - wobei ich unter "korrekt" jetzt mal "so wie die von mir getesteten" verstehe, weil natürlich die Entscheidung, was richtig und was falsch ist, davon abhängen wird, was man eigentlich erreichen wollte) ... allerdings immer schön beachten, daß es keine "feste Zuordnung" für die eMMC-Partitionen gibt im Bootloader (wie das bei den MTD-Devices in einer laufenden VR9-Box z.B. der Fall wäre), sondern daß diese Zuordnung (also welche eMMC-Partition sich gerade hinter mtd0 "verbirgt") vom Inhalt von "linux_fs_start" abhängig ist. Das ist schon ein Unterschied und ich will das nur noch einmal betonen, ehe sich der Nächste jetzt mit der Überlegung: '"linux_fs_start=1" ergibt "mtd11-mtd14" als Ziel des Uploads.' dann wieder ins Knie schießt.

Ob sich hinter "mtd0" in EVA nun gerade "/dev/mmcblk0p1" oder "/dev/mmcblk0p5" (aus einem laufenden System) verbirgt, liegt am Wert von "linux_fs_start" ... allerdings wird bei 0 eben immer "mmcblk0p1" die Partition mit dem zu startenden ARM-Filesystem sein und bei 1 die in "mmcblk0p5". Das ist sicherlich - gerade für Anfänger - verwirrend und man muß höllisch aufpassen, da nicht durcheinander zu kommen und sich erst recht nicht von irgendwelchen alten Anleitungen (die sich ohnehin auf vollkommen andere Modelle ohne eMMC-Partitionen beziehen) beeinflussen lassen.
 
Ich habe 2 Rechner

Rechner 1: Win7 64Bit mit VM(freetz - latest svn)
Rechner 2: Ubuntu 16.04

Auf beiden Rechnern habe ich es ebenfalls mit knoppix und suse LiveCD versucht.


Ich habe noch ein paar ältere Rechner/Laptops mit welchen ich die HW Seite (meinerseits) ausschließen könnte, klar wäre es jetzt toll gewesen, wenn die zweite Box auch diesen Bootloader hätte, in diesem Fall da er anders ist, ist es mir auch klar, dass es ansich keinerlei Aussage hat, ob das Schreiben bei dieser klappt.

- - - Aktualisiert - - -

[SNIP]
mal mit erase versucht die parttionen vor dem flashen zu löschen?
keine ahnung, ob das funktioniert aber versuch macht kluch.
[SNIP]

Code:
ftp> quote erase mtd*
502 Command not implemented
 
hallöle, fürchte ich hab mir nen briefbeschwerer gebastelt.. alle leds gehen kurz an, dann blinkt die power-leuchte ein paar mal, bleibt dann konstant, blinkt wieder, dann gehen die leds aus und dann beginnt das spiel von vorn.. bootschleife?

falls ja: was hab ich falsch gemacht? vorgegangen bin ich so:

heini66@heini66-VirtualBox ~/var/remote/var/tmp $ ftp 192.168.178.1
Connected to 192.168.178.1.
220 ADAM2 FTP Server ready
Name (192.168.178.1:heini66): adam2
331 Password required for adam2
Password:
230 User adam2 successfully logged in
Remote system type is AVM.
ftp> quote MEDIA FLSH
200 Media set to MEDIA_FLASH
ftp> binary
200 Type set to BINARY
ftp> passive
Passive mode on.
ftp> put filesystem.image mtd0
local: filesystem.image remote: mtd0
227 Entering Passive Mode (192,168,178,1,54,69)
150 Opening BINARY data connection
226 Transfer complete
14896185 bytes sent in 12.10 secs (1.1737 MB/s)
ftp> put kernel.image mtd1
local: kernel.image remote: mtd1
227 Entering Passive Mode (192,168,178,1,54,69)
150 Opening BINARY data connection
226 Transfer complete
1818451 bytes sent in 1.43 secs (1.2154 MB/s)
ftp> exit
221 Thank you for using the FTP service on ADAM2
heini66@heini66-VirtualBox ~/var/remote/var/tmp $ cd x86/
heini66@heini66-VirtualBox ~/var/remote/var/tmp/x86 $ ftp 192.168.178.1
Connected to 192.168.178.1.
220 ADAM2 FTP Server ready
Name (192.168.178.1:heini66): adam2
331 Password required for adam2
Password:
230 User adam2 successfully logged in
Remote system type is AVM.
ftp> quote MEDIA FLASH
200 Media set to MEDIA_SDRAM
ftp> binary
200 Type set to BINARY
ftp> passive
Passive mode on.
ftp> put filesystem.image mtd6
local: filesystem.image remote: mtd6
227 Entering Passive Mode (192,168,178,1,54,69)
150 Opening BINARY data connection
226 Transfer complete
13404484 bytes sent in 1.66 secs (7.6784 MB/s)
ftp> put kernel.image mtd7
local: kernel.image remote: mtd7
227 Entering Passive Mode (192,168,178,1,54,69)
150 Opening BINARY data connection
226 Transfer complete
3697840 bytes sent in 0.52 secs (6.8345 MB/s)
ftp> quote SETENV firmware_version avm
200 SETENV command successful
ftp> quote REBOOT
221 Thank you for using the FTP service on ADAM2
ftp> exit
221 Goodbye.
heini66@heini66-VirtualBox ~/var/remote/var/tmp/x86 $


die box war wohl noch quasi neu.. als ich im vorfeld testen wollte von welcher partition gebootet wird, kam nach

Remote system type is AVM.
quote GETENV linux_fs_start
501 environment variable not set

also müßte ja soweit alles richtig gemacht worden sein, da nur linux_fs_start 0 belegt ist und ich so mit 0,1,6,7 mit ner 6.61 anfangen muß bevor ich übers webinterface auf 6.83 umdaten kann..
 
aus der ferne schwer zu sagen...
env und counter werte hast du dir ja sicherlich vorher gesichert, sodaß du mit hilfe des lesens von http://www.ip-phone-forum.de/showthread.php?t=285810&p=2162540&viewfull=1#post2162540 und YourFritz dir selber nen für deine box passendes image für mtd3&4 daraus basteln kannst um die kiste zur not zurücksetzen zu können...
a: zerleg mal ne 6.83 und versuch es damit...
b: flash das mal auf 11-14 und setzte linux_fs_start 1
 
Leider wurde ab dem "gelöst" das ganze hier nicht verschoben

Wollte mich nur nochmals melden, habe es jetzt per Raspberry (default Installation - ftp nachinstalliert) per ftp und eva versucht weiterhin mit dem selben Ergebnis (MTU ist 1500)

Weiß man eig. wie es jetzt mit einem RecoveryTool für die 6490 aussieht und ob die FWs auch mal offiziell auf dem FTP liegen oder ob der Ordner 6490 weiterhin nur Deko bleibt.
 
der bootloader der neuerdings ausgelieferten kdg 6490 ist übrigends auf 169.254.98.1 umgezogen...
also:
wer eva auf 192.168.178.1 vermisst, sollte 169.254.98.1 mal versuchen.
oder?
selber vorher http://fritz.box/support.lua mal fragen, wo der bootloader ansprechbar ist.
 
@noob_noob:
Du weißt aber schon, daß man diese Adresse auch von außen setzen kann (und da meine ich jetzt nicht den FTP-Server)? Um so eine Adresse zu erhalten, reicht es schon bei einem Windows-System mit APIPA (oder bei einem Linux-System mit Zeroconf, wobei hier Recovery sicherlich unwahrscheinlicher ist) irgendein Recovery-Programm zu starten. Hat der PC zu diesem Zeitpunkt irgendeine beliebige Adresse aus 169.254.98.0/24 (absolut üblich bei APIPA, wobei auch das dritte Tupel noch beliebig innerhalb des Wertebereichs wechseln kann), kommt normalerweise genau so eine Adresse für die FRITZ!Box dabei heraus.
 
hmmm... da ich die boxen!!! ( 2stk, aber vom selben zusender ) nicht orginal ausgepackt sondern nur zur wiederbelebung zugeschickt bekommen hab, könnte das natürlich auch der fall sein...
war bei 2 stk der fall
definitiv hat sich die verpackung geändert.
* kopfkratz *
 
  • Like
Reaktionen: v!king
Ich häng mich mal hier rein, weil ich keinen passenden Thread gefunden habe;
Ich habe eine 6490 als wilhelm.tel-Edition (2000 2704) und einen Kabel-Deutschland-Anschluss. Im Herbst hatte ich die FB mal aktualisiert wie im forum beschrieben, dann bin ich auch auf die Kabel-Deutschland-Aktivierungsseite gekommen. Beim weiteren spielen kam ich dann in den bootloop.
Habe erst jetzt die Zeit gefunden die FB wieder zu resetten (per Linux die md3 und md4 überschrieben) jetzt bootet sie wieder einwandfrei. Leider kriege ich keinen Sync mehr zu KDG. Meldung ist die "auth rejected". firmware_version ist "avm". cert sind new/new, firmware ist 6.87. hoffe das war alles
Hat wer zufällig eine Idee woran es liegen könnte - bin für jeden Hinweis dankbar...

Grüße
Fauli
 
per Linux die md3 und md4 überschrieben
Womit genau, wenn man fragen darf? Wobei auch die Frage nach dem "wie" nicht ganz egal ist ... vor allem dann, wenn die Partition-Namen tatsächlich so verwendet wurden, wie sie dort stehen.
 
ok - habe befürchtet dass Detailfragen kommen ;-)
ich bin nach der im Forum verlinkten Anleitung von triebwerk23.de vorgegangen - die Seite ist grade leider down...

ansonsten noch eine kleine auffälligkeit: Nach dem Reset ist das Wlan-Passwort immer "speedboxspeedbox" ?!

sorry, mehr kriege ich grade zur Ursachenforschung nicht mehr aus meinem Hirn raus

Hier vielleicht noch die Meldungen des Kabel-syncs:
Code:
25.01.18 23:51:47 Auth Reject - Permanent Authorization Failure

25.01.18 23:51:38 MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1

25.01.18 23:51:31 Primary lease failed, IPv4 fallback initiated

25.01.18 23:51:31 DHCP FAILED - Critical field invalid in response

25.01.18 23:51:17 No Ranging Response received - T3 time-out

25.01.18 23:50:17 DHCP REBIND sent - No response for IPv4

25.01.18 23:49:02 DHCP RENEW sent - No response for IPv4

25.01.18 23:40:27 Auth Reject - Permanent Authorization Failure

25.01.18 23:40:22 MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1

01.01.70 01:01:50 Primary lease failed, IPv4 fallback initiated

01.01.70 01:01:50 DHCP FAILED - Critical field invalid in response

01.01.70 01:01:39 No Ranging Response received - T3 time-out
 
Tja, dann wage ich mal die Behauptung, daß da kein "echtes" TFFS-Image in die beiden Partitionen (die heißen dann auch "mtd3" und "mtd4") geschrieben wurde (dann wüßte man als Gefragter sicherlich auch, wo man die Daten für ein solches Image her hatte und wie man es erzeugt hat) und damit einfach gar nichts oder irgendwelcher Blödsinn (bzw. "allgemeine Daten") im Environment steht. Das (also u.a. auch eine falsche "macdsl") funktioniert dann eben auch nicht, wenn man ein neues Zertifikat für irgendeine CM-MAC hat ... man muß die schon auch noch verwenden.

Wie man auf die Idee kommen kann, irgendeiner Anleitung zu folgen, die einem einfach das Überschreiben von MTD3/4 empfiehlt, erschließt sich mir ohnehin nicht ... stand da in den Beiträgen nach demjenigen, der hier diesen Link enthalten soll, keine weitere Warnung, daß man sich das gut und gründlich überlegen sollte? Wo genau ist die denn hier im Forum verlinkt gewesen? Hier sollte eigentlich im Gegenteil immer darauf verwiesen werden, daß das reine Löschen dieser beiden Partitionen durch Schreiben von Daten mit einer Länge 0 so gar keine gute Idee ist, wie hier schon einige andere leidvoll erfahren mußten.

Warum schlägt man dann eigentlich mit seinem Problem doch wieder im IPPF auf, wenn man das nach einer Anleitung aus einer ganz anderen Quelle verbockt hat? Wenn das nach der von @qwertz.asdfgh aus dem anderen Forum schiefgelaufen wäre, könnte ich das wieder verstehen ... aber so wirkt es ein wenig wie der Hilferuf, nachdem man auf die (gutgemeinten) Ratschläge zuvor nicht hören wollte - gerade solche "Unfälle" sind eigentlich immer wieder der Grund gewesen, warum ich gegen irgendwelche Fehler in halbgaren Beschreibungen dann versucht habe anzukämpfen.

Zwar kann man auch jetzt noch versuchen, das irgendwie wieder geradezurücken, aber nicht mit "befürchteten Detailfragen" (selbst wenn das vermutlich scherzhaft gemeint war) und "an mehr kann ich mich nicht erinnern". Das Erinnern kann Dir definitiv niemand abnehmen ... deshalb klärt man das auch vor dem Ändern irgendwelcher Sachen ab, ob man das alles richtig verstanden hat und dabei hättest Du sicherlich auch (ungefragt) den Rat erhalten, Dir einiges zu sichern und das Geschehen zu dokumentieren.
 
Frage, rein aus Interesse: Hat jemand jemals rein aus den Daten des Aufklebers auf der Box (+ Annahmen und Schätzungen) ein Environment rekonstruiert?

Ich denke, genau das wäre hier der letzte Ausweg. Eine Sicherung des Environments bzw. erweiterte Supportdateien scheinen nicht vorhanden zu sein.
 
Ja, geht ... auch die "Zählweise" bei den MAC-Adressen kann man in etwa vom Herstellungsdatum ableiten, afaik. Wobei die anderen Adressen ohnehin egal sind ... nur die "beglaubigte" ist wichtig und die steht (zumindest bei den Retail-Modellen, bei alten Provider-Boxen weiß ich es gar nicht sicher) auf dem Aufkleber. Ansonsten gibt/gab es noch einen Strichcode und einen Aufkleber auf dem Karton, soweit ich weiß.

Auch WLAN-Key und ggf. Start-Kennwort sind aufgedruckt und beim CWMP-Account interessiert das Kennwort nicht wirklich - der sonstige Aufbau beim "Namen" ist ja bekannt und die anderen Angaben (soweit die nicht zu den "Standardwerten" gehören) wie Partitionen und -größen, usw., kann man auch aus anderen Boxen nehmen. Bei den erwähnten Angaben sollte man schon auf die aufgedruckten Angaben zurückgreifen (wenn die nicht aus der Finalisierung ohnehin gesetzt werden, kommt m.W. auch ein wenig auf den Bootloader und seine Version an), weil man spätere Verwirrungen vermeiden kann, falls mal jemand anderes die Box dann auf Werkseinstellungen setzen sollte.

Da man ohnehin ein neues TFFS-Image erzeugt, spielt es dann auch keine Rolle mehr, daß natürlich mit jeder Änderung an "maca", "Serialnumber", "tr069_passphrase" oder "wlan_key" auch die Verschlüsselung von AVM nicht mehr funktioniert und das FRITZ!OS ggf. eigene (verschlüsselte) Einstellungen auch nicht mehr lesen kann.
 
Auf den UM Boxen stehen CWMP-Acount, Wlan-Key, CM-Mac, Artikelnummer und Seriennummer.
 
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.