FRITZ!Box 7490 Labor-Firmware Version 113.06.25-30584 vom 01.06.2015

Hallo,
@PeterPawn:
Mal so völlig OT und ganz bewusst: :) :mrgreen: :groesste: :groesste: :meinemei:
Für die Energie, die Du in die Analysen und Deine Postings steckst :D
 
Also VDSL Treiber keine Änderung?
 
Die 29er fw hat die 133.21. ist nun die fortlaufende Nummer neuer oder die höhere?
 
Hallo,
Was hindert Dich an einem Test?
Einstellungen sichern, Recovern und neu einrichten.
 
edit: gelöscht. Fehlinformation
 
Zuletzt bearbeitet:
Klingt ganz nach einer interessanten Version. Mal schauen, was die endgültige Version hergibt.
 
Vielleicht ist das ja der Grund für die alte neue Labor:
Mit sehr hoher Wahrscheinlichkeit ist das nicht der Fall. Die dort (wohl von einem Honeypot generiert) beschriebene Lücke ist die altbekannte "webcm"-Schwachstelle aus dem Januar 2014.

Diese Lücke ist in aktueller Firmware (ebenfalls mit hoher Wahrscheinlichkeit, denn absolute Sicherheit gibt es nicht) bereits gefixt. Wenn noch irgendjemand mit alter - und damit verwundbarer - Firmware auf seiner FRITZ!Box unterwegs ist, ist er selbst schuld und hat es in meinen Augen nicht anders verdient. Inzwischen sind tatsächlich funktionierende gefixte Versionen schon seit langer Zeit verfügbar.

Also bitte keine Panik schüren ... das ist mit der o.a. Wahrscheinlichkeit nicht der Anlaß für diese Version, es sei denn, AVM hätte einen sehr häßlichen Fehler (in der Versionsverwaltung der CS-Quellen) für eine der Vorgängerversionen gehabt. Ob das der Fall ist, kann jeder für seine eigene FRITZ!Box mit dem Test der c't (http://www.heise.de/security/dienste/portscan/test/go.shtml?scanart=1) prüfen, dabei "Routertests->Fritzbox" auswählen (AVM dürfte ob dieser Schreibweise bei heise.de auch im Grabe rotieren).
 
Zuletzt bearbeitet:
Ich wollte keine Panik schüren.
Das galt auch weniger Dir, war etwas unglücklich formuliert von mir.

Ich wollte nur verhindern, daß jetzt die Anfragen "Oh Gott, eine neue Lücke ... wie kann ich mich schützen außer "Stecker ziehen"?" los gehen.

Die Meldung stammt - läßt sich ja verfolgen - von einem Hersteller von Web Application Firewalls und wurde auf der Basis eines "Angriffs" auf einen "Honeypot" (also ein System, was sich als "verwundbar" ausgibt und ein leichtes Ziel darstellen soll) lanciert. Schon die abschließende Bemerkung in dem Blog-Beitrag
https://www.trustwave.com/Resources/SpiderLabs-Blog/-Honeypot-Alert--Fritz!Box-%E2%80%93-Remote-Command-Execution-Exploit-Attempt/ schrieb:
Trustwave WAF and ModSecurity can both identify and block these types of attacks.
dürfte eine gewisse Intention der Meldung nahelegen. Warum da nach > 15 Monaten so ein Angriff als "neu" verkauft wird, kann ich mir auch nur begrenzt erklären. Vielleicht weil jetzt die Details für den CVE-Record ergänzt wurden? Dazu kann man sich beim NIST die "history" der Änderungen ansehen.

Wenn das tatsächlich der erste Angriff dieser Art auf den Honeypot gewesen sein sollte, dürfte der nur begrenzt tauglich sein für seine Aufgaben ... inzwischen sind diese Wellen ja schon fast wieder komplett abgeklungen.

EDIT: Das, was ich zum CVE-Eintrag geschrieben habe, ist sogar kompletter Unsinn. Ich habe mich von der CVE-Nummer (CVE-2014-9727) irritieren lassen. Der komplette Eintrag ist offenbar vom 01.06.2015 ... das macht es dann tatsächlich noch um einiges merkwürdiger, warum da seitens trustwave.com keine Hinweise auf "solutions" mit aufgenommen wurden.
 
