[Erledigt] 7390 Boot-Schleife, bricked?

[scp123]

Ausgangslage: FB 7390 (1&1) hinter EasyBox 804. Warum?

• 7390 hat permanent desyncs, vor allem abends. 804 hat ~5 dB mehr SNR, bisher kein desync
• 804 bietet VoIP nur mit dedizierter VoIP-Hardware an
• Habe keine solche Hardware, sondern bisher mit FritzApp Fon über WLAN telefoniert
• 7390 kann keine VoIP hinter 804 annehmen, da SIP 5060 Port hardcoded
• telnet/SSH Zugang nötig, Firmware 6.83 -> unmöglich
• Flashen!

Problementstehung:

• 6.83 akzeptiert keine nicht von AVM signierten Firmwares
• Recovery gibt's nur 6.51 online, akzeptiert ebenso keine nicht von AVM signierten Firmwares
• Firmware < 6.5x besorgt (Danke)
• modfs funktioniert nicht, weil NOR-Flash
• push_firmware probiert, funktioniert nicht (timeout bei STOR mtd1)
• ruKernel besorgt, < 6.5x flashed, funktioniert!
• über Weboberfläche freetz 6.83 mit dropbear versucht zu flashen, Abbruch, sei keine Firmware für 7390
• über ruKernel versucht zu flashen, lässt mich nur den kernel flashen, keine Firmware. Ergo dropbear wäre nicht dabei, Abbruch
• push_firmware versucht, funktioniert
• Boot-Schleife (3x rot, 1x grün, danach blinkend grün)
• Recovery versucht, keine Chance, findet keine FB
• ruKernel versucht, keine Chance, bricht immer ab mit "konnte keine statische IP setzen"

Problembehebung:
Keine Ahnung. Bricked? Was kann ich noch probieren?

 

[stoney]

• Recovery versucht, keine Chance, findet keine FB

• ruKernel versucht, keine Chance, bricht immer ab mit "konnte keine statische IP setzen"

Wie sehen denn die Einstellungen der Netzwerkkarte aus ? (ich de-/aktiviere nach dem ändern der IP die Netzwerkkarte)

Wurde der PC neugestartet ? (mit eingestellter statitischen IP von 192.168.178.2)

 

[PeterPawn]

Erster Schritt: Hinsetzen und einen Plan machen, der auch funktionieren kann. Zweiter Schritt: Diesen Plan dann auch umsetzen und dabei auftretenden Fehlern auf den Grund gehen, anstatt einen neuen Plan zu machen und beim nächsten Problem dann den dritten, usw.

Die mit Freetz erstellte Firmware läßt sich direkt auf die Box bringen ... notfalls sogar mit einem FTP-Client, solange der den passiven Modus unterstützt. Man darf halt nur nicht beim ersten Problem sofort nach einem anderen Weg suchen, solange das Problem (zumindest der Beschreibung nach) nur in der ungeeigneten Auswahl/Einstellung des eigenen Werkzeugs liegt.

 

[scp123]

Wie sehen denn die Einstellungen der Netzwerkkarte aus ? (ich de-/aktiviere nach dem ändern der IP die Netzwerkkarte)

Wurde der PC neugestartet ? (mit eingestellter statitischen IP von 192.168.178.2)

Letzteres in Kombination mit einer Internetverbindung über WLAN war's, danke. Scheint ein tolles Windows10 Feature zu sein, dass ohne Internetverbindung alle Netzwerkanfragen unterbindet (sagt einfach kein Kabel eingesteckt und verweigert jeden Netzwerkdienst).

Erster Schritt: Hinsetzen und einen Plan machen, der auch funktionieren kann. Zweiter Schritt: Diesen Plan dann auch umsetzen und dabei auftretenden Fehlern auf den Grund gehen, anstatt einen neuen Plan zu machen und beim nächsten Problem dann den dritten, usw.

Die mit Freetz erstellte Firmware läßt sich direkt auf die Box bringen ... notfalls sogar mit einem FTP-Client, solange der den passiven Modus unterstützt. Man darf halt nur nicht beim ersten Problem sofort nach einem anderen Weg suchen, solange das Problem (zumindest der Beschreibung nach) nur in der ungeeigneten Auswahl/Einstellung des eigenen Werkzeugs liegt.

