[Info] FRITZ!Box 7490 Firmware FRITZ!OS 06.80 (23.01.2017)

[sicomet]

Oh sorry ja passt DANKE...

 

[HabNeFritzbox]

Und was hat es mit der Firmware zutun?

 

[page]

Mit Version 6.00 wird die aber noch ganz anders spucken

sorry war ein Zahlendreher

 

[DerJacky]

Mal eine Frage zum Wlan Steering

Wie kann ich es erreichen dass sich mein fire tv immer im 5ghz ac modus anmeldet?

Im 2,4 Ghz Modus ruckeln die Filme nämlich...
Hatte vorher das 5Ghz Netzwerk anders benannt, dann klappte das natürlich.
Aber für Wlan Steering müssen die Netze ja gleich heissen und man kann am Endgerät ja nicht nehr entscheiden welches Netz genutzt wird (und im Falle des Fire Tvs muss es halt das 5Ghz Netz sein).

 

[ralph.sprenger]

das 5Ghz Netzwerk anders benannt, dann klappte das

So geht wohl der einzige Weg am ftv Stick.

 

[DerJacky]

So geht wohl der einzige Weg am ftv Stick.

Aber dann geht ja kein wlan steering und das ist an der 6.80 ja die hauptneuerung. Für das steering müssen beide Netze den gleichen Namen haben.

Es wäre doch ein leichtes für AVM einen Menüunterpunkt einzubauen bei dem man beim verbundenen Wlangerät einstellen kann, mit welchem Netz verbunden werden soll.

Klar wenn man das dann bei allen macht ist das steering sinnlos.
Aber bei mir ist es 1 Wlan Client von ca. 20.

Gesendet von meinem SM-T700 mit Tapatalk

 

[PeterPawn]

Festtackern auf ein Band bei gleichzeitigem Steering für andere Clients ist wohl (noch?) nicht ... dafür hätte AVM das Steering z.B. mit einer weiteren (gemeinsamen) SSID realisieren können, wenn man verschiedene SSIDs für die beiden APs setzt. Ungefähr so, wie das Gastnetz ebenfalls "zusätzlich" als Slave angehangen wird auf den APs für die beiden Bänder (wobei mein WLAN-Scanner das Gastnetz auf 5 GHz gar nicht findet, wenn es im 2,4 GHz-Band aktiv ist - aber das kann am Scanner liegen, die Konfigurationsdatei - /var/tmp/wlan_dynamic.cfg - enthält zumindest die Rolle für beide APs).

Da AVM sich dagegen entschieden hat, wird wohl irgendetwas nicht machbar sein (der verwendete "lbd" für die Steuerung des Steerings ist wohl eine Eigenentwicklung oder zugekauft, entsprechende OpenSource-Pakete kenne ich zumindest nicht und habe auf die Schnelle auch kein solches gefunden in einer Suchmaschine), wenn der zuständige Daemon nicht das "master"-Interface steuern kann, denn das "Vertreiben" eines Gerätes aus einem Band soll ja der Beschreibung nach durch Deauthorization und "Totstellen" umgesetzt sein, bis sich das Gerät im anderen angemeldet hat.

Theoretisch müßte aber eigentlich zumindest die Vergabe einer weiteren SSID (dann wieder getrennt für beide AP) über ein zusätzliches Slave-Interface denkbar sein, notfalls unter Verzicht auf das Gast-WLAN, wenn nicht mehr als ein Slave erlaubt sein sollte - das muß aber AVM dann machen, denn die WLAN-Konfiguration ist ein sehr dynamisches Gebilde (der Name "wlan_dynamic.cfg" ist sehr treffend und die wird auch nur temporär erzeugt) und ein Eingreifen in diese Konfigurationen ist nicht nur schwierig, sondern sollte auch tatsächlich unterbleiben (und das schreibe ich (hoffentlich) im Vollbesitz meiner geistigen Kräfte).

