[Problem] rote Info LED nach Werkseinstellungen und ändern der Bootpartition (6490)

[stoney]

ja es scheint so das die Phantom MAC durch die Inkonsistenz zustande kam ?
Ich muss auf auf jeden Fall kein arp -s mehr setzten und erreiche die Box per 192.168.178.1

quote UNSETENV firmware_info
quote SETENV firmware_info recovered=2
quote SETENV firmware_info recovered=3

selbe Ergebnis in der Lichterorgel..

 

[Pokemon20021]

wenn die Kiste nun nach erfolgreicher TFFS-Partition-Reparatur und nach Anwenden der Inputs von PeterPawn aus #106

• "quote UNSETENV firstfreeaddress"
• sowie Anpassung der "firmware_info": "Anhängen von ',recovered=3' das Zurücksetzen auf Werkseinstellungen 'komplettieren' lassen (also 'nvram' neu initialisieren lassen"

immer nicht bootet, bzw. in den Ausgangsstatus #1 zurückgelangt, dann ist es naheliegend, dass durch das Schreiben eines "defekten" TFFS-Images weitere Partitionen (Kernel, oder Root-FS) korrupt gegangen sind, siehe auch:

BTW ... ich muß glatt mal nachsehen, ob das "out of bounds"-Schreiben beim TFFS immer noch möglich ist bei der Initialisierung, da gab es mal eine Möglichkeit. Da konnte man durch ein (absichtlich) falsch aufgebautes TFFS-Image fremde Bereiche im Kernel-Speicher nach der "name table" bei deren Laden aus dem TFFS überschreiben (hatte ich in einer E-Mail am 01.04.2016 an AVM mal angerissen als mögliches Problem (und das war kein Aprilscherz), aber ohne PoC, da kam niemals auch nur eine Nachfrage nach genaueren Einzelheiten zurück) und damit eine Box zum "Recovery-Fall" machen - blöd nur, wenn es gar kein Recovery-Programm für das Modell gibt. Mal schauen ... wenn das immer noch funktioniert, melde ich es demnächst mal - eine 6490 könnte damit vermutlich leicht "abgeschossen" werden.

Das Schreiben eines ungültigen TFFS-Images habe ich selbst (zur Validierung einer entsprechenden Fehlermeldung an AVM am 13.09.2016) ausprobiert (das Image enthielt eine ungültige "name table" und damit waren die dahinterliegendenen Daten auch nicht erreichbar) ... ich konnte im Anschluß problemlos ein neues TFFS-Image schreiben (allerdings keine alten Daten lesen - das habe ich aber gar nicht erst probiert).

d.h. es bleibt nur noch "Second Life" z.B. als Türstopper, Briefbeschwerer, ...

 

[stoney]

wenn die Kiste nun nach erfolgreicher TFFS-Partition-Reparatur und nach Anwenden der Inputs von PeterPawn aus #106

• "quote UNSETENV firstfreeaddress"
• sowie Anpassung der "firmware_info": "Anhängen von ',recovered=3' das Zurücksetzen auf Werkseinstellungen 'komplettieren' lassen (also 'nvram' neu initialisieren lassen"

immer nicht bootet, bzw. in den Ausgangsstatus #1 zurückgelangt, dann ist es naheliegend, dass durch das Schreiben eines "defekten" TFFS-Images weitere Partitionen (Kernel, oder Root-FS) korrupt gegangen sind..

d.h. es bleibt nur noch "Second Life" z.B. als Türstopper, Briefbeschwerer, ...

nein ein UNSET firstfreeaddress bringt auch nicht

Also heißt das unterm Strich wenn ich das jetzt richtig verstehe, dass

Durch die inkonsistenten env und counter welche unter Ubuntu erstellt wurden, vorher aber noch ein " mac2unix -n <origfile> <dstfile> / mac2unix <file>" benötigt hätten, die Box jetzt erst mal "gebricked" haben bis es (vielleicht) mal ein RecoveryTool gibt ?

Durch die vorher inkonsistenten files wurde die PhantomMac "generiert" da die files mit " cat " nicht lesbar waren?

