FRITZ!Box 7490 - Labor 113.07.08-64272 vom 17.12.2018

[Tuffi]

@OD1001: Glückwunsch.
Funktioniert es mit dem InternetExplorer/Edge, Chome o.ä.?

 

[HarryP_1964]

Wollte ich auch gerade schreiben, einfach mal den (aktuellen ) IE versuchen!

Harry

 

[pctelco]

Bei meinem ersten Versuch hat das Update auch nicht geklappt, es kam auch keine Fehler-Email, es wurde einfach kommentarlos die alte 7.01 wieder hoch gefahren.
Beim zweiten Versuch jedoch (bei mir auch Win10 64Bit und FF V64.0 64Bit) ging es dann jedoch problemlos.
Also einfach weiter versuchen!

 

[OD1001]

Mit Chrome hat's endlich funktioniert. Danke.

 

[PeterPawn]

Für diejenigen, die entweder "modfs" verwenden oder "Freetz" oder sonstwie mit eigenen Tools auf der Suche nach der Versionsnummer in einer (nicht aktiven) Dateisystemkopie dieser Labor-Version sind:

Die bereits bei einer Inhouse-Version mal angemerkte Änderung hinsichtlich des Speicherortes für die Versionsinformationen (https://www.ip-phone-forum.de/threa...r-firmware-intern.294029/page-81#post-2306405) hat es jetzt auch in diese Labor-Version geschafft.

Damit stehen die Versionsinformationen nicht mehr (primär) in der "/etc/version", sondern in der "/etc/init.d/rc.conf" und sehe bei dieser Version dann so aus:

372 ##########################################################################################
373 ## Box spezifische Konfiguration (aus Produkt.init)
374 ##########################################################################################
375 export CONFIG_ANNEX="B"
376 export CONFIG_INSTALL_TYPE="mips34_512MB_xilinx_vdsl_dect446_4geth_2ab_isdn_nt_te_pots_2usb_host_wlan11n_27490"
377 export CONFIG_VERSION="07.08"
378 export CONFIG_SUBVERSION="-64272"
379 export CONFIG_VERSION_MAJOR="113"
380 export CONFIG_ROMSIZE="0-sflash_size=1MB-nand_size=512MB"
381 export CONFIG_RAMSIZE="256"
382 export CONFIG_RELEASE="2"
383 export CONFIG_BETA_RELEASE="1"
384 export CONFIG_LABOR_ID_NAME="BETA"
385 export CONFIG_BUILDTYPE="1001"
386 export CONFIG_BUILDNUMBER="64272"

Dadurch funktionieren einige meiner Tools nicht mehr, die ja wiederum bei einigen IPPF-Lesern im Einsatz sind ... bis hin zum Boot-Manager, der die Versionsinformationen an dieser Stelle noch nicht auslesen kann.

Ich werde mich bemühen (nachdem das nun auch in die offizielle Labor-Version Einzug gehalten hat), das schnellstmöglich zu korrigieren bei "meinen" Tools ... Fehlermeldungen dazu also bitte nur dann absetzen, wenn es sich schon um eine neue/korrigierte Version handelt nach Ansicht des Berichtenden.

 

[H´Sishi]

Das ist definitiv neu und schon seit Ewigkeiten eigentlich Pflicht.

Es geschehen noch Wunder. Endlich kann man an der Fritze die Status-LED's per Benutzeroberfläche abschalten.

Das ist so neu nicht - es gab in sehr frühen Laborserien schonmal so einen Schalter, der aber irgendwann wieder entfernt wurde.
Als WorkAround haben ein oder zwei IPPF-User Umschalt-Scripts per PHP-Seite angeboten; außerdem konnte man in der EXPORT-Datei den Parameter ebenfalls umstellen.

Aber auch ich begrüße den wieder vorhandenen Schalter.

*edit*

Für das aktive Steuern von WLAN-Geräten zwischen FRITZ!Box und WLAN-Repeater(n) müssen folgende Voraussetzungen erfüllt sein:
- Sowohl FRITZ!Box als auch Repeater nutzen die aktuelle Laborversion

Doh ... mein DVB-C hat weder eine offizielle Labor noch eine 7.08-Inhouse.

 

[fritz-fuchs]

Mit den aktuellen Labor- und Inhausversionen für die FB 7490 und FB 7590 ist bei mir kein Zugriff mehr auf den 1&1-Onlinespeicher mehr möglich. Das Verzeichnis wird als "leer" angezeigt. Das betrifft den Zugriff über FRITZ!NAS und auch den Zugriff über Windows. Ich hatte es schon hier beschrieben:
https://www.ip-phone-forum.de/threa...r-firmware-intern.294029/page-85#post-2309096
Hat das Problem sonst noch jemand?
Habe den Onlinespeicher vorübergehend mit meiner FB 7390 verbunden, bei der alles problemlos funktioniert.

 

[Master SaMMy]

Wenn ich ein usb Stick an die Box mache 7590 geht er bei mir der Onlinespeicher

und bin auch bei 1und1

 

[H´Sishi]

Der interne Speicher der 7490 ist nur 512 MB groß und wird zudem noch für Fax- und AB-Features genutzt. Ist also zu klein.

 

[fritz-fuchs]

Es ist mir bekannt, dass sich der Onlinespeicher nur mit eingestecktem USB-Stick verbinden kann. Er verbindet sich bei mir ja auch, jedoch werden die dort vorhandenen Daten nicht angezeigt ("das Verzeichnis ist leer"). Hochladen einer neuen Datei ist möglich und diese wird auch kurzfristig angezeigt. Kurze Zeit später wird das Verzeichnis wieder als leer angezeigt. Lade ich die gleiche Datei nochmal hoch, kommt die Frage, ob die bereits vorhandene Datei überschrieben werden soll. Der Fehler tritt bei mir seit der Installation der neuen Inhaus auf der FB 7590 und der FB 7490 auf und ist hier auch bei den aktuellen Laborversionen vorhanden.

 

[digi1]

Eben probiert, Zugriff auf den 1u1 Onlinespeicher ohne Probleme in vollem Umfang möglich....

 

[jumPM]

Ich habe die Labor-Firmware auf meiner 7490 und dem Repeater 1750E installiert. Mit dem aktiviertem AP Steering kommt offensichtlich mein Smartphone (Sony Xperia X mit SailfishOS 2.2.1) nicht klar. Zumindest stürzt der Netzwerk-Stack komplett ab und es lässt sich nur per Soft-Reset wieder zum Leben erwecken. Dann funktioniert es einige Minuten bis zum nächsten Crash.

Laut Eintrag in der Fritzbox werden 802.11k/v von dem Gerät unterstützt. Wäre nun die Frage, ob es an SailfishOS selbst liegt oder an den Treibern für die WLAN-Hardware. SailfishOS nutzt ja über einen Software-Layer die originalen Android-Treiber. Hat jemand ein Xperia X oder auch ein anderes Sony Smartphone und kann das mal testen?

Natürlich muss auch das FritzOS nicht unschuldig sein, falls das AP Steering nicht standardkonform arbeiten sollte...

 

[DickS]

@jumPM Ob ein Gerät dies Unterstützt kannst du in der Fritzbox sehen auf Heimnetz, Mesh, Details klicken zum Gerät und runterscrollen. Da sollte es stehen.

Hast du bei WLAN das PMF aktiviert in der Fritzbox? Das kann zu diesem Fehlerbild passen.

 

[jumPM]

@DickS: Ja, mein Smartphone mit SailfishOS unterstützt 802.11k/v laut Fritzbox. PMF habe ich ausgeschaltet.

Mir ist noch aufgefallen, dass unter WLAN->Funkkanal die Auslastung der Funkkanäle nicht immer korrekt angezeigt, wenn ich auf der Fritzbox einlogge. Ändere ich die Bandsteering-Option, dann funktioniert die Grafik korrekt, bis zur Abmeldung. Egal ob Bandsteering ein oder aus, nach erneutem Anmelden ist die Grafik ohne Inhalt.

 

[Master SaMMy]

Hier lauft das mit den Online Speicher auch 100tig richtig, wie ich es gestern schon gesagt habe. Dann hast du da wohl ein fehler in deiner Box oder auf den Speicher.





man achte auf das Datum

 

[hilikuss]

So, ich habe jetzt auch die Labor auf der 7490 und dem 1750e. Ich hoffe, das Band steering auf meinem iPad geht jetzt weniger disruptiv von statten.

 

[PeterPawn]

Alter Wein in neuen Schläuchen

Ich habe dieser Labor-Version jetzt (gezwungenermaßen) mal etwas "unter die Haube" geschaut und habe dabei durchaus gemischte Gefühle, wohin das bei AVM wohl gehen soll.

Wie irgendwo schon bemerkt wurde, baut AVM mehr und mehr das GUI erst im Browser zusammen (die "lua"-Dateien sind nur noch "Datenlieferanten" und der Rest wird per Javascript und CSS auf der Client-Seite erledigt) ... ob das immer schlau ist, muß jeder selbst wissen.

Am Ende läuft es jedenfalls (mein Eindruck) darauf hinaus, daß das GUI (zumindest auf älteren Geräten und erst recht mit etwas angestaubten JS-Engines) immer langsamer wird ... irgendwo ja auch logisch, wenn eben ein HTML-Element nicht mehr aus dem HTML-Text einer Antwort gerendert wird, sondern erst per JS ins DOM gehämmert werden muß.

Und hier reden wir nicht mehr von "aktiven" Elementen einer Seite, die sich auch mal auf der Basis des Zustands der Box ändern und wo "dynamisch" einen Sinn ergibt ... nein, hier wird inzwischen (zumindest an einigen Stellen) tatsächlich jeder Furz (aka "div" oder "span") nur noch per JS erzeugt - entsprechend "schnell" ist das halt am Ende und AVM hat (meine Meinung) hier nur noch Glück, wenn die zunehmende Prozessor-Power und die besser werdenden JS-Engines hier den größten Teil des Mehraufwands auffangen und das GUI nicht so richtig "schnarchig" wird.

Für meinen persönlichen Geschmack setzt man beim GUI inzwischen deutlich zu sehr auf die "Optik" im Gegensatz zur Funktion und an die Stelle des "designs" (das dann der "function" zur Seite steht) tritt immer mehr "art" - wobei immer öfter die Informationen nicht mehr in Textform ausgegeben werden, sondern als "Anzeige" irgendwelcher "künstlerischen Elemente".

Aber da, wo das beim Smartphone und beim Tablet noch verständlich ist (schließlich sind diese praktisch 24/7 Begleiter ihrer Besitzer), ist das bei einem GUI für ein Gerät wie die FRITZ!Box (selbst wenn es ein AIO ist) eher brotlose Kunst ... für manchen recht nett anzusehen, aber beim "Informationsgehalt" eher unterirdisch und reines "bloating" eines Interfaces - was wohl auch darüber hinwegtäuschen soll, daß die Einstellmöglichkeiten (sowie es etwas "spezieller" wird) deutlich gegenüber der Konkurrenz abfallen.

Das mag bei einem Teil der Zielgruppe ein Vorteil sein (die kommen aber ohnehin nicht über die "Übersicht" und ggf. noch die "Anrufliste" hinaus), ist aber eher hinderlich, wenn man die FRITZ!Box wenigstens als "semi-professionelles Gerät" positionieren will.

AVM hätte (immer noch in meinen Augen) noch genug andere Baustellen, an denen man sich daran machen könnte, das GUI "anwenderfreundlicher" zu gestalten ... das muß nicht unbedingt in "Spielerei" und "optische Gimmicks" ausarten. Man muß sich nur mal die Einstellmöglichkeiten für ein DECT-Telefon in der Box ansehen und sich daran machen, für ein solches auf jeder der vier "Registerkarten" irgendeine Einstellung ändern zu wollen, was z.B. nach dem Einrichten eines neuen Telefoniegerätes ja nun nicht sooo überraschend wäre.

Von so ziemlich jeder anderen Oberfläche mit solchen "Tabs" kennt man es, daß die Buttons am unteren Rand die Einstellungen "als Ganzes" übernehmen und man ansonsten zwischen den Tabs auch mal umschalten kann. Nicht jedoch beim FRITZ!OS ... wer hier auf einen anderen Tab wechselt, verliert (kommentarlos) die bisher getätigten Einstellungen in der aktuellen Registerkarte und wer sich zwischendrin dann doch zum "OK" breitschlagen läßt, fängt erst mal in der Liste aller Telefoniegeräte erneut an, indem er dort das gewünschte Gerät "bearbeitet" (mit dem "Stift"). Schaut man sich dann noch die Zeiten (in dieser Labor-Version zumindest) an, die für das "Öffnen" der Geräteeinstellungen benötigt werden:

, stelle ich mir schon die Frage, ob AVM nicht eher ein paar Anstrengungen in ein "stateful switching" über die Tabs (an dieser und auch an ein paar anderen Stellen) investieren sollte, als in irgendwelches "Aufhübschen" des GUI. Es kann noch so nett aussehen ... wenn es bescheiden arbeitet, wiegt ein "facelift" das einfach nicht auf.

Von ein paar "anständigen" Erweiterungen der Funktionalität (auch jenseits von "Mesh" und "zentraler Verwaltung") mal ganz zu schweigen ... ich finde es zum Beispiel "zum Heulen" (oder auch zum Haareraufen), daß es AVM zwar (hinter den Kulissen) gelungen ist, mehrere DynDNS-Accounts auch "verwaltbar" zu machen (bisher ging das zwar auch schon, aber ausschließlich über die "ar7.cfg" und inzwischen gibt es wenigstens eine Möglichkeit, in der Firmware auch mehrere Accounts "auszulesen"), es aber immer noch nur einen einzigen "benutzerdefinierten" Account gibt und man bei dem (auch alles in der Firmware vorhanden und nur nicht im GUI umgesetzt) weder einstellen kann, ob der nun IPv4, IPv6 oder beides "kann", noch wann eine (unveränderte) IP-Adresse erneut beim DynDNS-Server angemeldet werden soll (touchtime), weil einige Provider solche Erneuerungen verlangen.

Dann kommt noch hinzu, daß dieses "benutzerdefiniert" offenbar der einzige "Provider" ist, bei dem das DynDNS-Update über TLS gesichert werden kann (ob da "nameserver.de" mit der Angabe der Portnummer 443 eine Ausnahme ist und die Firmware das automatisch als TLS-Port erkennt, weiß ich nicht), indem man eine HTTPS-URL angibt. Mit Ausnahme des erwähnten "nameserver.de" sind alle anderen vorbelegten Provider mit einer HTTP-URL unterwegs.

Wenn man sich mal die Auswirkungen "auf dem Transport" überlegt (denn m.W. bzw. nach meinen Tests funktioniert nicht mal Digest-Authentifizierung, weil der DynDNS-Client das gleich mit "basic auth" sendet und auf ein "Forbidden" etwas verschnupft reagiert, anstatt die Nonce aufzunehmen und "digest auth" zu versuchen) und sich vor Augen hält, daß ein Angreifer nur kurzzeitig die Kontrolle über den DynDNS-Account bräuchte (und vom FRITZ!OS dabei noch assistiert wird, indem bei "falscher Adresse" ein Update (das nirgendwo im GUI protokolliert wird) auf die richtige erfolgt - da braucht der Angreifer sich nicht mal selbst darum zu kümmern), um sich ein passendes LE-Zertifikat erstellen zu lassen für den DynDNS-Namen, dann sollte man eigentlich von einem unverschlüsselten DynDNS-Update schleunigst Abstand nehmen.

Insofern sind die "vorbelegten" Einträge für DynDNS-Provider ziemlich veraltet ... fast alle diese Provider bieten inzwischen auch HTTPS-Updates an. Als Beispiel sei hier mal "dyndns.org" herausgegriffen, das inzwischen Oracle gehört: https://dyn.com/update-client-faqs/ und wo deutlich nachzulesen ist:

Our recommendation:
We recommend you use one of the official Dyn Updater Clients. However, if you use a third party update client it should be configured to send via an HTTPS connection to protect the confidentiality of your data over the Internet. If you need to continue the use of HTTP, we strongly recommend utilizing your update client key instead of your account password.

Hier leistet AVM dem Kunden also eher einen Bärendienst, wenn man ihm "vorkonfektionierte" Einträge für DynDNS-Provider vorsetzt, die lange überholt sind. Und auch wenn die meisten sicherlich in ihrer "ar7.cfg" die Einträge schon stehen haben (und sie damit ohnehin nicht mehr ohne weiteres geändert würden durch neue "defaults"), habe ich extra noch einmal in die "lib/libar7cfg.so" geschaut (dort stehen diese Standardeinträge und man kann z.B. mit "strings" sich wunderbar sein eigenes Bild machen), bevor ich diesen "Vorwurf" erhebe.

Das war zumindest mal wieder ein Beispiel für einen Mangel an Funktion, der gleichzeitig auch ein Mangel an Sicherheit ist - welcher Kunde eines DynDNS-Providers macht sich schon klar, daß die "hochgelobte" FRITZ!Box das Update seiner Adresse dermaßen unsachgemäß angehen könnte, auch noch in der heutigen Zeit, wenn man einen der "fertigen" Einträge dafür verwendet. Man kann das zwar problemlos auch über "benutzerdefiniert" dann per HTTPS machen (sofern man es selbst konfiguriert) ... nur ist da eben (im GUI jedenfalls) auch bei einem Account das Ende der Fahnenstange erreicht und die - durchaus, je nach Provider, unterschiedlichen - Parameter zu den anderen Einstellmöglichkeiten (touchtime, delay, ddnsmode) kann man ohnehin nicht einstellen.

Das war dann meinerseits ein weiteres Beispiel, wo AVM einfach "die Hausaufgaben" nicht macht ... stattdessen verlegt man sich auf irgendwelche "bunten Oberflächen". Ich habe per se auch nichts gegen solche Oberflächen ... nur ist deren Bedienung heutzutage i.d.R. Sache irgendeiner "App" (vom Android-Smartphone über das iOS-Tablet bis zum Windows 10-PC) und wer über ein solches GUI z.B. sein SmartHome steuern will (das wäre dann eine "tägliche Nutzung", die ich mir auch mal vorstellen könnte - schon bei der "Anrufliste" wird die Benutzung dann deutlich dünner), wird das eher selten über einen "vollwertigen Browser" irgendwo machen.

Denn das "Unhandliche" geht schon dort los, wo man sich erst mal am GUI anmelden muß ... für das schnelle Ein- oder Ausschalten einer DECT-Steckdose werden also nur die allerwenigsten Kunden irgendwie auf einen Browser zurückgreifen und da fragt man sich dann schon unwillkürlich, wie "optisch ansprechend" so ein GUI im Browser am Ende tatsächlich sein muß - und das ist auch der Punkt, wo sich (für mich) dann die "Kunst" vom Design unterscheidet und es mir vollkommen ausreicht, wenn ich ein funktionierendes Oberflächendesign habe ... das muß dann gar nicht "künstlerisch wertvoll" sein, solange es genau das macht, wofür ich es benutzen will und solange es das auch noch in einer "logischen" Art und Weise macht (womit ich dann wieder bei der Konfiguration eines DECT-Telefons bin).

Ansonsten hat sich AVM erneut an die Implementierung der Erkennung "verdächtiger Ziele" gemacht:

, die Liste dazu holt man sich (vermeintlich) aus dem Internet:

GET /files/candc_2018-12-19.data HTTP/1.1
Host: sv.cinflst.de
User-Agent: Wget
Connection: close

HTTP/1.1 200 OK
Server: nginx/1.10.3 (Ubuntu)
Date: Wed, 19 Dec 2018 20:20:34 GMT
Content-Type: application/octet-stream
Content-Length: 1231444
Last-Modified: Tue, 18 Dec 2018 19:30:20 GMT
Connection: close
ETag: "5c194acc-12ca54"
Accept-Ranges: bytes

Wofür in diesem Kontext dann der neue öffentliche Schlüssel in der "/etc/candc_public_key" dienen soll ("candc" verwendet AVM für diese listenbasierte Erkennung von "command & control"-Servern), ist noch nicht so richtig klar ... vielleicht will AVM die Liste künftig selbst erstellen und signieren?

Schaut man mal genauer hin, macht das AVM offensichtlich jetzt schon (wenn auch ohne Signieren), auch wenn man dazu irgendwie "unter falscher Flagge" segelt in meinen Augen:

vidar:~ $ dig cinflst.de. any

; <<>> DiG 9.11.2 <<>> cinflst.de. any
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16899
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 2, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 0425a680e5594cf4fd08913e5c1aaeae830c7654a97cd518 (good)
;; QUESTION SECTION:
;cinflst.de.                    IN      ANY

;; ANSWER SECTION:
cinflst.de.             14400   IN      MX      30 avm.all.de.
cinflst.de.             14400   IN      MX      20 mail.avm.de.
cinflst.de.             14400   IN      SOA     ns1.avm.de. admin.avm.de. 2017041700 14400 3600 604800 14400
cinflst.de.             14400   IN      NS      ns2.avm.de.
cinflst.de.             14400   IN      NS      ns1.avm.de.

;; AUTHORITY SECTION:
cinflst.de.             14400   IN      NS      ns1.avm.de.
cinflst.de.             14400   IN      NS      ns2.avm.de.

;; Query time: 17 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Dec 19 21:48:46 CET 2018
;; MSG SIZE  rcvd: 222

vidar:~ $

Die Domain, von der diese Liste geladen wird, liegt also zumindest mal bei AVM ... genaue Angaben zum Owner und Admin sind seit der DSGVO (zurecht) nicht mehr so leicht zu ermitteln.

Warum AVM hier in der Firmware Verbindungen zu den eigenen Servern unter einer "Tarnadresse" aufbaut, muß man vielleicht mal abwarten ... auf alle Fälle führt es natürlich dazu, daß man bei der "Kontrolle", welche Verbindungen so eine startende FRITZ!Box wohl "nach Hause" aufbaut, erst einmal in die Irre geht, sofern man dabei nur auf "avm.de" achtet.

Denn auch dahin habe ich (TLS-)Verbindungen im Mitschnitt der startenden Box ... am Ende stellen diese sich aber wieder nur als das (auch nur sehr unzureichend von AVM dokumentierte) Abfragen des RSS-Feeds heraus, die eben - solange die DECT-Basis aktiv ist und man ein FRITZ!Fon-irgendwas besitzt, auf dem man die anzeigen könnte - bei jedem Neustart der Box erfolgen und AVM damit (zumindest indirekt) auch wieder darüber informieren (das ist sogar so etwas wie ein kleiner "heartbeat" bei der Standardkonfiguration, in der alle 20 Minuten nach neuen Nachrichten gesucht wird, ohne daß der Besitzer davon irgendetwas mitbekommt oder explizit sein Einverständnis gegeben hätte), daß unter der Absender-Adresse eine FRITZ!Box mit aktivierter DECT-Basis und mind. einem FRITZ!Fon ihren Dienst tut, deren Besitzer es versäumt hat, die standardmäßig eingerichteten RSS-Feeds zu deaktivieren.

Das sollte man (so man die nicht wirklich braucht) auch für alle anderen Feeds machen, die da eingetragen sind ... denn schließlich posaunt die FRITZ!Box dabei auch noch fröhlich heraus, wer sie eigentlich ist und so erfährt die abgefragte Website zumindest mal, daß da eine FRITZ!Box zu finden ist und sogar noch, welche System-Version darauf läuft:

GET /rss.xml HTTP/1.0
User-Agent: FeedDaemon FRITZ!OS/07.08 Linux/3.10.107
Host: <undisclosed>
Connection: close

Einfacher kann man es mit einer (nicht aktualisierten) FRITZ!OS-Version den Leuten schon fast nicht mehr machen, sich die passenden Ziele im Internet zu suchen.

Wobei ... ich korrigiere mich, es ginge noch einfacher; mit einer Suchmaschine, in der das Modell und die Firmware-Version jeder FRITZ!Box aufgelistet ist, wäre das möglich - nur, wo kriegt man so eine Datensammlung eigentlich her, wenn man nicht gerade die Domain "myfritz.net" übernehmen kann?

Es ist ja auch wieder nicht so, daß AVM bei den vorkonfigurierten RSS-Feeds jetzt besonders darauf achten würde, daß diese zumindest ausschließlich per TLS kontaktiert werden können und damit die FRITZ!OS-Version und die Tatsache, daß es eine FRITZ!Box ist, nur dem Empfänger bekannt wird) ... nein, da ist u.a. auch noch "spiegel.de" dabei, wo man - sofern man den RSS-Feed per HTTPS haben will - sogar explizit auf die unverschlüsselte Adresse weitergeleitet wird und auch bei "tagesschau.de" erfolgt die Abfrage über eine unverschlüsselte Verbindung.

