[Problem] FritzBox 6490 Netzwerk-Setup zurücksetzen

fesc

Mitglied
Mitglied seit
14 Mai 2016
Beiträge
350
Punkte für Reaktionen
92
Punkte
28
Hallo,

mittels einer (zugegeben idiotischen) Netzwerkkonfiguration (router) ich habe es geschafft dass meine 6490/Cable in einer bootschleife haengt.
Adam2 ftp geht noch via 192.168.178.1.

Kennt jemand eine Möglichkeit die Netzwerkparameter (IP, router) von FritzOS via adam2 zurückzusetzen? Wie gesagt, es ist eine 6490, hier scheinen die features des bootloaders ziemlich beschraenkt (get geht gar nicht, put wohl auch nicht).
Ich habe bereits alle bekannten environment-Variablen ausgelesen und versucht mtd3 zu loeschen, ohne Erfolg.

Ich spiele bereits mit dem Gedanken eine UART Verbindung anzulöten, aber das scheint wohl wenig Sinn zu machen.

Ich wäre für jeden Hinweis sehr Dankbar!

Gruss,

Felix.
 
Es gibt dazu schon ein Thema: [thread]282765[/thread]
Ich nehme, dir ist ähnliches passiert, oder?
 
Danke für Hinweis. Ja, genau das gleiche ist mir passiert.
Aus der Diskussion schliesse ich dass die Box wohl im Eimer ist :-(
 
1. Environment und Counter auslesen
2. Eigenes TFFS-Image bauen aus den ausgelesenen Werten und einer passenden "name table"
3. Das eigene Image nach "mtd3" und "mtd4" schreiben, damit sind die Einstellungen Geschichte und die Box sollte wieder starten können, wenn es tatsächlich an falschen Einstellungen liegt.

Wie das Auslesen und der Zusammenbau funktionieren, kann man in meinem GitHub-Repo nachlesen in den Skript-Dateien (Verzeichnisse "eva_tools" und "tffs"), das Vorgehen habe ich m.W. auch vorher irgendwo hier ausführlicher erläutert (wenn auch für ein anderes Modell, aber es klappt bei der 6490 ebenfalls) - Link habe ich nicht zur Hand.

Die aktuelle Name-Table (404B mit "wlan_ssid") habe ich irgendwo in einem Thread zur 7412 mal in einem Beitrag gehabt, ansonsten geht ja auch eine 404A aus irgendeiner anderen FRITZ!Box. Wenn der Kernel eine neuere Tabelle will, erzeugt er die beim ersten Start schon selbst. Für das Auslesen der Namen aus einer (VR9-)Box gibt es auch ein Skript im Repository.
 
Vielen Dank, da werde ich mich mal dranmachen.

Falls es interessiert, die Konfiguration die zu meinem Fehler geführt hat.
Box IP: 192.168.0.2, DHCP aus.

Soweit alles OK, dann router eingetragen: 192.168.0.1

Danach ging der Aerger los. Auf einmal war die box nicht mehr erreichbar. In der ARP table des routers (192.168.0.1) tauchte sie auf einmal als 192.168.0.254 auf!
Dort war auch das WEB login erreichbar, allerdings hing der login nach Eingabe der Zugangsdaten.
Ich habe dann im login-dialog noch probiert einen factory-reset auszufuehren, der allerdings nicht mehr ging da die Box schon mehr als 10min lief.
Also abschalten, einschalten -> tot.

Ich habe deine Vorschlaege bzgl. firmware_info=...,recovered=1 bzw. 2 versucht.
Hilft nix, die variable ist aber nach der boot loop zurückgesetzt.
Gefühlt bewirkt recovered=2 dass nach dem booten des kernels (LED an nach bootloader) es wesentlich länger dauert bis der reset stattfindet.
Normal blink die LED noch ein paar mal, dann reset. Mit recovered=2 hat sie oft noch minutenlang weitergeblinkt. Ich habe aber nicht versucht das wirklich zu verifizieren.

169.254.1.1/2 waren zu keinem Zeitpunkt erreichbar.

Kurze Frage: Auf der Rückseite des PCB ist ein SPI Flash (Macronix 25L1608, schwer zu lesen), in dem wohl der Bootloader liegt. Sind dort auch die Konfigurationsdaten drin, oder hat die Box noch ein eMMC (sonst habe ich nichts flash-artiges gefunden)?

- - - Aktualisiert - - -

Du bist der Held, die Box funktioniert wieder, vielen Dank!!

Es hat etwas Zeit gekostet alle Informationen zu finden (v.a. deine nametable) und die skripte lauffaehig zu bekommen, aber letztendlich lief es.
Da ich scheinbar der erste bin der die Box nach einem falschen router-setup wieder zum leben bekam werde ich bei Gelegenheit alles mal zusammenschreiben ... aber Heute nicht mehr.

Beste Grüße,

Felix.
 
Die Erreichbarkeit der Box unter der Adresse .254 ist Absicht von AVM ... wenn ich das richtig getestet habe, kriegt der Atom-Kern immer die letzte Adresse im Segment und das ist bei einer 24er-Maske dann eben die .254 - das ist also noch nichts Komisches.

Erst wenn dann die Box auf 192.168.0.2 nicht reagieren will, dann wird es merkwürdig. Muß ich bei Gelegenheit mal nachstellen ...

Du bist auch nicht ganz der Erste, der dieses Vorgehen anwendet - der andere Thread ist ja schon etwas älter und der war Teil des Anstoßes, daß ich die Skript-Dateien überhaupt veröffentlicht habe. Das soll Dich aber keineswegs von Deinem Vorhaben abhalten, das mal ausgiebig/ausführlich zu beschreiben ... ganz im Gegenteil, es soll bestätigen, daß es keine "Eintagsfliege" ist und daß es tatsächlich jeder mit entsprechenden Grundkenntnissen anwenden kann.

Was mich allerdings daran tatsächlich interessiert, ist der Punkt "Skripte lauffähig machen" ... da würde ich gerne wissen wollen, was nicht auf Anhieb aus einem GitHub-Checkout funktionieren wollte.

Ach ja, die Konfigurationsdaten liegen bei der 6490 im SPI ... würde ich trotzdem nicht unbedingt auslöten (kommt für viele ohnehin nicht in Betracht, weil erstens das notwendige SMD-Werkzeug fehlt und zweitens die Box i.d.R. dem Provider gehört).
 
Zuletzt bearbeitet:
Also, bevor ich alles wieder vergesse, hier mein "user guide" (aus dem Kopf, ich wollte das nicht nochmal machen). Evtl ist das eine andere zu umstaendlich, aber so hat es bei mir funktioniert.

0. git clone https://github.com/PeterPawn/YourFritz

1. Wichtig ist die richtige variante von netcat. Es gibt eine "openbsd" und "traditional", die skripte benoetigen "openbsd" (-d flag muss unterstuetzt sein). Unter debian bekommt man die mit "apt install netcat-openbsd". Pruefen (mit nc -h) ob das -d flag unterstützt ist.

2. Die skripte setzen vorraus dass /bin/sh eine bash ist (bei Debian ist das z.B. eine dash). Also alle skript header in eva_tools und tffs wenn noetig auf #!/bin/bash aendern.
Auserdem sollte man sicher gehen dass "." in der PATH variable ist (PATH=$PATH:. oder set path=($path .) ).

2.5 Box booten und in eva anhalten (bei blinken "ftp 192.168.178.1, adam2/adam2 einloggen, mit quit wieder raus).

3. Environment und counter lesen mit
cd eva_tools
eva_get_environment env 192.168.178.1 > /tmp/env.txt
eva_get_environment count 192.168.178.1 > /tmp/count.txt

4. Obsolet, war : Files in richtiges format fuer die tffs tools umwandeln:
sed -i -e 's/\([^ ]*\)[ ]*\(.*\)/name=\1 value="\2"/' /tmp/env.txt
sed -i -e 's/\([^ ]*\)[ ]*\(.*\)/name=\1 value="\2"/' /tmp/count.txt

5. Obsolet, war: Die Werte in count.txt die von der 6490 kommen mag das tffs skript nicht. Also ggf. count.txt editieren und alles von "u" auf "0" setzen.
Anm: diese Zeile gibt einen Fehler da $value nicht gesetzt ist:
eval $name=$(( -1 << $value ))

6. Obsolet, nametable ist im repository. War: "/tmp/nametable" file erzeugen. Die Daten aus dem anderen Thread haben bei mir fuer die 6490 funktioniert:
510 @L
431 AutoMDIX
259 DMC
256 HWRevision
260 HWSubRevision
257 ProductID
258 SerialNumber
425 annex
385 autoload
512 bb0
513 bb1
514 bb2
515 bb3
516 bb4
517 bb5
518 bb6
519 bb7
520 bb8
521 bb9
386 bootloaderVersion
387 bootserport
428 bluetooth_key
388 bluetooth
424 country
389 cpufrequency
417 crash
390 firstfreeaddress
430 firmware_info
422 firmware_version
391 flashsize
441 jffs2_size
416 kernel_args
415 kernel_args1
423 language
408 linux_fs_start
392 maca
393 macb
394 macwlan
406 macwlan2
395 macdsl
396 memsize
397 modetty0
398 modetty1
452 modulemem
432 mtd0
433 mtd1
434 mtd2
435 mtd3
436 mtd4
437 mtd5
438 mtd6
439 mtd7
442 mtd8
443 mtd9
444 mtd10
445 mtd11
446 mtd12
447 mtd13
454 mtd14
455 mtd15
399 my_ipaddress
453 plc_dak_nmk
400 prompt
451 provider
426 ptest
401 reserved
402 req_fullrate_freq
403 sysfrequency
449 tr069_passphrase
448 tr069_serial
509 urlader-version
404 usb_board_mac
418 usb_device_id
420 usb_device_name
421 usb_manufacturer_name
419 usb_revision_id
405 usb_rndis_mac
450 webgui_pass
440 wlan_cal
427 wlan_key
456 wlan_ssid

7. tffs image erzeugen:
cd tffs
build_tffs_image tffs_name_table /tmp/env.txt /tmp/count.txt > /tmp/mtd.img

8. Image auf mtd3 und mtd4 schreiben. Ich nehme an hier ist es extrem wichtig wirklich mtd3/4 zu tippen!
cd eva_tools
eva_store_tffs mtd3 /tmp/mtd.img
eva_store_tffs mtd4 /tmp/mtd.img

9 Box resetten, sollte wieder laufen.

10. Die daten aus /tmp fuer spaetere verwendung sichern.

- - - Aktualisiert - - -

Ich hatte uebrigens einen interessanten wert in der environment:

name=crash value="[0]0,529fbc50,48217088[1]4821614c,529fbc7c,529fbc60[2]352e2a9,54bc6f00,1[3]48563a44,60,0"

Ist das evtl. irgendwie relevant?
 
Zuletzt bearbeitet:
  • Like
Reaktionen: Simitar
2. Die skripte setzen vorraus dass /bin/sh eine bash ist, von was man eigentlich nicht ausgehen sollte (bei debian ist das z.B. eine dash). Wenn man bash will sollte man auch /bin/bash schreiben. Also alle skript header in eva_tools und tffs auf #!/bin/bash aendern.
Ok, ist ein Standpunkt, den ich nicht teile ... außerdem hoffe ich, daß die Skripte tatsächlich auch mit der "ash" aus der Busybox zufrieden sind. Wenn ich wirklich die "bash" vorausgesetzt hätte, hätte ich einiges wesentlich einfacher machen können (z.B. /dev/tcp verwenden) - es ist Absicht, daß das nicht der Fall ist und somit die Dateien auch auf einer STB oder einem RasPi o.ä. verwendet werden können. Es gibt wirklich nur sehr wenige Systeme, welche die eingeschränkte Syntax nicht verstehen.

Klar, man kann auch "tcsh" oder "ksh" verwenden (wenn wir mal den "Debian-Sonderfall" außen vorlassen, daß die "dash" am Ende "nur" POSIX-kompatibel ist und selbst die "ash" einige (sinnvolle) Erweiterungen ggü. POSIX bietet, tut mir ja leid für die Benutzer einer Debian-basierten Distribution, aber das Linux-Universum besteht auch noch aus anderen Komponenten und die kennen die "dash" am Ende meist gar nicht), aber es zieht sich (hoffentlich) wie ein roter Faden durch das gesamte "YourFritz"-Repository, daß die Dateien auch jede Menge zusätzlichen Aufwands in Kauf nehmen, damit sie auch direkt auf einer FRITZ!Box laufen können (zumindest mit geringem Anpassungsaufwand) und da ist die aktuelle Shell eben das "ash"-Applet.

Die Konvention ist es eigentlich auch, daß der /bin/sh-Link auf die aktuell verwendete Shell zeigt. Die "ash" ist (in Grenzen, wenn man aufwändige Konstrukte vermeidet) kompatibel mit der "bash" und die Benutzer einer anderen Shell kennen das Problem in aller Regel bereits, denn "bash" ist nun mal der "Quasi-Standard" und viele andere Skript-Dateien laufen mit anderen Shell-Dialekten ja auch nicht. Und als Debian-Benutzer sollte man auch an diverse Inkompatibilitäten gewöhnt sein ... das gilt auch für den Unterschied der Pakete "netcat-traditional" und "netcat-openbsd".

Ich hatte zwar mal die Angewohnheit, in solchen Skript-Dateien die Existenz aller benötigten Programme am Beginn zu testen (es gibt noch Rudimente in einigen Dateien im Repository bzw. auf yourfritz.de und schon der unterschiedliche Ablageort einiger Dateien (/bin vs. /usr/bin) macht es fast unmöglich, da Dateien für sämtliche Geschmacksrichtungen von Linux passend zu machen), aber das macht das "Mitlesen" nicht einfacher und so bin ich (solange es kein "load & run"-Skript ist) davon wieder weg.

Hier sollen die Verwender ja gerade vorher nachsehen, was da passiert und dann fällt ein "nc", welche sich nicht von seiner Standardeingabe trennen mag (also den "-d"-Parameter nicht kennt, das geht dem Busybox-Applet genauso) recht schnell auf. Hier macht es sich aber bemerkbar, daß ich tatsächlich meist als "Dokumentation" irgendeinen Thread hier verwende und solche Voraussetzungen entweder im Text im Header der Datei beschreibe oder sogar "nur" in dem betreffenden Beitrag hier ... auf der anderen Seite ist es auch nervig, jede Kleinigkeit bis ins Detail zu beschreiben (für Leser und Autoren).

fesc schrieb:
Auserdem sollte man sicher gehen dass "." in der PATH variable ist (PATH=$PATH:. oder set path=($path .) ).
Ich hoffe mal, daß ich das an der anderen Stelle (die meinte ich als ich vom "vergessenen Link" oben schrieb, war m.E. KingTutt oder Riverhopper geantwortet und da ging es um die Verwendung von "provider additive"-Sicherungen) angemerkt hatte ... aber ich sehe eigentlich zur Zeit nur in der "Zusammenfassung" mehrerer Skript-Dateien in "build_tffs_image" eine Stelle, wo das relevant wäre (die anderen Dateien sollten event. mit "./scriptname" aufgerufen werden). Die andere Klippe (die "yourfritz_helpers"-Datei muß im aktuellen Verzeichnis liegen) ist noch direkt in der GitHub-Ansicht zu sehen, denn das war der Kommentar des letzten Commits dort.

Aber ich werde darüber nachdenken, ob ich diese Stelle nicht wirklich ändere ... mal sehen - ich sehe Vor- und Nachteile in der Verwendung von "./scriptname" (vor den letzten Commit stand da noch "bin/scriptname" drin, weil die anderen Skript-Dateien bei mir tatsächlich in einer Hierarchie an anderer Stelle lagern) und da keine Linux-Installation 1:1 wie die andere aussieht (wir reden hier ja nicht von der Box selbst), ist das etwas zuviel Aufwand (der auch nicht über "autoconf" o.ä. abgefangen werden kann/soll, denn das gibt es auf der Box dann wieder nicht), es wirklich so umzusetzen, daß es auf jedem denkbaren System sofort verwendbar ist.

fesc schrieb:
2.5 Box booten und in eva anhalten (bei blinken "ftp 192.168.178.1, adam2/adam2 einloggen, mit quit wieder raus).
Man kann auch "eva_discover" aus "eva_tools" verwenden (gibt es inzwischen auch in einer PowerShell-Variante für die Windows-Benutzer), dann erspart man sich ggf. das Umkonfigurieren der lokalen Netzwerkeinstellungen auf dem verwendeten Gerät, weil man dem Bootloader die Adresse vorgeben kann.

fesc schrieb:
4. Files in richtiges format fuer die tffs tools umwandeln:
sed -i -e 's/\([^ ]*\)[ ]*\(.*\)/name=\1 value="\2"/' /tmp/env.txt
sed -i -e 's/\([^ ]*\)[ ]*\(.*\)/name=\1 value="\2"/' /tmp/count.txt
Diesen Schritt verstehe ich nicht ... nach meiner Ansicht sollten die Dateien "environment_to_tffs" und "counter_to_tffs" aus dem Verzeichnis "tffs" genau diese Aufgabe übernehmen.

fesc schrieb:
5. Die Werte in count.txt die von der 6490 kommen mag das tffs skript nicht. Also ggf. count.txt editieren und alles von "u" auf "0" setzen.
Anm: diese Zeile gibt einen Fehler da $value nicht gesetzt ist:
eval $name=$(( -1 << $value ))
Ok, das ist mir auch aufgefallen, daher enthält "counter_to_tffs" dafür auch eine "Spezialbehandlung".

fesc schrieb:
8. Image auf mtd3 und mtd4 schreiben. Ich nehme an hier ist es extrem wichtig wirklich mtd3/4 zu tippen!
In der Tat ... die 6490 mag die Namen nur in kleiner Schreibweise, bei Großschreibung stellt sie sich blöd.

fesc schrieb:
name=crash value="[0]0,529fbc50,48217088[1]4821614c,529fbc7c,529fbc60[2]352e2a9,54bc6f00,1[3]48563a44,60,0"
Das ist der Punkt des letzten Absturz mit "kernel panic" ... das System enthält extra recht umfangreichen Code, der (immer unter der Annahme, daß da die Strukturen noch stimmen) in so einem Falle entweder einen langen Stack-Dump erzeugt und in einem TFFS-Node sichert oder nur die wichtigsten Registerinhalte in der Variablen "crash" ablegt. Zumindest sieht man - wenn man mittels UNSETENV den Wert löscht -, ob er älteren Datums ist oder tatsächlich bei jedem Startversuch neu gesetzt wird. Sinnvoll verwenden kann man ihn nur mit einem Debugger oder den Linker-Protokollen des verwendeten Kernels.
 
Ok, ist ein Standpunkt, den ich nicht teile ... außerdem hoffe ich, daß die Skripte tatsächlich auch mit der "ash" aus der Busybox zufrieden sind. Wenn ich wirklich die "bash" vorausgesetzt hätte, hätte ich einiges wesentlich einfacher machen können (z.B. /dev/tcp verwenden) - es ist Absicht, daß das nicht der Fall ist und somit die Dateien auch auf einer STB oder einem RasPi o.ä. verwendet werden können. Es gibt wirklich nur sehr wenige Systeme, welche die eingeschränkte Syntax nicht verstehen.
Ok, akzeptiert, ich glaube da kann mal lange diskutieren :). Meine Philosophie: Bash ist tatsaechlich ein standard, deshalb erwarte ich auch dass es /bin/bash gibt. Und wenn nicht, dann bekommt man wenigstens eine ordentliche Fehlermeldung anstatt von obskuren skript-Fehlern. Das /bin/sh immer alle bash-Features hat ist eben nicht der Fall, und wenn man portabel sein will muss man halt (leider) damit rechnen. An BusyBox/ash hate ich jetzt allerdings nicht gedacht.


Man kann auch "eva_discover" aus "eva_tools" verwenden (gibt es inzwischen auch in einer PowerShell-Variante für die Windows-Benutzer), dann erspart man sich ggf. das Umkonfigurieren der lokalen Netzwerkeinstellungen auf dem verwendeten Gerät, weil man dem Bootloader die Adresse vorgeben kann.
Das hatte ich gemacht, aber das tool ist etwas zu intelligent (und ich zu faul zum lesen). Es nimmt per default das netz von eth0 und konfiguriert daraufhin die Box um. Bei mir war es aber nicht eth0 sondern eth0:1 so dass ich erst mal auf die Nase gefallen bin. Vielleicht sollte das skript zwingend vorraussetzen dass man das interface angibt bevor man sich aus Versehen die Box verkonfiguriert.

Diesen Schritt verstehe ich nicht ... nach meiner Ansicht sollten die Dateien "environment_to_tffs" und "counter_to_tffs" aus dem Verzeichnis "tffs" genau diese Aufgabe übernehmen.
Stimmt, habe ich jetzt auch gesehen. Allerdings hat deine sed expression meinen file-inhalt nicht erkannt und die daten 1:1 durchgereicht (wegen dem "\r\+$" suffix am ende ..). Deshalb dachte ich dass ich die Daten vorher konvertieren muss.

Ok, das ist mir auch aufgefallen, daher enthält "counter_to_tffs" dafür auch eine "Spezialbehandlung".
Die hat nicht zugeschlagen, wohl auch wegen der sed expression.

Ich habe dein skript geaendert und nehme diese expression, damit geht es ohne schritte 4 und 5:
sed -e "s|^\([^ ]*\)[ ]*\(.*\)|name=\"\1\" value=\"\2\"|" >$cntfile
 
Bei mir kamen (über das "nc"-Kommando) die Zeilen mit Windows-Kodierung (also \r\n, ich weiß allerdings nicht mehr, ob bei 6490 oder 7490 ... daher ohnehin erst mal die erzeugte Image-Datei prüfen) und da werden dann die "\r" am Ende bis in das erzeugte TFFS-Image durchgereicht.

Hier macht es sicherlich einen Unterschied, ob man die FTP-Übertragung binär oder als Text ausführt ... ich will gar nicht beschwören, wie ich das gemacht habe und müßte auch erst nachsehen, was da welches Modell als Standard-Einstellung verwendet bzw. sogar, was das zuständige RFC für FTP als Standard vorschreibt und ich bin ohne Nachsehen nicht einmal sicher, ob ich da tatsächlich ein "MODE I" vor der Übertragung in den Skript-Dateien habe (muß ich zu meiner Schande gestehen). Aber ich verstehe ohnehin nicht, warum ich da fälschlicherweise das Plus anstelle des Fragezeichens stehen habe ... das ist halt der Unterschied in den "quantifiers" - wird nachher noch korrigiert.

Bei "eva_discover" fehlt tatsächlich noch ein guter Teil der Logik, der bei mehreren Netzwerkschnittstellen die passende selektieren soll ... wenn ich mal viel Zeit habe - geht halt auch so, vielleicht ist es aber wirklich einfacher, da die Standardwerte zu entfernen.
 
Ich hatte das selbe Problem mit meiner 6490. Unter Firmware 6.26 etwas an der Routingtabelle geändert und dann ständiges neu booten.
Dank Euer beider Hilfe konnte ich es wie beschrieben reparieren. VIELEN DANK!!!!

st
 
Guten Tag,

meine hängt auch in einer Boot-Schleife und es ist kein Zugriff via FTP möglich. Was kann ich machen?

Danke
 
meine hängt auch in einer Boot-Schleife und es ist kein Zugriff via FTP möglich.

Wenn die Box in einer Boot-Schleife hängt ist ein Zugriff per FTP auf den Bootloader weiterhin möglich. Also entweder eine von deinen beiden Feststellungen ist nicht korrekt oder du hast kein geeignetes Vorgehen für den Zugriff per FTP auf den Bootloader verwendet (Edit: Die zweite Variante ist hier im IPPF sozusagen der "Kassenschlager" von daher liegt der Verdacht sehr nahe).
 
Zuletzt bearbeitet:
Wenn die Box in einer Boot-Schleife hängt ist ein Zugriff per FTP auf den Bootloader weiterhin möglich. Also entweder eine von deinen beiden Feststellungen ist nicht korrekt oder du hast kein geeignetes Vorgehen für den Zugriff per FTP auf den Bootloader verwendet (Edit: Die zweite Variante ist hier im IPPF sozusagen der "Kassenschlager" von daher liegt der Verdacht sehr nahe).

Verstehe ich nicht ganz. Was ist denn die zweite Variante?
 
Was wäre denn das geeignete Vorgehen?
 
Was wäre denn das geeignete Vorgehen?

gestern war Nikolaus, leider hatte er nur Geschenke für meine Kinder dabei;-)
auch fehlt mir die Glauskugel, daher tue ich mich Wahrsagen schwer;

wie wäre es denn wenn Du uns mitteilst was Du vorher getan hast, vor die FB6490 in Bootloop gelaufen ist;
ich denke dann erhältest Du auch gezielt Hinweise/Lösungsvorschläge.
 
Hallo, ich war vielleicht ein Bisschen zu blöd oder zu voreilig. Hatte versucht mittels FTP meine gebrandete Box von KDG auf AVM umzustellen.
 
Hatte versucht mittels FTP meine gebrandete Box von KDG auf AVM umzustellen.

Hallo Bubu1980,
dann bist Du aber in falschem Thread gelandet;

richtig wäre: http://www.ip-phone-forum.de/showthread.php?t=274859
Hier gibt es auch Lösungsvorschläge, wie man die Kiste aus Bootloop herausbekommt.

Gruß
Pokemon20021

EDIT:
Hinweis: sollte es bei Deiner FB6490 um eine HomeBox3 von VKD mit FW >= 06.31 handeln,
so hilft oft schon der Befehl "quote SETENV firmware_version kdg" in der EVA-Konsole hilfreich sein.
 
Zuletzt bearbeitet:
So verstanden. Melde mich dann in den anderen Thread ab! Danke!

Was ist eine EVA-Konsole?
 
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.