Zuletzt bearbeitet:
SF1975 schrieb:
also, IMHO ist AVM noch nicht tot, oder?
Erstens fiel mir keine bessere Metapher ein und zweitens ist Koma ja ähnlich, oder? Es könnte allerdings auch Schockstarre sein ... oder nur "busy with work"?

Aber in Wirklichkeit habe ich tatsächlich die Hoffnung, daß AVM inzwischen (15 Monate nach "webcm"-Gate) tatsächlich bei der Sicherheit der Firmware echte Schritte nach vorne machen will (die Angriffe auf Router im Allgemeinen mehren sich ja auch, irgendwann muß es auch AVM mal wieder erwischen, wenn man sich nicht kümmert) und letztlich bin ich jetzt nur noch gespannt, wie weit man da tatsächlich gehen wird. Irgendwann wird es sicherlich wieder einen "großen Wurf" geben bei der Firmware, die relativ lange Ruhephase bei der "regulären Laborversion" deutet hoffentlich nicht darauf hin, daß bei AVM niemand mehr arbeitet. Und wenn jetzt vor dem Erscheinen einer neuen Oberfläche tatsächlich erst einmal "unter der Haube" aufgeräumt und modernisiert wird, kann das auch nur gut sein.

Solange AVM keine "Live-Updates" ermöglicht (also den Austausch einzelner Pakete gegen aktualisierte Versionen), ist so ein Release-Zyklus immer verdammt lang und solche Aktionen wie am Anfang des vorherigen Jahres kann man auch nicht ständig machen.

Eigentlich hat AVM ja mit dem selbst gebauten Plugin-Mechanismus tatsächlich schon ein Werkzeug zur Verfügung, mit dem man (notfalls über den USB-Slot bei Boxen ohne internen Speicher) auch Sicherheitsupdates so nachinstallieren könnte, daß man die Zeit zwischen zwei Releases (das ist ja immer so ca. 1 Jahr) damit überbrücken kann. Aber das erfordert eben eine ziemlich gründliche "Renovierung" des zugrunde liegenden Systems - ob AVM das tatsächlich vor der nächsten Katastrophe freiwillig macht (oder ob es nicht sogar intern solche "Studien" bereits gibt und es nur ein Abwägen zwischen Aufwand und potentiellem Schaden ist, was die Überführung solcher PoCs in die reguläre Firmware verhindert), weiß nun mal nur AVM alleine.

Wenn ein "richtiges" Firmware-Update ein zu großer Aufwand für das Fixen einer aktuellen Lücke wäre, dann könnte man wenigstens mit "Plugin-Paketen" solche Fixes nachschieben. Das OpenSSL "verharrt" z.B. bei der 7490 auch bei dieser Version weiterhin auf der Version 1.0.1h, die ist jetzt 1 Jahr alt und enthält mind. 4 Releases mit Security-Fixes noch nicht, angefangen bei der "downgrade attack" auf SSLv3, von der weiterhin vorhandenen RC4-Unterstützung ganz zu schweigen.

So ein "Plugin-Update" hat dann auch noch den Vorteil, daß man es bei doch irgendwo auftretenden Inkompatibilitäten relativ leicht wieder zurückziehen kann, wenn man einen Mechanismus zur Aktualisierung einer solchen Paketliste implementiert.

Wenn AVM selbst beim aktuellen Flaggschiff nur so "lazy" mit Security-Fixes bei der TLS-Unterstützung umgeht (und wo sollte man das testen, wenn nicht in den Labor-Versionen), dann mache ich mir aber auch weiterhin "Sorgen" und hoffe mal, daß das nur ein "Ausrutscher" ist. Ich glaube jedenfalls nicht daran, daß da seitens AVM irgendwelche Backports von Security-Fixes auf 1.0.1h vorgenommen werden (ein SSL-Test des Webservers fördert auch entsprechende Probleme zutage), denn es ist garantiert einfacher, da auf eine aktuelle 1.0.1-Version zu setzen.

