[Gelöst] EVA-Discover.ps1 hält die FritzBox nicht im Bootloader

WileC

Mitglied
Mitglied seit
28 Nov 2007
Beiträge
395
Punkte für Reaktionen
13
Punkte
18
Hallo liebe Forumler,

ich habe derzeit ein kleines Problem mit einer FritzBox 3490: ich möchte mittels PeterPawns "EVA-Discover.ps1" die FritzBox suchen lassen und dann mittels "EVA-FTP-Client.ps1" flashen. Bei einer anderen 3490 hat das ganz prima geklappt... doch mit der jetzigen, die will einfach nicht im "Wartungsmodus" bleiben.

PowerShell:
Code:
PS D:\temp\freetz>./EVA-Discover.ps1
EVA_IP=192.168.178.1
True
PS D:\temp\freetz>

Danach springt nach ca. 5 Sekunden die Box in den normalen Boot, ohne dass ich eine Möglichkeit habe, "EVA-FTP-Client.ps1" auszuführen.

Weiß jemand von Euch Rat?

MfG
Tobias

PS: hier mein alter Thread bzgl. des Updates: http://www.ip-phone-forum.de/showthread.php?t=290053
 
Zuletzt bearbeitet:
@WileC:
Theoretisch das falsche Unterforum ... besser eins höher (also "Modifikationen"), ehe sich jemand empört (PowerShell hat dann nicht einmal mehr etwas mit Linux zu tun und damit nur noch wenig mit "Freetz" gemein).

Ansonsten verhält sich das PowerShell-Skript anders als die Shell-Variante ... schaut man in den Kopf der Datei, steht dort ja ein "$False" als Standard bei fehlender Angabe für den "nohold"-Parameter. Die PowerShell-Variante sollte also die Box anhalten (bei fehlender Angabe), die Linux-Variante hingegen nicht.

Warum die Box hier nicht stehenbleiben mag, kann man so aber auch nicht sehen, dazu müßtest Du schon den Aufruf um die Parameter "-Debug" und "-Verbose" erweitern. Wenn dann ein Fehler angezeigt wird, muß man ggf. das Skript ändern für die korrekte/komplette Fehlermeldung, weil hier einfach ein "catch" für jeden Fehler gemacht wird (um das einfacher zu halten).

Ich würde ad hoc darauf tippen, daß die lokale Netzwerk-Konfiguration nicht dazu angetan ist, die FRITZ!Box unter der Adresse 192.168.178.1 zu finden. Das kann z.B. ein noch nicht verfallener ARP-Eintrag von einer anderen Box sein, der nun die 192.168.178.1 mit einer anderen MAC-Adresse verknüpft oder auch eine falsche IP-Adresse/Route, wo dann die Daten auf einem anderen Interface landen und nicht auf demselben, wo die Box gefunden wurde. Dann hilft ggf. schon die Angabe der "gewünschten" Adresse der FRITZ!Box, sofern diese Angabe zur eigenen Konfiguration des Netzwerks paßt. Vielleicht sucht hier auch erst einmal das Windows-Netzwerk (dank "media sense") nach einer eigenen Adresse per DHCP, nachdem das Interface nun dank "Power-On" bei der FRITZ!Box der Meinung ist, es müsse sich neu konfigurieren. Das kann man "von außen" und ohne weitere Angaben nicht sehen/einschätzen - da müßtest Du dann schon noch etwas mehr auf den Tisch packen.

Es ist aber i.d.R. ohnehin besser, die beiden Skript-Dateien unmittelbar nacheinander auszuführen und auf die zwischenzeitliche Verbindung zum FTP-Server (die ist es ja, was die Box im Loader "festhält" bzw. halten soll, auch über ihr Beenden hinaus) zu verzichten.

Es gibt sehr unterschiedliche Reaktionen von verschiedenen Bootloader-Versionen ... während die einen beim puren Aufbau einer Verbindung, die ohne jeden Austausch von Daten wieder geschlossen wird, etwas allergisch scheinen (und im Anschluß nicht mehr auf einen neuen Verbindungswunsch reagieren), geschieht das bei anderen wohl nur dann, wenn man diese Verbindung sofort wieder mit einem "QUIT" beendet.

