[FAQ] AVM Repeater 3000 ax - die Fakten + Aha Effekt :-)

Exodus88

Aktives Mitglied
Mitglied seit
15 Jan 2012
Beiträge
2,357
Punkte für Reaktionen
677
Punkte
113
Da ich mir gerade einen Repeater 3000 ax geholt habe, hier die Infos die man von AVM nicht bekommt, bzw. die von den Herstellerangaben abweichen.

Hier der Link zum AVM Produkt - https://avm.de/produkte/fritzwlan/fritzrepeater-3000-ax/technische-daten/

Die erste Überraschung für mich war, dass beide 5 Ghz Module 160 Mhz unterstützen, dazu aber später mehr.

Der Repeater wurde mit der Firmwareversion 270.07.41ausgeliefert, und offiziell ist das die aktuelle Releaseversion, ein Update wird nicht gefunden.
Mit dieser Version unterstützt der Repeater zero wait DFS (mehr oder weniger)....

Zum Testen wurde der Repeater bei mir Zuhause mit meiner 6690 (7.29) als WLAN Bridge betrieben.
Nach dem Verbinden und Einmeshen und sofortiger Deaktivierung der Einstellungsübernahme sah es in der MESHÜbersicht so aus.

1sdfhsgsjgfdhklgfjlö.jpg

Die 6690 sendete auch nach dem Verbinden weiterhin mit 160 Mhz auf Kanal 104 (100-128)

2dfsgnmfhg,j.hgk.jpg

Dann zur ersten Überraschung... Der 3000ax unterstützt mit beiden Bändern 160 Mhz, und das gleichzeitig!

4dfbfgmhg,jhggfx.jpg

Zu diesem Zeitpunkt war der Repeater mit dem 5 GHZ II (100-128) Modul mit der Fritte verbunden.

3sdghsdgfmh,g.jpg

Und für die Clients steht das "theoretische langsamere" Ghz I (Kanäle 36-64) Modul zur Verfügung.

Und dann kommen wir zur zweiten Überraschung...

Wifi 6 fähigen Clients mit 160 Mhz Unterstützung steht die volle Bandbreite bei 2x2 Streams zur Verfügung, nicht nur die 1200 Mbit/s wie von AVM angegeben!

8cbnmfmhgfh,.jpg 9ufhudodzrs.jpg

Anschließend habe ich einen Kanalwechsel an der Fritzbox von Kanal104 auf 36 durchgeführt, nur um zu sehen, ob der Repeater den Sprung mitmacht und das Modul wechselt.

In der Theorie hat alles gut geklappt und der Repeater hat sich nun mit dem 5 Ghz Modul I mit der Basis verbunden.

5fdhdjfhklfglfsdsgfjjk.jpg

Jetzt kommen wir von der Theorie zur Praxis...

Natürlich wird hier vorab der Kanal untersucht, ob die Kanäle wirklich frei sind und der "zero wait DFS" Eintrag ist auch im erweiterten WLAN-Log zu finden.
Der Repeater sendet sofort auf Kanal 100-112 mit 80 Mhz und versucht die Kanäle 116-128 zu scannen. Wobei die Betonung auf "versucht" liegt....

6Bugsadgshdfgjkfhlk.jpg

Anders gesagt, er macht überhaupt nichts, die GUI für die Kanaluntersuchung friert ein und sieht auch 30 Minuten später noch so aus.
Auch diverse Versuche einen manuellen Kanalwechsel herbeizuführen schlugen fehl.

An dieser Stelle möchte ich mich gleich noch bei AVM recht herzlich bedanken, dass bei einer Releaseversion dieselben Probleme präsent sind, wie bei den Laborersionen 7.39 anderer Modelle.

Somit, wie bei den anderen Modellen, Stecker ziehen und neu Booten.... Nach 10 Minuten alles Paletti, so wie es sein soll, und es stehen auch hier den Clients wieder die volle Bandbreite zur Verfügung.

7fbdsfndgsjfdsgfh.jpg

Der Test als LAN-Bridge steht noch aus, und wird eingefügt.

Somit sind die Angaben von AVM falsch, solange ich keinen Denkfehler drin habe.

fffffhfdkgflkfglfg.jpg

Dank der 160 Mhz Unterstützung auf beiden 5 Ghz Modulen komme ich auf folgende Werte:

4804 Mbit/s (5Ghz Modul II)
2402 Mbit/s (5 Ghz Modul I)
573 Mbit/s (2,4 Ghz Modul)


Gruß

Roland
 
Zuletzt bearbeitet:
  • Like
Reaktionen: alexandi und Benares
Mittlerweile bin ich am finalen Standort des 3000 ax Repeaters angekommen und es sieht aktuell so aus...

0sdfgehertju.jpg

Der Weg dahin, war kein leichter und man muss auch das Netz verstehen können, was nicht immer logisch erscheint...

Aber fangen wir mal an. Der 3000 ax läuft als LAN-Bridge an einer 7590 ax und ersetzte eine 2400er. Der 2400er wird jetzt als WLAN-Bridge am Teich eingesetzt und der vorherige 1750e wurde ausgemustert.

Im Gegensatz zum WLAN-Bridge Modus wird hier kein "zero wait DSF" angezeigt, die Kanäle werden lt. Anzeige für 1 Minute gesperrt, dauert aber tatsächlich 10 Minuten bis der Sprung auf 160 Mhz erfolgt.

1dfghjfzkgulhl.jpg

Ich dachte, ich gönne dem 2400er das 5 Ghz Modul II, auf den Kanälen 100-128., was sich als eine ganz schlechte Idee herausstellte.

Theoretisch sollte der 2400er das machen, was der 3000 ax am 5 Ghz Modul 2 macht...
In der Praxis sieht es aber anders aus!?!

Solange der 3000 ax die Kanäle scannt, liefert er nur 80 Mhz, das macht der 2400er problemlos mit. Sobald der Scan fertig ist, reißt der 3000 ax auf und sendet mit 160 Mhz auf Kanal 100-128. Zeitgleich dreht der 2400er am Rad und reduziert die Bandbreite auf 40 Mhz.

2240040sdvdsfbhdgj.jpg

Die 40 Mhz belegt mir auch Wifi Analyzer, es handelt sich nicht um einen Anzeigefehler!

3dsfhgfdlöfghdf.jpg
2400 = letzter Eintrag, Bild stammt aus einem vorhergehendem Test, deshalb passen die Kanäle nicht.

Nach 30 Minuten immer noch keine Veränderung. Ich vermute, das bleibt ewig so.
Abhilfe schafft man nur mit einem Kanalwechsel am 3000 ax oder man wechselt den Heimnetzwerkzugang von Modul II auf Modul I.

