v!king
Mitglied
- Mitglied seit
- 8 Apr 2015
- Beiträge
- 433
- Punkte für Reaktionen
- 27
- Punkte
- 28
Modell: FRITZ!Box 7490 / 6.80-42651.image
Aktueller Energieverbrauch: 50% <---- war vohher bei 38 %
ist das bei euch auch so?
Aktueller Energieverbrauch: 50% <---- war vohher bei 38 %
ist das bei euch auch so?
Zuletzt bearbeitet:
DickS
Aktives Mitglied
- Mitglied seit
- 22 Feb 2005
- Beiträge
- 2,285
- Punkte für Reaktionen
- 132
- Punkte
- 63
ADSL + DECT gleich geblieben.
UPDATE: Nach mehrere Stunden auffällig geringere DSL-Fehler verglichen mit 6.80.
UPDATE 2: Läuft sehr gut, habe keine Aussetzer mehr wenn der Downloadstream nahe zu 100% ausgelastet ist.
Zuletzt bearbeitet:
Corrado-HH
Mitglied
- Mitglied seit
- 21 Mrz 2006
- Beiträge
- 767
- Punkte für Reaktionen
- 6
- Punkte
- 18
Ich hatte die Grundversion per C&P übernommen (Post von Jochen) und nur die build angepasst. :weg:
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,279
- Punkte für Reaktionen
- 1,754
- Punkte
- 113
Wie aktuell und durchdacht wird denn das neue Release nun wirklich sein?
Hat AVM bei den neuen Versionen (06.80-irgendwas) eigentlich den Schritt zu einer neuen OpenSSL-Version gewagt?
Die in den letzten zwei Jahren verwendete Version OpenSSL 1.0.1 ist ja seit dem Jahreswechsel "out of support" ... wenn die nächste Lücke bekannt wird, die sich auch auf MIPS/ARM/x86 (bei der 6490 wird eben für den NAS-Teil auch die - gewöhnlich besser "ausgeleuchtete", weil sich die meisten PoC eben auf x86-Code stützen - Version für x86 verwendet) auswirkt oder ausnutzen läßt, dann wird die derzeit immer noch präsente Version (1.0.1q vom 03.12.2015) zwar ohnehin ersetzt werden müssen, aber so eine "Notoperation" ist sicherlich nicht der geeignete Zeitpunkt für den Wechsel der OpenSSL-Basisversion - daher hege ich die (nicht überbordende) Hoffnung, daß AVM das mal rechtzeitig macht (es gab ja bereits einmal eine FRITZ!OS-Version, wo die verwendete OpenSSL-Version tatsächlich aktuell war - damals war sogar das OpenSSL-Update der letzte Schritt, der noch einmal eine neue Version des FRITZ!OS hervorbrachte) und - da ein modulares Update ja ohnehin derzeit nicht möglich ist, auch wenn AVM vielleicht irgendwann den Plugin-Mechanismus mal dafür "aufbohren" wird bzw. das machen könnte - wir für die 7490 mit einer FRITZ!OS-Version mit aktuellem OpenSSL rechnen dürfen.
Auch wenn sich die (noch eine Weile unterstützte) 1.0.2 und die 1.0.1 nicht allzu wesentlich voneinander unterscheiden (wobei es ohnehin noch sechs weitere "security advisories" seit der von AVM verwendeten 1.0.1q gab, auch wenn die nicht alle relevant für MIPS-Prozessoren und/oder die von AVM verwendete Konfiguration sein mögen), gerade bei den VPN-Funktionen wird m.W. immer noch auch DES (bzw. 3DES) mit kurzen Schlüsseln und/oder Blocklängen unterstützt (was man zwar ohnehin nicht verwenden sollte) und da ergaben sich nach dem Bekanntwerden von SWEET32 einige Änderungen am OpenSSL-Code (u.a. bei der "automatischen Wahl" von Verschlüsselungsalgorithmen), die ggf. (ich kenne natürlich die AVM-Quellen nicht und auch die von AVM verwendete Konfiguration bei der Übersetzung der OpenSSL-Quellen ist nicht veröffentlicht, weil die Lizenz es nicht erforderlich macht und AVM es ja nicht einmal für die Quellen gebacken bekommt, wo sie rechtlich dazu verpflichtet wären) auch Auswirkungen auf AVM-Code und dessen Funktion haben könnten und dann ist ein ggf. notwendiger schneller Fix für eine OpenSSL-Lücke sicherlich nicht die richtige Gelegenheit, um solche Abhängigkeiten dann (a) auszuschließen oder (b) gut zu testen, bevor man so eine Version als "erforderliches Update" freigibt und auf den Kundenboxen automatisch installiert.
Mit der Implementierung der "Autoupdate"-Funktionen hat AVM ja auch automatisch eine größere Verantwortung für die korrekte Funktion der Kundengeräte nach so einem automatischen Update übernommen und da gehören nun einmal umfangreiche Regressionstests (das sind Tests, daß eine neue Funktion bzw. eine Änderung nicht nur den gewünschten neuen Effekt erzielt, sondern daß davon auch keine bereits vorhandenen Funktionen in Mitleidenschaft gezogen werden) nicht mehr zur Kür, sondern nunmehr zum Pflichtprogramm.
Angesichts einiger aktueller Katastrophen (u.a. ungeklärter Phänomene beim unerwünschten Firmware-Update bei NOR-Boxen - konkret wohl nur der 7390) setzt sich bei mir irgendwie nicht der Eindruck durch, daß man sich bei AVM dieser neu übernommenen Verantwortung auch wirklich bewußt ist und nicht nach dem Motto "Wo gehobelt wird, da fallen Späne ..." einfach billigend in Kauf nimmt, daß es bei einem bestimmten (hoffentlich kleineren) Prozentsatz von Kunden dann eben Probleme geben wird.
Die (zumindest nach meinem Empfinden, das sich allerdings nicht auf eigene Anfragen stützt und nur auf aktuellen "Erfahrungen" von anderen Kunden beruht, die dann nach unbefriedigendem AVM-Ergebnis Kontakt mit mir aufnehmen) weiter nachlassende Qualität des Kundensupports (es hängt sicherlich auch immer davon ab, wen man "erwischt" als Bearbeiter des eigenen Anliegens - hier fehlt AVM nach meinem Dafürhalten eindeutig ein Bewertungssystem für den Kundensupport, wo der Kunde seinem "Unmut" dann Luft machen kann ohne große Schreiberei (die ohnehin niemand liest) und wo das "Ergebnis" direkt dem Mitarbeiter zugeordnet werden kann) ist nun nicht unbedingt ein Punkt, der eine zusätzliche Belastung des Kundensupports nahelegen sollte.
Man male sich nur einmal aus, was z.B. passieren würde, wenn eine der "automatisch" aktualisierten Versionen auf einmal an nur 10% der Internet-Anschlüsse keine stabile Verbindung mehr aufbauen kann und deren Eigentümer dann auf einmal vor der Aufgabe stehen, sich eine ältere Firmware erst einmal auf irgendeinem anderen Weg zu beschaffen (die eigene Internetverbindung geht ja dann nicht) und diese dann auch noch per Recovery-Programm zu installieren. Da, wo vor 2-3 Jahren vielleicht noch die Existenz eines PC mit der Möglichkeit einer Ethernet-Verbindung zur Box vorausgesetzt werden konnte, da hat sich die Landschaft der eingesetzten Geräte inzwischen komplett gewandelt und es gibt schon genug Haushalte, in denen nur noch WLAN-Clients (oder auch Computer ohne Windows - entweder mit OS X oder Linux) vorhanden sind (selbst viele "Laptops" haben heute ja keinen Ethernet-Port mehr) und wo die Verwendung des bisher von AVM ausschließlich bereitgestellten Windows-Programms für das Recovern die Benutzer vor ungeahnte Probleme stellen kann.
Selbst wenn so ein automatisches Update sich i.d.R. über eine Woche verteilen würde (das FRITZOS sucht in der Standardeinstellung m.W. nur alle 168 Stunden nach einer neuen Version, was bei einem wirklich drängenden Problem auch schon ein zweischneidiges Schwert ist) und man es vermutlich spätestens nach 24 Stunden wieder stoppen würde, wenn genug Beschwerden im Support eingehen ... stimmen die (überschlagenen) Zahlen von > 50% Anteil bei Breitband-Anschlüssen in D (> 30 Mio. (feste) Anschlüsse, Stand Q3/2016), sind das (gleichmäßige zeitliche Verteilung mal unterstellt) bereits > 2 Mio. Boxen innerhalb von 24 Stunden (30 Mio. * 50% / 7 Tage), die von der Freigabe so einer neuen Version als "Notfallupdate" betroffen wären (wobei ich die "Fehlerrate" ja nur bei 10% angesetzt habe und das sind dann nur noch 200.000 Anschlüsse/Kunden, die damit Probleme haben) und da ist das (zumindest in meinen Augen) dann der falsche Moment, wenn man sich "gezwungenermaßen" zu einer neuen OpenSSL-Version mit (zumindest denkbaren) "side effects" durchringen muß (um mal den Kreis beim Gedankengang wieder zu schließen).
Überhaupt finde ich das "automatische Update" (das ich - noch einmal sei auf die berichteten Merkwürdigkeiten bei der 7390 verwiesen - für ungenügend getestet halte) schon recht ambitioniert ... da sind schon ganz andere (und wesentlich größere/besser testende) Firmen wie Microsoft oder Apple heftig auf die Nase gefallen, wenn dann irgendwelche Computer nach so einem Update nicht mehr richtig starten wollten. Während man da aber immer noch eine funktionierende Internet-Verbindung und damit entsprechende Recherchemöglichkeiten zur Behebung hatte, bleibt am Ende bei einem Problem mit dem Router ja fast nur noch der telefonische Support - über Mobilfunk, der natürlich auch kein Recovery auf dem Router machen kann und das wäre dann (neben dem auslösenden Problem, das die Notwendigkeit so eines Updates hervorgerufen hatte) wohl der Super-GAU, der AVM passieren könnte.
Insofern ist das nicht "unmutig", sich so eine Möglichkeit überhaupt zu schaffen (wobei man ja spekulieren kann, ob sich AVM bisher noch nicht so richtig "traute", das Update auf 06.5x bei NAND-Modellen als "notwendig" zu kennzeichnen für 06.2x-06.3x-Verwender) ... aber man sollte sie eben auch im Vorfeld dann sehr gut testen (bei der 7390 gibt es ja nicht einmal den theoretischen Rückweg über den Bootloader zur vorhergehenden Version) und man sollte auch einem Plan B (für den heutigen(!) Kunden mit seiner "IT-Landschaft") in der Schublade haben.
Den Eindruck gewinne ich bei AVM nicht ... es gäbe so viele Möglichkeiten, wie man z.B. durch einen geänderten Bootloader bei den neueren Modellen (die ja fast alle NAND-basiert sind und "linux_fs_start" verwenden) entsprechende Vorsorge treffen könnte (bei der Gelegenheit könnte man auch viele derzeit noch mögliche Angriffe über den Bootloader gleich ebenfalls be- oder sogar verhindern), die auch den "normalen Kunden" nicht wirklich überfordern ... der wird ja wohl noch einen Button an der Box drücken können. Darüber könnte man schon den generellen Zugang zum FTP-Server (der ja für Recovery gebraucht wird) absichern und ggf. sogar die Umschaltung auf die vorherige Version (über "linux_fs_start") vornehmen lassen (wenn man nicht gleich ein automatisches Fallback einbauen will, wenn die Box nach einem Update nicht starten will), auch ohne daß der Kunde irgendwie ein Gerät per Ethernet-Kabel verbinden muß - das ist einfach nicht mehr zeitgemäß und wird der neuen Wirklichkeit bei den "Endgeräten" schon lange nicht mehr gerecht. Hier lebt AVM einfach immer noch in der Vergangenheit ... daran ändert auch ein "responsive design" beim GUI nichts wirklich.
Andere Hersteller gehen inzwischen den umgekehrten Weg und bauen spezielle "Apps" für die Bedienung ihrer Router ... das neue "Norton Core"-Projekt zielt etwas in diese Richtung und da, wo ich vor wenigen Wochen noch als "verspäteter Aprilscherz" verdächtigt wurde (als es z.B. um weitere Anwendungen auf dem Router als zentrale Schnittstelle im Heimnetz ging - auch wenn das wirklich nicht ganz ernstgemeint war), da wurde ich mal wieder von der Realität überholt.
Das funktioniert aber eben auch nur, wenn die Geräte überhaupt starten/laufen ... wobei eben eine FRITZ!Box durchaus auch funktionieren kann, selbst wenn sie keine Internetverbindung aufbauen kann (wg. der neuen Firmware) und man dann zumindest noch den WLAN-Zugriff auf das GUI erhält. Aber seitdem AVM die Möglichkeiten zum Downgrade entfernt hat und das nicht durch die Möglichkeit zur Umschaltung auf die "vorhergehende Firmwareversion" ersetzt wurde, fehlt eben selbst bei funktionierendem (WLAN-)Zugriff auf das GUI dem Nutzer die Möglichkeit, irgendetwas zu bewirken.
Hier hat AVM nach meiner Überzeugung zwar Sicherheitslücken geschlossen (auch die Funktion mit dem Telefon (das natürlich kein SIP-Client sein darf, dann kann man sich das auch gleich komplett sparen, weil sich das genauso wieder automatisieren ließe) bzw. dem Drücken einer Taste an der Box für bestimmte Funktionen gehört ja in diesen Dunstkreis und als erster Schritt ist das sicherlich auch nicht zu verachten - wen es stört, der verzichtet halt auf diesen zusätzlichen Schutz ... für das Senden von Faxen sollte sich das aber ohnehin selektiv abschalten lassen - hatten wir aber auch alles schon), sich aber parallel dazu keinerlei (erkennbare) Gedanken gemacht, wie sich der Kunde bei anderen Problemen (in der heutigen Zeit, wo es eben nicht mehr "normal" ist, daß ein passender Windows-PC existiert) helfen soll.
Auch hier wäre eben die Möglichkeit der Umschaltung auf die vorhergehende Version (gestartet über das GUI, aber erst ausgeführt nach Drücken von Buttons am Gerät) machbar ... wobei ich die Bootloader-Lösung (auch wegen der zusätzlich denkbaren Absicherung gegen Angriffe) immer noch präferieren würde - aber auch parallele Möglichkeiten (die Bootloader-Version braucht sicherlich mehr "skills" auch beim Kunden) sind ja denkbar. Selbst ein neuer "Telefon-Code" für die Umschaltung auf die letzte Firmware (wenn sie noch so weit startet, daß diese Codes überhaupt funktionieren) wäre ja nun nicht so schwer zu realisieren ... aber die neuen Möglichkeiten mit der doppelt vorhandenen Firmware wurden bisher irgendwie noch nie so richtig "ausgereizt" von AVM.
Hat AVM bei den neuen Versionen (06.80-irgendwas) eigentlich den Schritt zu einer neuen OpenSSL-Version gewagt?
Die in den letzten zwei Jahren verwendete Version OpenSSL 1.0.1 ist ja seit dem Jahreswechsel "out of support" ... wenn die nächste Lücke bekannt wird, die sich auch auf MIPS/ARM/x86 (bei der 6490 wird eben für den NAS-Teil auch die - gewöhnlich besser "ausgeleuchtete", weil sich die meisten PoC eben auf x86-Code stützen - Version für x86 verwendet) auswirkt oder ausnutzen läßt, dann wird die derzeit immer noch präsente Version (1.0.1q vom 03.12.2015) zwar ohnehin ersetzt werden müssen, aber so eine "Notoperation" ist sicherlich nicht der geeignete Zeitpunkt für den Wechsel der OpenSSL-Basisversion - daher hege ich die (nicht überbordende) Hoffnung, daß AVM das mal rechtzeitig macht (es gab ja bereits einmal eine FRITZ!OS-Version, wo die verwendete OpenSSL-Version tatsächlich aktuell war - damals war sogar das OpenSSL-Update der letzte Schritt, der noch einmal eine neue Version des FRITZ!OS hervorbrachte) und - da ein modulares Update ja ohnehin derzeit nicht möglich ist, auch wenn AVM vielleicht irgendwann den Plugin-Mechanismus mal dafür "aufbohren" wird bzw. das machen könnte - wir für die 7490 mit einer FRITZ!OS-Version mit aktuellem OpenSSL rechnen dürfen.
Auch wenn sich die (noch eine Weile unterstützte) 1.0.2 und die 1.0.1 nicht allzu wesentlich voneinander unterscheiden (wobei es ohnehin noch sechs weitere "security advisories" seit der von AVM verwendeten 1.0.1q gab, auch wenn die nicht alle relevant für MIPS-Prozessoren und/oder die von AVM verwendete Konfiguration sein mögen), gerade bei den VPN-Funktionen wird m.W. immer noch auch DES (bzw. 3DES) mit kurzen Schlüsseln und/oder Blocklängen unterstützt (was man zwar ohnehin nicht verwenden sollte) und da ergaben sich nach dem Bekanntwerden von SWEET32 einige Änderungen am OpenSSL-Code (u.a. bei der "automatischen Wahl" von Verschlüsselungsalgorithmen), die ggf. (ich kenne natürlich die AVM-Quellen nicht und auch die von AVM verwendete Konfiguration bei der Übersetzung der OpenSSL-Quellen ist nicht veröffentlicht, weil die Lizenz es nicht erforderlich macht und AVM es ja nicht einmal für die Quellen gebacken bekommt, wo sie rechtlich dazu verpflichtet wären) auch Auswirkungen auf AVM-Code und dessen Funktion haben könnten und dann ist ein ggf. notwendiger schneller Fix für eine OpenSSL-Lücke sicherlich nicht die richtige Gelegenheit, um solche Abhängigkeiten dann (a) auszuschließen oder (b) gut zu testen, bevor man so eine Version als "erforderliches Update" freigibt und auf den Kundenboxen automatisch installiert.
Mit der Implementierung der "Autoupdate"-Funktionen hat AVM ja auch automatisch eine größere Verantwortung für die korrekte Funktion der Kundengeräte nach so einem automatischen Update übernommen und da gehören nun einmal umfangreiche Regressionstests (das sind Tests, daß eine neue Funktion bzw. eine Änderung nicht nur den gewünschten neuen Effekt erzielt, sondern daß davon auch keine bereits vorhandenen Funktionen in Mitleidenschaft gezogen werden) nicht mehr zur Kür, sondern nunmehr zum Pflichtprogramm.
Angesichts einiger aktueller Katastrophen (u.a. ungeklärter Phänomene beim unerwünschten Firmware-Update bei NOR-Boxen - konkret wohl nur der 7390) setzt sich bei mir irgendwie nicht der Eindruck durch, daß man sich bei AVM dieser neu übernommenen Verantwortung auch wirklich bewußt ist und nicht nach dem Motto "Wo gehobelt wird, da fallen Späne ..." einfach billigend in Kauf nimmt, daß es bei einem bestimmten (hoffentlich kleineren) Prozentsatz von Kunden dann eben Probleme geben wird.
Die (zumindest nach meinem Empfinden, das sich allerdings nicht auf eigene Anfragen stützt und nur auf aktuellen "Erfahrungen" von anderen Kunden beruht, die dann nach unbefriedigendem AVM-Ergebnis Kontakt mit mir aufnehmen) weiter nachlassende Qualität des Kundensupports (es hängt sicherlich auch immer davon ab, wen man "erwischt" als Bearbeiter des eigenen Anliegens - hier fehlt AVM nach meinem Dafürhalten eindeutig ein Bewertungssystem für den Kundensupport, wo der Kunde seinem "Unmut" dann Luft machen kann ohne große Schreiberei (die ohnehin niemand liest) und wo das "Ergebnis" direkt dem Mitarbeiter zugeordnet werden kann) ist nun nicht unbedingt ein Punkt, der eine zusätzliche Belastung des Kundensupports nahelegen sollte.
Man male sich nur einmal aus, was z.B. passieren würde, wenn eine der "automatisch" aktualisierten Versionen auf einmal an nur 10% der Internet-Anschlüsse keine stabile Verbindung mehr aufbauen kann und deren Eigentümer dann auf einmal vor der Aufgabe stehen, sich eine ältere Firmware erst einmal auf irgendeinem anderen Weg zu beschaffen (die eigene Internetverbindung geht ja dann nicht) und diese dann auch noch per Recovery-Programm zu installieren. Da, wo vor 2-3 Jahren vielleicht noch die Existenz eines PC mit der Möglichkeit einer Ethernet-Verbindung zur Box vorausgesetzt werden konnte, da hat sich die Landschaft der eingesetzten Geräte inzwischen komplett gewandelt und es gibt schon genug Haushalte, in denen nur noch WLAN-Clients (oder auch Computer ohne Windows - entweder mit OS X oder Linux) vorhanden sind (selbst viele "Laptops" haben heute ja keinen Ethernet-Port mehr) und wo die Verwendung des bisher von AVM ausschließlich bereitgestellten Windows-Programms für das Recovern die Benutzer vor ungeahnte Probleme stellen kann.
Selbst wenn so ein automatisches Update sich i.d.R. über eine Woche verteilen würde (das FRITZOS sucht in der Standardeinstellung m.W. nur alle 168 Stunden nach einer neuen Version, was bei einem wirklich drängenden Problem auch schon ein zweischneidiges Schwert ist) und man es vermutlich spätestens nach 24 Stunden wieder stoppen würde, wenn genug Beschwerden im Support eingehen ... stimmen die (überschlagenen) Zahlen von > 50% Anteil bei Breitband-Anschlüssen in D (> 30 Mio. (feste) Anschlüsse, Stand Q3/2016), sind das (gleichmäßige zeitliche Verteilung mal unterstellt) bereits > 2 Mio. Boxen innerhalb von 24 Stunden (30 Mio. * 50% / 7 Tage), die von der Freigabe so einer neuen Version als "Notfallupdate" betroffen wären (wobei ich die "Fehlerrate" ja nur bei 10% angesetzt habe und das sind dann nur noch 200.000 Anschlüsse/Kunden, die damit Probleme haben) und da ist das (zumindest in meinen Augen) dann der falsche Moment, wenn man sich "gezwungenermaßen" zu einer neuen OpenSSL-Version mit (zumindest denkbaren) "side effects" durchringen muß (um mal den Kreis beim Gedankengang wieder zu schließen).
Überhaupt finde ich das "automatische Update" (das ich - noch einmal sei auf die berichteten Merkwürdigkeiten bei der 7390 verwiesen - für ungenügend getestet halte) schon recht ambitioniert ... da sind schon ganz andere (und wesentlich größere/besser testende) Firmen wie Microsoft oder Apple heftig auf die Nase gefallen, wenn dann irgendwelche Computer nach so einem Update nicht mehr richtig starten wollten. Während man da aber immer noch eine funktionierende Internet-Verbindung und damit entsprechende Recherchemöglichkeiten zur Behebung hatte, bleibt am Ende bei einem Problem mit dem Router ja fast nur noch der telefonische Support - über Mobilfunk, der natürlich auch kein Recovery auf dem Router machen kann und das wäre dann (neben dem auslösenden Problem, das die Notwendigkeit so eines Updates hervorgerufen hatte) wohl der Super-GAU, der AVM passieren könnte.
Insofern ist das nicht "unmutig", sich so eine Möglichkeit überhaupt zu schaffen (wobei man ja spekulieren kann, ob sich AVM bisher noch nicht so richtig "traute", das Update auf 06.5x bei NAND-Modellen als "notwendig" zu kennzeichnen für 06.2x-06.3x-Verwender) ... aber man sollte sie eben auch im Vorfeld dann sehr gut testen (bei der 7390 gibt es ja nicht einmal den theoretischen Rückweg über den Bootloader zur vorhergehenden Version) und man sollte auch einem Plan B (für den heutigen(!) Kunden mit seiner "IT-Landschaft") in der Schublade haben.
Den Eindruck gewinne ich bei AVM nicht ... es gäbe so viele Möglichkeiten, wie man z.B. durch einen geänderten Bootloader bei den neueren Modellen (die ja fast alle NAND-basiert sind und "linux_fs_start" verwenden) entsprechende Vorsorge treffen könnte (bei der Gelegenheit könnte man auch viele derzeit noch mögliche Angriffe über den Bootloader gleich ebenfalls be- oder sogar verhindern), die auch den "normalen Kunden" nicht wirklich überfordern ... der wird ja wohl noch einen Button an der Box drücken können. Darüber könnte man schon den generellen Zugang zum FTP-Server (der ja für Recovery gebraucht wird) absichern und ggf. sogar die Umschaltung auf die vorherige Version (über "linux_fs_start") vornehmen lassen (wenn man nicht gleich ein automatisches Fallback einbauen will, wenn die Box nach einem Update nicht starten will), auch ohne daß der Kunde irgendwie ein Gerät per Ethernet-Kabel verbinden muß - das ist einfach nicht mehr zeitgemäß und wird der neuen Wirklichkeit bei den "Endgeräten" schon lange nicht mehr gerecht. Hier lebt AVM einfach immer noch in der Vergangenheit ... daran ändert auch ein "responsive design" beim GUI nichts wirklich.
Andere Hersteller gehen inzwischen den umgekehrten Weg und bauen spezielle "Apps" für die Bedienung ihrer Router ... das neue "Norton Core"-Projekt zielt etwas in diese Richtung und da, wo ich vor wenigen Wochen noch als "verspäteter Aprilscherz" verdächtigt wurde (als es z.B. um weitere Anwendungen auf dem Router als zentrale Schnittstelle im Heimnetz ging - auch wenn das wirklich nicht ganz ernstgemeint war), da wurde ich mal wieder von der Realität überholt.
Das funktioniert aber eben auch nur, wenn die Geräte überhaupt starten/laufen ... wobei eben eine FRITZ!Box durchaus auch funktionieren kann, selbst wenn sie keine Internetverbindung aufbauen kann (wg. der neuen Firmware) und man dann zumindest noch den WLAN-Zugriff auf das GUI erhält. Aber seitdem AVM die Möglichkeiten zum Downgrade entfernt hat und das nicht durch die Möglichkeit zur Umschaltung auf die "vorhergehende Firmwareversion" ersetzt wurde, fehlt eben selbst bei funktionierendem (WLAN-)Zugriff auf das GUI dem Nutzer die Möglichkeit, irgendetwas zu bewirken.
Hier hat AVM nach meiner Überzeugung zwar Sicherheitslücken geschlossen (auch die Funktion mit dem Telefon (das natürlich kein SIP-Client sein darf, dann kann man sich das auch gleich komplett sparen, weil sich das genauso wieder automatisieren ließe) bzw. dem Drücken einer Taste an der Box für bestimmte Funktionen gehört ja in diesen Dunstkreis und als erster Schritt ist das sicherlich auch nicht zu verachten - wen es stört, der verzichtet halt auf diesen zusätzlichen Schutz ... für das Senden von Faxen sollte sich das aber ohnehin selektiv abschalten lassen - hatten wir aber auch alles schon), sich aber parallel dazu keinerlei (erkennbare) Gedanken gemacht, wie sich der Kunde bei anderen Problemen (in der heutigen Zeit, wo es eben nicht mehr "normal" ist, daß ein passender Windows-PC existiert) helfen soll.
Auch hier wäre eben die Möglichkeit der Umschaltung auf die vorhergehende Version (gestartet über das GUI, aber erst ausgeführt nach Drücken von Buttons am Gerät) machbar ... wobei ich die Bootloader-Lösung (auch wegen der zusätzlich denkbaren Absicherung gegen Angriffe) immer noch präferieren würde - aber auch parallele Möglichkeiten (die Bootloader-Version braucht sicherlich mehr "skills" auch beim Kunden) sind ja denkbar. Selbst ein neuer "Telefon-Code" für die Umschaltung auf die letzte Firmware (wenn sie noch so weit startet, daß diese Codes überhaupt funktionieren) wäre ja nun nicht so schwer zu realisieren ... aber die neuen Möglichkeiten mit der doppelt vorhandenen Firmware wurden bisher irgendwie noch nie so richtig "ausgereizt" von AVM.
informerex
IPPF-Urgestein
- Mitglied seit
- 20 Apr 2005
- Beiträge
- 17,194
- Punkte für Reaktionen
- 61
- Punkte
- 48
schlag ich schon seit Jahren vor, ebenso wie AddOns, sprich ein Basis-System und der Kunde kann baukastenmäßig zusammenstellen/abwählen
was auch einer zeitgemäßen Software-Entwicklung entspricht
Der Support ist nicht das Problem sondern anscheinend die internen Strukturen, denn die Hotline hat kein/kaum Kontakt zu den Abteilungen - es wird nur weitergeleitet.
Somit fällt in der Regel die Bewertung positiv aus, da der Kunde ja davon ausgehen muss, es wird sich drum gekümmert.
Erschwerend kommt hinzu, dass in der Regel binnen weniger Tage die Rückfrage kommt, aber bspw. eine einfache Änderung im changelog ca. 4-6 Wochen benötigt und dies erst nach 2maliger "erneuter" Reklamation.
Aktuell ist es wirklich schwer, früher eine klare Firmen/Kauf-Empfehlung, heute nur "was willst den sonst nehmen"?
Hallo zusammen,
ich bin neu hier.
Gibt es einen Weg zurück (Downgrade) von der INTERN FW (7490.113.06.80-42651) zu aktueller Beta (06.69-42372 BETA) bzw. zur Final 06.60?
ich bin neu hier.
Gibt es einen Weg zurück (Downgrade) von der INTERN FW (7490.113.06.80-42651) zu aktueller Beta (06.69-42372 BETA) bzw. zur Final 06.60?
Blackace
Mitglied
- Mitglied seit
- 27 Aug 2008
- Beiträge
- 430
- Punkte für Reaktionen
- 54
- Punkte
- 28
koyaanisqatsi
IPPF-Urgestein
- Mitglied seit
- 24 Jan 2013
- Beiträge
- 14,210
- Punkte für Reaktionen
- 590
- Punkte
- 113
Moins
Da ich keine INTERN nutze/habe, hätt ich da 1,2 Fragen...
1. Habt ihr im Webinterface eine Entwicklerseite mit ShellInABox (SIAB) ?
2. Wenn ja, Screenshot , bitte bitte...
Da ich keine INTERN nutze/habe, hätt ich da 1,2 Fragen...
1. Habt ihr im Webinterface eine Entwicklerseite mit ShellInABox (SIAB) ?
2. Wenn ja, Screenshot , bitte bitte...
Zurück zur offiziellen BEta: Einfach das andere Image flashen und den Werksreset bestätigen.
Sauberer Weg wäre der Umweg über das offizielle Recovery, wobei aber auch die Einstellungen flötengehen.
Sauberer Weg wäre der Umweg über das offizielle Recovery, wobei aber auch die Einstellungen flötengehen.
bastiks1988
Mitglied
- Mitglied seit
- 24 Jan 2011
- Beiträge
- 343
- Punkte für Reaktionen
- 45
- Punkte
- 28
Danke für Deinen Hinweis.
Ich habe bisher nur Telnet benutzt und natürlich den "unschönen" Hinweis auf der Startseite, den ich wegrecovern müsste.
Geht SIAB auch ohne Telnet einzuschalten?
koyaanisqatsi
IPPF-Urgestein
- Mitglied seit
- 24 Jan 2013
- Beiträge
- 14,210
- Punkte für Reaktionen
- 590
- Punkte
- 113
Bezgl. der Meldung über Modifikationen bzw. Änderungen an der Box nach Benutzung von Telnet:
Es gibt dazu etliche Beiträge im Forum, die meisten empfehlen Recover. Wenn man über SIAB verfügt, geht's einfacher.
Einloggen über die Konsole (Anmeldepaßwort der Box), dann
Beim nächsten Aufruf der Benutzeroberfläche (Neu-Einloggen) ist die Meldung verschwunden - bis man sich wieder per Telnet anmeldet.
Auch diese Lösung wurde hier schon mehrfach beschrieben - leider bringt die SuFu nur Themen mit zig Seiten hervor und man kann aus der Suche heraus nicht gezielt den Beitrag aufrufen, in dem das Such-Stichwort (hier "clear_id") auftaucht ... es wird nur bei der Anzeige eines gefundenen Thema's hervorgehoben.
Es gibt dazu etliche Beiträge im Forum, die meisten empfehlen Recover. Wenn man über SIAB verfügt, geht's einfacher.
Einloggen über die Konsole (Anmeldepaßwort der Box), dann
Code:
echo "clear_id 87" > /proc/tffsBeim nächsten Aufruf der Benutzeroberfläche (Neu-Einloggen) ist die Meldung verschwunden - bis man sich wieder per Telnet anmeldet.
Auch diese Lösung wurde hier schon mehrfach beschrieben - leider bringt die SuFu nur Themen mit zig Seiten hervor und man kann aus der Suche heraus nicht gezielt den Beitrag aufrufen, in dem das Such-Stichwort (hier "clear_id") auftaucht ... es wird nur bei der Anzeige eines gefundenen Thema's hervorgehoben.
Neueste Beiträge
-
Mesh System- schlechter Empfang
- Letzte: Mastapeace
-
[Sammlung] AVM-Gateway-kompatible Zigbee-Geräte- Letzte: alexandi
-
Fritzbox nicht unter IPv6 erreichbar
- Letzte: starbright
-
Rufumleitung Agfeo per Keypad im Amt möglich?
- Letzte: slemke
-
DECT Repeater mit POE für die FB- Letzte: chrsto
-
FRITZ!Box 7590 / FRITZ!OS 8.00 vom 31.10.2024- Letzte: stoney