Nach dem TFFS upload eines Images mit konsistente env und couter haben die PhantomMac verschwinden lassen sodass zumindest jetzt meine Box wieder auf #1 Stand ist ?

Edit:
Aber was brachte denn jetzt die Box in den Zustand von #1?
Das laden der Werkseinstellungen mit alten certs ? hab da mal was hier im Forum gelesen (und auch in einem vorherigen Post angesprochen)
Oder doch das zurücksetzten und direkte umstellen von linux_fs_start ohne die Box über den Bootloader hinaus fahren zu lassen ?

Mit über 3k Aufrufen gibt es ja scheinbar noch mehr mit diesem oder ähnlichen Fehlerbild.
Ich denke eine Art "Sammlung" über die Verläufe zusammen zu tragen wäre hilfreich.

 

[Pokemon20021]

Ja, so sehe ich dies, es war wohl etwas in Abarbeitung der Schritte 4 -5, das diese Folgestörung verursacht hat, ansonsten müsste ja der Ausgangszustand #1 wieder erreichbar sein.

Hinweis: die Tools im tffs-bzw. im eva_tools-Verzeichnis sind IMHO teilweise aus Proof-of-concept entstanden, d.h. es gibt derzeit noch nicht überall Plausibilitäts-Prüfungen. Folglich muß der Anwender/Operator entsprechend Augen aufmachen und die Zwischenergebnisse prüfen;

auch sollte man auch auf die Anleitungen sehen:

• wie alt sind diese (Timestamp der letzten Änderung),
• hat der Verfasser in Folgepostings noch Anmerkungen/Änderungshinweise gemacht,
• haben sich seit Erstellungsdatum die zugehörigen Tools im Git-Hub geändert, ...

am Besten ist es, wenn der Anwender weiß was er tut, da in diesem Fall Fehler unverzeichlich sind.


siehe auch Posting mit Beschreibung wie ein TFFS-Image mit provideradditive.tar erstellt werden kann, was ebenfalls die Tools "build_tffs_image, eva_store_tffs" einsetzt; hier gibt es vom Verfasser tetzlav folgende Anmerkungen:

WICHTIG VORAB: Das ist keine Step-by-Step-Anleitung für Leute die nicht wirklich wissen/verstehen was hier passiert. Ich habe diese "Anleitung" nur erstellt um zu zeigen dass das in den vorangegangene Beiträgen diskutierte Proof-of-Concept wirklich funktioniert und versiertere Linux-Nutzer es nachvollziehen können. Wer nicht versteht was hier gemacht wird: LASS ES BITTE und/oder ließ dir ersteinmal den kompletten Thread hier durch!

sowie http://www.ip-phone-forum.de/showthread.php?t=286994&p=2191445&viewfull=1#post2191445

Bitte nicht falsch verstehen oder Böse sein, ich bin hier nur der Überbringer der "schlechten" Botschaft.

 

[stoney]

Nein keine Angst ich sehe das eher als positive Kritik.

Ich war der Annahme das ich mich genügend eingelesen habe und genügend Grundkenntnisse vorhanden sind.
Wie kommt das eig. das die Files inkonsistent erstellt werden vom ./eva_get_environment ? - wäre eine zusätzliche Installation von Paket nötig gewesen ?

Ich wäre trotzdem bereit alles nochmal übersichtlich zusammen zu fassen - auch wenn es ja bislang das eig. Problem nicht löst.

Ich habe ja selbst ein paar Pakete nachinstallieren müssen nach der frischen Ubuntu 16.04 LTS - hätte man ggf. vor dem erstellen mit ./eva_get_environment ein Paket installieren müssen, damit die files konsistent erzeugt worden wären??

Allerdings sind die ein oder anderen Sachen - wie zB die Box nicht per 192.168.178.1 zu erreichen außer man legt einen passenden "arp -s" an für jmd hilfreich. (auch in Bezug natürlich auf andere Modelle)

Also wer auch dieses oder ähnliche Probleme und ggf. Lösung dafür gefunden hat, soll sich doch bitte zu Wort melden. - Denn hier ist erst mal Schluss mit Neuigkeiten wie es aussieht (außer Peter würde jetzt noch etwas einfallen)

 

[Pokemon20021]

Wie kommt das eig. das die Files inkonsistent erstellt werden vom ./eva_get_environment ? - wäre eine zusätzliche Installation von Paket nötig gewesen ?

hierzu am besten direkt bei Entwickler @PeterPawn oder Verfasser des Workflows @fesc melden;

Wichtig: mehrer User wie @stanpete78 oder "Daniel Ventura" haben erfolgreich den Workflow fon fesc umgesetzt.
http://www.ip-phone-forum.de/showthread.php?t=282765&p=2193077&viewfull=1#post2193077
http://www.ip-phone-forum.de/showthread.php?t=285810&p=2173053&viewfull=1#post2173053

theoretisch sollte es möglich sein, alle Aktivitäten des "fesc-Workflows" in ein Programm zu packen, inkl. Plausibilitätsprüfungen;
ich denke die Community wäre dankbar, wenn Du dies inkl. Beschreibung umsetzt und die Wartung und Support übernimmst; Vorlage wäre z.B. "modfs"

 

[stoney]

Allerdings hatten fesc stanpete78 und Daniel Ventura ja ansich andere Probleme wie ich in #1 angegeben habe, oder ?

Da ging es ja eher um falsche routeringtabellen bzw bootloop (ist ja beides nicht der Fall bei mir)

Das Ursprungsproblem steht ja auch noch weiterhin im Raum
weiß jetzt jmd was über das "Phänomen" mit den Werkseinstellungen und den, ich glaube es waren alten certs, welche die Box in einen ähnlichen Zustand versetzte ?

 

[chilango79]

Oder ihr wartet auf eine recover-FW von AVM.
Auf dem FTP-Server bestehen ja schon die Ordner. Ist nur eine Frage der Zeit

 

[stoney]

Oder ihr wartet auf eine recover-FW von AVM.
Auf dem FTP-Server bestehen ja schon die Ordner. Ist nur eine Frage der Zeit

Durch die inkonsistenten env und counter welche unter Ubuntu erstellt wurden, vorher aber noch ein " mac2unix -n <origfile> <dstfile> / mac2unix <file>" benötigt hätten, die Box jetzt erst mal "gebricked" haben bis es (vielleicht) mal ein RecoveryTool gibt ?

Diesen Ordner "x_misc/" gibt es bei jedem Modell - auch bei der 6360 und dieser ist auch schon seit dem ich mich daran erinnern kann leer.

Aber klar - wenn es eine freie Version von der 6490 gibt, sollte da auch ein recover mal folgen.

Allerdings denke ich das es wie bei den DSL Modellen ist, nur für firmware_version avm + 1 & 1, also nur für die Retail anwendbar sein wird - nur eine Annahme meinerseits

 

[Pokemon20021]

weiß jetzt jmd was über das "Phänomen" mit den Werkseinstellungen und den, ich glaube es waren alten certs, welche die Box in einen ähnlichen Zustand versetzte ?

ich hoffe nicht, dass da ein Vorbesitzer Dir einen speziellen "Push Service" hierfür eingerichtet hat https://github.com/PeterPawn/YourFritz/tree/master/reported_threats/796851 und Du den "Passwort vergessen" Button gedrückt hast ;-)

 

[stoney]

Zumindest kann ich mich daran nicht mehr erinnern - allerdings verstehe ich den englischen Text auch nur teilweise - leider

 

[Pokemon20021]

es gibt auch ein dt. Posting hierzu:
http://www.ip-phone-forum.de/showthread.php?t=286994&p=2192663&viewfull=1#post2192663

oder mit einem Praxis-Beispiel:
http://www.ip-phone-forum.de/showthread.php?t=286994&p=2193739&viewfull=1#post2193739

Der exploit über Export-Passwort wird im übrigen auch beim Zurücksetzen auf Werkseinstellungen ausgelöst

"Push Service" cfgexport mit Password:
https://service.avm.de/help/de/FRITZ-Box-6490-Cable/014/hilfe_system_pushservice_cfgexport

 

[stoney]

