Fragen? Antworten! Siehe auch: Alternativlos
Aber keine Sorge. TP-Link hat einen Patch zur Verfügung gestellt.
Die sind echt Helden der Arbeit, denn der betroffene Router ist End of Life (abgekündigt, Support eingestellt).
Wartet. Geht noch weiter. Die Sicherheitslücke ist ewig alt (von 2014).
Ja gut, denkt ihr euch jetzt. Der Router muss dann halt auch steinalt sein.
Nein. Der ist vom Juli 2022. Was ist das denn bitte für eine bodenlose Frechheit!? Die sind bei mir direkt auf der schwarzen Liste gelandet. Ich kauf doch nicht von Firmen, die nur ein halbes Jahr Support für brandneue Produkte anbieten! (via) (Danke, Johannes)
Klar, die Telcos möchten gerne Supportkosten sparen, indem sie möglichst jedem dasselbe Gerät geben.
Aber ab und zu gibt es dann halt eine Plasterouterapokalypse: Aktuell in Geräten von Buffalo und Arcadyan. Unter anderem in Deutschland verbaut als Speedport Smart 3 bei der Telekom, und als Easybox bei Vodafone.
Der Einsender schreibt:
Diverse Vodafone Easyboxen sowie Speedport Smart 3 (Standard-Router bei der Deutschen Telekom) und viele weitere Provider-Router bei KPN, British Telecom, Verizon etc. haben derzeit ein bisschen (Remote) Authentication Bypass. Also z.B. Zugang auf die Konfig-Dateien der Router und auf die dort enthaltenen Credentials (SIP, PPP-Logindaten usw.)Das klingt jetzt nicht so schlimm, aber mit deinen Credentials kann sich dein Nachbar als du anmelden und Telefonate für dich annehmen. Oder über deinen Anschluss Bittorrent anwerfen und du kriegst dann die Post von den Abmahnkanzleien. (Danke, Jakob)Bei vielen OEM-Modellen ist der Punkt derzeit ungepatcht, aber gleichzeitig eben auch öffentlich.
Weil heutzutage aus Legacy-Gründen alle hinter einem NAT-Plasterouter hängen, hat croc da noch eine Relay-Infrastruktur in der Cloud.
Update: Link entfernt, weil die Site Fefe-Lesern einen Stylesheet untergeschoben hat. Nein, das ist kein Bug, dass man bei mir externe Stylesheets setzen kann. (Danke, Veit)
Der Cloudflare-Timeout gestern? Das war mein Aprilscherz.
Aber das Niveau an Paranoia unter meinen Lesern empfinde ich in diesen schweren Zeiten als sehr positiv. :-)
Und keine Sorge. Ich habe keinen von euch tatsächlich zu Cloudflare geschickt, auch nicht für Ressourcen auf der Timeout-Seite.
MIPS Technologies ist 1984 als Stanford-Ausgliederung entstanden, und MIPS geht auf die Arbeit des legendären John Hennessy zurück, der mit "Computer Architecture, A Quantitative Approach" eines der bis heute wichtigsten Standardwerke geschrieben hat, zusammen mit seinem Kollegen David Patterson von Berkeley, wo SPARC herkommt, ein anderer Pionier unter den RISC-Architekturen.
1992 hat Silicon Graphics dann MIPS übernommen, aber sich dann kurz vor der Jahrtausendwende für den Wechsel auf Intels "Itanic" IA-64 entschieden und ist damit endgültig baden gegangen. MIPS wurde dann von Imagination Tech gekauft, die eigentlich für ihre ranzigen "PowerVR" 3d-Chips bekannt waren. Imagination wurde dann von chinesischen Investoren übernommen, die haben den Laden dann aufgespalten und an andere Heuschrecken verhökert. Dabei ging MIPS an einen Laden namens Wave Computing, die Venture-Kapital sammelt, um damit "KI-Beschleuniger" (heiseres Lachen) herzustellen. Die gingen dann pleite und jetzt haben sie ihre Umstrukturierung offenbar überlebt und wollen sich umfirmieren und unter dem Namen MIPS weitermachen *augenroll*
Wie das halt häufig so ist im Tech-Umfeld. Alte Tech stirbt nicht, sie wird weiterverhökert. Myspace und Winamp gibt es ja auch noch.
Schon schade um MIPS. Die waren mal eine echte Legende unter den Architekturen. Aber gegen Intel kamen sie halt alle nicht an, die so viel Kohle im Massenmarkt eingesackt haben, dass sie damit auch ihre eigentlich minderwertige Architektur konkurrenzfähig halten konnten.
Hier ist die Pressemitteilung von Wave Computing, mit diesem zentralen Satz, der eigentlich alles sagt, was es da zu sagen gibt:
MIPS is developing a new industry-leading standards-based 8th generation architecture, which will be based on the open source RISC-V processor standard.Davor war ihre Ansage, sie würden Deep Learning revolutionieren.Lief wohl nicht so gut.
Wenn ihr es nicht wisst, aber einen Plasterouter einsetzt, dann ist die Antwort wahrscheinlich: Ja.
Sie haben ein Remote Code Execution-Bug gefunden, im DNSSEC-Codepfad.
Kurze Erklärung, wie Netflix funktioniert. Die stellen ihre Video-Server bei eurem ISP auf. Wenn ihr Netflix guckt, dann kommt das nicht von Übersee, im Allgemeinen nicht mal von jenseits des DE-CIX, sondern aus dem fucking Netz eures fucking ISPs. Die einzige Infrastruktur, die da also überlastet sein könnte, wäre die des ISP. Und wisst ihr, was passiert, wenn Netzinfrastruktur überlastet ist? Dann werden Pakete gedroppt. Und wisst ihr, wer das sofort merkt? Euer Client. Und der holt sich dann automatisch die nächstkleinere Auflösung, weil er annimmt, DASS DIE FUCKING INFRASTRUKTUR ÜBERLASTET IST.
Noch nicht überzeugt? Euer ISP kann selbstredend auch Traffic künstlich runterpriorisieren. Das nennt sich Traffic Shaping. Einfach Netflix und Youtube runterdrehen. Wisst ihr, woran ihr erkennt, dass sie das machen? tagesschau.de flutscht noch, aber euer Youtube ruckelt. Oder noch besser: Gar nichts ruckelt.
Es gab hier keinen Handlungsbedarf. Die EU hat Netflix kaputtgemacht.
Im Übrigen sei der Hinweis erlaubt, dass Netflix einer der technisch besten Streaming-Anbieter ist, wenn es um schonende Bandbreitennutzung geht. Amazon streamt z.B. deutlich verschwenderischer. Daran könnt ihr sehen, dass es hier nicht um die Sache ging, sondern ein EU-Fuzzy wollte gerne beim Handeln gesehen werden. Leadership!!1!
Update: Nach Netflix jetzt auch Youtube. Für die gilt alles oben gesagte ebenfalls.
Update: Kurze Anmerkung noch dazu: Auch wenn die Netzneutralitätsleute das nicht gerne hören: Traffic Shaping ist ganz normal. Geht mal davon aus, dass euer Internet auch Traffic Shaping macht. Und zwar nicht nur euer ISP, auch euer Plasterouter. Denn wenn der Plasterouter das nicht machen würde, dann würde bei euch bei jedem Upload gar nichts mehr gehen. Verbindungen sind im Internet paketbasiert. Wenn du was downloadest, schickt dir die Gegenseite immer ein großes Paket mit dem nächsten Datenhappen, und dann schickst du der Gegenseite ein kleines "ist angekommen"-Paket. Weil die Internetprovider kapitalistische Schweinebacken sind, haben sie euer DSL genau so ausgelegt, dass vom Internet zu euch hin die Bandbreite dick ist, und von euch zum Internet hin ist sie dünn. So dünn, dass es genau reicht, um für einen die Leitung auslastenden Speed-Test alle "ist angekommen"-Pakete rauszuschicken. Warum erzähle ich das? Ohne Traffic Shaping würde ein Upload euer Internet komplett zum Erliegen bringen, weil die kleinen "ist angekommen"-Pakete nicht mehr oder nur stark verspätet rausgehen würden. Daher machen alle Plasterouter Traffic Shaping und priorisieren die "ist angekommen"-Pakete. Die heißen übrigens ACK.
Trafficpriorisierung funktioniert in der Praxis gerne so, dass lange Bulk-Verbindungen (Downloads, Backups) die kleinste Priorität kriegen, dann Streaming-Dienste, dann Videokonferenzen und Fernwartung, dann DNS und interaktive Dienste wie SSH und die höchste Priorität haben ACKs.
Wer sich für die Details interessiert, wie man sowas unter Linux selbst konfiguriert: Die Referenzdokumentation von Bert Hubert.
Update: Dieser Angriff betrifft die Server-Seite im pppd, d.h. eher die Access-Konzentratoren bei den ISPs. Außer euer Router hat einen VPN-Modus, bei dem er mehr als Client ist.
Update: Ilja schreibt mir gerade:
So it affects the server and client. Both eap_request() and eap_response() are vulnerable (and have the exact same bug). Further more, there is no check to see if you’ve actually configured eap and are using eap prior to hitting the parser. So even if it’s not configured, you’re still vulnerable. Oh, and it’s pre-auth.
Es trifft also doch alle eure Plasterouter. UND die Access-Konzentratoren. Und man kann es ausnutzen, ohne einen gültigen Account zu haben, und ohne dass EAP konfiguriert sein muss. Das ist der perfekte Sturm.
Oh und wenn euer Unix pppd setuid root installiert hat, ist das auch eine local privilege escalation.
Ich glaube ja, dass POWER tot ist. Diese Initiative richtet sich ja auch gar nicht auf Server sondern auf sowas wie Plasterouter oder so FPGA-Frickelkram. Und da ist der Zug auch abgefahren, seit es RISC-V gibt.
Technisch gesehen ist der Instruction Set von POWER auch eher warzig und historisch gewachsen. Wieso IBM glaubt, das würde jemand haben wollen, erschließt sich mir nicht. MIPS ist ja auch schon Open Source gegangen Ende letzten Jahres. Das hat ja auch nicht zu einer MIPS-Renaissance geführt.
Drittens: Die Hersteller der Geräte bauen ihre Software alle ohne -fPIE, ohne -fstack-protector und ohne RELRO. Über Stack Protector und RELRO kann man unter Umständen verhandeln, weil die eine Abwägung beinhalten. Aber PIE sollte echt immer an sein, da gibt es keine Ausreden.
Wer sich jetzt denkt, hey, die haben da bestimmt schwarze Magie angewendet, um diese Messungen durchzuführen! Für den habe ich gute Nachrichten: Es gibt da ein einfaches Tool für und hier gibt es eine knappe Erklärung, was die einzelnen Teile bedeuten.
Update: Hier gibt es eine noch gewartete Version von checksec.sh.
Und Fließtext dann:
sagte BSI-Präsident Arne SchönbohmIs nich wahr!1!! Den kenn ich doch!
Der von Brancheninsidern als „Cyberclown“ verspottete Schönbohm liefert keinerlei Indikation für technische ExpertiseHach komm, Fefe, seit wann braucht man technische Expertise, um sich als Experte bezeichnen zu lassen?
Na siehste. Wie immer. Wie Arsch auf Eimer.
Update: Weiter unten im Artikel, habt ihr hoffentlich alle gesehen:
Jedoch müssten die Kunden IT-Sicherheit einfordern, sagte Schönbohm.
Das sagt der, der gerade verhindert hat, dass die eingeforderten sicheren Plasterouter stattfinden. (Danke, Markus)
Und da haben sie sich echt ins Zeug gelegt! Also gut, eher in die Jauchegrube.
Das Normenwerk sei "ein erster Schritt" für die Anwender, betont das BSI darin. Es handle sich um ein Instrument, auf dessen Basis "der Stand der Technik" fortgeschrieben und Router sicherheitstechnisch weiterentwickelt werden könnten.Ach so! Die wollten gar nichts verbessern. Die wollten bloß den beschissenen Zustand beschreiben! Damit … es besser werden könne. Von alleine, versteht sich. Schade eigentlich, dass wir keine Behörde haben, die sich um sowas kümmert. Oder zuständig wäre.
In der Richtlinie "einen bestimmten Zeitraum festzuschreiben, in dem die Hersteller Sicherheitsupdates bereitstellen müssen, erzeugt nicht automatisch mehr IT-Sicherheit", heißt es in Bonn. Es sei sinnvoller, wenn die Gerätefabrikanten diese Spanne "dynamisch kommunizieren" könnten, statt sich frühzeitig "zu Lasten der Kunden" auf eine Periode festzulegen.In welchem Paralleluniversum leben die denn da eigentlich? In einem, offensichtlich, in dem Hersteller eh schon 20 Jahre Support liefern, und wenn das BSI jetzt 5 Jahre fordert, dann gehen dem armen gebeutelten Kunden die anderen Supportjahre verloren!1!!
Zu Lasten der Kunden. Ich leg mich flach.
Die von den Hackern ins Spiel gebrachte Option, alternative freie Firmware wie OpenWrt auf den Netzwerkgeräten installieren zu können, bietet nach Ansicht der Behörde "keinen pauschalen Sicherheitsgewinn".Nee, nur in 99,9% der Fälle. Aber hey, liebes BSI, daher war das ja auch als "das muss gehen" formuliert, nicht als "die müssen das damit ausliefern". Der eine hypothetische, bisher noch nicht wissenschaftlich dokumentierte Fall, in dem ein Hersteller eine Firmware ausliefert, die besser als openwrt ist, in dem hat der CCC nicht vorgeschlagen, dass da openwrt rübergeprügelt werden muss.
Unabhängig davon könne alternative Software genutzt werden, nachdem sie vom Hersteller bestätigt worden sei.Und wieder so ein absurder Konjunktiv. Wenn die Hersteller das täten, hätte der CCC das gar nicht als Forderung formulieren müssen!
Wenn ihr jetzt "nein" antworten wolltet, dann irrt ihr wahrscheinlich. Das ist in einer Menge Plasterouter verbaut. Drei davon sind Remote Code Execution.
Update: Und in WLAN-APs, UMTS-Sticks und Android.
Die FTC hatte D-Link verklagt, weil die so unsichere Plasterouter ausgeliefert hatten. Die FTC als Regulierungsbehörde fand, dass das negative Auswirkungen haben sollte, die weiter gehen als "wir machen mal nen Patch, den wir dann shippen, wenn er halt fertig ist, und den könnt ihr euch auf eigene Kosten runterladen und aufspielen".
Das hat nicht geklappt. Damit leben wir jetzt ganz offiziell in einer Welt, in der es keine negativen Auswirkungen hat, unsicheren Elektroschrott auszuliefern.
JA SUPER!
Die Liste der Probleme ist einmal alles:
Bei den Lücken handelt es sich unter anderem um Hintertürzugänge mit fest eingestellten Passwörtern, zu laxen Datei-Rechten, auf dem Gerät unsicher gespeicherten Passwörtern und einem DHCP-Client, über den Angreifer eigene Befehle mit Admin-Rechten ausführen können. Außerdem überprüfen die Geräte Firmware-Updates nicht oder nur ungenügendJa super! Von so einer Qualitätsfirma will man doch Qualitätsprodukte kaufen!1!!
udp.c in the Linux kernel before 4.5 allows remote attackers to execute arbitrary code via UDP traffic that triggers an unsafe second checksum calculation during execution of a recv system call with the MSG_PEEK flag.Das klingt jetzt schlimmer als es ist, denn MSG_PEEK wird selten benutzt, UDP wird selten benutzt, und MSG_PEEK bei UDP wird noch seltener benutzt. Mir ist persönlich kein Fall bekannt.Ich habe dieses Flag in meiner Laufbahn 1-2 Mal benutzt. Man nimmt es, wenn man von einem Socket ein paar Bytes lesen will, ohne die zu lesen (d.h. wenn man danach nochmal read aufruft, kriegt man die Bytes wieder). Ich benutze das in gatling, um zu sehen, ob Daten auf einer SSL-Verbindung wirklich wie ein SSL-Handshake aussehen — allerdings auf einem TCP-Socket.
Kurz gesagt: Ich mache mir da jetzt keine großen Sorgen. Die DNS-Implementationen von glibc, dietlibc und djb benutzen jedenfalls nicht MSG_PEEK, und wenn es um UDP geht, ist DNS der übliche Verdächtige.
Ich will das nicht kleinreden, das ist ein ganz übler Bug und die sollten sich was schämen. Aber es ist kein "OMG die NSA hat mich gehackt, ich reinstalliere und mache alle Keys neu"-Bug. Außer ihr fahrt auf eurem Server irgendwelche UDP-basierten Protokolle.
Update: Im OpenVPN-Code findet grep auch kein MSG_PEEK. VPN und VoIP wären die anderen in Frage kommenden Codebasen.
Update: Ein paar Leser haben bei Debian und Gentoo mal ein bisschen rumgesucht und fanden als potentiell verwundbare Pakete dnsmasq und VNC-Implementationen. dnsmasq läuft praktische allen Plasteroutern. Das wäre in der Tat potentiell katastrophal.
Update: Einsender weisen darauf hin, dass systemd angeblich MSG_PEEK benutzt, und dass möglicherweise noch Chrome in Frage kommt als Angriffspunkt, wegen QUIC.
Welche ARM- (oder von mir aus auch MIPS oder PowerPC) Kleingeräte gibt es für wenig Geld zu kaufen, bei denen man dann einen Standard-Kernel selber bauen kann, und der funktioniert auch?
Das andere Gerät, bei dem ich in dieses Problem lief, ist ein Plasterouter, auf dem ich mal ein DD-WRT installieren wollte zum Testen, und da gab es nur eine Version von 2008 oder so, und neuere Kernel gehen nicht. Ja, äh, dann kann ich auch gleich Windows nehmen, wenn ich da keinen eigenen Kernel drauftun kann!
Ich empfinde es als zutiefst unseriös, ein Gerät als "da läuft Linux drauf" zu bewerben, auf dem dann nur ein spezifischer Gammelkernel läuft.
Auch auf Android-Smartphones scheint das ein massives Problem zu sein, wie ich aus zweiter Hand hörte. Sobald da mal was anbootet, ist das halt der Kernel für das Gerät und es wird nur noch das Userland außenrum geupdated, und vielleicht im krassen Notfall mal ein Security-Patch für den Kernel rückportiert.
Das kann doch nicht wahr sein? Ist das wirklich so?!
Update: Einsender empfehlen:
Ein anderer Einsender meint zu Allwinner noch:
ist dein RPI-Clone zufälligerweise ein Allwinner-Gerät? Das sind die beliebtesten China-SoCs. Sie sind ein wunderbares Beispiel für das Problem des "Code Vomittings". Die GPL zwingt Hersteller dazu, Code zu veröffentlichen? Wunderbar, erzeugen wir halt einen Code-Drop auf Github. Es gibt mit linux-sunxi.org eine Seite, auf der der Status für den Support im Upstream-Kernel sowie im eigenen "Fork" dokumentiert sein sollte. Die Situation ist nicht die beste, könnte aber schlimmer sein...
Update: Ein anderer Einsender meint:
the Allwinner ARM Chips do not belong on pole position. Too many critical missing features. A lot has changed in Kernel 4.11 but far from complete especially for the recent Allwinner ARM chips. too much red and WIP...
RaspberryPi is better supported and now also with mainline 64bit Kernel on RPi3.
https://michaelfranzl.com/2016/10/31/raspberry-pi-debian-stretch/
https://github.com/michaelfranzl/rpi23-gen-image
https://michaelfranzl.com/2017/03/21/zero-client-boot-kernel-root-filesystem-network-raspberry-pi2-pi3/
Haben sie euren Telefonanschluss auf IP umgestellt? Und ihr fragt euch jetzt, wieso altbekannte und beliebte Dienstmerkmale wie Anklopfen, Makeln, Rückfragen oder Dreierkonferenz nicht gehen?
Nein, nicht eure Fritzbox ist schuld. Das hat die Telekom noch nicht implementiert.
"Och komm, Timotheus, ditt rolln wa aus! Das merken die NIE!!1!"
Und das merken wahrscheinlich viele tatsächlich nicht, denn die Speedport-Plasterouter emulieren das halt auf Clientseite, wo es geht (bei Makeln und Konferenz).
Update: Aus einigen alten Forenbeiträgen geht hervor, dass das schonmal implementiert war. Vielleicht haben sie das bei einer der krassen Infrastrukturapokalypsen ausgeschaltet? (Danke, Tobias)
Jetzt gibt es gerade wieder so einen Fall. Die Plasterouter, die von den Herstellern keine Security-Updates kriegen, weil die Hersteller doof sind und nach Lulu riechen lieber ihren Profit als die Sicherheit ihrer Kunden maximieren. Da haben auch alle möglichen Experten gemeckert, aber ich sehe das inzwischen als positiv an, wenn man irgendwo überhaupt noch plausible deniability hat. Denn Freiheit definiert sich am Ende als der Raum, in dem wir Dinge tun können, die nicht uns attribuierbar sind. Der Raum, in dem wir noch unerkannt bleiben können. Unsere Gesellschaft hat sich von der Technologie und den Security-Fetischisten vor den Karren spannen und durchs Dorf ziehen lassen, so dass jetzt dank Überwachungskameras und anfallenden Daten von Mobiltelefonen und Kreditkarten praktisch das gesamte Leben nachvollziehbar ist. Damit sind wir das Verbrechen nicht losgeworden, auch das Sicherheitsgefühl hat meiner Beobachtung nach nicht zugenommen. Wir sind nur immer weniger frei geworden.
Jetzt gab es gerade einen Fall, wo jemand von den "Rechteinhabern" eines Hollywood-Films verfolgt wurde, und der hat dem Richter erklärt, er vermute, dass sich jemand über eine Sicherheitslücke in seinem Plasterouter Zugang zu seinem Internetzugang beschafft haben könnte, und der habe dann auch so diese fiese Raubmordkopiererei durchgeführt.
Und überraschenderweise fand der Richter: Stimmt, das diese Möglichkeit müsse vom Rechteinhaber hinreichend widerlegt werden, und das sei nicht geschehen, daher … Filesharing-Klage abgeschmettert.
Es liegt natürlich die Vermutung nahe, dass da nur ein Richter in Notwehr die Prozesslast durch die Contentmafia einschränken wollte, und dann ein "suchen Sie sich mal ein anderes Gericht für ihre lächerlichen Gängelklagen" gepullt hat. Aber so als Fanal der Hoffnung ist das schon sehr schön. Ich für meinen Teil hoffe, dass sich ab jetzt weniger Leute beklagen, dass ihre Plasterouter nicht updatebar sind.
Das ist der erste große Breitband-Internet-Anbieter, der so offen die Netzneutralität verletzt. Insofern ist der Beißreflex jetzt natürlich, da voll gegenzukloppen. Ich bin da Kunde und daher "Betroffener".
Leider ist die Sache nicht so einfach, wer da jetzt der Gute ist. Ich will mal ein paar Details auflisten. Erstens drosselt KDG schon immer. Ich habe auf dem Papier 32 MBit Downstream. Tagsüber habe ich um die 2 MB/sec Downloadrate, nachts um die 4 MB/sec. Ich finde auch 2 MB/sec in Ordnung, bei der Telekom hab ich in Stoßzeiten noch deutlich weniger als die Hälfte der Bandbreite gesehen.
Zweitens ruckelt Youtube bei KDG nicht. Das war für mich eine völlig neue Erfahrung. Da war bei der Telekom nicht dran zu denken. Das ging gar nicht. Wenn das Shaping der Preis dafür ist, dass Dienste wie Youtube nicht ruckeln, bin ich das zu zahlen bereit.
Ich habe mich vorhin mit ein paar Kumpels darüber unterhalten. Da kamen dann ein paar Argumente, die ich spannend finde. Erstens: Das ist ein Shared Medium, da muss man shapen. Zweitens: sollen sie doch shapen, aber dann sollen sie auch ungeshaped Internet anbieten.
Ich finde beide Argumente falsch. Erstens weil alle Internetzugangstechnologien ein Shared Medium sind. Auch DSL wird massiv überbucht. Mir als Kunde ist das wurscht, ob die Daten nicht bei mir ankommen, weil das letzte oder das vorletzte Stück Leitung überlastet ist. Das Argument "aber das ist ein shared medium" kann ich nicht gelten lassen.
Das Argument "aber dann sollen sie bitte auch ungeshaped anbieten" klingt sinnvoll. Aber mal auf den Tisch mit den Fakten. Wenn man in großen Kontingenten Traffic einkauft, kommt man für 100 MBit nicht auf 30 Euro pro Monat, eher so 150, mit Kosten für die Infrastruktur und Wartung des Providers sagen wir mal 200. Gut, sagt jetzt vielleicht der eine oder andere, das wäre ich zu zahlen bereit. Aber wäre nicht das erst die eigentliche Netzneutralitätsverletzung? Der Grund, warum wir Netzneutralität haben wollen, ist doch gerade weil wir so ein zweigleisiges Modell vermeiden wollen, bei dem die Reichen gutes Internet haben und beim Rest ruckelt Youtube. Insofern finde ich das akzeptabler, wenn es kein Premium-Angebot ohne Ruckeln gibt, denn auf der feinen Linie zwischen Qualitätsmaximierung und Profitmaximierung nimmt das Premiumangebot allen Zweifel, dass es um Letzteres geht.
Ich finde die Netzneutralitätsdebatte im Übrigen generell ziemlich verlogen. Erstens ist Traffic Shaping gut und wird von fast allen gemacht, ob sie es wissen oder nicht. Eure Plasterouter priorisieren wahrscheinlich Voip vor Downloads, wenn sie nicht noch aus dem letzten Jahrtausend sind. Und das will man ja auch so haben, weil Internet anders völlig unerträglich ist. Und dieses "aber aber dann müssen die ja DPI machen und DPI ist böse!1!!" ist auch verlogen, denn man kann das natürlich auch ohne DPI machen, indem man ein paar gute Ports whitelistet und den Rest shaped. Dann funktioniert es aber weniger gut und das ist am Ende im Sinne von niemandem, weder dem Kunden noch dem Provider. Wir als Kunden wollen, dass das Internet nicht ruckelt, und der Weg dahin heißt Traffic Shaping und QOS. Das kann man nicht einfach verbieten und gut ist.
Die einzige andere Möglichkeit ist, wenn man den Providern gesetzlich vorschreibt, dass sie die Bandbreite nicht überverkaufen dürfen. Könnte man drüber reden, aber überlegt euch mal, wie die Welt dann aussieht. Dann haben wir wieder 1 MBit Internetanbindungen. Und um Anfeindungen wegen Netzneutralitätsverletzung aus dem Wege zu gehen würden die Provider dann immer noch shapen, aber halt in die andere Richtung — keiner darf dann mehr gutes Internet kriegen, wenn Kapazitäten frei sind, sondern dann muss das auch für den einzigen aktiven Teilnehmer schmerzen und ruckeln.
Fakt ist: 32 MBit Internet zuhause ist nicht real. Das geht nur, wenn man mehr Bandbreite verkauft als man hat. Und das ist ja nicht nur bei Internet üblich, sondern auch bei Flugzeugen und der Bahn. Und wenn dann mehr Leute zugfahren als Sitzplätze da sind, dann müssen die eben stehen, und beim Flugzeug können die dann halt nicht mitfliegen und die Fluglinie hat ein Problem und muss Gutscheine verteilen. Auch unsere Straßen und das Telefonnetz sind nicht darauf ausgelegt, dass sie alle zur gleichen Zeit benutzen. Denen verbietet das ja auch keiner. Von Banken mal ganz zu schweigen, die verleihen ja auch mehr Geld als sie Einlagen haben.
Ich glaube daher, Netzneutralität ist die falsche Baustelle. Das wirkliche Problem ist, wenn Provider ihre Netze nicht ausbauen. Da kann man aus meiner Sicht Kabel Deutschland gerade vergleichsweise wenig Vorwürfe machen. Mein Vorschlag wäre daher, nicht die Netzneutralität festzuschreiben, sondern andersherum:
Ich persönlich finde auch das Shaping tagsüber auf die Hälfte im Grunde auch akzeptabel. Das ist der Preis, den ich dafür zahle, dass ich für 30 Euro dickes Internet kriege. Aber man kann auch das Gegenteil argumentieren: Sollen sie lieber mehr Bandbreite ranschaffen und die Kosten auf die Kunden umlegen. Wem das zu teuer ist, der kann ja zum alten Preis das halbe Internet nehmen. Was wir eigentlich erreichen wollen ist ja, dass die Leute sich grob auf die Bandbreitenangaben ihres Providers verlassen können.
Update: Das sollte jetzt kein Manifest zur Netzneutralität werden, sondern nur ein paar Details zum Shaping ansprechen. Die eigentliche Netzneutralitätsverletzung kommt, wenn Rapidshare zu KDG geht und fragt, wieviel Geld sie auf den Tisch legen müssen, damit sie höher als Mediafire priorisiert werden, und KDG dann eine Zahl sagt. Auf der anderen Seite würde niemand was sagen, wenn Rapidshare bei KDG im Rechenzentrum Platz anmietet und dort ihre Server hinstellt. So einfach ist die Situation eben nicht, dass man das mal eben übers Knie brechen kann.
Dann kommt hier noch der Einwand, dass Netzneutralität nicht um Shaping nach Trafficsünderei geht sondern um Diskriminierung von Diensten. Wer Lesen kann ist klar im Vorteil:
Die neue Regelung soll neben Peer-to-Peer Netzwerken unter anderem auch One Click Hoster betreffen.
Erst mal die generellen technischen Daten. Die werben mit "bis zu 32 MBit". Davon sieht man nichts. Bei mir kommen bei Rückenwind bergab mit Anlauf 10 MBit an. Da ist offensichtlich ein Shaper am Start, und zwar rund um die Uhr. Aber gut, 10 MBit ist auch schon mal mehr als 3 MBit. Die Round Trip Zeit zu typischen Hosts ging von 50 auf 30 ms runter.
Doch seit heute habe ich fett Packet Loss auf der Leitung. Zwischen 5 und 15%. Web-Klicken und SSH zögert sich unter diesen Umständen minutenlang hin, manche Sites (inklusive www.kabel-deutschland.de) laufen komplett in einen Timeout. Gut, kann immer mal passieren, sowas. Aber begeistert bin ich ja bisher nicht von dem Angebot.
Mal gucken, ob mir die Telekom dann doch mal irgendwann VDSL legen kann. Da sagt mir die tolle VDSL-Webseite "nicht verfügbar, klicken Sie doch auf der Verfügbarkeitswebseite", und wenn man da klickt, dann sagt die "ist verfügbar", aber bestellen kann man es nicht. Pfusch am Bau, wo man hinguckt.
Es ist ja nicht so, dass ich unbedingt 32 MBit Internet zuhause brauche, aber wenn man dranschreibt, dass da bis zu 32 MBit rauskommen kann, dann muss das zumindest nachts um 4 zu mindestens einer gut angebundenen Site auch möglich sein. Und dieser Packet Loss geht mal gar nicht.
Update: Ah, anscheinend hat heute vormittag ein Nachbar Kabelinternet gekriegt oder sich da was legen lassen. Dann war bzw. sein Elektriker schuld an dem Paketverlust jetzt.
Update: Wird immer schlimmer.
--- ioctl ping statistics ---:-(
38 packets transmitted, 25 packets received, 35% packet loss
round-trip min/avg/max = 25.692/72.618/960.972 ms
Update: Hab auf Anraten der Hotline das Modem resettet, das hat dann statt der angesagten 2-3 Minuten 17 gebraucht, bis es wieder hoch kam, aber seit dem tut alles. Und ich habe auch rausgefunden, wieso ich nicht vollen Durchsatz bekam: der Plasterouter, den die mitgeliefert hatten, hat QoS enabled gehabt, aber die Upstream-Bandbreite fälschlicherweise auf 128 kbit geschätzt. Das hat dafür gesorgt, dass mein Router die ACKs geshaped hat, und das limitiert auch die einkommende Bandbreite. *stöhn*