Keine Ahnung was du genau meinst. Der Plan ist makellos und hat auch funktioniert. Einzige fehlerhafte war/ist das freetz-Image.

Ein Tipp warum freetz nicht funktioniert?
Ich habe neben den Standardeinstellungen nur dropbear, debranding 1&1, und signing ausgewählt, so dass ich beim nächsten Mal SSH-Zugang habe bzw. einfach ein freetz über Webapp aufspielen kann.

 

[PeterPawn]

Keine Ahnung was du genau meinst. Der Plan ist makellos und hat auch funktioniert.

Wenn der funktioniert hätte, gäbe es ja das Problem nicht ... was ich damit zum Ausdruck bringen wollte, war nur die Feststellung, daß Du praktisch alle derzeit bekannten Werkzeuge für das Flashen einer NOR-Box ausprobiert hast (mit Ausnahme des "reinen" FTP-Clients) und doch keiner der Wege zum (stillen) Erfolg führte - ansonsten hätte es diesen Thread ja nicht gebraucht. Und auch die abschließende Frage

Was kann ich noch probieren?

legt ja nahe, daß Du auf der Suche nach dem "nächsten Plan" bist und weniger auf der Suche nach den eigenen Fehlern bei der Umsetzung des einen (richtigen) Plans.

Auch gibt es nun mal - zumindest nach dem, was Du schreibst - noch Probleme beim Verständnis der Abläufe ... ein Beispiel wäre:

über ruKernel versucht zu flashen, lässt mich nur den kernel flashen, keine Firmware. Ergo dropbear wäre nicht dabei, Abbruch

Bei NOR-Boxen gibt es nur eine einzelne Datei (nämlich "kernel.image"), die aus dem eigentlichen Kernel und dem daran unmittelbar anschließenden SquashFS-Image besteht ... die "filesystem.image" hat bei diesen Modellen eine Größe von 0 Byte und es ist vollkommen richtig (und ausreichend), die "kernel.image" nach MTD1 zu schreiben, um eine NOR-Box (mit diesem Aufbau) sowohl mit einem neuen Kernel als auch einem geänderten Filesystem zu versehen.

Schon anhand der letzten zwei Punkte aus der Beschreibung in #1 konnte man ablesen, daß es (vermutlich nach der Verwendung des ruKernelTools, was wohl die IP-Adresse auf 99.88.77.xxx verstellt hatte) am Ende nur ein Problem der korrekten Netzwerkeinstellungen war (das dreimalige rote Blinken signalisiert die Zeit, in der der FTP-Server in EVA Verbindungen annimmt und damit normalerweise auch die korrekte Funktion des Bootloaders, was dem

Bricked?

entgehensteht) und das wollte ich mit meinem letzten (Halb-)Satz in #2 zum Ausdruck bringen.

 

[scp123]

Wenn der funktioniert hätte, gäbe es ja das Problem nicht ... was ich damit zum Ausdruck bringen wollte, war nur die Feststellung, daß Du praktisch alle derzeit bekannten Werkzeuge für das Flashen einer NOR-Box ausprobiert hast (mit Ausnahme des "reinen" FTP-Clients) und doch keiner der Wege zum (stillen) Erfolg führte - ansonsten hätte es diesen Thread ja nicht gebraucht. Und auch die abschließende Frage

legt ja nahe, daß Du auf der Suche nach dem "nächsten Plan" bist und weniger auf der Suche nach den eigenen Fehlern bei der Umsetzung des einen (richtigen) Plans.

Der Plan war freetz zu flashen und das habe ich auch erfolgreich getan. Also hat der Plan funktioniert.

Ob freetz dann tatsächlich funktioniert, stand nicht im Plan.

Auch gibt es nun mal - zumindest nach dem, was Du schreibst - noch Probleme beim Verständnis der Abläufe ... ein Beispiel wäre:

Bei NOR-Boxen gibt es nur eine einzelne Datei (nämlich "kernel.image"), die aus dem eigentlichen Kernel und dem daran unmittelbar anschließenden SquashFS-Image besteht ... die "filesystem.image" hat bei diesen Modellen eine Größe von 0 Byte und es ist vollkommen richtig (und ausreichend), die "kernel.image" nach MTD1 zu schreiben, um eine NOR-Box (mit diesem Aufbau) sowohl mit einem neuen Kernel als auch einem geänderten Filesystem zu versehen.

