Hallo @ausdemdorf,

konntest du an anderer Stelle noch Testen und kannst uns darüber berichten? Vielleicht gibt es hier ja doch noch jemanden, der dir von seinen Tests berichten kann. 

VG
Dennis

Hey, danke für die Antwort :)

Nun, das Einzige was ich bisher herausgefunden habe, ist das der genannte Router als maximale Größe 1024 zulässt, alles darüber wird fragmentiert. Liegt es am Router oder Netz? Gute Frage.

Leider konnten mir die Gurus hier nicht weiterhelfen und sagen welche Größe im Netz genutzt wird.

Der Homespot Router liegt “irgendwo” bei mir im Büro, dort komme ich aufgrund von Homeoffice aktuell nicht dran. Es wäre denkbar das die Firmware des Huawei hier reinfunkt, daher hätte mich ein Vergleich mit den anderen kompatiblen Modellen am Homespottarif interessiert.

Nachdem ich allerdings die Größe von 1024 benutze, sind Verbindungsabbrüche für Tunnellösungen nicht mehr aufgetreten.

Eventuell würde diese Information bei den CoD Modern Warfare - NAT, Nintendo Switch - NAT Fehlermeldungen hier helfen, da besonders UDP Verbindungen an falschen MTU Einstellungen scheitern können.

Mangels Switch und mangels CoD habe ich das aber nicht getestet.

Auch weiß ich gar nicht ob man diese Einstellung im Homespot vornehmen kann.

Welche MTU Size benutzt o2 im LTE Netz ist bisher nicht geklärt.

Wenn du so nett wärst hier einmal bei der Technik nachzufragen @o2_Dennis würde ich mich sehr freuen =)

@Droggelbecher @TBCMagic @Tom_  Das ist doch bestimmt ein spannendes Thema für euch.

Gruß
Antje

Spannend wird es vermutlich erst, wenn einige andere Dinge plötzlich nicht mehr funktionieren.

Hier auch einmal nachsehen: Maximum Transmission Unit (MTU) und Fragmentierung

Ich denke, dass es in diesem Artikel hinreichend erklärt ist.

Mit einem Huawei E3372 und mit dem Homespot komme ich auch auf 1024 (996 + 28)

C:\Users\tbcma>ping www.heise.de -f -l 996

Ping wird ausgeführt für www.heise.de s193.99.144.85] mit 996 Bytes Daten:
Antwort von 193.99.144.85: Bytes=996 Zeit=43ms TTL=243
Antwort von 193.99.144.85: Bytes=996 Zeit=46ms TTL=243
Antwort von 193.99.144.85: Bytes=996 Zeit=39ms TTL=243
Antwort von 193.99.144.85: Bytes=996 Zeit=39ms TTL=243

Ping-Statistik für 193.99.144.85:
 Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
 (0% Verlust),
Ca. Zeitangaben in Millisek.:
 Minimum = 39ms, Maximum = 46ms, Mittelwert = 41ms


C:\Users\tbcma>ping www.heise.de -f -l 997

Ping wird ausgeführt für www.heise.de h193.99.144.85] mit 997 Bytes Daten:
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.

Ping-Statistik für 193.99.144.85:
 Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
 (100% Verlust),

C:\Users\tbcma>

Eine weitere Frage wäre,ob der Wert sich ändert, wenn der NAT-Type umgestellt wird.

In einem anderen Netz komme ich auf andere Werte und auch die Rückmeldung, dass das Paket fragmentiert übermittelt werden sollte: (1472 + 28 = 1500)

C:\Users\tbcma>ping www.heise.de -f -l 1472

Ping wird ausgeführt für www.heise.de r193.99.144.85] mit 1472 Bytes Daten:
Antwort von 193.99.144.85: Bytes=1472 Zeit=61ms TTL=241
Antwort von 193.99.144.85: Bytes=1472 Zeit=45ms TTL=241
Antwort von 193.99.144.85: Bytes=1472 Zeit=52ms TTL=241
Antwort von 193.99.144.85: Bytes=1472 Zeit=36ms TTL=241

Ping-Statistik für 193.99.144.85:
 Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
 (0% Verlust),
