FRITZ!Box 7590 - INHAUS 7.39 - Sammelthema

[TSprecher]

Wesentlich weniger Darstellungsfehler mit Zyxel Switches im Heimnetz als die gestrige Inhaus-Version 95581!
So richtig wirr wurde die Darstellung, wenn dann auch noch der 2400-Repeater das Inhaus-Update 95571 erhielt...
Auch Reboots kamen mit der 95581 vor...

Die 95616 von heute ist an meinem Anschluss bis jetzt vergleichbar stabil wie die letzte BETA.
Der dort beschriebene Teilfix für Switches wirkt sich so aus, dass an 1750E-Repeatern mit 7.29 Firmware halt immer noch LAN-Geräte mit MAC-Adressen aus dem Switch-Bereich angezeigt werden. Die Funktionalität des Mesh ist hier aber uneingeschränkt.

[Edit Novize: Beiträge zusammengefasst - siehe Forumsregeln] Danke!

mit der 95616 sieht die Übersicht des 2400-Repeaters nach dem Uptdate auf die Inhaus-95571 dann so aus:


mit der 2400-Repeater-Release 7.29 sieht es in Kombination mit der neuesten FB Inhaus 95616 so aus:
(der Verzicht auf das Update der Repeater-Firmware bei Verwendung bestimmter Switches erscheint vorläufig sinnvoll...)

 

[kleinkariert]

Kein Aprilscherz, endlich geht das mit der letzten Labor geschrottete IKEv1-VPN wieder.

 

[Grisu_]

95703 gefunden.
Ich warte aber lieber auf die hoffentl. heute noch erscheinende Labor, mir ist der Inhaus-Zweig zu dubios (unsicher, fehlerbehaftet) selbst auf der Mesh-Repeater Box (schon zu oft eingefahren damit).

 

[kleinkariert]

Inhaus-Zweig zu dubios (unsicher, fehlerbehaftet)

Bei 7590 (und 7530) fand ich beim aktuellen 7.39-Zweig kaum noch signifikante Unterschiede zwischen Labor und Inhaus, wenn es um "unsicher, fehlerbehaftet" geht.

 

[SlurfyYT]

Mit der neuen InHaus kann die Box nun den "Nur IPv6 verwenden" Modus

 

[B612]

download.avm.de/inhaus/MOVE21/7590/FRITZ.Box_7590-07.39-95703-Inhaus.image

 

[Zwanzigeinundzwanzig]

Rufbehandlungen: Rufumleitungen lassen sich nicht editieren oder löschen, nur deaktivieren. Neu anlegen geht.
Keine Ahnung, wie lange schon...
EDIT: Bei einer konkurrierenden Neueinrichtung einer RUL wird die alte gelöscht, ist aber erst zu sehen, wenn man das Menü völlig verlassen hat...

 

[kleinkariert]

Bei ist das dasselbe mäßig intakte Verhalten wie bei 7.29:
Ändern geht (zunächst) nur mit den Radiobuttons "an Zielrufnummer"/"an Anrufbeantworter"/"an Telefon"
und dann weiter mit "Eigene Rufnummer" unten.
"Art der Umleitung" ganz unten ging bei mir noch nie zu ändern.

 

[tonda1t]

Ich habe ab -07.39-95581 grosse wlan Probleme zwischen 7590 und 7390.

 

[myfb7590]

Hallo Allerseits,

mich beschäftigt da ein Problem wo ich nicht weiß wie ich da herangehen soll...

Setup: 7590 -WLAN- 6000 -WLAN- 7590 -LAN- Client

Bis zur 07.39-95378 funktionierte alles einwandfrei, seit der folgenden Inhouse kommt es bei Clients, die am "Ende" hängen, immer zu kurzen Verbindungsabbrüchen:

Antwort von fe80::c078:3308:7cdd:da6c%9: Zeit=13ms
Antwort von fe80::c078:3308:7cdd:da6c%9: Zeit=7ms
Zeitüberschreitung der Anforderung.
Antwort von fe80::c078:3308:7cdd:da6c%9: Zeit=7ms
Antwort von fe80::c078:3308:7cdd:da6c%9: Zeit=7ms
Antwort von fe80::c078:3308:7cdd:da6c%9: Zeit=7ms
Antwort von fe80::c078:3308:7cdd:da6c%9: Zeit=9ms
Antwort von fe80::c078:3308:7cdd:da6c%9: Zeit=10ms
Antwort von fe80::c078:3308:7cdd:da6c%9: Zeit=12ms
Antwort von fe80::c078:3308:7cdd:da6c%9: Zeit=8ms
Antwort von fe80::c078:3308:7cdd:da6c%9: Zeit=9ms
Antwort von fe80::c078:3308:7cdd:da6c%9: Zeit=9ms
Antwort von fe80::c078:3308:7cdd:da6c%9: Zeit=11ms
Antwort von fe80::c078:3308:7cdd:da6c%9: Zeit=14ms
Antwort von fe80::c078:3308:7cdd:da6c%9: Zeit=10ms
Antwort von fe80::c078:3308:7cdd:da6c%9: Zeit=10ms
Antwort von fe80::c078:3308:7cdd:da6c%9: Zeit=7ms
Antwort von fe80::c078:3308:7cdd:da6c%9: Zeit=27ms
Antwort von fe80::c078:3308:7cdd:da6c%9: Zeit=10ms
Antwort von fe80::c078:3308:7cdd:da6c%9: Zeit=12ms
Antwort von fe80::c078:3308:7cdd:da6c%9: Zeit=20ms
Antwort von fe80::c078:3308:7cdd:da6c%9: Zeit=11ms
Antwort von fe80::c078:3308:7cdd:da6c%9: Zeit=13ms
Antwort von fe80::c078:3308:7cdd:da6c%9: Zeit=9ms
Antwort von fe80::c078:3308:7cdd:da6c%9: Zeit=7ms
Antwort von fe80::c078:3308:7cdd:da6c%9: Zeit=11ms
Antwort von fe80::c078:3308:7cdd:da6c%9: Zeit=10ms
Antwort von fe80::c078:3308:7cdd:da6c%9: Zeit=34ms
Zeitüberschreitung der Anforderung.
Antwort von fe80::c078:3308:7cdd:da6c%9: Zeit=9ms
Antwort von fe80::c078:3308:7cdd:da6c%9: Zeit=7ms
Antwort von fe80::c078:3308:7cdd:da6c%9: Zeit=12ms
Antwort von fe80::c078:3308:7cdd:da6c%9: Zeit=11ms
Antwort von fe80::c078:3308:7cdd:da6c%9: Zeit=10ms
Antwort von fe80::c078:3308:7cdd:da6c%9: Zeit=9ms
Antwort von fe80::c078:3308:7cdd:da6c%9: Zeit=8ms
Antwort von fe80::c078:3308:7cdd:da6c%9: Zeit=12ms
Antwort von fe80::c078:3308:7cdd:da6c%9: Zeit=12ms
Antwort von fe80::c078:3308:7cdd:da6c%9: Zeit=10ms

Antwort von 192.168.188.1: Bytes=32 Zeit=10ms TTL=128
Antwort von 192.168.188.1: Bytes=32 Zeit=9ms TTL=128
Antwort von 192.168.188.1: Bytes=32 Zeit=11ms TTL=128
Antwort von 192.168.188.1: Bytes=32 Zeit=7ms TTL=128
Antwort von 192.168.188.1: Bytes=32 Zeit=10ms TTL=128
Antwort von 192.168.188.1: Bytes=32 Zeit=10ms TTL=128
Antwort von 192.168.188.1: Bytes=32 Zeit=9ms TTL=128
Antwort von 192.168.188.1: Bytes=32 Zeit=7ms TTL=128
Antwort von 192.168.188.1: Bytes=32 Zeit=10ms TTL=128
Antwort von 192.168.188.1: Bytes=32 Zeit=9ms TTL=128
Antwort von 192.168.188.1: Bytes=32 Zeit=8ms TTL=128
Antwort von 192.168.188.1: Bytes=32 Zeit=10ms TTL=128
Antwort von 192.168.188.1: Bytes=32 Zeit=13ms TTL=128
Antwort von 192.168.188.1: Bytes=32 Zeit=12ms TTL=128
Zeitüberschreitung der Anforderung.
Antwort von 192.168.188.1: Bytes=32 Zeit=8ms TTL=128
Antwort von 192.168.188.1: Bytes=32 Zeit=9ms TTL=128
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Antwort von 192.168.188.1: Bytes=32 Zeit=16ms TTL=128
Antwort von 192.168.188.1: Bytes=32 Zeit=9ms TTL=128
Antwort von 192.168.188.1: Bytes=32 Zeit=8ms TTL=128
Antwort von 192.168.188.1: Bytes=32 Zeit=9ms TTL=128
Antwort von 192.168.188.1: Bytes=32 Zeit=9ms TTL=128
Antwort von 192.168.188.1: Bytes=32 Zeit=9ms TTL=128
Antwort von 192.168.188.1: Bytes=32 Zeit=11ms TTL=128