Danke dafür. Meine Annahme rührte von ruKernel her. Dort heißt es (Wortlaut): "kernel.image ist aus der Firmware extrahiert und enthält nur das OS, sonst keine weiteren Pakete." Letzteres lies mich schließen, dass Pakete wie dropbear dann nicht enthalten seien.

Schon anhand der letzten zwei Punkte aus der Beschreibung in #1 konnte man ablesen, daß es (vermutlich nach der Verwendung des ruKernelTools, was wohl die IP-Adresse auf 99.88.77.xxx verstellt hatte) am Ende nur ein Problem der korrekten Netzwerkeinstellungen war (das dreimalige rote Blinken signalisiert die Zeit, in der der FTP-Server in EVA Verbindungen annimmt und damit normalerweise auch die korrekte Funktion des Bootloaders, was dem

entgehensteht) und das wollte ich mit meinem letzten (Halb-)Satz in #2 zum Ausdruck bringen.

Das ist falsch. Windows10 hat jeden Netzwerkdienst unterbunden gehabt, weil angeblich "kein Kabel" angeschlossen. Deswegen hat kein kein Netzdienst funktioniert, z.B. ping, aber auch nicht die Funktion, das Netzwerk zu konfigurieren. Dies hat ruKernel testet, ob es das kann. An dieser Stelle hat ruKernel korrekterweise abgebrochen.
Recovery dagegen, hat nicht abgebrochen, sondern ist nach einem Timeout auf 192.168.178.1 in einer Endlosschleife gelandet mit 0.0.0.0 zu verbinden.

Halten wir fest: Ich kann vermutlich freetz direkt mit ruKernel flashen. Wahrscheinlich ändert das aber nichts an der Funktionsfähigkeit von freetz. Ein Tipp dazu?

 

[stoney]

Es dauert einfach eine gewisse Zeit bis die Netzwerkkarte erkennt, dass ein aktives Gerät darang "hängt" - ein Switch dazwischen wirkt da Wunder (diese und andere Methoden wurden aber an anderer Stelle genug disskutiert)
Ob es an W10 liegt wage ich zu bezweifeln, im Idealfall deaktiviert man alle Netzwerkinterfaces bis auf das, was genutzt werden soll.

Ich kann vermutlich freetz direkt mit ruKernel flashen.

nicht nur vermutlich, dass kann Du!

Wahrscheinlich ändert das aber nichts an der Funktionsfähigkeit von freetz

wie das (Freetz) Image auf die Box kommt spielt keine Rolle. Warum auch?!

Ein Tipp dazu?

einen Tipp wozu?

 

[PeterPawn]

Erstens ist das für Freetz hier das falsche Unterforum (dafür gibt es ein eigenes) und zweitens bleibt mir auch hier eigentlich nur die Feststellung, daß Dein Problem mit einem funktionsfähigen und laufenden Freetz-Image auf der Box wohl eher an eigenen Fehlern liegt als an einem generellen Problem. Wie soll man jetzt anhand der bisher vorhandenen Angaben eine Idee entwickeln, die auch nur im Ansatz auf einer plausiblen Annahme beruhen kann? Da bleibt praktisch nur "Benutzerfehler" und da Du das ja offenbar eher als "ehrenrührig" ansiehst (auch wenn Du nicht der Erste und vermutlich auch nicht der Letzte bist, dem solche Fehler unterlaufen), bin ich mir nicht sicher, ob ich tatsächlich der Richtige für die weitere Diskussion wäre ... aber ich bin mir (s.o.) ziemlich sicher, daß das hier nicht das richtige Unterforum ist.

BTW ... wenn wir beide von "Plan" reden, meinen wir offenbar auch jeweils etwas anderes. Bei Dir ist es offenbar eher eine Frage der Strategie (also mehr das zu erreichende Ziel):

Der Plan war freetz zu flashen und das habe ich auch erfolgreich getan. Also hat der Plan funktioniert.