Was ich noch nicht getestet habe, ist die Vermutung, daß es nach einer erfolgreichen Anmeldung an der Box (also nach "USER"- und "PASS"-Kommando) ein einheitliches Verhalten geben könnte ... ansonsten hätten die Recovery-Versionen von AVM auch so ihre Probleme mit unterschiedlichen Bootloader-Versionen, denn diese Programme melden sich ebenfalls mehrfach bei der Box an.

Allerdings gibt es für die natürlich auch keine Notwendigkeit, das in zwei getrennte Schritte zu splitten - ich weiß halt nicht, was die Ursache solcher Verbindungsprobleme nach einem Anhalten beim Aufruf eines der Discovery-Skripte tatsächlich ist. Die PowerShell-Variante benutzt jedenfalls die Variante ohne explizites "QUIT", was nicht jeder Bootloader mag - aber dann sollte die Box nur auf weitere Kommandos nicht mehr reagieren und nicht einfach mit ihrem Start fortfahren (außer nach einem erfolgreichen "in(to)-memory"-Upload, da wartet sie dann nicht auf weitere Kommandos).

Am einfachsten wäre da halt ein eigenes "Klammerskript" für die beiden Kommandos, wobei die PowerShell auch das Semikolon als Trennzeichen zwischen zwei Kommandos kennt und man das somit auch problemlos auf eine Zeile kriegt.

Die Ausgabe von "EVA-Discover.ps1" umfaßt eigentlich auch extra die IP-Adresse der Box, damit man bei einer weitergehenden Automatisierung auf diese Angabe zurückgreifen kann und auch der "Rückgabewert" ist eigentlich dazu gedacht, daß der Aufrufer ermitteln kann, ob eine Box gefunden wurde oder nicht und ggf. die Verarbeitung bei einem Problem abbrechen kann.

Da der betreffende Fehler beim Herstellen einer FTP-Verbindung zum Bootloader im "EVA-FTP-Client.ps1" auch nicht einfach mit einem "catch (all)" weggefangen wird, kann man bei unmittelbar aufeinanderfolgenden Aufrufen die passende Fehlernachricht auch direkt dem zweiten Skript-Aufruf entnehmen und muß das erste nicht noch anpassen, damit man die ausführliche Fehlernachricht sehen kann.

Bei mir funktioniert jedenfalls (bei einer 7580, die ich gerade untersuche und passend verkabelt habe) auch das Anhalten im Bootloader:
Code:
PS C:\Users\PeH> [COLOR="#0000FF"][B].\Desktop\EVA-Tools\EVA-Discover.ps1 -Debug -Verbose[/B][/COLOR]
VERBOSE: Sending discovery packet (1) ...
VERBOSE: Sending discovery packet (2) ...
VERBOSE: Sending discovery packet (3) ...
VERBOSE: Sending discovery packet (4) ...
VERBOSE: Sending discovery packet (5) ...
VERBOSE: Sending discovery packet (6) ...
VERBOSE: Sending discovery packet (7) ...
VERBOSE: Sending discovery packet (8) ...
VERBOSE: Sending discovery packet (9) ...
VERBOSE: Sending discovery packet (10) ...
DEBUG: Received UDP packet from 192.168.178.1:5035 ...
VERBOSE: Trying to connect to the FTP port to hold up the device in bootloader ...
EVA_IP=192.168.178.1
True
PS C:\Users\PeH> [COLOR="#0000FF"][B].\Desktop\EVA-Tools\EVA-FTP-Client.ps1 -ScriptBlock { GetEnvironmentValue ProductID } -Debug -Verbose[/B][/COLOR]
DEBUG: Response:
220 ADAM2 FTP Server ready

================
DEBUG: Sent
USER adam2
================
DEBUG: Response:
331 Password required for adam2

================
DEBUG: Sent
PASS adam2
================
DEBUG: Response:
230 User adam2 successfully logged in

================
DEBUG: Sent
SYST
================
DEBUG: Response:
215 AVM EVA Version 1.3229 0x0 0x46409

================
DEBUG: Sent
GETENV ProductID
================
DEBUG: Response:
ProductID             Fritz_Box_HW225

200 GETENV command successful

================
Fritz_Box_HW225
PS C:\Users\PeH>

- - - Aktualisiert - - -

