Ärgernis KabelBW (2/3): Das unzuverlässige ISDN-Modem und die FRITZ!Box 6360

Im zweiten Teil der „Doku“ (zum ersten Teil) geht es um das mittlerweile nicht mehr ausgelieferte ISDN-Modem von Siemens und dessen Nachfolger, der FRITZ!Box Cable 6360.

Störungsmeldungen werden nicht richtig ernst genommen

Mit dem Siemens-Modem stand ich schon eine ganze Weile auf dem Kriegsfuß. Immer wieder kam es zu Ausfällen beim Telefonieren oder auch beim Internet. Die Ausfälle beim Telefonieren waren dabei die weitaus häufigeren. Die Crux daran: Man bekam selten mit, dass das Telefon ausgefallen war. Sofern man selbst nicht telefonierte, kam es u.U. vor, dass man etliche Stunden für Anrufer nicht erreichbar war.

Um das Problem zu beheben, gab es nur ein probates Mittel: Netzstecker ziehen. Ein Anruf bei der Störungsstelle von KabelBW ergab immer das selbe: Eine Störung kann nicht erkannt werden, man sieht lediglich, dass sich das Modem irgendwann abgemeldet hat (genau dann, als ich den Netzstecker gezogen hab). Ich solle das ganze beobachten. Gesagt, getan, immer wieder Störungsmeldungen abgesetzt, immer wieder die Antwort bekommen, dass keine erkannt werden kann und immer wieder den Status der LEDs durchgegeben (was blinkt, welche Farbe) und daraufhin immer keine oder keine aussagekräftige Antwort bekommen.

So ging das ca. 20 mal in einem Jahr. Nicht immer hab ich eine Störungsmeldung abgesetzt, das wird einem ja zu blöd, schließlich weiß man ja, was dabei rauskommt: nix! Im Nachhinein hätte ich vielleicht öfter nerven sollen, aber einem ist die Zeit da auch einfach zu schade.

Der ersehnte Modemtausch – erste Vorboten

Dann, vor ca. einem Monat, wieder ein Ausfall. Seit der letzten Störungsmeldung war wieder etwas Zeit ins Land gegangen, also setzt ich wieder eine ab. Wieder die selbe Rückmeldung und die Nachfrage, wie der Status der LEDs ist. Ich also wieder brav geantwortet und noch den Hinweis gegeben, dass das nun zum 20. Mal auftritt und man doch bitte dem Problem auf den Grund gehen soll. Erhofft hab ich mir davon jedoch nichts. Die Erfahrung hatte anderes gelehrt.

Doch ich wurde überrascht. Vier Tage später bekam ich ein Anruf von einem Techniker. Ob denn wirklich wie beschrieben die LEDs VoIP/B1/B2 blinkten. Ich bejahte und dann war die Sache auch schon geklärt. Das Modem hat wohl irgendeine Macke, die immer wieder zum Ausfall führt und daher muss das Modem nun getauscht werden. Aha, auf einmal geht’s doch!

Kurz darauf rief dann schon die Installationsfirma an und ich bekam eine neue FRITZ!Box Cable 6360. Ein nettes Upgrade im Vergleich zum alten Modem. Mit AVM hab ich auch bisher gute Erfahrungen gemacht. Das kann ja nur gut werden, dachte ich mir. Kaum war die FritzBox angestöpselt, hieß es erst mal etliche Minuten warten, bis das neueste Firmware-Update durchgelaufen war. Das dauerte alles ca. 15 Minuten und danach durfte ich dann auch gleich testen, ob das Telefon tut – was es natürlich nicht tat. Wie immer vermutet man zuerst das Problem beim Endgerät des Kunden. Mit der Frage „Davor hat’s schon funktioniert, oder?“ bin ich auch schon vertraut.

Es stellte sich heraus, dass es – welch Wunder – nicht an meinem Gigaset lag, sondern am Firmware-Update, das nicht richtig draufgespielt war. Schuld daran waren laut KabelBW natürlich Installateur bzw. Kunde, die das Update nicht haben durchlaufen lassen. Ganz klar, wie gut das Installateur bzw. Kunde der FritzBox 15 Minuten beim Blinken zugesehen haben und während dieser Zeit absolut nichts gemacht haben. Ein erneuter Updatelauf brachte dann das gewünschte Ergebnis und das Telefon ging.

Warum soll auch mal irgendwas reibungslos klappen?

Da die FritzBox WLAN und DECT integriert hat, hatte ich die Hoffnung, meine Gigaset Basis-Station und mein WLAN-Router einzumotten. Ersteres funktionierte nicht, da auf den Mobilteilen der Anrufer nicht mehr angezeigt wird, sondern nur noch dessen Nummer (obwohl im Telefonbuch des Mobilteils). Das WLAN der FritzBox zu nutzen sollte 08/15 sein, so dachte ich.

Die Einrichtung klappte auch wunderbar und schnell (wie gewohnt). Doch WLAN selbst, war alles andere als gewohnt, nämlich langsam, dauernde Verbindungsabbrüche etc. Surfen mit 1 Mbit anstatt 25 Mbit und instabile WLAN-Verbindung waren die Folge. Eine Recherche im Netz ergab, dass auch andere dieses Problem haben. Eine Parade-Lösung gab’s nicht, also bei KabelBW angerufen (eine Mail an den Kundenservice wurde mal wieder nicht beantwortet). Die kennen zwar das Problem, aber da die FritzBox von AVM ist, müsse man sich an die wenden. KabelBW supportet nur die Modem-Komponente. Bei AVM bin ich dann mehr oder weniger zufällig in den FAQ auf die Lösung gestoßen. Seitdem ich die Verbindung auf 54 Mbit respektive 802.11g-Standard gedrosselt habe, ist das WLAN wieder schön schnell (eben bis max. 54 Mbit).

