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

[Pokemon20021]

Habe hier mal mit dem ruKernel die mtd3 beider Partitionen ausgelesen

Allerdings hat sich an meinem Problem nichts geändert - es ist ein neues dazu gekommen - und zwar ist die Box per adam nicht mehr erreichbar

ftp 192.168.178.1
ftp: connect: Connection timed out
ftp >

Frage: Kann es sein, dass Du Dir mit der ruKernelTool Episode dir die Bootloader Environment-Variable my_ipaddress von 192.168.178.1 nach 99.88.77.1 "verbogen" hast ?

War da so ein Output im ruKernelTool ?

Box-Informationen auslesen:
===========================
SNIP

  PC temporär auf statische IP-Adresse "99.88.77.66" umsetzen... fertig
  Netzwerkadapter noch einmal neu einlesen... fertig
  Aktuelle Einstellungen:
    IP-Adresse:       99.88.77.66
    Adam2-IP-Adresse: 99.88.77.1

siehe auch:
http://www.ip-phone-forum.de/showthread.php?t=288563&p=2189989&viewfull=1#post2189989

Vorschlag: PC mal auf IP 99.88.77.66 / Subnetmask 255.255.255.0 einstellen
und dann mit "ftp 99.88.77.1" den Zugriff auf die FB6490 testen.

 

[stoney]

Auch kein Erfolg

Daran wirds auch nicht liegen, da ich ja NACH dem rukernel #9 erst an das TFFS ran bin, somit kann wenn dann höchstens was dabei schief gelaufen sein, was ja leider nicht mehr nachvollziehbar ist, da ich mir die 3 files nicht gesichert habe.

 

[Pokemon20021]

an das TFFS ran bin, somit kann wenn dann höchstens was dabei schief gelaufen sein

ich Frage mich halt, was da schief gelaufen sein kann,
hast Du evtl. das falsche Destination-Partition bei Befehl eva_store_tffs angegeben ?
evtl. mtd1 statt mtd3 ?

 

[stoney]

Nein.
Sicher mtd3 und mtd4

 

[Pokemon20021]

sollte bei der Anwendung der "eva_store_tffs" Befehle aus dem Posting von fesc

cd eva_tools
eva_store_tffs mtd3 /tmp/mtd.img
eva_store_tffs mtd4 /tmp/mtd.img

der Bootloader zerstört worden sein,
so bleibt für die Box nur noch "Second Live" Nutzung übrig.

siehe auch:

Hat man aber den Bootloader erst einmal zerschossen (ich weiß nicht einmal sicher, ob man die cefdk-Partition schreiben könnte, ich mußte es eben noch nie probieren - zumindest das Vorgehen dürfte ziemlich anders sein als bei anderen (AVM-)Boxen), ist das auch nur noch der berühmte Ziegelstein/Briefbeschwerer.

 

[PeterPawn]

Das TFFS-Image läßt sich ja jederzeit neu erstellen ... auf die Counter-Werte ist bei der 6490 gepfiffen (die sind ohnehin beim "normalen Auslesen" nur "u" und werden nach 0 "übersetzt") und der Rest des Environments läßt sich ja auslesen.

Wenn man vor dem Start des Systems den Inhalt von "firmware_info" im Urlader-Environment löscht, kann man am Wert beim/nach dem Hängenbleiben zumindest ablesen, ob bis zur S01-head abgearbeitet wurde oder ob ggf. schon das Mounten des Root-Dateisystems nicht funktionierte (dann startet nicht einmal ein "init").

Solange die Box noch etwas mit den LEDs signalisiert, was sich nicht in den ersten drei bis vier Sekunden nach dem PowerOn abspielt, solange ist auch der Zugriff auf den FTP-Server im Bootloader möglich ... alles andere widerspräche eklatant den bisher zusammengetragenen Erkenntnissen.