Ca. Zeitangaben in Millisek.:
 Minimum = 36ms, Maximum = 61ms, Mittelwert = 48ms

C:\Users\tbcma>


C:\Users\tbcma>ping www.heise.de -f -l 1473

Ping wird ausgeführt für www.heise.de �193.99.144.85] mit 1473 Bytes Daten:
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.

Ping-Statistik für 193.99.144.85:
 Pakete: Gesendet = 3, Empfangen = 0, Verloren = 3
 (100% Verlust),

Im Test oben wurde ein Huawei E8372 verwendet (Ethernet 10)

C:\Users\tbcma>Netsh interface ipv4 show interfaces

Idx Met MTU State Name
--- ---------- ---------- ------------ ---------------------------
 67 55 1500 disconnected WLAN
 1 75 4294967295 connected Loopback Pseudo-Interface 1
 16 5 1500 disconnected Ethernet
 15 25 1500 connected Ethernet 5
 61 25 1500 disconnected LAN-Verbindung* 6
 2 25 1500 disconnected LAN-Verbindung* 7
113 35 1500 connected Ethernet 10

Ich habe einmal die MTU hochgesetzt und noch einmal getestet:

C:\Users\tbcma>Netsh interface ipv4 show interfaces

Idx Met MTU State Name
--- ---------- ---------- ------------ ---------------------------
 67 55 1500 disconnected WLAN
 1 75 4294967295 connected Loopback Pseudo-Interface 1
 16 5 1500 disconnected Ethernet
 15 25 1500 connected Ethernet 5
 61 25 1500 disconnected LAN-Verbindung* 6
 2 25 1500 disconnected LAN-Verbindung* 7
113 35 2000 connected Ethernet 10


C:\Users\tbcma>ping www.heise.de -f -l 1600

Ping wird ausgeführt für www.heise.de d193.99.144.85] mit 1600 Bytes Daten:
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.

Ping-Statistik für 193.99.144.85:
 Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
 (100% Verlust),

Die Grenzen sind irgendwann erreicht. 

Am Homespot kann man den MTU nicht ein- oder umstellen.

Man kann mit der MTU “spielen” oder muss es vielleicht sogar, wenn es zu Problemen kommt. Sollte aber bedenken, dass es zu anderen Problemen führen könnte.

Danke für deine Mühen,

sehr ausführlich, das weiß ich zu schätzen!

Damit sind es schon zwei Tests die 1024 an Huawei Geräten bestätigen.

Mich stört dabei am meisten das meine tolle Idee neben IPv4 Traffic auch IPv6 Traffic (min MTU 1280) zu tunneln zu massiver Paketfragmentierung führt. Es geht alles, aber unglaublich hakelig, weswegen ich IPv6 nun erstmal wieder über Kupferader in mein Netz hole.

GIbt es noch weitere User die fix Ihre Ergebnisse nebst Gerätemodell hier reinstellen würden?

Könnte noch jemand mit Homespot dies einmal für mich testen?

Ich würde mich sehr freuen =)

Ich möchte hiermit ein letztes Mal um Unterstützung aus dem O2 Team bitten.

Bitte fragt die Fachabteilung einmal was im LTE Netz der Telefonica als MTU Größe benutzt wird.

Leider wissen die Gurus diese Antwort nicht und andere Supportwege sind nicht vorhanden.

Da hier erst in ca. 2 Jahren das Festnetz auf vernünftige Geschwindigkeiten ausgebaut wird, bin ich so lange noch auf dieses Produkt angewiesen.

Seit 22 Tagen ist diese Frage leider unbeantwortet.

UFF - Ich wundere mich seit Tagen, warum ich keine stabil-/schnellen TCP Verbindungen hinbekomme.

Ich nutzte den Tarif HomeSpot Unlimited mit einer Fritzbox 6890 LTE

VPN läuft träge, Streaming auch oft unterirdisch.IPv6 Tunnel (HE.Net) ist für’n Ar... 

Nun habe ich hier auch mal die MTU durchgeklappert.

Ergebnis:

C:\Users\j.weltmeyer>c:\mturoute -t heise.de

mturoute to heise.de, 30 hops max, variable sized packets

ICMP Fragmentation is not permitted.

Speed optimization is enabled.

