Ich weiß auch nicht mehr genau, wann EVA auf den Plan trat ... aber diese Box stammt aus dem Jahr 2007 (letztes Update 2009) und verwendet wohl auch noch einen 2.4er-Kernel(?) - da mußte beim Update auf 2.6 erst mal das gesamte Layout des Flash-Speichers angepaßt werden
(EDIT: EVA wurde wohl doch noch früher "geformt" aus der Rippe und die 7113 hatte vielleicht auch von Beginn an einen 2.6er-Kernel ... das ist nach so langer Zeit schwierig zu ermitteln, was 04.38 für einen Kernel verwendete.)
Aber ich nehme zur Kenntnis, daß da bei AVM wirklich mal etwas zu den Einstellungen auf dieser Registerkarte stand ... aber ich halte das auch eher für Übereifer der Autor:innen dieses Artikels, wo einfach komplett die Netzwerk-Konfiguration beschrieben wurde.
Ein weiteres Indiz für diese Annahme ist für mich die Tatsache, daß da auch eine (vollkommen überflüssige) Konfiguration eines DNS-Servers beschrieben ist ... denn ich denke mal, daß Einigkeit darüber besteht, daß die FRITZ!Box (die ja nach AVM-Wunsch als einzige direkt per Kabel mit dem PC verbunden sein soll) da gar keinen DNS-Server bereitstellt und auch keine irgendwie geartete Namensauflösung erfolgt (die Box wird ja nicht als "fritz.box" o.ä. gesucht) bzw. erfolgen KANN.
Ähnliches gilt auch für die Abfrage der LMHOSTS ... das wären dann - analog zur
hosts
-Datei - die Namen von SMB-/NetBIOS-Servern hinterlegt, wenn es keinen Server (und keinen "elected master browser") gäbe und trotzdem keine Namensauflösung per Broadcast, sondern über eine feste Zuordnung von Namen zu IP-Adressen erfolgen soll. Alles Dinge, die mit dem Recovery-Programm gar nichts zu tun haben. Eigentlich gilt sogar dasselbe für die NetBT-Einstellungen, was schon beim DNS-Server richtig war ... da es (bei AVM-"Verkabelung") gar kein weiteres Gerät am Ethernet-Adapter gibt und die FRITZ!Box nach den Anweisungen des Programms auch keinen Strom haben soll, KANN da auch keine Komponente aktiv sein, die IRGENDETWAS mit NetBT zu tun hat. Das Einzige, was da überhaupt kommuniziert, ist nun mal der Bootloader selbst ... und wer hätte schon mal von NetBT-Support in EVA gehört?
EDIT: Das gilt eigentlich sogar für die Einstellung eines "Standard-Gateways" ... bei der geforderten Verkabelung (und den verwendeten Adressen) ist das ohnehin die FRITZ!Box, die aber gar keinen Strom hat. Und wenn es tatsächlich mal um ein (IPv4-)Paket geht, was lokal nicht zugestellt werden kann, dann greift nun mal auf dem Client auch das Protokoll zur Ermittlung von L2-Adressen, um die Gateway-Adresse überhaupt in eine MAC-Adresse aufzulösen ... aber auch auf das dann fällige ARP-Paket wird die FRITZ!Box nur dann antworten, wenn sie tatsächlich auch läuft (zumindest im Bootloader). Bleibt trotzdem die Frage, warum das Recovery-Programm irgendein IPv4-Paket erzeugen sollte, was nicht für die lokale Verteilung gedacht ist - erst recht angesichts der ansonsten von AVM empfohlenen IPv4-Settings und bei einer FRITZ!Box, die in EVA auf die Adresse 192.168.178.1/24 hört.
Wobei das mit der Maske nicht mal sicher ist - ich denke nicht, daß der minimale TCP-Stack in EVA der Box überhaupt die Behandlung nicht-lokaler Gegenstellen (also die Verwendung eines Gateways) erlaubt. Die Box selbst sucht ja (in EVA) auch bei FTP nicht selbst per ARP nach irgendwelchen Adressen ... auch das zeigt schon der Wireshark-Mitschnitt - letztlich startet sie ohnehin keine Verbindungen von sich aus, sondern sie reagiert nur auf einkommende Verbindungen, wo sie sogar schon die MAC-Adresse des jeweiligen Absenders kennt.
Aber wenn man das nicht glaubt, kann man ja mal spaßeshalber
NetBIOS over TCP/IP
in den Einstellungen deaktivieren und wenn man's auf die Spitze treiben will, auch noch in der Firewall alle ausgehenden Verbindungen zu den UDP-Port 137-139 (das wäre dann NetBT bzw. bei 139 käme noch TCP dazu) bzw. TCP-Port 445 (da wird seit Windows 2000 die SMB-Kommunikation direkt abgewickelt) untersagen.
Wenn danach das Recovery-Programm immer noch funktioniert (ich habe es sowohl für das der 7113 als auch der 7490 überprüft - beides mit einer 7412 als "UDP-Responder" mit der falschen Versionsnummer), dann KANN das einfach nichts wirklich mit NetBT oder SMB zu tun haben.
Wer will, kann auch die Bindung von "File and Printer Sharing for Microsoft Networks" und "Client for Microsoft Networks" an den entsprechenden Ethernet-Adapter aufheben (einfach die Checkbox an der von AVM beschriebenen Stelle - da, wo man ansonsten IPv4 auswählen soll - deaktivieren) und dann findet da ebenfalls kein Traffic mehr statt, der mit NetBIOS in Verbindung zu bringen wäre.
Wie gesagt ... ich habe extra mal das Recovery-Programm für die 7113 vom AVM-Server geladen und dessen Aktivitäten analysiert (mit Wireshark und
procmon
) - bis zum FTP-Dialog zum Auslesen von Environment und Countern ist da praktisch kein Unterschied zu heute zu sehen ... außer ggf. bei einer etwas abweichenden Behandlung von UDP-Broadcasts, wenn das Interface schon eine Adresse aus 192.168.178.0/24 hat - dann wird offenbar zusätzlich zum Broadcast noch ein Unicast-Paket an die 192.168.178.1 auf Port 5035 gesendet, was beim Vergleich mit dem Recovery-Programm der 7490 nicht zu sehen war.
Mein Netzwerk-Adapter hat dabei (ständig) eine Adresse 192.168.178.14/24 und 192.168.188.14/24 als sekundäre Adressen gesetzt - nur für den Zugriff auf startende FRITZ!Boxen (oder -Repeater) - und parallel dazu als primäre noch eine aus dem hier verwendeten LAN-Segment - was keine Überschneidungen mit irgendeinem im FRITZ!OS vorkommenden IP-Segment hat.
Warum will ich hier so genau sein? Ich denke mal, den meisten Lesern ist am ehesten damit geholfen, wenn sie hier die tatsächlich notwendigen Einstellungen nachlesen können und nicht, wenn hier noch jede Menge anderer, aber vollkommen nutzloser Einstellungen ventiliert werden (wie ein
debug bin
beim FTP-Dialog).
Ich verstehe auch, wenn jemand nach einer Änderung an einer der Einstellungen einen Erfolg verzeichnet und diesen dann seiner Änderung zuschreiben möchte ... nur muß das eben nicht stimmen und daher sollte man solche Annahmen bis zum "Beweis" ihres Wahrheitsgehalts auch immer nur als These verstehen/äußern. Ein (Anscheins-)Beweis könnte z.B. darin bestehen, daß man diese Einstellung wieder ändert (oben habe ich das komplette Deaktivieren von NetBT getestet) und daß danach dann das Recovery-Programm nicht mehr funktioniert.
Nur müßte man dazu halt wissen, was man einstellen muß/soll, DAMIT das nicht mehr funktioniert - ich konnte es (s.o.) nicht mal bei deaktiviertem NetBT und mit gesperrter Firewall (die bei einem öffentlichen Profil ohnehin (und zwar auch schon vor Windows 7) NetBT/SMB blockieren würde, wenn man die MS-Einstellungen nicht geändert hat) erreichen, daß die startende FRITZ!Box (obendrein noch über zwei Switches mit VLANs - Netgear GS-105E und HP Procurve) vom Recovery-Programm (sowohl unter W10 als auch unter einer alten W7-VM) nicht gefunden wurde.
Ja, es gibt bisher wenig Erfahrungen mit dem AVM-Recovery-Programm für einen WLAN-Repeater 6000 ... schließlich hat AVM das Programm auch erst kürzlich auf die Menschheit losgelassen. Und ebenfalls ja, es könnte hier einen Unterschied zu den anderen Recovery-Programmen geben ... auch wenn das auf den ersten Blick nicht einleuchtend erscheint. Aber auch dann sollte eine Behauptung wie oben, daß die NetBT-Einstellungen ebenfalls "stimmen" müssen, ja jederzeit nachprüfbar sein, weil das dann eben auch reproduzierbar wäre. So, wie das für mich derzeit aussieht, wird hier Koinzidenz mit Kausalität verwechselt (post hoc ergo propter hoc).
Code:
0:03:060: AVM Berlin recover-tool-version:[RECOVER:213][IO_CSP:122] compiled at Feb 18 2008 on 17:16:29
0:03:060: Registry: SYSTEM\CurrentControlSet\Services\TcpIp\Parameters\DisableDHCPMediaSense=0
0:03:060: recover-firmware-id: 129
0:03:060: recover-firmware-version: 60.04.67
0:03:060: recover-urloader-version: 393.eva
0:03:160: check adapter(Marvell Yukon 88E8056 PCI-E Gigabit Ethernet Controller) adapter 0xd: Ip: 192.168.168.129(255.255.255.0) (static)
0:03:160: compatible ipaddress (static) found: 192.168.178.14 on adapter 0xd
0:03:200: search on addr: 192.168.178.1
0:03:530: ---> read environment <---
0:03:630: open ftp 192.168.178.1 port 21
0:03:660: recv: 220 ADAM2 FTP Server ready
0:03:660: send: USER adam2
0:03:660: recv: 331 Password required for adam2
0:03:660: send: PASS adam2
0:03:660: recv: 230 User adam2 successfully logged in
0:03:660: send: SYST
0:03:660: recv: 215 AVM EVA Version 1.2834 0x0 0x47409
0:03:660: send: TYPE I
0:03:660: recv: 200 Type set to BINARY
0:03:660: send: MEDIA SDRAM
0:03:660: recv: 200 Media set to MEDIA_SDRAM
0:03:660: send: P@SW
0:03:660: recv: 227 Entering Passive Mode (192,168,178,1,12,0)
0:03:660: open ftp data 192.168.178.1 port 3072
0:03:660: send: RETR env
0:03:660: recv: 150 Opening BINARY data connection
0:03:900: recv: 226 Transfer complete
0:04:000: environment successfully readed(1408 bytes)
0:04:000: send: USER adam2
0:04:000: recv: 331 Password required for adam2
0:04:000: send: PASS adam2
0:04:000: recv: 230 User adam2 successfully logged in
0:04:000: send: SYST
0:04:000: recv: 215 AVM EVA Version 1.2834 0x0 0x47409
0:04:000: send: TYPE I
0:04:000: recv: 200 Type set to BINARY
0:04:000: send: MEDIA SDRAM
0:04:000: recv: 200 Media set to MEDIA_SDRAM
0:04:000: send: P@SW
0:04:000: recv: 227 Entering Passive Mode (192,168,178,1,12,3)
0:04:000: open ftp data 192.168.178.1 port 3075
0:04:000: send: RETR count
0:04:000: recv: 150 Opening BINARY data connection
0:04:220: recv: 226 Transfer complete
0:04:320: environment successfully readed(153 bytes)
0:04:320: send: BYE
0:04:320: recv: 221 Thank you for using the FTP service on ADAM2
0:04:320: hardware-revision: 209
0:04:320: firmware-version: 137.06.83
0:04:320: urloader-version: 3834
0:04:320: oem: avm
0:04:440: incompatible partitionsize mtd3 (0x40000,0x440000) partitionsize =4194304 byte (no support)
0:04:550: exit: errorcode=-7
0:04:550: ----EOF---