Entschuldigt das ich mich erst jetzt zurück melde.

Wie es aussieht war es Export-Passwort Exploit welcher beim Zurücksetzten ausgelöst wurde.

Zum Glück war dieser Thread nicht ganz umsonst (Phantom MAC) und kann doch dem ein oder anderen helfen - ich denke es wäre Sinnvoller die Überschrift dementsprechend abzuändern "6490 Passwort Exploid" oder zumindest das mit der Bootpartition raus nehmen, das hatte ja letztendlich nichts damit zu tun.

Ich hoffe ich finde bald die Zeit um das wie schon geschrieben, eine Zusammenfassung zu schreiben. (ich hoffe ich bekomme es noch hin)

Ich danke Pokemon20021 und PeterPawn für die Unterstützung

 

[noob_noob]

moin,

ich hab hier auch so nen kandidaten mit 30:78:30:30:2c:20 und nicht erreichbarem bootloader.
led's = alle 1 mal an, dann 4 *rot, 2 sec pause, wieder 4 mal rot...
setze ich mit arp -s 192.168.178.1 (cwmp-acoount mac) komme ich zwar auf den bootloader, aber alle env's die ich mit GETENV abfragen möchte, sind leer. ein versuch sie neu zu setzten quittiert die kiste mit

501 environment variable not set

eva_getenvironment läuft ins leere

einer ne idee, wie ich die wiederbeleben kann?

 

[back2live]

Setze mal die Variablen (auch mtdx) per Hand, klappt das?

 

[noob_noob]

quittiert sie mit:

501 environment variable not set

edit

mein fehler.
irgendwas ist beim erstellen des mtd.img für mtd3&4 in die hose gegangen. count und env.txt hatte ich noch. neue datei erstellt, geflasht... alles wieder hübsch

 

[Pokemon20021]

ich hab hier auch so nen kandidaten mit 30:78:30:30:2c:20 und nicht erreichbarem bootloader.
led's = alle 1 mal an, dann 4 *rot, 2 sec pause, wieder 4 mal rot...
...
einer ne idee, wie ich die wiederbeleben kann?

auch andere Nutzer sind mit diesem Fehlerbild konfrontiert worden: http://www.ip-phone-forum.de/showthread.php?t=289201&p=2197300&viewfull=1#post2197300

 

[stoney]

moin,

ich hab hier auch so nen kandidaten mit 30:78:30:30:2c:20 und nicht erreichbarem bootloader.
led's = alle 1 mal an, dann 4 *rot, 2 sec pause, wieder 4 mal rot...
setze ich mit arp -s 192.168.178.1 (cwmp-acoount mac) komme ich zwar auf den bootloader, aber alle env's die ich mit GETENV abfragen möchte, sind leer. ein versuch sie neu zu setzten quittiert die kiste mit

501 environment variable not set

eva_getenvironment läuft ins leere

einer ne idee, wie ich die wiederbeleben kann?

quittiert sie mit:

501 environment variable not set

edit

mein fehler.
irgendwas ist beim erstellen des mtd.img für mtd3&4 in die hose gegangen. count und env.txt hatte ich noch. neue datei erstellt, geflasht... alles wieder hübsch

Wie war denn deine Ausgangssituation ? - Nur das Problem beim erstellen / flashen von mtd3+4 durch das scheinbar Fehlerhafte mtd.img ? Werkseinstellungen / Pushmail Bug ? oder gar etwas ganz anderes ?

Was für eine 6490 ist es denn (am besten mit Artikelnummer, für mein Interesse und ggf. für spätere Leser)

 

[noob_noob]

da hatte ich mir die ar7.cfg beim try & error config suchen zersemmelt, dann wohl die datei für mtd3&4 falsch erstellt.

 

[stoney]

quittiert sie mit:

501 environment variable not set

edit

mein fehler.
irgendwas ist beim erstellen des mtd.img für mtd3&4 in die hose gegangen. count und env.txt hatte ich noch. neue datei erstellt, geflasht... alles wieder hübsch

Sehe es erst jetzt.
Aber schön das du trotzdem nach 17 Tagen zurück geschrieben hast