Es schlagen auch immer zwei Herzen in meiner Brust (auch das ist nicht wörtlich zu nehmen, ich habe keine solche anatomische Abweichung) ... einerseits braucht es für den Normalnutzer eine wirklich sichere Firmware, in die auch ein Angreifer aus dem LAN nicht eindringen kann und andererseits will ich selbst als "Bastler" weiterhin (m)einen Zugang auch für Erweiterung der Möglichkeiten haben.

Das ist vielleicht ein Spagat ... aber die FRITZ!Boxen verdanken einen guten Teil ihrer Beliebtheit ja auch dem Wirken von "Multiplikatoren", die sich an der Erweiterbarkeit der Boxen erfreuen.

Da AVM wegen der Lizenzrechte vermutlich nie eine Firmware mit OpenVPN auf den Markt bringen wird, ist z.B. auch das ein wichtiger Punkt für viele "Homeoffice"-Benutzer, wenn die Hauptniederlassung nur über ein OpenVPN-Gateway zu erreichen ist und da nicht tatsächlich mehrere Verbindungen für einen "Benutzer" betrieben werden sollen (Smartphone, Tablet, PC ... was der "Home-Worker" so bei sich daheim herumstehen/-liegen hat). Die VPN-Frage (da hinkt AVM eben mit dem eigenen VPN und "nur" IKEv1 hinterher) ist jedenfalls nach meiner Erfahrung die am häufigsten benötigte "Erweiterung" bei Kunden. Erst danach kommt dann die Implementierung eines "Heartbeat"-Services zur Überwachung von FRITZ!Boxen mit Nagios/Icinga ... das wäre mal ein Wunsch von mir für "neue Features", daß man eine Einstellung für den Abruf einer HTTP-Seite in festzulegenden Intervallen in der FRITZ!Box vornehmen kann.
 
Zuletzt bearbeitet:
Jaaaa, Einen AVM-Paketmanager bei dem ich Services de- und dazuinstallieren kann je nach Anforderung.
In meinem speziellen Fall eben eine dt. FB mit alternativen span. UI aber ohne italienisch oder englisch etc.
Der fehlende Rufnummernsuffix bei der internat. FW lässt mich bei der dt. FW bleiben und ich bin der einzige der dort dann konfigurieren kann (was aber auch seine gaaanz grossen Vorteile hat, ich stell mir grad vor meine bessere Hälfte ....)
 
Jaaaa, Einen AVM-Paketmanager
als ich das mal vor geraumer Zeit vorgeschlagen hatte, wurde ich belächelt.
ein modularer Aufbau würde jedoch viele Probleme beseitigen, wie man ja bei iOS/Android (Windows "neu") sieht.

ein minimalistisches OS, welches modular erweitert werden kann. Beispielsweise
manche User benötigen doch grundsätzlich kein AB und Fax, div. (kleine) Boxen hab jedoch hardwareseitig Probleme (Prozessor/Speicher) - also warum nicht entfernen bzw. schon garnicht installieren
Treiber - an div. Anschlüssen laufen die alten viel besser, an manchen die neuen, nur die erhält man ja nicht, da aktuell nur im kompletten FW-"bundle" erhältlich
DSL-/VoiP-Anbieter - manche User kennen sich mit den Details nicht aus, diese ändern sich im Laufe der Zeit, weltweit gibt es aber viele, die zu berücksichtigen sind - also warum nicht wie bei Gigaset, just-in-time die Daten vom Server abrufen oder per Button aktualisieren lassen
aber auch Google Play/UI/T-Online-APIs aktuell laufen die ja noch, nur wie lange, wenn man die Google-Telefonbuch-Problematik aktuell sieht.
warum kann bspw. kein Mircosoft/Outlook-Anbindung oder gar "Apple Music"-API nachgeladen
selbst eine Sprachassistenten wie Siri, Google Now, Cortana oder hound könnten nachgerüstet werden - warum geht es bei Handy/PC usw. jedoch nicht beim Festnetz? ... obwohl Internet+API (Service) vorhanden, ist ja nicht so dass dies von der Basis her neu entwickelt werden müsste

AVM wollte mit FRITZ!OS eine "bessere Plattform" schaffen und ist auf der Hälfte des Weges stehen geblieben bzw. befindet sich in der jetzigen Form sogar in einer Sackgasse, insbesondere wenn sich der Veränderungs-Zyklus noch beschleunigt.
 
