Telekom und ihr Krüppel Peering, Aufruf und Ideensammlung

nun, da wir den Titel jetzt eh schon hier offen diskutieren

ich könnte das sicher in Tiefe noch genauer Analysieren, aber hier geht es doch darum, dass ein
„speedtest“ gegen einen server der „speedtest“ im Namen hat mit 16Mbit abgefrühstückt wird, und sei dies auch nur weil der via http geht.
Ein anderer Test, der nachweislich 300 Mbit bringen kann, bei krüppeligen 3Mbit dahin schleicht - selbst mit beiden augen zugedrückt seh ich da immer noch „kriminelle“ Bevorzugung einzelnen traffics,
sei es aus sicht des protokolls / port
oder aus sicht von peering und ASen

und wenn ich mich nicht irre wäre das in beiden fällen illegal

Es ist normal das die Hybrid Anschlüsse mit geringster prio am Mast laufen.
Darüber eine Flüchtlingsunterkunft anbinden :-/
wenn andere mit ihrem smartphone yt schauen und den Mast platt machen dann bleibt für die Hybrid Anschlüsse halt nichts mehr übrig.

Das ist ganz normal.

EDIT / NACHTRAG:
======================================================

Die normalen Mobilfunknutzer laufen über die APN
und die Hybridnutzer über die HAAP welche deutlich schlechter angebunden sind.
Ping meist 40 -60 ms schlechter und es ist nur ein Teil der Bandbreite am Mast für
HAAP vorgesehen. Da Klagen von Mobilfunk-Resellern befürchtet wurden wenn 
die Hybrid-Anschlüsse den Mast platt machen.
Die Infos bekamen wir vom T-Punkt in der Bahnhofstraße in Fulda.
Welche uns davon abrieten eine Flüchtlingsunterkunft per hybrid anzubinden.

Wegen der Ideensammlung:

Die Telekom lässt sich nicht Fremdwunsch steuern, z.B. von Hetzner, Level3, etc.
Das Klappt nur mit dem Druckmittel Geld, und das kommt u. a. vom zahlenden Kunden.
→ Telekomaktionäre wollen Dividende, Telekom will Geld für Contentdurchleitung anstelle dafür selber Geld in die Hand zu nehmen, Telekom mindert bewusster die Produktqualität, die Telekomkunden wissen von nix und zahlen monatlich ihre Rechnung um (machmal bereits schon bezahlten) Content geliefert zu bekommen.

Daher das Thema bzw. den Grund noch stärker DAU-tauglich publik machen.
Das Problem kennen viele Telekomkunden: Youtube stockt am Abend gerne mal. Nur liegt es gewiss nicht an Youtube, es liegt an der Telekom. Dann der mündigen Masse der Telekomkunden klarmachen, dass da sehr wohl was gegen gemacht werden kann (Druck ausüben (Hotline oder Netzagentur) oder Anbieter wechseln).

2 Likes

@jason … seh ich auch so, aber dazu müsste man dennoch anfangen einmal ordentlich daten zu sammeln, das in einzelfällen hier und dort festzustellen genügt nicht.
Aufgrund dieser Datenbasis kann man dann die Telekom für Unschuldig befinden , oder aber medial - Evidenz vorrausgesetzt - tätig werden. Und das wird dann schon einen Impact haben, ich vermute in Kombination mit den Level3 und Hetzner Schreiben sogar mehr als zu deren jeweiligen Einzelstatements. Die kamen in der "Tech"Szene zwar gut an und wurden auch verstanden, aber der DAU von der Straße versteht da nur Bahnhof. Wem will mans verübeln das selbst so Themen wie Netzneutralität schwer zugänglich und zu vermitteln sind. Aber wenn ich hingehen könnte und sagen könnte, hier schau , da war am sowieso, an sowieso Youtube langsam und das hatte System - das ist was anderes. Auch wenn ich Nachweisen kann das bei den speedtests ähnlich geschummelt wird wie bei Abgasen. Aber das muss man machen, und dazu brauch man Messungen.

1 Like

Hallo @fuzzle,

