FRITZ!Box 7580 Fritz!OS 153.07.00 Release vom 24.07.2018

[7490tester]

Erstaunlich, dass das erst jetzt Einzug findet. Ich meine, dass Fehler in der HW durch SW umschifft werden (müssen) ist doch nichts Neues. Natürlich würde ich auch gerne wissen, was da genau los ist oder war, aber am Umstand an sich finde ich nichts mysteriös.

 

[NDiIPP]

Aber was wurde genau ab Seriennummer "J115" 10.03.2017 geändert?

Vielleicht wanderten da die beiden WiFi-Module mit auf das PCB? Allerdings hätte ich da eine neue HWSubRev erwartet.

Intel / Lantiq VRX318.

Auf den tippe ich eher mal nicht. Ich tippe eher auf WLAN (was nicht heißt, dass ich richtig liegen muss).

Irgendwas war da doch mal bei den ersten Chargen eines neuen Fritzbox-Modell mit dem WLAN was mit einem Fix in einer neuen Firmwareversion behoben wurde. Ich weiß nur leider nicht mehr ob es überhaupt die 7580 war und auch nicht mehr ob das Problem damals mit Ver. 6.83 behoben wurde.

Edit
Ah verdammt! Man sollte doch immer auch die letzten Beiträge im Thema lesen und den Links darin folgen bevor man antwortet. @PeterPawn hatte ja des Rätsels Lösung in #59 bereits verlinkt...

 

[eisbaerin]

Vielleicht wanderten da die beiden WiFi-Module mit auf das PCB?

Warum muß da dann was an der SW geändert werden?
Wegen einer anderen Leitungsführung?

Allerdings hätte ich da eine neue HWSubRev erwartet.

Eine mögliche Ursache, die ich mir vorstellen könnte:
AVM hat bei der Produktion die HWSubRev zu einem falschen Zeitpunkt (zu früh) auf 2 erhöht. Falsche Environment eingespielt. Und als sie das gemerkt haben, wurde die rc.errata.sh erfunden um das zu korrigieren.

des Rätsels Lösung

Das war aber nur eine Vermutung von mir.

Irgendwas war da doch mal bei den ersten Chargen eines neuen Fritzbox-Modell mit dem WLAN was mit einem Fix in einer neuen Firmwareversion behoben wurde.

Ging da das WLAN gar nicht oder zu schwach oder ...?

 

[NDiIPP]

Wegen einer anderen Leitungsführung?

Ich würde in diesem Zusammenhang eher auf eine andere Revision der WLAN-Chips tippen.

Das war aber nur eine Vermutung von mir.

Mit "des Rätsels Lösung" meinte ich, dass das tatsächlich mit dem WLAN zusammenhängt und nicht mit dem DSL AFE (VRX318).

Ging da das WLAN gar nicht oder zu schwach oder ...?

Imo weder noch. Ich glaube da gab es wohl mal Probleme mit einigen WLAN-Clients unter bestimmten Bedingungen.

 

[Athanatos]

@Athanatos Hast du mal die Werkseinstellungen geladen und die Box anschließend manuell neu konfiguriert?

Ja, hatte ich gemacht. Die Box ist erst mit 7.00 neu eingerichtet worden.

Auch die neue BETA 60403 für den 1750E funktioniert mit meiner 7580 mehr schlecht als recht. Teils verbindet sich der Repeater nach dem Einstecken gar nicht - erst nachdem das WLAN deaktiviert und wieder aktiviert wurde -, teils gibt es wieder die genannten Verbindungsabbrüche.

Kurioserweise sind diese mit anderen WLAN-Geräten ohne bewusste Änderungen (!) deutlich zurückgegangen. Hmm...

 

[PeterPawn]

Ein von mir beobachtetes Problem:

1. FRITZ!Box 7580
2. 1&1-Branding
3. Werkseinstellungen
4. Einrichtungsassistent (der will unbedingt einen Startcode) abgebrochen
5. manuelle Konfiguration als Router über Ethernetverbindung an "WAN"
6. externen GUI-Zugriff über "Internet -> Freigaben -> FRITZ!Box-Dienste" freigeschaltet