Das ist gar nicht weiter interessant für die von dort abgefragten Daten (die sind "öffentlich") ... nur die dabei auch unverschlüsselt übermittelte Information, daß es sich um eine FRITZ!Box mit der OS-Version 07.08 handelt, ist hier der Knackpunkt. Das ist auch erst einmal recht uninteressant, solange die Version aktuell ist und es keine bekannte Lücke gibt ... aber gibt es dann doch mal eine und die Box wird nicht direkt aktualisiert, weiß zumindest der Betreiber der Seite mit dem Feed ganz genau, wo er "verwundbare Boxen" finden könnte. Nun kann man ja mal Vermutungen anstellen, wie AVM die Abfragen des Feeds wohl auswerten könnte ... "billiger" kommt man kaum zur Information, wer seine Box noch nicht aktualisiert hat, wenn deren Besitzer die Kommunikation mit dem Hersteller eigentlich unterbunden hat.

Daher finde ich (für mich), daß auch das eigentlich ein "no go" ist ... wenn ich RSS-Feeds mit dem Telefon lesen will (kleiner Tipp: will ich ohnehin nicht auf dem Mini-Bildschirm), dann sage ich das schon an und wenn die Box dann diese Daten abfragt, ist das auch in Ordnung. Ansonsten hat sie die Füße stillzuhalten und nur da Daten abzurufen und ihrerseits Spuren zu hinterlassen, wo ich als Besitzer das möchte und wo ich auch damit rechnen würde. Es kann ja wohl nicht sein, daß ich der Box die Kommunikation mit dem Hersteller komplett verbiete und dann kriegt der es "hintenrum" trotzdem wieder auf dem Silbertablett präsentiert, daß ich (a) eine FRITZ!Box und (b) ein FRITZ!Fon benutze.