es gibt immer zwei Seiten der Medaille. Natürlich hat die Telekom ein weit über dem Branchenüblichen liegende Peeringpreise, aber sie haben es immerhin auch geschafft, dass einige Millionen der GAFA in den deutschen Breitbandausbau fließen. Man kann über Vectoring jammern, aber sie sind immer die einzigen, die derzeit wirklich was erreichen. Das hab ich hier gerade in Münster erlebt. Innerhalb eines Jahres haben sich die DSL-Geschwindigkeiten für die allermeisten verzwei bis verfünffacht. Die anderen reden immer nur davon, mir ist aber nicht bekannt, wo die anderen Anbieter mal ausgebaut haben, abseits von lokalen Initiativen der Stadtwerke. Natürlich kann man über LTE jammern, aber es ist vom Preisleistungsverhältnis (unlimitiertes LTE) oft das günstigste und an vielen Orten das einzige Angebot in abgelegenen Gebieten heute schon zeitgemäßes Internet zu nutzen.

Man kann über alles offen reden. Den Terminus kriminelle Zustände finde ich hier trotzdem unangebracht und würde dich bitten, die zwei Worte zu entfernen.

Den Test fände ich höchstinteressant. Ich könnte mir vorstellen, dass man ein Firmwarepaket dazu macht, das optional aktiviert werden kann und dann zu verschiedenen Zeiten bestimmte Messungen durchführt. Fände ich höchst spannend.

Viele Grüße
Matthias

PS: Titel in Absprache mit @fuzzle angepasst.

1 Like

@fuzzle Wenn ich das richtig raus lese, habt ihr eine Möhre bei Hetzner stehen. Dann klickt euch doch mal den double paid traffic. Haben wir auch mal gemacht. Ich habe es dann aber wieder gekündigt, weil ich es nicht für den richtigen Weg halte. Aber so kannst du sehr einfach herausfinden, ob das in deinem konkreten Fall wirklich am Peering oder was anderem liegt, bevor hier alle auf die Blechtrommel kloppen.

Hetzner ist ja recht unproblematisch, denen wirfste dann nen 5er in den Hut und kündigst das dann direkt wieder. Das sollte ja für „Forschung & Entwicklung“ mal drin stecken.

Wir hatten damals in der Tat Probleme im Peering zwischen der Telekom und Hetzner. Gerade in den Abendstunden ging fast nichts mehr. Aber mittlerweile geht es „recht gut“, Hetzner baut ja auch ständig an ihrer Anbindung. Damals, als wir Probleme hatten, ging der Traffic über GTT, jetzt, wo es recht gut klappt, geht es über core-backbone. Siehe:

Bei uns war es auch so, dass es an den LTE (Hybrid) Anschlüssen tendenziell problematischer war.

Anmerkung: Es waren damals auch nur stichprobenartige Tests, bei denen auch nicht alle (Telekom) Anschlüsse Probleme hatten.


Also zumindest mal ein Traceroutes beisteuern, bevor man hier das ganz große Ranting los tritt, das hätte doch mal was.


10 Sekunden sind imho für Tests über LTE Hybrid zu kurz. Teste mal über 60 Sekunden oder so. Wie bereits erwähnt, wird der LTE Tunnel zugeschaltet, sobald ein bestimmter Schwellwert überschritten ist. Diese Hinzuschalten geschieht allem Anschein nach aber weder binär, noch linear.


Lagen allen Tests die selben Protokolltypen zugrunde? Wie viele Verbindungen je Test gab es? Versuch mal den iperf mit mehreren parallelen Verbindungen durchzuführen. Nicht, dass es besser wäre, wenn die Leitungskapazität nur mit mehreren parallelen Verbindungen ausgenutzt werden könnte, aber es wäre halt ein anderes Problem.


Haben alle verglichenen Tests außerhalb des Freifunk-Tunnels stattgefunden?


Ich persönlich habe den Eindruck, dass l2tp nicht so geil über Hybrid performt, wie fastd zuvor. Aber das kann auch Einbildung sein, ich hatte noch keine Zeit dem näher auf den Grund zu gehen.


Das sind wohl alternative Fakten. :stuck_out_tongue:


Woher habt ihr da? Das sind doch Fake News! Zumindest hat die Telekom mehrfach betont (u. a. in ihrem Unternehmensblog), dass sie in der Priorisierung zwischen Hybridkunden und dem Rest nicht unterscheiden, oder gar anders priorisieren. Die Statements waren relativ klar formuliert, d. h. wenn sie es insgeheim doch machen würden, wäre es vermutlich PR-mäßig und ggf. auch rechtlich eher suboptimal, daher eher unwahrscheinlich.