Um noch einmal meinen Senf dazu abzulassen: Ich wollte keinen Paket-Manager bei AVM anregen.

(Bei Freetz ist das wieder etwas anderes, da hätte ich tatsächlich konkrete Vorstellungen, die aber in der Umsetzung Zeit und entsprechende Mitstreiter bräuchten.)

Die diversen Abhängigkeiten/Seiteneffekte bei Vorhandensein oder auch bei Nichtvorhandensein diverser Komponenten in der AVM-Firmware sind viel zu unübersichtlich, als das so ein Management tatsächlich sauber zu machen wäre ... zumindest bei der derzeitigen Umsetzung seitens AVM.

Da wurde eben im Laufe der Zeit immer wieder mal etwas "angebaut" und (ich vermute mal aus Performancegründen, denn eine FRITZ!Box ist nun mal kein Device mit wahnsinnig viel überschüssiger Leistungsreserve) dabei auch so mancher "kurze Dienstweg" zwischen Komponenten gewählt, der eine saubere Trennung unmöglich macht. Das kann man alles auch ohne Kenntnis der CS-Quellen von AVM schon aus den Verflechtungen von Binaries und Libraries schließen und teilweise auch schon beobachten, wenn man nur auf der eigenen Box Dienste stoppt, die man eigentlich nicht benötigt. Schon das Beenden (oder "Nichtstarten") des AHA-Daemons (weil man schlicht keine entsprechende Peripherie hat) führt zu permanentem "Quängeln" des Webservers, weil der irgendwelche Werte vom AHA-Daemon abrufen will und den dann nicht findet.

Das ist ja auch ein Problem, was sich bei den "remove patches" von Freetz schnell manifestiert, da funktionieren inzwischen auch diverse dieser Patches in aktueller Firmware nicht mehr reibungslos.

Daß AVM da das komplette System umbaut für eine saubere Trennung in einzelne Komponenten, kann man meines Erachtens getrost vergessen. Das, was sich jetzt schon (bzw. eher noch) über die CONFIG-Variablen der Firmware sauber "abschalten" läßt, kann man auch einzeln entfernen, aber eben - nach meiner Erfahrung - nur aus den laufenden Prozessen und eher nicht aus dem Filesystem.

Man sollte auch nur immer eine größere Baustelle gleichzeitig betreiben (solange die Anzahl der MA relativ konstant ist) und ich hoffe mal, das ist bei AVM jetzt der Punkt der Sicherheit. Zwar würde sicherlich auch dabei ein Redesign an einigen Stellen und die Kommunikation der Komponenten nur noch über exakt definierte Schnittstellen hilfreich sein, aber das ist ja auch ein Punkt, an dem AVM immer mal wieder "werkelt". Man sieht immer wieder Stellen, wo Funktionen aus einem Binary in eine Bibliothek wandern und damit zwangsläufig eine definierte Schnittstelle dahin entsteht. Auch die Nachnutzung solcher Bibliotheken durch andere Komponenten trägt sicherlich zu einer besser wartbaren Codebasis bei, wenn man keine doppelten Funktionen warten muß. Auch im lesbaren Teil der Firmware (das ist ja in erster Linie das LUA-Interface) wird immer mehr modularisiert und anstelle von mehrfachem identischem Code auf Objekte für die Lösung einer speziellen Aufgabe umgestellt. Davon kann sich jeder selbst überzeugen, inzwischen ist die Lua-"Bibliothek" unter /usr/www/$OEM/lua schon auf eine beachtliche Größe angewachsen.

Also: Im Gegensatz zu anderen würde ich definitiv nicht um einen Paket-Manager von AVM bitten (das traue ich dieser Firma beim derzeitigen Stand des FRITZ!OS - soweit wir ihn in der Öffentlichkeit kennen - nicht zu und ich würde an dieser Stelle mehr Probleme als Lösungen erwarten), ich meinte tatsächlich nur einen Update-Mechanismus, der für ein schnelleres Rollout von Sicherheitsfixes sorgen soll.