Es betrifft eben nur Clients, die an der letzten Stelle hängen.

Ich kann das auch insoweit reproduzieren als wenn ich die Master-FritzBox auf die 07.39-95378 wieder downgrade es zu keinen Abbrüchen mehr kommt. Ein Downgrade der Client-Fritzbox macht keinen Unterschied bzw. bringt keine Besserung.

Der Repeater läuft auf 07.29-93257, die Client-FritzBox aktuell mit 07.39-95703.
Ich habe die Heimetz-Einstellungen der Geräte schon einmal gelöscht gehabt, hat keine Abhilfe gebracht, auch nicht die Einstellung "unbeschränkt" beim Filter.
Die Client-Fritzbox oder der Repeater selbt scheint von dem Problem nicht betroffen, diese sind während solcher Aussetzer durchgehend per Ping erreichbar. Auch scheint das bei Geräten mit wenig Netzwerkverkehr nicht zu passieren oder nicht ins Gewicht zu fallen.

Ich habe keine Ahnung woran das liegen könnte? Von meinem Beobachtungen her muss die am VDSL-Anschluss hängende Fritzbox den Verkehr zu den spzeifischen Endgeräten (auch den innerhalb des Hauses, der durch die Box läuft) zeitweise blockieren.

Klar, es ist eine Inhause-Version, ich behelfe mich auch mit einem downgrade, trotzdem wundert es mich.

Vielleicht hat jemand eine Idee...

Viele Grüsse

 

[Grisu_]

Es betrifft eben nur Clients, die an der letzten Stelle hängen.

Oder doch am WLAN zw. 6000er und 7590-Repeater?
Könnte ja auch durch geändertes Mesh-Funktionalitäten hervorgerufen werden, dann wäre der Fehler noch immer 2. WLAN, aber Ursprung die Master-Box die so einiges vorgibt.

 

[myfb7590]

@Grisu_, bin mir nicht ganz sicher ob ich es richtig verstehe wie Du es meinst, es ist auf jeden Fall so, dass der 7590-Repeater selbst nicht betroffen ist, ich kann die Box durchwegs anpingen während ich zur gleichen Zeit einen Client, der daran hängt, nicht erreiche. Wo es aber auf der Strecke zwischen Master und 7590-Repeater-Client tatsächlich hakt, kann ich aber nicht herausfinden, falls Du das meinst.

 

[Grisu_]

Achso, der Repeater bleibt dabei erreichbar, dann hats wohl nix mit dessen WLAN oder Aussetzern.

Bei mir könnte es übrigens was ähnliches sein.
Nach einiger Zeit kann ich von meinem (über WLAN an der Repeater 7590) angebundenen Client gar NICHTS mehr erreichen, außer der Oberfläche besagter Repeater-Box, dort dann Neustart und alles geht wieder.
Kann kurz bis Tag dauern daß es soweit ist.
Aber wenn ich auf Gast-WLAN gehe habe ich sofort wieder volle Konnektivität (ins Internet), hilft nur nix wenn man auf eine Box zugreifen wollte.

Hast du vielleicht auch ein größeres als nur /24 Subnetz am Laufen (dahin geht nämlich inzw. meine Vermutung)?

 

[myfb7590]

Ich habe nur ein 24er Netz.
Aber mit der neuesten Inhaus (95703) mache ich auch die Beobachtungen, dass Geräte an LAN1-LAN4 nicht mehr erreichbar sind (der als LAN5 genutzte WAN-Port ist aber davon nicht betroffen). Neustart hilft wenn auch nur für kurze Zeit... ich habe die Firmware allerdings erst gestern aufgespielt, in der Zeit seitdem ist das zweimal passiert.

 

[Grisu_]

