FRITZ!Box 7490 Fritz!OS 113.07.01 Release vom 12.09.2018

[markus397]

Hast Du mal das schnellere 5GHz-Netz zum Repeaten versucht? Die 7590 rennt wohl auch mit 7.0?
In #81 wird ein ähnliches "Repeater-Problem" im 2,4GHz-Netz angedeutet.
LG

Habe ich noch nicht gemacht, da im Log steht das es kurz wegen Radar immer mal wieder weg ist.
Hatte Befürchtungen das die Verbindung damit instabiler wird XD.

Das Problem ist die Telefonie meiner Eltern läuft über den Repeater und der muss halt laufen. Bringt nix wenn die Verbindung abreist und keine Gespräche mehr rein kommen weil man es gerade nicht mit bekommt. Technisch sind die halt auch nicht so versiert.

und ja die Master 7590 ist auf 7.0

 

[H´Sishi]

Die Radarerkennung ist nur bei den dreistelligen Kanälen, 48-64 sind ok, wenn sonst niemand darauf funkt.

 

[Micha0815]

AVM meint 36-48? Mag sein, dass auf 48-64 typische Hinderungs-Ereignisse seltener anstehen? In den Logs sah ich noch nie, auf welchen Kanal genau das Ereignis eintrat bzw. wer oder was es auslöste.
LG

 

[DickS]

Versuche mal PMF (WLAN-Sicherheit) zu deaktivieren (falls aktiv).

 

[bino]

Frage in die Runde:
Bei mir werden die Balken in der DSL-Information --> Statistik
seit längerem und auch in der Final zu schmal dargestellt.
Früher war das nicht so.
Ist das nur bei mir der Fall?
Wenn nicht, würde ich gezwungenermassen mal recovern?
Danke!
bino

 

[Fieser-Kardinal]

Bei mir wird es auch so schmal dargestellt.

 

[avm_7170]

Ratet mal, was ich gerade bei der 7590 mit der 7.0 gefunden habe. ;-)

Und was hast du gefunden ? Ich finde Rate-Spiele in einem Forum deplatziert

 

[7490tester]

Hhm, Leute die sich nicht einmal einen gesamten Beitrag durchlesen und dann solche Kommentare lassen aber irgend wie auch.

 

[goa-inge]

Hm, ich hätte nicht gedacht, dass es so schwierig ist von "Spoiler: CheckDisk-Protokoll" auf den NTFS-Treiber zu schließen. Schließlich war es ja geradezu ein Running-Gag von mir bei jeder neuen Labor vom Fehler zu berichten.

Im Endeffekt wollte ich darauf hinaus, dass AVM hier einen sehr mutigen Weg gewählt hat sich um diesen Fehler zu kümmern bzw. die 7.0 bei anderen Modellen zu releasen, denn es handelt sich wohl nicht um einen hardwarespezifischen Bug, da scheinbar alle Modelle mit FRITZ!OS 7.0 betroffen sind.

 

[avm_7170]

auf welchen Kanal genau das Ereignis eintrat bzw. wer oder was es auslöste.

Bei mir der Kanal 124, hatte heute wieder das Problem mit der Radarerkennung ...bei der 7490 die nur als Mesh Client und Repeater läuft ... diese hat einen Kanalwechsel durchführen wollen und dann die WLAN Verbindung zum Master 7590 verloren, der ist auf Kanal 124 geblieben. Ich musste mehrmals "Wlan aus" und "Wlan an" bei der 7490 ausführen.

Worauf stützt sich denn die These das es bei den Kanälen 48-64 die Radar Erkennung besser läuft oder das dort keiner vorhanden ist.

 

[sffan]

Dann liess Dir besser mal die Hinweise im 1&1-Kundenforum durch, bzgl. Neuerungen im OS7.0x und DS-Lite als "Standard-Einstellung". IPv6/IPv4 als Dualstack richten sie auf Anfrage sofort ein.
... Vollzitat gekürzt by stoney

Hach, ich weiss, daß man da schon seit mehr als einem Jahr sich "anmelden" kann. Unter "anbieten" verstehe ich halt etwas Anderes. Das "anmelden" hört sich für mich eher nach Teilnahme an einem öffentlichen Beta-Test an. Dafür habe ich weder Zeit noch Lust. Und damit ist Deine freundliche Klarstellung mindestens genauso "unrichtig". Wie so oft: Alles Ansichtssache.

 

[avm_7170]

auch Vodafone erklärt jedem Kunden wie man die IPV6 in der Fritzbox einzurichten sind, aber man bekommt eben keine IPV6 das Vodafone bei DSL eben keine zuordnet .....

 

[Micha0815]

...
Worauf stützt sich denn die These das es bei den Kanälen 48-64 die Radar Erkennung besser läuft oder das dort keiner vorhanden ist.

Im Normalfall möchte man ja die Radarerkennung eher vermeiden, um das Umschalten zu verhindern? Ich kenne nur die in der WIKI genannten Kanäle.

Das sicherlich häufiger anzutreffende Problem, dürfte der Standort einer Master-WLAN-Mesh-FB und einer reinen WLAN-Repeater-FB sein. Die Master-FB z.B. im EG/UG/Keller bekommt von Radarstörungen nichts mit und die Repeater-FB im OG/Wintergarten o.ä wechselt munter die Kanäle. (bzw. muss dies).
Ob die Umkehr der Mesh-Rollen (Master<->Repeater) dieses Problem behebt, weiss ich nicht.
Zumindest las ich noch von keiner Konstellation hier im Forum, wo eine am DSL hängende FB Mesh-Client war und eine WLAN-Repeater-FB als Mesh-Master fungierte, da dies imho so nicht funktionieren kann.
LG

 