Das "Paketmanagement" dabei soll sich ausschließlich darauf konzentrieren, solche Updates zu verteilen und ggf. auch wieder zurückzuziehen, wenn sich doch irgendwelche Inkompatibilitäten ergeben, die den Betrieb mit dem Update behindern. Die Einflußmöglichkeiten des Benutzers würde ich dabei tatsächlich auf die generelle Entscheidung, ob solche "differential updates" verwendet werden sollen oder nicht, beschränken ... alles andere (inkl. der Auswahl, welche Updates verwendet werden sollen) bringt wieder Abhängigkeiten mit sich (wenn Update B unbedingt auch Update A benötigt), die schnell unübersichtlich - und damit fehlerträchtig und nachteilig für die Stabilität - werden.

Ein komplett modular aufgebautes FRITZ!OS wäre zwar tatsächlich "ein Traum" und würde auch viele Vorbehalte bei Puristen (die der Meinung sind, auf einem Router hat ein NAS eben nichts zu suchen) abbauen können, aber das wäre sicherlich eine Aufgabe, bei der das Controlling von AVM im Dreieck springt, denn der Nutzen eines solchen Redesigns ist - nach meiner Erfahrung mit solchen "Entscheidungsträgern" - auf den ersten Blick nicht sichtbar und kurzfristig ergeben sich daraus eben ausschließlich Belastungen, auf die man ja auch verzichten könnte, denn es läuft ja noch. Anders als die ganzen "personal gadgets" ist eine FRITZ!Box auch kein Gerät, das der gemeine Nutzer mit sich herumschleppt und auch mal schnell gegen ein neueres Modell austauscht ... und so sollte man sich lieber wünschen, daß AVM mal bei neueren Modellen auch einen mutigen Schritt wagt und ein neues FRITZ!OS auflegt, das die o.a. Kriterien erfüllen kann. Dem "auf halbem Weg stehen geblieben" würde ich in weiten Teilen zustimmen ... ich würde mal raten wollen, daß das halt in Angriff genommen wurde und dann stellte man fest, daß es mit der vorhandenen Manpower eben doch nicht so einfach ist, alles gleichzeitig zu stemmen. Das würde sich jedenfalls mit eigenen Erfahrungen in anderen - ähnlichen - Situationen decken.

Einen "Umbau" des bestehenden Systems halte ich persönlich jedenfalls auch nicht für sinnvoll (und teilweise auch für aussichtslos) ... solange bei AVM für irgendwelche Probleme bereits Lösungen vorhanden sind, die dann an anderer Stelle (auch wenn sie nicht 100% passen) immer wieder nachgenutzt werden (ein nachvollziehbarer Reflex, der aber eben auch alten Code und alte Lösungen zementiert), solange wird ein "FRITZ!OS 10" (in Anlehnung an ein anderes - demnächst erscheinendes - System) eher ein Traum bleiben.

Ein (für mich) (un)schönes Beispiel für solch ein Vorgehen ist z.B. die Verschlüsselung von "sichtbaren" Werten und von Kennwörtern mit genau demselben Code, was dann dazu führt, daß man nur den verschlüsselten Text zwischen zwei solchen Werten austauschen muß, um wieder auf den Klartext eines Kennworts zugreifen zu können und damit die eigentlich getroffenen Vorsichtsmaßnahmen - die vier Sterne werden ja auch intern verwendet zur "Darstellung" verschlüsselter Kennwörter - auszuhebeln.

Ein weiteres Beispiel ist ein (von der grundsätzlichen Funktion her schon sehr altes) Binary aus dem GUI (firmwarecfg), das auch als "Sammelbecken" für viele verschiedene Funktionen dient und so - neben dem Im- und Export von kompletten Konfigurationen oder auch nur VPN-Einstellungen und vielem mehr - eben auch für die Überprüfung der Signatur von AVM-Paketen zuständig ist (eigentlich ja eine klassische Aufgabe für eine "shared library") und somit von allen möglichen anderen Komponenten über interne Pipes (popen/pclose, system und auch einigen Skripten) auch dafür aufgerufen wird. So etwas in ein Binary zu packen, das auch über das GUI (über den Pfad /cgi-bin/firmwarecfg) aufgerufen werden kann, ist schon gefährlich, wenn man nicht tatsächlich bei jeder Änderung an diesem Binary auch berücksichtigt, daß beim CGI-Aufruf auch mal absichtlich sehr falsche Parameter übergeben werden könnten. Ich möchte eigentlich den Quellcode dieses Binaries lieber nicht sehen ... ich würde - rein von außen und mit Kenntnis anderer (offener) Quellen - erwarten, daß dort Übersichtlichkeit eher kein Punkt beim Design war und das ist für ein GUI-Modul eben i.d.R. "tödlich". Da kommen dann zwei oder drei neue Funktionen noch dazu und am Ende ist das nur noch ein Graus, was da - im schlechtesten Falle auch noch von mehreren unabhängigen Leuten - als Ergebnis produziert wurde. Das funktioniert dann häufig zwar auch wie erwartet, sieht aber eher wie die Elektroverkabelung (oder die Telefonleitungen) in einer "Dritte Welt"-Stadt aus, wo man sich auch immer wieder wundert, daß so etwas tatsächlich läuft - und da dann nach Fehlern zu suchen (das webcm-Binary ist (war?) derselbe "Aufrufmechanismus", auch wenn das wesentlich weniger "Funktionalität" abbilden muß(te)) ist eine Mammutaufgabe.
 
