Diese Frage wartet auf Beantwortung

WIfIonICE Packet loss

Hallo DB-Team,
ich fahre regelmässig die Strecke ICE1550 sowie ICE1651 Dresden-Frankfurt und zurück.
Seit der Umstellung auf das neue Wifi ist der TCP Paketverlust stark schwankend und oft enorm hoch.
Arbeiten im Zug z.B. via Citrix Receiver wird damit echt zur Qual.
MTU Anpassung auf 1440 hat bei mir bisher auch nichts gebracht.
Interessant ist, das während einer Request Timeout Phase ein anderer Client, bspw. ein Smartphone ohne Probleme irgendeine Webseite aufrufen kann, mein Notebook aber nicht. Umgekehrt tritt das auch auf, auf dem Smartphone dann mit "hängendem" Seitenzugriff, wg. fehlendem ping-Beweis.
Da ich das schon mehrfach beobachtet habe, gehe ich auch nicht von einem allgemeinen Empfangsproblem aus Sicht des ICE in dem ich sitze aus, zumal sich die Anzahl der Funkmasten entlang der Strecke sich ja nicht wesentlich geändert haben zu "vorher".
Ich muss aber sagen, "vorher" war es bzgl. was "arbeiten" (nicht surfen) anbetrifft, wesentlich besser, zumindest in dieser Fahrttangente.
Jetzt ist ICE1550 ab 20:13 Dresden nicht unbedingt der vollste Zug, also scheidet als Grund eigentlich der allgemeine Benutzungsgrad aus. Ich vermute neben dem MTU Problem im bereits geschlossenen SSL-VPN Thread immer noch eher ein Konfigurationsproblem oder sogar ein physik. Limit in der verbauten Hardware auf Icomera Seite.

Kann da nicht doch noch jemand mal gezielter schauen wie das u.U. verbessert werden könnte?

icependler2016
icependler2016

icependler2016

Ebene
0
24 / 100
Punkte

Antworten

DB
DB

DB

Ebene
4
5000 / 5000
Punkte
Team

Guten Morgen icependler2016, grundsätzlich ist die Nutzung von VPN schon möglich, aber es werden noch nicht alle Konfiguration unterstützt. Es wird aber daran gearbeitet. Ob oder wann aber alle Konfigurationen nutzbar sind, kann ich leider nicht sagen. /no

Sehr geehrtes Team der DB,
es ist eine absolute Frechheit, den vorhandenen VPN-Thread (82 Antworten) zu schließen.
Das Problem ist noch lange nicht behoben, und erneut wird behauptet, dass daran gearbeitet wird.
Es ist zu bezweifeln, dass das stimmt und das Problem ernst genommen wird.
Ich sitze gerade im ICE906 nach Hamburg. WifiONICE Verbindung hergestellt, aber kein Internet. Man gelangt auf die Startseite des Services, danach erscheint ein HTTP 500 Fehler.
Bin erneut auf eigene Kosten mit meiner SIM-Card online.
Auf meiner letzten Testfahrt, die ich eigens für unseren Kunden gemacht habe, war auf der ICE-Strecke nach Stralsund der gesamte Service gar nicht verfügbar. Die Zugbegleiter gaben mir unterschiedliche Auskünfte von "haben wir hier auf der Strecke gar nicht" bis "das WLAN ist im Moment defekt".
Liebe DB, schmeißen Sie den Anbieter der Lösung am besten im hohen Bogen aus seinen Verträgen heraus, und fordern Sie Schadensersatz. Diese Lösung ist komplett unbrauchbar.

icependler2016
icependler2016

icependler2016

Ebene
0
24 / 100
Punkte

Ich nehme momentan an, es sind zwei verschiedene Probleme.
Das eine Problem ist die grundsätzliche Blockierung von direkten VPN Verbindungen wie im erwähnten VPN-SSL Thread. Da geht's wahrscheinlich tatsächlich um Ports&Co. und tiefer gehende Konfigurationen hinsichtlich von VPN überhaupt z.B. über Network Connect Juniper.

