liegt am nat3 wenn über udp daten gesendet werden und die ports nicht offen sind, sind die daten weg. gibt ja kein handshack, daher einfach weg. wenn du ein vpn benutz kannst du nat2 haben ohne verluste oder bestellst netpublic bei o2.

wann hast du denn 300mbits über lte, nachts? ich kann froh sein wenn ich nachts 100mbit habe :)

und ja es gibt beschwerden.

Vielen Dank erstmal für Deine Antwort. Gibt es denn weitere Faktoren die das Verhalten verschlimmern / verbessern? Mein Bruder ist o2 Kunde und hat einen Homespot, allerdings ohne gebuchte IPv4 (oder gibts die dort immer?).

Ich habe ihn mal gebeten ein Ziel etwas länger anzupingen - hat er auch getan und bei ihm gibt es keinerlei Beschwerden. Kein Paket loss.

Ich bin zusätzlich auch noch Vodafone Kunde. Ich habe mal meine Vodafone-SIM Karte eingelegt und auch dort gibts es CGN, allerdings habe ich kein Paket-Loss, jedenfalls nicht im so hohen Bereich wie bei o2.

Wenn es mit dem VPN nicht so symptomfrei wäre, würde ich ja sagen, die Verbindung zwischen mir und o2 ist gestört, aber daran würde ja der VPN nichts ändern.

Für die Moderatoren und weitere Mitleser habe ich den Test heute nochmal wiederholt mit einem PING ohne und mit VPN damit man auch eine tagesform ausschließen kann.

Mit VPN

60 packets transmitted, 60 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 43.535/58.368/396.009/44.665 ms

Ohne VPN

60 packets transmitted, 9 packets received, 85.0% packet loss
round-trip min/avg/max/stddev = 35.451/56.599/117.875/29.971 ms

Ich kann mir beim besten Willen nicht vorstellen, dass die gesamte Kundschaft, die nicht auf die Idee kommt 49 Euro für einen anderen NAT Typen auszugeben mit 85%++ Packet loss lebt oder es gar nicht erst bemerkt.

@NothingSpecial42 sie bemeken es kaum, wer nur surft der bemerkt höchstens das mal eine seite nicht komplett oder erst beim 2. mal ladet. wer videos schaut hat ab und zu mal einen verbindunngsabbruch.

wer spielt über psn oder so hat hin und wieder verbindungsabbrüche. denn zu dem nat 3 kommt ja auch noch dazu wie belastet die zelle ist die dich versorgt. bei dem einen besser bei dem anderen schlechter.

manchmal antwortet der masst nicht weil er überlastet ist. es ist halt ein shared medium wo du die verbindungsqualität durch netpublic verbessern kannst aber der faktor getaktete verbindung bleibt immer.

je nach standort und uhrzeit besser oder schlechter. weiß nicht ob ein homespot automatisch netpublic hat.

zudem kommt noch wenn du router benutz das du dann die nat verschachtelst was die verbinungsqualität verschlechtert. wenn du nat3 hast brauchst du keine 2. firewall mehr durch deinen router.

Würde deine Annahme bedeuten, dass mit der Buchung einer IPv4 das Problem behoben ist? 

Hallo @NothingSpecial42,

so eine Testkatre ist schon eine feine Sache, denn genau zum testen ist sie ja da :-)

Und jetzt meine ganz persönliche Einschätzung: Ein Ping sollte egal ob mit öffentlicher IIP-Adresse normalerweise durchlaufen. Ob es eventuell die Möglichkeit gäbe, dass nach Buchung einer bestimmten Option unter Umständen ein niedrigerer Packetloss auftreten könnte würde ich persönlich nicht in meine Überlegungen mit einbeziehen. Denn wenn es selbst mit öffentlicher IP-Adresse keine Besserung geben sollte (was durchaus realistisch ist), hast du am Ende einen Vertrag, der nicht das leistet, was du erwartest.

Gruß,

Lars

Hey Lars, 