Sicherheit in allen Ehren, nur soviel passierte bisher auch nicht.

Viel wichtiger ist doch, dass die "Firmware-Statik" bröckelt und man hier dringend einen Turbo einschalten müsste.
Sieht man nämlich den Gesamtmarkt Telefonie, insbesondere im Hinblick auf die Smartphones, deren Nutzungsmöglichkeiten, die immer attraktiveren Preise und dem geänderten Nutzungsverhalten (dauernde Erreichbarkeit), so bekommen die herkömmlichen Geräte immer weniger Bedeutung, zumal deren Komfort/Ausstattung (im Vergleich zu Smartp.) minimalistisch ist. (viele sagen doch schon heute, egal in welche Altersklasse - ich hab doch garkein Telefon [Festnetz] mehr bzw. benutzte es nicht)

Parallel ist der Markt im Smartphone/PC/Tab.-Bereich aktuell nur Verdrängung, was auch die Vorstellung der letzten Wochen beweist (waren doch zum gähnen bezogen auf die Hardware).
Dh. es wird teilweise nachgezogen (wie bei Apple Musik - letzter nach Drittanbieter, Google, Amazon) usw. und muss nächstes/übernächstes Jahr ein "Knaller" kommen, nämlich evtl. die weitere Smarthome V2-Stufe, verbunden mit stylischen Endgeräten.
usw usw.
... ach und die Berliner Jungs werden geschluckt oder verschwinden sodann in der Versenkung, weil so halt der Markt ist - ein bisschen Makeup macht kein Supermodel.

aber wie (kommen) sind OFF-Topic, da es in dem T. ja um die reine FW geht
 
Auch wenn es OT ist ... wir sind uns sicherlich einig, daß AVM schon lange in der Versenkung verschwunden wäre (der Markt wird eben auch über Preis/Leistung erobert), wenn die Deals mit den Providern nicht wären.

Sowie da ein Wettbewerber kommt, der für einen wesentlich attraktiveren Preis (da ist ja vermutlich bei der UVP-Empfehlung für den Einzelhandel ein satte Marge auch für AVM dabei, die tatsächlichen Kosten für die Großabnehmer dürften wesentlich darunter liegen) bei den Providern auch nur annähernd denselben Support (das geht dann bei der deutschsprachigen Kommunikation los, wenn es der Provider mal im eigenen Support nicht regeln kann) anbietet, gerät AVM automatisch unter Druck.

Ich kann mir gut vorstellen, daß dort bei den diversen Ankündigungen von ähnlich leistungsfähigen Geräten schon mal Unruhe aufkommt und man sich so seine eigenen Gedanken zur Weiterentwicklung der Produktpalette macht. Ob das dann immer auf Anhieb mit den neuen Produkten klappt (siehe die ersten DECT-Gehversuche oder die DVB-C-Repeater, um die es auch eher still geworden ist, was einerseits an reibungsloser Funktion oder andererseits an zu geringer Verbreitung liegen kann), steht wieder auf einem anderen Blatt ... ebenso die tatsächlichen Fähigkeiten eines potentiellen Mitbewerbers, hier hat AVM den Vorteil, das schon unter Beweis gestellt zu haben.