Resümee oder was mich an dieser Geschichte so immens ärgert

Zum einen die Zeit, die KabelBW braucht, um ein Problem ernst zu nehmen. Warum muss ich als Kunde andauernd Störungsmeldungen abgeben und ein ganzes Jahr lang mit Ausfällen leben, bevor sich da mal was tut? Und warum vergeht von Störungsmeldung bis Problemlösung über eine Woche? Warum ruft der Techniker nicht gleich bei mir an und erfragt den Status der Modem-LEDs, wenn er das nach einer erneuten E-Mail doch sowieso nochmal macht?

Zum zweiten: Wenn ich ein neues Gerät wie die FritzBox ausliefere, dann vergewissere ich mich doch, ob da alles funktioniert. Wenn man sich Forenberichte durchliest, was da bisher schon alles gelaufen ist, fragt man sich echt, ob es denn sein muss, dass der Kunde als Beta-Tester fungiert. Auch die Sache mit dem WLAN. Wenn das bekannt ist, dann frag ich doch bei AVM nach, was das Problem macht und ob es eine temporäre Lösung gibt. Wenn dann der Kunde bei mir anruft, verweise ich gleich auf die FAQ und gebe meinen Installateuren den Hinweis, dass es mit dem WLAN Probleme gibt. Diese können das dann gleich präventiv an den Kunden weitergeben. Das ist Service, liebe KabelBW!

An seiten AVM geht ein ähnlicher Appell: Wenn doch gehäuft Probleme auftreten, dann verstecke ich das nicht tief in den FAQ, sondern platziere die Lösung prägnant.

RT2870 under (K)Ubuntu Natty (11.04)

The new version of (K)Ubuntu, Natty (11.04), is shipped with the new Kernel 2.6.38 but still with the old wireless driver for the RT2870. If one does not want low speed on data transfers, the driver for the RT2870 has to be compiled manually, but that does not work without compilation errors. To solve this issue follow the steps for the previous version Maverick, which I described in my article „RT2870 compile error under (K)Ubuntu Maverick (10.10)“.

RT2870 unter (K)Ubuntu Natty (11.04)

Die neueste Version von (K)Ubuntu, Natty (11.04),  bringt trotz des neuen Kernels 2.6.38 nur den alten RT2870 Wireless-Treiber mit. Wer nicht mit angezogener Handbremse Daten über’s WLAN senden will, der muss auch unter Natty den Treiber für den RT2870 manuell kompilieren, was ohne Fehler aber nicht funktioniert. Abhilfe schafft auch hier die Vorgehensweise für die Vorgängerversion Maverick, wie ich in meinem Artikel [intlink id=“40″ type=“post“]“RT2870-Kompilierungsfehler unter (K)Ubuntu Maverick (10.10)“[/intlink] beschrieben hab.

RT2870-Kompilierungsfehler unter (K)Ubuntu Maverick (10.10)

Gestern wurde die neue Version der beliebten Linux-Distribution veröffentlicht. Mit im Gepäck der Kernel 2.6.35. Wer wie ich im Besitz eines WLAN-Sticks mit dem RT2870-Chipsatz ist, stellt das erst mal vor Probleme. Ich nutze nicht den mitgelieferten Treiber rt2870sta, da dieser meine WLAN-Übertragung von 130 MBit/s auf 54 MBit/s drosselt.

Abhilfe schafft da den aktuellsten Ralink-Treiber zu kompilieren, was aber mit dem neuen Kernel 2.6.35 zu folgendem Fehler führt:

CC [M]  2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../common/cmm_mac_usb.o
2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../common/cmm_mac_usb.c: In function ‘RTMPAllocUsbBulkBufStruct’:
2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../common/cmm_mac_usb.c:52: error: implicit declaration of function ‘usb_buffer_alloc’
2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../common/cmm_mac_usb.c:52: warning: assignment makes pointer from integer without a cast
2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../common/cmm_mac_usb.c: In function ‘RTMPFreeUsbBulkBufStruct’:
2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../common/cmm_mac_usb.c:78: error: implicit declaration of function ‘usb_buffer_free’
2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../common/cmm_mac_usb.c: In function ‘RTMPFreeTxRxRingMemory’:
make[2]: *** [2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux/../../common/cmm_mac_usb.o] Fehler 1
make[1]: *** [_module_2010_0709_RT2870_Linux_STA_v2.4.0.1/os/linux] Fehler 2
make[1]: Verlasse Verzeichnis '/usr/src/linux-headers-2.6.35-22-generic'
make: *** [LINUX] Fehler 2

Schuld daran ist der Rückgriff auf die Funktionen usb_buffer_alloc() und usb_buffer_free(). Diese wurden umbenannt, was sich auch der Changelog des Kernels entnehmen lässt:

    USB: rename usb_buffer_alloc() and usb_buffer_free() users

    For more clearance what the functions actually do,

      usb_buffer_alloc() is renamed to usb_alloc_coherent()
      usb_buffer_free()  is renamed to usb_free_coherent()

Alles was man also tun muss ist die entsprechenden Funktionen in der include/os/rt_linux.h umzubenennen. Einen entsprechenden Patch könnt ihr hier runterladen. Einfach folgendes Kommando im Treiberverzeichnis ausführen:

patch -ul -p0 -i pfad/zur/patchdatei

Oder bequem per Einzeiler:

wget -qO- http://www.linuxcrew.de/wp-content/uploads/2010/10/rt2870sta_usb_kernel2635.patch | patch -ul -p0

Danach lässt sich der Treiber wieder problemlos kompilieren.