Schlechte Idee ... die 6490 ist für solche Verwendung das falsche Modell.
 
  • Like
Reaktionen: stoney
Danke, dachte ich mir schon .... werde mir dann die 3490 zu legen ... würde zwar gerne auch eine 75XX nehmen wegen dem Mesh .... aber die sind wohl noch zu teuer ..... und werde kaum mit defekten Modem angeboten ...
 
BLÖDE Frage .. was passiert eigentlich wenn ich anstatt der Kernel Image und filesystem.image sowie im x86 Bereich die 6590 Firmware zerlege und die Dateien manuell über den bootloader mit ftp flashe anstatt die 6490 files?
Rein von der Funktion sowie Prozessor und allem ist doch soweit ich das aus der Hardwaretabelle gesehen habe alles identisch oder irre mich da? Könnte das funktionieren?
 
BLÖDE Frage .. was passiert eigentlich (...)?
Ich habe zwar nicht alle Details Deiner Idee verstanden, aber die Frage lässt sich trotzdem mit einiger Sicherheit mit: "Dann hast Du einen Briefbeschwerer." beantworten. Mit anderen Worten - tu's nicht.
 
Ich denke nicht, denn der bootloader wird ja gar nicht angegriffen und könnte dann trotzdem noch nach einem reboot angesprochen werden richtig @PeterPawn ? Oder liege ich da so falsch?
 
Das geht an diversen Stellen schon schief, weil AVM in der Firmware mehrfach z.B. die HWRevision abfragt und noch so manchen anderen Wert.

Was soll der Quatsch eigentlich bewirken?

Die Boxen unterscheiden sich genau beim WLAN und es wird mit ziemlicher Sicherheit auch für die 6490 irgendwann mal (auch wenn das ggf. noch länger dauern könnte) eine aktuelle Firmware (wahrscheinlich eine Version 7 und wahrscheinlich mit Mesh-Support - zumindest als Master, weil die 6490 ja eigentlich nicht zum "IP-Client" taugt (zumindest bisher) ... ich lasse mich aber überraschen, was AVM sich da einfallen läßt) geben.

Ich mache ja auch viel Unfug mit den Boxen ... aber wieso man eine 6590-Firmware als Alien auf einer 6490 installieren sollte, erschließt sich mir nun überhaupt nicht mehr.
 
weil ich eine alte 6490 hier übrig habe.. nur spasseshalber wäre das ein test gewesen.. mx wlan ist anders ja das hab ich grad auch bemerkt.. Mesh kann ich in der Labor auch haben....
 
Hi,

ich habe mir auf eBay eine gebrauchte Fritzbox 6490 gekauft, die der Vorbesitzer schon versucht hat für Pyür zu aktivieren bzw freizuschalten und ich war eigentlich so optimistisch und dachte ich bekomme die wieder hin.

Ich habe jetzt schon den ganzen Abend versucht die beiden Partitionen zu flashen linux_fs_start 0 und linux_fs_start 1 und mit dem firmware_version Tag zu spielen, am Anfang stand es auf kdg habe es auch mal auf avm gesetzt. Habe über die Anleitung ein FritzOS 6.87 und 7.10 auf mtd0/1 und mtd6/7 installiert, an die reservierten mtd11-14 noch nicht herangetraut.

Das Auslesen über eva_get_environment liefert leider auch nur leere Files.

Was ich auch angestellt habe, die Power/Cable LED der Box blickt nur und alle ca. 150 - 160 Sec rebootet sie.

Jemand ne Idee, ob bzw. wie die Box noch zu retten ist?

PS: Ach ja, was auch nicht geklappt hat, war das Backup:
retr ENV
retr CONFIG
Da hat der FTP Client immer gesagt, invalid command.
 
Da hat der FTP Client immer gesagt, invalid command.
Dann war das wohl der falsche FTP-Server oder vielleicht doch auch nur das falsch verstandene und falsch verwendete Kommando.

Der FTP-Server in EVA geht zwar manchmal gar nicht (zumindest bei einigen Bootloader-Versionen), wenn das TFFS einfach nur zerschossen wurde ... aber daß der am Ende behauptet, er kenne die Kommandos "RETR env" und "RETR count" (meinetwegen auch "RETR config", wobei das ja nicht wirklich gebraucht würde, um ein TFFS-Image zu bauen) gar nicht, wäre eher neu.