Das Problem was ich beschrieben habe hat damit eher wahrscheinlich nichts zu tun. Denn ich kann ja grundsätzlich mit der zumindest bei deutschen Unternehmen weit verbreiteten Software Citrix Receiver Verbindung aufnehmen. Nur kann ich bspw. auf meinem Client aus Sicherheitsgründen keine weiteren Konfigurationen vornehmen, bspw. was den Timeout betrifft.
Es ist bei dem Problem so, das ich mir absolut nicht erklären kann warum überhaupt so viele Pakete verloren gehen.
Eine abstrakte Annahme könnte ja bspw. darin bestehen das der ICE keine Funkverbindung hat. Logo - da gibts dann Paketverlust und träge TCP/IP Verbindungen die auf alle oberen Anwendungschichten durchschlagen.
Aber: Die Anzahl der Funkmasten hat doch zu als abgenommen, also erscheint mir das nicht plausibel.

Eine viel plausiblere Erklärung könnte eine politische sein: Internet schon - aber eben für alle ein kleines bisschen. Wenn ich dann von Frankfurt nach Dresden durchweg arbeite, vielleicht ist das ja nicht gewollt.

Aber liebe DB, dann möchte ich auch soviel Transparenz das Ihr sagt: Ja, wollen wir nicht. Jeder soll ein klein bisschen surfen können, aber konstante Verbindungen nach draußen sind nicht gewünscht und werden demzufolge technisch unterbunden oder eben erschwert.
Vielleicht momentan eher unabsichtlich.