Die "Hilfeversion" für die neue Labor-Reihe ist dann - nur nebenbei bemerkt - die "018" (wer also die Unterschiede in den Hilfeseiten finden will, muß von der 07.0x zur 07.08 hin die "017p2" durch "018" in der URL ersetzen).

Was AVM auch nicht hinbekommt (ich schreibe mal "immer noch nicht"), ist die Abfrage der "challenge" unmittelbar vor der Verschlüsselung der Zugangsdaten. Hat man aus irgendeinem Grund in einem Browser-Tab das GUI der FRITZ!Box eine Weile offen und wird "zwangsabgemeldet", steht da ja wieder der Login-Dialog. Ist aber auch der nicht mehr so ganz taufrisch, ist die darin verwendete "challenge" bereits wieder abgelaufen und der Anmeldeversuch aus diesem Fenster wird (absehbar) scheitern und dabei gleich noch alle anderen Tabs, in denen ggf. eine weitere Session aktiv ist zu derselben Box, mit in den Abgrund reißen.

Das ist - neben der vergeblichen Kennwort-Eingabe - das zweite Problem mit dieser dämlichen Login-Seite ... dabei wäre es ein Leichtes, wenn AVM eben vor dem Verschlüsseln von Benutzername und Kennwort ("verschlüsseln" ist etwas zu viel, es ist ja nur ein MD5-Hash über drei verkettete Werte) erst noch einmal überprüft (meinetwegen auch mit einem lokalen Timer), ob die Challenge noch aktuell ist oder wenn man sich gleich prophylaktisch eine neue Challenge holt, bevor man mit dem Hashen beginnt.