Dann passts auch wieder, und der 2400er spuckt die 160 Mhz aus.

42400160izfuzdoutdotuc.jpg

EDIT: Der 1200 ax verhält sich an derselben Position wie vorher der 2400er Vorbildlich und schaltet selbstsändig auf 160 Mhz, nachdem die Kanaluntersuchung des 3000 ax abgeschlossen wurde - siehe >>> #25 <<< EDIT ENDE

Das 2,4 Ghz Modul kommt mir etwas schwächer im Vergleich zum 2400er. Als Referenz nehme ich die angebundenen 600er. Teilweise fehlen mir bis zu 50% an angezeigten Datendurchsatz. Evtl. lässt sich das noch verbessern, indem ich den 3000 ax etwas drehe oder verstellen. Evtl. pendelt sich das auch so noch ein.

Die Verbindung zum 2400er ist auch nicht gerade berauschend, ich hätte mir da mehr erwartet.
Vorher hatte ich die letzten Tage zwischen dem 2400er und dem 1750e eine kombinierte Datenrate von 900-1100 Mbit/s.
Aktuell liefert der 3000 ax zum 2400er 855 Mbit/s, obwohl bei dieser Kombination wesentlich mehr drin sein sollte.

Aber vielleicht lässt sich auch diesen noch durch drehen und Wenden optimieren, heute ging mir das Tageslicht aus.

Aktuell bin ich immer noch ein wenig hin- und hergerissen und muss noch viel ausprobieren, was möglich ist und was nicht.

EDIT: Erfahrungen aus #20 eingefügt.

Heute war es dann so weit, gedreht und gedreht und weitergedreht

Das beste Ergebnis sieht so aus...

Bruckdsgsedhrejz.jpg

Wobei der 3000 ax die beste Abstrahlung auf der Rückseite hat, da wo der Stromanschluss und die LAN-Anschlüsse sind.
Klingt zwar eigenartig, ist aber so...
Ist aber auch ungewöhnlich, da auf der Rückseite des Repeaters nur 2, der insgesamt 7 Antennen angebracht sind.
Ein Bild von der 3000 ax Platine samt geätzten Antennen gibt es hier zu sehen - https://refbox.de/news/repeater-3000-ax/

Nicht wundern, die temporäre Teststellung sieht aktuell so aus.

20221118_113110.jpg

In der Endlösung bekommt der Repeater eine IP65 Box, wie ich es schon einmal realisiert habe - https://www.ip-phone-forum.de/threa...rische-betriebssicherheit.312491/post-2489350

EDIT: Endlösung

20221119_152659.jpg

Die Verbindung im 2,4 Ghz zu den angebundenen Repeatern ist aber immer noch nicht so rosig, und dachte das einfach das Modul relativ schwach ausgelegt ist.
Dabei ist mir aber ein "Denk"Fehler unterlaufen... Die beiden 600er und auch der 2400er können im 2,4 Ghz Band knappe Brutto 600 Mbit/s, so ist der 3000 ax auch angegeben... Allerdings schafft das der 3000 ax nur mit wifi6 fähigen Geräten mit 2x2 Streams, die non ax Repeater brauchen dafür aber 4x4.

Im Nachhinein ist es dann logisch... die 600er und 2400er können bei einer Anbindung am 3000 ax max. 300 Mbit/s, da der Neuzugang ja nur 2 Spitalstreams unterstützt. Somit bin ich damit immer noch sehr gut bedient, was die Datenrate im 2,4 Ghz WLAN betrifft.

Das kann dann der 6000er besser, da wären wieder Bruttoraten von 600 Mbit/s drin und ist neben den fehlenden 2,5 Gbit/s Anschluss der zweite Nachteil.
Aber irgendwie geht man immer einen Kompromiss ein. Die Ideallösung wäre der Repeater 6000 mit 160 Mhz Unterstützung und somit die EierlegendeWollMilchSau. Aber leider wird so ein Produkt nicht von AVM angeboten.

EDIT:

Da das "Zusammenspiel" zwischen dem 2400er und dem 3000 ax bzw. ax und non ax nicht so richtig passt, habe ich eine "Pimp my Backhaulanbindung" Aktion durchgeführt und den 2400er gegen einen 1200 ax ersetzt.
Der Zuwachs der angezeigten Datenrate hat sich bis zu 50% verbessert.

1dfshgfdkgfhkfdsfh.jpg 2dfhrgfktzkzdfd.jpg

Gruß

Roland
 
Zuletzt bearbeitet:
Zero-Wait-DFS wird er ja nicht machen können, weil bei die Bandhälften unterschiedlichen Aufgaben zugeordnet sind. Was er machen kann, ist das von mir getaufte 'One-Wait-DFS' - dabei muss man nur eine Minute warten, indem man unter K116 schaltet und so den Bereich K100..112 mit 80 MHz belegt. Aber mit seinen 160 MHz Eigenschaften im backhaul und zu den Clients läuft der R3000ax dem R6000 ganz klar den Rang ab - wäre da nicht das lahme Doppel von 1 GbE-Schnittstellen, was ihn als Access-Point völlig ungeeignet erscheinen lässt.
Mithin wäre der 3000ax der erste Repeater überhaupt, der die 1110 Mbit/s Netto meiner ebenfalls 6690 zum Client bringen kann. Der 1200ax macht zwar auch die 160 MHz, braucht dazu jedoch nahezu die doppelte Zeit zum Transfer und halbiert etwa die Nettorate (muss umschalten Empfang/Senden)
 
  • Like
Reaktionen: SlurfyYT
Zero-Wait-DFS wird er ja nicht machen können...

Ja, nein oder vielleicht:D

Jetzt hast du mich schon so weit gebracht, an meinen eigenen Text zu zweifeln. :rolleyes:

Vor allem, da es seit der Inbetriebnahme im LAN-Bridge Modus keinerlei "zero wait DFS" Einträge mehr im WLAN-Log gab, nur die von dir erwähnte 1 Minuten Sperre (auch wenn die in Wirklichkeit 10 Minuten dauert.

ffffdfshfrtjfdzk.jpg

Um mein schlechtes Gewissen zu beruhigen, habe ich mich zu Hause eingewählt und einen Screenshot vom WLAN-Log der 6690 gemacht.

Hier ist eindeutig und sogar mehrmals der zero wait DFS Eintrag zu finden.

Screenshot_20221116_191450_Edge.jpg

Gruß

Roland
 
Aktuell liefert der 3000 ax zum 2400er 855 Mbit/s, obwohl bei dieser Kombination wesentlich mehr drin sein sollte.
Vergisst du vllt. gerade, dass der R2400 ein 2-Radio Repeater ist, der seine 1733 Mbit/s bei 4*4 ac etwa teilt im WLan-Modus? Da sind deine 855 Mbit/s eine recht gute Näherung. Du wirst in dieser Anordnung aber niemals einen ax-Client mit WiFi6 versorgen können - dazu müsste ein 3-Radio Repeater mit WiFi6 wie der R3000ax/R6000 direkt vor dem Client hängen. Den Fehler hat auch Gordon von AVM gemacht, indem er einen R1200ax an das Ende einer ac-Repeaterkette setzen will (
bei 1'23'' etwa) und so bevorzugt die ax-Clients bedienen will
 
Danke für deine Antwort.

Vergisst du vllt. gerade, dass der R2400 ein 2-Radio Repeater ist, der seine 1733 Mbit/s bei 4*4 ac etwa teilt im WLan-Modus? Da sind deine 855 Mbit/s eine recht gute Näherung.

Der 2400er schafft die 1733 Mbit/s aber auch mit 2x2 und 160 Mhz, aber darum geht es mir eigentlich nicht.

Vorher lief der 2400er im LAN-Bridge Modus, und daran per WLAN ein 1750e. Dabei war die kombinierte Datenrate in der MeshÜbersicht heute vor der Demontage bei 1.1 Gbit/s.
An dem Platz, wo vorher der 2400er war, werkelt jetzt der 3000 ax und der 2400er hat den Platz vom 1750e eingenommen und die angezeigte Datenrate liegt bei 855 Mbit/s.
Der 1750e hat nur 3x3 Streams und kann keine 160 Mhz, trotzdem war die Datenrate höher.

Auch so verhält sich die Anbindung bzw. Anzeige wie bei Pipi Langstrumpf "ich mache mir die Welt, wie es mir gefällt"...

Ist der 2400er mit dem 5 Ghz Modul I (Kanal 36-64) verbunden, zeigen die Geräte unterschiedliche max. Datenraten bzw. Mhz.

Screenshot_20221116-214047_Edge.jpg Screenshot_20221116-214129_Edge.jpg Screenshot_20221116-214235_Edge.jpg

Mit dem 5 Ghz Modul II (100-128) sieht es so aus...

Screenshot_20221116-215006_Edge.jpg Screenshot_20221116-215050_Edge.jpg Screenshot_20221116-215200_Edge.jpg

Eigentlich müsste hier die Verbindung mit 4x4 hergestellt werden und der 3000 ax und der 2400er sollten "nur" noch mit 80 Mhz Arbeiten, macht der 3000 ax aber nicht. Beider Geräte senden und empfangen mit 160 Mhz.

Screenshot_20221116-221244_Edge.jpg

Gruß

Roland
 
Ja, nein oder vielleicht:D

Jetzt hast du mich schon so weit gebracht, an meinen eigenen Text zu zweifeln. :rolleyes:
Nun, ich habe nicht vor, dich irgendworan zweifeln zu lassen, aber das Verhalten von Wlan ist inzwischen in Fleisch und Blut übergegangen ;-) Bei einem (fälschlich) 2-Band-Repeater wie dem R3000 zB. wird die Bandhälfte ab K100 aufwärts für die Anbindung zum Master genutzt (backhaul) und die Hälfte unter k100 (i.e. K36-64) als Bandhälfte zu den Clients. Der richtige Ausdrück wäre also 2-Radio-repeating auf 5 GHz.
Nun zu den DFS-Regeln: Wetterradar findet sich ab/über k116 und muss nach Vorschrift 10 Minuten lang abgesucht werden auf Primärnutzer. Beim R3000 (ohne ax!) und bei der 6660 ist das leider so geregelt, dass das Band ab k100 aufwärts bis Fw 7.21 im R3000 komplett abschaltet, weil damals noch mit 160 MHz verbunden wurde. Die 6660 hat es noch immer, weil AVM äußerst unclever den Schalter 80/160 MHz abgeschafft hat, so dass im oberen Bereich der Kanal 116 wegen 160 MHz immer belegt wird. Der Patch, der die 80 MHz wieder zulässt, ist übrigens meiner und sorgt in einigen seltenen Fällen für nicht mehr auftretende Fehler bei einigen Clients.
Zero-Wait kann also gar nicht gehen, weil es NULL WARTEZEIT bedeutet. Der Trick ist einfach folgender: nach Einschalten des Repeaters verringert man die Bandbreite im Bereich ab k100 aufwärts von 160 auf 80 MHz und setzt die WLan-Glocke auf Kanal 100 (oder 104, oder 108, oder 112) und erreicht damit, dass man unterhalb der 116 nur noch eine Minute statt der 10 Minuten die Kanäle zu Prüfungszwecken ausschalten muss.That's it! Deswegen auch mein ironischer Name 'One-Wait-DFS'
Die andere Bandhälfte sieht etwas anders aus: ein gut funktionierendes Zero-Wait wechselt mit 80 MHz auf den Kanal 36 und deckt den Bereich bis K48 im Spektrum ab. Das schöne an diesem Bereich ist, dass dort keine priorisierten Nutzer sein können, so dass durchgehend Daten gesendet werden können. Es gibt jetzt noch zwei Varianten bei Routern, die sich in dem Verbleib auf K36 unterscheiden, denn auf K100 braucht man auch nur 1 Minute zu warten - man teilt also bei Routern die 10 Minuten auf auf zwei Zeitscheiben (K36..48 und K100..112) auf. Geht beim R3000/3000ax/6000 natürlich nicht - dort müssen die beiden Bandhälften getrennt betrachtet werden. Ich sehe an deinem Log, dass AVM einen 'strenggenommen' Bock im Algorithmus hat - sie lassen im unteren Band die 160 MHz eingeschaltet. Es kommt aber zu Pass, das der Bereich von K52..64 auch nur 1 Minute ausfallen muss zur Prüfung, und das deckt sich zeitlich mit der oberen Bandhälfte; erneut wird der Begriff 'One-Wait-DFS' realisiert, wie ihn auch der Log darstellt.
Zu deiner 6690 und anderen gut funktionierenden 'Zero-Waitern': das ist echtes Zero-Wait, denn mit Einschalten des 5 GHz-WLans kann sofort gesndet werden auf K36 mit 80 MHz, weil dort niemand höher priorisiert ist. Später erfolgt dann der Wechsel auf einen anderen Bereich mit 160MHz, sofern dies gewünscht ist.
Noch ein Wort zur 7590ax, weil es genau hierhin passt: AVM hat dieser Box inwischen ja auch 'so etwas wie' Zero-Wait verpasst, macht dies aber nach meinem Dafürhalten ohne Sinn und Verstand; der Wechsel auf den Kanal 36 erfolgt zwar wie gewohnt, die Bandbreite wird aber absolut unnötigerweise auf 20 MHz runtergeschaltet - das macht Null Sinn. Man kann dies auch anders umschreiben: man ist die ersten 10 Minuten auf der Inhaus/Beta der 7590ax im 5 GHz-Bereich nur noch halb so schnell wie im 2,4 GHz-Bereich mit 40 MHz Bandbreite. Die einzige Erklärung für diesen Blödsinn kann ich mir nur vorstellen als einen Seiteneffekt von Kanal 140, der neuerdings mit 20 MHz abstrahlen kann, sofern er eingestellt wird. das kann man übrigens sehr schön in Homedale ansehen (da seteckt auch mein Know-How drin)
Vor allem, da es seit der Inbetriebnahme im LAN-Bridge Modus keinerlei "zero wait DFS" Einträge mehr im WLAN-Log gab, nur die von dir erwähnte 1 Minuten Sperre (auch wenn die in Wirklichkeit 10 Minuten dauert.

Gruß

Roland
Lieben Gruß
Jürgen
 
Nun, ich habe nicht vor, dich irgendworan zweifeln zu lassen...

Hallo Jürgen,

nochmals danke für deine Antwort.

Das mit dem "zweifeln" war ja nicht schlimm, ich könnte mich verlesen oder einfach vertan haben. Deshalb hatte ich das nochmals gecheckt.

Die Backhaul Anbindung eines 3000 (ohne ax) kann auch wahlweise mit dem 5 Ghz Modul I auf Kanal 36-64 erfolgen, je nachdem man die Basis einstellt.
Das wurde erst diese Woche diskutiert - https://www.ip-phone-forum.de/threads/repeater-1200ax-an-4060-6000er.314107/post-2495118
Und ist auch mit dem 3000 ax problemlos möglich.

Ich kann gerne diese Woche nochmals genau beschreiben, wie sich der 3000ax nach einem Neustart verhält. Heute werde ich es vermutlich nicht realisieren können. Aber ich vermute, das man auch hier unterscheiden muss zwischen den Einstellungen Autokanal und fest eingestellten Kanal... Zumindest gibt es bei den Laborversionen Unterschiede zum Verhalten.

Und zur 7590 ax und den Labor bzw. Inhausversionen. Die hat mehr als das Problem mit der Bandbreitenreduzierung auf 20 Mhz bei zero wait DFS...

Das von dir beschriebene Szenario mit den 10 Minuten mit 20 Mhz im 5 Ghz Bereich bezieht sich aber nur, wenn ein Kanal Fest >100 eingestellt ist.
Setzt du vor einem Neustart die Einstellung auf Autokanal, stehen dir nach einem Reboot nach 30 Sekunden 160 Mhz auf Kanal 36-64 zur Verfügung.

Wird mit dieser Laborversion einmal ein Radar erkannt und es erfolgt ein Wechsel auf einen niedrigen Kanal, kannst du nur mittels eines Neustarts die Box dazu bringen, sich wieder an einen Kanal >100 anzusiedeln.

Auch wenn ein bevorrechtigter Nutzer auf Kanälen <100 erkannt wird, wird die Bandbreite auf 20 Mhz reduziert und klebt auf only Kanal 36 fest - https://www.ip-phone-forum.de/threads/fritz-box-7590-ax-labor-7-39-sammelthema.312202/post-2493930

Da steckt von viel Nachholbedarf seitens AVM in diesen Geräten...

Gruß

Roland
 
@Exodus88 Wenn du

http://<repeater-adresse>/jason_boxinfo.xml

aufrufst, dann kannst du ablesen, an welchem Punkt des Entwicklungsprozesses AVM dann eine Zwischen-Final gezogen hat.

Ich glaube fast, da steht noch eine 270.07.(39-40)-99xxx.

Das ist übrigens kein Mangel, sondern einfach der Neueinführung geschuldet. Eine 7.29 oder 7.30 existiert für den 3000AX schlicht nicht, weil die Box erst danach entstanden ist.

Die Alternative wäre gewesen, die Box später zu produzieren.

Ansonsten spiegeln die Fehler - über alle Boxen und Repeater hinweg - schlicht den Entwicklungsstand wieder, mit dem AVM das OS 7.50 vorangetrieben hat.

Da das OS mit allen Produkten funktionieren soll, ist die Entwicklung nicht einfach.

Und nein: es ist bei Software nicht möglich, diese Fehlerfrei auszuliefern. Irgendwo wird immer etwas zu finden sein, das Probleme macht, nicht ganz rund läuft. Da ändert auch eine Releaseversion nichts, die letztlich nicht mehr ist, als der größte gemeinsame Nenner, an dem man neue Funktionen in die Öffentlichkeit gibt, um danach damit zu beginnen, einzelne gravierende Bugs zu fixen (7.51, 7.52.etc) oder auf der jeweiligen Basis dann zu beginnen, die nächste Neuentwicklung bei den Funktionen aufzusetzen.
 
Hallo Jürgen,

nochmals danke für deine Antwort.
...
Gruß

Roland
Moin Roland,
da ich schon recht früh den Repeater 3000 mein Eigen nennen durfte, ist mir sein Verhalten - auch bezogen auf die Bandbeschickung - sehr gut bekannt; damals hatte meiner sogar noch 160 MHz im 4*4-Zweig und zwang mich indirekt, das Thema DFS und TPC genauer zu beleuchten.
Die von dir beschriebene Einstellung auf Autokanal bei Routern nutze ich niemals, weil ich die maximalen 1000mW ab Kanal 100 auch nutzen möchte. Ist aber hier alles halb so wild - Unterbrechungen durch Primärnutzer gibt es hier kaum bis gar nicht.
Meine beiden Laptops mit AX200 und AX201 bekommen durchweg Brutto 2402/2402 Mbit/s und erreichen die 1105 Mbit/s mühelos, manchmal bis zu 1110. Flutscht also recht gut.
Ich nutze die 6690 und die 7590ac als Internetboxen und schaffe somit etwas Redundanz. Die gesamten anderen Geräte - und das ist wirklich nahezu die komplette AVM-Palette - immer nur nachgeschaltet als IP-Client oder kaskadierte Router. Die viele Repeater passen natürlich hinter jede Box, ganz gleich wie nun konfiguriert. Die letzten beiden Neuzugänge sind ein zweiter 7590ax ohne ISDN und eine 4060, obwohl ich mich schon recht früh gegen Router/Repeater ausgesprochen habe, die in ihrer Bandbreite auf 80 MHz 'kastriert' wurden, aber der Preis von 160€ war einfach zu verlockend. Ich meine, der 4060 war der erste Router (mit 2-Radio-Technik in 5 GHz), der von besagter One-Wait-DFS-Logik gebrauch machte - es geht ja nicht anders. Selbst bei Nutzung des 4060 als Access-Point mit 2,5 Gbit-Anbindung an der 6690 erreicht man bestenfalls 1201 Mbit/s Brutto an einem 2*2 Client, weil eben nur 80 MHz rüberkommen. Ich bin übrigens recht sicher, dass auch über die Entfernung die erreichbare Nettobitrate des 4060 an 2*2-Clients immer unterhalb der einer 6690 bleiben muss; in der Natur sind nun mal alle Vorgänge stetig und die Physik kannst du nicht einfach wegdiskutieren. Ergo: ein Repeater 6000 bzw der bauähnliche 4060 kann einen DSL-Nutzer mit knapp 300 Mbit/s voll entzücken, einen Kabel-Nutzer aber überhaupt nicht. Ausnahme: Nutzung von Wireguard-VPN, wo der 4060s sehr potent sein soll. Für mich stellt er also ein reines Studienobjekt dar und wird im Alltagseinsatz kaum genutzt. Mich nervt auch immer wieder, dass die 2,5 Gbit-Schnittstelle bei Umschaltung von Router-Modus auf IP-Client immer in den WAN- statt LAN-Modus geschaltet wird. LAN wäre im Client-Modus doch das, was ich gerne als Default hätte - muss also wieder aufstehen und LAN-Kabel in eine gelbe Buchse stecken, um den Zugriff auf das Internet wieder zu bekommen und dann manuell wieder auf LAN umstellen die blaue Buchse.
Abschließend gebe ich dir absolut recht mit der Aussage, es ist noch viel zu tun bis zur Release. Auch die falschen Bitraten, die AVM im WiFi6 Modus angibt, nerven nur noch. Ist das so schwierig, sich bei MCSindex.com anzusehen, wie die Bitraten berechnet werden? Es sind keine 2401 Mbit/s, sondern 2402! Marginalien sicherlich, aber auch irgendwie peinlich, finde ich. Nun gut, das war jetzt schon ein sanftes Abgleiten in die metaphysische Gedankenwelt, ich halte den fachlichen Austausch aller Gegebenheiten aber für unabdingbar und bin daher in Telegram recht aktiv, habe dort auch eigene Gruppen, in denen Ergebnisse/Firmwarelinks etc. bekanntgegeben werden (https://t.me/AVM_Beta) und bin auch in der AVM-Hauptgruppe recht aktiv (https://t.me/avm_de). Vllt. sieht man sich und/oder den Einen oder Anderen wieder :) Und jetzt ist erst mal Frühstück angesagt

Weiterhin frohes Schaffen und Grüße

Jürgen
 
@jstessi

Jetzt ging es mit dem Testen doch schneller als erwartet...

Vor dem Test, die Istwerte angesehen.
Kanaleinstellungen beim 3000 ax waren Kanal 44 + 100.
Dabei konnte die Kanalauslastung von Modul I seit gestern nicht aufgerufen werden, da hier immer gesucht wird. Die Anzeige von Modul II liegt fast am Anschlag, obwohl es keinerlei Fremdnetze in der Umgebung gibt.

1sdgesdtjrzkfgthfdsz.jpg

Auf Autokanal in beiden 5 Ghz Bändern eingestellt und neu gestartet...

Direkt nach dem Reboot sieht es so aus.

2srhfrdtjkftgklgfdgjd.jpg

Nach ca. 60 Sekunden so...

4dfsnfgmfhdkghkfdkh.jpg

Nach 10 Minuten Scannan dann wie von der Fritte gewünscht.

5fgnfkhghljhgdfgjk.jpg

Übrigens, auch hier gab es heute einen "zero wait DFS" Eintrag...

3fdbhdgjfdhkfdgdjdjm.jpg

Noch zu erwähnen, wie gestern arbeitete der angedockte 2400er Anfangs auf 80 Mhz, bis der Scan abgeschlossen wurde. Anstatt sich dann mit 4x4 und 80 Mhz bzw. 2x2 mit 160 Mhz zu verbinden, schaltet er runter auf 40 Mhz im 5 Ghz Bereich. Was er auch selbst mit 4x4 und 40 Mhz bzw. 866 Mbit/s bestätigt.

6dfghdshgdgjgk.jpg

Interessant wurde es, nachdem ich die Kanäle wieder fest vergeben hatte - 44 + 100 und einen Neustart durchführte.

Nach dem Reboot stand in den Funkeinstellungen in auf beiden Modulen "Autokanal" und ließ sich auch nicht aufklappen. Erst nach den 60 Sekunden, stellte die Box selbstständig um und zeigte die gewählten Kanäle an.

Ab da, war die Prozedur wie auf "Autokanal" identisch.

7gfjdfhkhghgl.jpg


@Daniel Lücking

hier die gewünschten Daten

Code:
<j:BoxInfo>
<j:Name>FRITZ!Repeater 3000 AX</j:Name>
<j:HW>270</j:HW>
<j:Version>270.07.41</j:Version>
<j:Revision>100749</j:Revision>
<j:Serial>xxxxxxxxxx</j:Serial>
<j:OEM>avm</j:OEM>
<j:Lang>de</j:Lang>
<j:Annex>-</j:Annex>
<j:Lab/>
<j:Country>049</j:Country>
<j:Flag>mesh_repeater</j:Flag>
<j:UpdateConfig>3</j:UpdateConfig>
</j:BoxInfo>

@Exodus88 Wenn du
Und nein: es ist bei Software nicht möglich, diese Fehlerfrei auszuliefern. Irgendwo wird immer etwas zu finden sein, das Probleme macht, nicht ganz rund läuft. Da ändert auch eine Releaseversion nichts, die letztlich nicht mehr ist, als der größte gemeinsame Nenner, an dem man neue Funktionen in die Öffentlichkeit gibt, um danach damit zu beginnen, einzelne gravierende Bugs zu fixen (7.51, 7.52.etc) oder auf der jeweiligen Basis dann zu beginnen, die nächste Neuentwicklung bei den Funktionen aufzusetzen.

Theoretisch bin ich bei dir, aber dann stelle ich mir die Frage, warum es Laborversionen gibt, die getestet und die Fehler zurückgemeldet werden.

Seit einem halben Jahr stehe ich mit AVM in Kontakt und habe die gravierenden Fehler im 5 Ghz WLAN bis ins kleinste Detail beschrieben, wann und sogar warum diese aufteten. Das ganze habe ich noch mit etlichen Bildern und Videos belegt, leider ändert sich nichts.
Auch auf höfliche Rückfragen, ob die Bandbreitenreduzierung bei der 7590 ax auf 20 Mhz während zero wait DFS gewollt oder ein Bug ist, gibt es keine Antwort - und das ist nur ein Beispiel von vielen... Es kommt immer nur ein Standardtext zurück. Bei einer letzten Mail an AVM hatte ich sogar vergessen, die Support Datei anzuhängen, obwohl ich das extra im Text erwähnt hatte, lt. Antwort ist es dem Mitarbeiter nicht mal aufgefallen, was mir ein gewisses Desinteresse widerspiegelt.
Und ich spreche hier nicht von optischen Mängeln, sondern von Fällen, wo das 5 Ghz Band Unbrauchbar wird.
Nach Radarerkennung gibt es eine Bandbreitenreduzierung auf 20 Mhz im 5 Ghz Band und kein Client findet mehr dieses Netz, nur angebundenen AVM Repeater sind noch verbunden, allerdings mit stark reduzierter Bandbreite.
Dann ist auch kein manueller Wechsel des Kanals mehr möglich, es hilft nur noch Stecker ziehen, das kann doch nicht die Lösung für ein Release sein - zumindest meiner Meinung nach. Betroffene Produkte sind z. Bsp. 7530 ax, 7590 ax und der 2400er Repeater, wo man im Forum genug belegte Probleme findet.
Daher habe ich von meiner Seite den Kontakt zu AVM abgebrochen, meine Zeit kann ich auch anderswo sinnlos verschwenden.

Gruß

Roland
 
Danke @Exodus88 . Mit einem Stand über 100.000 hätte ich nicht gerechnet.

Generell:
Zwischen "einen Fehler erkennen und melden" und "den Fehler beheben, liegen leider die realen Grenzen, die die Softwareentwicklung hat. Und das ist eben auch die Abarbeitung der Fehler durch Programmierer*innen sowie auch die Entscheidung dafür, wie priorisiert diese Fehler behandelt und abgearbeitet werden.

Der individuelle Fehler mag ja erkannt sein - aber ob der bei genug anderen Leuten so vorkommt, dass der priorisiert wird, ist eben nie genau zu sagen aus der Entfernung.
 
Ich bezweifle das ich der einzige Nutzer einer Laborversion bin, wo ein Radar erkannt wird - ab da ist alles mit jeden anderen Nutzer identisch.

Die einzige Ausnahme ist die Kanaleinstellung, da die meisten gerne die "Autokanal" Einstellung nutzen. Aber auch da kommt es zu den Problemen, wenn ein bevorrechtigter Nutzer erkannt wird... Dann geht nix mehr, nur noch den Stecker ziehen.

Aber spielt auch keine Rolle, Aufregen und/oder schimpfen bringt keinen Weiter.

Gruß

Roland
 
das kann doch nicht die Lösung für ein Release sein - zumindest meiner Meinung nach. Betroffene Produkte sind z. Bsp. 7530 ax, 7590 ax und der 2400er Repeater, wo man im Forum genug belegte Probleme findet.
Daher habe ich von meiner Seite den Kontakt zu AVM abgebrochen, meine Zeit kann ich auch anderswo sinnlos verschwenden.
Tja, Roland, was glaubst du, wie oft ich den Kontakt zu AVM schon gesucht habe und auch von den garvierendsten Fehlern berichtet habe, u.a. auch von den 20 MHz bei ZWDFS; daraufhin wurde es in der Antwort so dargestellt, als habe ICH ein Problem und man benötige von mir die Support-Daten. Man nehme es mir bitte nicht übel, aber entweder ist es das Maß der Beratungsresistenz, oder aber die internen Strukturen bremsen den Innovationsfluss von AVM gehörig aus. Das ist schade, denn AVM war IMO mal tonangebend in Sachen Router/Repeater im mittleren Kundensegment, hat aber nach meinem Dafürhalten langsam die Bodenhaftung verloren, weil zunehmend unpopuläre Entscheidungen getroffen werden und so in Sachen Mengenrelevanz versucht wird, ein Maximum für AVM rauszuholen - dabei verscherzt sich AVM aber seine guten Kundenkontakte und erwartet ernsthaft eine gute Zuarbeit bei Betatests. Was das letztlich werden soll, frage ich mich schon lange, und die nach Insidern wohl noch dieses jahr erscheinende 7.50 werde ich garantiert nicht auf meinen Produktivboxen einsetzen - es laufen schon Wetten, wann die ersten Fw-Versionen nach 7.50 kommen. Und die zukünftig fehlende Abschaltungsmöglichkeit für 2FA bei verschiedenen Funktionen wird wahrscheinlich meinen Absprung einläuten - oder holst du dir auch erst eine Pin, wenn du deinen internetfähigen Kühlschrank öffnen willst? :cool:

Gruß
Jürgen
 
oder holst du dir auch erst eine Pin, wenn du deinen internetfähigen Kühlschrank öffnen willst?
Da vergleicht jemand Äpfel mit Pferdeäpfeln ... und mancher wäre vermutlich froh, wenn der internetfähige Kühlschrank für die (sicherlich ebenfalls vorhandene) Seite mit den Einstellungen (oder auch für die Kommunikation mit der zugehörigen App oder deren Kommunikation mit irgendeinem Server im Internet) ausreichende Sicherheit bieten würde, damit nicht am Ende noch der Nachbar, bis zu dem das WLAN ja auch reicht (und auch ein PSK dafür ist schnell mal "rübergereicht") oder gar irgendwelche (unberechtigten) Nutzer per Internet an den Einstellungen drehen können und wahlweise der Inhalt komplett vereist oder verdorben ist (oder irgendwelcher Scheiß nachbestellt wird, was ja in Verbindung mit Online-Lieferdiensten auch bei vielen neueren Modellen möglich ist).

Denn die 2FA bei AVM schützt ja auch nicht den bloßen Zugang zu Informationen (obwohl ich mir das - als optional einstellbares Feature - auch wünschen würde), sondern lediglich die Veränderung von (sicherheitskritischen - wo man gerne auch noch über "Einzelfälle" diskutieren kann) Einstellungen im FRITZ!OS.

Während das also manchen offenbar "zum Absprung" veranlaßt, freuen sich andere darüber, daß außer einem Benutzernamen und einem Kennwort (die auch "gesnifft" werden oder sonstwie verloren gehen können) noch ein zweiter Faktor (und das sind immerhin drei verschiedene Optionen, wie man diesen zweiten Faktor auslösen kann) erforderlich ist, wenn sich jemand an (nochmal: sicherheitskritischen, denn vieles geht eben auch ohne 2FA-authentifizierte Session) Einstellungen des FRITZ!OS zu schaffen macht.

EDIT: Was aber auch nicht heißt, daß ich AVM's Implementierung der 2FA (im GUI) für "smart" halte (https://www.ip-phone-forum.de/threa...-39-–-sammelthema.312181/page-43#post-2476697) ... da besteht (ob in den letzten Labor-Versionen immer noch, weiß ich aber auch nicht genau) noch genug Nachholbedarf, damit die 2FA (speziell der TOTP-basierte zweite Faktor) nicht unnötigerweise zum Ärgernis für den Benutzer wird. Aber das ist eben "Verbesserungspotential" und nicht zwingend (für mich) ein Grund "zum Absprung".
 
Zuletzt bearbeitet:
Die Frage ist auch immer, ob sich ein Fehler reproduzieren lässt. Gerade bei Zero-Wait-DFS.

Ich hatte neulich das Problem, dass es die FRITZ!Box 5530 immer wieder in einen Neustart trieb. Irgendwann habe ich erkannt, dass mehrere Radar-Erkennungsereignisse hintereinander offenbar für so viel Prozessorlast gesorgt haben, dass die Box die Grätsche machte. Andere Nutzer berichteten von der 5590 ein identisches Verhalten, das wir letztlich dadurch beheben konnten, dass wir von der Autokanal-Einstellung weg gegangen sind und die unteren 5-GHz-Kanäle fest eingestellt haben.

AVM muss aber ersteinmal herausfinden, welche der vielen Funktionen und Prozesse diese Prozessorlast letztlich auslösen. Das kann länger dauern oder aber als "tritt bei zu wenigen Leuten auf, priorisieren wir niedriger, als ein anderes Problem, das aktuell mehr Leute melden".

Dazu kommt: Wer Software entwickelt und programmiert arbeitet für gewöhnlich nicht an der AVM-Kundenhotline.
 
Denn die 2FA bei AVM schützt ja auch nicht den bloßen Zugang zu Informationen (obwohl ich mir das - als optional einstellbares Feature - auch wünschen würde), sondern lediglich die Veränderung von (sicherheitskritischen - wo man gerne auch noch über "Einzelfälle" diskutieren kann) Einstellungen im FRITZ!OS.
Moin Peter,
offensichtlich wird es bisher als sicherheitskritisch angesehen, dass man das Abspeichern der Config mit 2FA belegt, obwohl dieses Abspeichern ja auf die intern vorbelegten Pfade geht; diese Diskussion ist also dringend überfällig, WAS, WANN eine 2FA haben sollte; ich teste u.a. auch an Boxen, die überhaupt nicht online sind - logischerweise melde ich nicht immer ein DECT-Fon an, um einen Code eingeben zu können. Ich bin nahezu sicher, dass dieses Thema seine Schatten schon vorauswirft.

Gruß
Jürgen
 
Was ist denn mit "Abspeichern der Config mit 2FA" genau gemeint? Ich kenne nur das Sichern der Einstellungen des FRITZ!OS und da wüßte ich jetzt nicht, daß das an irgendwelche "vorbestimmten" Ziele erfolgt (ich verstehe auch "intern vorbelegte Pfade" nicht wirklich) - ich erhalte das ganz simpel als (HTTP-)Download angeboten und wohin mein Browser das dann speichert, darüber hat das FRITZ!OS keinerlei Kontrolle mehr.

Da aber in der Sicherungsdatei jede Menge WIRKLICH sicherheitskritischer Daten stehen (allerdings in verschlüsselter Form: [Info] Wie funktioniert eigentlich die AVM-Verschlüsselung für die Einstellungen?, aber das verwendete "Kennwort" für diese Verschlüsselung ist eher schwach - ein MD5-Hash über das vom Benutzer angegebene Kennwort ist kaum mehr zeitgemäß), ist das Absichern des "Auslesens" solcher Daten in meinen Augen sogar ABSOLUT notwendig. Ansonsten reicht schon das Hijacken einer einzigen (nicht per 2FA gesicherten) Admin-Session, um die GESAMTE FRITZ!Box-Konfiguration und - meist noch viel wichtiger - dort hinterlegte Credentials für andere Dienste offenzulegen. So eine Session-ID ist auch schnell mal durch eine Sicherheitslücke auf einem Smartphone oder Tablet "erobert" - und sei es durch eine bösartige App, die solche Daten versucht zu ergattern.

Das ist also auch nicht nur "science fiction", was die Gefahren für eine SID angeht ... hier MACHT AVM ja (wieder in meinen Augen) schon (zu) viele Kompromisse ... denn wenn so eine Session erst mal per 2FA authentifiziert wurde, kann sie praktisch wieder "alles machen" und weitere Aktionen (die mit der ursprünglich autorisierten gar nichts mehr zu tun haben müssen) sind danach automatisch wieder erlaubt - wenn die Session regelmäßig "verlängert" wird, sogar wieder auf unbestimmte Zeit bzw. bis zum nächsten Reboot der Box.

Man muß/kann sich ja auch schon die Frage stellen, warum jemand so oft die Einstellungen sichert (und das dann nicht gleich "vollautomatisiert", denn die lassen sich auch über TR-064 auslesen), daß die 2FA (dabei) für ihn/sie zum Problem wird. Abgesehen von der Fax-Funktion fiele mir da (abseits der o.a. Implementierungs-"Fehler" beim 2FA-Dialog, was ja auch nur (m)eine persönliche Einschätzung ist) aus dem Stand nur wenig ein.

Ich werde ja nur immer hellhörig, wenn jemand die 2FA in Bausch und Bogen ablehnt ... DAFÜR hätte ich dann gerne (wenn's nicht zuviel Mühe bereitet) auch noch eine passende Begründung und - sofern es nicht nur als "persönliche Entscheidung" dargestellt wird, sondern den Sinn des Ganzen komplett in Frage stellt - am besten auch noch eine, die nicht nur das eigene Nutzungsverhalten berücksichtigt, sondern auch das des "Durchschnittskunden" (denn für den dürfte das bei AVM konzipiert werden).

PS:
Wobei ich gerade in der Dokumentation von AVM (https://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/x_auth.pdf) nichts finde, ob tatsächlich auch die TOTP-Methode über X_AVM-DE_Auth (also bei TR-064) unterstützt wird ... die Dokumentation dazu ist von 2016 und die TOTPs gibt es m.E. erst deutlich kürzer (im FRITZ!OS) - da müßte man glatt noch mal schauen, was da bei AVM mittlerweile GENAU implementiert ist.
 
Die Frage ist auch immer, ob sich ein Fehler reproduzieren lässt. Gerade bei Zero-Wait-DFS.

Hallo Daniel,

ich möchte dir nur ein Beispiel nennen...

7590 ax mit einer der letzten drei oder vier Laborversionen, seitdem die zero wait DFS Funktion eingeführt wurde.

Du stellst einen Kanal >100 ein, ein Radar wird erkannt, die Box macht den Sprung auf Kanal 36-64. Bis dahin ist alles noch vorbildlich, aber auch Schluss!

30 Minuten später versucht die Box selbstständig einen Kanalwechsel auf den voreingestellten Kanal >100, wobei ein Log Eintrag zu finden ist. Aber diesen Zeitpunkt ist leider Schicht im Schacht. Der Scan wird nicht ausgeführt und/oder die AVM programmierte Routine hängt sich auf.
Ab diesen Zeitpunkt ist kein Kanalwechsel mehr auf einen Kanal >100 möglich, nicht nach einer Stunde, auch nicht nach einem Tag und auch nach einer Woche nicht. Da hilft nur noch ein Neustart oder eben Stecker ziehen.
Wird dann auch noch ein Radar auf Kanal 52-64 erkannt, wird es noch schlimmer. Die Box reduziert die Bandbreite teilweise auf 20 Mhz auf only Kanal 32.

Auch bei der Einstellung Autokanal sieht es bedauerlicherweise nicht besser aus...

Jederzeit reproduzierbar, auf unterschiedlichen Fritzboxen (V1 und V2) und unterschiedliche Standorte. Egal als ob Master oder Client...
Wenn du Lust hast, schaust du mal im 7590 ax Laborthread vorbei, da findest du von mir massenhaft Beiträge, Bilder und sogar für Sonnenbrillenträger ein Video, das genau das aufzeigt, von dem ich die ganze Zeit schreibe.

So und in weit detaillierter Form hat das AVM von mir nach jeder Laborversion erhalten.

Gruß

Roland

EDIT: Links eingefügt
 
Zuletzt bearbeitet:
Aber vielleicht lässt sich auch diesen noch durch drehen und Wenden optimieren, heute ging mir das Tageslicht aus.


Heute war es dann so weit, gedreht und gedreht und weitergedreht :)

Das beste Ergebnis sieht so aus...

Bruckdsgsedhrejz.jpg

Wobei der 3000 ax die beste Abstrahlung auf der Rückseite hat, da wo der Stromanschluss und die LAN-Anschlüsse sind.
Klingt zwar eigenartig, ist aber so...
Ist aber auch ungewöhnlich, da auf der Rückseite des Repeaters nur 2, der insgesamt 7 Antennen angebracht sind.
Ein Bild von der 3000 ax Platine samt geätzten Antennen gibt es hier zu sehen - https://refbox.de/news/repeater-3000-ax/

Nicht wundern, die temporäre Teststellung sieht aktuell so aus.

20221118_113110.jpg

In der Endlösung bekommt der Repeater eine IP65 Box, wie ich es schon einmal realisiert habe - https://www.ip-phone-forum.de/threa...rische-betriebssicherheit.312491/post-2489350

Die Verbindung im 2,4 Ghz zu den angebundenen Repeatern ist aber immer noch nicht so rosig, und dachte das einfach das Modul relativ schwach ausgelegt ist.
Dabei ist mir aber ein "Denk"Fehler unterlaufen... Die beiden 600er und auch der 2400er können im 2,4 Ghz Band knappe Brutto 600 Mbit/s, so ist der 3000 ax auch angegeben... Allerdings schafft das der 3000 ax nur mit wifi6 fähigen Geräten mit 2x2 Streams, die non ax Repeater brauchen dafür aber 4x4.

Im Nachhinein ist es dann logisch... die 600er und 2400er können bei einer Anbindung am 3000 ax max. 300 Mbit/s, da der Neuzugang ja nur 2 Spitalstreams unterstützt. Somit bin ich damit immer noch sehr gut bedient, was die Datenrate im 2,4 Ghz WLAN betrifft.

Das kann dann der 6000er besser, da wären wieder Bruttoraten von 600 Mbit/s drin und ist neben den fehlenden 2,5 Gbit/s Anschluss der zweite Nachteil.
Aber irgendwie geht man immer einen Kompromiss ein. Die Ideallösung wäre der Repeater 6000 mit 160 Mhz Unterstützung und somit die EierlegendeWollMilchSau. Aber leider wird so ein Produkt nicht von AVM angeboten.

@Daniel Lücking

nochmal zurück zum besprochenen Thema 7590 ax und der "Reproduzierbarkeit"

Heute wurde bei mir Zuhause ein "echtes" Radar erkannt, ein Hubschrauber kreiste fast 15 Minuten über uns hinweg (Grund unbekannt).

Dabei wurde die 6690 Masterbox (grün) und die Clientbox (rot) in die DFS freien Kanäle gezwungen - soweit alles ok.

1hrtzkziöuzöfg.jpg

30 Minuten strebte die 7590 ax einen selbstständigen Switch auf den voreingestellten Kanal an, das ist der Part der eben nicht funktioniert. Die Box möchte, kann aber nicht - vermutlich ein Programmierfehler. Es wird nicht einmal ein Scan der Kanäle durchgeführt.

2sdagdjfgkhlgö.jpg

Die Probleme, die dabei entstehen, das 5 Ghz Band wird unbrauchbar und auch der angebundene Repeater verliert die Verbindung im 5 Ghz Band.

3fdshfklziö.jpg

Schaltet man jetzt das 5 Ghz WLAN ab und wieder an, weil ein manueller Wechsel herbeigeführt werden soll. Sieht es letztendlich so aus.

4ihougfizfiögol.jpg

Das ist auch kein Anzeigefehler in der GUI, sogar die AVM eigene WLAN App bestätigt die 20 Mhz, der WiFi Analyzer sowieso.

Screenshot_20221118_133907_FRITZ!AppWLAN.jpg Screenshot_20221118_133923_WiFiAnalyzer.jpg

Evtl. kannst du ja deine Kontakte zu AVM bei Gelegenheit mal in Anspruch nehmen, und dieses Thema ansprechen - aber nur wenn es keine Umstände macht"

Gruß

Roland
 
Zuletzt bearbeitet:

Neueste Beiträge

Statistik des Forums

Themen
244,695
Beiträge
2,216,686
Mitglieder
371,314
Neuestes Mitglied
Gjorstn
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.