Wenn keine Konfigurationsgründe erkennbar sind, muss halt analysiert werden. Ist ja kein Problem, das ich da als Hauptnutzer eingebunden werde, ich fahre die Strecke alle zwei Wochen (aber immer in anderen ICE's dem Namen nach).
Bspw. ist doch komisch das auf der kurzen VDE8 Strecke bei 230km/h zwischen Leipzig und Erfurt der Paketverlust nicht schlimmer ist, als bspw. zwischen Leipzig und Riesa.
Überall flaches Land.

DB
DB

DB

Ebene
4
5000 / 5000
Punkte
Team

Hallo icependler2016,

es gibt von unserer Seite keine Blockierung von VPN-Verbindungen. Bitte beachten Sie unseren Hinweis im erwähnten Thread zum Thema vom 3. Februar. Das Patch ist aufgespielt und erfolgreich im Einsatz. Somit können Sie in der 1. Klasse zuverlässig arbeiten und entspannt ankommen. In der 2. Klasse können Sie auf der gesamten Reise einfach surfen und kommunizieren. Wenn das Angebot hier zu intensiv genutzt wird, surfen Sie zugunsten der anderen Fahrgäste mit niedrigerer Geschwindigkeit weiter. /ma

Liebes Bahn-Team, woher nehmen Sie die Information, dass damit erfolgreich gearbeitet wird?
Ich konnte letzte Woche keine VPN-Verbindung aufbauen. Wäre es möglich, dass sich ein Fachteam dazu hier nochmal genauer äußert mit technischen Details, d.h. welche Art VPN-Verbindungen mit welchen MTU-Werden supported werden und getestet sind?
Seit wann sind die Qualität der Verbindungen nun doch wieder unterschiedlich zwischen 1. u. 2. Klasse? Es hieß zuletzt, dass der Service im gesamten Zug gleich sei.

icependler2016
icependler2016

icependler2016

Ebene
0
24 / 100
Punkte

... und hier ein aktuelles Beispiel vom 1.5.2017, ICE1552 Drs-Ffm zwischen Dresden und Riesa, aber so ähnlich schlecht ist das eigentlich die ganze Strecke:

PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=47 time=86.994 ms
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
64 bytes from 8.8.8.8: icmp_seq=1 ttl=47 time=2180.590 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=47 time=1179.680 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=47 time=175.607 ms
Request timeout for icmp_seq 6
64 bytes from 8.8.8.8: icmp_seq=4 ttl=47 time=3083.632 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=47 time=2325.734 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=47 time=1326.116 ms
Request timeout for icmp_seq 10
Request timeout for icmp_seq 11
Request timeout for icmp_seq 12
Request timeout for icmp_seq 13
Request timeout for icmp_seq 14
Request timeout for icmp_seq 15
Request timeout for icmp_seq 16
64 bytes from 8.8.8.8: icmp_seq=16 ttl=47 time=1701.329 ms
64 bytes from 8.8.8.8: icmp_seq=17 ttl=47 time=1143.927 ms
64 bytes from 8.8.8.8: icmp_seq=18 ttl=47 time=1008.953 ms
Request timeout for icmp_seq 20
Request timeout for icmp_seq 21
Request timeout for icmp_seq 22
Request timeout for icmp_seq 23
Request timeout for icmp_seq 24
Request timeout for icmp_seq 25
Request timeout for icmp_seq 26
Request timeout for icmp_seq 27
64 bytes from 8.8.8.8: icmp_seq=26 ttl=47 time=2620.763 ms
64 bytes from 8.8.8.8: icmp_seq=27 ttl=47 time=1621.013 ms
64 bytes from 8.8.8.8: icmp_seq=28 ttl=47 time=616.980 ms
64 bytes from 8.8.8.8: icmp_seq=31 ttl=47 time=219.788 ms
64 bytes from 8.8.8.8: icmp_seq=32 ttl=47 time=214.373 ms
64 bytes from 8.8.8.8: icmp_seq=33 ttl=47 time=383.011 ms
64 bytes from 8.8.8.8: icmp_seq=29 ttl=47 time=4460.189 ms
64 bytes from 8.8.8.8: icmp_seq=34 ttl=47 time=548.672 ms
64 bytes from 8.8.8.8: icmp_seq=35 ttl=47 time=276.096 ms
64 bytes from 8.8.8.8: icmp_seq=36 ttl=47 time=593.506 ms
64 bytes from 8.8.8.8: icmp_seq=37 ttl=47 time=410.813 ms
64 bytes from 8.8.8.8: icmp_seq=38 ttl=47 time=170.039 ms
64 bytes from 8.8.8.8: icmp_seq=39 ttl=47 time=386.515 ms
64 bytes from 8.8.8.8: icmp_seq=40 ttl=47 time=282.680 ms
64 bytes from 8.8.8.8: icmp_seq=41 ttl=47 time=501.584 ms
64 bytes from 8.8.8.8: icmp_seq=42 ttl=47 time=728.205 ms
Request timeout for icmp_seq 44
Request timeout for icmp_seq 45
Request timeout for icmp_seq 46
Request timeout for icmp_seq 47
64 bytes from 8.8.8.8: icmp_seq=48 ttl=47 time=432.355 ms
64 bytes from 8.8.8.8: icmp_seq=49 ttl=47 time=449.570 ms
64 bytes from 8.8.8.8: icmp_seq=50 ttl=47 time=468.061 ms
64 bytes from 8.8.8.8: icmp_seq=51 ttl=47 time=262.349 ms

--- 8.8.8.8 ping statistics ---
52 packets transmitted, 30 packets received, 42.3% packet loss
round-trip min/avg/max/stddev = 86.994/995.304/4460.189/1016.365 ms

DB
DB

DB

Ebene
4
5000 / 5000
Punkte
Team

Hallo Alandexter, in dem verlinkten Thread wurde bereits alles gesagt, was wir an Informationen haben. Zudem kann man auch im Thread selber lesen, dass auch andere User durchaus das WLAN mit VPN nutzen konnten. Es ist aktuell noch Konfigurationsabhängig und es wird weiter an einer Verbesserung gearbeitet. Auch wenn es aktuell bei Ihnen noch nicht funktioniert, kann ich nur um Geduld bitten. /no