Maximum payload is 10000 bytes.

1 +- host: 192.168.178.1 max: 1500 bytes

2 No response from traceroute for this TTL. Tried 3 times

3 ...-.- host: 10.81.7.1 not responding

4 .-.- host: 10.81.85.22 not responding

5 .-++.-+.-.-++++++ host: 62.52.49.34 max: 1024 bytes

6 +.- host: 62.53.28.171 max: 1024 bytes

7 .-.- host: 80.81.192.132 not responding

8 +.- host: 82.98.102.5 max: 1024 bytes

9 +.- host: 82.98.102.65 max: 1024 bytes

10 .-.- host: 212.19.61.13 not responding

11 +.- host: 193.99.144.80 max: 1024 bytes

C:\Users\j.weltmeyer>c:\mturoute -t hilfe.o2online.de

mturoute to hilfe.o2online.de, 30 hops max, variable sized packets

ICMP Fragmentation is not permitted.

Speed optimization is enabled.

Maximum payload is 10000 bytes.

1 +- host: 192.168.178.1 max: 1500 bytes

2 No response from traceroute for this TTL. Tried 3 times

3 ...-.- host: 10.81.7.1 not responding

4 .-.- host: 10.81.85.22 not responding

5 .-++.-+.-.-++++++ host: 62.52.49.34 max: 1024 bytes

6 +.- host: 62.53.8.189 max: 1024 bytes

7 .-.- host: 99.82.182.196 not responding

8 .-.- host: 52.93.23.210 not responding

9 .-.- host: 54.239.106.105 not responding

10 .-.- host: 54.239.4.218 not responding

11 .-.- host: 54.239.5.231 not responding

12 No response from traceroute for this TTL. Tried 3 times

13 No response from traceroute for this TTL. Tried 3 times

14 No response from traceroute for this TTL. Tried 3 times

15 +.- host: 52.222.149.238 max: 1024 bytes

C:\Users\j.weltmeyer>

@o2_Antje :

Ich würde das als Störung deklarieren. So eine niedrige Paketgröße ist wirklich unterirdisch..

Bitte zeitnah beheben.

Nachtrag:

Ich habe das ganze auch mal auf dem Smartphone getestet.

Eine O2 SIM im gleichen LTE Netz hat eine MTU von 1500. 

Also scheint hier was bei den HomeSpot Tarifen anders zu sein.

Noch ein Nachtrag:

wenn ich als Ziel google.de(172.217.18.99) oder direkt 8.8.8.8 nehme, dann ist die mtu bei 1500,

aber alle TTL-Reducer unterwegs haben nur 1024 - was ist denn hier los? Traffic Shaping, das macht, was es will?

Das war gegen 8.8.8.8 … gegen alles andere außer google ist auch mobil nur 1024… -.-

Danke @jweltmeyer für deine Werte!

Kannst du mir sagen mit welcher App du das am Handy gemacht hast?

Hier wollte ich nicht “alles mögliche” installieren, aber die Tools die ich benutze können das leider nicht.

Grundsätzlich wäre es mir ja egal wenn zwischendrin die Paketgröße wechselt, sofern das unproblematisch weitergereicht würde.

Irgendwas ist da allerdings nicht in Ordnung bei O2, denn Tunnel mit einer MTU Size >1024 gehen immer wieder ein.

Und wenn UDP Pakete so dermaßen leiden im LTE Netz, dann wundern die vielen NAT Probleme auch nicht von denen man hier ließt.

Wie oben erwähnt macht dann auch IPv6 keinen Sinn.

Hoffen wir hier mal weiter auf eine offizielle Antwort aus der Technik :)

@ausdemdorf : Die App heißt “Ping&Trace, Ad free” von “NIva Dev”, ist im playstore zu finden.

=> https://play.google.com/store/apps/details?id=com.studionivadev.pingtrace&hl=de

ja, ich hoffe hier guckt überhaupt mal einer aus der Technik rein…

ich könnte ja mal frech ein paar der aktiven Supportler taggen… :)

@o2_Ines , @o2_Antje , @o2_Kurt …

Gibt bestimmt anschi**, aber evtl bekommen wir so Aufmerksamkeit…

Schmunzel-Edit:

Joar.. Ich weiß jetzt, warum o2 sich mit der einführung von IPv6 so schwer tut…

Immer wenn sie einem Interface eine IPv6 zuweisen wollen, kommt eine Fehlermeldung ;)

Hi zusammen!

Eure Antworten befördern den Thread immer wieder nach oben (wir arbeiten von alt zu neu), deswegen nun erst die verspätete Antwort.

Die Anfrage ist gestellt (samt Link hierher)

Wie die Antwort aussehen wird, kann ich leider noch nicht sagen - meist dauert diese aber nicht sehr lang.

Viele Grüße,

Kurt

Hi zusammen!

Die Antwort auf meine Frage “welche MTU-Size im Telefonica-LTE-Netz verwendet wird”:

wir haben grundsätzlich eine MTU von 1600 im Netz.

Allerdings muß man hiervon die Header abziehen, je nach Verbindung (TCP/IP, GTP, evtl. IPSEC, etc).

Für den Kunden sollte eine Packetgröße von mindestens 1450 übrig bleiben

Bei TCP-Connections greift jedoch vorher schon die im APN vorgegebene MSS von 1430.

MTU = Maximum Transmission Unit

MSS = Maximum Segment Size

Ich hoffe, dies hilft euch bereits ein wenig weiter!

Viele Grüße,

Kurt

Öhmm.. Also hat derjenige, der diese Aussage getroffen hat, sich diesen Thread nicht durchgelesen.

Wir haben hier eine MTU von nur 1024 Bytes

Also jenseits von 1450, die mindestens übrig bleiben sollen.

Unsere Anschlüsse weichen von eurer MTU ab, warum auch immer, wir haben darauf keinen Einfluss.

ALSO STÖRUNG - BITTE BEHEBEN :)

@o2_Kurt  Danke für deinen Einsatz!

