[Sammlung] FRITZ!Repeater 3000 - 2400 - (1750E) - 1200 - 600 - Inhaus/Labor ab 7.19

Hi...bin weiter gekommen, da muss noch mehr umgestellt werden, nicht nur Firewall aus und die IP-Daten/DNS-Daten fest vergeben........

2021-05-16 18_30_10-Netzwerkverbindungen_1.png2021-05-16 18_30_52-Einstellungen_2.png

nun hat es auch geklappt mit der Recovery.exe....

2021-05-16 18_37_52-FRITZ!Box 6591 Cable.png so läuft es wieder richtig unter 7.20
 
Zuletzt bearbeitet:
  • Like
Reaktionen: Karl.
Darum habe ich die Bilder eingestellt, im 2.Bild die Einstellung unter WINS passte nicht..

die Einstellungen in den beiden Bildern sind so gültig, damit es mit der Recovery.exe auch klappt
 
Ja, das mit NetBIOS hab ich schon mal gelesen. Wobei es in den aktuellen Howtos in der AVM Wissensdatenbank nicht mehr drin steht, dass es aktiviert sein muss. Das ist sicher ein wertvoller Hinweis.
 
Es gibt keine belegbaren Anzeichen dafür (als vorsichtiger Mensch beschränke ich das trotzdem auf meinen eigenen Kenntnisstand, wobei ich auch keinen anderen Fall wüßte, wo das jemand auf Probleme in den NetBIOS-Einstellungen zurückgeführt hätte), daß das AVM-Recovery-Programm IRGENDETWAS mit den NetBIOS-Einstellungen zu tun hat. Ohne Kenntnis, was da VORHER in der Seite bei den Netzwerk-Einstellungen stand, kann man auch schlecht beurteilen bzw. mutmaßen, wie sich das auf die Suche des Recovery-Programms nach der Box ausgewirkt haben könnte.

Aber daß da grundsätzlich irgendeine zusätzliche Einstellung notwendig wäre (schon das mit der festen IP-Adresse ist letztlich nur die allerletzte Lösung, die in sehr vielen Fällen auch nicht erforderlich ist), kann man mit einiger Sicherheit (oder meinetwegen auch "Wahrscheinlichkeit") ausschließen und wenn bei AVM irgendetwas zu NetBIOS gestanden haben sollte, dann vermutlich auch eher im Zusammenhang mit den SMB-Freigaben und nicht mit der Anwendung des Recovery-Programms.

Ja ... ich wage sogar die Behauptung, daß das AVM-Recovery-Programm auch bei (fast) jeder anderen Einstellung auf der WINS-Registerkarte verwendet werden kann - aber ich wäre schon gespannt darauf, welche Einstellung genau das sein sollte, die eine erfolgreiche Anwendung dieses Programms letztlich verhindern könnte. Die Mechanismen, mit denen das Programm nach der Box sucht (UDP-Broadcast auf Port 5035 und TCP-Zugriff auf Port 21 für FTP) sind eigentlich sehr gut bekannt ... und da es nicht um Namensauflösungen geht und auch nichts mit irgendwelchen SMB-Freigaben zu tun hat, gibt es keinen logisch begründbaren (bekannten) Zusammenhang zwischen NetBIOS und diesem Programm (dessen "Rumpf" auch nicht wirklich modellspezifisch ist - erst der FTP-Dialog unterscheidet sich dann je nach Modell).
 
und wenn bei AVM irgendetwas zu NetBIOS gestanden haben sollte, dann vermutlich auch eher im Zusammenhang mit den SMB-Freigaben und nicht mit der Anwendung des Recovery-Programms.
Nöö, da ging es schon ums Recovery, hier am Beispiel einer 7113:

Wie gesagt, ist lange her, und in den aktuellen Anleitungen auch nicht mehr drin.
 
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---
 
Zuletzt bearbeitet:
  • Like
Reaktionen: frank_m24
Er meint sicherlich das was zwischen Fritzbox und Router besteht (5GHz II).
 
was zwischen Fritzbox und Router besteht (5GHz II).
wenn du den Repeater meinst dann ist es Band1, Band 2 geht doch dann mit max. 866MBit/s zum Client ;)

Das ist auch so ein Schmu beim 3000'er.
Ist er über >Kanal 100 mit der FB verbunden, kann er dann nur nur max 866, wogegen er mit <Kanal100 mit der FB verbunden ist, dann theoritsch 1733 könnte.
Praktisch aber nicht möglich, da ja nun kein 160Mhz-Band mehr da ist.
Beim 6000'er genau der gleiche Mist
 
Hi,

also bei mir war mein 1. 3000er immer mit 1,3GBit/s auf 5GHz Band 1 mit der Fritzbox verbunden und mit 866MBit/s auf 5GHz Band 2 zum PC...... nun habe ich ja diesen 3000er gegen den 6000er ersetzt... und der ist auch wieder mit 1,3GBit/s verbunden, gibt aber 1,7GBit/s weiter an den PC...
Diese Raten sind auch abhängig,wie weit er von der Box weg ist und welche sonstigen widrigen Umstände da sind.....
Mein 2. 3000er steht fast im gleichen Abstand,wie der 6000er und hat aber ne dicke Wand dazwischen.. und der hat generell max. 520Mbit zur Box....
 
Wenn der 3000er über LAN Kabel mit der Fritzbox verbunden ist, stehen dem Client zweimal das 5 GHz zu Verfügung.

Über WLAN leider nur einmal, da das andere Netz zwischen Repeater und Fritzbox funkt. Ich hatte z.b. einen festen Kanal (104) eingestellt und habe 1300 erreicht und das mit 80 MHz.
Habe mich aber trotzdem für eine LAN-Kabel Anbindung entschieden, da die Aussetzer im IP-TV durch die Radarerkennung nicht schön waren.
 

Anhänge

  • 20210517_190840.jpg
    20210517_190840.jpg
    203.4 KB · Aufrufe: 23
  • 20210517_190912.jpg
    20210517_190912.jpg
    104.2 KB · Aufrufe: 23
@Olga66 ....ja gut, aber was bringt das weiter? Dann ist per Lan die Verbindung bis zum Repeater zwar stabil, aber dann weiter über Wlan und 5Ghz auch nicht im oberen Bereich....
 
Das eine Bild zeigt, dass ich zwei Bänder habe eins im unteren und im oberen Bereich eins davon geht immer. ;)
 
...nicht unbedingt, dann musst Du das eine Band im unteren Bereich unterhalb von Kanal 48 platzieren, sonst greift auch da die Radarerkennung ;)
 
Das ist richtig aber wie du auf dem zweiten Bild siehst habe ich die Fritzbox auf Automatisch gelassen, demzufolge legt sie einen im unteren und einen im oberen Bereich an (egal welcher Kanal).
 
Der 6000er dagegen wohl nicht.
Wieso?
Ist es nicht die bei Heise erwähnte Kombination IPQ8074A mit QCN 5024/5054.
Dann sollte doch dies hier zutreffen und 160MHz auch unterstützen können: http://www.bitswrt.com/11AX

Ist mir halt nur schwer vorstellbar, daß neue ax-fähige Chips keine 160MHz unterstützen, aber wenn du meinst wirds schon so sein, bin nur äußerst verwundert und erstaunt.
 
Zuletzt bearbeitet:
Wo soll ich nachschauen um dir ein Ergebnis liefern zu können, im 3000er oder in einem Client der dort angebunden ist?
1750e, 1160 & Galaxy 7 (40 & 80) nichts von 160 zu lesen.
 
Zuletzt bearbeitet:
@ Olga66.... wenn Du beide auf Auto lässt, dann verbindet er auch beide auf andere Kanäle, nur gibt es mehr Kanalwechsel,wenn mehrere Netze da sind und sich eventell gegenseitig stören könnten. Das ist erst mal unabhängig von der Radarerkennung. Diese greift aber schon im unteren Band ab Kanal 48, also wird bei Radarerkennung auch der untere Kanal gewechselt,und somit kommt es zu einer Unterbrechung...stattdessen,solltes Du das untere Band "fest" auf einen Kanal unterhalb 48 setzen,dann hast Du keine Unterbrechung bei Radrerkennung!!
 
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.