Wobei ich ohnehin mal die Frage in den Raum werfen will, wie sich eigentlich Steering und der Einsatz von Repeatern vertragen. Da bisher ja nur die 7490 mit der 06.80 versorgt ist (bei den 75x0-Modellen weiß ich gar nicht, ob da das Steering enthalten ist) und die Repeater-Firmware davon noch keine Ahnung hat, müßten entweder die (Dualband-)Repeater bereits jetzt ständig die RSSI-Werte der angemeldeten Clients an die Basis funken und schon zuvor in der Lage gewesen sein, sich auch auf Kommando "totzustellen" oder die WLAN-Verbindung zu bei ihnen angemeldeten Clients zu kappen oder die bei AVM beschriebenen Vorteile beim Steering-Einsatz auch für einzelne Clients (bei Verschlechterung des RSSI unter einen Schwellwert im 5 GHz-Band wird der Client ins (weiter reichende) 2,4 GHz-Band "komplimentiert", solange er noch "in Reichweite" ist und nicht selbstständig das Band wechselt) sind beim Einsatz von Repeatern hinfällig.

Wenn der Repeater das 5 GHz-Band besser anbietet als die Basis und der Client mit dem Repeater verbunden ist (der womöglich noch Crossband-Repeating betreibt, wenn er nicht ohnehin per LAN als Brücke arbeitet), kann das doch eigentlich alles (ohne "zentrale Kontrolle") gar nicht mehr reibungslos funktionieren ... oder wo ist da mein Denkfehler bzw. was habe ich am Steering-Prinzip falsch verstanden?

Wenn dann die angesprochenen "Grundfunktionen" nicht bereits im Repeater implementiert sind und von der Basis nur "angeschoben" werden müssen, sehe ich da ein "implementation gap", was zu schließen wäre. Wenn das von AVM bereits in weiser Voraussicht und auf der Basis langfristiger Planungen für neue Feature in einer der letzten Repeater-Firmwares umgesetzt wurde, ziehe ich (symbolisch) den Hut (ist zu kalt draußen, um das wirklich zu machen).

Wobei die Eingangsfrage vermutlich schon wäre, ob sich das Steering überhaupt mit einem angemeldeten Repeater verträgt oder das eine das andere ausschließt. Wegen mehrerer FRITZ!Boxen lohnt sich bei mir der Einsatz eines Repeaters über zwei Etagen nicht (der würde ohnehin immer gerade das falsche WLAN verwenden und solange man ihn nicht auch nutzt, ist er nur ein zusätzlicher "Störer", der den "Äther" verschmutzt - daher sind früher mal verwendete Repeater bei mir wieder rausgeflogen) und somit habe ich das Thema (inkl. der zusätzlichen Sicherheitslücken in Repeatern a la "/var/assume_all_access_from_homenetwork", was inzwischen glücklicherweise Geschichte ist) aus den Augen verloren und bin leider zum Stellen neugieriger Fragen "gezwungen".

 

[DerJacky]

Ein Ansatz wäre ja ein dauerhaftes Totstellen für einen wlan client auf einem bestimmten Band, wenn man es in den Einstellungen angehakt hat.