bestünde eventuell die Möglichkeit eine IP zum Testen auf eine Test SIM zu buchen? Ein paar Stunden würden schon genügen. 
 

Was ist denn Deine Vermutung zur Ursache?

Hallo @NothingSpecial42,

wir können nur eine öffentliche IPv4 zuteilen. Bitte beachte aber, dass es sich hier nicht um eine feste IPv4 handelt.

Wenn du sie nur kurz nutzen möchtest, kannst du die Buchung innerhalb von 14 Tagen widerrufen. Es reicht aus, wenn du uns dazu hier Bescheid gibst.

Ich bin allerdings auch bei Lars und vermute, dass es keine große Verbesserung bei deinem Problem bringen würde.

Gib uns gerne Bescheid, wenn du es dennoch einmal testen möchtest.

Viele Grüße

Giulia

Hi,

dann würde ich das Angebot annehmen, danke. 

Hi nochmal!

ich habe mich heute nochmal mit einem befreundeten Techniker eines großen anderen Unternehmen unterhalten, welches u.a Mobilfunk vertreibt. Er hatte noch eine andere Vermutung und-zwar, dass ich als Test-SIM Karte eine andere Priorität habe, wie z.B Bestandskunden. Kann das derartige Symptome auslösen? Erschwert der VPN ggf. eine Priorisierung und dadurch kommt es zum besseren Datenfluss?

Werden Anfragen die Einzeln statt gebündelt über einen VPN kommen ggf. eher als Flood gesehen und findet deshalb ohne VPN ein Rate-Limiting statt?

Sowohl @o2_Lars als auch @o2_Giulia sagen beide, dass es wohl eher nicht an der fehlenden IPv4 liegt, allerdings habt ihr beide bisher überhaupt noch keine Idee geäußert, woran es liegen könnte. Prinzipiell stimmt ihr mir zu, dass das nicht der normal Fall sein sollte, oder?

Hallo @NothingSpecial42,

dass die Testkarten eine andere Priorität haben, würde ich mit Sicherheit ausschliessen. Wir wollen damit ja eigentlich Neukunden von unserem guten Netz überzeugen, das wäre dann ja nicht sehr beeindruckend

Nein eigentlich sollten solche Paketverluste natürlich gar nicht auftreten. Die Ursachen können hier aber sehr vielfältig sein, angefangen bei der eigenen Hard- und Software bis hin zu (in diesem Fall Mobilfunk-) Störungen oder überlasteten Netzwerkknoten.

Ich habe deiner Test-Karte jetzt eine öffenentliche IPv4 zugeteilt. Um sie nutzen zu können, ändere bitte den APN im Router auf netpublic.

Berichte dann gerne einmal, wenn du es testen konntest.

Viele Grüße

Giulia

Hallo @o2_Giulia,

erstmal Danke fürs zur Verfügung stellen der IPv4 für diesen Test.

Für den Test habe ich den VPN deaktiviert und unmittelbar danach mit einem MTR im Hintergrund massive Paketverluste festgestellt:

Request timeout for icmp_seq 5753
Request timeout for icmp_seq 5754
Request timeout for icmp_seq 5755
Request timeout for icmp_seq 5756
Request timeout for icmp_seq 5757
Request timeout for icmp_seq 5758
Request timeout for icmp_seq 5759
Request timeout for icmp_seq 5760
Request timeout for icmp_seq 5761
Request timeout for icmp_seq 5762
Request timeout for icmp_seq 5763
Request timeout for icmp_seq 5764
Request timeout for icmp_seq 5765
Request timeout for icmp_seq 5766
Request timeout for icmp_seq 5767
Request timeout for icmp_seq 5768
64 bytes from 1.1.1.1: icmp_seq=5769 ttl=56 time=28.253 ms
Request timeout for icmp_seq 5770
Request timeout for icmp_seq 5771
Request timeout for icmp_seq 5772
Request timeout for icmp_seq 5773
Request timeout for icmp_seq 5774
Request timeout for icmp_seq 5775
64 bytes from 1.1.1.1: icmp_seq=5776 ttl=56 time=28.017 ms
64 bytes from 1.1.1.1: icmp_seq=5777 ttl=56 time=29.028 ms
Request timeout for icmp_seq 5778
Request timeout for icmp_seq 5779
Request timeout for icmp_seq 5780
Request timeout for icmp_seq 5781
Request timeout for icmp_seq 5782
Request timeout for icmp_seq 5783
Request timeout for icmp_seq 5784
Request timeout for icmp_seq 5785
64 bytes from 1.1.1.1: icmp_seq=5786 ttl=56 time=26.945 ms
Request timeout for icmp_seq 5787
Request timeout for icmp_seq 5788
64 bytes from 1.1.1.1: icmp_seq=5789 ttl=56 time=37.558 ms
Request timeout for icmp_seq 5790
Request timeout for icmp_seq 5791
64 bytes from 1.1.1.1: icmp_seq=5792 ttl=56 time=27.411 ms
64 bytes from 1.1.1.1: icmp_seq=5793 ttl=56 time=31.549 ms
64 bytes from 1.1.1.1: icmp_seq=5794 ttl=56 time=28.192 ms
64 bytes from 1.1.1.1: icmp_seq=5795 ttl=56 time=27.450 ms
64 bytes from 1.1.1.1: icmp_seq=5796 ttl=56 time=28.580 ms
Request timeout for icmp_seq 5797
Request timeout for icmp_seq 5798
Request timeout for icmp_seq 5799
Request timeout for icmp_seq 5800
Request timeout for icmp_seq 5801
Request timeout for icmp_seq 5802
Request timeout for icmp_seq 5803
Request timeout for icmp_seq 5804
Request timeout for icmp_seq 5805
Request timeout for icmp_seq 5806
Request timeout for icmp_seq 5807
Request timeout for icmp_seq 5808
Request timeout for icmp_seq 5809
Request timeout for icmp_seq 5810
Request timeout for icmp_seq 5811
Request timeout for icmp_seq 5812
Request timeout for icmp_seq 5813
Request timeout for icmp_seq 5814
Request timeout for icmp_seq 5815
Request timeout for icmp_seq 5816
Request timeout for icmp_seq 5817
Request timeout for icmp_seq 5818
Request timeout for icmp_seq 5819
Request timeout for icmp_seq 5820
Request timeout for icmp_seq 5821
Request timeout for icmp_seq 5822
Request timeout for icmp_seq 5823
Request timeout for icmp_seq 5824

Danach habe ich die APN Daten auf “netpublic” umgestellt und habe seitdem 2 MTR im Hintergrund laufen, 2x Dauer-Ping und keine Paketverluste:

64 bytes from 1.1.1.1: icmp_seq=164 ttl=56 time=27.107 ms
64 bytes from 1.1.1.1: icmp_seq=165 ttl=56 time=28.409 ms
64 bytes from 1.1.1.1: icmp_seq=166 ttl=56 time=29.601 ms
64 bytes from 1.1.1.1: icmp_seq=167 ttl=56 time=41.488 ms
64 bytes from 1.1.1.1: icmp_seq=168 ttl=56 time=61.532 ms
64 bytes from 1.1.1.1: icmp_seq=169 ttl=56 time=31.639 ms
64 bytes from 1.1.1.1: icmp_seq=170 ttl=56 time=26.014 ms
64 bytes from 1.1.1.1: icmp_seq=171 ttl=56 time=43.163 ms
64 bytes from 1.1.1.1: icmp_seq=172 ttl=56 time=26.580 ms
64 bytes from 1.1.1.1: icmp_seq=173 ttl=56 time=26.563 ms
64 bytes from 1.1.1.1: icmp_seq=174 ttl=56 time=80.338 ms
64 bytes from 1.1.1.1: icmp_seq=175 ttl=56 time=155.835 ms
64 bytes from 1.1.1.1: icmp_seq=176 ttl=56 time=33.226 ms
64 bytes from 1.1.1.1: icmp_seq=177 ttl=56 time=40.838 ms
64 bytes from 1.1.1.1: icmp_seq=178 ttl=56 time=45.313 ms
64 bytes from 1.1.1.1: icmp_seq=179 ttl=56 time=36.636 ms
64 bytes from 1.1.1.1: icmp_seq=180 ttl=56 time=31.111 ms
64 bytes from 1.1.1.1: icmp_seq=181 ttl=56 time=34.220 ms
64 bytes from 1.1.1.1: icmp_seq=182 ttl=56 time=27.876 ms
64 bytes from 1.1.1.1: icmp_seq=183 ttl=56 time=30.825 ms
64 bytes from 1.1.1.1: icmp_seq=184 ttl=56 time=25.476 ms
64 bytes from 1.1.1.1: icmp_seq=185 ttl=56 time=30.101 ms
64 bytes from 1.1.1.1: icmp_seq=186 ttl=56 time=26.914 ms
64 bytes from 1.1.1.1: icmp_seq=187 ttl=56 time=50.363 ms
64 bytes from 1.1.1.1: icmp_seq=188 ttl=56 time=42.434 ms
64 bytes from 1.1.1.1: icmp_seq=189 ttl=56 time=125.092 ms
64 bytes from 1.1.1.1: icmp_seq=190 ttl=56 time=28.893 ms
64 bytes from 1.1.1.1: icmp_seq=191 ttl=56 time=26.914 ms
64 bytes from 1.1.1.1: icmp_seq=192 ttl=56 time=25.972 ms
64 bytes from 1.1.1.1: icmp_seq=193 ttl=56 time=25.713 ms
64 bytes from 1.1.1.1: icmp_seq=194 ttl=56 time=26.505 ms

Zudem im Schnitt sogar echt schöne Pings für LTE.

Das Peering zwischen “normal” und “netpublic” ist übrigens genau gleich. Erstmal möchte ich mich bei @kunde_404 für meine Skepsis entschuldigen, aber ich habe es einfach nicht glauben wollen.

Tatsächlich ist eine öffentliche IPv4 durch o2 die Lösung für massive Paketverluste, jedenfalls wenn man sie hat.

Ich werde es jetzt mal einen Tag beobachten, nicht, dass es nachher nur ein großer Zufall ist, aber ich bin sehr optimistisch.

Hallo @NothingSpecial42,

das sieht in der Tat super aus, freut mich, dass es in dieser Konstellation geklappt hat und die Paketverluste dann nicht mehr auftreten.

Beobachte es gerne noch ein paar Tage, wenn du möchtest.

Viele Grüße

Giulia

Hallo @o2_Giulia,

ja, ich werde es ein paar Tage beobachten und mich dann hier melden. Die Test-SIM läuft ja noch ein paar Tage. Vielen Dank, dass ihr euch so offen an dem Test beteiligt.

Tatsächlich wäre in dieser Konstellation o2 für mich ein guter Anbieter durch die beste Abdeckung hier vor Ort. Würde man nach Vertragsabschluss im Falle einer Störung ohne dieses IP-Paket diese Zubuchoption auch kostenfrei erhalten können?

Viele Grüße!

@NothingSpecial42 also zu versuchen es kostenlos zu bekommen kann man ja machen, aber es ist keine Störung sondern ein strikter nat type zur sicherheit der kunden. o2 hat desshalb ihre ip-config so streng gestalltet weil sie in ihren agb explizit threathering via hotspot erlauben, was andere anbieter zwar tollerieren aber nicht per agb freigegeben haben aufgrund ihrer config. denn wenn du einen offenen nat typ hast mit netpublic, hast du so gut wie keine oder nur eine sehr schwache firewall und du selbst trägst die veranwortung deine geräte bzw. software immer aktuell zu halten sowie eine sicherheitssoftware auf deinen geräten zu installieren. natürlich gehen hersteller von handys, tablets und spielkonsolen hin und machen die software so sicher wie möglich aber der kunde muß stets seine software aktuell halten!!!!