Wenn man sich die offizielle Angabe der Beschäftigtenzahl bei AVM ansieht (500 in 2014 lt. der Webseite), dann dürfte sich wenigstens die Hälfte davon im Support - von RMA-Handling bis zum Telefon-/E-Mail-Support - tummeln (reine Schätzung/Vermutung/Spekulation meinerseits, durch nichts belegt, damit da kein Mißverständnis aufkommt) ... ob da auch "studentische Hilfskräfte" dann in größerem Umfang dabei sind und ob/wie die gezählt werden, geht aus den veröffentlichten Zahlen ja nicht klar hervor, ist häufig aber auch Usus, wenn man eine imposante Mitarbeiterzahl nennen will.

Wenn man sich aber mal die Namen einiger Mitarbeiter aus der Firmware zusammensucht, dürfte das Entwicklungsteam (zumindest der harte Kern, der schon länger dabei ist) noch überschaubar sein und wohl kaum die Personalstärke einer beliebigen Mannschaft in der Fußball-Bundesliga erreichen und das meint nur die Spieler ... mit "Betreuerstab" käme man vielleicht auf dieselbe Zahl, wenn man alles an "Entwicklern" (vom PCB-Design über GUI-Design bis zum Handbuch-Entwurf) zusammen zählt. Die Produktion macht AVM meines Wissens ja auch nicht selbst, das war zumindest mal zu einem großen Teil RAFI und damit wären diese Angestellten wohl auch in den 500 genannten nicht enthalten. Dann noch die "übliche" Verwaltung (von Assistent(inn)en bis zu HR und Lohnbuchhaltung) und ich würde alles in allem die Zahl der Leute bei AVM, die schon einmal eine Zeile Code geschrieben haben, auf max. 75 Leute schätzen. Davon dann die üblichen 80% Effektivität bei der Arbeit (es gibt ja Krankheit, Urlaub, Fortbildung, Meetings, usw. - da sind 80% schon optimistisch) und man hat am Ende gar nicht mehr soviel Manpower für die (gesamte !) Entwicklung zur Verfügung, wie es die stattliche Anzahl von 500 Mitarbeitern vermuten lassen würde. Wie gesagt, alles nur theoretische Überlegungen auf der Basis "üblicher" Firmen und warum das bei AVM (mit einem ja - für Endkunden/Providerkunden - nicht zu leugnenden Support, der auch gut bei den Leuten ankommt) anders sein sollte, fiele mir jetzt nicht ein.

Die Leute, die hier im IPPF von schlechten Erfahrungen mit dem Support berichten, sind ja deutlich in der Minderheit, das darf man auch nicht vergessen. Wenn die verbreiteten Zahlen stimmen, stammt immerhin der Internet-Router in mind. jedem zweiten Haushalt mit DSL-Anschluß in Deutschland von AVM (lt. Statistischem Bundesamt hat D 40 Mio. Haushalte) und das sind dann selbst bei vorsichtiger Schätzung (die BNetzA spricht für 2013 von >23 Mio. DSL-Anschlüssen) deutlich oberhalb von 10 Mio. Geräten alleine in D. Wenn davon dann 10.000 Kunden unzufrieden sind, ist das immer noch ein einziges Promille ... auch wenn für einen engagierten Hersteller natürlich jeder unzufriedene Kunde einer zuviel sein sollte, aber es gibt definitiv auch Leute, denen man es ohnehin niemals recht machen kann.

Da ist selbst die aktive "Gemeinde" von FRITZ!Box-Kunden/-Nutzern, die an einer Erweiterung der eigenen Box arbeiten oder überhaupt daran interessiert sind (das sind - behaupte ich mal - auch nicht viel mehr als dieses eine Promille), auch nur der berühmte "Tropfen auf dem heißen Stein" und es würde mich tatsächlich nicht allzu sehr verwundern, wenn AVM auch auf diese Gemeinde am Ende "pfeift", wenn eine Abwägung zwischen dem eigenen Ruf (noch so eine Aktion wie Anfang 2014 braucht bei AVM bestimmt keiner) und dem Interesse einer kleinen Anzahl von Kunden an einer "zugänglichen FRITZ!Box" zu treffen ist. Ich lasse mich jedenfalls überraschen ...
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.