Nun stellt sich natürlich die Frage, ob das schon bei der Eingabe im FTP-Dialog so falsch verwendet wurde, wie es in #108 steht (oder ob nur die "Beschreibung" hier im Thread die falsche ist) ... welche (dann offensichtlich falsche) Anleitung/Erklärung behauptet denn, daß man auf die korrekte Schreibweise der Kommandos keine Rücksicht nehmen müsse?
Code:
vidar:/home/GitHub/YourFritz/eva_tools $ ./eva_discover INTERFACE=vlan1 FROM=192.168.178.2 TO=192.168.178.1 BLIP=1;nc 192.168.178.1 21
EVA_FOUND=1
EVA_IP=192.168.178.1
220 ADAM2 FTP Server ready
USER adam2
331 Password required for adam2
PASS adam2
230 User adam2 successfully logged in
SYST
215 AVM EVA Version 1.3125 0x0 0x36409
MEDIA FLSH
200 Media set to MEDIA_FLASH
retr ENV
502 Command not implemented
RETR env
425 can't open data connection
QUIT
221 Thank you for using the FTP service on ADAM2
221 Goodbye.
vidar:/home/GitHub/YourFritz/eva_tools $
Ich habe auf die tatsächliche Übertragung von Daten verzichtet, weil der Unterschied zwischen den beiden eingegebenen "RETR"-Versuchen hoffentlich augenfällig ist, auch im Hinblick auf die Antworten des Servers.

Wenn es aber schon an solchen "Kleinigkeiten" scheitert, würde ich (egal, wie das jetzt wieder ankommen mag) erst mal die Empfehlung mit dem "auf den Hosenboden setzen" aussprechen ... nach einigem Lesen kommen einem dann auch wieder passende Ideen, woran es ansonsten noch liegen könnte.

Da bei der Verwendung von "eva_get_environment" die Kommandos ja normalerweise in der korrekten Schreibweise abgesetzt werden, wird die Box wohl wirklich keine Daten mehr liefern ... wobei auch hier der Blick in die Log-Datei für das Skript (die heißt dann "eva_get_environment_session.log") ja eigentlich nicht schaden würde. Ob jetzt der FTP-Dialog nicht korrekt abläuft oder die Datenverbindung nicht richtig geöffnet wird (und dann irgendwann nur ein Timeout auftritt) oder ob da tatsächlich 0 Byte Daten (in kurzer Zeit) gesendet werden oder ob gar nur das Schreiben der Ausgabedaten (wenn da eine Umleitung beim Aufruf erfolgte, was bei der Idee mit der Weiterverarbeitung der Daten ja naheliegend wäre) irgendwie schiefgeht, MUSS man ja nicht unbedingt mit Raten ermitteln, wenn man es auch nachlesen kann ... die "Trefferrate" ist einfach viel höher dabei.

Müßte ich raten (und eigentlich muß man das ja, angesichts der fehlenden Infos), würde ich auf irgendwelche Versuche des Vorgängers tippen, die Einstellungen in MTD3 und MTD4 durch den - immer wieder gerne genommenen - Unfug mit dem Speichern einer leeren Datei in diesen Partitionen zu löschen (dieser Quatsch ist offenbar auch nicht auszurotten - aber selbst schuld, wer auf so etwas dann hereinfällt). Das führt dann nicht bei allen Bootloader-Versionen zu dem Problem, daß der FTP-Server der Box gar nicht mehr erreichbar ist, weil die ARP-Pakete Unsinn enthalten (das altbekannte "0x00, "-Problem) ... bei manchen gibt das dann auch nur ein "generisches Environment", das sich zum Teil aus den "Geburtsdaten" der Box speist (daher könnte auch in diesem Zustand noch das "kdg" kommen) und zum Teil (bei noch aussichtsloserer Lage für den Bootloader) aus "noch generischeren" Angaben, die praktisch in jedem EVA-Bootloader (quer durch alle Modelle) dieselben sind (da steht dann eine "maca" von "00:04:0E:FF:FF:01").