Z.b. eine Playstation mit interner zugang nat type 2 (offen) muss stets aktuell sein weil die Playstation bzw. betriebsssystem seine eigene firewall benutz, desshalb gibt es auch dort einen update-zwang um psn zu schützen weil der Hersteller für alle Netzwerkfunktionen nat 2 empfiehlt. Daher der Zwang Softwareaktualisierungen durchzuführen im psn.

Wer netpublic hat sollte nicht mit sehr alten handys surfen oder sogar cryptowallets hosten!!

Hey @kunde_404,

ich habe bei Vodafone und Telekom trotz CGN keine Paket-Losses von über 80% gehabt. Offenbar gibt es ja denn zwischen den einzelnen Anbietern im CGN massive Unterschiede? Und als normaler DSL Kunde sorge ich natürlich auch selbstständig für meine Sicherheit. Denn überlicherweise gibt es zum DSL, Glasfaser, Kabelanschluss immer eine öffentliche (wenn auch nicht feste!) IPv4/v6. Ich werde den Verdacht noch nicht ganz los, dass es nicht nur am CGN liegt sondern die Einstellung einer öffentlichen v4 intern (vermutlich auch unbewusst) weitere Einstellungen anstößt. Nicht umsonst konnten sich @o2_Lars und @o2_Giulia nicht vorstellen, dass eine öffentliche IPv4 sämtliche Packet-Loss Probleme löst.

Ich denke auch nicht, dass CGN etwas damit zutun hat, den Kunden ein nettes Sicherheits-Feature anbieten zu wollen, denn naturgemäß verwenden Anbieter CGN um wertvolle IPv4 Adressen zu sparen. Ist auch kein Vorwurf, aber wenn es dafür sorgt, dass ich am Laptop mit einer Daten-SIM über 80% der Pakete verliere, ist das kein angenehmes Arbeiten mehr.

@NothingSpecial42 bei allem respekt aber die mods sind keine techniker. wie gesagt telekom und vodafone sind nicht so streng wegen ihrer agbs, zum thema dsl mit öffentlicher ip bekommst du immer einen router der halt ne firewall besitzt. es git oder gab auch dsl verträge ohne öffentliche ip da bekommst du nur nen modem weil du vom provider nur nat 3 bekommst. Es ist keine störung, es ist gewollt so, die techniker von o2 wissen was sie tun und stellen den dienst agb gerecht.

Und nochmal, der paketverlust kommt durch geschlossene udp ports. Du benötigst netpublic dann und selbst dann könnten verluste durch die getaktete verbindung entstehen, aber viel weniger, weil shared medium ;)

nur um 49eur zu sparen krampfhaft auf eine Störung zu pochen und o2 abzusprechen das sie für ihre kunden sicherheit wollen, finde ich nicht fair gegenüber o2, wenn du kein bock auf die 49 eur hast warum nimmst du dann nicht dsl mit ner fetten fritzbox? (weil noch teurer ?)

Dazu kommt noch das du obwohl es einmalig 49 eur kostet trotdem viel günstiger bei o2 weg kommst als bei anderen anbietern, denn o2 ist vom preis her auch bei bestandskunden sehr gnädig und man bekommt super angebote, tipp frag immer in der Community nach angeboten.

Hallo @NothingSpecial42,

Das würden wir auf jeden Fall erst einmal durch unsere Techniker prüfen lassen, da diese Paketverluste in dem Umfang schon recht hoch sind. Kostenfrei können wir die öffentliche IPv4 nicht einrichten.

Das ist ein guter Punkt @kunde_404, man kann es gar nicht oft genug betonen. Eine öffentliche IPv4-Adresse ermöglicht es zunächst jedem, via Internet eine direkte Verbindung zum Gerät herzustellen. Man ist als Anwender für Schutz des eigenen Netzes selbst verantwortlich: z. B. Firmware des Geräts regelmäßig aktualisieren, Firewall installieren, IP-Adresse beim Surfen verbergen.

Viele Grüße

Giulia