Ergebnis:

• kein Zugriff von der WAN-Seite möglich
• Sicherheitsdiagnose zeigt keine geöffneten Ports an
• auch zwischenzeitliche Neustarts ändern daran nichts

Nächster Schritt:

• Einrichten einer eigenen VoIP-Rufnummer (Dummy, keine Registrierung möglich)

Ergebnis:

• immer noch kein Zugriff von der WAN-Seite möglich
• Sicherheitsdiagnose zeigt die geöffneten Ports für SIP und RTP an

Nächster Schritt:

• Einrichten einer VPN-Verbindung für eine LAN-LAN-Kopplung (BTW: Das "mittlere" Kennwort ist und bleibt beim VPN ein echter Witz, aber immerhin kommt das GUI-Kennwort von AVM auf der benutzten Box auch nur auf die Bewertung "mittel".)

Ergebnis:

• immer noch kein Zugriff von der WAN-Seite möglich
• Sicherheitsdiagnose zeigt die geöffneten Ports für SIP, RTP und VPN an

Nächster Schritt:

• Einrichten einer VPN-Verbindung für einen Benutzer (dabei gleich das nächste Problem beim Anlegen des Benutzers (ich komme ja von den Werkseinstellungen), gehe ich später drauf ein)

Ergebnis:

• jetzt erst ist der Zugriff von der WAN-Seite möglich
• Sicherheitsdiagnose zeigt die geöffneten Ports für SIP, RTP, VPN und HTTPS an
• auch das Löschen der VoIP-Nummer und der VPN-Verbindung ändert daran nichts mehr
• auch nach einem Neustart ist die Freigabe wieder aktiv

Ursache:

Schaut man sich im Verlauf der beschriebenen Aktionen immer wieder mal den Inhalt der "ar7.cfg" an (bei "internet_forwardrules"), fällt auf, daß der Eintrag für den HTTPS-Port (ich habe hier einfach mal 443 im GUI so belassen - immerhin ist das die angebotene Voreinstellung) gar nicht auftaucht, obwohl die anderen Einstellungen (Abschnitt "websrv", Werte "https_port" und "wanaccess") richtig gesetzt werden.

Man darf also als These für die Fehlersuche und -behebung sicherlich erst einmal davon ausgehen, daß beim Setzen von "remoteman:settings/enabled" ein Trigger fehlt, der das "Zusammensuchen" der freizugebenden Ports anstößt oder daß dabei eine Randbedingung nicht erfüllt ist und damit der HTTPS-Port nicht in die Liste der freizugebenden Ports (und in der Folge dann auch nicht in den gespeicherten Einstellungen) eingeschlossen wird. Diese These wird sich zwar - hinsichtlich der Speicherung in "internet_forwardrules" - als falsch erweisen, aber sie kann die Überlegungen erst einmal auf die richtigen Fragen lenken.

Bei der Überlegung, was diese Randbedingung bzw. fehlende Voraussetzung wohl sein könnte, stößt man dann unweigerlich darauf, daß für den externen Zugriff natürlich auch ein Benutzer erforderlich ist und daß AVM seit 07.00 tatsächlich beschreibt, daß der "Standardbenutzer" für das NAS mit dem Namen "ftpuser" für externe Zugriffe nicht mehr verwendet werden kann:

• Änderung Der voreingestellte Benutzer "ftpuser" kann aus Sicherheitsgründen nicht mehr für den Zugang aus dem Internet freigegeben werden.

Und genau da liegt dann auch der Hund begraben ... solange beim Aktivieren von "Internetzugriff auf die FRITZ!Box über HTTPS aktiviert" kein Benutzer-Account vorhanden ist, der diesen Zugang auch benutzen könnte, wird die Freigabe einfach nicht eingerichtet - eine entsprechende Fehlermeldung und/oder einen verständlichen Hinweis im GUI sucht man an dieser Stelle aber auch vergeblich.

Verwirrender wird das dann noch dadurch, daß es auch nicht ausreicht, einem Benutzer nachträglich dieses Recht "Zugang auch aus dem Internet" einzuräumen ... dabei erfolgt offenbar keine neuerliche Prüfung, ob nun vielleicht auch die betreffende Freigabe zu aktivieren wäre - ansonsten nutzt dem Benutzer dieses Recht ja auch wieder nichts so richtig.