Das ist zwar auch nicht vollkommen auszuschließen, aber anhand der "Wahrscheinlichkeiten" würde ich hier doch eher auf "handwerkliche Fehler" als auf einen kaputten Bootloader tippen - die bisher hier abgegebenen Beschreibungen überzeugen mich nicht wirklich, daß da bis ins Detail verstanden wurde, wie das funktioniert.

Da das aber wirklich oft genug beschrieben ist, fange ich damit nicht erneut an ... auch ein Grund, warum ich mich bisher hier komplett herausgehalten habe. Ich will eigentlich nur der Vermutung, der Bootloader wäre bei der beschriebenen Länge der Schleife (bzw. beim beschriebenen Hängenbleiben beim Booten der Box) automatisch als unbrauchbar anzusehen, entgegentreten.

 

[Pokemon20021]

Solange die Box noch etwas mit den LEDs signalisiert, was sich nicht in den ersten drei bis vier Sekunden nach dem PowerOn abspielt, solange ist auch der Zugriff auf den FTP-Server im Bootloader möglich ... alles andere widerspräche eklatant den bisher zusammengetragenen Erkenntnissen.

@PeterPawn: vielen Dank für Unterstützung.

@stoney0815: sollte die "LED-Lichtorgel" noch "Musik" von sich geben, dann sollte wie PeterPawn schreibt die FTP-Verbindung zur EVA-/ADAM2-Schnittstelle erneut getestet werden;

Vorschlag:
Ubuntu-VM fest auf IP=192.168.178.2 einstellen, im nachfolgenden Bespiel habe ich eth0 als LAN-Interface angenommen; dann einfach folgende Befehle als User root eingeben:

# cd eva_tools
#
# EVA_IP=[COLOR=#0000ff]192.168.178.1[/COLOR]
# PC_IP=[COLOR=#0000ff]192.168.178.2[/COLOR]
# PC_LAN_IF=[COLOR=#0000ff]eth0[/COLOR]
#
# eval $(./eva_discover INTERFACE=[COLOR=#0000ff]$PC_LAN_IF[/COLOR]  FROM=[COLOR=#0000ff]$PC_IP[/COLOR] TO=[COLOR=#0000ff]$EVA_IP[/COLOR] BLIP=1 WAIT=120 HOLD=0);nc [COLOR=#0000ff]$EVA_IP[/COLOR] 21

idealerweise erscheint am Ende ein "220 ADAM2 FTP Server ready" als Consolen-Output.

 

[stoney]

Danke Pokemon für deinen weiteren Einsatz :smile:

Ich bin eig. auch einer der nicht so schnell aufgibt und alles versucht.

Habe deinen Vorschlag dankend angenommen

Allerdings bekomme ich

"" utility couldn't be found or isn't executable.

Ich habe unter ../eva_tools/ die Datei "rettung" mit folgendem Inhalt angelegt

 #! /bin/bash
# cd eva_tools