Wobei die Box auch mit dem generischen Environment eigentlich starten müßte, solange das "Branding" zur installierten Firmware paßt ... da tippe ich jetzt mal (reiner Erfahrungswert, nicht persönlich gemeint, aber auch auf dem oben Stehenden mit den falschen FTP-Kommandos basierend) auf weitere (hoffentlich unbewußte) Fehler in der Anwendung der (passenden) Tools - wobei das ja eigentlich auch alles mit irgendwelchen Fehlermeldungen verbunden sein müßte, die man als jemand, der von sich denkt: "Ich kriege das schon hin." ja wohl eher nicht einfach nur ignorieren würde, oder?

Insofern habe ich zwar einige solcher "Vermutungen", aber irgendein Fakt oder irgendeine Überlegung paßt da jeweils nicht ... damit wäre es an Dir, da "Licht ins Dunkel" zu bringen, indem Du einfach deutlich ausführlicher beschreibst, was Du eigentlich machst und die Ergebnisse vielleicht nicht nur in Prosa, sondern in Protokolle kleidest.

Dann sollte man eine FRITZ!Box, die offenbar noch reagiert und erreichbar ist im Bootloader, auch wieder zum Leben erwecken können; ja, selbst bei den Modellen mit dem "0x00, "-Fehler ist das machbar (habe ich selbst auch schon mehrfach ausgeführt). Ob die Box dann tatsächlich das notwendige neue Zertifikat hat, um mitsamt dem CM genutzt zu werden, steht auf einem ganz anderen Blatt.
 
Ich habe auf die tatsächliche Übertragung von Daten verzichtet, weil der Unterschied zwischen den beiden eingegebenen "RETR"-Versuchen hoffentlich augenfällig ist, auch im Hinblick auf die Antworten des Servers.

Wenn es aber schon an solchen "Kleinigkeiten" scheitert, würde ich (egal, wie das jetzt wieder ankommen mag) erst mal die Empfehlung mit dem "auf den Hosenboden setzen" aussprechen ... nach einigem Lesen kommen einem dann auch wieder passende Ideen, woran es ansonsten noch liegen könnte.

Hi,

vielen Dank für deine Antwort, ok, ich sitze auf dem Hosenboden. Bei den Kleinigkeiten war ich mir tatsächlich nicht ganz sicher, da ich es mal so und mal so gefunden habe und es von hier hatte.

Also gut, eva_discover und eva_get_environment funktionieren jetzt. Vermutlich war mein Setup auch nicht ganz ideal, es entweder unter der angebissenen Ananas oder im Ubuntu Subsystem unter Windows zu probieren. Mit einer Linux VM hat es jetzt funktioniert, die Daten auszulesen.

Das Branding habe ich wieder auf avm geändert, damit es zur Firmware passt, aber die Box kommt trotzdem nicht hoch.

Ich werde jetzt mal versuchen die Box nochmal unter Linux zu flashen und wenn das nichts bringt, dann werde ich mal die tffs Geschichte anschauen?
 
