- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,619
- Punkte für Reaktionen
- 1,947
- Punkte
- 113
bzw. "Wie erreiche ich den Bootloader einer FRITZ!Box wirklich zuverlässig per FTP?", denn eine bestimmte Firmware kann man ja nicht nur mit dem AVM-Recovery-Programm (über einen minimalistischen FTP-Server im Bootloader) auf einer FRITZ!Box installieren und der FTP-Server erlaubt darüber hinaus ja auch noch das Ändern (mal persistent, mal volatil) von bestimmten Einstellungen.
Es kommt ja immer wieder das Problem auf, daß jemand seine FRITZ!Box irgendwie geändert hat und nach einer solchen Änderung einfach nicht mehr per FTP auf den Bootloader zugreifen kann. Auch bei der Verwendung des AVM-Programms (das man ja auch - in der falschen Version für die eigene Box - als "Wegbereiter" für den FTP-Zugriff verwenden kann, weil es beim Erkennen des falschen Modells einfach abbricht und die Box im "FTP-Modus" stehen läßt) kann es nicht schaden, wenn man die Arbeitsweise des Programms ein wenig versteht.
Denn auch das Recovery-Programm von AVM stellt eine FRITZ!Box - entgegen der landläufigen Meinung - eben nicht stur auf die Adresse 192.168.178.1 ein und versucht sich dann zu verbinden ... es sucht sich eine zur lokalen Konfiguration des Ethernet-Adapters passende Adresse aus und stellt die FRITZ!Box per UDP-Broadcast auf diese Adresse ein.
Welche das ist, steht normalerweise im Fenster des Recovery-Programms ... erst dann, wenn da irgendetwas in der Richtung "Suche Box an Adresse 0.0.0.0 ..." auftaucht, versucht das Programm einfach nur noch die Box irgendwie zu finden (bei 0.0.0.0 wird weiterhin die in der Box aktuell eingestellte Adresse verwendet - im Normalfall wäre das dann tatsächlich die 192.168.178.1, wobei diese Adresse absolut nichts - aber auch gar nichts - mit der Konfiguration zu tun hat, die von der FRITZ!Box im "Normalbetrieb" verwendet wird) anstatt ihr eine passende IP-Adresse vorzugeben.
Genau deshalb funktioniert das eben unter Windows auch, wenn man am Ende gar keinen DHCP-Server in seinem Netz hat und damit auch keine automatische IP-Adresse "von Fremden" erhält. In der Folge würfelt sich Windows eine Adresse aus dem 169.254.0.0/16-Segment aus (bei MS heißt das dann "APIPA", im Rest der Welt "ZeroConf") und weist dem Adapter diese Adresse zu ... das alles aber erst dann, wenn es keine Antwort auf einen DHCP-Request erhält.
Da so ein DHCP-Request auch erst mal etwas Zeit benötigt, bis man "Timeout" feststellen und damit konstatieren kann, daß wohl kein DHCP-Server vorhanden ist, darf/sollte an dieser Stelle die Aktivierung der Ethernet-Schnittstelle nicht davon abhängig sein, ob da ein Kabel in der Buchse steckt oder nicht ... wobei diese "Verbindung" eben auch nur dann erkannt werden kann, wenn sich "am anderen Ende" auch ein aktives Gerät befindet.
Ist das jetzt die FRITZ!Box selbst, wird die Verbindung ohne Strom in der FRITZ!Box eben gerade nicht als "aktiv" erkannt und der Ethernet-Adapter kriegt im Windows keine Adresse zugewiesen. Steckt man jetzt die FRITZ!Box an den Strom, startet erst die aufwändige Ermittlung der IP-Adresse ... das dauert in aller Regel deutlich zu lange für die 5-10 Sekunden, die einem der Bootloader nur Zeit läßt, wenn man mit ihm per FTP Kontakt aufnehmen will.
Daher muß man dieses Problem auf einem von drei möglichen Wegen "umschiffen" ... der erste Weg wäre es, einfach dafür zu sorgen, daß für den Windows-PC die Verbindung nicht erst dann "aktiv" wird, wenn die FRITZ!Box mit Strom versorgt ist - das geht am einfachsten über einen zusätzlichen Switch, den man zwischen PC und FRITZ!Box steckt. Damit sieht die Verbindung für den Windows-PC bereits "aktiv" aus und er konfiguriert seinen Adapter auf eine APIPA-Adresse, die dann vom Recovery-Programm auch benutzt wird, wenn die FRITZ!Box entsprechend "eingestellt" werden muß.
Eine Alternative ist (ab Windows 7 verfügbar) eine "Eingabeaufforderung" in Windows. Dazu gibt man in das Suchfeld einfach "cmd" ein und startet die dann (hoffentlich) gefundene "cmd.exe" (wir bleiben hier mal bei der alten Shell und verwenden "netsh", obwohl man das mit PowerShell auch noch anders lösen könnte) "als Administrator" ... den Punkt bietet einem das Kontext-Menü (erreichbar über die rechte Maustaste unter Windows) dann an. Dort gibt man den Text:
ein (der einfach nur mit "Ok." vom System bestätigt wird) und damit wird die Erkennung der "aktiven Verbindung" abgeschaltet.
In der Folge sollte sich Windows jetzt eine Adresse für den Ethernet-Adapter besorgen (daß die ganze Recovery-Geschichte nur mit einem Ethernet-Kabel und nicht über WLAN geht, steht hier, bei AVM und ist irgendwo ja auch logisch ... wie soll eine nicht gestartete FRITZ!Box auch ihre WLAN-Interfaces benutzen?) und weil wir ohnehin schon eine Shell zur Verfügung haben, können wir das mit einem beherzten:
auch gleich noch überprüfen. Da sollte irgendein Eintrag "Ethernet adapter <name>:" auftauchen (ggf. von MS übersetzt, ich arbeite mit einem englischen Windows) und unterhalb dieses Eintrags sollte eine Zeile mit einer "IPv4 Address" stehen. Die kann durchaus auch mit "169.254" beginnen ... stört uns hier kein bißchen.
Hat man auf diesem Weg die Erkennung der aktiven Verbindung unterbunden, sollte man nicht vergessen, nach dem Abschluß der Arbeiten durch erneute Verwendung des "netsh"-Kommandos oben, nur eben diesmal mit "dhcpmediasense=enabled", die Erkennung wieder einzuschalten (erspart spätere Kopfschmerzen, wenn ansonsten der Adapter nicht mehr wie erwartet eine neue Adresse organisiert, nachdem eine neue Verbindung hergestellt wurde).
Der dritte Weg ist natürlich die statische Konfiguration einer passenden IP-Adresse ... auch diese muß keineswegs (wenn ich mich nicht irre, auch für das AVM-Recovery-Programm nicht - hier habe ich mich doch geirrt, siehe weiter unten ... das mit statischen Adressen ist beim AVM-Programm dann doch wieder anders) aus dem Segment 192.168.178.0/24 stammen (die 192.168.178.1 "verbietet" sich dann ja ohnehin). Wer also bereits eine statische Konfiguration für seine Netzwerkkarte verwendet, muß diese nicht etwa unbedingt auf 192.168.178.irgendwas ändern ... der entscheidende Zeitgewinn entsteht hier aus der Tatsache, daß dann durch das Windows-OS gleich eine Adresse gesetzt wird, wenn die Verbindung "aktiv" wird und damit die Wartezeit auf eine Antwort vom DHCP-Server entfällt.
==========================================================================
Das kann man natürlich auch beliebig mixen ... es wird - wenn man ansonsten nichts falsch macht - auch mit einem Hardware-Switch, deaktiviertem Media-Sensing und einer statischen IP-Adresse funktionieren. Aber das wären drei Kondome übereinander ... während es den meisten dann wohl eher auf die Füße fallen wird, daß beim ersten Anlauf das Recovery-Programm von AVM (und auch meine PowerShell-Varianten) ein "listen" auf dem UDP-Port starten muß (müssen), um die Antwort der FRITZ!Box auf die Kontaktversuche einzufangen und das ist - bei aktivierter Windows-Firewall - nun mal eine Operation, die der Zustimmung durch den Benutzer bedarf (weil es "unsolicited traffic" ist, da das Senden an die FRITZ!Box an dieser Stelle als Broadcast-Paket erfolgt).
Daraus ergeben sich zwei Probleme ... Windows verwaltet die Freigaben für solche Netzwerk-Aktivitäten zwar für verschiedene Programme getrennt (wobei bei den PS-Skripten m.W. der PS-Host als "Programm" angesehen wird), aber damit dann nicht einfach jemand das Programm durch ein anderes mit demselben Namen (und Pfad) ersetzt, wird auch noch geprüft, daß es sich tatsächlich um dasselbe Programm handelt. Das funktioniert natürlich beim AVM-Recovery-Programm auch nur dann, wenn man genau diese Version auch schon einmal benutzt hat ... tauscht man das Recovery-Programm gegen eine neue Version aus, braucht auch diese i.d.R. die erneute Zustimmung zum "Durchlöchern" der Brandmauer.
Zusätzlich verwaltet Windows noch unterschiedliche Sätze von Firewall-Regeln, je nachdem, ob es sich um ein "privates" oder ein "öffentliches" Netzwerk handelt. Während bei den meisten das Netz der eigenen FRITZ!Box vermutlich als "privates Netzwerk" gehandelt wird, kann das Windows aber eben nur dann erkennen, wenn die FRITZ!Box in vollem Umfang arbeitet ... was hier aber genau nicht der Fall ist, wenn man irgendwie mit dem Recovery-Programm auf die startende Box zugreifen will (spätestens beim zweiten Versuch nicht mehr).
Daher muß man in der Regel dem Recovery-Programm das Recht zum "Lauschen" ins Netzwerk auch für "öffentliche Netzwerke" einräumen und bei einigen (ich weiß nicht, ob nicht sogar bei allen) Recovery-Programmen von AVM sind die Einstellungen da nur für "private Netzwerke" vorbelegt, was unerfahrene Benutzer auch vor zusätzliche Herausforderungen stellen kann, wenn man eine weitere Checkbox aktivieren muß in dem Freigabe-Dialog der Firewall.
Jedenfalls reicht die Zeit, die man selbst benötigt für das "Beantworten" der Frage (die u.U. auch erst dann auftaucht, wenn die Verbindung tatsächlich "aktiv" wird nach dem Versorgen der FRITZ!Box mit Strom), häufig auch schon aus, damit der erste Anlauf mit dem Recovery-Programm scheitert, weil die Box zwar in der Zeit antwortet, diese Antwort aber das Recovery-Programm mangels Zustimmung im Firewall-Dialog noch nicht erreicht und dann ist die Karenzzeit für den FTP-Zugriff schon um.
Dann bleibt einem i.d.R. nichts anderes übrig, als noch einmal von vorne zu beginnen mit dem Start des Recovery-Programms und der Box ... verwendet man jetzt dasselbe (Recovery-)Programm, fällt die "Verzögerung" durch den Firewall-Dialog weg und die Box wird gefunden.
Wenn man die Arbeitsweise (und die möglichen Probleme) erst einmal verstanden hat, kann man meist auch alleine erkennen, wo es gerade klemmt ... es liegt jedenfalls in den seltensten Fällen tatsächlich an der Box, wenn man keinen Zugriff auf den Bootloader erhält.
Es ist aber eben keineswegs so, daß vom AVM-Recovery-Programm immer die 192.168.178.1 für die FRITZ!Box verwendet wird ... ist ein Ethernet-Adapter bereits aktiv und konfiguriert, wenn das Programm gestartet wird, ermittelt es eine zu der vorhandenen Adresse passende IPv4-Adresse für die FRITZ!Box und sendet diese im Broadcast-Paket aus. In der Folge soll/wird die FRITZ!Box dann diese IP-Adresse verwenden und der Rest der Kommunikation erfolgt darüber - es sind also auch nicht in jedem Falle irgendwelche "Konfigurationsorgien" erforderlich, nur weil man mit dem Bootloader der FRITZ!Box "reden" will.
==========================================================================
EDIT:
Das AVM-Recovery-Programm mag bei einer tatsächlich statisch konfigurierten IP(v4)-Adresse offenbar doch keine Segmente, die von 192.168.178.0/24 abweichen. Ich kann es nicht beschwören, ob das früher nicht doch anders war - aber Stand heute (und zurück bis zur 06.5x, soweit habe ich mit dem Recovery-Programm getestet) muß es bei der Verwendung des AVM-Programms (das gilt also nicht für andere Tools und/oder manuellen Zugriff auf den Bootloader per FTP, wenn zuvor irgendein Tool mit "discovery feature" verwendet wurde) UND bei statisch konfigurierter IPv4-Adresse dann doch eine sein, die zum Segment 192.168.178.0/24 paßt und es darf nicht die erste aus dem Segment sein.
Die gute Nachricht ist aber, daß auch bei statisch konfigurierten Adressen nicht nur die "primäre" Adresse in Betracht gezogen wird, sondern auch alle anderen konfigurierten. Wer also häufiger mal mit FRITZ!Boxen in Kontakt ist, der hat i.d.R. ohnehin auf seinen Netzwerk-Interfaces vermutlich schon eine zusätzliche Adresse aus den Segmenten 192.168.178.0/24 (für den Zugriff aufs GUI einer "frischen" Box) und 192.168.188.0/24 konfiguriert, wobei man letztere immer dann braucht, wenn man eine FRITZ!Box mit halbwegs aktueller Firmware auf "LAN1"-Router umgestellt hat ... denn AVM setzt das LAN-Segment einer solchen Box dann automatisch erst einmal auf 192.168.188.0/24 - mit der Box als 192.168.188.1 - und man muß/müßte dann erst wieder sein Interface umkonfigurieren. Aber auch das gilt eben nur für statisch konfigurierte Interfaces ... sowie das Interface DHCP verwendet und bereits eine Adresse hat (dabei ist es dann auch egal, ob es diese von einem DHCP-Server bezogen oder sie selbst per APIPA zugewiesen hat), paßt sich das Recovery-Programm an diese Adresse an und setzt dann die FRITZ!Box passend dazu.
Hier wurde ein Laptop verwendet (mit W10 Pro 1909), dessen WLAN nicht verbunden war und der per Ethernet-Kabel direkt mit einer 7580 kommunizieren konnte (also ohne Switches o.ä.). Das Recovery-Programm wurde ohne Administrator-Rechte gestartet, daher konnte es keine Adressen von sich aus hinzufügen (s.u.). Das Ethernet-Interface war dabei auf DHCP eingestellt und DHCPMediaSense war ausgeschaltet (s.o.).
Die ausgelassenen Zeilen sind den (vergeblichen) Versuchen geschuldet, da doch noch selbst eine IP-Adresse zu setzen ... daher vergingen vom Start des Programms bis zur Anzeige des Fensters auch fast 30 Sekunden. Aber danach flutscht die Kommunikation dann auch mit einer FRITZ!Box, die ihrerseits die IP-Adresse 169.254.9.1 verwendet und das Environment und die Zählerstände werden problemlos gelesen.
Ein Versuch, das mit einer statischen Adresse außerhalb von 192.168.178.0/24 zu machen, scheitert jedoch kläglich:
Aber es wird hier ja schon anhand des Protokolls klar, daß das eine Einschränkung seitens des Recovery-Programms von AVM ist und nichts damit zu tun hat, worauf sich die Box einstellen ließe ... denn wäre das eine DHCP-Adresse, klappt das wieder problemlos - sogar mit einer 10.1.1.17/24:
Verwendet man andere Tools als das AVM-Programm, stehen einem auch andere Adressen offen:
Dabei wird dann auf der (seriellen) Console vom Bootloader auch "festgehalten", wenn sich die IP-Adresse aufgrund eines empfangenen Broadcast-Pakets ändert:
Falls sich jetzt jemand fragen sollte, warum man das alles wissen muß, wenn das AVM-Programm damit doch ohnehin nicht umgehen kann ... es muß eben auch nicht immer das AVM-Programm sein und wer eigene Firmware auf einer Box installieren will und dazu den Bootloader bemühen muß/will, der freut sich vielleicht auch darüber, daß er nicht ständig seine Systeme (die ja bei den allermeisten eher nicht mit einer statischen IP-Adresse aus 192.168.178.0/24 arbeiten, sondern mit DHCP und am besten auch noch mit einem anderen LAN-Segment als dem "Standard") umkonfigurieren muß oder soll, nur um irgendwie an den FTP-Server im Bootloader zu kommen.
==========================================================================
Ich bin letztens im Dialog mit einem Benutzer auch noch auf ein weiteres Problem aufmerksam gemacht worden, wenn man irgendeine Software für "EVA discovery" verwenden will (egal, ob es sich um das AVM-Programm oder eines meiner Skripte handelt). Das funktioniert aus einer virtuellen Maschine heraus nur dann, wenn man dort einen Netzwerk-Adapter verwendet, der mit dem Host-Adapter per Bridge verbunden ist. Ansonsten erreichen die UDP-Broadcast-Pakete ihr Ziel nie und auch die per Unicast gesendeten Antworten zerschellen dann gerne mal am NAT, was der VM-Host (zumindest bei VMware) als Alternative bereithält. Daß ein "host only"-Adapter (ebenfalls wieder bei VMware-Produkten) nichts bringt, sagt ja schon der Name.
==========================================================================
EDIT 08.05.2020:
Und für die meisten der neueren FRITZ!Box-Modelle noch ein ergänzender Hinweis (der steht zwar gefühlt auch in jedem zweiten Thread, wo es um Probleme beim Flashen - mit dem AVM-Recovery-Programm oder irgendwelchen anderen Tools - geht, aber hier war er tatsächlich nicht drin):
Das AVM-Programm schreibt i.d.R. als "Erfolgsmeldung" etwas in der Richtung: "Nach einem Neustart ist die neue Firmware installiert." (nicht wörtlich, aber sinngemäß) in sein Fenster ... das ist etwas unglücklich formuliert von den Autoren dieses Programms. Bei den Modellen, wo die Firmware ins RAM des Routers geladen und dort gestartet wird, ermittelt die soeben hochgeladene Firmware diesen Umstand ziemlich direkt nach ihrem Start (der aber auch mal 15 Sekunden und mehr dauern kann) und schreibt sich dann quasi selbst in den Flash-Speicher (und erst dann ist sie dauerhaft gespeichert). Anschließend wird der Router neu gestartet und nun wird die Firmware auch aus dem Flash geladen und initialisiert daher den Router "richtig" (sprich: das Schreiben in den Flash wird jetzt übergangen, weil es unnötig wäre).
Wer also dem Router nach der Meldung des Recovery-Programms nicht die Zeit läßt, daß er sich selbst neu starten kann und ihm unmittelbar nach der Meldung den Stecker zieht (entweder weil er die Meldung gar nicht zur Kenntnis genommen hat oder weil er sie als Aufforderung, den Router jetzt neu zu starten, interpretierte), der hat außer vergeudeter Zeit nur wenig erreicht ... immerhin hätte das AVM-Programm ihm aber schon erfolgreich die Einstellungen der FRITZ!Box zurückgesetzt. Nur müßte man dazu eher selten das Recovery-Programm bemühen, das ginge per GUI ja auch einfacher.
Das gilt zwar auch nicht für alle Router-Modelle (es hängt von den "inneren Werten" ab), aber außer einigen Repeatern und der 4040 / 4020 arbeiten die meisten FRITZ!Box-Modelle (für die es Recovery-Programme von AVM gibt, die Cable-Boxen gehören da - Stand heute - nicht dazu) inzwischen so - speziell wenn sie das FRITZ!OS in NAND-Flash speichern, weil dann meist erst das laufende OS die passende Behandlung für die verschiedenen Chips (beim Schreiben) sicherstellen kann. Ob das eigene Gerät nun diese Zeit zum Schreiben in den Flash braucht oder nicht, muß man entweder vorher ermitteln oder man läßt die Box eben nach der Meldung des AVM-Programms (oder auch nach dem Ende einer meiner Skript-Dateien, wenn man keine AVM-Firmware installieren wollte) noch 1-2 Minuten vor sich hin arbeiten. Länger sollte das Schreiben in den Flash-Speicher nicht dauern und wenn sie bis dahin noch nicht neu gestartet wurde, ist es mit einiger Sicherheit ein Modell, wo der Bootloader schon in den Flash schreibt und nicht erst das gestartete OS.
==========================================================================
EDIT 22.05.2020:
Das AVM-Recovery-Programm schreibt seinerseits auch noch zwei "Protokoll-Dateien" unter Windows. Die eine behandelt das Thema der FTP-Kommunikation mit der Box und heißt folgerichtig auch
Wer sich jetzt fragt, warum er diese Dateien (vermutlich) noch nie gesehen hat, dem sei gesagt, daß AVM hier einen uralten Mechanismus zum Erzeugen der Protokoll-Dateien verwendet und daß dieser in früheren Windows-Versionen kein Problem hatte, die fraglichen Dateien direkt im Windows-Verzeichnis abzulegen. Startet man das Recovery-Programm von vorneherein mit
Da es aber so gar keine gute Idee aus Security-Sicht ist, wenn einfach irgendwelche Programme in das Windows-Verzeichnis schreiben dürfen, ging Microsoft irgendwann mal hin und "virtualisierte" das Windows-Verzeichnis (das gilt auch für das Verzeichnis (bzw. die Verzeichnisse) mit den Programmen) dahingehend, daß die von "normalen Nutzern" vorgenommenen Änderungen an Dateien unterhalb des Windows-Verzeichnisses nur noch innerhalb ihres eigenen Benutzerprofils gespeichert wurden und damit andere Benutzer nicht in Mitleidenschaft gezogen werden konnten.
Daher findet man heutzutage diese AVM-Protokolle in aller Regel innerhalb des eigenen Benutzer-Profils - sie liegen hier im Verzeichnis
Wer also mit dem AVM-Programm so gar nicht klarkommt, kann auch mal einen Blick in die
EDIT: 24.07.2023
Apropo Kabel ... das falsche Interface kann man natürlich (zumindest, wenn man NICHT das AVM-Programm verwendet, denn das ignoriert m.W. Interfaces ohne Kabel) auch dann erwischen, wenn man ein Gerät mit WLAN und LAN verwendet (spez. irgendwelche Laptops, aber auch neuere PCs haben häufig WLAN-Hardware auf dem Mainboard) und dabei NICHT das WLAN deaktiviert. Wer also ein Gerät MIT WLAN verwendet, sollte doppelt prüfen (sofern nicht das AVM-Programm verwendet wird), ob er TATSÄCHLICH auf dem richtigen Interface versucht, mit der FRITZ!Box zu kommunizieren.
Es kommt ja immer wieder das Problem auf, daß jemand seine FRITZ!Box irgendwie geändert hat und nach einer solchen Änderung einfach nicht mehr per FTP auf den Bootloader zugreifen kann. Auch bei der Verwendung des AVM-Programms (das man ja auch - in der falschen Version für die eigene Box - als "Wegbereiter" für den FTP-Zugriff verwenden kann, weil es beim Erkennen des falschen Modells einfach abbricht und die Box im "FTP-Modus" stehen läßt) kann es nicht schaden, wenn man die Arbeitsweise des Programms ein wenig versteht.
Denn auch das Recovery-Programm von AVM stellt eine FRITZ!Box - entgegen der landläufigen Meinung - eben nicht stur auf die Adresse 192.168.178.1 ein und versucht sich dann zu verbinden ... es sucht sich eine zur lokalen Konfiguration des Ethernet-Adapters passende Adresse aus und stellt die FRITZ!Box per UDP-Broadcast auf diese Adresse ein.
Welche das ist, steht normalerweise im Fenster des Recovery-Programms ... erst dann, wenn da irgendetwas in der Richtung "Suche Box an Adresse 0.0.0.0 ..." auftaucht, versucht das Programm einfach nur noch die Box irgendwie zu finden (bei 0.0.0.0 wird weiterhin die in der Box aktuell eingestellte Adresse verwendet - im Normalfall wäre das dann tatsächlich die 192.168.178.1, wobei diese Adresse absolut nichts - aber auch gar nichts - mit der Konfiguration zu tun hat, die von der FRITZ!Box im "Normalbetrieb" verwendet wird) anstatt ihr eine passende IP-Adresse vorzugeben.
Genau deshalb funktioniert das eben unter Windows auch, wenn man am Ende gar keinen DHCP-Server in seinem Netz hat und damit auch keine automatische IP-Adresse "von Fremden" erhält. In der Folge würfelt sich Windows eine Adresse aus dem 169.254.0.0/16-Segment aus (bei MS heißt das dann "APIPA", im Rest der Welt "ZeroConf") und weist dem Adapter diese Adresse zu ... das alles aber erst dann, wenn es keine Antwort auf einen DHCP-Request erhält.
Da so ein DHCP-Request auch erst mal etwas Zeit benötigt, bis man "Timeout" feststellen und damit konstatieren kann, daß wohl kein DHCP-Server vorhanden ist, darf/sollte an dieser Stelle die Aktivierung der Ethernet-Schnittstelle nicht davon abhängig sein, ob da ein Kabel in der Buchse steckt oder nicht ... wobei diese "Verbindung" eben auch nur dann erkannt werden kann, wenn sich "am anderen Ende" auch ein aktives Gerät befindet.
Ist das jetzt die FRITZ!Box selbst, wird die Verbindung ohne Strom in der FRITZ!Box eben gerade nicht als "aktiv" erkannt und der Ethernet-Adapter kriegt im Windows keine Adresse zugewiesen. Steckt man jetzt die FRITZ!Box an den Strom, startet erst die aufwändige Ermittlung der IP-Adresse ... das dauert in aller Regel deutlich zu lange für die 5-10 Sekunden, die einem der Bootloader nur Zeit läßt, wenn man mit ihm per FTP Kontakt aufnehmen will.
Daher muß man dieses Problem auf einem von drei möglichen Wegen "umschiffen" ... der erste Weg wäre es, einfach dafür zu sorgen, daß für den Windows-PC die Verbindung nicht erst dann "aktiv" wird, wenn die FRITZ!Box mit Strom versorgt ist - das geht am einfachsten über einen zusätzlichen Switch, den man zwischen PC und FRITZ!Box steckt. Damit sieht die Verbindung für den Windows-PC bereits "aktiv" aus und er konfiguriert seinen Adapter auf eine APIPA-Adresse, die dann vom Recovery-Programm auch benutzt wird, wenn die FRITZ!Box entsprechend "eingestellt" werden muß.
Eine Alternative ist (ab Windows 7 verfügbar) eine "Eingabeaufforderung" in Windows. Dazu gibt man in das Suchfeld einfach "cmd" ein und startet die dann (hoffentlich) gefundene "cmd.exe" (wir bleiben hier mal bei der alten Shell und verwenden "netsh", obwohl man das mit PowerShell auch noch anders lösen könnte) "als Administrator" ... den Punkt bietet einem das Kontext-Menü (erreichbar über die rechte Maustaste unter Windows) dann an. Dort gibt man den Text:
Code:
netsh interface ipv4 set global dhcpmediasense=disabledIn der Folge sollte sich Windows jetzt eine Adresse für den Ethernet-Adapter besorgen (daß die ganze Recovery-Geschichte nur mit einem Ethernet-Kabel und nicht über WLAN geht, steht hier, bei AVM und ist irgendwo ja auch logisch ... wie soll eine nicht gestartete FRITZ!Box auch ihre WLAN-Interfaces benutzen?) und weil wir ohnehin schon eine Shell zur Verfügung haben, können wir das mit einem beherzten:
Code:
ipconfigHat man auf diesem Weg die Erkennung der aktiven Verbindung unterbunden, sollte man nicht vergessen, nach dem Abschluß der Arbeiten durch erneute Verwendung des "netsh"-Kommandos oben, nur eben diesmal mit "dhcpmediasense=enabled", die Erkennung wieder einzuschalten (erspart spätere Kopfschmerzen, wenn ansonsten der Adapter nicht mehr wie erwartet eine neue Adresse organisiert, nachdem eine neue Verbindung hergestellt wurde).
Der dritte Weg ist natürlich die statische Konfiguration einer passenden IP-Adresse ... auch diese muß keineswegs (
==========================================================================
Das kann man natürlich auch beliebig mixen ... es wird - wenn man ansonsten nichts falsch macht - auch mit einem Hardware-Switch, deaktiviertem Media-Sensing und einer statischen IP-Adresse funktionieren. Aber das wären drei Kondome übereinander ... während es den meisten dann wohl eher auf die Füße fallen wird, daß beim ersten Anlauf das Recovery-Programm von AVM (und auch meine PowerShell-Varianten) ein "listen" auf dem UDP-Port starten muß (müssen), um die Antwort der FRITZ!Box auf die Kontaktversuche einzufangen und das ist - bei aktivierter Windows-Firewall - nun mal eine Operation, die der Zustimmung durch den Benutzer bedarf (weil es "unsolicited traffic" ist, da das Senden an die FRITZ!Box an dieser Stelle als Broadcast-Paket erfolgt).
Daraus ergeben sich zwei Probleme ... Windows verwaltet die Freigaben für solche Netzwerk-Aktivitäten zwar für verschiedene Programme getrennt (wobei bei den PS-Skripten m.W. der PS-Host als "Programm" angesehen wird), aber damit dann nicht einfach jemand das Programm durch ein anderes mit demselben Namen (und Pfad) ersetzt, wird auch noch geprüft, daß es sich tatsächlich um dasselbe Programm handelt. Das funktioniert natürlich beim AVM-Recovery-Programm auch nur dann, wenn man genau diese Version auch schon einmal benutzt hat ... tauscht man das Recovery-Programm gegen eine neue Version aus, braucht auch diese i.d.R. die erneute Zustimmung zum "Durchlöchern" der Brandmauer.
Zusätzlich verwaltet Windows noch unterschiedliche Sätze von Firewall-Regeln, je nachdem, ob es sich um ein "privates" oder ein "öffentliches" Netzwerk handelt. Während bei den meisten das Netz der eigenen FRITZ!Box vermutlich als "privates Netzwerk" gehandelt wird, kann das Windows aber eben nur dann erkennen, wenn die FRITZ!Box in vollem Umfang arbeitet ... was hier aber genau nicht der Fall ist, wenn man irgendwie mit dem Recovery-Programm auf die startende Box zugreifen will (spätestens beim zweiten Versuch nicht mehr).
Daher muß man in der Regel dem Recovery-Programm das Recht zum "Lauschen" ins Netzwerk auch für "öffentliche Netzwerke" einräumen und bei einigen (ich weiß nicht, ob nicht sogar bei allen) Recovery-Programmen von AVM sind die Einstellungen da nur für "private Netzwerke" vorbelegt, was unerfahrene Benutzer auch vor zusätzliche Herausforderungen stellen kann, wenn man eine weitere Checkbox aktivieren muß in dem Freigabe-Dialog der Firewall.
Jedenfalls reicht die Zeit, die man selbst benötigt für das "Beantworten" der Frage (die u.U. auch erst dann auftaucht, wenn die Verbindung tatsächlich "aktiv" wird nach dem Versorgen der FRITZ!Box mit Strom), häufig auch schon aus, damit der erste Anlauf mit dem Recovery-Programm scheitert, weil die Box zwar in der Zeit antwortet, diese Antwort aber das Recovery-Programm mangels Zustimmung im Firewall-Dialog noch nicht erreicht und dann ist die Karenzzeit für den FTP-Zugriff schon um.
Dann bleibt einem i.d.R. nichts anderes übrig, als noch einmal von vorne zu beginnen mit dem Start des Recovery-Programms und der Box ... verwendet man jetzt dasselbe (Recovery-)Programm, fällt die "Verzögerung" durch den Firewall-Dialog weg und die Box wird gefunden.
Wenn man die Arbeitsweise (und die möglichen Probleme) erst einmal verstanden hat, kann man meist auch alleine erkennen, wo es gerade klemmt ... es liegt jedenfalls in den seltensten Fällen tatsächlich an der Box, wenn man keinen Zugriff auf den Bootloader erhält.
Es ist aber eben keineswegs so, daß vom AVM-Recovery-Programm immer die 192.168.178.1 für die FRITZ!Box verwendet wird ... ist ein Ethernet-Adapter bereits aktiv und konfiguriert, wenn das Programm gestartet wird, ermittelt es eine zu der vorhandenen Adresse passende IPv4-Adresse für die FRITZ!Box und sendet diese im Broadcast-Paket aus. In der Folge soll/wird die FRITZ!Box dann diese IP-Adresse verwenden und der Rest der Kommunikation erfolgt darüber - es sind also auch nicht in jedem Falle irgendwelche "Konfigurationsorgien" erforderlich, nur weil man mit dem Bootloader der FRITZ!Box "reden" will.
==========================================================================
EDIT:
Das AVM-Recovery-Programm mag bei einer tatsächlich statisch konfigurierten IP(v4)-Adresse offenbar doch keine Segmente, die von 192.168.178.0/24 abweichen. Ich kann es nicht beschwören, ob das früher nicht doch anders war - aber Stand heute (und zurück bis zur 06.5x, soweit habe ich mit dem Recovery-Programm getestet) muß es bei der Verwendung des AVM-Programms (das gilt also nicht für andere Tools und/oder manuellen Zugriff auf den Bootloader per FTP, wenn zuvor irgendein Tool mit "discovery feature" verwendet wurde) UND bei statisch konfigurierter IPv4-Adresse dann doch eine sein, die zum Segment 192.168.178.0/24 paßt und es darf nicht die erste aus dem Segment sein.
Die gute Nachricht ist aber, daß auch bei statisch konfigurierten Adressen nicht nur die "primäre" Adresse in Betracht gezogen wird, sondern auch alle anderen konfigurierten. Wer also häufiger mal mit FRITZ!Boxen in Kontakt ist, der hat i.d.R. ohnehin auf seinen Netzwerk-Interfaces vermutlich schon eine zusätzliche Adresse aus den Segmenten 192.168.178.0/24 (für den Zugriff aufs GUI einer "frischen" Box) und 192.168.188.0/24 konfiguriert, wobei man letztere immer dann braucht, wenn man eine FRITZ!Box mit halbwegs aktueller Firmware auf "LAN1"-Router umgestellt hat ... denn AVM setzt das LAN-Segment einer solchen Box dann automatisch erst einmal auf 192.168.188.0/24 - mit der Box als 192.168.188.1 - und man muß/müßte dann erst wieder sein Interface umkonfigurieren. Aber auch das gilt eben nur für statisch konfigurierte Interfaces ... sowie das Interface DHCP verwendet und bereits eine Adresse hat (dabei ist es dann auch egal, ob es diese von einem DHCP-Server bezogen oder sie selbst per APIPA zugewiesen hat), paßt sich das Recovery-Programm an diese Adresse an und setzt dann die FRITZ!Box passend dazu.
Hier wurde ein Laptop verwendet (mit W10 Pro 1909), dessen WLAN nicht verbunden war und der per Ethernet-Kabel direkt mit einer 7580 kommunizieren konnte (also ohne Switches o.ä.). Das Recovery-Programm wurde ohne Administrator-Rechte gestartet, daher konnte es keine Adressen von sich aus hinzufügen (s.u.). Das Ethernet-Interface war dabei auf DHCP eingestellt und DHCPMediaSense war ausgeschaltet (s.o.).
Die ausgelassenen Zeilen sind den (vergeblichen) Versuchen geschuldet, da doch noch selbst eine IP-Adresse zu setzen ... daher vergingen vom Start des Programms bis zur Anzeige des Fensters auch fast 30 Sekunden. Aber danach flutscht die Kommunikation dann auch mit einer FRITZ!Box, die ihrerseits die IP-Adresse 169.254.9.1 verwendet und das Environment und die Zählerstände werden problemlos gelesen.
Rich (BBCode):
0:08:959: AVM Berlin recover-tool-version:[RECOVER:557][IO_CSP:533] compiled at Aug 21 2018 on 12:43:38
0:08:959: Registry: SYSTEM\CurrentControlSet\Services\TcpIp\Parameters\DisableDHCPMediaSense=1
0:08:959: recover-firmware-id: 225
0:08:959: recover-firmware-version: 153.07.01
0:09:272: check adapter(This Atheros network Controller connects you to the network.) adapter 0xe: Ip: 0.0.0.0(0.0.0.0) (dhcp)
0:09:272: check adapter(Intel(R) Wireless WiFi Link 4965AGN) adapter 0x6: Ip: 0.0.0.0(0.0.0.0) (dhcp)
0:09:288: can't add ipaddress (192.168.178.2 - 255.255.255.0) on adapter=e Error=5
[...]
0:28:235: check adapter(This Atheros network Controller connects you to the network.) adapter 0xe: Ip: 0.0.0.0(0.0.0.0) (dhcp)
0:28:235: check adapter(Intel(R) Wireless WiFi Link 4965AGN) adapter 0x6: Ip: 0.0.0.0(0.0.0.0) (dhcp)
0:28:235: can't add ipaddress (192.168.178.2 - 255.255.255.0) on adapter=e Error=5
0:28:365: check adapter(This Atheros network Controller connects you to the network.) adapter 0xe: Ip: 169.254.9.156(255.255.0.0) (dhcp)
0:28:365: check adapter(Intel(R) Wireless WiFi Link 4965AGN) adapter 0x6: Ip: 0.0.0.0(0.0.0.0) (dhcp)
0:28:365: dhcp-adapter (14) with ip 169.254.9.156 found: first choice
0:28:412: search on addr: 169.254.9.1
0:28:755: ---> read environment <---
0:28:869: open ftp 169.254.9.1 port 21
0:28:885: recv: 220 ADAM2 FTP Server ready
0:28:885: send: USER adam2
0:28:885: recv: 331 Password required for adam2
0:28:885: send: PASS adam2
0:28:885: recv: 230 User adam2 successfully logged in
0:28:885: send: SYST
0:28:885: recv: 215 AVM EVA Version 1.3229 0x0 0x46409
0:28:885: send: TYPE I
0:28:885: recv: 200 Type set to BINARY
0:28:885: send: MEDIA SDRAM
0:28:885: recv: 200 Media set to MEDIA_SDRAM
0:28:885: send: P@SW
0:28:885: recv: 227 Entering Passive Mode (169,254,9,1,12,28)
0:28:885: open ftp data 169.254.9.1 port 3100
0:28:885: send: RETR env
0:28:885: recv: 150 Opening BINARY data connection
0:29:025: recv: 226 Transfer complete
0:29:135: environment successfully readed(1369 bytes)
0:29:135: send: USER adam2
0:29:135: recv: 331 Password required for adam2
0:29:135: send: PASS adam2
0:29:135: recv: 230 User adam2 successfully logged in
0:29:135: send: SYST
0:29:135: recv: 215 AVM EVA Version 1.3229 0x0 0x46409
0:29:135: send: TYPE I
0:29:135: recv: 200 Type set to BINARY
0:29:135: send: MEDIA SDRAM
0:29:135: recv: 200 Media set to MEDIA_SDRAM
0:29:135: send: P@SW
0:29:135: recv: 227 Entering Passive Mode (169,254,9,1,12,26)
0:29:135: open ftp data 169.254.9.1 port 3098
0:29:150: send: RETR count
0:29:150: recv: 150 Opening BINARY data connection
0:29:213: recv: 226 Transfer complete
0:29:322: environment successfully readed(152 bytes)
0:29:322: send: BYE
0:29:322: recv: 221 Thank you for using the FTP service on ADAM2
0:29:322: hardware-revision: 225
0:29:322: firmware-version: recovered=2
0:29:322: urloader-version: 1.3229 (4229)
0:29:322: oem: 1und1
0:29:322: provider:
0:29:967: set defaultsettings mtd4 (size: 2028)
0:29:967: ---> write image (mtdnand) <---
0:30:077: open ftp 169.254.9.1 port 21
[...]
Rich (BBCode):
0:09:669: AVM Berlin recover-tool-version:[RECOVER:557][IO_CSP:533] compiled at Aug 21 2018 on 12:43:38
0:09:669: Registry: SYSTEM\CurrentControlSet\Services\TcpIp\Parameters\DisableDHCPMediaSense=0
0:09:669: recover-firmware-id: 225
0:09:669: recover-firmware-version: 153.07.01
0:09:981: check adapter(This Atheros network Controller connects you to the network.) adapter 0xe: Ip: 0.0.0.0(0.0.0.0) (static)
0:09:981: get ipaddress from registry 192.168.187.20
0:09:981: check adapter(Intel(R) Wireless WiFi Link 4965AGN) adapter 0x6: Ip: 0.0.0.0(0.0.0.0) (dhcp)
0:09:981: no static compatible ipaddress found
0:10:091: exit: errorcode=-5
0:10:091: ----EOF---
Rich (BBCode):
0:06:788: AVM Berlin recover-tool-version:[RECOVER:557][IO_CSP:533] compiled at Aug 21 2018 on 12:43:38
0:06:788: Registry: SYSTEM\CurrentControlSet\Services\TcpIp\Parameters\DisableDHCPMediaSense=0
0:06:788: recover-firmware-id: 225
0:06:788: recover-firmware-version: 153.07.01
0:07:101: check adapter(This Atheros network Controller connects you to the network.) adapter 0xe: Ip: 10.1.1.17(255.255.255.0) (dhcp)
0:07:101: dhcp-adapter (14) with ip 10.1.1.17 found: first choice
0:07:116: search on addr: 10.1.1.1
[...]
Rich (BBCode):
vidar:/home/GitHub/YourFritz/eva_tools $ eval $(DISCOVER_DEMO=1 ./eva_discover FROM=10.1.1.254 TO=10.1.1.99 INTERFACE=vlan1 BLIP=1); [ "$EVA_FOUND" = "1" ] && nc $EVA_IP 21
Sending broadcast packets: ...........
220 ADAM2 FTP Server ready
USER adam2
331 Password required for adam2
PASS adam2
230 User adam2 successfully logged in
GETENV my_ipaddress
my_ipaddress 10.1.1.99
200 GETENV command successful
QUIT
221 Thank you for using the FTP service on ADAM2
221 Goodbye.
vidar:/home/GitHub/YourFritz/eva_tools $
Rich (BBCode):
Detected PXB4583el V1.2-2000
(AVM) EVA Revision: 1.3229
(C) Copyright 2005 AVM Date: Nov 30 2016 Time: 17:40:36 (0) 3 0x0-0x46409
[NAND:] 512MB TOSHIBA 4096 Pagesize 256k Blocksize 2048 Blocks
[SYSTEM:] GRX5 (ID 0x24 Revision 2) on 1000MHz/600MHz/666MHz
Eva_AVM ><set IP-Address to 10.1.1.99>==========================================================================
Ich bin letztens im Dialog mit einem Benutzer auch noch auf ein weiteres Problem aufmerksam gemacht worden, wenn man irgendeine Software für "EVA discovery" verwenden will (egal, ob es sich um das AVM-Programm oder eines meiner Skripte handelt). Das funktioniert aus einer virtuellen Maschine heraus nur dann, wenn man dort einen Netzwerk-Adapter verwendet, der mit dem Host-Adapter per Bridge verbunden ist. Ansonsten erreichen die UDP-Broadcast-Pakete ihr Ziel nie und auch die per Unicast gesendeten Antworten zerschellen dann gerne mal am NAT, was der VM-Host (zumindest bei VMware) als Alternative bereithält. Daß ein "host only"-Adapter (ebenfalls wieder bei VMware-Produkten) nichts bringt, sagt ja schon der Name.
==========================================================================
EDIT 08.05.2020:
Und für die meisten der neueren FRITZ!Box-Modelle noch ein ergänzender Hinweis (der steht zwar gefühlt auch in jedem zweiten Thread, wo es um Probleme beim Flashen - mit dem AVM-Recovery-Programm oder irgendwelchen anderen Tools - geht, aber hier war er tatsächlich nicht drin):
Das AVM-Programm schreibt i.d.R. als "Erfolgsmeldung" etwas in der Richtung: "Nach einem Neustart ist die neue Firmware installiert." (nicht wörtlich, aber sinngemäß) in sein Fenster ... das ist etwas unglücklich formuliert von den Autoren dieses Programms. Bei den Modellen, wo die Firmware ins RAM des Routers geladen und dort gestartet wird, ermittelt die soeben hochgeladene Firmware diesen Umstand ziemlich direkt nach ihrem Start (der aber auch mal 15 Sekunden und mehr dauern kann) und schreibt sich dann quasi selbst in den Flash-Speicher (und erst dann ist sie dauerhaft gespeichert). Anschließend wird der Router neu gestartet und nun wird die Firmware auch aus dem Flash geladen und initialisiert daher den Router "richtig" (sprich: das Schreiben in den Flash wird jetzt übergangen, weil es unnötig wäre).
Wer also dem Router nach der Meldung des Recovery-Programms nicht die Zeit läßt, daß er sich selbst neu starten kann und ihm unmittelbar nach der Meldung den Stecker zieht (entweder weil er die Meldung gar nicht zur Kenntnis genommen hat oder weil er sie als Aufforderung, den Router jetzt neu zu starten, interpretierte), der hat außer vergeudeter Zeit nur wenig erreicht ... immerhin hätte das AVM-Programm ihm aber schon erfolgreich die Einstellungen der FRITZ!Box zurückgesetzt. Nur müßte man dazu eher selten das Recovery-Programm bemühen, das ginge per GUI ja auch einfacher.
Das gilt zwar auch nicht für alle Router-Modelle (es hängt von den "inneren Werten" ab), aber außer einigen Repeatern und der 4040 / 4020 arbeiten die meisten FRITZ!Box-Modelle (für die es Recovery-Programme von AVM gibt, die Cable-Boxen gehören da - Stand heute - nicht dazu) inzwischen so - speziell wenn sie das FRITZ!OS in NAND-Flash speichern, weil dann meist erst das laufende OS die passende Behandlung für die verschiedenen Chips (beim Schreiben) sicherstellen kann. Ob das eigene Gerät nun diese Zeit zum Schreiben in den Flash braucht oder nicht, muß man entweder vorher ermitteln oder man läßt die Box eben nach der Meldung des AVM-Programms (oder auch nach dem Ende einer meiner Skript-Dateien, wenn man keine AVM-Firmware installieren wollte) noch 1-2 Minuten vor sich hin arbeiten. Länger sollte das Schreiben in den Flash-Speicher nicht dauern und wenn sie bis dahin noch nicht neu gestartet wurde, ist es mit einiger Sicherheit ein Modell, wo der Bootloader schon in den Flash schreibt und nicht erst das gestartete OS.
==========================================================================
EDIT 22.05.2020:
Das AVM-Recovery-Programm schreibt seinerseits auch noch zwei "Protokoll-Dateien" unter Windows. Die eine behandelt das Thema der FTP-Kommunikation mit der Box und heißt folgerichtig auch
ftp.log, während die zweite das ausgelesene Environment der Box beinhaltet und daher wohl auch environment.log genannt wurde. Für letztere legt das AVM-Programm dann sogar noch eine Sicherungskopie an, sofern es bei der Suche nach den Dateinamen von environment_00.log bis environment_19.log noch irgendeine Lücke erspähen kann - der erste freie Slot, der da gefunden wird, wird auch benutzt. Gibt es bereits alle 20 potentiellen Sicherungsdateien, wird keine weitere Kopie erstellt. Damit hat man aber - wenn man das Recovery-Programm nur selten benutzt - mit diesen Dateien so eine Art Historie, welche Box man wann mit dem Recovery-Programm angegangen ist.Wer sich jetzt fragt, warum er diese Dateien (vermutlich) noch nie gesehen hat, dem sei gesagt, daß AVM hier einen uralten Mechanismus zum Erzeugen der Protokoll-Dateien verwendet und daß dieser in früheren Windows-Versionen kein Problem hatte, die fraglichen Dateien direkt im Windows-Verzeichnis abzulegen. Startet man das Recovery-Programm von vorneherein mit
Run as administrator (im deutschen Windows vermutlich irgendwas mit Als Administrator ausführen - jeweils im Kontext-Menü des EXE-Files), klappt das mit dem Schreiben auch immer noch und man findet die Dateien dann direkt im Windows-Verzeichnis (meist C:\Windows, sicherer ist aber %SystemRoot%).Da es aber so gar keine gute Idee aus Security-Sicht ist, wenn einfach irgendwelche Programme in das Windows-Verzeichnis schreiben dürfen, ging Microsoft irgendwann mal hin und "virtualisierte" das Windows-Verzeichnis (das gilt auch für das Verzeichnis (bzw. die Verzeichnisse) mit den Programmen) dahingehend, daß die von "normalen Nutzern" vorgenommenen Änderungen an Dateien unterhalb des Windows-Verzeichnisses nur noch innerhalb ihres eigenen Benutzerprofils gespeichert wurden und damit andere Benutzer nicht in Mitleidenschaft gezogen werden konnten.
Daher findet man heutzutage diese AVM-Protokolle in aller Regel innerhalb des eigenen Benutzer-Profils - sie liegen hier im Verzeichnis
C:\Users\<benutzername>\AppData\Local\VirtualStore\Windows\ (das Laufwerk gilt natürlich nur bei "Standardinstallation" und im deutschen Windows verwendet Microsoft wohl auch Benutzer anstelle von Users), wobei für Art und Anzahl der Dateien das oben Geschriebene gilt.Wer also mit dem AVM-Programm so gar nicht klarkommt, kann auch mal einen Blick in die
ftp.log werfen - wenn man der Ansicht ist, ansonsten alles richtig gemacht zu haben, hilft einem ja vielleicht noch eine Meldung des Programm in dieser Protokoll-Datei auf die Sprünge ... manchmal ist es auch nur das falsche Interface, in das man ein Kabel gesteckt hat.EDIT: 24.07.2023
Apropo Kabel ... das falsche Interface kann man natürlich (zumindest, wenn man NICHT das AVM-Programm verwendet, denn das ignoriert m.W. Interfaces ohne Kabel) auch dann erwischen, wenn man ein Gerät mit WLAN und LAN verwendet (spez. irgendwelche Laptops, aber auch neuere PCs haben häufig WLAN-Hardware auf dem Mainboard) und dabei NICHT das WLAN deaktiviert. Wer also ein Gerät MIT WLAN verwendet, sollte doppelt prüfen (sofern nicht das AVM-Programm verwendet wird), ob er TATSÄCHLICH auf dem richtigen Interface versucht, mit der FRITZ!Box zu kommunizieren.
Zuletzt bearbeitet:
