[Info] FRITZ!Box 6490 Firmware FRITZ!OS 06.84 vom 07.09.2017
- Ersteller kekskruemel
- Erstellt am
jebeyer
Neuer User
- Mitglied seit
- 29 Apr 2007
- Beiträge
- 145
- Punkte für Reaktionen
- 22
- Punkte
- 18
Habe ich schon an AVM gemeldet. Bei der Update Frequenz für deren Kabelboxen, würde ich allerdings nicht mehr davon ausgehen das dieses Jahr noch was passiert...
jebeyer
Neuer User
- Mitglied seit
- 29 Apr 2007
- Beiträge
- 145
- Punkte für Reaktionen
- 22
- Punkte
- 18
Wenn ich mir die Antworten von AVM auf Twitter und FB diesbezüglich so ansehe (reicht von "irgendwann" bis "wird noch eine ganze Weile dauern..."), würde ich tendenziell eher 1. Halbjahr 2018 damit rechnen (für 6490/6590)
Zuletzt bearbeitet:
Kann ich nicht nachvollziehen. Bei mir liefen erst die 6490 und jetzt die 6590 völlig zuverlässig durch. Routing (IPv4 only), Telefonie, VPN - geht.
Dass der DECT-Monitor nicht geht, ist blöd - aber viel harmloser als irgendwelche Fehler, die mich bei der täglichen Arbeit stören. Und davon habe ich keine.
Kann ich ebenfalls nicht nachvollziehen. Bei mir gehen VPN-Verbindungen nach 60 Minuten zu, mutmaßlich Idle. Vielleicht liegt dessen Problem überhaupt nicht an der Fritz!Box. Die Fehlermeldung "Dead peer detection" könnte darauf hinweisen...
Die MAC in den Netzwerkverbindungen fehlt immer noch, die IP Sortierung im WLAN sortiert immer noch nicht richtig.
Dazu der Dect Bug....
Immerhin, der Paketmitschnitt läuft wieder.
Das tröstet etwas.
"erweiterte Smarthome-Funktionen", da muß ich wohl was übersehen haben.
Dazu der Dect Bug....
Immerhin, der Paketmitschnitt läuft wieder.
Das tröstet etwas.
"erweiterte Smarthome-Funktionen", da muß ich wohl was übersehen haben.
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,300
- Punkte für Reaktionen
- 1,760
- Punkte
- 113
Was meinst Du damit genau? Bei mir werden die MAC-Adressen "ganz normal" angezeigt, wenn man die Spalte der Anzeige hinzufügt.
Solltest Du damit das Fehlen dieser Spalte in der "initialen Anzeige" meinen, das dürfte seitens AVM beabsichtigt sein. Wie man es durch einfachste Änderungen am Lua-Code (bzw. hier ist es JS) beheben kann, findest Du z.B. in diesem Patch: https://github.com/PeterPawn/modfs/blob/master/modscripts/mod_default_show_mac#L31
Es gibt also die Möglichkeit, diesen "Fehler" selbst zu korrigieren ... auf AVM würde ich an dieser Stelle nicht warten, m.E. sieht man das dort kaum als Fehler oder Problem und persistente GUI-Einstellungen gibt es (abseits Standard vs. Erweitert) bisher nicht bei AVM (sonst könnte man auch unterschiedliche Interface-Sprachen und/oder GUI-Einstellungen/-Einschränkungen pro Benutzer realisieren).
...und könnte browserabhängig sein. Ich habe mir das mal vorgeknöpft, und der Übeltäter ist ein JavaScript in dect_moni.lua, welches an 4 Stellen eine Methode namens "jsl.remInPx()" aufzurufen versucht - die Firefox offenbar nicht kennt und daher die Ausführung abbricht. Deshalb wird die Seite nicht vollständig generiert.
Ersetzt man die Methodenaufrufe z.B. durch eine 4 (dieser Wert wurde in der 6.83 in diesem Script verwendet), dann funktioniert die Seite auch wieder im Firefox, und sieht besser aus als vorher - nur die Pfeile (die mit der Methode berechnet werden) sitzen nicht ganz richtig.
Ich vermochte im Web nichts zu einer JavaScript-Methode namens "jsl.remInPx()" zu finden. Ist das vielleicht eine proprietäre Erweiterung von Microsoft oder Apple...? Dann hat AVM wohl mit den "falschen" Browsern getestet...
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,300
- Punkte für Reaktionen
- 1,760
- Punkte
- 113
Code:
lib.remInPx=function(rem)
{
if (!rem || "number" !== typeof rem)
{
rem=1;
}
if (lRemInPxBox || createRemInPxBox())
{
return lRemInPxBox.offsetWidth * rem;
}
return 16 * rem;
};
lib.pxInRem=function(px)
{
if (!px || "number" !== typeof px)
{
return 0;
}
if (!lRemInPxBox)
{
createRemInPxBox();
}
return px / lRemInPxBox.offsetWidth;
};"jsl" dürfte irgendetwas in der Richtung "javascript library" darstellen und ist lediglich die Variable, der die Objekt-Struktur (in der Definition oben das "lib") zugewiesen wurde.
Das ist also nicht wirklich browserabhängig, sondern "reiner AVM-Code" und ziemlich eindeutig ein Fehler in der Versionierung bei AVM. Das Fehlen dieser Funktion zeigt jeder JS-Debugger in einem moderneren Browser an, wenn man denn irgendwie an einer Stelle vorbeikommt, an der diese Funktion aufgerufen werden soll.
Wenn irgendwelche Seiten diese Funktion benutzen wollen, sollte sie auch in der "avmcore.js" enthalten sein - eine der beiden Dateien (entweder die "dect_moni.lua" oder die "avmcore.js") liegt jedenfalls in der falschen Version vor in dieser Firmware und da wäre es schon komisch, wenn irgendetwas getestet wurde, nachdem diese beiden Komponenten zusammengekippt (aka "integriert") wurden.
So ganz unbeteiligt an diesem Kuddelmuddel dürfte auch die Planung und Koordination nicht sein ... man kann das sehr schön anhand des Unterschieds zwischen "www" und "www.nas" sehen, daß da offenbar vorhandener Code aus dem "www.nas"-Teil (da gibt es nämlich diese Library-Funktionen noch einmal, nur halt in einzelnen Dateien, wie das früher auch im "www"-Teil der Fall war - man vergleiche einfach mal die 06.63 mit der 06.83, besonders das Verzeichnis "/usr/www/avm/js" - der Umzug von ARM auf ATOM hat da nicht so viel Einfluß gehabt) nun nach und nach auch im "www"-Teil genutzt wird und dort wird das aber inzwischen alles in ein größeres JS-File gekippt (eben in diese "avmcore.js"). Auch in der "login.lua" in "www" findet man noch (auskommentiert) die entsprechenden "script"-Statements im HTML-Code, mit denen zuvor die einzelnen Dateien geladen wurden:
HTML:
<script src="/js/avmcore.js?lang=<?lua box.html(config.language) ?>"></script>
<!--<script src="/js/browser.js"></script>-->
<!--<script src="/js/jsl.js"></script>-->
<!--<script src="/js/md5.js"></script>-->
<!--<script src="/js/html.js"></script>-->
<!--<script src="/js/func.js"></script>-->
<!--<script type="text/javascript" src="/myfritz/js/focuschanger.js?lang=<?lua box.js(config.language) ?>"></script>-->
<!--<script src="/js/html2.js?lang=<?lua box.html(config.language) ?>"></script>-->
<!--<script src="/js/http.js"></script>-->
<script type="text/javascript" src="/js/login.js"></script>
<script type="text/javascript">Bei allem Verständnis für Deine Bemühungen, AVM hier auch in Schutz nehmen zu wollen ... ich bleibe dabei: Das kann keiner vernünftig getestet haben (der Browser spielt auch nur eine untergeordnete Rolle hier) und beim Auseinanderhalten verschiedener Stände macht AVM da auch keine so richtig gute Figur.
Die "remInPx()" hielt erst mit der Labor-Reihe 06.88 Einzug in den "www"-Zweig (wo nun mal die "dect_moni.lua" liegt), in der 06.86 für die 7590 (m.W. die letzte Release-Version mit der höchsten Nummer VOR der Labor-Reihe) ist sie noch nicht vorhanden - zumindest nicht im "www"-Zweig, sondern nur im "www.myfritz"- und "www.nas"-Zweig und da noch in der Datei "screen.js" ... daher rührt auch meine oben geäußerte Feststellung, daß AVM da Code aus dem NAS- und dem MyFRITZ!-Teil nachnutzt im "www"-Part - die waren ja auch zuvor schon graphisch anspruchsvoller als der "www"-Teil (also das "normale" GUI), auch wenn das jetzt mit der Mesh-Netzwerkübersicht bei den graphischen Spielereien deutlich zugelegt hat.
Zuletzt bearbeitet:
Ich versuche die Logik im Menü zu verstehen und das fällt mir zunehmend schwerer. Beispiel:
Ich sortiere die IP Geräte gerne nach Adresse aufsteigend, funktioniert auch (nach Aufruf im Untermenü) in den Netzwerkverbindungen.
Mach das mal unter WLAN...
Und warum wird diese Option nicht als Vorlage verwendet?
Die alphabetische Ordnung hat mir noch nie viel gebracht, (ich habe max 34 Geräte an der Box laufen).da ich die IP aufsteigend in Gruppen vergebe.
Aber das ist vielleicht Ansichtssache.
Warum wurde die MAC aus dem Grundmenü herausgenommen, Platz ist genug in der Zeile und früher war sie auch drin.
Und auch hier Gegenbeispiel, im WLAN wird sie standardmäßig angezeigt. Logik ??
Ich brauch die Mac u.a. deshalb so häufig, weil seit der neuen (bl/ws) Oberfläche einige Sachen "verschlampt" wurden.
Bei mir tauchen Geräte neuerdings gerne 2 x in der Liste auf, zur Klärung hilft dann nur die MAC, also warum ist sie hier raus und da drin?
Im Moment muß ich erstmal rauskriegen, warum mein Synology seit dem FB update nicht mehr in den Ruhezustand geht. Bei der alten FW war es der Medienserver, aber der ist wie vorher deaktiviert.
Um "in Schutz nehmen" geht es mir weniger als darum, erst mal zu verstehen, was da überhaupt falsch gelaufen ist. Als Softwareentwickler habe ich eben einen anderen Blick auf die Problematik "Variantenmanagement".
Wie bekommt man die Softwareentwicklung für zig Modelle in den Griff? Jedes Modell in einem eigenen Repository/Branch pflegen erleichtert zwar die Konsistenz, führt aber schnell dazu, dass die Branches auseinanderlaufen und für alle Modelle notwendige Sicherheitsupdates zigmal eingepflegt werden müssen. Oder man nutzt gemeinsame Repositories, hat dann aber wie hier das Problem, dass jede Änderung an gemeinsam genutzten Code zigfachen Testaufwand auslöst. Die ökonomischste Lösung wäre, gemeinsam genutzten Code einfach nicht mehr anzufassen, aber das wäre ja auch blöd.
Und der von mir schon mal genannte Lösungsansatz - automatisierte Tests - ist nun ausgerechnet bei UI-Themen besonders schwierig, insbesondere wenn wie hier die Änderung die UI gerade deutlich verändert hat...
Und manuelle Tests sind eben zeitaufwändig und kostenintensiv. Kann sich ja jeder mal selbst überlegen, ob er gerne einen Niedriglohnjob hätte, bei dem er ggf. mehrmals täglich nichts anderes tut als auf zig Routermodelle einen aktuellen Build einzuspielen und sämtliche(!) UIs durchzuklicken und gründlich auf korrekte Funktion zu testen.
Nur fordern "Das muss ordentlich getestet sein, bevor es auf die Kunden losgelassen wird!" ist einfach. Aber hat jemand einen konkreten Vorschlag, wie man das so hinbekommen kann, dass die Boxen nicht ein vielfaches kosten müssten, um den Aufwand zu bezahlen...?
Also bei mir wird die eine IP-Adresse aus dem DHCP-Pool getrennt von den anderen manuell vergebenen, die nicht im DHCP-Pool liegen, sortiert. Würde das auch bei Dir zutreffen?
Mußte den Satz mehrfach lesen, sorry.
Ich habe einen kleinen Pool oberhalb 200, wenn mal ein Gast kommt, alles andere ist fest vergeben.
Und bei der Anzahl ist eine aufsteigende Anzeige, zumal durch die Gruppenvergabe
(Beispiel Fritzboxen, Reps. Switche ab 1-10,
NVRs, Cams, 11-20,
NAS 21-30, ..
Fernseher 71 - 7x) sehr übersichtlich.
Besser als nach Gerätenamen. Die Gerätezuordnung per IP hab ich im Kopf.
Sortiere mal im WLAN nach IP Adresse, geht garantiert nicht bei 1 los.
Ich habe einen kleinen Pool oberhalb 200, wenn mal ein Gast kommt, alles andere ist fest vergeben.
Und bei der Anzahl ist eine aufsteigende Anzeige, zumal durch die Gruppenvergabe
(Beispiel Fritzboxen, Reps. Switche ab 1-10,
NVRs, Cams, 11-20,
NAS 21-30, ..
Fernseher 71 - 7x) sehr übersichtlich.
Besser als nach Gerätenamen. Die Gerätezuordnung per IP hab ich im Kopf.
Sortiere mal im WLAN nach IP Adresse, geht garantiert nicht bei 1 los.
Geht halt mit der *.*.*.101 los (das eine Gerät mit der Adresse aus dem DHCP-Pool), aber der Rest (mit der letzten Stelle im Bereich 10-99) ist korrekt aufsteigend sortiert. Wenn ich die Reihenfolge umkehre, steht wieder nur die 101 am falschen Ende, aber der Rest stimmt.
Würde ich dem einen Gerät auch noch eine feste IP-Adresse zuweisen, die nicht im DHCP-Pool liegt, wäre vielleicht sogar alles fehlerfrei sortiert...
Aber warum unter Netzwerkverbindungen so und bei WLAN anders?
Bei WLAN gehts bei mir sortiert mit 10,11,.. los dann mit 24x weiter, danach dann 3,4,5, dann 80 aufwärts.
Und alle, bis auf 2 aus dem Pool ab 241.. fest vergeben.
Ich wills ja nur verstehen.
Bei WLAN gehts bei mir sortiert mit 10,11,.. los dann mit 24x weiter, danach dann 3,4,5, dann 80 aufwärts.
Und alle, bis auf 2 aus dem Pool ab 241.. fest vergeben.
Ich wills ja nur verstehen.
Achso, das ist schnell erklärt: Ein einfacher Stringvergleich kennt nur Ziffern, keine Zahlen, und Leerzeichen und Interpunktionen sind in ASCII "kleiner" als Ziffern, deshalb ergibt eine Sortierung von Strings, die Zahlen enthalten, z.B. die Reihenfolge:
1
10
11
111
19
2
20
200
22
3
4
5
6
7
8
9
Wenn man das für den Menschen intuitiver sortieren will, muss man einen aufwändigeren Vergleich anwenden, der Zahlen in den Strings erkennt. Das wird unter Heimnetzübersicht -> Netzwerkverbindungen getan, wogegen Deiner Beschreibung nach unter WLAN->Funknetz ein einfacher Stringvergleich verwendet wird.
Wenn Du nicht darauf warten willst, dass AVM das mal angleicht, kannst Du das umgehen, indem Du nur 2- oder 3-stellige IP-Stellen verwendest, also entweder nur *.*.*.10-99 oder *.*.*.100-255. Das wird auch bei einem einfachen Stringvergleich numerisch richtig sortiert.
Danke für die Erklärung,ich habs nun gelegentlich gerne mal aufgeräumt, vor allem aber übersichtlich.
Aber deshalb die Standard IP der Fritzboxen zu ändern artet in Arbeit aus, bleibt ja dann bei den Geräten nicht nur bei der IP.
Andererseits, wenn Herr Fritz den aufwendigen Code in der Übersicht schon verwendet, warum dann nicht auch gleich im WLAN.
Wobei wir wieder bei der Logik sind. Warum rausgenommen, was schon mal drin war.
Aber lassen wir es gut sein, für meine Restlaufzeit werd ich mich dran gewöhnen.
Aber deshalb die Standard IP der Fritzboxen zu ändern artet in Arbeit aus, bleibt ja dann bei den Geräten nicht nur bei der IP.
Andererseits, wenn Herr Fritz den aufwendigen Code in der Übersicht schon verwendet, warum dann nicht auch gleich im WLAN.
Wobei wir wieder bei der Logik sind. Warum rausgenommen, was schon mal drin war.
Aber lassen wir es gut sein, für meine Restlaufzeit werd ich mich dran gewöhnen.
Zuletzt bearbeitet:
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,300
- Punkte für Reaktionen
- 1,760
- Punkte
- 113
@rstle:
Mich mußt Du nicht fragen, warum AVM welche Entscheidung trifft. Ich habe lediglich den Ist-Zustand beschrieben und Dir zeigen wollen, daß eine simple Änderung in einer "js"-Datei in der Firmware die MAC-Adresse wieder standardmäßig als Spalte ans Licht holt. AVM konzipiert die Firmware ja für verschiedene Umgebungen und bei wenigen Geräten im LAN (und für viele FRITZ!Box-Besitzer) ist die MAC-Adresse sicherlich eine eher unnütze Information in dieser Liste. Ähnliches gilt für eine eingestellte Sortierung ... auch die ließe sich verändern. Solange es die erwähnte Speicherung von GUI-Einstellungen nicht gibt, sehe ich keine andere Möglichkeit. Als Fehler der Firmware kann man es m.E. trotzdem nicht bezeichnen, daß die MAC-Adresse in der Seite nicht automatisch enthalten ist.
@robert_s:
Ich wollte meinerseits auch lediglich zeigen, daß Deine Annahme einer "spezielleren" Umgebung - damit dieser Bug überhaupt auffällt - falsch war. Gerade als Software-Entwickler (und ich bin auch ein solcher, zumindest habe ich auch das lange genug beruflich gemacht) kann ich auch "bei mir geht alles Wesentliche" nicht so richtig nachvollziehen als Standpunkt eines anderen aus demselben Metier. Wenn nur noch "wichtige Funktionen" tatsächlich fehlerfrei ausgeliefert und Fehler an anderen Stellen als "aber viel harmloser als ..." abgetan werden, dann offenbart das (a) einen Blick auf Fehler und Firmware ausschließlich aus der eigenen Perspektive (es beinhaltet auch eine gewisse Arroganz, weil automatisch davon ausgegangen wird, daß für alle anderen auch nur die von einem selbst genutzten Funktionen ausreichend Bedeutung hätten) und (b) eben doch - wenn auch implizit - die Feststellung, daß es "weniger wichtige Fehler" gibt, die man auch ruhig mal mit ausliefern kann, weil sie nicht alle Kunden betreffen und damit eben keine "show stopper" sind - die paar Kunden, die damit dann Probleme haben, sind genauso "weniger wichtig" (als man selbst). Wenn das bei "wandernden Problemen" passiert und jeder Fehler andere Kunden verprellt, ist auch dieses Herangehen durchaus dazu geeignet, eine größere (und am Ende stetig wachsende) Anzahl von Kunden zu verärgern und den eigenen Ruf zu ruinieren.
Das mit der Arroganz mögest Du bitte auch nicht persönlich nehmen ... da geht es weniger (bzw. gar nicht) um Deine Person als vielmehr um den von Dir vertretenen Standpunkt, der häufiger anzutreffen ist. Beim DECT-Monitor mag den noch so mancher nachvollziehen können und teilen wollen, beim Fehler aus der vorhergehenden Version (dem nicht aufzurufenden Paketmitschnitt) ist das schon deutlich schwieriger. Wie will jemand anderes einschätzen können, welche Priorität für meine Arbeit mit einer 6490 dieser Paketmitschnitt hat und ob nicht gerade dieser am Ende das Alleinstellungsmerkmal war, welches die 6490 von anderen Geräten unterscheidet und mich zum Kauf/Einsatz genau dieses Routers veranlaßte?
Da ist dann so ein Fehler alles andere als "harmlos", zumal bis zu seiner Beseitigung (absehbar) so viel Zeit vergehen wird, daß die oft bei AVM so hochgelobte Dauer, für die auch ältere Boxen mit Updates versorgt werden, sich spätestens dann auch relativiert, wenn man die Zeit zwischen zwei Versionen ins Verhältnis zu dieser Dauer setzt. Sechs Updates in vier Jahren (mal 9 Monate unterstellt, je nach Modell geht es mal schneller und mal dauert es deutlich länger) sind jetzt auch wieder nicht soo viel, daß man direkt in Euphorie ausbrechen müßte.
Läßt man die 06.83 in der "Zählung" mal aus (die wurde ja mehr oder weniger "inoffiziell" zurückgezogen, über die dafür (mutmaßlich) verantwortlichen Probleme haben wir hier auch noch nicht "geredet"), dann sind wir bei etwas mehr als zehn Monaten zwischen der 06.63 (28.10.2016) und dieser Version hier ... und da ist der Aspekt der extrem langsamen Behebung von Sicherheitsproblemen, der sich aus solch langen Zeiträumen zwischen Updates ergibt, noch gar nicht ausreichend gewürdigt. Solange das nicht problemlos auch von außen auszunutzen ist, sieht AVM bekanntermaßen ein Sicherheitsproblem eher als weniger wichtig an, im Vergleich zu neuen Funktionen - und selbst die Möglichkeit eines externen Angriffs (mit geringeren Auswirkungen als von innen) führt nicht automatisch zu höherer Priorität, wie wir auch inzwischen wissen.
Wobei der Fehler beim Paketmitschnitt (und ich meine hier den in der 06.83 und nicht die falsche Handhabung der Interface-Namen in irgendeiner Version davor, wo sich dann der Mitschnitt zwar starten, aber nicht sauber beenden ließ) schon beim Versuch, jeden Link wenigstens einmal mit dem korrekten Ergebnis aufzurufen, zu finden sein sollte und das ließe sich durchaus automatisieren - die Lua-Seiten und ihr Inhalt sowie die erwarteten Ergebnisse sind bekannt und die möglichen POST-Request an die "data.lua" ebenfalls, mit denen dann diese Seiten im Endergebnis aufgerufen werden, genauso die "richtigen" HTML-/JSON-Ausgaben bei definierten Ausgangswerten - die sollten bereits aus "unit tests" für die kleineren Einheiten vorliegen.
Das dann noch einmal nach der Integration durchzuführen, kann eigentlich nicht soo schwer sein. Jeder Kunde, der seinerseits irgendwelche Aufgaben über das GUI automatisieren möchte (es gibt auch hier genug Anfragen in dieser Richtung), macht das am Ende genauso ... er sieht sich die gesendeten Requests an und sucht sich aus den - auf diese Requests erhaltenen - Antworten den Teil der Daten heraus, der ihn interessiert. Es gibt ja sogar die Möglichkeit, mit "dbg=1" in einer URL sich noch eine Liste der aus der Firmware gelesenen Einstellungen und diverser interner "tables" aus dem Lua-Code der Seite ausgeben zu lassen (wurde auch ins GUI integriert, findet man im User-Menü, wenn die Option beim Aufruf angegeben war) - da könnte man bei einer Automatisierung von Tests (das ist JSON, was da kommt bei "dbg=1") auch drauf zugreifen.
Das mit ein "Einpflegen von Sicherheitsupdates" finde ich schon wieder putzig ... wenn das tatsächlich anhand der Version geschehen sollte, in der so ein Problem auch auftrat und dieser Punkt liegt vor irgendwelchen "feature branches", dann sollte es (ich unterstelle mal, daß AVM auch "git" einsetzt, alles andere würde mich sehr wundern) kein wirkliches Problem darstellen, solche Branches auf Basis des nunmehr geänderten Ausgangspunkts (also der Stelle mit dem gefixten Problem) neu aufzusetzen (rebase).
Lasse ich solche Sicherheitsupdates aber eher liegen und ändere das alles ohnehin erst nach dem Fertigstellen neuer Features (so stellt es sich bei AVM ja dar - das kann jeder selbst verfolgen, wann in den Labor-Zweigen bisher auch solche Probleme behoben wurden, die lange vor dem (öffentlichen) Start der Labor-Reihe bereits gemeldet waren), ändert das für meine verschiedenen "Varianten" (aka Modelle) am Aufwand nichts.
Wenn ich das als Firma dann aber nicht mehr wirklich gebacken kriege, mehrere/viele Modelle auf einmal zu managen, dann muß ich entweder meine Strategie anpassen an das erweiterte Portfolio, mehr Manpower rankarren (damit das ohne Änderungen der Abläufe gestemmt werden kann) oder auf die Verbreiterung meines Portfolios einfach verzichten. Dem Käufer einer 7490 kann ich wohl kaum plausibel machen, daß ich nicht mehr in der Lage bin, seinem Modell die notwendige Aufmerksamkeit zu widmen (und die notwendigen Ressourcen zuzuteilen), nur weil es auch noch eine 3490 oder eine 7430 als billigere Varianten für eine leicht abweichende Zielgruppe gibt und ich mich eigentlich schon übernommen habe.
Und Deiner Feststellung
Und auch wenn es wie "Korinthenkackerei" aussieht ... in gewisser Weise regt mich auch die "Sprachregelung" bei AVM auf. Es gibt eben keine "Fehlerkorrekturen" nach eigener Ansicht ... es geht immer nur um "Weitere Verbesserungen" und wenn man die o.a. Liste als Kunde so ansieht, dann würde man (meine Meinung) vielleicht zwei Punkten (Modem-Treiber und zusätzliche 2FA) diese Klassifizierung zugestehen ... alles andere ist nichts weiter als das Beheben zuvor verbockter Probleme. Das wirkt auf mich dann immer ein wenig wie das "fishing for compliments" nach dem Motto: "Schau her, lieber Kunde, wir verbessern unsere Produkte ständig in Deinem Interesse." und dabei handelt es sich hier (nimmt man die Punkte und nicht die dahinter ggf. verborgene Arbeit) zu 2/3 um das Beheben eigener Fehler. Was mich hier auch mehr als erstaunt, ist die Tatsache, daß von einer Behebung des Problems an DS-Lite-Anschlüssen, wie es für UM bei der 06.83 mehrfach berichtet wurde (hatten wir auch hier irgendwo in einem Thread), eigentlich nichts zu lesen ist. Funktioniert das jetzt auch und war quasi "Nebenprodukt" einer der aufgeführten Änderungen, so daß es gar keiner eigenen Erwähnung bedarf? Oder gab es das Problem gar nicht? Welcher der o.a. - nunmehr behobenen - Punkte wird denn derjenige gewesen sein, der zum "Zurückziehen" der 06.83 führte? (Auch wenn es das offiziell nie gab, ist die geänderte Antwort auf Versionsabfragen am Ende ja nichts anderes.) Es wird eher nicht die Verwendung mit einem einzelnen US-Kanal gewesen sein, zumal das auch - nach Beschreibung - nur sporadisch zu Problemen führte.
Wie gesagt ... ich will auch nicht den Blick für die Realität verlieren und kenne durchaus auch die Probleme, vor denen AVM (mutmaßlich) steht. Aber das kann einfach keine Entschuldigung dafür sein, daß der Kunde in zunehmendem Umfang mit Firmware-Versionen konfrontiert wird, denen man das "mit der heißen Nadel gestrickt" sofort ansehen kann. Da braucht es auch gar keinen Billig-Löhner, der sich den ganzen Tag nur durch irgendwelche GUIs klickt, wie Du Deinerseits (etwas polemisch) festgestellt hast ... wir reden hier nämlich nicht über "tägliche Tests" und irgendwelche (internen oder öffentlichen) Labor-Versionen. Für diese könnte man das sicherlich akzeptieren (und darf sich trotzdem auch dort darüber aufregen), wenn bei der Integration mal etwas nicht auf Anhieb funktioniert. Aber hier geht es deutlich um eine Release-Version und da darf man als Kunde tatsächlich vor der Bereitstellung des Updates erwarten, daß noch mindestens ein Test ausgeführt wird.
Ob manuell oder automatisch, ist mir als Kunde sowas von egal ... entscheidend ist, daß derart offensichtliche Fehler gefunden werden und - noch einmal - es gab bisher praktisch keine wirklich fehlerfreie Firmware für die 6490 (und jetzt bitte nicht wieder den alten Spruch, daß es eine solche gar nicht geben kann ... es geht hier entweder tatsächlich um Basisfunktionen (DS-Lite) oder um Fehler, die AVM-Kunden dann innerhalb von Stunden nach der Freigabe der Firmware gefunden haben und nicht um versteckte Probleme in irgendwelchen unvorhersehbaren, absonderlichen Konstellationen) und da reden wir auch nicht nur von irgendwelchen GUI-Fehlern, sondern wirklich von "bread'n'butter"-Funktionen.
Wenn Du selbst von dem DS-Lite-Problem am UM-Anschluß betroffen gewesen wärst, wäre vermutlich auch Deine Einschätzung zur Bedeutung dieses Problem deutlich anders ausgefallen - auch hier kannst Du gerne Deine eigene Person (die aber die oben nachzulesenden Aussagen aufgestellt hat, daher beziehe ich mich nun auch darauf) durch abstraktere Charaktere ersetzen. Gerade bei den DOCSIS-Modellen ohne öffentlichen Beta-Test muß ich mir doch auch als Hersteller einfach mehr Mühe geben, wenn ich selbst weiß, daß die ansonsten aus dem Kundenkreis kommenden Rückmeldungen hier einfach fehlen.
Die paar Tester bei den KNB können doch die Labor-Benutzer bei den DSL-Varianten nicht ersetzen ... daß man dort (sollte es tatsächlich eine Vorläufer-Beta für die KNB gegeben haben, die dann 1:1 zur Release-Version wurde) das Problem mit dem DECT-Monitor oder auch dem Paketmitschnitt nicht findet (man testet ja die Funktion im eigenen Netz und nicht das AVM-GUI) oder es - selbst wenn man es findet - gar nicht erst meldet, kann ich sehr gut nachvollziehen. Denen ist da kein Vorwurf zu machen ... solange AVM sie nicht für solche Tests bezahlt, haben sie halt die Möglichkeit, die reibungslose Funktion der Firmware in ihrem Netz zu begutachten und notfalls Änderungsbedarf anzumelden. Das bezieht sich aber auf ihr eigenes Netz und damit die eCM- und eRouter-Funktionen der Retail-Version (mehr enthält die ja auch nicht, was unter DOCSIS fallen würde) - was interessiert es denn einen KNB, ob meinetwegen die DynDNS-Dienste oder die MyFRITZ!-Anmeldung oder -Freigaben funktionieren? Gar nicht ... ganz einfach. Das ist vielleicht noch bei der Provider-Firmware ein Problem - ansonsten kann ein Kunde mit einer Retail-Box den KNB aber mal "gerne haben".
Mit diesem Wissen im Hinterkopf muß ich dann eben als Hersteller mehr in das Modell investieren ... und erst recht dann, wenn ich meinerseits den Kunden empfehle, sie sollten mir doch (quasi blind) vertrauen und mir selbst das Aktualisieren der Firmware ihrer Geräte überlassen (die empfohlene Auto-Update-Einstellung von AVM - schau in die Online-Hilfe). Dann stehe ich automatisch noch mehr in der Verantwortung, meinerseits alles Menschenmögliche zu tun, damit ich mich dieses Vertrauens auch würdig erweise ... da sind solche Fehler dann nicht nur ärgerlich für den Kunden, sie schaden auch dem Renommee des Herstellers insgesamt.
Es ist zwar nicht der Super-GAU, aber es ist ein schlechtes Zeugnis für die QS bei AVM ... und etwas in dieser Richtung sollte es (hoffentlich) auch dort geben. Bei den DOCSIS-Boxen kommt noch erschwerend hinzu, daß es keinen (offiziellen) Weg zurück zur Vorgängerversion gibt ... m.W. rückt AVM auch keine Recoveries an Kunden heraus, die nach einem Update tatsächlich mit Problemen zu kämpfen haben (und zwar auch solchen, die den Anschluß unbenutzbar machen) und tauscht auch dort lieber die Box aus (nach dem zusätzlichen Aufwand für den Kunden kräht da auch kein Hahn mehr).
Der Super-GAU wäre es, wenn nach einem automatischen Update die Einstellungen des Kunden verloren gehen und er - in vielen Haushalten sicherlich auch noch der Fall - keine aktuellen Sicherungen hat oder gar nicht weiß, wie er diese einspielen soll, weil die Installation von einem "Fachmann" vorgenommen wurde - da ist dann ggf. selbst die Sicherung per E-Mail wenig hilfreich, weil man die ohne funktionierende Box auch nicht wieder abrufen und importieren kann, denn das geht nur selten mit einem Tablet oder Smartphone, was seinerseits mit Mobilfunk noch ins Internet käme ... viele können die lokale Speicherung von Downloads, die für die Benutzung des Upload-Formulars notwendig ist, gar nicht realisieren. Es ist also durchaus "sportlich", was AVM sich da so zutraut (und mit der neuen Datenschutzerklärung bei der 06.90 nun auch noch ausweiten will) ... da wäre dann eine tatsächlich nachvollziehbare und nicht nur postulierte Sorgfalt beim Ausrollen von Updates aber deutlich besser.
Würde so etwas jedenfalls einem anderen Hersteller passieren (z.B. Huawei, Netgear, D-Link ... jeder kann diese Aufzählung selbst nach Belieben fortsetzen), wäre es bis zu einem "typisch, wer denen automatische Updates erlaubt, ist selber schuld" nur ein extrem kleiner Schritt und dieser Meinung würden sich viele Benutzer anschließen (zumindest zeigt das die Erfahrung aus der Vergangenheit und aus anderen Foren, wenn es bei anderen Herstellern dann mal eine Lücke und entsprechende Updates gab oder gibt) ... an AVM darf man aber in dieser Richtung praktisch keine Kritik üben bzw. wenn dann mal offensichtliche "Patzer" nachweislich vorhanden sind, dann wird das verharmlost oder relativiert, denn "von AVM können sich andere eine Scheibe abschneiden".
Da werden dann auch gleich wieder Vergleiche mit irgendwelchen Billig-Routern an den Haaren herbeigezogen (die kosten dann auch nur 1/3 der FRITZ!Box und ich kann mir in den fünf Jahren der AVM-Garantie problemlos 2,5 neue Geräte (auch mit neuer Firmware) zulegen und habe i.d.R. immer noch weniger ausgegeben) und sofort betont, daß AVM doch wenigstens der Einäugige unter den Blinden ist. Wenn das tatsächlich der Maßstab sein sollte, daß man nur "ein wenig besser" als die Konkurrenz ist und dann ist man aus dem Schneider und/oder der Verantwortung entlassen, dann kann das auch ganz, ganz schnell nach hinten losgehen, wenn dann ein anderer Hersteller plötzlich "ein wenig besser" als AVM selbst ist. Ohne die extreme Fokussierung auf den deutschen Markt (praktisch alle anderen Hersteller befassen sich weltweit mit dem Thema, wenn man mal von chinesischen "Inlandsprodukten" absehen will) und dem damit einhergehenden - und aus der Masse der anderen herausstechenden - Support, wäre AVM auch nur ein Hersteller unter vielen.
Ich finde die Geräte auch nicht schlecht für den Heimanwender und die Feststellung, daß in deutschen Haushalten in der Mehrheit solche Geräte arbeiten, macht die auch für (eigene) Untersuchungen interessant ... aber die auch immer wieder anzutreffende Mentalität, AVM und die FRITZ!Boxen nun über den grünen Klee zu loben und als Vorbild für alle anderen Router und Hersteller zu deklarieren, während man jede Kritik von anderer Seite sofort als "Majestätsbeleidigung" interpretiert, kann in meinen Augen auch nur einem sehr verengten Gesichtsfeld zugeschrieben werden (oder einem generell eher unkritischen Umgang mit Technik, weil man Zusammenhänge gar nicht mehr versteht ... bei diesem ganzen neumodischen Kram).
Oder es ist doch auch wieder nur die "Verteidigung" des eigenen "Besitzstandes" nach dem Motto: "Wenn ich das auch habe und dafür teuer bezahlen mußte, dann KANN das einfach nicht schlecht sein, weil dann ja auch MEINE Wahl in Frage gestellt würde." ... das wäre dann wieder allzu menschlich und (leider) nur wenig objektiv.
Wieder ein recht langer Text ... es galt halt auch, Zusammenhänge darzulegen und Beispiele für Behauptungen meinerseits zu erbringen. Das kann ich in Stichworten nun mal nicht ... zumindest nicht in der (notwendigen) Eindeutigkeit, daß man mir nicht hinterher irgendwelche unklaren Formulierungen (berechtigterweise) um die Ohren haut.
Mich mußt Du nicht fragen, warum AVM welche Entscheidung trifft. Ich habe lediglich den Ist-Zustand beschrieben und Dir zeigen wollen, daß eine simple Änderung in einer "js"-Datei in der Firmware die MAC-Adresse wieder standardmäßig als Spalte ans Licht holt. AVM konzipiert die Firmware ja für verschiedene Umgebungen und bei wenigen Geräten im LAN (und für viele FRITZ!Box-Besitzer) ist die MAC-Adresse sicherlich eine eher unnütze Information in dieser Liste. Ähnliches gilt für eine eingestellte Sortierung ... auch die ließe sich verändern. Solange es die erwähnte Speicherung von GUI-Einstellungen nicht gibt, sehe ich keine andere Möglichkeit. Als Fehler der Firmware kann man es m.E. trotzdem nicht bezeichnen, daß die MAC-Adresse in der Seite nicht automatisch enthalten ist.
@robert_s:
Ich wollte meinerseits auch lediglich zeigen, daß Deine Annahme einer "spezielleren" Umgebung - damit dieser Bug überhaupt auffällt - falsch war. Gerade als Software-Entwickler (und ich bin auch ein solcher, zumindest habe ich auch das lange genug beruflich gemacht) kann ich auch "bei mir geht alles Wesentliche" nicht so richtig nachvollziehen als Standpunkt eines anderen aus demselben Metier. Wenn nur noch "wichtige Funktionen" tatsächlich fehlerfrei ausgeliefert und Fehler an anderen Stellen als "aber viel harmloser als ..." abgetan werden, dann offenbart das (a) einen Blick auf Fehler und Firmware ausschließlich aus der eigenen Perspektive (es beinhaltet auch eine gewisse Arroganz, weil automatisch davon ausgegangen wird, daß für alle anderen auch nur die von einem selbst genutzten Funktionen ausreichend Bedeutung hätten) und (b) eben doch - wenn auch implizit - die Feststellung, daß es "weniger wichtige Fehler" gibt, die man auch ruhig mal mit ausliefern kann, weil sie nicht alle Kunden betreffen und damit eben keine "show stopper" sind - die paar Kunden, die damit dann Probleme haben, sind genauso "weniger wichtig" (als man selbst). Wenn das bei "wandernden Problemen" passiert und jeder Fehler andere Kunden verprellt, ist auch dieses Herangehen durchaus dazu geeignet, eine größere (und am Ende stetig wachsende) Anzahl von Kunden zu verärgern und den eigenen Ruf zu ruinieren.
Das mit der Arroganz mögest Du bitte auch nicht persönlich nehmen ... da geht es weniger (bzw. gar nicht) um Deine Person als vielmehr um den von Dir vertretenen Standpunkt, der häufiger anzutreffen ist. Beim DECT-Monitor mag den noch so mancher nachvollziehen können und teilen wollen, beim Fehler aus der vorhergehenden Version (dem nicht aufzurufenden Paketmitschnitt) ist das schon deutlich schwieriger. Wie will jemand anderes einschätzen können, welche Priorität für meine Arbeit mit einer 6490 dieser Paketmitschnitt hat und ob nicht gerade dieser am Ende das Alleinstellungsmerkmal war, welches die 6490 von anderen Geräten unterscheidet und mich zum Kauf/Einsatz genau dieses Routers veranlaßte?
Da ist dann so ein Fehler alles andere als "harmlos", zumal bis zu seiner Beseitigung (absehbar) so viel Zeit vergehen wird, daß die oft bei AVM so hochgelobte Dauer, für die auch ältere Boxen mit Updates versorgt werden, sich spätestens dann auch relativiert, wenn man die Zeit zwischen zwei Versionen ins Verhältnis zu dieser Dauer setzt. Sechs Updates in vier Jahren (mal 9 Monate unterstellt, je nach Modell geht es mal schneller und mal dauert es deutlich länger) sind jetzt auch wieder nicht soo viel, daß man direkt in Euphorie ausbrechen müßte.
Läßt man die 06.83 in der "Zählung" mal aus (die wurde ja mehr oder weniger "inoffiziell" zurückgezogen, über die dafür (mutmaßlich) verantwortlichen Probleme haben wir hier auch noch nicht "geredet"), dann sind wir bei etwas mehr als zehn Monaten zwischen der 06.63 (28.10.2016) und dieser Version hier ... und da ist der Aspekt der extrem langsamen Behebung von Sicherheitsproblemen, der sich aus solch langen Zeiträumen zwischen Updates ergibt, noch gar nicht ausreichend gewürdigt. Solange das nicht problemlos auch von außen auszunutzen ist, sieht AVM bekanntermaßen ein Sicherheitsproblem eher als weniger wichtig an, im Vergleich zu neuen Funktionen - und selbst die Möglichkeit eines externen Angriffs (mit geringeren Auswirkungen als von innen) führt nicht automatisch zu höherer Priorität, wie wir auch inzwischen wissen.
Wobei der Fehler beim Paketmitschnitt (und ich meine hier den in der 06.83 und nicht die falsche Handhabung der Interface-Namen in irgendeiner Version davor, wo sich dann der Mitschnitt zwar starten, aber nicht sauber beenden ließ) schon beim Versuch, jeden Link wenigstens einmal mit dem korrekten Ergebnis aufzurufen, zu finden sein sollte und das ließe sich durchaus automatisieren - die Lua-Seiten und ihr Inhalt sowie die erwarteten Ergebnisse sind bekannt und die möglichen POST-Request an die "data.lua" ebenfalls, mit denen dann diese Seiten im Endergebnis aufgerufen werden, genauso die "richtigen" HTML-/JSON-Ausgaben bei definierten Ausgangswerten - die sollten bereits aus "unit tests" für die kleineren Einheiten vorliegen.
Das dann noch einmal nach der Integration durchzuführen, kann eigentlich nicht soo schwer sein. Jeder Kunde, der seinerseits irgendwelche Aufgaben über das GUI automatisieren möchte (es gibt auch hier genug Anfragen in dieser Richtung), macht das am Ende genauso ... er sieht sich die gesendeten Requests an und sucht sich aus den - auf diese Requests erhaltenen - Antworten den Teil der Daten heraus, der ihn interessiert. Es gibt ja sogar die Möglichkeit, mit "dbg=1" in einer URL sich noch eine Liste der aus der Firmware gelesenen Einstellungen und diverser interner "tables" aus dem Lua-Code der Seite ausgeben zu lassen (wurde auch ins GUI integriert, findet man im User-Menü, wenn die Option beim Aufruf angegeben war) - da könnte man bei einer Automatisierung von Tests (das ist JSON, was da kommt bei "dbg=1") auch drauf zugreifen.
Das mit ein "Einpflegen von Sicherheitsupdates" finde ich schon wieder putzig ... wenn das tatsächlich anhand der Version geschehen sollte, in der so ein Problem auch auftrat und dieser Punkt liegt vor irgendwelchen "feature branches", dann sollte es (ich unterstelle mal, daß AVM auch "git" einsetzt, alles andere würde mich sehr wundern) kein wirkliches Problem darstellen, solche Branches auf Basis des nunmehr geänderten Ausgangspunkts (also der Stelle mit dem gefixten Problem) neu aufzusetzen (rebase).
Lasse ich solche Sicherheitsupdates aber eher liegen und ändere das alles ohnehin erst nach dem Fertigstellen neuer Features (so stellt es sich bei AVM ja dar - das kann jeder selbst verfolgen, wann in den Labor-Zweigen bisher auch solche Probleme behoben wurden, die lange vor dem (öffentlichen) Start der Labor-Reihe bereits gemeldet waren), ändert das für meine verschiedenen "Varianten" (aka Modelle) am Aufwand nichts.
Wenn ich das als Firma dann aber nicht mehr wirklich gebacken kriege, mehrere/viele Modelle auf einmal zu managen, dann muß ich entweder meine Strategie anpassen an das erweiterte Portfolio, mehr Manpower rankarren (damit das ohne Änderungen der Abläufe gestemmt werden kann) oder auf die Verbreiterung meines Portfolios einfach verzichten. Dem Käufer einer 7490 kann ich wohl kaum plausibel machen, daß ich nicht mehr in der Lage bin, seinem Modell die notwendige Aufmerksamkeit zu widmen (und die notwendigen Ressourcen zuzuteilen), nur weil es auch noch eine 3490 oder eine 7430 als billigere Varianten für eine leicht abweichende Zielgruppe gibt und ich mich eigentlich schon übernommen habe.
Und Deiner Feststellung
kann ich nicht folgen ... die Oberfläche dürfte sich ja (bei korrektem VCS-Einsatz) in dieser Version gerade nicht geändert haben. Jedenfalls kann ich meinerseits in der "info.txt" zu diesem Update keinen Hinweis in dieser Richtung finden:robert_s schrieb:
... außer Du willst mir jetzt die 2FA als diese entscheidende Änderung "unterjubeln" (nicht falsch verstehen, ich hätte auch "verkaufen" o.ä. schreiben können, das ist nicht persönlich gemeint). Die wurde aber nur auf weitere Einstellungen ausgedehnt und existierte bereits davor ... da der DECT-Monitor auch nicht zu diesen Seiten gehört, ist es halt unklar, wie dessen neuere Variante aus der 06.88-Reihe in den Branch für die 06.84 gelangt sein mag.
Und auch wenn es wie "Korinthenkackerei" aussieht ... in gewisser Weise regt mich auch die "Sprachregelung" bei AVM auf. Es gibt eben keine "Fehlerkorrekturen" nach eigener Ansicht ... es geht immer nur um "Weitere Verbesserungen" und wenn man die o.a. Liste als Kunde so ansieht, dann würde man (meine Meinung) vielleicht zwei Punkten (Modem-Treiber und zusätzliche 2FA) diese Klassifizierung zugestehen ... alles andere ist nichts weiter als das Beheben zuvor verbockter Probleme. Das wirkt auf mich dann immer ein wenig wie das "fishing for compliments" nach dem Motto: "Schau her, lieber Kunde, wir verbessern unsere Produkte ständig in Deinem Interesse." und dabei handelt es sich hier (nimmt man die Punkte und nicht die dahinter ggf. verborgene Arbeit) zu 2/3 um das Beheben eigener Fehler. Was mich hier auch mehr als erstaunt, ist die Tatsache, daß von einer Behebung des Problems an DS-Lite-Anschlüssen, wie es für UM bei der 06.83 mehrfach berichtet wurde (hatten wir auch hier irgendwo in einem Thread), eigentlich nichts zu lesen ist. Funktioniert das jetzt auch und war quasi "Nebenprodukt" einer der aufgeführten Änderungen, so daß es gar keiner eigenen Erwähnung bedarf? Oder gab es das Problem gar nicht? Welcher der o.a. - nunmehr behobenen - Punkte wird denn derjenige gewesen sein, der zum "Zurückziehen" der 06.83 führte? (Auch wenn es das offiziell nie gab, ist die geänderte Antwort auf Versionsabfragen am Ende ja nichts anderes.) Es wird eher nicht die Verwendung mit einem einzelnen US-Kanal gewesen sein, zumal das auch - nach Beschreibung - nur sporadisch zu Problemen führte.
Wie gesagt ... ich will auch nicht den Blick für die Realität verlieren und kenne durchaus auch die Probleme, vor denen AVM (mutmaßlich) steht. Aber das kann einfach keine Entschuldigung dafür sein, daß der Kunde in zunehmendem Umfang mit Firmware-Versionen konfrontiert wird, denen man das "mit der heißen Nadel gestrickt" sofort ansehen kann. Da braucht es auch gar keinen Billig-Löhner, der sich den ganzen Tag nur durch irgendwelche GUIs klickt, wie Du Deinerseits (etwas polemisch) festgestellt hast ... wir reden hier nämlich nicht über "tägliche Tests" und irgendwelche (internen oder öffentlichen) Labor-Versionen. Für diese könnte man das sicherlich akzeptieren (und darf sich trotzdem auch dort darüber aufregen), wenn bei der Integration mal etwas nicht auf Anhieb funktioniert. Aber hier geht es deutlich um eine Release-Version und da darf man als Kunde tatsächlich vor der Bereitstellung des Updates erwarten, daß noch mindestens ein Test ausgeführt wird.
Ob manuell oder automatisch, ist mir als Kunde sowas von egal ... entscheidend ist, daß derart offensichtliche Fehler gefunden werden und - noch einmal - es gab bisher praktisch keine wirklich fehlerfreie Firmware für die 6490 (und jetzt bitte nicht wieder den alten Spruch, daß es eine solche gar nicht geben kann ... es geht hier entweder tatsächlich um Basisfunktionen (DS-Lite) oder um Fehler, die AVM-Kunden dann innerhalb von Stunden nach der Freigabe der Firmware gefunden haben und nicht um versteckte Probleme in irgendwelchen unvorhersehbaren, absonderlichen Konstellationen) und da reden wir auch nicht nur von irgendwelchen GUI-Fehlern, sondern wirklich von "bread'n'butter"-Funktionen.
Wenn Du selbst von dem DS-Lite-Problem am UM-Anschluß betroffen gewesen wärst, wäre vermutlich auch Deine Einschätzung zur Bedeutung dieses Problem deutlich anders ausgefallen - auch hier kannst Du gerne Deine eigene Person (die aber die oben nachzulesenden Aussagen aufgestellt hat, daher beziehe ich mich nun auch darauf) durch abstraktere Charaktere ersetzen. Gerade bei den DOCSIS-Modellen ohne öffentlichen Beta-Test muß ich mir doch auch als Hersteller einfach mehr Mühe geben, wenn ich selbst weiß, daß die ansonsten aus dem Kundenkreis kommenden Rückmeldungen hier einfach fehlen.
Die paar Tester bei den KNB können doch die Labor-Benutzer bei den DSL-Varianten nicht ersetzen ... daß man dort (sollte es tatsächlich eine Vorläufer-Beta für die KNB gegeben haben, die dann 1:1 zur Release-Version wurde) das Problem mit dem DECT-Monitor oder auch dem Paketmitschnitt nicht findet (man testet ja die Funktion im eigenen Netz und nicht das AVM-GUI) oder es - selbst wenn man es findet - gar nicht erst meldet, kann ich sehr gut nachvollziehen. Denen ist da kein Vorwurf zu machen ... solange AVM sie nicht für solche Tests bezahlt, haben sie halt die Möglichkeit, die reibungslose Funktion der Firmware in ihrem Netz zu begutachten und notfalls Änderungsbedarf anzumelden. Das bezieht sich aber auf ihr eigenes Netz und damit die eCM- und eRouter-Funktionen der Retail-Version (mehr enthält die ja auch nicht, was unter DOCSIS fallen würde) - was interessiert es denn einen KNB, ob meinetwegen die DynDNS-Dienste oder die MyFRITZ!-Anmeldung oder -Freigaben funktionieren? Gar nicht ... ganz einfach. Das ist vielleicht noch bei der Provider-Firmware ein Problem - ansonsten kann ein Kunde mit einer Retail-Box den KNB aber mal "gerne haben".
Mit diesem Wissen im Hinterkopf muß ich dann eben als Hersteller mehr in das Modell investieren ... und erst recht dann, wenn ich meinerseits den Kunden empfehle, sie sollten mir doch (quasi blind) vertrauen und mir selbst das Aktualisieren der Firmware ihrer Geräte überlassen (die empfohlene Auto-Update-Einstellung von AVM - schau in die Online-Hilfe). Dann stehe ich automatisch noch mehr in der Verantwortung, meinerseits alles Menschenmögliche zu tun, damit ich mich dieses Vertrauens auch würdig erweise ... da sind solche Fehler dann nicht nur ärgerlich für den Kunden, sie schaden auch dem Renommee des Herstellers insgesamt.
Es ist zwar nicht der Super-GAU, aber es ist ein schlechtes Zeugnis für die QS bei AVM ... und etwas in dieser Richtung sollte es (hoffentlich) auch dort geben. Bei den DOCSIS-Boxen kommt noch erschwerend hinzu, daß es keinen (offiziellen) Weg zurück zur Vorgängerversion gibt ... m.W. rückt AVM auch keine Recoveries an Kunden heraus, die nach einem Update tatsächlich mit Problemen zu kämpfen haben (und zwar auch solchen, die den Anschluß unbenutzbar machen) und tauscht auch dort lieber die Box aus (nach dem zusätzlichen Aufwand für den Kunden kräht da auch kein Hahn mehr).
Der Super-GAU wäre es, wenn nach einem automatischen Update die Einstellungen des Kunden verloren gehen und er - in vielen Haushalten sicherlich auch noch der Fall - keine aktuellen Sicherungen hat oder gar nicht weiß, wie er diese einspielen soll, weil die Installation von einem "Fachmann" vorgenommen wurde - da ist dann ggf. selbst die Sicherung per E-Mail wenig hilfreich, weil man die ohne funktionierende Box auch nicht wieder abrufen und importieren kann, denn das geht nur selten mit einem Tablet oder Smartphone, was seinerseits mit Mobilfunk noch ins Internet käme ... viele können die lokale Speicherung von Downloads, die für die Benutzung des Upload-Formulars notwendig ist, gar nicht realisieren. Es ist also durchaus "sportlich", was AVM sich da so zutraut (und mit der neuen Datenschutzerklärung bei der 06.90 nun auch noch ausweiten will) ... da wäre dann eine tatsächlich nachvollziehbare und nicht nur postulierte Sorgfalt beim Ausrollen von Updates aber deutlich besser.
Würde so etwas jedenfalls einem anderen Hersteller passieren (z.B. Huawei, Netgear, D-Link ... jeder kann diese Aufzählung selbst nach Belieben fortsetzen), wäre es bis zu einem "typisch, wer denen automatische Updates erlaubt, ist selber schuld" nur ein extrem kleiner Schritt und dieser Meinung würden sich viele Benutzer anschließen (zumindest zeigt das die Erfahrung aus der Vergangenheit und aus anderen Foren, wenn es bei anderen Herstellern dann mal eine Lücke und entsprechende Updates gab oder gibt) ... an AVM darf man aber in dieser Richtung praktisch keine Kritik üben bzw. wenn dann mal offensichtliche "Patzer" nachweislich vorhanden sind, dann wird das verharmlost oder relativiert, denn "von AVM können sich andere eine Scheibe abschneiden".
Da werden dann auch gleich wieder Vergleiche mit irgendwelchen Billig-Routern an den Haaren herbeigezogen (die kosten dann auch nur 1/3 der FRITZ!Box und ich kann mir in den fünf Jahren der AVM-Garantie problemlos 2,5 neue Geräte (auch mit neuer Firmware) zulegen und habe i.d.R. immer noch weniger ausgegeben) und sofort betont, daß AVM doch wenigstens der Einäugige unter den Blinden ist. Wenn das tatsächlich der Maßstab sein sollte, daß man nur "ein wenig besser" als die Konkurrenz ist und dann ist man aus dem Schneider und/oder der Verantwortung entlassen, dann kann das auch ganz, ganz schnell nach hinten losgehen, wenn dann ein anderer Hersteller plötzlich "ein wenig besser" als AVM selbst ist. Ohne die extreme Fokussierung auf den deutschen Markt (praktisch alle anderen Hersteller befassen sich weltweit mit dem Thema, wenn man mal von chinesischen "Inlandsprodukten" absehen will) und dem damit einhergehenden - und aus der Masse der anderen herausstechenden - Support, wäre AVM auch nur ein Hersteller unter vielen.
Ich finde die Geräte auch nicht schlecht für den Heimanwender und die Feststellung, daß in deutschen Haushalten in der Mehrheit solche Geräte arbeiten, macht die auch für (eigene) Untersuchungen interessant ... aber die auch immer wieder anzutreffende Mentalität, AVM und die FRITZ!Boxen nun über den grünen Klee zu loben und als Vorbild für alle anderen Router und Hersteller zu deklarieren, während man jede Kritik von anderer Seite sofort als "Majestätsbeleidigung" interpretiert, kann in meinen Augen auch nur einem sehr verengten Gesichtsfeld zugeschrieben werden (oder einem generell eher unkritischen Umgang mit Technik, weil man Zusammenhänge gar nicht mehr versteht ... bei diesem ganzen neumodischen Kram).
Oder es ist doch auch wieder nur die "Verteidigung" des eigenen "Besitzstandes" nach dem Motto: "Wenn ich das auch habe und dafür teuer bezahlen mußte, dann KANN das einfach nicht schlecht sein, weil dann ja auch MEINE Wahl in Frage gestellt würde." ... das wäre dann wieder allzu menschlich und (leider) nur wenig objektiv.
Wieder ein recht langer Text ... es galt halt auch, Zusammenhänge darzulegen und Beispiele für Behauptungen meinerseits zu erbringen. Das kann ich in Stichworten nun mal nicht ... zumindest nicht in der (notwendigen) Eindeutigkeit, daß man mir nicht hinterher irgendwelche unklaren Formulierungen (berechtigterweise) um die Ohren haut.
Zuletzt bearbeitet:
PeterPawn
So gerade mit dem Lesen fertig geworden, stimme fast völlig zu, (soweit ich allem folgen konnte), aber da muß ich doch noch mal zur Tapse greifen.
Falls ich so in der Hinterstube behalten habe, was Du letztendlich alles (berechtigt) bemängelst an Herrn Fritz und seinen Werktätigen,
wundere ich mich dann aber doch, daß Du mir den Vorschlag machst, das was ich (seit der neuen Oberfläche) nicht mehr habe selber zu korrigieren.
Gut, daß kriege ich noch hin, wenn ich denn wollte, ich will aber nicht. Ist nicht meine Aufgabe.
Ob meine ehemals vorhandenen Wünsche nun für die Allgemeinheit relevant sind, ist mir erstmal wurscbt,
Mir stellt sich nur die Frage, warum was entfernt wurde, was drin war und dann auch noch halbherzig,
Deshalb frage ich immer nach dem Warum und, falls es dafür wirklich eine begründete Ursache gäbe, würde sogar ich das (vielleicht) verstehen.
Am RAM wirds ja hoffentlich nicht liegen.
Die Konkurenz schläft nicht, da muß auch AVM punkten, aber,
ob eine eierlegende Wollmilchsau also immer Maximum statt Optimierung der heilige Gral ist, wage ich zu bezweifeln.
Werden wir beide nicht lösen, also entweder selber basteln oder es bleibt alles ganz anders.
So gerade mit dem Lesen fertig geworden, stimme fast völlig zu, (soweit ich allem folgen konnte), aber da muß ich doch noch mal zur Tapse greifen.
Falls ich so in der Hinterstube behalten habe, was Du letztendlich alles (berechtigt) bemängelst an Herrn Fritz und seinen Werktätigen,
wundere ich mich dann aber doch, daß Du mir den Vorschlag machst, das was ich (seit der neuen Oberfläche) nicht mehr habe selber zu korrigieren.
Gut, daß kriege ich noch hin, wenn ich denn wollte, ich will aber nicht. Ist nicht meine Aufgabe.
Ob meine ehemals vorhandenen Wünsche nun für die Allgemeinheit relevant sind, ist mir erstmal wurscbt,
Mir stellt sich nur die Frage, warum was entfernt wurde, was drin war und dann auch noch halbherzig,
Deshalb frage ich immer nach dem Warum und, falls es dafür wirklich eine begründete Ursache gäbe, würde sogar ich das (vielleicht) verstehen.
Am RAM wirds ja hoffentlich nicht liegen.
Die Konkurenz schläft nicht, da muß auch AVM punkten, aber,
ob eine eierlegende Wollmilchsau also immer Maximum statt Optimierung der heilige Gral ist, wage ich zu bezweifeln.
Werden wir beide nicht lösen, also entweder selber basteln oder es bleibt alles ganz anders.
Zuletzt bearbeitet:
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,300
- Punkte für Reaktionen
- 1,760
- Punkte
- 113
@rstle:
Das eine ist der prinzipielle Ansatz des "Nachvollziehens" solcher Änderungen, bei dem man sich als AVM-Produkt-Designer vermutlich fragt, was die Kunden am häufigsten benutzen, was zu zusätzlichen Unklarheiten/Erklärungsbedarf im Support-Aufkommen führt und was bei den meisten Kunden ohnehin nur als eher nutzlose Information im GUI "rumsteht" (und so eine Spalte mehr oder weniger kann dann beim "responsive design" schon den Unterschied ergeben, bei welcher Bildschirmgröße und Auflösung auf andere Darstellungen umgeschaltet werden muß) und ggf. erst nach weiteren Bedienschritten angezeigt werden kann (es ist ja nicht so, daß die MAC-Adressen gar nicht mehr zum Vorschein kommen bei der AVM-Firmware). Das hängt auch mit der Einschätzung zusammen, wie kompliziert/ausführlich so ein GUI nun für die Mehrzahl der Kunden sein muß oder soll (ich will auch keine fünf oder noch mehr Abstufungen bei den Einstellungen zur Sichtbarkeit von irgendwelchen Optionen haben). Noch einmal ... die Funktionalität wurde hier nicht komplett entfernt, sie braucht nur zusätzliche Handgriffe, damit man sie nutzen kann.
Das andere ist dann die Frage, welche (realistische) Chance man den eigenen Anforderungen und Erwartungen an die Firmware und der daraus resultierenden Beschwerde bei AVM am Ende wirklich einräumt. Anstatt mich jetzt für die nächsten 10 Monate über AVM zu ärgern und dann bei der nächsten Version erneut festzustellen, daß AVM das offensichtlich (oder meinetwegen auch nur vermutlich) anders sieht, gehe ich halt lieber hin und investiere 10 Minuten meiner Zeit für die Korrektur dessen, was ich selbst als Fehler sehe. Das muß mich nicht davon abhalten, bei AVM trotzdem zu intervenieren ... aber wenn das dann zwei- oder dreimal erfolglos blieb, dann denke ich mir auch einfach "Leckt mich doch ..." und verzichte künftig auf weitere Kontakte, mache es halt einfach selbst. Die Alternative wäre es ansonsten, das Gerät/den Hersteller zu wechseln ... je nach Schwere des Problems (und nach meinen eigenen Kenntnissen, Fähigkeiten und Möglichkeiten) notwendig oder eine Überreaktion.
EDIT: Auch die Frage, warum die in der WLAN-Liste (hier aber auch unter dem Aspekt "Sicherheit") automatisch angezeigt wird und in der Netzwerk-Übersicht nicht, finde ich nicht so schwer zu beantworten (ob die Antwort dann auch wirklich stimmt, sei dahingestellt, zumindest eine gewisse Wahrscheinlichkeit kann man aber annehmen). Im WLAN spielt nämlich die MAC-Adresse auch ansonsten eine Rolle in der AVM-Firmware ... vom Eintrag im Event-Log bei der Anmeldung neuer (bisher unbekannter) Geräte bis hin zum (unsäglichen) "MAC address filter" (nur bekannte Geräte zulassen). Bei LAN-Geräten dürften eher selten (im Privathaushalt) neue Geräte auftauchen und auch die MAC-Filterung (gäbe es ja auch in der Theorie) ist da nicht möglich bei der FRITZ!Box. Wenn also jemand eine Eintragung im Event-Log überprüfen will und findet im GUI gar keine Stelle, wo die MAC-Adresse aufgeführt ist, wäre das sicherlich auch merkwürdig ... dafür reicht aber die Anzeige der WLAN-Clients dann auch aus und es muß nicht (automatisch) auch noch der Platz in den Netzwerkverbindungen belegt werden (zumal da viele denkbare Einträge gar keine MAC-Adresse haben).
Das eine ist der prinzipielle Ansatz des "Nachvollziehens" solcher Änderungen, bei dem man sich als AVM-Produkt-Designer vermutlich fragt, was die Kunden am häufigsten benutzen, was zu zusätzlichen Unklarheiten/Erklärungsbedarf im Support-Aufkommen führt und was bei den meisten Kunden ohnehin nur als eher nutzlose Information im GUI "rumsteht" (und so eine Spalte mehr oder weniger kann dann beim "responsive design" schon den Unterschied ergeben, bei welcher Bildschirmgröße und Auflösung auf andere Darstellungen umgeschaltet werden muß) und ggf. erst nach weiteren Bedienschritten angezeigt werden kann (es ist ja nicht so, daß die MAC-Adressen gar nicht mehr zum Vorschein kommen bei der AVM-Firmware). Das hängt auch mit der Einschätzung zusammen, wie kompliziert/ausführlich so ein GUI nun für die Mehrzahl der Kunden sein muß oder soll (ich will auch keine fünf oder noch mehr Abstufungen bei den Einstellungen zur Sichtbarkeit von irgendwelchen Optionen haben). Noch einmal ... die Funktionalität wurde hier nicht komplett entfernt, sie braucht nur zusätzliche Handgriffe, damit man sie nutzen kann.
Das andere ist dann die Frage, welche (realistische) Chance man den eigenen Anforderungen und Erwartungen an die Firmware und der daraus resultierenden Beschwerde bei AVM am Ende wirklich einräumt. Anstatt mich jetzt für die nächsten 10 Monate über AVM zu ärgern und dann bei der nächsten Version erneut festzustellen, daß AVM das offensichtlich (oder meinetwegen auch nur vermutlich) anders sieht, gehe ich halt lieber hin und investiere 10 Minuten meiner Zeit für die Korrektur dessen, was ich selbst als Fehler sehe. Das muß mich nicht davon abhalten, bei AVM trotzdem zu intervenieren ... aber wenn das dann zwei- oder dreimal erfolglos blieb, dann denke ich mir auch einfach "Leckt mich doch ..." und verzichte künftig auf weitere Kontakte, mache es halt einfach selbst. Die Alternative wäre es ansonsten, das Gerät/den Hersteller zu wechseln ... je nach Schwere des Problems (und nach meinen eigenen Kenntnissen, Fähigkeiten und Möglichkeiten) notwendig oder eine Überreaktion.
EDIT: Auch die Frage, warum die in der WLAN-Liste (hier aber auch unter dem Aspekt "Sicherheit") automatisch angezeigt wird und in der Netzwerk-Übersicht nicht, finde ich nicht so schwer zu beantworten (ob die Antwort dann auch wirklich stimmt, sei dahingestellt, zumindest eine gewisse Wahrscheinlichkeit kann man aber annehmen). Im WLAN spielt nämlich die MAC-Adresse auch ansonsten eine Rolle in der AVM-Firmware ... vom Eintrag im Event-Log bei der Anmeldung neuer (bisher unbekannter) Geräte bis hin zum (unsäglichen) "MAC address filter" (nur bekannte Geräte zulassen). Bei LAN-Geräten dürften eher selten (im Privathaushalt) neue Geräte auftauchen und auch die MAC-Filterung (gäbe es ja auch in der Theorie) ist da nicht möglich bei der FRITZ!Box. Wenn also jemand eine Eintragung im Event-Log überprüfen will und findet im GUI gar keine Stelle, wo die MAC-Adresse aufgeführt ist, wäre das sicherlich auch merkwürdig ... dafür reicht aber die Anzeige der WLAN-Clients dann auch aus und es muß nicht (automatisch) auch noch der Platz in den Netzwerkverbindungen belegt werden (zumal da viele denkbare Einträge gar keine MAC-Adresse haben).
Zuletzt bearbeitet:
Neueste Beiträge
-
Ping-Spikes 7590 im lokalen Netzwerk- Letzte: frank_m24
-
zusätzliche 1GB AF, aber kein Kontingent bei DSL Vertrag mehr- Letzte: Gildehauser
-
FRITZ!Box 7530 / FRITZ!OS 8.0x vom 10.10.2024- Letzte: Dolde
-
[Problem] Mitel RFP44 mit Signalisierungs- und Sprachproblemen
- Letzte: Chilltime
-
[Frage] Mitel430-CompanyFlex-5G
- Letzte: Chilltime