Generell würde ich gerne dazu ermutigen das Problem besser zu beschreiben / genauer zu lokalisieren und anschließend auf einer umfangreicheren Testbasis zu diskutieren als einfach den 1000ten Telekom-alles-doof Thread aufzumachen.

Und wie @MPW schon sagte, ist nicht alles schlecht bei der Telekom. Wenn man also überhaupt die Aussicht auf Erfolg haben möchte, sollte man das Problem schon etwas detaillierter erörtern.


Beide machen v6.


Nö. Nicht nur „normaler“, sondern aller, außer mancher telekom-„eigener“ z. B. VoIP oder man setzt eigene Regel dafür, dass bestimmter Traffic nur über DSL geben soll. Ganz am Anfang gab es mal Probleme mit SSH über Hybrid, sodass man das auf DSL only stellen musste (deren Hybrid-Tunnel gereffel hatte irgendwelche Header kaputt gemacht). Die Telekom hat aber recht schnell ein FW-Update hinterher geschoben und seit dem geht SSH wunderbar über DSL+LTE bonding.


Ja, die Erfahrung habe ich leider auch gemacht. Wobei es seit einigen Firmware-Version relativ selten geworden ist.

1 Like

Ich habe auch Hybrid (seit ca. 1 Jahr, Mainz) und bei mir konnte ich konnte mittlerweile ganz genau feststellen, warum Freifunk nicht sonderlich gut geht: UDP
Mein Router leitet UDP nur über die DSL Leitung aus, eine Bündelung traut sich die Telekom wohl nicht. Wenn ich DSL kappe, wird mein Freifunk erheblich schneller. Bei denen, wo es gut geht muss UDP dann wohl irgendwie gebondet werden. Das nervt auch bei anderen UDP Anwendungen und es gibt auch zahlreiche Beschwerden dazu im Telekom Forum (Stichwort VPN)

1 Like

Ich habe jetzt auch mal ein bisschen herumgetestet. Zu meinem konkreten Anschluss zuhause kann ich die Probleme (derzeit) nicht nachvollziehen.

Ich habe zwischen meinem Hybrid-Anschluss zuhause und 5 Servern in 4 Rechenzentren, alle bei Hetzner, alle ohne double paid traffic Option, getestet.

Testumgebung:

  • Telekom Hybrid, DSL: 2 MBit/s (~ 500 KBit/s up) , LTE 50 MBit/s (10 MBit/s up)
  • Habe auf meinem Notebook getestet, war im WLAN
  • Gleichzeitig waren noch weitere Teilnehmer im Netz (u. A. Freifunk :wink: )
  • Auf den Servern gingen teilweise zu der Zeit auch mehrere hundert MBit/s drüber.

Ich habe jeweils über IPv4 und IPv6 getestet. Jeweils die Richtung server->client (also mit -R attribut, da Server auf dem Server gestartet).

Interessant: IPv6 brauchte bei all meinen Tests länger als IPv4, um mit einer höheren Bandbreite zu übertragen. Außerdem erschienen mir hier die Schwankungen etwas höher.

Außerdem habe ich einen Traceroute jeweils für IPv4 und IPv6 und in beide Richtungen je Server beigefügt.

Aufgrund der maximalen Beitragslänge hier im Forum habe ich es in ein gist geworfen:


Wenn wir dem Problem nachgehen wollen, sollten wir uns überlegen, wie wir es am Besten isoliert bekommen und welche Parameter wir bei Tests erfassen wollen.

1 Like

Also bei mir funktionieren l2tp und fastd über den Hybrid recht gut. So wie du es beschreibst, funktioniert es bei dir ja nicht nur nicht gut, sondern es wird gar nicht erst genutzt?

Also entweder es gibt echt verschiedene Hybrid-Implementierungen oder bei dir ist irgendwas „kaputt“. Firmware mal auf Aktualität geprüft?

Edit:

Habe jetzt mal über Freifunk getestet, zwar nur mit mäßigem WLAN Empfang (hatte gerade kein Kabel zur Hand), was aber klar wird: Es ist definitiv mehr als die DSL Leitung her gibt:

Time: Sat, 11 Mar 2017 21:03:53 GMT
Connecting to host 148.251.45.X, port 5201
Reverse mode, remote host 148.251.45.X is sending
      TCP MSS: 1228 (default)
[  4] local 10.43.9.X port 41388 connected to 148.251.45.X port 5201
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 60 second test
[ ID] Interval           Transfer     Bandwidth
[  4]   0.00-1.00   sec   465 KBytes  3.81 Mbits/sec                  
[  4]   1.00-2.00   sec   621 KBytes  5.09 Mbits/sec                  
[  4]   2.00-3.00   sec   624 KBytes  5.11 Mbits/sec                  
[  4]   3.00-4.00   sec   662 KBytes  5.42 Mbits/sec                  
[  4]   4.00-5.00   sec   746 KBytes  6.11 Mbits/sec                  
[  4]   5.00-6.00   sec   802 KBytes  6.57 Mbits/sec                  
[  4]   6.00-7.00   sec  1006 KBytes  8.24 Mbits/sec                  
[  4]   7.00-8.00   sec  1.15 MBytes  9.68 Mbits/sec                  
[  4]   8.00-9.00   sec  1.39 MBytes  11.7 Mbits/sec                  
[  4]   9.00-10.00  sec  1.75 MBytes  14.7 Mbits/sec                  
[  4]  10.00-11.00  sec  2.13 MBytes  17.8 Mbits/sec                  
[  4]  11.00-12.00  sec  2.07 MBytes  17.4 Mbits/sec                  
[  4]  12.00-13.00  sec  2.17 MBytes  18.2 Mbits/sec                  
[  4]  13.00-14.00  sec  1.95 MBytes  16.4 Mbits/sec                  
[  4]  14.00-15.00  sec  2.24 MBytes  18.8 Mbits/sec                  
[  4]  15.00-16.00  sec  2.31 MBytes  19.4 Mbits/sec                  
[  4]  16.00-17.00  sec  2.46 MBytes  20.7 Mbits/sec                  
[  4]  17.00-18.00  sec  2.66 MBytes  22.3 Mbits/sec                  
[  4]  18.00-19.00  sec  2.25 MBytes  18.9 Mbits/sec                  
[  4]  19.00-20.00  sec  1.75 MBytes  14.7 Mbits/sec                  
[  4]  20.00-21.00  sec  1.33 MBytes  11.2 Mbits/sec                  
[  4]  21.00-22.00  sec  1.26 MBytes  10.6 Mbits/sec                  
[  4]  22.00-23.00  sec  1.37 MBytes  11.5 Mbits/sec                  
[  4]  23.00-24.00  sec  1.43 MBytes  12.0 Mbits/sec                  
[  4]  24.00-25.00  sec  1.26 MBytes  10.6 Mbits/sec                  
[  4]  25.00-26.00  sec  1.35 MBytes  11.3 Mbits/sec                  
[  4]  26.00-27.00  sec  1.50 MBytes  12.6 Mbits/sec                  
[  4]  27.00-28.00  sec  1.60 MBytes  13.5 Mbits/sec                  
[  4]  28.00-29.00  sec  1.69 MBytes  14.1 Mbits/sec                  
[  4]  29.00-30.00  sec  1.92 MBytes  16.1 Mbits/sec                  
[  4]  30.00-31.00  sec  2.15 MBytes  18.0 Mbits/sec                  
[  4]  31.00-32.00  sec  1.81 MBytes  15.1 Mbits/sec                  
[  4]  32.00-33.00  sec  1.35 MBytes  11.4 Mbits/sec                  
[  4]  33.00-34.00  sec  1.40 MBytes  11.7 Mbits/sec                  
[  4]  34.00-35.00  sec   943 KBytes  7.72 Mbits/sec                  
[  4]  35.00-36.00  sec  1.41 MBytes  11.8 Mbits/sec                  
[  4]  36.00-37.00  sec  1.38 MBytes  11.6 Mbits/sec                  
[  4]  37.00-38.00  sec  1.57 MBytes  13.2 Mbits/sec                  
[  4]  38.00-39.00  sec  1.42 MBytes  11.9 Mbits/sec                  
[  4]  39.00-40.00  sec  1.64 MBytes  13.7 Mbits/sec                  
[  4]  40.00-41.00  sec  1.54 MBytes  13.0 Mbits/sec                  
[  4]  41.00-42.00  sec  1.55 MBytes  13.0 Mbits/sec                  
[  4]  42.00-43.00  sec  1.64 MBytes  13.8 Mbits/sec                  
[  4]  43.00-44.00  sec  1.57 MBytes  13.1 Mbits/sec                  
[  4]  44.00-45.00  sec  1.98 MBytes  16.6 Mbits/sec                  
[  4]  45.00-46.00  sec  2.35 MBytes  19.7 Mbits/sec                  
[  4]  46.00-47.00  sec  2.56 MBytes  21.5 Mbits/sec                  
[  4]  47.00-48.00  sec  2.64 MBytes  22.1 Mbits/sec                  
[  4]  48.00-49.00  sec  2.56 MBytes  21.5 Mbits/sec                  
[  4]  49.00-50.00  sec  2.77 MBytes  23.3 Mbits/sec                  
[  4]  50.00-51.00  sec  3.06 MBytes  25.7 Mbits/sec                  
[  4]  51.00-52.00  sec  2.88 MBytes  24.1 Mbits/sec                  
[  4]  52.00-53.00  sec  2.80 MBytes  23.5 Mbits/sec                  
[  4]  53.00-54.00  sec  2.76 MBytes  23.2 Mbits/sec                  
[  4]  54.00-55.00  sec  2.89 MBytes  24.2 Mbits/sec                  
[  4]  55.00-56.00  sec  2.73 MBytes  22.9 Mbits/sec                  
[  4]  56.00-57.00  sec  2.89 MBytes  24.3 Mbits/sec                  
[  4]  57.00-58.00  sec  2.79 MBytes  23.4 Mbits/sec                  
[  4]  58.00-59.00  sec  2.65 MBytes  22.2 Mbits/sec                  
[  4]  59.00-60.00  sec  2.59 MBytes  21.8 Mbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-60.00  sec   111 MBytes  15.5 Mbits/sec   76             sender
[  4]   0.00-60.00  sec   110 MBytes  15.4 Mbits/sec                  receiver
CPU Utilization: local/receiver 1.1% (0.2%u/0.9%s), remote/sender 0.0% (0.0%u/0.0%s)