Man muß jetzt tatsächlich noch einmal in die "FRITZ!Box-Dienste"-Seite gehen und die Einstellungen erneut übernehmen (glücklicherweise muß man die Option nicht erst noch deaktivieren, um sie wieder aktivieren zu können - aber das ist eigentlich bei allen Lua-Seiten von AVM so, daß sie am Beginn erst mal die Auswertung der Formulardaten machen und dann eben auch dieselben Werte erneut setzen, wenn man "Übernehmen" gewählt hat), damit man im Anschluß auch die Freigabe für den HTTPS-Port (und nur für diesen) in der Seite mit der Sicherheitsdiagnose bestaunen kann.

Am Ende war die Herleitung der Ursache tatsächlich eine "Odyssee", die durch die ständigen Neustarts und auch das wiederholte Zurücksetzen auf Werkseinstellungen (damit die Bedingungen reproduzierbar sind) auch entsprechende Zeit in Anspruch nahm ... ich habe das mal so ausführlich berichtet (vollkommen entgegen meiner sonstigen Gewohnheiten), um damit mal zu zeigen, wie sich eine Erklärung für ein festgestelltes Fehlverhalten (und um ein solches handelt es sich in meinen Augen, wenn es keine Fehlermeldung gibt - wobei ich natürlich applaudiere, wenn keine Ports freigegeben werden, die gar nicht genutzt werden können) am Ende an einem vollkommen anderen Punkt in der Firmware finden kann.

Im Verlauf der Suche nach dem hier beschriebenen Problem bin ich dann wohl auch darüber gestolpert, warum das Eintragen eigener Freigaben in der "ar7.cfg" unter "internet_forwardrules" am Ende nichts (mehr) bringt (und damit auch das "avm_forwarding"-Paket im Freetz spätestens jetzt obsolet wäre) ... das FRITZ!OS selbst scheint diese Einstellung jedenfalls gar nicht mehr zu verwenden. Auch wenn die Freigabe für HTTPS eingerichtet ist und funktioniert, gibt es immer noch keine entsprechende Einstellung in der "ar7.cfg" - das war in vorhergehenden Versionen allerdings noch anders, wenn ich mich recht erinnere.

---------------------------------------------------------------------------------

Auf die deutlich zu schwache Forderung nach einem Kennwort mit Qualität "mittel" i.V.m. einer LAN-LAN-Kopplung bin ich schon mehrfach eingegangen ... dieses Kennwort ist einfach bei "aggressive mode" der einzige vorhandene Schutz einer solchen Verbindung (in der Phase der Einrichtung) - das ist einer der Gründe, warum man auch heute noch im Internet Stellen findet, an denen von der Verwendung dieses "aggressive mode" strikt abgeraten wird.

Aber mit ausreichend starkem Kennwort kann man den tatsächlich benutzen ... jedoch gehen die Meinungen, was da "ausreichend" ist, offenbar stark auseinander.

Wie oben schon mal kurz angerissen, fand ich es trotzdem putzig, daß auch das voreingestellte Kennwort für das GUI nur eine "mittlere" Qualität bescheinigt bekommt ... irgendwo in grauer Vorzeit hatte ich mal versucht aufzuzeigen, daß die Kombination eines vier- oder fünfbuchstabigen Wortes (Gibt es vielleicht sogar welche mit sechs Buchstaben? Wenn ja, ist mir noch keine derartige Box untergekommen.) der deutschen Sprache (die man eben mit einem Wörterbuch auch prima durchprobieren kann) und einer vierstelligen Zahl (die dann aus einem Wort halt 10.000 unterschiedliche macht, was aber immer noch keine "echte" Größenordnung beim Kennwort-Knacken ist) noch keinen wirklich sicheren "Schlüsselraum" für ein Kennwort ergibt - und da hilft auch der Brute-Force-Schutz des FRITZ!OS nur wenig, weil man mit einer einzigen mitgeschnittenen Anmeldung in aller Ruhe auch offline das richtige Kennwort errechnen lassen kann.