OK, das wußte ich tatsächlich nicht, daß da im Freetz-Repo eine Datei mit diesen (durchaus falschen, wenn man sie zum "Abtippen" verwendet - siehe mein Versuch in #109) Infos vorhanden ist.

Der Pfad, den Du dorthin verlinkt hast, geht zwar über "meinen" Fork von Freetz und auch über den richtigen Branch, die Datei stammt aber direkt aus dem Freetz-Repo: https://github.com/Freetz/freetz/blob/master/howtos/en/6490_info_sheet.txt und wurde von mir nur beim Klonen bzw. Aktualisieren unbewußt mitkopiert.

Nach meinem Verständnis (beim Lesen jetzt) ist das nur ein Notizzettel, wie das "generell" funktioniert und keine Anleitung, die den Anspruch erhebt, syntaktisch korrekte Kommandos darzustellen und den Leser zu irgendeinem bestimmten Ziel zu leiten. Aber ich werde mal (mit diesem "Link": @f666 @er13) die Verantwortlichen darauf aufmerksam machen ... ggf. sehen sie auch die Notwendigkeit, da Änderungen/Ergänzungen/Klarstellungen anzubringen.

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

Wenn sich das Environment auslesen läßt und die Daten darin vollständig sind (Beispiele gibt es in anderen Threads genug), dann sollte die Box auch starten - wobei schon die Länge so eines Boot-Loops eine Idee davon liefern kann, wo das Problem auftritt, wenn man es z.B. mit einer funktionierenden 6490 (und der dort vorhandenen Ausgabe von "dmesg" in der Support-Datei) vergleicht.

Abgesehen davon will ich die Aufforderung noch einmal erneuern, bei Problemen (spätestens dann, denn auch bei "funktioniert jetzt" enthalten die Angaben manchmal noch Infos, mit denen andere etwas anfangen können - ich hätte z.B. anhand des gezeigten Environments (meinetwegen auch "anonymisiert") schon mal abschätzen/raten können, ob das komplett ist oder aus den Finalisierungsdaten neu erstellt wurde vom Bootloader) immer die Protokolle zu zeigen - spätestens beim Zusammenbau des TFFS-Images WILL ich das sehen (wenn ich weiterhin helfen soll), weil die Fehlernachrichten in diesen Skript-Dateien eher unterentwickelt sind (das war eigentlich nie für den ständigen Gebrauch gedacht, sondern immer nur zum Zeigen der Prinzipien).
 
Abgesehen davon will ich die Aufforderung noch einmal erneuern, bei Problemen (spätestens dann, denn auch bei "funktioniert jetzt" enthalten die Angaben manchmal noch Infos, mit denen andere etwas anfangen können - ich hätte z.B. anhand des gezeigten Environments (meinetwegen auch "anonymisiert") schon mal abschätzen/raten können, ob das komplett ist oder aus den Finalisierungsdaten neu erstellt wurde vom Bootloader) immer die Protokolle zu zeigen - spätestens beim Zusammenbau des TFFS-Images WILL ich das sehen (wenn ich weiterhin helfen soll), weil die Fehlernachrichten in diesen Skript-Dateien eher unterentwickelt sind (das war eigentlich nie für den ständigen Gebrauch gedacht, sondern immer nur zum Zeigen der Prinzipien).

Klar, gerne.
cat count.txt
reboot_major u
reboot_minor u
run_hours u
run_days u
run_mounths u
run_years u

cat env.txt
HWRevision 213
HWSubRevision 4
ProductID Fritz_Box_HW213a
SerialNumber 0000000000000000
annex Kabel
autoload yes
bootloaderVersion 1.3167
bootserport tty0
cpufrequency 1200000000
crash [0]0,0,0[1]0,0,0[2]0,0,0[3]0,0,0
firstfreeaddress 0x00b20000
firmware_info 141.06.87
firmware_version kdg
flashsize nor_size=0MB sflash_size=2MB nand_size=2048MB
language de
linux_fs_start 0
maca E0:28:6D:xx:xx:xx
macb E0:28:6D:xx:xx:xx
macwlan E0:28:6D:xx:xx:xx
macwlan2 E0:28:6D:xx:xx:xx
macdsl E0:28:6D:xx:xx:xx
memsize 0x10000000
modetty0 38400,n,8,1,hw
modetty1 38400,n,8,1,hw
modulemem 947058
mtd0 0x0,0x4000000
mtd1 0x4000000,0x4800000
mtd2 0xa0000,0xc0000
mtd3 0xc0000,0x100000
mtd4 0x100000,0x140000
mtd5 0x140000,0x1e0000
mtd6 0x4800000,0x8800000
mtd7 0x8800000,0x9000000
mtd8 0x0,0x80000
mtd9 0x80000,0x90000
mtd10 0x90000,0xa0000
mtd11 0x9000000,0xd000000
mtd12 0xd000000,0xd800000
mtd13 0xd800000,0x11800000
mtd14 0x11800000,0x12000000
my_ipaddress 192.168.178.1
prompt Eva_AVM
req_fullrate_freq 100000000
sysfrequency 100000000
tr069_passphrase 1xpRW2xxxxx
tr069_serial 00040E-E0286Dxxxxxx
urlader-version 4167
usb_board_mac E0:28:6D:xx:xx:xx
usb_device_id 0x0000
usb_device_name USB DSL Device
usb_manufacturer_name AVM
usb_revision_id 0x0000
usb_rndis_mac E0:28:6D:xx:xx:xx
wlan_key 47110815

Die SerialNumber steht tatsächlich nur auf 0000, die MAC Adressen und WLAN-Key habe ich mal frisiert.

PS: Woher bekomme ich die Datei tffs_name_table, wird die beim Aufruf von ./build_tffs_image automatisch mit erzeugt?
PPS: Ok, hat sich erledigt, die Datei ist wohl umgezogen und liegt jetzt unter data und heißt nametable_@L
 
Zuletzt bearbeitet:

Das Environment sieht eher so aus, als wäre auch das Flashen einer aktuellen Firmware nicht korrekt abgelaufen (aber ansonsten scheint es durchaus komplett und nicht nur in EVA generiert).

Der Schritt, die aktuelle Version in "firmware_info" abzulegen, erfolgt schon sehr früh im Verlauf des Startprozesses und wenn da noch 141.06.87 steht (und nach dem Löschen mittels "UNSETENV" in EVA beim nächsten Start dort auch wieder eingetragen wird), erfolgt hier wohl ein Startversuch für genau diese Version.

Das mit "kdg" verstehe ich dann auch nicht (ich hätte jetzt das ausgelesene Environment NACH der Änderung des Brandings erwartet, die in #110 erwähnt wurde ... auslesen muß/sollte man das zur Kontrolle ja ohnehin) ... man muß ja wohl annehmen, daß schon der Vorbesitzer da versucht hat, eine Retail-Firmware zu installieren (das sollte man als Käufer zumindest in etwa erfahren haben) und daß die jetzt vermutlich installierte 06.87 damit auch kein "kdg"-Branding enthalten wird. Damit sollte der allererste Schritt das Ändern auf "avm" sein und danach sollte man auch (und zwar nach einem erneuten "Kaltstart" durch Steckerziehen) noch einmal kontrollieren, ob die eigene Änderung nun erfolgreich war oder nicht.

Eine echte Seriennummer steht bei AVM erst seit den GRX5-Modellen im Environment - das ist also zu erwarten, daß da nur Nullen bei einer 6490 auftauchen (das sollte man beim Vergleich mit anderen 6490 oder auch mit anderen Threads hier im IPPF auch sehen können - das ist hier ja ohne einer der eher "abseits stehenden", wie man schon an den Daten der letzten Beiträge sieht, bevor Du Dich drangehangen hast) und damit kein Indiz dafür, ob etwas bzw. was mit dem Environment passiert ist.

Das vorhandene "modulemem" spricht sogar komplett dagegen, daß hier überhaupt ein Environment-Problem vorgelegen haben könnte (daher machen Versuche mit einem TFFS-Image wohl auch nur begrenzt Sinn), denn das würde erst 10 Minuten nach dem erfolgreichen Start des FRITZ!OS überhaupt dort eingetragen und angesichts des beschriebenen Verhaltens beim Boot-Loop kann man wohl davon ausgehen, daß es nicht das derzeit installierte und startende System ist, was diesen Eintrag vorgenommen hat.

Damit KANN der ja eigentlich nur aus irgendeiner vorhergehenden Version stammen und damit KANN dann auch das Environment nicht das Problem gewesen sein. Jedenfalls solange nicht, wie nicht jemand auf die (so gar nicht gute bzw. nachvollziehbare) Idee kam, mit irgendwelchen "Phantasiedaten" aus einer anderen Box/einer anderen "Anleitung" ein TFFS-Image zusammenzuschustern und zu installieren ... ich habe (hoffe ich mal) immer wieder betont, daß die "Betriebsdaten" der Box darin nicht benötigt werden ... das geht von "firstfreeaddress" über "modulemem" bis zu "crash".

Wobei auch Dir die "Anonymisierung" nicht so 100% gelungen ist ... man kann auch aus den beiden USB-MAC-Adressen oder dem CWMP-Account auf die "maca" schließen und von da aus dann den Rest wieder schlußfolgern ... vielleicht willst Du da noch einmal "nacharbeiten" in #112. Daß aber der CWMP-Account ebenfalls zu den gezeigten MAC-Adressen paßt, ist ein weiteres Indiz GEGEN ein selbst erstelltes Environment - oder derjenige hätte tatsächlich sehr wenige Fehler dabei gemacht, was dann wieder zu der Frage führen würde, warum er - trotz offensichtlich gar nicht schlechter Kenntnisse - die Box nicht zum Laufen gebracht hätte.

Ich würde also - bei all den Anzeichen - mehr davon ausgehen, daß das Environment in Ordnung war und ist und eher darauf verzichten, jetzt irgendwelche Experimente mit einem eigenen TFFS-Image zu machen, wenn irgendetwas nicht funktioniert. Da erscheint mir die Suche nach der tatsächlichen Ursache eines solchen "funktioniert bei mir nicht" weiterhin erfolgversprechender - den Rückweg auf MacOS X (was ohnehin dann ohne Homebrew-Software bei diesen Skript-Dateien schwierig ist - nur "juis_check" wurde auch unter diesem System ausführlich auf POSIX- und BSD-Kompatibilität getestet, der ganze Rest nicht und die BSD-Derivate sind da echt zickig) würde ich mir schenken ... wobei einiges unter WSL tatsächlich laufen sollte und ich hier eher auf Firewall o.ä. tippen würde, denn da sitzt auch für die WSL die Windows-Firewall vor dem Netzwerk.
 
Zuletzt bearbeitet:
Danke dir für die Unterstützung!
Ich habe in der Zwischenzeit trotzdem weiter daran rumgefummelt und mit build_tffs_image ein Image gebaut und es mit eva_store_tffs auf die Box geschrieben.
Danach war sie beim booten nur kurz anpingbar und ansonsten offline.

Ich habe anschließend nochmal die Umgebungsvariablen gecheckt, anbei der diff
15d14
< language de
42a42
> provider

Dann habe ich nochmal über eva_discover die Firmware-Version auf AVM gesetzt und dann kam die Box sogar mit der alten Firmware 06.87 hoch, ich konnte mich an der Web-GUI anmelden und ein Update auf 7.10 machen.

Also vermutlich lag es nur daran, dass die ENV nicht richtig gesetzt wurde... :rolleyes:
 
Dann habe ich nochmal über eva_discover die Firmware-Version auf AVM gesetzt
Auch wenn ich neugierig wäre, wie man das mit "eva_discover" macht, halte ich mal für Nachahmer einfach den Tipp fest, beim Erstellen eines eigenen TFFS-Images gleich die richtigen Angaben in der Eingabedatei mit den Environment-Einstellungen zu verwenden ... das spart dann die Notwendigkeit späterer Änderungen über den FTP-Server in EVA, wenn man schon ein eigenes Image erstellt und installiert.
 
ich will mich mal herzlich bei allen bedanken die hier ihre zeit und nerven opfern
ich war auch schon drauf und dran nach firmwares hier zu fragen
aber nach stunden der scripte durchrödeln lassen und anderen Unsinn machend
stellte ich die variablen wie de und 049 einfach alles wieder so ein wie es war war nämlich seit tagen schon im fiesen bootloop und kam nicht mehr raus
nun das half erstmal nicht weiter weil die box jetzt infomässig auf rot blinkte
aber dann machte ich per ftp das draufspielen der Dateien nochmal ich nahm die neue laborversion dies echt hammer
okay blöd ich muss ohne aufsehen erregen den klopsbacken von vodafone die online Registrierung entlocken
aber eigentlich könnte das mein neuer medienserver werden der dank mesh mit 1gbit funkstrecke mit meinem anderen router verbunden ist
ich hatte eine kdg kabelbox 7.12 neustes update aber sowas von limitiert mit den einstellungen auf boxmatrix.info und dem ersten abschnittt deines artikels
habe ich es geschafft juhuu
Anmerkung 2020-05-05 232539.png
https://www.ip-phone-forum.de/threads/gelöst-6490-per-ftp-bootloader-flashen.287470/#post-2210206 Vielen vielen dank und großes LOB an alle :cool::cool::cool:
 
Moin liebe ip-phone-community!

Ich habe eine 6490 und wollte nun das Branding (lgi) entfernen. Dazu habe ich mich an die Anleitung von PeterPawn gehalten.
Als Basis habe ich die LaborVersion 7.20 (eben das Neueste) organisiert und entsprechend Schritte 1 bis 5 durchgeführt (inklusive 5b).
Schritte 6 (Flashen des OS) ohne mtd11+12 sowie ohne 13+14.

Die Box selber ist noch erreichbar nach dem Neustart mittels FTP, aber es läuft ansonsten nicht viel. Nach den ellenlangen Meldungen, was alles nicht mehr geht und wie man seine Box bricked, hab ich beschlossen erst einmal keine weiteren Schritte einzuleiten, damit sie nicht unwiederbringlich kaputt geht. Nach meinem Verständnis hätte die Box nun eigentlich mit dem neuen OS anlaufen sollen, aber es tut sie nicht.

Um einen kurzen Fahrplan wäre ich dankbar, wo ich am besten ansetzen sollte, ohne mehr kaputt als heile zu machen.

Viele Grüße
Euer Spookster

PS: habe mir schon viele der anderen Threads durchgelesen, aber da die alle nicht mehr Neu sind, ist es schwer den Überblick zu behalten, welche Informationen noch relevant sind oder vll überaltert sind. Errine mich da an ein Statement von PeterPawn, der unglücklich war, dass manche Teile kopiert worden sind aber fehlerbehaftet waren (so habe ich es verstanden).
PPS: Danke für jeden konstruktiven Hinweis!
 
[...] jemals eine Anleitung veröffentlicht hat.
Die eine oder andere Anleitung gibt es schon ... auch von mir (u.U. auch in Form einer "Erzählung" oder als "Kurzgeschichte"). Nur sicherlich nicht zum Thema 6490 ... :)
 
So, endlich wieder Zeit um mich um das Problem zu kümmern ;)