iperf Done.

Ich habe seit 5 Monaten Hybrid
Der Anschluss liefert DSL 15,8 Down 2,4 Up , LTE 35 / 10
Gemessen habe ich auf meinem Notebook per Kabel an einen Offloader der den Tunnel zum Supernode herstellt.

T-Online - > AS 65410 → Backbone

Zum vergleichen mal die Firmware-Version aus dem T-online Router
Firmware-Version
050124.03.00.012
LTE-Firmware-Version
H1331.11.994.13.113a

Hast du mehr Infos dazu? Wäre ja mal interessant, wenn man das als Kunde seinen Anschluss einer Variante zuordnen könnte (z. B. durch Merkmale in der FW). So könnte man das Peering-Problem ggf. eine bestimmten Hybird-Art zuordnen.

PS: Mir ist auch schon aufgefallen, dass die Peering-Probleme, die ich mit meinem Hybrid-Anschluss hatte bei meinen Nicht-Hybrid(-Quasi)-Nachbarn (Region Münster) nicht oder nicht in diesem Ausmaß existierten.

Wenn man sich umhört, bekommt man häufig zu hören „Das ist eine große (rosa) Wolke, da geht ein Kabel rein, ein Kabel raus; entweder alle haben dieses (peering) Problem oder keiner.“. Das scheint ja offensichtlich (alles andere hätte mich auch gewundert) nicht der Fall zu sein.

Ja, das ist richtig. Verfiziert über die Geschwindigkeit, übers abziehen von DSL und irgendwo gabs im Engineering Menü noch was.

Firmware aktuell. Es muss da einen Unterschied geben. Ich habe als DSL VDSL25, soweit ich das (hier) sehe haben alle, bei denen es gut funktioniert. ADSL(2+). Kann das der Unterschied sein?

Ich werde am Mo mal ne Störung melden wegen UDP zu langsam. Mal sehen, ob damit irgendwer was anfangen kann :smile:

Um genau zu sein, müsste man vermutlich auf http://speedport.ip/engineer/html/interface.html?lang=de schauen. Dort sind die in/out Frames je interface (also auch LTE und DSL) aufgelistet (leider nicht die octets).