Zumindest beruhigend, daß wenigstens ein anderer auch von solchen Erscheinungen betroffen ist, vielleicht wirds dann bis zur Release ja noch behoben.
Was mich verblüfft, daß sonst noch niemand darüber geschrieben hat und scheinbar bei denen alles Eitel Wonne ist.
Fast als ob sonst keiner Boxen als Repeater einsetzen würde.

 

[meyergru]

Mal eine ganz dumme Frage, bevor ich mir das Risiko einer Inhaus-Version gebe:

Ich habe die aktuelle Labor (07.39-95780 BETA) im Einsatz und versuche, dort per Wireguard LAN2LAN zu machen. Das kann man zwar auswählen, muss dann aber beide Seiten der Konfiguration auf einmal erzeugen (d.h. die Fritzbox, auf der man die Konfiguration erzeugt, liefert auch den privaten Schlüssel der Gegenseite).

Es ist mir gelungen, eine solche Konfiguration auf einem anderen System zu konfigurieren (nicht Fritzbox) - es hat allerdings den Nachteil, dass man dort mehrere WG-Instanzen laufen lassen muss, wenn man mehrere VPNs zu verschiedenen Fritzboxen aufbauen will. Das heißt, man muss mehrere Ports öffnen, mehrere private Keys haben usw. Aber es funktioniert zumindest.

Ist die Gegenstelle aber eine andere Fritzbox, klappt das Ganze nicht, denn die erzeugte / angezeigte Konfiguration lässt sich dort nicht einspielen - bzw. kann ich nirgends angeben, unter welchen DynDNS-Namen die andere Box erreichbar sein soll. Im Idealfall sollen ja beide Seiten wissen, mit wem sie Kontakt aufnehmen können.

Ist das Problem, die Gegenseite zu konfigurieren, bei den Inhaus-Versionen gelöst oder funktioniert das genauso wenig wie bei der Labor?

Das kann m.E. auch nicht wirklich funktionieren, weil wie gesagt der Zwang existiert, die Konfiguration auf der einen Seite zu erzeugen und auf der anderen Seite einzuspielen, während die Konfig-Datei der Fritzbox am Ende nur eine einzige lokale Konfiguration beinhalten kann (siehe "wg_private_key"):