[andilao]

Soeben Update gemacht und es lief sehr sauber ab, einzig die Aktivierung des "E-Mail-Filter über Port 25" war etwas übertrieben. Aber wie soll AVM auch wissen, dass es ein Mailserver im selben Subnetz ist? An der IP-Adresse des SMTP-Servers? Letztendlich hat sich dadurch nur die Fritzbox selbst blockiert. Sehr nett ist der neue "WPAD-Filter".

 

[7490tester]

Ganz ehrlich, ich würde auch einen eigenen Mailserver nicht mehr unsicher über Port 25 verschicken lassen.

 

[PeterPawn]

Ganz ehrlich, ich würde auch einen eigenen Mailserver nicht mehr unsicher über Port 25 verschicken lassen.

Wo steht denn, daß dass "unsicher" sein muß? Oder wolltest Du gar nicht "Port 25 == unsicher" postulieren?

Ein fremder SMTP-Server kontaktiert ein Relay (oder den Zielhost, das ist egal) normalerweise erst mal auf Port 25 (der Port 465 für SMTPS muß nicht von jedem SMTP-Server unterstützt werden und eine "Anzeige" dafür - im DNS oder so - gibt es auch nicht - wenn der Sender das "probieren" möchte, ist das seine Sache) und stellt dann in der EHLO-Antwort fest, ob der Server STARTTLS versteht. Dann kann er immer noch auf TLS umschalten, wenn er (oder der Empfänger-Server) das möchte und die Verbindung ist sicher.

Nur kann die FRITZ!Box das halt ohne "deep packet inspection" nicht feststellen, ob ein Mail-Versand über TLS stattfindet oder nicht - auch wird das sicherlich eher wg. Spam-Versand durch irgendwelche Apps bzw. infizierten Geräte im LAN gesperrt und weniger wg. der Frage der Sicherheit.

Wenn man solche Vorkehrungen trifft, rechnet man ja offenbar mit infizierten Geräten im LAN - oder man wollte hier nur zu den Speedports aufholen, die das schon vor den FRITZ!Boxen wegfilterten an Telekom-Anschlüssen, wo man sich erst einen abbrechen mußte, wenn man einen anderen Mail-Server (und dann noch einen auf Port 25) verwenden wollte.

Auch hier hat AVM m.E. noch eine "Versorgungslücke" in der Implementierung, selbst wenn viele Mail-Server beim ersten "Einliefern" inzwischen auf "submission" setzen ... aber eine Ausnahme für einen Mail-Server sollte man schon hinterlegen können, auch wenn man Port 25 ansonsten gesperrt haben möchte.

Diese "alles oder nichts"-Option verhindert eben auch die Benutzung eines (gültigen) Mail-Kontos zum Versand von irgendeinem LAN-Host, solange der zugehörige Server nur auf Port 25 seine Dienste als Briefkasten offeriert.

 

[andilao]

Clients versenden per Port 25 über den lokalen Mailserver. Und bei den Clients handelt es sich um Fritzboxen, Geräte und PCs, welche Logfiles und Statusmeldungen versenden, die also von zu Hause nach Hause telefonieren. Wenn ich den Port 25 an der Box filtere, wird allein diese Box aus vorauseilendem Gehorsam keine Meldungen mehr versenden können.

Positiv: Die 7.01 schaltete nicht wie das 7.0 auf der 7560 beide WLANs auf Autokanal.

 

[H´Sishi]

Ok, mein Fehler dann. Ich nahm (mangels besseren Wissens) an, daß die Radargeräte nur auf den höheren Kanälen funken, schon wegen der großen Lücke zwischen 64 und 100.

Mir neu ist auch, daß es auch in den unteren Kanälen DFS und RadarDetection geben KANN (nicht muß) sowie alle 5 GHz-Kanäle zunächst als "nicht verfügbar" behandelt werden müssen. Außerdem soll es (gemäß der Norm EN 301 893) eine 24h-Zwangstrennung der 5 GHz-Verbindungen geben, was aber wohl nicht von allen Herstellern und (professionellen) Anwendern eingehalten wird.
Quelle: https://www.wlan-skynet.de/docs/rechtliches/etsi_301_893.shtml

 

[johnripper]

Clients versenden per Port 25 über den lokalen Mailserver. Und bei den Clients handelt es sich um Fritzboxen, Geräte und PCs, welche Logfiles und Statusmeldungen versenden, die also von zu Hause nach Hause telefonieren. Wenn ich den Port 25 an der Box filtere, wird allein diese Box aus vorauseilendem Gehorsam keine Meldungen mehr versenden können.

Grds. gebe ich dir Recht, aber der Anwendungsfall ist schon semi-professionell. Und eine FB ist immer noch Consumer.

Abgesehen davon gehört im professionellen Umfeld "testen" dazu.

Hätte man ferner die Funktion als opt-in gestaltet hätte man sie auch weglassen können, weil man gerade die User nicht bekommt, die SPAM via Port 25 rausblasen.

Auf der anderen Seite bezweifle ich aber den Nutzen: gute ausgehende Mailserver lassen kein Login auf port mehr zu und eingehende Mailserver lehnen die Verbindungen von variablen Addressbereichen schon seit ewiger Zeit ab oder filtern anderweitig.

 

[H´Sishi]

Stimmt, aber ich würde anstatt "gute ausgehende Mailserver" mit "seriöse ausgehende Mailserver" ersetzen. Irgendwo müssen doch die Spamwellen herkommen und es dürfte technisch kein Problem sein, unseriöse Mailserver per se zu blockieren.