Nochmal: Besser als kein Kennwort für den ersten Zugriff ist es allemal, aber zu dieser Erkenntnis dürfte auch bei AVM eher das Testkonzept des BSI für die Bewertung von SOHO-Routern beigetragen haben (Punkt 3.4.1) als eigene Einsicht - insbesondere in Anbetracht der Tatsache, wie lange der unsichere Erstzugang bei AVM überleben konnte und daß es auch heute noch möglich ist, den Modus "Kennwortlose Anmeldung (nicht empfohlen)" auch ohne den Tastendruck zu betreiben, der nach

• Änderung Die nicht empfohlene Option "Kennwortlose Anmeldung" an der FRITZ!Box-Benutzeroberfläche erfordert nun einen Tastendruck an der FRITZ!Box

ja angeblich erforderlich sein soll - die Checkbox im GUI dieser Version sagt da etwas anderes:


Auch könnte das GUI meiner Ansicht nach durchaus eine entsprechende Warnung (zumindest auf der "Sicherheit"-Seite) vertragen, wenn die Anmeldung dauerhaft auf "Anmeldung mit dem FRITZ!Box-Kennwort" eingestellt bleibt und dabei weiterhin das voreingestellte Kennwort verwendet wird anstelle eines eigenen (gilt ähnlich auch für den WPA2-PSK).

Denn es ist für jedes Gerät, was zum Zeitpunkt eines "Power-On"-Starts der FRITZ!Box per LAN-Kabel auf die Box zugreifen könnte, immer noch ein Leichtes, dieses Kennwort aus dem Environment zu extrahieren (ja, das habe ich schon einmal irgendwo behauptet, falls jemand jetzt ein Déjà-vu haben sollte) ... und es in der Folge dann natürlich auch zu benutzen. Wenigstens kann man damit jetzt nicht mehr von extern auf die Box zugreifen (es ist ja gleichzeitig das Kennwort des "ftpuser") ... ein erster Schritt wäre auch hier wieder getan.

---------------------------------------------------------------------------------

Das nächste "Problem" (bzw. eigentlich ist es nur eine "Unstimmigkeit" im GUI, die aber recht fiese Auswirkungen haben kann) ist das Einrichten eines Benutzers bei aktivierter 2FA. Während an den anderen, per 2FA gesicherten Stellen im GUI die Abfrage erscheint und die ursprünglich auslösende Aktion nach dem "OK" im Bestätigungsfenster automatisch fortgeführt wird, ist das beim Anlegen eines neuen Benutzers eben nicht der Fall - man kann es mit einem weiteren Fenster für das GUI ganz einfach verifizieren, während die Eingabemaske noch angezeigt wird nach der 2FA-Bestätigung.

Wer hier jetzt irgendetwas anderes macht, als erneut auf "Übernehmen" zu klicken, der darf den neuen Benutzer dann gleich noch ein zweites Mal anlegen (was dann auch klappt, weil die zuvor eingeholte 2FA-Bestätigung ja für die weitere Session gilt).

Es gibt ja leider auch genug Seiten im GUI, wo dieses Verhalten "normal" wäre und nach "Übernehmen" die Seite zwar erneut angezeigt wird, aber vorgenommene Änderungen tatsächlich gespeichert wurden - man erkennt es leider trotzdem nicht und vielleicht sollte AVM in so einem Falle einfach den "Übernehmen"-Button bis zur nächsten Änderung einer Einstellung deaktivieren.

---------------------------------------------------------------------------------

Und um der Frage zuvorzukommen, ob ich irgendetwas davon direkt an AVM gemeldet hätte: Nein, das habe ich nicht getan.

Warum nicht?

Die Gründe bzw. Überlegungen dazu haben ich dann doch in einen gesonderten Thread gepackt:

https://www.ip-phone-forum.de/threads/der-nächste-bitte-oder-die-frage-welche-erfahrungen-andere-mit-dem-avm-support-gemacht-haben.300704/

- hier paßten sie dann eher nicht mehr hinein:

 

[Dann halt nicht mehr]

Die 7.01 ist da.