, während ich da auch noch den Weg zu diesem Ziel (also "Taktik") einbeziehen würde und dazu gehört auch die richtige "Werkzeugsammlung" (oder auch "toolbox") und das geplante Vorgehen in einzelnen Schritten. Hier hast Du (nach Deiner eigenen Beschreibung) eben nicht nur einen Weg genommen und bei dessen Umsetzung eigene Fehler gesucht bzw. ausgeschlossen, sondern bei einem Problem einfach einen anderen Weg genommen (der aber erst mal genauso in die Hose ging).

 

[stoney]

Erstens ist das für Freetz hier das falsche Unterforum

dachte ich mir direkt nach Erstellung des Threads zwar auch, war mir aber nicht sicher, ob es jetzt wirklich in die Richtung Freetz geht...

@scp123 soll nach Freetz verschoben werden?

 

[scp123]

Ich bin mir ziemlich sicher, dass es ein W10 Feature ist. Was sonst sollte komplett den Netzverkehr unterbinden (selbst die Konfiguration des Netzwerks) sobald am anderen Ende des Kabels kein Switch oder sonstiges hängt, bzw. mit 1-2 s Zeitfenster zu kurz aktiv ist?

Mit meiner Lösung einfach ein 2. Netzwerk über WLAN aktiv halten, sodass ich das 1. Kabelgebundene kofigurieren kann, hat's dann schließlich funktioniert.

Problem war der debranding Patch in freetz. Denn wer hätte gedacht, dass man nicht den debranding-Patch zu seinem Branding auswählen darf, wenn dieser im Bootloader steht. Mir bleibt dann der Sinn dieser Patches fern.

Thema erledigt.

 

[PeterPawn]

Problem war der debranding Patch in freetz. Denn wer hätte gedacht, dass man nicht den debranding-Patch zu seinem Branding auswählen darf, wenn dieser im Bootloader steht. Mir bleibt dann der Sinn dieser Patches fern.

Das kann/will ich so nicht stehen lassen (zumindest für spätere Leser, die dann den Sinn ja vielleicht sehen können) ... die Anzeige(n) in Freetz ist/sind auch nur schwer mißzuverstehen.

Dort wird unter dem Oberpunkt "Removal patches" auch "Remove brandings" angeboten, wo man dann die Möglichkeit hat, einzelne Brandings entfernen zu lassen (was nur sehr wenig zusätzlichen Platz in aktueller Firmware bringt).

Irgendwie versteht es sich eigentlich von selbst, daß es hier darum geht, die Unterstützung für dieses Branding aus der Firmware zu entfernen und nicht etwa darum, das Branding der Box zu ändern - es geht hier ja auch um das Erstellen der eigenen Firmware und nicht um deren Installation (also das "Bündeln" der erzeugten Firmware mit einem konkreten Gerät).

Dann sollte man auch nicht auf die Idee kommen, hier das derzeit aktive Branding des "Zielgerätes" auszuwählen ... auch wenn die Möglichkeit, dort tatsächlich alle Brandings aus der Firmware entfernen zu lassen, wohl als "pitfall" für unerfahrene Anwender angesehen werden kann. Wobei auch das eigentlich nur für "sehr Unerfahrene" zu konstatieren ist, denn der Hilfetext für diesen Patch bemerkt noch ausdrücklich:

Each branding provides the web UI templates for a certain manufacturer or OEM.

NOTE: Make sure not to remove the branding corresponding to the one defined
in your box's boot loader environment. It can be determined by calling the
following command from the box's shell prompt:

echo $(cat /proc/sys/urlader/firmware_version)

Ansonsten bringt dieser Patch inzwischen tatsächlich nur noch wenig Einsparungen ... das liegt u.a. daran, daß die Brandings heutzutage nur noch sehr wenige Unterschiede im Dateisystem enthalten, das verwendete SquashFS automatisch Duplikate von Dateien erkennt und bei solchen Dubletten lediglich noch einige Verwaltungsinformationen zusätzlich in das Image eingebaut werden (anstelle einer Kopie der kompletten Datei).

Man sollte/kann also problemlos auf diesen Patch verzichten, solange man nicht wirklich das letzte Byte aus dem Image quetschen will oder muß (da hat sich durch den neuen PLUGINV2-Mechanismus die Situation bei der 7390 durchaus etwas entspannt) - und auch dann sollte man nur die Brandings aus der Firmware entfernen lassen, die man in der eigenen Box eben NICHT benötigt.