EVA_IP=[COLOR=#0000ff]192.168.178.1[/COLOR]
PC_IP=[COLOR=#0000ff]192.168.178.2[/COLOR]
PC_LAN_IF=[COLOR=#0000ff]enp0s3[/COLOR]

eval $(./eva_discover INTERFACE=[COLOR=#0000ff]$PC_LAN_IF[/COLOR]  FROM=[COLOR=#0000ff]$PC_IP[/COLOR] TO=[COLOR=#0000ff]$EVA_IP[/COLOR] BLIP=1 WAIT=120 HOLD=0);nc [COLOR=#0000ff]$EVA_IP[/COLOR] 21

welche ich mit "sudo ./rettung" ausführe

meine ifconfig sieht so aus

 

[Pokemon20021]

"" utility couldn't be found or isn't executable.

Bitte das Programm socat installieren:

# cat eva_discover
SNIP
if [ ! -x "$socat" ]; then

    echo "\"$socat\" utility couldn't be found or isn't executable." 1>&2
    exit 1

#
# [COLOR=#0000ff]sudo [I]apt[/I]-[I]get install socat[/I]
[/COLOR]

eva_discover:

• shell script to detect a starting FRITZ!OS device in your network
• BusyBox 'ash' compatible syntax
• 'socat' utility (http://www.dest-unreach.org/socat/) is needed for network access
• command line parameter utilization is incomplete yet

 

[stoney]

nach der installation von socat läuft es zwar nicht in einen Fehler - allerdings auch in kein Ergebnis ?




Das Script ansich selbst funtioniert (zumindst per WLAN an meine 7490 - bekomme ich einen "220 ADAM2 FTP Server ready" als Antwort

edit:

hab den timeout (wait) mal auf 300 gesetzt - Bordcastpakets werden versucht zu senden - allerdings landet es immer in einer "leeren" Befehlzeile, wie im Bild oben zu sehen.

(Die Lichterorgel ändert sich nicht - immer noch 7x Power/Cable danach immer der selbe Intervall 2x blinkende INFO LED 2 Sekunden Pause - 2x blinkende Info LED - 2 Sekunden Pause,....

 

[Pokemon20021]

leider kann ich aus dem Fehlerbild

Die Lichterorgel ändert sich nicht - immer noch
7x Power/Cable
danach immer der selbe Intervall 2x blinkende INFO LED
2 Sekunden Pause -
2x blinkende Info LED -
2 Sekunden Pause,....

ist die Box per adam nicht mehr erreichbar

ftp 192.168.178.1
[COLOR=#FF0000]ftp: connect: Connection timed out[/COLOR]
ftp >

sowie:

Ich habe unter ../eva_tools/ die Datei "rettung" mit folgendem Inhalt angelegt

 #! /bin/bash
# cd eva_tools

EVA_IP=[COLOR=#0000ff]192.168.178.1[/COLOR]
PC_IP=[COLOR=#0000ff]192.168.178.2[/COLOR]
PC_LAN_IF=[COLOR=#0000ff]enp0s3[/COLOR]

eval  $(./eva_discover INTERFACE=[COLOR=#0000ff]$PC_LAN_IF[/COLOR]   FROM=[COLOR=#0000ff]$PC_IP[/COLOR] TO=[COLOR=#0000ff]$EVA_IP[/COLOR]  BLIP=1 WAIT=120 HOLD=0);nc [COLOR=#0000ff]$EVA_IP[/COLOR] 21

welche ich mit "sudo ./rettung" ausführe

allerdings landet es immer in einer "leeren" Befehlzeile

nicht direkt eindeutig eine Ursache zuordnen und somit auch keinen Aktionsplan ableiten,
so dass IMHO nur das Ausschlußverfahren von Fehlerquellen und weitere Analysen übrig bleibt.

Fragen:
1.) Welchen LAN-Port verwendest Du ?
==> hatte mal wo gelesen, dass LAN-Port-1 zu verwenden ist, alles andere USB, RF-Cabel ausstecken, bitte mal testen
2.) Media-Sensing/Auto-Sensing
==> nach meinem Stand verwendest Du ein Windows-Rechner als Hostsystem mit Ubuntu-VM
==> Bitte das Media-Sensing auf dem Windows-Host mal abschalten, idealerweise einen Hub zwischen FB6490 und PC schalten.
3.) Bootloader (HW-Defekt ???)
==> möchte mal sehen, ob die Ethernet-Schnittstelle des EVA-/ADAM2-Devices noch funktioniert, d.h. ARP-Requests schickt
==> Bitte hierzu den Ethernet-Traffic beim Booten mitschneiden, d.h. vor Power-ON der FB6490 folgenden Befehl in Ubuntu-VM eingeben ""tcpdump -s0 -i enp0s3 -w ./rettung.pcap"
anschließend kann Post-Analyse beginnen: z.B. "tcpdump -s0 -r ./rettung.pcap 'arp'"

 

[stoney]

Zu 1. LAN1 (allerdings habe ich auch alle anderen Ports ausprobiert) Es ist / war immer nur NT und 1LAN Kabel angeschlossen.

Zu 2. Ja das war gestern der Fall (habe jetzt eine Ubuntu Installation auf einer anderen HDD)

Zu 3.

$ sudo tcpdump -s0 -r ./rettung.pcap 'arp'
reading from file ./rettung.pcap, link-type EN10MB (Ethernet)
19:51:52.468258 ARP, Reply 192.168.178.2 is-at 90:e6:ba:06:4e:e1 (oui Unknown), length 28
19:51:55.147372 ARP, Request who-has 192.168.178.2 (Broadcast) tell 192.168.178.2, length 28

 

[Pokemon20021]

$ sudo tcpdump -s0 -r ./rettung.pcap 'arp'
reading from file ./rettung.pcap, link-type EN10MB (Ethernet)
19:51:52.468258 ARP, Reply 192.168.178.2 is-at 90:e6:ba:06:4e:e1 (oui Unknown), length 28
19:51:55.147372 ARP, Request who-has 192.168.178.2 (Broadcast) tell 192.168.178.2, length 28

eigentlich sollte sich IMHO der ATOM-Bootloader mit seinen 2 IP-Adressen 192.168.178.1 und 169.254.1.1 per ARP melden;
unklar was da los ist;

Sorry, aber außer "Serial Console" fällt bei bei diesem Fehlerbild momentan nichts mehr ein;
evtl. kann PeterPawn oder andere Sachkundige weitere Tips geben.

 

[stoney]

Trotzdem danke für deine Bemühungen

Wie genau meintest du das mit dem Hub dazwischen ? (Verbindung war in diesem Zeitpunkt direkt)
Sollte ich es nochmal mit einer FritzBox (welcher ich unter Heimnetz eine IP vergebe) dazwischen versuchen?

 

[PeterPawn]

@Pokemon20021:
Der Bootloader hat die 169.254.1.1 nur dann, wenn man ihn per Broadcast entsprechend einstellt. Eine "Notfall-IP" gibt es im Bootloader nicht.

@stoney0815:
Die FRITZ!Box mit dem Ubuntu-Rechner direkt verbinden und das LAN-Interface auf eine statische Konfiguration (sowohl statische IP-Adresse als auch direkt beim Systemstart zu aktivieren) stellen. Der Standard ist m.W. auch dort die dynamische Konfiguration und für die Benutzung von "eva_discover" (und das sollte man dann auch einfach mal einzeln aufrufen, damit man erst einmal weiß, ob die Box nun gefunden wird oder nicht) braucht es einen aktiven Adapter mit einer statischen IP-Adresse.

Dann ruft man "eva_discover" mit dem entsprechenden Interface auf (die Parameter sind im Kopf der Datei erläutert) und setzt dabei für "TO" eine Adresse, die zur eigenen Netzwerk-Karte paßt.

Bei einer 6490 war das mit dem "HOLD=1" früher mal problematisch, die Box mag kein "QUIT" für den FTP-Server - das ist aber im GitHub auch lange korrigiert und sollte kein Problem mehr darstellen. Abgesehen davon muß man ja auch nicht unbedingt mit "HOLD=1" arbeiten, wenn das nächste Kommando gleich danach folgt.

Ansonsten erzeugt der Aufruf von "eva_discover" auch entsprechende Ausgaben in der Console, die sollte man dann seinem "Fehlerbericht" auch hinzufügen ... und bitte als "CODE"-Kasten und nicht als Bildschirmfoto.

Ach so ... beim Start von "eva_discover" ist die FRITZ!Box zunächst mal "stromlos" und erst dann, wenn man die mittels "BLIP=1" angezeigten Broadcast-Pakete "sehen" kann, dann kriegt die Box Strom. Das ist zwar das normalste Vorgehen der Welt - ich bin mir aber ziemlich sicher, daß es immer noch an falscher Handhabung liegt und nicht an einer defekten Box.

Wobei man das Ganze ohnehin auch mit Windows machen könnte ... warum muß man denn mit einem Linux-System in einer VM unter Windows überhaupt anfangen?

Was passiert denn, wenn man das Recovery-Programm für die 7490 auf diese 6490 losläßt?

Irgendwie fehlen hier massenhaft Informationen ... ich bin mir nicht so ganz sicher, warum @Pokemon20021 auf die Idee kommt, der Bootloader könnte defekt sein. Bisher liegen einfach außer (sehr kurzen und wenig präzisen) Beschreibungen und der "Blinksequenz" praktisch keine Informationen vor.

Damit die handwerklichen Fehler minimiert werden, würde ich mich an Deiner Stelle zuerst mal für eine Plattform entscheiden und dann auch dort bleiben. Wenn das Windows ist, kannst Du mit einem "falschen Recovery-Programm" oder den PowerShell-Skripten aus dem Repository arbeiten oder meinetwegen auch mit den "ruKernelTool" ... wobei ich nicht so richtig verstanden habe, was Du mit dem "ruKernelTool" überhaupt an der 6490 zu suchen hattest - außer der Tatsache, daß Du es verwendet hast, findet ich keine "Begründung", was Du Dir davon versprochen hast.

Daß Dir auch der Aufbau der Box nicht so ganz klar zu sein scheint, hatten wir ja schon ... hast Du Dir denn diesen Hinweis zu Herzen genommen und Dich einfach mal etwas schlau gemacht?

 

[Pokemon20021]

ein Punkt zu "Ubuntu-VM" ist mir noch eingefallen:
die VM ist hostseitig schon im Netzwerk-Modus "Bridged Networking" konfiguriert ?
z.B. bei VirtualBox: https://www.thomas-krenn.com/de/wiki/Netzwerkkonfiguration_in_VirtualBox#Bridged_networking

sind die ftp-Befehle evtl. von Ubuntu-VM mit Netzwerk-Mode NAT abgeschickt worden ?

Allerdings hat sich an meinem Problem nichts geändert - es ist ein neues dazu gekommen - und zwar ist die Box per adam nicht mehr erreichbar

ftp 192.168.178.1
ftp: connect: Connection timed out
ftp >

und nun bin ich wieder passiver Mitleser.

EDIT: Frage zu NAT eingepflegt

 

[PeterPawn]

und nun bin ich wieder passiver Mitleser.

Das ist eigentlich die Rolle, die ich für mich vorgesehen hatte.

Vielleicht erbarmst Du Dich ja doch noch und fängst einfach noch einmal systematisch mit der (geführten) Suche an ... wenn Du mich nicht direkt angesprochen hättest, hätte ich (vermutlich) gar nichts weiter geschrieben.

Anstelle des "Hubs" zwischen FRITZ!Box und PC kann man auch irgendeinen "Switch" nehmen ... entscheidend ist der Punkt, daß die Verbindung zwischen PC und Switch bereits "bereit" ist und nicht erst beim Einstecken des Stroms für die FRITZ!Box das ganze Geraffel mit der Netzwerk-Konfiguration beginnt. Wobei das tatsächlich meist nur bei irgendwelchen Notebooks eine Rolle spielt, wo ein Treiber des Herstellers die Schnittstelle aus Stromspargründen abschaltet, solange kein Kabel drin steckt (und eine FRITZ!Box ohne Strom sieht auch wie ein fehlendes Kabel aus). In aller Regel kann man diese Treiber dann nur schlecht dazu überreden, auf diese Abschaltung zu verzichten ... da ist dann der Switch ein probates Mittel. Ob das eine zweite FRITZ!Box sein kann/sollte, hängt auch wieder vom konkreten Netz ab. Bei mir geht merkwürdigerweise ab und an die 7490 mal in die Knie, wenn in demselben Netz eine 6490 gerade startet ... die Ursache habe ich noch nicht gesucht, aber es ist (zumindest 50:50) reproduzierbar.

 

[Pokemon20021]

@PeterPawn: das Thema Reparieren einer "Verbogenen Fritzbox-Configuration" per "Neu-Initialisierung der TFFS-Partitionen" finde ich interessant; hierzu arbeite ich mich gerne in die YourFritz eva- und ttfs-Tools ein;

Da seitens TE die Ubuntu-VM schon für den Einsatz von "eva_get_environment, build_tffs_image, eva_store_tffs" verwendet wurde, war es für mich naheliegend auch das LINUX-Tools eva_discovery anstatt eines Windows-Tools ("falsches Recovery-Programm" oder PowerShell Befehle) zum Setzen der EVA-IP und "Unterbrechen des Bootvorganges per FTP-Login" zu verwenden.

etwaige Infrastruktur-Probleme waren im Vorfeld nicht erkennbar.
===================================================
Gibt es eine Möglichkeit ein per build_tffs_image erstelltes TFFS-Image zu prüfen bevor man es an den Bootloader per 'eva_store_tffs' "füttert" ? kann ich hier tlist verwenden ?

für das Tool eva_discovery hätte ich folgende Verbesserungsvorschlag:

freetz@Pi2:~$ diff eva_discover.org eva_discover
289c289,290
<       echo "\"$socat\" utility couldn't be found or isn't executable." 1>&2
---
>       #echo "\"$socat\" utility couldn't be found or isn't executable." 1>&2
>       echo "socat utility couldn't be found or isn't executable." 1>&2
freetz@Pi2:~$

Hintergrund: wenn das socat Programm nicht gefunden wird, dann wird die Variable socat auf "" gesetzt

###########################################################################
#
# check, if a suitable "socat" utility is available
#
###########################################################################
if [ $socat_set -ne 1 ]; then
[COLOR=#0000ff]        socat="$(which socat)"
[/COLOR]        if [ $? -eq 127 ]; then
                orgifs="$IFS"
                IFS=:
                set -- $PATH
                IFS="$orgifs"
                socat="socat"
                while [ ${#1} -gt 0 ]; do
                        if [ -x $1/$socat ]; then
                                socat="$1/$socat"
                                break
                        fi
                done
        fi
fi
if [ ! -x "$socat" ]; then
        echo "[COLOR=#ff0000]\"$socat\"[/COLOR] utility couldn't be found or isn't executable." 1>&2
        exit 1
fi
############################################################################

siehe auch Fehlermeldung gestern:

Allerdings bekomme ich

"" utility couldn't be found or isn't executable.

 

[stoney]

Die FRITZ!Box mit dem Ubuntu-Rechner direkt verbinden und das LAN-Interface auf eine statische Konfiguration (sowohl statische IP-Adresse als auch direkt beim Systemstart zu aktivieren) stellen. Der Standard ist m.W. auch dort die dynamische Konfiguration und für die Benutzung von "eva_discover" (und das sollte man dann auch einfach mal einzeln aufrufen, damit man erst einmal weiß, ob die Box nun gefunden wird oder nicht) braucht es einen aktiven Adapter mit einer statischen IP-Adresse


Ansonsten erzeugt der Aufruf von "eva_discover" auch entsprechende Ausgaben in der Console, die sollte man dann seinem "Fehlerbericht" auch hinzufügen ... und bitte als "CODE"-Kasten und nicht als Bildschirmfoto.

Ach so ... beim Start von "eva_discover" ist die FRITZ!Box zunächst mal "stromlos" und erst dann, wenn man die mittels "BLIP=1" angezeigten Broadcast-Pakete "sehen" kann, dann kriegt die Box Strom. Das ist zwar das normalste Vorgehen der Welt - ich bin mir aber ziemlich sicher, daß es immer noch an falscher Handhabung liegt und nicht an einer defekten Box.

Was passiert denn, wenn man das Recovery-Programm für die 7490 auf diese 6490 losläßt?

Irgendwie fehlen hier massenhaft Informationen ... ich bin mir nicht so ganz sicher, warum @Pokemon20021 auf die Idee kommt, der Bootloader könnte defekt sein. Bisher liegen einfach außer (sehr kurzen und wenig präzisen) Beschreibungen und der "Blinksequenz" praktisch keine Informationen vor.

Damit die handwerklichen Fehler minimiert werden, würde ich mich an Deiner Stelle zuerst mal für eine Plattform entscheiden und dann auch dort bleiben. Wenn das Windows ist, kannst Du mit einem "falschen Recovery-Programm" oder den PowerShell-Skripten aus dem Repository arbeiten oder meinetwegen auch mit den "ruKernelTool" ... wobei ich nicht so richtig verstanden habe, was Du mit dem "ruKernelTool" überhaupt an der 6490 zu suchen hattest - außer der Tatsache, daß Du es verwendet hast, findet ich keine "Begründung", was Du Dir davon versprochen hast.

Feste IP ist bei Ubuntu gestezt.

Fehler von eva_discover

sudo ./rettung[sudo] Passwort für stoney: 
Sending broadcast packets: 2016/12/21 22:11:40 socat[3390] E bind(6, {AF=2 192.168.178.2:0}, 16): Cannot assign requested address
2016/12/21 22:11:40 socat[3389] E bind(5, {AF=2 192.168.178.2:5035}, 16): Cannot assign requested address
stoney@stoney-K50AB:~/Schreibtisch/YourFritz-master/eva_tools$ sudo ./rettung
[COLOR=#ff0000]boot sequence interrupted[/COLOR]
stoney@stoney-K50AB:~/Schreibtisch/YourFritz-master/eva_tools$ sudo ./rettung
Sending broadcast packets: 2016/12/21 22:21:49 socat[7731] E bind(5, {AF=2 192.168.178.2:5035}, 16): Cannot assign requested address
2016/12/21 22:21:49 socat[7732] E bind(6, {AF=2 192.168.178.2:0}, 16): Cannot assign requested address
stoney@stoney-K50AB:~/Schreibtisch/YourFritz-master/eva_tools$ sudo ./rettung
Sending broadcast packets: 2016/12/21 22:21:56 socat[9413] E bind(6, {AF=2 192.168.178.2:0}, 16): Cannot assign requested address
2016/12/21 22:21:56 socat[9412] E bind(5, {AF=2 192.168.178.2:5035}, 16): Cannot assign requested address
stoney@stoney-K50AB:~/Schreibtisch/YourFritz-master/eva_tools$ sudo ./rettung
Sending broadcast packets: ..2016/12/21 22:24:17 socat[11168] E sendto(6, 0x23d5260, 16, 0, AF=2 255.255.255.255:5035, 16): Invalid argument
................................................................................stoney@stoney-K50AB:~/Schreibtisch/YourFritz-master/eva_tools$ sudo ./rettung
Sending broadcast packets: 2016/12/21 22:28:45 socat[13205] E bind(5, {AF=2 192.168.178.2:5035}, 16): Cannot assign requested address
2016/12/21 22:28:45 socat[13206] E bind(6, {AF=2 192.168.178.2:0}, 16): Cannot assign requested address
stoney@stoney-K50AB:~/Schreibtisch/YourFritz-master/eva_tools$ sudo ./rettung
stoney@stoney-K50AB:~/Schreibtisch/YourFritz-master/eva_tools$

Recoverprogramm der 7490 findet die Box nicht - der Rukernel kam erst zum Einsatz als die Box nach dem TFFS schreibens nicht mehr erreichbar war und aktuell auch immer noch nicht ist. (da ich hoffte, das ich über den rukernel nochmals in die envs rein schauen könnte um ggf. anhand diesen direkt einen Fehler zu erkennen)

Welche weiteren Infos fehlen denn ? - ich würde diese natürlich gerne liefern (allerdings gebe ich zu, habe ich mich noch nicht so viel und intensiv wie man anderer hier damit beschäftigt, bin aber gewillt alles von mir verlange umzusetzen um Fakten, die nötig sind, liefern zu können)

 

[Pokemon20021]

@stoney0815:
könntest Du noch Bitte Rückmeldung zu den Frage #36 geben
idealerweise auch mit Angabe der Virtualisierungs-Software.

Bitte auch die Meldungen "Recoverprogramm der 7490 findet die Box nicht", einfach Copy&Paste in CODE-Tags
dann sieht man mehr.