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

[stoney]

Habe heute alles nochmal über eine eigenständige installierte Instanz wiederholt mit dem selben Ergebnis.
Als NAT lief das Netzwerkinterface allerdings nicht.

Habe vorhin ja das 7490 recover unter W7 auf die 6490 los gelassen (nur die LAN Verbindung von W7 aktiv, WLAN sowie beide VM Interfaces waren disabled sowie MediaSensing)

Würde morgen den. "Log" vom Recovery posten (auf 192.168.178.1 sowie auf 0.0.0.0 keine Reaktion aber #code# folgt noch)

 

[Pokemon20021]

Vorschlag für Umgebung:
Als Umgebung schlage ich vor den PC und die FB6490 an die "3272 FW 6.50 (IP-Client)" zu hängen; damit sind etwaige Probleme mit MediaSensing/Auto-Neg proaktiv aus der Welt; IP der FB3272 muß konfliktfrei zu PC, Ubuntu-VM und EVA_IP sein;
PC fest eingestellt z.B. auf IP=192.168.178.11
Ubuntu-VM muß seitens Virtualisierungs-Software im Netzwerk-Modus "Bridged Network" betrieben werden, sonst kommen die Broadcast-Pakete nicht an FB6490 an; bitte Ubuntu-VM mit IP=192.168.178.2 betreiben

und dann Tests (eva_discover, ...) nochmals durchführen und sämtlich Outputs posten.

Frage: Welche Umgebung und Tool hast Du den früher (vor eva_store_tffs) verwendet, als der Zugriff auf das EVA/ADAM2-Device noch funktionierte ?

 

[PeterPawn]

Die Fehlermeldung vom "socat" deutet ja eher darauf hin, daß da der Netzwerkkarte nicht die Adresse 192.168.178.2 zugewiesen ist.

Auch kann man sich unter "rettung" ja nun alles mögliche vorstellen ... wie wäre es denn mit einem passenden Aufruf von "eva_discover"? Ansonsten wäre auch mal die Anzeige der Netzwerk-Konfiguration nützlich, dann muß man bzgl. der verwendeten IP-Adressen nicht raten.

 

[Pokemon20021]

Auch kann man sich unter "rettung" ja nun alles mögliche vorstellen ... wie wäre es denn mit einem passenden Aufruf von "eva_discover"? Ansonsten wäre auch mal die Anzeige der Netzwerk-Konfiguration nützlich, dann muß man bzgl. der verwendeten IP-Adressen nicht raten.

das Skript "rettung" wurde von TE in #28 eingeführt; die Netzwerk-Configuration ist in #28 als Attachment seitens TE beigefügt.

Die Fehlermeldung vom "socat" deutet ja eher darauf hin, daß da der Netzwerkkarte nicht die Adresse 192.168.178.2 zugewiesen ist.

@stoney0815: Hat sich an Netzkonfig der Ubuntu-VM da was gegenüber #28 geändert ?
welche Virtualisierungs-Software hast Du denn ? VMware-Player, ..., ??? http://www.com-magazin.de/praxis/virtualisierung/virtualbox-vmware-player-hyper-v-460656.html
welchen Netzwerk-Modi hast Du eingestellt ? "Nicht NAT", aber was genau ?
es ist für einen Helfswilligen sehr ermüdend, wenn man den Informationen mehrfach hinterher hechten muß :-(

- - - Aktualisiert - - -

Habe heute alles nochmal über eine eigenständige installierte Instanz wiederholt mit dem selben Ergebnis.
Als NAT lief das Netzwerkinterface allerdings nicht.

Nun habe ich die Info gefunden: bei der Virtualisierungs-Software handelt sich um "Oracle VM VirtualBox"
siehe: http://www.ip-phone-forum.de/attachment.php?attachmentid=88508&d=1482269357

aber welcher Netzwerk-Modus/Netzwerktyp kann ich mir unter "Als NAT lief das Netzwerkinterface allerdings nicht." vorstellen ?
es wurde doch explizit nach "Bridged Networking gefragt"

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

evtl. "internal networking" ?
es gibt 6 Modi bei VirtualBox!!! und nur "Bridged networking" funktioniert bei "eva_discovery"
https://www.thomas-krenn.com/de/wiki/Netzwerkkonfiguration_in_VirtualBox#Bridged_networking

Netzwerktyp	Zugriff Gast -> andere Gäste	Zugriff Host -> Gast	Zugriff Gast -> externes Netzwerk
Not attached
Network Address Translation (NAT)
Network Address Translation Service
Bridged networking
Internal networking
Host-only networking

[TH="bgcolor: #FFCCCC, align: center"]-[/TH]
[TH="bgcolor: #FFCCCC, align: center"]-[/TH]
[TH="bgcolor: #FFCCCC, align: center"]-[/TH]

[TH="bgcolor: #FFCCCC, align: center"]-[/TH]
[TH="bgcolor: #FFCCCC, align: center"]-[/TH]
[TH="bgcolor: #CCFFCC, align: center"]✔[/TH]

[TH="bgcolor: #CCFFCC, align: center"]✔[/TH]
[TH="bgcolor: #FFCCCC, align: center"]-[/TH]
[TH="bgcolor: #CCFFCC, align: center"]✔[/TH]

[TH="bgcolor: #CCFFCC, align: center"]✔[/TH]
[TH="bgcolor: #CCFFCC, align: center"]✔[/TH]
[TH="bgcolor: #CCFFCC, align: center"]✔[/TH]

[TH="bgcolor: #CCFFCC, align: center"]✔[/TH]
[TH="bgcolor: #FFCCCC, align: center"]-[/TH]
[TH="bgcolor: #FFCCCC, align: center"]-[/TH]

[TH="bgcolor: #CCFFCC, align: center"]✔[/TH]
[TH="bgcolor: #CCFFCC, align: center"]✔[/TH]
[TH="bgcolor: #FFCCCC, align: center"]-[/TH]

es wäre toll, wenn die angefragten Informationen #36 geliefert würden;
muß nun mal auf Weihnachtsmarkt;-)

 

[PeterPawn]

das Skript "rettung" wurde von TE in #28 eingeführt

Es macht wenig Sinn, wenn man sich die Informationen Stück für Stück zusammensuchen muß und Du hast im weiteren Verlauf des Beitrags ja dann auch festgestellt, daß es sich beim "Foto" in #28 um die VM gehandelt hatte.

Die Fehlermeldung vom "socat" (die m.W. auch "neu" ist und in der VM ja wohl nicht auftrat):

2016/12/21 22:21:49 socat[7732] E bind(6, {AF=2 192.168.178.2:0}, 16): Cannot assign requested address

läßt jedenfalls wenig Spielraum für Mißverständnisse - auch wenn die mal mit Port 0 (das dürfte der "Sender" sein) und mal mit Port 5035 (das sollte der "Listener" sein) auftaucht.

Ich möchte (wenn ich bei der Fehlersuche behilflich sein soll) den direkten Aufruf von "eva_discover" sehen und keinen, der durch ein darum herumgebautes "eval" seinen STDOUT-Deskriptor in irgendeine Pipe umgeleitet hat - insofern interessiert mich der Rest in "rettung" nicht - zumindest solange nicht, wie nicht ein unmittelbar vor dem Aufruf erfolgendes "cat rettung" mir den tatsächlich verwendeten Inhalt der Datei zeigt (das gilt auch für ein "ifconfig" bzw. ein "ip a"). Schon ein "Mißverständnis" beim Übergang von der VM auf die Linux-Installation "auf dem Blech" kann zu vollkommen unnötigem Aufwand führen (mal vollkommen abgesehen von der Notwendigkeit, die Informationen Stück für Stück aus mehreren Beiträgen zusammenzusuchen, wofür es ebenfalls keinen nachvollziehbaren Grund gibt).

Spätestens dann, wenn man den "normalen" Aufruf durch "bash -x <scriptname>" ersetzen willl für eine Debug-Ausgabe des Skripts, wird es ohnehin nötig, den Aufruf mal "von Hand" auszuführen und wenn man bereits festgestellt hat, daß eine "Zusammenfassung" mehrerer Aufrufe in Form eines eigenen Skriptes nicht funktioniert, dann geht man ohnehin "zu den Wurzeln" zurück und probiert erst einmal, ob die verwendeten Bausteine überhaupt wie erwartet funktionieren.

 

[Pokemon20021]

Die Fehlermeldung vom "socat" (die m.W. auch "neu" ist und in der VM ja wohl nicht auftrat):

2016/12/21 22:21:49 socat[7732] [COLOR=#ff0000]E bind(6, {AF=2 192.168.178.2:0}, 16): Cannot assign requested address[/COLOR]

läßt jedenfalls wenig Spielraum für Mißverständnisse

nachdem ich frische Luft und etwas "heißen Traubensaft" inhaliert habe, starte ich hier nochmal;

diese Fehlermeldung "bind ... Cannot assign requested address" bedeutet nach meiner Ansicht, dass die Ubuntu-VM keine lokale IP-Adresse 192.168.178.2 im IP-Stack für das Programm socat vorfindet und deshalb entteuscht diese Fehlermeldung auswirft; d.h. es liegt ein "handwerkliches Problem" vor.

@stoney0815:
Bitte mal die IP-Settings Schnittstelle enp0s3 der Ubuntu-VM prüfen

# ifconfig
# ip address

und ggf. richtigstellen (feste IP=192.168.178.2),

Weitere Aktivitäten:

• VBox-Einstellung "Bridged Networking" kontrollieren und ggf. richtigstellen, so dass die Ubuntu-VM die FB6490 per Broadcast ohne Router/NAT erreichen kann
• etwaige Firewalls/Security-Suites auf Hostsystem (Win7) ggf. temp. deaktivieren.
• Direkte Verbindung zw. PC und FB6490 mit MediaSense=disabled herstellen oder Switch/Hub/FritzBox-mit-IP-Client Modus dazwischen schalten
• direkter Aufruf von "eva_discovery" ohne Wrapper-Skript "rettung", ferner ohne "eval-Variablenzuweisung"
  

  # bash ./eva_discover INTERFACE=enp0s3 FROM=192.168.178.2 TO=192.168.178.1 BLIP=1 WAIT=120 HOLD=0

  dann sollte der Output
  

  Sending broadcast packets: ................

  erscheinen
• nun die FB6490 einschalten (Power-ON)
• Bitte Consolenoutput bis "EVA_FOUND=1 EVA_IP=192.168.178.1" oder "EVA_FOUND=0" posten

 

[stoney]

Sorry Leute für die Umstände.

Ich würde gerne schnellstmöglich alle relevanten Informationen liefern (auch wenn der passende "Befehl" vorgekaut werden muss - ich gelobe Besserung und versuche mich weiter in Linux sowie dem FritzBoxSystem einzuarbeiten - etwas Linuxkenntnisse (Debian) sind vorhanden.

Ich habe mir eine Ubuntu Installation auf einer seperaten HDD erstellt über welche ich aktuell arbeite - KEINE VM mehr.

Hier die zuletzt erfragten Ausgaben

./eva_discover INTERFACE=enp3s0 FROM=192.168.178.2 TO=192.168.178.1 BLIP=1 WAIT=120 HOLD=0
Sending broadcast packets: .....................................................
EVA_FOUND=1
EVA_IP=192.168.178.1


ifconfig 
enp3s0    Link encap:Ethernet  Hardware Adresse xxxxxxxx 
          inet Adresse:192.168.178.2  Bcast:192.168.178.255  Maske:255.255.255.0
          inet6-Adresse: fe80::92e6:baff:fe06:4ee1/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST MULTICAST  MTU:1500  Metrik:1
          RX-Pakete:7 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
          TX-Pakete:121 Fehler:0 Verloren:0 Überläufe:0 Träger:0
          Kollisionen:0 Sendewarteschlangenlänge:1000 
          RX-Bytes:420 (420.0 B)  TX-Bytes:11514 (11.5 KB)

lo        Link encap:Lokale Schleife  
          inet Adresse:127.0.0.1  Maske:255.0.0.0
          inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
          UP LOOPBACK RUNNING  MTU:65536  Metrik:1
          RX-Pakete:3492 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
          TX-Pakete:3492 Fehler:0 Verloren:0 Überläufe:0 Träger:0
          Kollisionen:0 Sendewarteschlangenlänge:1 
          RX-Bytes:258774 (258.7 KB)  TX-Bytes:258774 (258.7 KB)

wlp4s0    Link encap:Ethernet  Hardware Adresse xxxxxxxx 
          inet Adresse:192.168.178.50  Bcast:192.168.178.255  Maske:255.255.255.0
          inet6-Adresse: fe80::e502:9ee7:7800:4e8a/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX-Pakete:2542 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
          TX-Pakete:216 Fehler:0 Verloren:0 Überläufe:0 Träger:0
          Kollisionen:0 Sendewarteschlangenlänge:1000 
          RX-Bytes:1348431 (1.3 MB)  TX-Bytes:37385 (37.3 KB)

Verbindung wurde wie folgt aufgebaut:

LAN an 3370 LAN2 (switch - nur HeimnetzIpZugewisen) - 3370 LAN1 an 6490 LAN1

Ich hoffe ihr habt noch Nerven auf mich

PS: ich habe vorerst absichtlich mit den in den vorherigen Posts gefragen Angaben eingegangen, da es ja jetzt, scheinbar, nach der richtigen Handhabung zumindest (sry noch mal) ein korrektes Ergebnis liefert. (falls dies oder noch weiter Angaben von Nöten sind, werde ich dies nachholen / erledigen)


PPS: auf meine dumme Frage. ob die die 7490 ins Gehäuse der 6490 passt war natürlich unüberlegt (DSL - Koaxial ?!) - allerdings passen die "Oberteile" der (6/7) 490 auf die "Unterteile" und somit kann man die Farbe ändern.

 

[Pokemon20021]

./eva_discover INTERFACE=enp3s0 FROM=192.168.178.2 TO=192.168.178.1 BLIP=1 WAIT=120 HOLD=0
Sending broadcast packets: .....................................................
[COLOR=#0000ff]EVA_FOUND=1
EVA_IP=192.168.178.1[/COLOR]

das ist ja SUPER!!!
der Bootloader lebt und ist erreichbar;

Bitte nun mal Bootloader-Environment auslesen:

./eva_discover INTERFACE=enp3s0 FROM=192.168.178.2 TO=192.168.178.1 BLIP=1 WAIT=120 HOLD=0; nc 192.168.178.1 21;

wenn "220 ADAM2 FTP Server ready" erscheint, dann "RETR env" eingeben und Output posten (MAC-Addressen, wlan-key, serien-nummer anonymisieren);

ifconfig
wlp4s0    Link encap:Ethernet  Hardware Adresse 00:25:d3:6c:e8:40  
          inet Adresse:192.168.178.50  Bcast:192.168.178.255  Maske:255.255.255.0
          inet6-Adresse: fe80::e502:9ee7:7800:4e8a/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX-Pakete:2542 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
          TX-Pakete:216 Fehler:0 Verloren:0 Überläufe:0 Träger:0
          Kollisionen:0 Sendewarteschlangenlänge:1000 
          RX-Bytes:1348431 (1.3 MB)  TX-Bytes:37385 (37.3 KB)

Bitte das WLAN-Interface auf Ubuntu-PC deaktivieren, nicht dass hier noch Interaktionen (zwei Netzwerk-Interfaces im gleichen Subnetz ...) auftreten.

EDIT: Hinweis zu "RETR env":

Bei "RETR env" (muß m.W. auch unter "MEDIA SDRAM"-Bedingung aufgerufen werden, sonst mag der Bootloader gar kein RETR-Kommando, das könnte aber vom Loader abhängen)

also:

$ [COLOR=#0000ff]ftp 192.168.178.1[/COLOR]
220 ADAM2 FTP Server ready
[COLOR=#0000ff]USER adam2[/COLOR]
331 Password required for adam2
[COLOR=#0000ff]PASS adam2[/COLOR]
230 User adam2 successfully logged in
[COLOR=#0000ff]SYST[/COLOR]
215 AVM EVA Version 1.1964 0x0 0x740D
[COLOR=#0000ff]TYPE I[/COLOR]
200 Type set to BINARY
[COLOR=#0000ff]MEDIA SDRAM[/COLOR]
200 Media set to MEDIA_SDRAM
[COLOR=#0000ff]P@SW[/COLOR]
227 Entering Passive Mode (192,168,178,1,12,8)
[COLOR=#0000ff]RETR env[/COLOR]
150 Opening BINARY data connection
226 Transfer complete
[COLOR=#0000ff]BYE
[/COLOR]221 Thank you for using the FTP service on ADAM2
221 Goodbye.

 

[stoney]

Bitte nun mal Bootloader-Environment auslesen:

./eva_discover INTERFACE=enp3s0 FROM=192.168.178.2 TO=192.168.178.1 BLIP=1 WAIT=120 HOLD=0; nc 192.168.178.1 21;

sudo ./eva_discover INTERFACE=enp3s0 FROM=192.168.178.2 TO=192.168.178.1 BLIP=1 WAIT=120 HOLD=0; nc 192.168.178.1  21;
EVA_FOUND=1
EVA_IP=192.168.178.1

ifconfig 

enp3s0    Link encap:Ethernet  Hardware Adresse 90:e6:ba:06:4e:e1  
          inet Adresse:192.168.178.2  Bcast:192.168.178.255  Maske:255.255.255.0
          inet6-Adresse: fe80::92e6:baff:fe06:4ee1/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX-Pakete:44 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
          TX-Pakete:280 Fehler:0 Verloren:0 Überläufe:0 Träger:0
          Kollisionen:0 Sendewarteschlangenlänge:1000 
          RX-Bytes:6263 (6.2 KB)  TX-Bytes:27587 (27.5 KB)

lo        Link encap:Lokale Schleife  
          inet Adresse:127.0.0.1  Maske:255.0.0.0
          inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
          UP LOOPBACK RUNNING  MTU:65536  Metrik:1
          RX-Pakete:4256 Fehler:0 Verloren:0 Überläufe:0 Fenster:0
          TX-Pakete:4256 Fehler:0 Verloren:0 Überläufe:0 Träger:0
          Kollisionen:0 Sendewarteschlangenlänge:1 
          RX-Bytes:306740 (306.7 KB)  TX-Bytes:306740 (306.7 KB)

Leider komme ich nicht bis zu "RETR env"

 

[Pokemon20021]

Bitte mal nach "eva_discover" und "EVA_FOUND=1"-Output direkt mit ftp-Client testen:

$ [COLOR=#0000ff]ftp 192.168.178.1[/COLOR]
220 ADAM2 FTP Server ready
[COLOR=#0000ff]USER adam2[/COLOR]
331 Password required for adam2
[COLOR=#0000ff]PASS adam2[/COLOR]
230 User adam2 successfully logged in
[COLOR=#0000ff]SYST[/COLOR]
215 AVM EVA Version 1.1964 0x0 0x740D
[COLOR=#0000ff]TYPE I[/COLOR]
200 Type set to BINARY
[COLOR=#0000ff]MEDIA SDRAM[/COLOR]
200 Media set to MEDIA_SDRAM
[COLOR=#0000ff]P@SW[/COLOR]
227 Entering Passive Mode (192,168,178,1,12,8)
[COLOR=#0000ff]RETR env[/COLOR]
150 Opening BINARY data connection
226 Transfer complete
[COLOR=#0000ff]BYE
[/COLOR]221 Thank you for using the FTP service on ADAM2
221 Goodbye.

 

[stoney]

ftp 192.168.178.1
ftp: connect: Connection timed out
ftp>

 

[Pokemon20021]

das ist seltsam;
hast Du den FTP-Befehl evtl. zu spät (d.h. nicht im 5 sec Zeitfenster) abgesetzt ?

Frage: Liefert der Befehl

./eva_discover INTERFACE=enp3s0 FROM=192.168.178.2 TO=192.168.178.1 BLIP=1 WAIT=120 HOLD=0; [COLOR=#0000FF]nc 192.168.178.1 21[/COLOR];

die Ausgabe "220 ADAM2 FTP Server ready" ?

 

[stoney]

Der FTP Befehl wurde 10 mal versucht anzuwenden ( Box noch stromlos 1,2,3,4,5,6,7,8,9, sek. nach "strom an" ) und funktionierte ja sonst auch immer - nur nicht nach dem TFFS schreiben - ich denke daran wird es nicht in der "Handarbeit" liegen.

./eva_discover INTERFACE=enp3s0 FROM=192.168.178.2 TO=192.168.178.1 BLIP=1 WAIT=120 HOLD=0; nc 192.168.178.1 21;
EVA_FOUND=1
EVA_IP=192.168.178.1
stoney@stoney-K50AB:~/Schreibtisch/YourFritz-master/eva_tools$

 

[PeterPawn]

Jetzt mal ohne das angehangene "nc"-Kommando und stattdessen mit HOLD=1 ... dann sollte die Box "endlos" im Bootloader stehen bleiben (Power blinkt langsam vor sich hin).

Erst wenn das funktioniert, dann noch einmal den FTP-Aufruf danach absetzen (die Box steht ja noch in "Empfängnisbereitschaft"), wobei man dafür auch "eva_get_environment" verwenden kann - auch ein FTP-Client kann u.U. schon mal etwas mehr machen, als man eigentlich erwartet (das geht beim Versuch des automatischen Logins per .netrc schon los).

Wenn der Bootloader auf den Broadcast reagiert und die passende IP-Adresse zurückmeldet (die ausgegebene Adresse nach "EVA_IP" wird ja aus dem Antwortpaket extrahiert und nicht einfach von den Parametern übernommen), dann wäre es schon extrem komisch, wenn im Anschluß der FTP-Server im Bootloader nicht funktionieren soll.

 

[stoney]

./eva_discover INTERFACE=enp3s0 FROM=192.168.178.2 TO=192.168.178.1 BLIP=1 WAIT=120 HOLD=1
EVA_FOUND=1
EVA_IP=192.168.178.1
[B]boot sequence interrupted[/B]

 

[Pokemon20021]

Bitte mal

bash ./eva_get_environment env 192.168.178.1 > /tmp/env.txt

eingeben.
wenn das fehlerfrei durchgelaufen ist, dann sollte dort der Output des FTP-Befehls "RETR env" in der Datei /tmp/env.txt enthalten sein;

ls -la /tmp/env.txt
strings /tmp/env.txt

eingeben und Output posten (MAC-Addressen, wlan-key, serien-nummer anonymisieren);

Bei etwaigen Problemen Bitte das Logfile;

cat eva_get_environment_session.log

sowie Debug-Output generieren

bash -x ./eva_get_environment env 192.168.178.1 > /tmp/env.txt

und posten.

Hinweis:
hier noch Requirement-Checks nach neu installiertem Umgebung (#47: Ubuntu auf HDD neu installiert):
nicht vergessen:
1.) von Dash auf Bash umzuschalten:

Damit die scripte fehlerfrei arbeiten sollte man vorab überprüfen welche shell sich hinter /bin/sh verbirgt. ls -al /bin/sh sollte möglichst ein link auf bash sein. Unter Debian/Ubuntu hilft ein sudo dpkg-reconfigure dash mit [x]NO auf default shell.

Kontrolle:

freetz@Pi2:~$ ls -la /bin/sh
lrwxrwxrwx 1 root root Dez 10 08:59 /bin/sh -> [COLOR=#0000ff]bash[/COLOR]
freetz@Pi2:~$

Alternativ (von mir nicht empfohlen) kann man Skripte anpassen:

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.

2.) auf richtige "nc" Version prüfen:

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.

Kontrolle:

freetz@Pi2:~$ [COLOR=#0000ff]dpkg -l | grep netcat[/COLOR]
ii  [COLOR=#0000ff]netcat-openbsd[/COLOR]                        1.105-7                                   armhf        TCP/IP swiss army knife
freetz@Pi2:~$

3.) Suchpfad
eine Anpassung des Suchpfades ist nach meinem Stand bei neueren YourFritz-Version nicht mehr erforderlich:

Auserdem sollte man sicher gehen dass "." in der PATH variable ist (PATH=$PATH:. oder set path=($path .) ).

Kontrolle:
Beispiel von meinem RasPI

freetz@Pi2:~$ [COLOR=#0000ff]echo $PATH
[/COLOR]/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
freetz@Pi2:~$

Bei Problemen einfach die Kontrollbefehle eingeben und posten, dann tut man sich bei Ferndiagnose leichter.


EDIT:
Requirement-Check 3.) Suchpfad eingefügt
Korrektur Logfiledateiname eva_get_environment.log ==> eva_get_environment_session.log (Hinweis von stoney0815 aus #57)

 

[stoney]

Bitte mal

bash ./eva_get_environment env 192.168.178.1 > /tmp/env.txt

eingeben.

/tmp/env.txt wird erstellt aber nicht befüllt

Bei etwaigen Problemen Bitte das Logfile;

cat ./eva_get_environment.log

du meintest eva_get_environment_session.log ? - dies bleibt auch leer

sowie Debug-Output generieren

bash -x ./eva_get_environment env 192.168.178.1 > /tmp/env.txt

und posten.

bash -x ./eva_get_environment env 192.168.178.1 > /tmp/env.txt 
+ box_ip=192.168.178.1
+ box_port=21
+ box_user=adam2
+ box_pass=adam2
+ '[' x '!=' x0 -a x '!=' x1 ']'
+ subsys_id=
+ passive_ftp=P@SW
+ '[' 0 -eq 0 ']'
+ TMP=/tmp
++ date +%s
+ tmpdir=/tmp/tmp_1482485243_2657
+ writefifo=/tmp/tmp_1482485243_2657/write
+ readfifo=/tmp/tmp_1482485243_2657/read
+ storefifo=/tmp/tmp_1482485243_2657/store
+ outstream=7
+ instream=8
+ upstream=9
+ logstream=3
+ logfile=eva_get_environment_session.log
+ envfile=/tmp/tmp_1482485243_2657/env
+ startaddress=0x80000000
+ mkfifo
+ '[' 1 -eq 127 ']'
+ nc
+ '[' 1 -eq 127 ']'
+ mkdir -p /tmp/tmp_1482485243_2657
+ mkfifo /tmp/tmp_1482485243_2657/write
+ rc=0
+ '[' 0 -ne 0 ']'
+ mkfifo /tmp/tmp_1482485243_2657/read
+ rc=0
+ '[' 0 -ne 0 ']'
+ mkfifo /tmp/tmp_1482485243_2657/store
+ rc=0
+ '[' 0 -ne 0 ']'
+ eval 'exec 7<>/tmp/tmp_1482485243_2657/write'
++ exec
+ rc=0
+ '[' 0 -ne 0 ']'
+ eval 'exec 8<>/tmp/tmp_1482485243_2657/read'
++ exec
+ rc=0
+ '[' 0 -ne 0 ']'
+ eval 'exec 3<>eva_get_environment_session.log'
++ exec
+ rc=0
+ '[' 0 -ne 0 ']'
+ control_connection=2665
+ data_connection=
++ read_ftp_response 8 3
++ local 'line=   -' rc=0 instream=8 log=3
++ read -u 8 -r line
+ nc 192.168.178.1 21

Die erstellten files " read / store / write " sind ebenfalls leer.

Hinweis:
nach neu installiertem Ubuntu auf HDD nicht vergessen auch von Dash auf Bash umzuschalten:

freetz@Pi2:~$ ls -la /bin/sh
lrwxrwxrwx 1 root root Dez 10 08:59 /bin/sh -> bash
freetz@Pi2:~$

ls -la /bin/sh
lrwxrwxrwx 1 root root 4 Dez 23 10:19 /bin/sh -> bash

Die scripte hatte ich vorher alle auf /bin/bash umgeschrieben

sowie auf richtige "nc" Version prüfen:

freetz@Pi2:~$ dpkg -l | grep netcat
ii  netcat-openbsd                        1.105-7                                   armhf        TCP/IP swiss army knife
freetz@Pi2:~$

 dpkg -l | grep netcat
ii  netcat-openbsd                             1.105-7ubuntu1                                              amd64        TCP/IP swiss army knife

 

[Pokemon20021]

bash -x ./eva_get_environment env 192.168.178.1 > /tmp/env.txt 
SNIP
+ data_connection=
++ read_ftp_response 8 3
++ local 'line=   -' rc=0 instream=8 log=3
++ read -u 8 -r line
+ nc 192.168.178.1 21

ich denke da brauchen wir den Entwickler (PeterPawn) ;-)

@stoney0815: den Logfiledateiname eva_get_environment.log ==> eva_get_environment_session.log habe ich in #56 korrigiert

für mich sieht es nach Problem bei Skriptausführung eva_discover in Line 201 aus:
nc $box_ip $box_port <&$outstream >&$instream 2>/dev/null &

für weitere Diagnose wäre IMHO ein "Port-Check" per Befehl "nmap -p 21 192.168.178.1" ein Ansatzpunkt,
ggf. kann PeterPawn helfen.

 

[stoney]

für weitere Diagnose wäre IMHO ein "Port-Check" per Befehl "nmap -p 21 192.168.178.1" ein Ansatzpunkt,
ggf. kann PeterPawn helfen.

stoney@stoney-K50AB:~$ nmap -p 21 192.168.178.1

Starting Nmap 7.01 ( https://nmap.org ) at 2016-12-23 11:55 CET
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 0.07 seconds
stoney@stoney-K50AB:~$ nmap -Pn 21 192.168.178.1

Starting Nmap 7.01 ( https://nmap.org ) at 2016-12-23 11:56 CET
Nmap scan report for 21 (0.0.0.21)
Host is up (0.0000050s latency).
All 1000 scanned ports on 21 (0.0.0.21) are filtered

Nmap scan report for 192.168.178.1
Host is up (0.0000050s latency).
All 1000 scanned ports on 192.168.178.1 are filtered

Nmap done: 2 IP addresses (2 hosts up) scanned in 13.11 seconds

 

[PeterPawn]

Das sieht so aus, als würde der FTP-Server der Box keine Antworten senden.

Ich kenne zwar die Quellen des Bootloaders auch nicht ... aber wenn ich raten sollte und tatsächlich "alles richtig gemacht" wird, würde ich auf ein total leeres Environment tippen (vielleicht hat ja jemand die Box doch mit dem "ruKernelTool" und "Clear MTD3+MTD4" "behandelt"?) und daraus resultierender Unlust des FTP-Servers.

Ich gehe jetzt einfach mal davon aus, daß die ganzen anderen Aufrufe von Programmen (egal ob "nc", "ftp" oder "eva_get_environment") immer auf eine Box losgelassen werden, die unmittelbar zuvor (und zwar ohne erneute Unterbrechung des Stroms, da liest sich der erste Satz in #53 schon etwas merkwürdig) mit "eva_discover" im Bootloader "gefunden" wurde (womit dann erst einmal die Frage der verwendeten Adresse und ein eventuelles "Verbiegen" durch das "ruKernelTool" vom Tisch ist).

Das gezeigte Fehlen der Antworten des FTP-Servers könnte ja aber auch schlicht darauf zurückzuführen sein, daß der Bootloader an der Stelle gar nicht wirklich aktiv ist, weil die Box tatsächlich noch (mehrfach oder einmal) neu gestartet wird ... daher noch einmal ganz deutlich: Die Box ist nach "eva_discover" vielleicht noch für vier Sekunden auf dem FTP-Port erreichbar - nur die Verwendung von "HOLD=1" unterbricht den weiteren Bootvorgang und bietet die Möglichkeit, den FTP-Server auch über diese kurze Zeitspanne hinaus zu kontaktieren.

Was war denn nun eigentlich das Ergebnis, nachdem der Aufruf mit "HOLD=1" erfolgte? Blieb die Box weiterhin im Bootloader stehen? Die dann zu erwartende LED-Anzeige habe ich zwar meinerseits beschrieben, ob das aber auch wie erwartet funktionierte, steht da nirgendwo.

@stoney0815:
Hast Du eigentlich mal meinen "allgemeinen" Text zur Erreichbarkeit des FTP-Servers im Bootloader aus dem "modfs"-Repository gelesen? Ich habe (schon eine Weile) den Eindruck, daß Du die Box immer wieder neu startest, bevor Du irgendwelche Kommandos absetzt ... das gilt aber nur für "eva_discover", daß dafür die Box neu zu starten ist und nicht für alle anderen Kommandos. Die müssen/können entweder direkt nach dem Aufruf von "eva_discover" auf derselben Kommandozeile angegeben werden (das war der Versuch mit dem "; nc 192.168.178.1 21" dahinter) oder die Box muß eben im Bootloader "festgehalten" werden (HOLD=1). Bei der hier vorhandenen Retail-Version der 6490 funktioniert das auch problemlos, solange man die "FTP-Sitzung" nicht mit "QUIT" beendet, was nun schon lange "ausgebaut" ist aus "eva_discover".

Ansonsten muß man auch nicht gleich wieder mit so etwas Komplexem wie einem "RETR"-Kommando (das braucht die parallele Datenverbindung für den passiven Transfer) beginnen, wenn man den FTP-Server in der FRITZ!Box erst einmal testen will.