BTW ... wer mittels "EVA-Discover.ps1" nur ermitteln will, welche IP-Adresse in der Box aktuell für den Bootloader eingestellt ist (die ist bekanntlich vollkommen unabhängig von der Adresse einer "richtig gestarteten" Box), der kann als "Wunschadresse" einfach 0.0.0.0 angeben - dann ändert die Box ihre eigene IP-Adresse nicht und antwortet unter/mit der aktuell eingestellten Adresse.
 
Also das wäre meine Ausgabe von EVA-Discover.ps1 -Debug -Verbose:
Code:
PS D:\Temp\Freetz> .\EVA-Discover.ps1 -Debug -Verbose
VERBOSE: Sending discovery packet (1) ...
VERBOSE: Sending discovery packet (2) ...
VERBOSE: Sending discovery packet (3) ...
VERBOSE: Sending discovery packet (4) ...
VERBOSE: Sending discovery packet (5) ...
VERBOSE: Sending discovery packet (6) ...
VERBOSE: Sending discovery packet (7) ...
VERBOSE: Sending discovery packet (8) ...
VERBOSE: Sending discovery packet (9) ...
VERBOSE: Sending discovery packet (10) ...
DEBUG: Received UDP packet from 192.168.178.1:5035 ...
VERBOSE: Trying to connect to the FTP port to hold up the device in bootloader ...
DEBUG: Error during FTP connection attempt ...
EVA_IP=192.168.178.1
True
PS D:\Temp\Freetz>

Bei meinem Laptop beziehen alle Interfaces ihre IP-Adresse per DHCP. Während die Box mittels LAN-Kabel am Laptop hängt, ist WLAN deaktiviert.

Ausgabe von ipconfig /all:
Code:
PS D:\Temp\Freetz> ipconfig /all

Windows-IP-Konfiguration

   Hostname  . . . . . . . . . . . . : laptop-tobias
   Primäres DNS-Suffix . . . . . . . : ups
   Knotentyp . . . . . . . . . . . . : Hybrid
   IP-Routing aktiviert  . . . . . . : Nein
   WINS-Proxy aktiviert  . . . . . . : Nein
   DNS-Suffixsuchliste . . . . . . . : ups

Drahtlos-LAN-Adapter Drahtlosnetzwerkverbindung 6:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Microsoft Virtual WiFi Miniport Adapter #6
   Physikalische Adresse . . . . . . : 02-16-6F-DD-48-F3
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja

Drahtlos-LAN-Adapter Drahtlosnetzwerkverbindung 5:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Microsoft Virtual WiFi Miniport Adapter #5
   Physikalische Adresse . . . . . . : 02-16-6F-DD-48-F2
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja

Drahtlos-LAN-Adapter Drahtlosnetzwerkverbindung 4:

   Verbindungsspezifisches DNS-Suffix: ups
   Beschreibung. . . . . . . . . . . : Intel(R) Dual Band Wireless-AC 7260
   Physikalische Adresse . . . . . . : 00-16-6F-DD-48-F2
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja
   IPv4-Adresse  . . . . . . . . . . : 192.168.1.121(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Lease erhalten. . . . . . . . . . : Samstag, 1. April 2017 18:24:13
   Lease läuft ab. . . . . . . . . . : Sonntag, 9. April 2017 18:28:42
   Standardgateway . . . . . . . . . : 192.168.1.1
   DHCP-Server . . . . . . . . . . . : 192.168.1.10
   DNS-Server  . . . . . . . . . . . : 192.168.1.10
   NetBIOS über TCP/IP . . . . . . . : Aktiviert

Ethernet-Adapter LAN-Verbindung:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : JMicron PCI Express Gigabit Ethernet Adapter
   Physikalische Adresse . . . . . . : BC-AE-C5-5C-5C-C1
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja

Tunneladapter isatap.kurekhome.lan:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix: ups
   Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter
   Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja

Tunneladapter Teredo Tunneling Pseudo-Interface:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
   Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja

Tunneladapter isatap.{8DBBE0E4-97EF-404D-9CD0-2A0DE1540CCE}:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #6
   Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja
PS D:\Temp\Freetz>
 
Gerade bei Laptops braucht dieses ganze Umschalten zwischen WLAN und LAN zum Stromsparen dann noch zusätzliche Zeit ... diese "Automatik" einfach abstellen, dem Ethernet-Interface eine feste IP-Adresse geben (ggf. gleich passend zur "Standardadresse" der Box, also z.B. 192.168.178.10/24) und dann sollte auch die FTP-Verbindung klappen. Wenn die Umschaltung sich nicht abschalten läßt beim Treiber des Laptop-Herstellers, irgendeinen Switch in die Kabelverbindung einbauen - der hebelt dann "media sense" aus.
 
Also mein WLAN war die ganze Zeit deaktiviert, ich habe meinem LAN-Interface eine feste IP-Adresse (192.168.178.21) gegeben und schon rutschte das flashen durch.

@PeterPawn: meinst Du, du könntest das setzen der IP-Adresse vom LAN passend zur FritzBox ins Skript einarbeiten ?!
 
@PeterPawn: meinst Du, du könntest das setzen der IP-Adresse vom LAN passend zur FritzBox ins Skript einarbeiten ?!

Sonst noch Wünsche?

IMHO steht es oft genug an den verschiedensten Stellen geschrieben und eine Suche hätte das Problem sicher auch lösen können
 
@WileC:
Mal abgesehen von allem anderen ... woher soll das Skript denn wissen, ob der Benutzer das überhaupt will (also seinen LAN-Adapter an die FRITZ!Box anpassen)? Wenn er es als Parameter angibt, dann kann er auch gleich seinen Rechner selbst richtig konfigurieren (und das ggf. nach erfolgreichem Abschluß auch wieder rückgängig machen) und wenn der Aufrufer seinerseits etwas vollkommen anderes will (nämlich die FRITZ!Box an seine bestehende LAN-Konfiguration anpassen), dann bietet das Skript bereits die notwendigen Parameter an - man muß sie nur nutzen.

Wobei man den Verwendern der PowerShell-Skripte auch noch mit auf den Weg geben sollte, daß diese in der Regel den Zugriff auf das Netzwerk brauchen und daher bei der Firewall-Nachfrage dieser auch genehmigt werden muß (das gilt natürlich auch für irgendwelche AV-Suiten). Da sich so eine FRITZ!Box im Bootloader nicht unbedingt "richtig authentifizieren" muß, reicht häufig auch die Einstellung für "privates Netzwerk" noch nicht aus (das Netz aus dem "normalen Betrieb" wird nicht unbedingt erkannt) und man sollte lieber gleich auch "public" einschließen. Notfalls muß man den Eintrag für die PowerShell (oder die ISE, je nachdem, was man benutzt hat) eben hinterher wieder aus der Firewall-Konfiguration löschen.
 
@PeterPawn:
dann wäre es doch schön oder ein "improvement", wenn EVA-Discover.ps1 das Interface überprüfen würde, ob's eine feste IP hat, oder per DHCP gezogen wird. Wenn DHCP eingestellt ist, könnte das Skript mit einer Fehlermeldung/Hinweis abgebrochen werden. Nur als Idee.
 
Sorry, ich habe so gar keinen Ehrgeiz, dieses Skript irgendwie "zu verbessern". Wenn jemand zuvor seine Netzwerk-Konfiguration ändern möchte, macht er das mit einem Skript "außen herum" um EVA-Discover.ps1 und EVA-FTP-Client.ps1 ... da kann er dann über WMI an seinem Windows herumkonfigurieren, wie er will.

Ich habe die PowerShell-Varianten aus reinem Interesse (wie attackiere ich auf einem Windows-PC (ausschließlich mit Bordmitteln) eine FRITZ!Box am besten?) und als Alternative zu den Linux-/Shell-Versionen erstellt.

Zumal das mit dem DHCP auch funktionieren kann ... so einfach ist es dann doch wieder nicht.

Erst dann, wenn da irgendwelche Stromsparmechanismen zuschlagen und einen Adapter ohne eingestecktes Kabel (bei direkter Verbindung zur FRITZ!Box) komplett deaktivieren und der dann erst wieder umständlich aktiviert werden muß beim Einstecken der FRITZ!Box (was man mit einem Switch dazwischen problemlos aus dem Spiel nehmen kann), erst dann gibt es Probleme.

Ansonsten würde sich ein (unkonfigurierter) Windows-PC eben im ersten Anlauf eine APIPA-Adresse zuweisen, wenn er keinen DHCP-Server finden kann (also eine aus 169.254.0.0/16) und mit einer solchen Adresse kann man problemlos ebenfalls auf die FRITZ!Box im Bootloader zugreifen ... man muß halt die Box an den PC "anpassen" lassen beim "discover".
 
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.