DAS nenne ich dann eine Verbesserung im GUI und eine leichter bedienbare FRITZ!Box ... auf die ganzen anderen Spielereien kann ich dann locker verzichten, weil ich mir auch unter "20 von 2.000 MB verbraucht" in Zahlen etwas vorstellen kann und dazu keinen Balken brauche, der mir 1% "visualisiert" - um mal irgendein Beispiel zu nennen, wo eine solche Darstellung (immer nach meinem Dafürhalten) so gar keinen Sinn macht (schon weil man das eine Prozent vermutlich kaum sehen würde).

 

[DickS]

Kann vielleicht damit zusammenhängen, dass AVM denkt immer mehr werden Remote auf die Box zugreifen statt lokal? Dass das UI sich wie ein "Webserver" verhalten sollte?

Denke mal 99,9% der User sehen die UI 1x beim Einrichten, danach nie wieder - sicher auch ein Problem der "Versions-Fragmentierung" wenn die Box sich nicht selbst aktualisiert.

Das möchte AVM vielleicht ändern, und daher ist eine "sehr einfache" Bedienoberfläche notwendig - dann nutzen die User vielleicht auch andere Funktionen oder kaufen die anderen AVM-Produkte (als nächstes kommt dann Push-Werbung für AVM-Zubehör ;-) ).

 

[eisbaerin]

gemischte Gefühle, wohin das bei AVM wohl gehen soll.

Dem kann ich nur zustimmen, denn die "gemischten Gefühle" habe ich schon sehr lange.

Wie irgendwo schon bemerkt wurde

Vielleicht meinst du mich hier:
https://www.ip-phone-forum.de/threads/sammelthema-für-fb-7590-mit-labor-firmware-intern.294029/page-85#post-2309134

 

[avm_7170]

Meine Erfahrung nach funktionieren die Updates mit Firefox nicht, aber es gehen Chrome und IE ....