Soweit ich es verstanden habe sollen die Repeater erst in späteren Firmwares ( dann auch für die Repeater miteingebunden werden. Habe selbst 2 1750 mit im System.

Gesendet von meinem SM-T700 mit Tapatalk

 

[koyaanisqatsi]

:?:

Wobei ich ohnehin mal die Frage in den Raum werfen will, wie sich eigentlich Steering und der Einsatz von Repeatern vertragen.*

7560(6.80)<-basis--2,4GHz--repeater->7360SL(6.30)
Auch ohne Steering gibt es nach unbestimmter Zeit Probleme mit/auf Klienten die am 2,4GHz der 7560 hängen.
Sodaß ich quasi gezwungen bin den Repeater wieder ausser Betrieb zu nehmen.
Da läuft es noch nicht stabil.
(Hab hier nur einen 5GHz Klienten)

 

[PeterPawn]

Die Frage, wo und wie man das dann wirklich besser implementiert, kann ich nicht fundiert einschätzen ... mir wäre (so ich es zu entscheiden hätte) der Ansatz mit den zwei zusätzlichen SSIDs schon deshalb sympathischer, weil dabei dann der Client entscheidet, wann und wohin (und ob überhaupt) er durch die Gegend getrieben wird - das ist das genaue Gegenteil des "zentralistischen" Ansatzes, das in der FRITZ!Box einzustellen und der bläht (meine Ansicht) nur dort die Verwaltung auf.

Selbst wenn es keine zweite "slave"-Rolle neben dem Gastzugang geben darf, wäre die Alternative mit den zusätzlichen SSIDs anstelle des Gastnetzes immer noch (fast) ohne Änderungen am GUI umzusetzen (einfach eine Warnung, daß nur "entweder/oder" geht), auch für Laien nachvollziehbar und vor allem (was ich fast für wichtiger halte) ohne die Speicherung zusätzlicher Daten (abseits der beiden Namen) zu irgendwelchen Clients in irgendeiner Datei zu realisieren. Solche Listen (wie auch die "landevices") tendieren eben dazu, ständig zu wachsen und nur sehr selten (und meist erst recht nicht automatisch) zu schrumpfen.

Das geht dann wieder in die Richtung minimaler Änderungen und minimalistischer Datenspeicherung - denn während die zusätzlichen SSIDs sicherlich auch leicht wieder zu importieren wären, müßten die Einstellungen pro Gerät entweder wieder "selektiv" zu übernehmen sein oder man läßt deren Import gleich weg (mit der Folge zusätzlichen Aufwands nach einem Import, ähnlich wie bei der (Neu-)Anmeldung von DECT-Geräten nach dem Zurücksetzen mit anschließendem Import).

Wobei man vielleicht tatsächlich abwägen müßte, wenn jeder WLAN-AP-Master nur einen Sklaven besitzen darf - kann der aber auch mehrere davon "halten" (das wird langsam "politisch unkorrekt"), dann wäre m.E. eindeutig die zusätzliche SSID pro Netz (meinetwegen sogar automatisch erstellt mit einem Suffix im Namen, parallel zur "Steering"-SSID, dann braucht es gar keine Änderungen im GUI des FRITZ!OS) die bessere Lösung -> (meine) Argumente s.o.

 

[Schlumpfine]

ich habe bei diesem Release das Problem, dass alle WLAN Geräte ständig abgemeldet (teils in 1min Takt) werden und sich wieder anmelden. Zusätzlich schlägt gerne die Anmeldung von autorisierten Geräten (bisher nur im 2,4GHz Band beobachtet) einfach fehl. Die werden zwar korrekt wenig später angemeldet, was aber zu unschönen Aussetzern während der Nutzung führt.
Das betrifft sowohl das "interne" WLAN als auch das Gäste-WLAN. Dabei ist die Art des Clients unerheblich; es betrifft alle Architekturen: Smartphones, PCs, Ferseher, Android, iOS, Windows. WLAN Steering an/aus, nur das 2,4GHz Band aktivieren macht keinen Unterschied. Geräte einfach "rausschmeißen" und komplett neu registrieren schafft auch keine Abhilfe.

 

[distanzcheck]

Hatte ähnliches am Wochenende. Nachdem ich dann die Externe USB Festplatte von der Box abgemeldet und entfernt hatte ging das WLAN wieder tadellos.

Gesendet von unterwegs

 

[Schlumpfine]

externe Geräte wie USB sind an meiner Box nicht angeschlossen. Der Standard für USB ist in der Box auch auf 2.0 gestellt.

 

[Fredfire]

ich habe bei diesem Release das Problem, dass alle WLAN Geräte ständig abgemeldet (teils in 1min Takt) werden und sich wieder anmelden. Zusätzlich schlägt gerne die Anmeldung von autorisierten Geräten (bisher nur im 2,4GHz Band beobachtet) einfach fehl. Die werden zwar korrekt wenig später angemeldet, was aber zu unschönen Aussetzern während der Nutzung führt.
Das betrifft sowohl das "interne" WLAN als auch das Gäste-WLAN. Dabei ist die Art des Clients unerheblich; es betrifft alle Architekturen: Smartphones, PCs, Ferseher, Android, iOS, Windows. WLAN Steering an/aus, nur das 2,4GHz Band aktivieren macht keinen Unterschied. Geräte einfach "rausschmeißen" und komplett neu registrieren schafft auch keine Abhilfe.

Ich habe genau das gleiche Problem seit dem Upgrade. Mein Sohn kann sich mit seinem Galaxy S5 auf einmal nicht mehr mit dem 2.4 Ghz WLAN verbinden. Nach dem klick auf "verbinden" passiert einfach nix. Da ist doch massiv was faul...

 

[rst-cologne]

Außer den üblichen Hinweis doch einfach mal alles neu zu installieren (so langsam frage ich mich wozu es das laden und speichern von Konfigurationen in der FB überhaupt gibt?) wird man hier vermutlich nicht viel zur Lösung des Problems hören.
AVM und WLAN ist und bleibt Glückssache. :evil:

 

[Schlumpfine]

vermutlich nicht, eventuell aber schon. zudem ist es interessant zu wissen, ob es Einzelschiksale sind oder es sich um ein generelles Problem handelt, welches vielleicht sogar reproduzierbar ist.

auch mag es User geben, welche nicht permanent alles verfolgen können; da sind solche nochmaligen Tipps und Hinweise wie mit dem USB willkommen.

schließlich ist das Forum und dieser Thread dazu da, sich auszutauschen.

bei jedem nicht erwarteten Verhalten der Fritzbox sofort Recovery, Sicherung und "Klappe halten" rufen finde ich nicht sehr konstruktiv. ich verstehe das hier immer noch als Userforum, nicht als Entwicklerforum.

PS: Fritzbox neu+ Sicherung wurde vorher eh ausprobiert, stellt die Problematik aber auch nicht ab

 

[rst-cologne]

Ich stimme dir in allem zu.
Ich hätte aber nach Fritzbox neu nicht direkt die Config rein geladen, sondern erst mal nur WLAN schnell konfiguriert um zu sehen ob es in diesem frischen Zustand denn geht.

 

[PeterPawn]

Außer den üblichen Hinweis doch einfach mal alles neu zu installieren [...]

Oder eben auch, sofern tatsächlich WLAN-Steering eingeschaltet ist, dieses einfach einmal versuchsweise deaktivieren. Der Witz an der Art und Weise, wie die FRITZ!Box die Verteilung der Clients auf die beiden Bänder regelt, ist es doch (folgt man der AVM-(Marketing-)Beschreibung, einen Mitschnitt so eines erzwungenen Wechsels hat m.W. noch niemand hier veröffentlicht), daß dabei ein Client auf dem einen Band hinausgeworfen und nicht erneut akzeptiert wird, damit er auf den Trichter kommt, das andere zu verwenden.

Da braucht ja nun nur die rechtzeitige "Freigabe" einer erneuten Anmeldung nicht mehr zu funktionieren (obwohl der Client sich eben auf dem anderen Band nicht anmeldet), damit es genau solche Phänomene ergibt ... ein Client fliegt (ohne erkennbaren Grund) und kann sich auch für eine Weile nicht mehr anmelden. Zwar sollten das jeweils nur sehr kurze Zeiträume sein (wenn AVM irgendwann mal eine "technische Beschreibung" der umgesetzten Algorithmen auf den Tisch legt, stehen da ja vielleicht auch Zeitangaben drin), aber bei diesem nun doch noch sehr neuen Feature wäre es (behaupte ich jetzt einfach einmal, ohne es konkret beweisen zu können, wie alt und "ausgereift" der Code nun wirklich ist, weil das sicherlich auch davon abhängt, ob der komplett selbst entwickelt oder eben doch irgendwo lizensiert wurde) ja auch nicht wirklich verwunderlich, wenn das noch etwas "abhängen" muß.

Es gibt m.W. keine STA-seitige Unterstützung für so eine Funktion, zumindest keine, mit der ein AP eine STA "bitten" kann, doch auf ein anderes Band zu wechseln. Kennt jemand eine solche, wäre ein Link zum Standard nett. Gibt es keine, "überrascht" so ein erzwungener Verbindungsverlust ggf. auch mal eine STA und dann ist es halt an ihr, wann und mit wem sie alternative Netze (und das andere Band ist ja i.d.R. für eine STA ein anderes Netz, der AP hat eine andere MAC-Adresse, damit auch eine andere BSSID) ausprobiert.

Ich habe gerade mal meine 7490 von der Benutzung zweier getrennter SSIDs auf eine gemeinsame umgestellt und siehe da ... dabei wurde automatisch auch das Steering aktiviert. Ich möchte also nicht wissen, wieviele Leute nach dem Update auf 06.80 das Steering automatisch in ihrem Router verwenden und davon gar keinen Schimmer haben. Da würde ich bei einigen der hier geschilderten WLAN-Probleme doch zuerst einmal nach den Einstellungen schauen und wenn dann die Voraussetzungen und Symptome stimmen (identische SSIDs, Steering aktiv, unerklärliche Verbindungsabbrüche, Probleme beim Herstellen einer Verbindung), einfach einmal den "lbd" abschalten lassen. Zumindest zum Eingrenzen der Probleme könnte das beitragen ... treten sie weiterhin auf, haben sie offenbar doch nichts mit dem Steering zu tun - auch wenn die dabei eingesetzten Techniken genau dieselben Effekte hervorrufen würden.

Ich bin ohnehin auf die technische Beschreibung (so es irgendwann mal eine gibt und man das dann nicht alles selbst ermitteln muß) gespannt ... das geht m.E. schon damit los, wie der AP nun genau ermitteln will, ob eine STA beide Bänder unterstützt - das geht ja nur bei tatsächlich gleichzeitig oder zumindest zeitnah eintreffenden "probe requests". Da, wo bei einer Infrastruktur mit EAP (also da, wo sich die anderen Anbieter von WLAN-Technik mit "Band Steering" normalerweise bewegen) noch eine eindeutige (oder zumindest höchstwahrscheinliche) Identifikation der STA auch unabhängig von der Hardware möglich ist (und damit die dauerhafte Speicherung von "kann beide Bänder nutzen" einen Sinn ergeben könnte - wobei das ja auch noch nicht vor der Änderung von Client-Einstellungen schützt), kann das bei Verwendung eines PSK nicht mehr an der "Identität" des Clients festgemacht werden. Hat dann eine STA gar noch unterschiedliche MAC-Adressen in beiden Bändern (dann hat der "Client" ja eigentlich auch zwei "STA-Rollen", für jedes Band eine - keine Ahnung, ob das FRITZ!OS das erkennen kann oder überhaupt will), dann kann man eigentlich nur noch auf der Basis anderer Merkmale mit einer gewissen "Wahrscheinlichkeit" eine solche Annahme treffen - das trifft aber bereits bei der Vergabe von Adressen über DHCP zu, daß dann die "Identität" nicht mehr an der MAC-Adresse festgemacht werden kann.

Da, wo ein "DHCP hopping" beim "normalen Anwender" aber niemanden stört (die wenigsten prüfen nach, welche IP-Adresse sie erhalten haben) und vielleicht die KiSi davon betroffen ist, wenn ein Gerät falsch identifiziert wurde, da ist dann beim "Verweigern" einer WLAN-Anmeldung in der Annahme, dieser Client könne auch das andere Netz benutzen (vielleicht hat der auch einen "Schalter", wie einige Windows-Treiber, wo man eine Auswahl/Einschränkung einstellen kann und der Benutzer hat das (ggf. auch implizit über irgendein "Tool") geändert - und dabei auch noch gewagt, die FRITZ!Box nicht darüber zu informieren, weil es ihm selbst gar nicht bewußt war), schnell mal guter Rat teuer beim "durchschnittlichen Kunden", der sich anhand der Formulierung im GUI "Zur Verbesserung der Datenübertragung darf bei einem Dualband-WLAN-Gerät automatisch der Wechsel zwischen 2,4- und 5-GHz-Frequenzband herbeigeführt werden." vielleicht keine Fragen zum technischen Hintergrund stellt und damit wohl auch nicht unbedingt erwarten würde, daß das nur funktioniert, weil eben in dem einen Band die Anmeldung absichtlich verweigert wird, damit der Client auf das andere ausweicht. Macht der das dann einfach nicht oder klappt die Anmeldung dort nicht und auch die automatische Freigabe für das absichtlich gesperrte Band funktioniert im Anschluß nicht zuverlässig, dann steht der durchschnittliche Kunde am Ende mit einem Gerät da, was sich - aus seiner Sicht - absolut irrational verhält und mal im WLAN funktioniert und mal nicht.

Wenn ich nicht etwas verpaßt habe (ich nehme entsprechende Links wirklich gerne, weil ich selbst nicht fündig geworden bin), gibt es keinen Standard für dieses "Band Steering" und auch keine "Kommunikation" zwischen AP und STA (sind eigentlich auch jeweils zwei AP - für jedes Band einer - und zwei STA), ob der Client "dualband-tauglich" und obendrein "bereit" ist, sich nicht mehr selbst um die Beobachtung der Signalstärken und das "roaming" zwischen mehreren APs mit demselben ESS zu kümmern, sondern das irgendeiner zentralen Steuerung (hier eben dem "lbd" in der FRITZ!Box) zu überlassen. Ohne eine solche Kommunikation sieht so ein "Rauswurf" einer STA auf einem Band für diese aber erst einmal nach einem "Versagen" der Verbindung aus und solange die Hardware des Clients nicht auch tatsächlich ständig parallel in beiden Bändern aktiviert ist (also nicht nur (automatisch) "umgeschaltet" werden kann und ansonsten z.B. dieselben (Kompromiss-)Antennen verwendet), dauert ggf. sogar der Wechsel des Clients auf das andere Band etwas oder er wechselt gar - wenn es andere ihm bekannte Netze auf demselben Band in der Umgebung gibt - in ein anderes Service-Set.

Es mag tatsächlich Situationen und Kombinationen aus Geräten geben, wo das reibungslose Steering auch bei "Heimnetzen" (mit PSK und eben eher ohne "zentrale Verwaltung") funktioniert ... ich bin aber sehr skeptisch, daß es wirklich in den vielen denkbaren Kombinationen und ohne einen passenden Standard (noch einmal, vielleicht gibt es den ja tatsächlich und ich kenne ihn nur nicht bzw. ich kann bei der Suche nach "wlan steering" oder "band steering" auch nichts finden - zumindest keinen Standard, sondern nur das bekannte Whitepaper von LANCOM, die Diskussion dazu bei OpenWRT, die Beschreibung bei CISCO und die Ankündigungen von AVM ... dann ist aber auch das Ende der Fahnenstange erreicht) sauber gelingen wird, einen Client nicht nur "am Anfang" auf ein bestimmtes Band zu "locken" (wie es bei CISCO beschrieben ist für das Bevorzugen des 5 GHz-Bandes, damit das andere für "legacy clients" (also Geräte ohne moderneres WLAN) verfügbar bleibt), sondern ihn auch noch dynamisch und ohne (spürbare) Unterbrechungen (und möglichst noch bei einer gerade tatsächlich für die Datenübertragung genutzten WLAN-Verbindung) und Probleme beim "reconnect" mit sanftem Druck in das andere Band zu zwingen.

Solange das System des Clients dabei nicht bestehende Verbindungen abbricht, weil es sich erst einmal in dem anderen Band per DHCP wieder eine/dieselbe IP-Adresse abholen muß und dabei den IP-Stack neu initialisiert (oder gibt es tatsächlich Systeme, die bei einer WLAN-Verbindung den L2 auf der Basis des 2.4 GHz-Bandes einfach "spur- und unterbrechungslos" gegen einen auf der Basis des 5 GHz-Bandes "austauschen", solange dabei nur die Identifikation auf L2 (also die MAC) dieselbe bleibt), solange müßten eben auch alle darauf aufbauenden TCP-Verbindungen auf L4 und darüber und damit auch HTTP-basiertes Streaming usw. in Mitleidenschaft gezogen werden - also sollte das vielleicht nur dann erfolgen, wenn es gerade keine aktive Datenübertragung gibt.

Wie das dann wieder zur "Umleitung" von Paketen über den "packet accelerator" paßt, wo ja die Pakete dann auf einem "fast path" mehr oder weniger am System vorbeigeschleust werden (der "lbd" läuft - zumindest dem Augenschein nach - als Userland-Prozess), wird sicherlich die Zukunft noch zeigen ... aber daß bei einer derartigen Technik (und m.W. ist AVM der erste Hersteller, der das ins "Heimnetz" bringen will und dabei eben keine zentrale Steuerungskomponente verwendet bzw. das soll hier die FRITZ!Box neben ihren Rollen als AP für die beiden Bänder auch noch übernehmen) auch entsprechende Startschwierigkeiten zu erwarten sind, versteht sich von selbst und man muß eben etwas Geduld aufbringen.

Daraus würde ich jetzt nicht unmittelbar folgern, daß man bei AVM das WLAN so gar nicht im Griff hat (war hier auch irgendwo zu lesen) ... allerdings hoffe ich auch, daß es bei AVM so umgesetzt wird/wurde, daß beim Abschalten des Steerings tatsächlich ein stabiles WLAN das Ergebnis ist, was zumindest nicht hinter die bisher gezeigten Leistungen (auch da gab es ja teils unmotivierte Deauth/Deassoc-Orgien bei einigen, wenigen Clients) zurückfällt.

Ansonsten hätte man sich mit diesem Versuch, "band steering" in den Consumer-Bereich zu bringen, einen Bärendienst erwiesen. Ich hoffe ja, daß AVM irgendwann wirklich mal die Vorgänge dabei erläutert und das nicht am Ende alles mit dem Mäntelchen des "Betriebsgeheimnisses" bedecken will ... so etwas wie das vierseitige Whitepaper von Lancom sollte vielleicht auch bei AVM "drin" sein, damit man wenigstens eine Vorstellung davon kriegt, nach welchen Kriterien AVM wirklich arbeitet und wie man sich dann bei Problemen vielleicht selbst helfen kann, ggf. auch ohne das Steering abschalten zu müssen.

Irgendwelche Einstellungen für Trigger-Werte (wie bei LANCOM) gibt es ja bei AVM wohl nicht (zumindest nicht im GUI und beim WLAN rate ich auch von Änderungen in irgendwelchen Dateien ab) und damit ist schon die höchst unterschiedliche Topologie eines WLANs eine ziemliche Herausforderung. Bei der größeren Zahl potentieller Kunden sind auch die Kombinationen sicherlich wesentlich vielfältiger als in einer Firma, wo der Admin das dann auch noch "ausmessen" und Stück für Stück optimieren kann, z.B. durch zusätzliche AP oder eine Änderung von deren Platzierung.

Das macht das Vorhaben, eine "allgemeingültige" Lösung für WLAN-Steering zu entwickeln, die sowohl auf dem Land oder beim freistehenden Einfamilienhaus mit ausgedehntem Grundstück als auch in der Stadt im Mehrfamilienhaus mit zig benachbarten Netzen zuverlässig, reibungslos und wie vorgesehen funktioniert, schon zu einem sehr ambitionierten und ich hoffe einfach mal, daß man sich das bei AVM gründlich überlegt hat, bevor man es in Angriff nahm.

Wenn jetzt nach und nach auch die Repeater daran angepaßt werden (einige Router-Modelle sind ja auch nicht betroffen, weil der Router für's Steering schon dualband-tauglich sein sollte), dann wird sich sicherlich auch im Verlauf des nächsten Jahres irgendwann mal zeigen, wie gut das funktioniert - auch dann, wenn man nicht nur irgendwo eine einzige, zentral aufgestellte FRITZ!Box verwendet und diese dann einen "Gerätepark" von Repeatern (auch hier gibt es ja sehr verschiedene Modelle und Arbeitsweisen, von anderen Herstellern will ich noch gar nicht reden) zu "orchestrieren" hat.

Spannend finde ich ja die Frage, ob das auch für Dualband-Repeater denkbar/machbar/geplant ist, wenn diese als AP (per LAN-Kabel mit einer FRITZ!Box ohne Dualband-Funktion gekoppelt) arbeiten - wenn ich am Aufstellort der FRITZ!Box (da, wo der Anschluß die eigenen vier Wände "betritt") gar keinen Bedarf für WLAN-Clients habe und per Repeater irgendwo anders ein Netz aufspanne (zentral im Wohnbereich, da wo ich es brauche - der 1750E sollte doch genau das können), dann wäre das ja (abhängig von der Nachbarschaft) immer noch keine unnütze Funktion, daß die vorhandenen Clients nach ihren eigenen Fähigkeiten und ggf. sogar noch dynamisch anhand der Signalqualität und der Auslastung (so lese ich das bei AVM jedenfalls) verteilt werden.

 

[flyingoffice]

Als ich erstmalig von der AVM Ankündigung zum WLAN Band Steering laß, dache ich tatsächlich dass ich für einzelne Clients festlegen kann dass diese explizit das 2,4 oder 5 GHZ Netz nutzen können. Nach der Installation der 6.80 Firmware kam aber die Ernüchterung. Nach wie vor haben sich die Clients zu 99% in das 2,4 Netzwerk eingewählt, also in keinster Weise das was ich mir erhofft habe. Inzwischen arbeiten hier 2 1750E Repeater im LAN Bridge Mode und das WLAN der 7490 ist deaktiviert. Jetzt befinden sich 80 bis 90 % der Clients im 5 GHZ Netz, also genau das was ich hier eigentlich vom Band Steering erhofft hatte.

 

[full2000]

Ich schaffe es einfach nicht, mit der neuen 6.80 irgendwelche Portweiterleitungen einzurichten. Es kommt immer die Fehlermeldung "Fehlerbeschreibung: Die angegebene IP-Adresse wird von FRITZ!Box verwendet. Eine Portfreigabe auf diese IP-Adresse ist nicht zulässig.".

Mache ich einen Werksreset und trage dann eine Portweiterleitung ein, geht es (Weiterleitung funktioniert auch!). Boote ich dann neu, ist die Weiterleitung wieder deaktiviert und ich kann auch keine neue mehr eingeben.

Was könnte das sein?! Ein manuelles Eintragen in die ar7.cfg hat den gleichen Effekt. Dort schreibt die Box nach einem Neustart ein "#" vor den jeweiligen Eintrag.