Ich wundere mich allerdings, wenn der Thread hier wirklich mitgegeben wurde, dann wurde er nicht gelesen :(

Bitte dem Kollegen sagen das dem nicht so ist!

Die MTU SIze ist viel kleiner als angegeben!

Bitte eskalieren mit der Bitte einmal die Konsole zu  benutzen und es selbst zu sehen.

Beispielsweise muss ich hier nen Tunnel mit 944er MTU aufziehen um v4/v6 da durch zu bekommen. Das ist echt übel, 1024 ist das Maximum, darüber werden Pakete fragmentiert.

Da Bilder mehr helfen als 1000 Worte, ich hab fix nochmal den PC angeworfen.

Hier nur die Windows Ansicht, sieht aber unter Linux genaus aus, versprochen:

@o2_Antje@o2_Kurt@o2_Dennis 

Gibt es hierzu schon Neues? Wurde von euch unser Hinweis auf die “1024 sinds trotzdem” bei eurer Technik eingekippt?

Haben sich die Kollegen aus der Technik dazu schon geäußert?

Gerne fachsimpel ich auch über MSS clamping, headersize, Jumboframes, vpi/vci, irgendwelche z-Kanäle oder die gute alte HDLC Kodierung bei nem Kasten Bier, würde mich im Gegenzug aber auch über einen “regeren Informationsfluss” freuen.

Kommt schon, eine Woche immer wieder hier rein zu schauen und keine Antwort zu bekommen ist echt frustrierend .

Hallo liebes o2 Team,

wurde hierzu schon etwas herausgefunden?

20 Tage seit eurer letzten Antwort .

Ein direkter Technikansprechpartner existiert nicht, die total überfragte Hotline wimmelt einen ab, hier im Supportforum passiert WOCHEN nichts von eurer Seite. Das ärgert mich mittlerweile doch sehr.

Mein Eindruck:

Wenn es um Vertragsverlängerungen geht, kleben eure Kollegen einem wie die Bluthunde im Minutentakt am Telefon im Nacken… wenn es um Probleme geht, kann man es genauso gut auch aufgeben.

Ich würde mich sehr über fundierte, auf die Frage bezogene Antworten freuen die nicht proaktiv eingefordert werden müssen.

Entschuldigt bitte aber der aufgestaute Frust in Richtung eurer Internetlösung und dessen “Support” drückt meine Contenance langsam aber sicher bei Seite.

Hallo @ausdemdorf,

das tut mir leid. 

@o2_Kurt Hast du zum Thema inzwischen was neues gehört?

Viele Grüße

Vivian

Also.. Wenn selbst die eigenen Kollegen keine Antwort mehr bekommen.. Generell ist das spätestens für Business-Anwendung doch ein schärferes Problem. Scheinbar  muss ich dann doch zur Konkurrenz abwandern schade. Telekom hat übrigends eine vernünftige MTU von 13XX

Hi zusammen!

Nein, ich habe bisher keine weitere Antwort erhalten.

Wir können für jede eurer Nummern ein eigenes Ticket dazu eröffnen (landet in der gleichen Abteilung), eine andere Antwort auf Anfragen erwarte ich nicht. Bei individuellen Anfragen mit Rufnummern und Details kann es natürlich wieder anders aussehen.

Viele Grüße,

Kurt

Dann bitte ich hiermit darum, das ein Ticket eröffnet wird.

MSS darf 996 Bytes groß sein, alles darüber läuft ins Nirvana oder wird fragmentiert.

Bitte auch im Hinterkopf behalten, das ich -zumindest für den Homespot- eine externe IP Adresse gebucht habe, es dort ja Monate Probleme in eurem Netz gab vom o2 Handy auf die externe IP zuzugreifen und dieses Problem augenscheinlich gelöst wurde. (Inoffiziell wurden wohl einige eurer IP Ranges für meinen Homespot und mein Handy gesperrt und beide befinden sich nun immer im selben IP Adressbereich).

Die “externe IP” hört bei einem Trace über externe Netze bei euch an 62.52.49.38 auf, dem Server der in den letzten Monaten immer mal durch stoßweisen Paketverlust glänzt (https://hilfe.o2online.de/o2-homespot-o2-my-data-spot-21/ueberlast-im-telefonica-netz-62-52-49-38-535199).

Bis zu meinem Netz liegen hinter diesem Server mindestens jedoch drei weitere Hops:

10.81.85.xx, 10.81.7.xx und ein Gerät das auf nichts antwortet und keine Adresse rausrückt.

Entgegen eurem Marketing wird trotz allem also immer noch eine Art des CGN benutzt um public Anfragen auf ein privates Netz umzubiegen.

Geht hier bei eurer Umsetzung die MSS Size kaputt?

Eines der Programme welches ich für die MTU Bestimmung unter Windows getestet habe, spuckt das hier aus:

“PMTU blackhole found in path from this host to 62.52.49.38”

Ich bin mir nicht sicher ob damit dieser problematische Server gemeint ist, oder das Blackhole in den letzten Hops bis zu mir. Kann ja auch sinnvoll sein die Antworten zu unterdrücken.

Aber bitte mal den Fachleuten geben, gerne auch mit obigen Screenshots angereichert, welche leider immer noch aktuell sind.

Servus,

wurde schon ein Ticket angelegt? Wie ist der Bearbeitungsstatus, was sagt die Technik?

Ich trickse mir hier IPv6 ins Netz (über einen IPv4 Tunnel), was dabei stört ist die beknackte MTU Problematik im O2 Netz.

Da IPv6 Pakete eine minimale Größe von 1280 Byte haben müssen, fragmentiert das wie verrückt und erzeugt unnötigen Overhead (https://tools.ietf.org/html/rfc2460).

Zwei Monate, nen paar Telefonate und hier gepostet, nichts passiert seitens O2.

Frustrierend.

Mein Handyvertrag musste verlängert werden… ich habe soviele Anrufe von euch bekommen, GEIL.

Wenn jetzt noch irgendwer daran interessiert wäre die Technik zu reparieren, richtig gut!

Stattdessen rennt man hinterher und hat das Gefühl vertröstet und als störend empfunden zu werden.

Ich bin sauer.

Bis zum 31igsten Dezember 2021 soll hier in der Stadt Glasfaser bis ins Haus gelegt werden, nach den bisherigen Serviceerfahrungen seit Dezember letzten Jahres mit o2… glaube ich, das ihr bis dahin das Problem nicht gelöst haben werdet.

Eventuell mag mich O2 ja vom Gegenteil überzeugen?