Danke für die kurzen Antworten.

@PeterPawn: Jau, jetzt hab ich in den ganzen Threads soviel Zeugs von Dir gelesen, dass ich mich beim Post dann sogar doch noch vertan habe xD der Threadstarter war ja xubutan... MEA CULPA!

@KunterBunter: Dieser Schritt war bisher glaub ich nicht Teil der Gleichung... prüfe das gern eben noch einmal... Ne, das hab ich zwar bei anderen "Anleitungen" gelesen, aber tauchte hier nicht auf. Hatte vermutet, dass sich der Teil erledigt, wenn man das generische Image überspielt, aber das scheint ein Misverständnis zu sein.

EDIT
[: Soll ich das nachziehen?
Da geht es um den Befehl quote SETENV firmware_version avm , richtig?]

Da ist mir wohl einfach der Mut ausgegangen! Danke für den Hinweis! Nach langem, zweifelnden warten, kam dann doch die WLAN Lampe hoch und ich konnte es nicht glauben. Mal sehen, ob alles funktioniert, aber Danke! Anbei die commands, die ich benutzt habe.

debug bin
quote GETENV provider
quote UNSETENV provider
quote SETENV firmware_version avm
quote reboot


--

Ja, es ist ein Doppelpost, aber um dem Board etwas zurückzugeben, melde ich mich noch einmal :)

Also es hat geklappt! Was genau?

Ich hatte eine 6490 mit einer 6er Fritz!OS Version, die kein Meshing unterstützte. Da ich kein Kabel mehr habe, war die Box an und für sich ein Briefbeschwerer, bis ich gelesen habe, dass mit der 7er das Meshing für diese Box freigeschaltet wird. Ich benutze sie als Access Point in einer anderern Etage und die Box ist mit einer 7590 per LAN verbunden.

Installiert ist nun
FRITZ.Box_6490_Cable-07.19-80659-LabBETA.image

geholfen hat mir diese Anleitung (Danke an Threadersteller) und die Stupser von KunterBunter und PeterPawn und ansonsten empfand ich als hilfreich:


um das Subsystem (Bash) ans Laufen zu bekommen (hierzu benötigt man dann noch die Ubuntu Installation aus dem Windows Store), denn es funktioniert mit der neuesten Windows Version nur noch über DISM und nicht (mehr) wie in vielen Anleitungen beschrieben über Apps und Features.

Sollte man Hyper-V noch nicht aktiviert haben, wird das Subsystem nicht anlaufen, daher war auch folgender Link hilfreich


Danke noch einmal!
 
Zuletzt bearbeitet von einem Moderator:
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.