vpncfg {
        vpncfg_version = 1;
        global {
                wg_private_key = "$$$$ASLGAKFGASFÖHÖFASM6HUT2XPTFQXA1FHO2XUKHSKV5QX4BNJQPI2ETU4ZYAZBHP34USDAIBUHGUEYGOBMTI4DOYLX2IQF5WOQIBHKGE3DKBGTKS";
                wg_listen_port = 51463;
        }

Wie sollte man also mit den in der Fritz Labor vorhandenen Konfigurationsmöglichkeiten z.B. LAN2LAN VPNs zwischen drei Fritzboxen aufbauen? Mir ist es nicht mal mit zwei gelungen...

 

[B612]

zwischen drei Fritzboxen

Dann musst du das 3 mal einrichten. Immer zwischen 2 FB.

 

[meyergru]

Dann musst du das 3 mal einrichten. Immer zwischen 2 FB.

Ist mir klar. Wie? Die Fritzbox, auf der die Konfiguration erzeugt wird, gibt den privaten Key der anderen vor, wo es, wie ich gezeigt habe, nur einen Key geben kann (nicht zwei).

Also Fritzbox A gibt den privaten Key von Fritzbox B vor (erstes Problem: die nimmt die Konfiguration, wie sie von A erzeugt/angezeigt wird, gar nicht an).
Dann will ich Fritzbox C mit A koppeln: Die selbe Konfiguration wie die für B kann ich nicht nehmen, weil dann C und B nicht unterschieden werden könnten.
Also brauche ich eine neue Konfiguration auf A, gut. Die spiele ich auf C ein, was dort den privaten Key bestimmt (abgesehen davon, dass es nicht funktioniert).

So und jetzt will ich B und C koppeln. Egal wie ich es mache, die privaten Keys der beiden Boxen sind schon durch den jeweils von A vorgegebenen Key bestimmt. Also kann ich auf keiner der beiden Boxen eine Konfiguration einspielen, die funktionieren würde.

Das ist einfach die Beschränkung, die dadurch entsteht, dass ich bei der Erzeugung der Konfiguration immer beide privaten Keys erzeugen muss und keinen vorhandenen public key mitgeben kann, wie das sonst bei Wireguard möglich ist.

Folgerichtig habe ich ja auch nur eine Verbindung von einer Fritzbox zu einem Nicht-AVM-Gerät aufbauen können, und dort wird der Verbindungsaufbau auch nur von diesem Gerät zur Fritzbox aufgenommen und nicht in der Gegenrichtung (da ich auch die DynDNS-Adresse der Gegenstelle nirgends angeben kann).


Zumindest sehe ich in der aktuellen Labor keine Möglichkeiten, die Adresse oder den Public Key der Gegenstelle mitzugeben, wenn ich eine LAN2LAN-Kopplung einrichte. Ist das bei der Inhaus anders? Das ist ja genau meine Frage.

 

[B612]

So und jetzt will ich B und C koppeln.

Dann musst du auf B oder C eine neue Konfig erzeugen.

 

[meyergru]

Frage 1: Hast Du das tatsächlich erfolgreich gemacht?
Frage 2: Mit der Labor oder mit der Inhaus?

Meine Erfahrung ist, dass schon die Verbindung mit zwei Fritzboxen scheitert. Schaut man sich die Konfiguration auf der ersten Box an, sieht man, dass diese gar keine Verbindung zur zweiten Box aufnehmen kann (klar: man kann ja auch deren DynDNS-Adresse oder IP gar nicht angeben). Offenbar wird lokal nur eine Konfiguration erzeugt, die auf eingehende Verbindungen lauscht, aber selbst nichts aktiv tut (mangels Möglichkeit zur Angabe einer Ziel-Adresse in der Konfiguration in der Labor-Version).

Übernimmt man dann die erzeugte Konfiguration in die zweite Box, steht dort der DynDNS-Name der ersten Box drin, so dass eine Verbindung zur ersten Box theoretisch erfolgen könnte - das klappt bei mir praktisch aber nicht. Meine Vermutung ist, dass dies nicht möglich ist, weil ich dort vorher noch eine andere VPN-Verbindung eingetragen hatte, die den (einzig möglichen) wg_private_key (siehe oben) bereits vorgegeben hatte.

Da die erste Box bei der Erzeugung der Konfiguration den private Key der Verbindung vorgeben möchte (er steht in der erzeugten Konfiguration drin, die man auf die zweite Box übernehmen soll), kann das nicht klappen - er wird nicht übernommen (das weiß ich sicher, weil die erste WG-Verbindung weiter funktioniert, also bleibt offensichtlich der alte Key erhalten). Somit kann die Verbindung in dieser Richtung auch nicht zustande kommen.

Ich glaube, so wie AVM das konzipiert hatt, kann LAN2LAN nicht klappen, weil dazu ein Schlüsselaustausch der Public Keys notwendig ist. Das Konzept ist einfach fehlerhaft und kann nur für Einzelverbindungen klappen, z.B. für Mobile Clients, denen man den private Key einfach "aufdrücken" kann.

Es funktioniert auch dann, wenn man eine Wireguard-Gegenstelle hat, bei der man den private Key vorgeben kann (bei Fritzboxen also nicht). Dann benötigt man dort aber für jede Verbindung eine eigene Instanz, weil pro Verbindung ein separater private Key benötigt wird.

Normalerweise ist es mit Wireguard ja möglich, die lokale Seite einmal zu definieren und dann beliebig viele Gegenstellen anzugeben. Genau deswegen muss man den Gegenstellen seinen public Key ja nennen. AVM erwartet, dass sie der Gegenstelle den (inklusive des private Key) immer vorgeben können, was spätestens mit 2 Gegenstellen nicht mehr funktioniert (deswegen mein Beispiel mit 3 Fritzboxen, wo jede mindestens zwei Verbindungen bräuchte).

Eventuell ließe sich das per manuellem Eingriff in die Fritzbox-Konfigurationsdatei machen, allerdings ist mir die Bedeutung der "wg_"-Parameter schleierhaft. Insbesondere sehe ich nicht, wie ich den Adresse einer Gegenstelle vorgeben könnte - wg_dyndns ist es nicht, das ist der eigene Name. Und wg_master_config ist auch irgendwie seltsam, denn es enthält anscheinend eine normale Wireguard-Configuration - ich bezweifele aber, dass das funktioniert, weil der ListenPort nur einmal global definiert wird. Also kann eigentlich die "[Interface]"-Sektion da drin nicht funktionieren.