Leider sind im Speedport keine Standards Implementiert, über die man das Teil über Zeit monitoren könnte. Aber ich kann dir folgendes Empfehlen:

Das parst den Engineer-Mode in regelmäßigen Abständen und spuckt das als json oder rrd aus. Das kannste dann in irgendwas rein werfen, was bunte Bildchen macht (ich hatte das seinerzeit in graphite → grafana geworfen).

Hinweis: Leider kann man sich im speedport immer nur mit einer Instanz einloggen, sodass man immer aus dem webui fliegt, wenn das tool gerade wieder neue Datenpunkte liest. Zumindest war es früher so. :confused: also ggf. dann kurzfristig wieder abstellen. Ich habe das glaube ich auf 10 oder 30 Sekunden Intervalle eingestellt. Da hat man schon recht genau gesehen, „was passiert“.

War wohl doch nicht so alternativ-faktisch. Nennt man dann wohl vorschnelles urteilen :P.

2 Likes

Ähm, nö! Grundsätzlich scheint es ja zu gehen. Möglicherweise liegt an der Konfiguration des Anschlusses ein Fehler vor oder es betrifft nur einzelne Hybrid-Varianten (wobei mir diese Info auch neu war, ich dachte immer, dass es nur eine Variante von Hybrid gäbe. Muss mich da mal einlesen…).

Möglicherweise hätte ich eine wohlklingendere Formulierung wählen sollen. Also versuche ich es noch mal:

Nein, es ist nicht generell bei Telekom Hybrid so, dass iperf nur über die DSL Strippe geht.


Btw:

Bei der ietf finden sich ein paar Dokumente von der Telekom&Huawei, die die konzeptionellen Ideen hinter Hybrid beschreiben:

Ich muss aber ehrlicherweise gestehen, dass ich sie nur zu Teilen gelesen btw. überflogen habe und das auch schon 1-2 Jahre her ist. Aber vielleicht interessiert es ja den Einen oder Anderen. :wink:

2 Likes

Ihr habt beide etwas Recht. Bei mir geht iperf sauber über die Strecke, auch mit Bonding (Und das ist höchstwahrscheinlich bei allen so). Das liegt aber daran, dass iperf standardmäßig tcp verwendet. UDP mit iperf zu benchmarken ist schwierig, da man eine Sender-rate einstellen muss und dann auf den Packet-Loss schielen muss. Also nehme ich VPNs (tinc,openvpn,fastd) die UDP verwenden zum benchmarken und in den Tunneln dann iperf.

2 Likes

Das habe ich hier gemacht.

Möchte hier nebenbei darauf hinweisen, dass das Betreiben des Hybrid Routers ohne Verbindung zum DSL Anschluss nur mit LTE Uplink über längere Zeit ein Vertragsbruch und vermutlich auch strafbar ist. Das sollte man nicht hier im Forum empfehlen.

In welchem Gesetz soll das denn stehen :P. Wenn man ein Gesetz bricht, macht man sich strafbar, so schlimm, dass Firmen das Land regieren, ist es nun wirklich noch nicht. Die AGBs der Telekommunikationsfirmen sind einfach Lachnummern.

Es würde mich nicht wundern, wenn es noch Mobilfunkanbieter gibt, in deren AGBs drin steht, dass man kein Instant Messaging (z. B. WhatsApp) oder VoIP (z. B. WhatsApp) machen darf.

6 Likes

ich könnte das sicher in Tiefe noch genauer Analysieren, aber hier geht es doch darum, dass ein
„speedtest“ gegen einen server der „speedtest“ im Namen hat mit 16Mbit abgefrühstückt wird, und sei dies auch nur weil der via http geht.
Ein anderer Test, der nachweislich 300 Mbit bringen kann, bei krüppeligen 3Mbit dahin schleicht

Verstehe ich das richtig, dass der Geschwindigkeitstest nur anhand der url erkannt wird?
Denn, falls ja, würde man bei z.B. diesem Speedtest die echte Geschwindigkeit ermitteln, während Geschwindigkeitstests mit „Speedtest“ in der URL der Leitung eine zu hohe Geschwindigkeit bescheinigen würden. Oder stehe ich auf der Leitung?