[Info] FRITZ!Box 7490 Labor-Firmware 113.06.88-45942 vom 14.08.2017

[alarbiere]

Ja, wie sollen denn sich die WLANs untereinander vernetzen, wenn nicht der gleiche Kanal bei allen verwendet wird?

Hängt davon ab wie die Geräte verbunden sind.
Bei WLAN Repeater ist ja eines der Highlights das sogenannte Cross-Band repeating. Da muss ein Kanal passen (der wird dann für's Repeating genutzt) aber der andere sollte ja besser verschieden sein, damit sich Repeater und Router (oder anderer Repeater) möglichst wenig in die Quere kommen.
Bei diesem Anwendungsfall sollte man dann ja sehr wahrscheinlich die FRITZ Geräte selber die WLAN Kanäle festlegen lassen.
Aber bei mehreren FBs die per LAN verbunden sind - ein Router und ein oder mehrere IP Clients - ist der gewählte WLAN Kanal absolut unerheblich für die Kommunikation zwischen Mesh Master und Mesh Slave. Und in diesem Fall sollte eben WLAN Kanäle nicht überall die Gleichen sein.

 

[bino]

Will nochmal kurz auf mein Problem aufmerksam machen, da es durch die neue Firmware wahrscheinlich untergeht!

https://www.ip-phone-forum.de/threa...908-vom-11-08-2017.296356/page-2#post-2235982

Hi flak65,

ja, ein ähnliches Phenomän habe ich auch bei mir.

Konstellation bei mir: Fritzbox 7490 <--> Repeater 310 <--> IRadio

Hier ist die 2,4 GHZ Verbindung zwischen Repeater 310 (nur 2,4 GHZ unterstützt) und meinem iRadio betroffen.
Mal wird eine Geschwindigkeit anzeigt und mal nur die 2,4 GHZ allein.
Außerdem sind die Hyperlinks am Repeater und am Radio mal vorhanden, mal nicht.
Weiter wechselt am Repeater zeitweise die angezeigte IP-Adresse (mal wird die zur Fritzbox angezeigt (192.168.xxx.01), mal die des Repeaters (192.168.xxx.26) und mal die vom Radio (192.168.xxx.70).
Dabei verweisen die Hyperlinks auch auf diese Geräte.

Besser ist es erst geworden, als ich dem Repeater eine eigene SSID gegeben habe.
Jetzt stimmen die IP-Adressen, jedoch verschwinden die Hyperlinks noch zeitweise.

 

[Thomas5]

Dass alllerdings auch der Funkkanal mit übernommen wird, halte ich eher für suboptimal, denn z.Z. nutzen meine drei im Haus verteilten FBen zwar die diesselbe SSID, funken aber jeweils möglichst auf festen verschiedenen überlappungsarmen Kanälen!?!

Bist du dir sicher, dass du verstanden hast was ein Mesh ist? Die Geräte müssen auf dem selben Kanal arbeiten, damit ein Mesh funktionieren kann!

 

[muetzekoeln]

Bist du dir sicher, dass du verstanden hast was ein Mesh ist? Die Geräte müssen auf dem selben Kanal arbeiten, damit ein Mesh funktionieren kann!

Hallo Thomas,
hast Du genaue Information darüber, wie das, was AVM als "Mesh" bezeichnet, genau funktioniert? Mir fehlt genau diese Info. Und "Mesh" ist erstmal doch wohl nur ein Buzzword und kein Kommunikationsprotokoll. Überhaupt frage ich mich, ob sich hinter dem AVM-Mesh ein (Quasi-)Standard verbirgt. Steckt vielleicht 802.11s drin?

 

[flak65]

Hier erklärt dir AVM was Mesh ist (oder auch nicht )

 

[alarbiere]

Bist du dir sicher, dass du verstanden hast was ein Mesh ist? Die Geräte müssen auf dem selben Kanal arbeiten, damit ein Mesh funktionieren kann!

Jetzt hast du mich neugierig gemacht.

Ich habe zwei FB 7490, eine ist Router, die andere ist IP Client. Beide scheinen ein Mesh WLAN zu bilden (zumindest sieht es in der Heimnetzübersicht so aus). Und beide nutzen verschiedene WLAN Kanäle.
Alle WLAN Geräte im Haus suchen sich die FB mit dem besten Empfang aus, und werden auch mal von der FB von einem Frequenzband ins andere gekickt wenns da besser läuft.
Ich dachte jetzt dass das alles bei mir funktionniert... aber nach dir tut es das nicht.

Ich bin immer gerne bereit mich belehren zu lassen:

• Was genau funktionniert nicht bei dieser Konstellation (Verbindung der einzelnen Access Points über LAN Kabel oder PowerLAN) ? Mein Fall ist ja vielleicht ein glücklicher Sonderfall...
  
• Kann man das irgendwo nachlesen?

Bitte lese hier keinen Sarkasmus hinein. Du sagst dies ist ein Problem - ich bemerke keins. Ich möchte einfach nur verstehen...

 

[Hans Juergen]

Bist du dir sicher, dass du verstanden hast was ein Mesh ist?

Weißt du es? Wo steht, was technisch passiert? Ich meine nicht einfach eine Bedienungserleichterung bei der Einrichtung, sondern was passiert mit den Netzen, werden die synchronisiert, ist wie bei der früheren Repeater-Version nur noch ein durchgehendes Netz vorhanden, ist seamless handover möglich? Dann wären WLAN-Telefone (wieder) interessant...
Das Video ist reine Werbung, ohne technische Erklärung...

 

[H´Sishi]

In einem Artikel über Mesh-fähige Router im professionellen Bereich habe ich herausgelesen, daß diese Mesh-Router im Grunde intelligent vernetzte Access-Points sind, die eben nicht passiv darauf warten, daß ein Client sich von AP zu AP bewegt, sondern den Client aktiv zum Wechsel des Accesspoints "nötigen". Wie diese AP untereinander verbunden sind, ist dabei nebensächlich - sowohl drahtlos als auch per LAN-Kabel funktioniert.

Anscheinend hat AVM letzteres (auch) ermöglicht, was dafür spricht, daß @alarbiere trotz unterschiedlicher Kanäle sowohl die Mesh-Übersicht als auch den reibungslosen Betrieb hat.
ODER die Mesh-aktiven FritzBoxen werden zwar als Mesh-Geräte gekennzeichnet, aber es ist kein "echtes" Mesh aktiv. Laut der Netzwerk-Übersicht gibt es keine extra Kennzeichnung, daß zwischen einem Master und einem Client eine Mesh-Verbindung besteht. Auch meine Box hat das Mesh-Symbol - aber ich habe kein zweites Gerät, das ebenfalls Mesh kann.

 

[PeterPawn]

In den neuen "Mesh-fähigen" Versionen der Firmware gibt es auch einen neuen Daemon: avmnexusd. Wie schon die Wahl des Namens "nexus" vermutlich zeigen soll, ist das der Dienst, der für die Kommunikation der Mesh-APs untereinander wohl zuständig ist.

Für einen "reibungslosen" Mesh-Betrieb braucht es eben eine Kommunikation zwischen den AP ... z.B. muß ja der von einem AP mit einer STA ausgehandelte (individuelle) Session-Key ebenfalls an den "übernehmenden" AP kommuniziert werden, wenn für den Client der Wechsel tatsächlich "seamless" erfolgen soll - was u.a. für die unterbrechungsfreie Übertragung von Streams entscheidend wäre. Insofern bin ich auch etwas skeptisch (kann/will das aber mangels Technik und echtem Interesse auch nicht testen), ob tatsächlich ein Client bei unterschiedlichen Kanälen "seamless" zwischen APs wechseln kann - der müßte ja zumindest seinerseits auch auf einen anderen Kanal wechseln und dann dürften die meisten STA (Clients) ohnehin eine neue Session mit dem AP aushandeln, wodurch i.d.R. auch gerade aktive Übertragungen auf höheren Schichten beeinträchtigt würden, die dann wieder eigene Fehlerkorrekturmechanismen (z.B. Wiederholungen von verlorenen Paketen) aktivieren müßten, wenn die neue L1/L2-Verbindung steht.

Bei einem "einzelnen" Mesh-Gerät macht AVM die Anzeige des Icons vermutlich im Moment von der Aktivität dieses neuen Daemons abhängig ... und auch wenn es keine weiteren Geräte gibt, mit denen der aktiv kommuniziert, steht er natürlich Gewehr bei Fuß (oder auch "Zertifikat bei Fuß", denn für diese Kommunikation untereinander gibt es ein neues eigenes Zertifikat) und wartet auf entsprechende Verbindungswünsche (auf TCP-Port 52738) aus dem LAN (wobei das auch nur durch die "normale" Firewall nach außen abgegrenzt ist - solange es keine Weiterleitung von "dev dsl" nach innen gibt, ist das auch nur von lokalen Schnittstellen erreichbar).

 

[muetzekoeln]

... bei unterschiedlichen Kanälen "seamless" zwischen APs wechseln ... dann dürften die meisten STA (Clients) ohnehin eine neue Session mit dem AP aushandeln

Ich bin kein 802.11-Experte, aber das hier klingt so, als könnten(!) Clients das tatsächlich cleverer handhaben (siehe vor allem Punkt 4):
https://documentation.meraki.com/MR...ractices/802.11_Association_process_explained

Leider steht da nicht, ob alle APs auf dem selben Kanal sein müssen....

 

[PeterPawn]

Da ist nur die "association" zwischen AP und STA beschrieben ... das ist (weit) vor der Phase, in der eine (individuelle oder Gruppen-)Verschlüsselung zwischen AP und STA überhaupt zum Tragen kommt - bei Broadcasts und Multicasts wird der (Nutz-)Traffic für eine ganze Gruppe verschlüsselt (mit einem anderen temporären Key), damit der nicht mehrfach übertragen werden muß.

Im Prinzip kann man diese (dort beschriebene) "association" eines STA mit einem AP mit dem Vorgang des Einsteckens eines LAN-Kabels vergleichen ... erst dann geht es mit dem Aushandeln der Übertragungsparameter (auch auf einem Ethernet-Kabel) wirklich los.

Es gibt allerdings Standards im 802.11 im Bezug auf WLANs, in denen auch solche "handovers" definiert sind ... aber die setzen in aller Regel auf einer zentralen Authentifikation der Clients und auf einer zentralen Regelung von Zugangsrechten (EAP/RADIUS) auf, was dann im Endergebnis auch Unterschiede bis zur Generierung des PMK (ein längerfristiges "Geheimnis" zwischen AP und STA, mit dem dann ein PTK als kürzer gültiger Schlüssel für die Datenübertragung sicher berechnet werden kann) ergibt. Bisher war bei AVM das beim Einsatz von Repeatern immer so, daß diese nur über L2TPv3 einen Tunnel zwischen der "steuernden Basis" und der STA aufgebaut hatten und die Zugriffskontrolle (jenseits vom WLAN, das muß natürlich der AP (als Repeater) schon selbst machen) dann über die Basis erledigt wurde.

Ich weiß nicht, was AVM in der Kommunikation auf Port 52738 zwischen den Mesh-Controllern für eine bestimmte STA austauscht ... aber es müßte zumindest der PMK sein, wenn nicht sogar der PTK - jedenfalls nach meinem Verständnis (was nicht zwangsläufig korrekt sein muß). Zumindest sofern da wirklich ein echtes "handover" stattfinden soll, was auch (unwilligen/älteren) Clients das Gefühl vermittelt, sie würden immer mit demselben AP kommunizieren - nur das könnte sie (wieder nach meinem Verständnis) davon abhalten, ihrerseits ein "roaming" zu machen und ggf. auf andere (bekannte) Netze (aka BSSIDs) auszuweichen, die ggf. besser zu empfangen sind.

 

[informerex]

@All was hat das mit der og. Firmware direkt zu tun? hier sollten nur Probleme/Fehler usw. rein
früher hatte man solche Diskussion in einem separaten Thread behandelt, zumal die Thematik mesh - Box/Modell übergreifend ist.
es gehört also in den Sub-Bereich "FRITZ!Box Fon WLAN: Diskussion nur zum Funknetzwer" bspw. https://www.ip-phone-forum.de/threads/fritz-talk-02-was-ist-mesh.296373/ wo auch der Video-Clip schon seit erscheinen publiziert ist.

//edit:
@PeterPawn genau das meinte ich (bzgl. verloren gehen usw.) - ok hab es mal gemeldet

 

[PeterPawn]

No problem ... wo sollte die "Abspaltung" Deines Erachtens beginnen? Bei #15?

Schreib' doch mal Deinem Foren-Admin ... ich finde es auch besser, wenn solche "Grundsätzlichkeiten" leichter zu finden sind als in diesen (inzwischen schon wegen der Update-Frequenz bei AVM einfach unsinnigen) Laber-Threads.

Wer heute ein Problem mit Firmware "4abcd" feststellt und sich nicht erst durch 5-10 "alte" Threads für die Vorgängerversionen kämpft, der "kassiert" dann auch schnell mal den Hinweis, daß das schon seit Version "4efgh" so ist - das macht diese Threads insgesamt (ist nur meine Ansicht) ziemlich sinnfrei.

Jetzt nähert sich diese Runde ja offenbar einem (vorläufigen) Ende, da sollte man dann die Erkenntnisse auch in einer Form zusammentragen, die nicht bereits am Freitag wieder überholt ist.

Schon die Auskunft von AVM, daß man in den GRX5-Boxen 802.11k (zum "Verteilen" der Clients beim Band-Steering) und 802.11v (damit kann man die Informationen eines Clients zum WLAN an seinem Standort - z.B. zur Empfangsqualität in einem BSS - einsammeln über die im "mesh" verteilten Clients, sofern die das auch können) unterstützen wird , gehört ja nicht in einen solchen Thread, wo sie nach spätestens einer Woche dann wieder verloren ist.

 

[PeterPawn]

Ich muß auch mal ein Lob loswerden an AVM ... da es (im Bezug auf die Support-Daten) erst bei dieser Version geändert wurde, steht es dann halt hier im Thread.

Bei den automatisch an AVM über TR-069 übermittelten Daten (Stichwort "argo") hat man sich jetzt (bzw. schon in vorhergehenden Versionen) richtig Mühe gegeben und - obwohl man die Datenmenge massiv vergrößert hat, gerade was das Netzwerk anbelangt - es werden jetzt weitere (m.E. auch wirklich sensitive) Daten maskiert. In den WLAN-Daten werden jetzt die SSIDs der Netze aus der Umgebung entfernt (alles als Unterschied zur 06.83 zu sehen) und bei den anderen Angaben zum Netzwerk werden dann IP-Adressen (beide Protokolle) und auch MAC-Adressen entsprechend maskiert, genauso auch event. auftauchende E-Mail-Adressen.

Wenn jetzt dort auch noch die konfigurierten (Nicht-Standard-)Ports für Weiterleitungen von extern ins LAN (und auf die Box selbst) durch "port<seq>" o.ä. ersetzt (oder auch komplett maskiert) werden (auch wenn eine "versteckte" Portnummer nur ein unvollkommener Schutz ist, vervielfacht sie doch den Aufwand für einen Angreifer), gibt es da gar nichts mehr so richtig "zu meckern" bei den automatisch verschickten Daten - sparsamer als andere Hersteller (allerdings von anderen Geräten, denn Router machen eher seltener bisher "Telemetrie") ist das dann allemal. Allerdings bin ich etwas skeptisch, was die GRX5-Modelle und die dort im Environment abgelegte Seriennummer angeht ... die hat AVM offenbar vergessen oder hält sie nicht für relevant (auch wenn das hier der 7490-Thread ist).

Auch andere Daten werden beim Erstellen der Support-Daten jetzt ausgeblendet (allerdings natürlich nicht die oben bei der automatischen Übermittlung berücksichtigten Daten, das gilt alles für die Support-Daten nicht, da sind nur die Kennwörter durch "SECRET" ersetzt) ... bei der neuen Konfiguration für "avmnexus" hat man dann auch gleich den privaten Schlüssel für die "Nexus-Identität" weggelassen in den Support-Daten, was - angesichts der Tatsache, daß der noch einmal verschlüsselt ist bei der Speicherung im TFFS (und das meint nicht nur die zusätzliche Base64-Kodierung) - dann wieder den Schluß nahelegt, daß das Kennwort für diesen Schlüssel auch aus irgendwelchen Geräteeigenschaften abgeleitet wird (es ist aber ein anderes als für den GUI-Key, das habe ich schon getestet).

Der neue Weg (seit dieser Version) zum Erstellen der "Erweiterten Support-Daten" (es gibt gesonderte Buttons und die Auswertung basiert nicht mehr auf der Einstellung in der "ar7.cfg", sondern auf dem Aufruf durch "firmwarecfg") ist auch deutlich sicherer ... bisher konnte auch der Provider über TR-069 die erweiterten Support-Daten abrufen, wenn das Flag erst einmal gesetzt war und da sind bekanntlich sämtliche "Geheimnisse" der FRITZ!Box enthalten. Jetzt muß man schon im GUI explizit diesen Button wählen (der Erklärungstext warnt auch eindringlich davor, das zu tun) und kann nicht mehr versehentlich die einmal getätigte Auswahl stehen lassen.

Ich wäre schwer begeistert, wenn AVM jetzt auch noch etwas an anderen sicherheitskritischen Stellen machen würde (bevor die Firmware veröffentlicht wird) ... da fiele mir aus dem Stand noch der DNS-Server ein, der nicht ganz so vertrauensselig mit den Namen umgehen sollte, die ihm von den LAN-Clients als Wunschvorstellung präsentiert werden und nicht jeden dieser Namen gleich noch lokal auf eine DNS-Abfrage hin ausliefern sollte.

Auch der Start (bzw. die Konfiguration) des "inetd" sollte noch einmal überdacht werden ... ist ein Angreifer erst einmal zu einer Zeile in dieser Datei gelangt (die dann eine Shell aufruft), startet der "inetd" diesen Service auch treudoof, weil er die Datei nicht etwa aus den zu startenden Diensten neu zusammensetzt, sondern mit irgendwelchen "grep"- und "echo"-Kommandos daran herumdoktert. So ein Schreibzugriff auf /var/tmp ist so manches Mal auch noch einfacher zu bewirken als der direkte Aufruf eines beliebigen Kommandos und so ist das - immer noch - eine "offene Wunde", die sich leicht infizieren kann (bzw. läßt).

 

[PeterPawn]

Man kommt gar nicht mehr heraus aus der ganzen Lobhudelei ... nachdem die erste Lücke in der TR-064-/TR-069-Implementierung zur 06.83 hin nur überwindlich geschlossen wurde (also wirklich nur diese eine konkret gemeldete Stelle mit der Firmware-URL bei einem Download-Auftrag), wurde seither (wann genau, weiß ich nicht, interessiert ja auch nicht wirklich - aber die Existenz weiterer potentieller Schwachstellen in diesem Teil der Firmware hatte ich Anfang Juni hier mal "erwähnt" - irgendwo in den Weiten des langen Textes, in kursiv in einem Einschub - und m.E. war die damals aktuelle Labor-Version noch nicht gefixt an diesen Stellen) auch noch an einigen anderen Stellen in der TR-069-Implementierung nachgebessert und die variablen Werte beim internen Aufruf von Kommandos sind inzwischen wohl besser gegen "command injections" geschützt.

Damit kann auch der Provider (oder jemand, der sich für seinen ACS ausgibt) nicht mehr ohne weiteres irgendwelche wahlfreien Kommandos auf einer FRITZ!Box ausführen ... wenn denn dann erst einmal entsprechende Release-Versionen vorliegen, denn die 06.83 (hier konkret für die 7580) ist eben noch verwundbar an dieser Stelle - daher hat ja AVM sicherlich auch die nachträglichen Änderungen vorgenommen, die jeder mit einem "strings"-Kommando für die Datei "/usr/share/ctlmgr/libtr069.so" selbst ermitteln kann, wenn er die dort enthaltenen "Kommando-Ketten" miteinander vergleicht.

EDIT:
Pluspunkt: Das Laden der Werkseinstellungen ist jetzt wohl auch über die 2FA zusätzlich abgesichert (welche zuvor noch offenen Stellen da noch hinzugekommen sind, muß ich erst noch testen).

Dicker, fetter Minuspunkt: Der Media-Server ist nach dem Laden der Werkseinstellungen und dem Durchlaufen des Einrichtungsassistenten (getestet mit 7580, eine UI-Box, kein Startcode vorhanden, WAN über den gleichnamigen Port) wie eh und je standardmäßig aktiviert (der SMB-Server nebenbei bemerkt auch, nur der FTP-Server ist aus) und "serviert" auch alle angeschlossenen USB-Datenträger - so, wie hier vor 9 Monaten schon gezeigt. Damit ist das komplette Auslesen eines USB-Speichers also nach wie vor möglich und man sollte (so man Wert auf einen Rest Privatsphäre legt) auf einem solchen USB-Stick nichts speichern, was man nicht ohnehin jedem Client im LAN zur Verfügung stellen will ... irgendwelche Zugriffsrechte beim Lesen der Daten auf so einem Volume sind reiner Theaterdonner (es steht alles jedem offen, der die richtige "Sprache" (aka das richtige Protokoll) spricht) und halten niemanden davon ab, da für einen unerwarteten Datenreichtum zu sorgen.

 

[SnoopyDog]

@flak65 @bino Habt ihr euer Problem denn per Feedback an AVM gemeldet?

Nachtrag: Bei mir schaut es in der Grafik auch so aus wie bei euch... Ich kann mom bloß leider nicht testen, ob der 2.4 GHz Bereich über den Repeater funktioniert oder nicht, erst heute Abend.

 

[koyaanisqatsi]

Der Mediaserver sollte zumindest mal bei den Komfortfunktionen auftauchen, damit er dort wenigstens mal ins Auge fällt.
Ansonsten mag ich den "Gratis-Webserver", wenn er vorher entschärft wurde...

...und ihn entsprechend auf einen unverfänglichen Speicher loslässt.

 

[flak65]

@SnoopyDog Ja, das Problem habe ich am Montag per Facebook gemeldet, da man beim Feedback der Labor-Firmware keine Bilder anhängen kann. Per Facebook wurde mir zugesichert es weiterzugeben.

 

[Pom-Fritz!]

Zum Thema Mesh und WLAN-Kanäle möchte ich mal meine Erfahrungen schildern:

Mein Equipment siehe Signatur. FB7580 K52 (5GHz), K1 (2,4GHz), Rep. 1750E: K40 (5GHz), K11 (2,4GHz). Eine 12GB große Datei per FTP vom PC (LAN) zum Smartphone im 5GHz-Bereich übertragen. Startpunkt: 2Meter neben der Fritz!Box. Dann während des Uploads mit dem Smartphone mehrmals in den jeweils anderen Funkbereich gewechselt und das in der FB und Rep unter "WLAN/Funkkanal/Auslastung" kontrolliert. Beim herumwandern ist der Upload nie abgebrochen, aber das Smartphone hatte sich dann mit dem 2,4 GHz-Netz verbunden und diese Verbindung während des Tests nicht mehr aufgegeben. Nachdem der Upload beendet war, habe ich Quell- und Zieldatei verglichen. Sie waren gleich. Nach dem Test waren die Funkkanäle immer noch so, wie vor dem Test.

Also ist ein seamless Handover auch bei verschiedenen Kanälen möglich, zumindest bei einer FTP-Übertragung.
Was dabei noch auffiel: Während des Tests hatte der Repeater (hier Access Point) einen geringeren Durchsatz (etwa 9/12MB/s) als der Router (2,4GHz-Band) bei annähend gleicher Entfernung.

 

[PeterPawn]

Das mit dem "seamless handover" ist halt so eine Sache ... das, was bei einer Dateiübertragung mit TCP als "unterbrechungsfrei" angesehen wird (TCP selbst hat eben entsprechende Sicherungsmechanismen, hatte ich oben mal erwähnt), kann wieder vollkommen anders aussehen, wenn man dabei gerade einen Video-Stream ansieht oder ein (VoIP-)Telefonat führt (oder auch ein Videotelefonat, dann hat man beides). Hier macht sich auch eine Unterbrechung von 1-2 Sekunden dann bemerkbar, die bei einem Datei-Download (naturgemäß) überhaupt nicht stört (oder auch nur auffällt).