Seid heute morgen geht bei o2 kein Wifi Calling und VoLTE mehr. Sowohl bei meinem Hauptarif und Partnerkarte auch mit 2 verschiedenen Handys Mi9 und Mate 10 Pro geht es nicht. Bei einem anderer User mit dem ich Privaten Kontakt habe geht es nicht mit seinem S9+. Da es 3 verschiedene Verträge und Geräte sind muss es ja an o2 liegen.
Wer hat das sonst noch festgestellt?
Ich hatte vor einer Stunde auch schon einen Beitrag dazu gesendet - de rist jedoch irgendwie nicht aufrufbar (Forumsfehler). Das Problem war sehr ärgerlich weil bei mir zuhause das Mobilfunknetz eher mäßig ist.
Ich hatte eine Analyse des Netzverkehrs durchgeführt (TCPDUMP auf dem Router): Sobald das Smartphone sich mit dem WLAN verbindet, versucht es eine IPsec Verbindung aufzubauen (via IKE Protokoll, also Ports 500 und 4500 - alles nach Standard). Allerdings meldet der O2-Server nur eine Fehlermeldung (invalid_ike_spi). Das Smartphone probiert das etwa eine Minute und gibt dann auf.
Ich nehme an, da gibt es ein Problem.
Dump (das wiederholt sich dann mehrmals bis das Smartphone entgültig aufgibt):
# tcpdump -v -i ifwan 'udp port 500 or udp port 4500'
tcpdump: listening on ifwan, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
15:43:00.746166 IP (tos 0x0, ttl 63, id 37046, offset 0, flags [df], proto UDP (17), length 492)
p4FC8B9EF.dip0.t-ipconnect.de.47289 > 89.204.152.48.isakmp: isakmp 2.0 msgid 00000000: parent_sa ikev2_init[i]:
(sa: len=44
(p: #1 protoid=isakmp transform=4 len=44
(t: #1 type=encr id=aes (type=keylen value=0100))
(t: #2 type=integ id=hmac-sha )
(t: #3 type=prf id=hmac-sha )
(t: #4 type=dh id=modp2048 )))
(v2ke: len=256 group=modp2048)
(nonce: len=32 data=(f8248bb3e110cfc426bd...0000402f00010002000300040000000800004016))
(n: prot_id=#0 type=16388(nat_detection_source_ip))
(n: prot_id=#0 type=16389(nat_detection_destination_ip))
(n: prot_id=#0 type=16430(status))
(n: prot_id=#0 type=16431(status))
(n: prot_id=#0 type=16406(status))
15:43:00.779205 IP (tos 0x0, ttl 248, id 20222, offset 0, flags [none], proto UDP (17), length 80)
89.204.152.48.isakmp > p4FC8B9EF.dip0.t-ipconnect.de.47289: isakmp 2.0 msgid 00000000: parent_sa ikev2_init[r]:
(n: prot_id=#0 type=16390(cookie) data=(00004787f6bf33379788ea02fda0476d))
15:43:00.783368 IP (tos 0x0, ttl 63, id 37048, offset 0, flags [df], proto UDP (17), length 516)
p4FC8B9EF.dip0.t-ipconnect.de.47289 > 89.204.152.48.isakmp: isakmp 2.0 msgid 00000000: parent_sa ikev2_init[i]:
(n: prot_id=#0 type=16390(cookie) data=(00004787f6bf33379788...0000402f00010002000300040000000800004016))
(sa: len=44
(p: #1 protoid=isakmp transform=4 len=44
(t: #1 type=encr id=aes (type=keylen value=0100))
(t: #2 type=integ id=hmac-sha )
(t: #3 type=prf id=hmac-sha )
(t: #4 type=dh id=modp2048 )))
(v2ke: len=256 group=modp2048)
(nonce: len=32 data=(f8248bb3e110cfc426bd...0000402f00010002000300040000000800004016))
(n: prot_id=#0 type=16388(nat_detection_source_ip))
(n: prot_id=#0 type=16389(nat_detection_destination_ip))
(n: prot_id=#0 type=16430(status))
(n: prot_id=#0 type=16431(status))
(n: prot_id=#0 type=16406(status))
15:43:00.979252 IP (tos 0x0, ttl 248, id 20404, offset 0, flags [none], proto UDP (17), length 444)
89.204.152.48.isakmp > p4FC8B9EF.dip0.t-ipconnect.de.47289: isakmp 2.0 msgid 00000000: parent_sa ikev2_init[r]:
(sa: len=44
(p: #1 protoid=isakmp transform=4 len=44
(t: #1 type=encr id=aes (type=keylen value=0100))
(t: #2 type=prf id=hmac-sha )
(t: #3 type=integ id=hmac-sha )
(t: #4 type=dh id=modp2048 )))
(v2ke: len=256 group=modp2048)
(nonce: len=16 data=(d773dbc3de31fb268361...0ec91f16c19f3ec5c21e8c330a7fd17acbf88d35))
(n: prot_id=isakmp type=16388(nat_detection_source_ip))
(n: prot_id=isakmp type=16389(nat_detection_destination_ip))
15:43:01.013843 IP (tos 0x0, ttl 63, id 37071, offset 0, flags [df], proto UDP (17), length 380)
p4FC8B9EF.dip0.t-ipconnect.de.34235 > 89.204.152.48.ipsec-nat-t: NONESP-encap: isakmp 2.0 msgid 00000001: child_sa ikev2_auth[i]:
(v2e: len=316)
15:43:02.019997 IP (tos 0x0, ttl 63, id 37163, offset 0, flags [df], proto UDP (17), length 380)
p4FC8B9EF.dip0.t-ipconnect.de.34235 > 89.204.152.48.ipsec-nat-t: NONESP-encap: isakmp 2.0 msgid 00000001: child_sa ikev2_auth[i]:
(v2e: len=316)
15:43:04.020429 IP (tos 0x0, ttl 63, id 37298, offset 0, flags [df], proto UDP (17), length 380)
p4FC8B9EF.dip0.t-ipconnect.de.34235 > 89.204.152.48.ipsec-nat-t: NONESP-encap: isakmp 2.0 msgid 00000001: child_sa ikev2_auth[i]:
(v2e: len=316)
15:43:08.020897 IP (tos 0x0, ttl 63, id 37648, offset 0, flags [df], proto UDP (17), length 380)
p4FC8B9EF.dip0.t-ipconnect.de.34235 > 89.204.152.48.ipsec-nat-t: NONESP-encap: isakmp 2.0 msgid 00000001: child_sa ikev2_auth[i]:
(v2e: len=316)
15:43:08.338999 IP (tos 0x0, ttl 248, id 28473, offset 0, flags [none], proto UDP (17), length 156)
89.204.152.48.ipsec-nat-t > p4FC8B9EF.dip0.t-ipconnect.de.34235: NONESP-encap: isakmp 2.0 msgid 00000001: child_sa ikev2_auth[r]:
(v2e: len=92)
15:43:08.441563 IP (tos 0x0, ttl 63, id 37661, offset 0, flags [df], proto UDP (17), length 108)
p4FC8B9EF.dip0.t-ipconnect.de.34235 > 89.204.152.48.ipsec-nat-t: NONESP-encap: isakmp 2.0 msgid 00000002: child_sa inf2[i]:
(v2e: len=44)
15:43:08.659728 IP (tos 0x0, ttl 63, id 37665, offset 0, flags [df], proto UDP (17), length 492)
p4FC8B9EF.dip0.t-ipconnect.de.47289 > 89.204.152.48.isakmp: isakmp 2.0 msgid 00000000: parent_sa ikev2_init[i]:
(sa: len=44
(p: #1 protoid=isakmp transform=4 len=44
(t: #1 type=encr id=aes (type=keylen value=0100))
(t: #2 type=integ id=hmac-sha )
(t: #3 type=prf id=hmac-sha )
(t: #4 type=dh id=modp2048 )))
(v2ke: len=256 group=modp2048)
(nonce: len=32 data=(798a9d46c116d4a2cb4f...0000402f00010002000300040000000800004016))
(n: prot_id=#0 type=16388(nat_detection_source_ip))
(n: prot_id=#0 type=16389(nat_detection_destination_ip))
(n: prot_id=#0 type=16430(status))
(n: prot_id=#0 type=16431(status))
(n: prot_id=#0 type=16406(status))
15:43:08.718987 IP (tos 0x0, ttl 248, id 28920, offset 0, flags [none], proto UDP (17), length 80)
89.204.152.48.isakmp > p4FC8B9EF.dip0.t-ipconnect.de.47289: isakmp 2.0 msgid 00000000: parent_sa ikev2_init[r]:
(n: prot_id=#0 type=16390(cookie) data=(00004787bb786d4d6cb8576cc3dd28ad))
15:43:08.722800 IP (tos 0x0, ttl 63, id 37670, offset 0, flags [df], proto UDP (17), length 516)
p4FC8B9EF.dip0.t-ipconnect.de.47289 > 89.204.152.48.isakmp: isakmp 2.0 msgid 00000000: parent_sa ikev2_init[i]:
(n: prot_id=#0 type=16390(cookie) data=(00004787bb786d4d6cb8...0000402f00010002000300040000000800004016))
(sa: len=44
(p: #1 protoid=isakmp transform=4 len=44
(t: #1 type=encr id=aes (type=keylen value=0100))
(t: #2 type=integ id=hmac-sha )
(t: #3 type=prf id=hmac-sha )
(t: #4 type=dh id=modp2048 )))
(v2ke: len=256 group=modp2048)
(nonce: len=32 data=(798a9d46c116d4a2cb4f...0000402f00010002000300040000000800004016))
(n: prot_id=#0 type=16388(nat_detection_source_ip))
(n: prot_id=#0 type=16389(nat_detection_destination_ip))
(n: prot_id=#0 type=16430(status))
(n: prot_id=#0 type=16431(status))
(n: prot_id=#0 type=16406(status))
15:43:08.867347 IP (tos 0x0, ttl 248, id 29085, offset 0, flags [none], proto UDP (17), length 68)
89.204.152.48.ipsec-nat-t > p4FC8B9EF.dip0.t-ipconnect.de.34235: NONESP-encap: isakmp 2.0 msgid 00000002: child_sa inf2[r]:
(n: prot_id=#0 type=4(invalid_ike_spi))
+4Es geht wieder, wenn o2 den Fehler berichtigt hat.
kann heute sein, morgen oder erst in einer Woche.
du merkst, wenn es wieder geht
Geht übrigens mit keinem der Geräte mit verschiedenen O2-Verträgen. Ich nehme auch nicht an, dass es spezifisch bei einzelnen Nutzern ist, denn laut Netzanalyse (s.o.) ist es ein globales Problem: Der Verbindungsaufbau des IKE-Protokolls (v2) haut nicht mehr hin, da wird noch nicht mal irgendwelche SIM-Kartennummern ausgetauscht, daher wird es wohl alle User betreffen. Das kennt man auch von VPN-Verbindungen in der Berufswelt wenn der VPN-Server ein Problem hat… Was anderes ist VoWifi und VoLTE nicht (SIP getunnelt durch ein IPsec VPN).
+4Das war eigentlich als Code maskiert. Nicht sicher was der gemacht hat.
Bei mir in München geht wohl seit heute morgen auch nichts, habe das allerdings nicht so registriert. Es war halt für mich erstmal nur eine grottenschlecht Verbindung. Heute Abend habe ich dann gesehen das das Symbol nicht angezeigt wurde obwohl die Funktion eingeschaltet war. Habe einiges probiert:
Funktion ein/aus
WLAN ein/aus
Smartphone ein/aus
alles in verschiedenen Reihenfolgen ohne positives Ergebnis. Der WLAN in der Wohnung funktioniert einwandfrei. Eine O2 Basisstation in der Nähe soll eine Störung haben, aber daran kann es ja wohl nicht liegen wenn es hier mehrere Meldungen gibt. Hoffentlich kriegen die bei o2 den Hintern hoch und bekommen das schnell geregelt.
Wir sind hier ja im Hochtechnologiestandort Deutschland ... oder täusche ich mich da??
Zumindest habe ich oftmals Zweifel
+4
Mit dem Verkauf von Transrapid haben wir das letzte high tech Kapitel geschlossen.
selbst der ice ist eine lahme Gurke verglichen mit den Franzosen und Japanern.
Ja, das kann ich nur bestätigen, wir sind hier auf dem absteigenden Ast und unten lauert die Mittelklasse. Siemens ist auch so ein Beispiel ... nur noch ein Schatten des einstmals großen Namen.
Was ich nicht verstehe ist das z.B. O2 im "Heimatmarkt" Spanien ein hervorragendes Netz hat und hier wird nur abkassiert bei unterirdischer Leistung, aber Vodafone und Telekom sind auch nicht viel besser ...
Ich frage mich ob o2 selbst überhaupt weiß das es nicht geht. Vorhin ging es bei mir ganz kurz so ca. für 1 Minute und das war es aber auch.
Guten Morgen, auch heute früh ( Montag ) besteht die Störung weiterhin ( kein wifi-calling und VoLTE wegen fehlendem VPN-Tunnel) . Seitens O2 scheint der Fall noch gar nicht registriert zu sein. Zumindest ist in diesem Thread noch kein Kommentar von denen aufgetaucht. Sehr bedauerlich.
Guten Morgen,
... schön zu lesen dass es offensichtlich nicht an mir liegt :-) Hier in Mittelhessen geht es auch seit Sonntag nicht .
Beste Grüße!
HALLO O2
MITLESEN, AUFWACHEN UND REAGIEREN!!!
Guten Morgen, auch heute früh ( Montag ) besteht die Störung weiterhin ( kein wifi-calling und VoLTE wegen fehlendem VPN-Tunnel) . Seitens O2 scheint der Fall noch gar nicht registriert zu sein. Zumindest ist in diesem Thread noch kein Kommentar von denen aufgetaucht. Sehr bedauerlich.
P.S.: habe O2 heute früh auf diesen denen noch unbekannten Thread hingewiesen. Der Fall war denen noch unbekannt:-( Abwarten, was hier von O2 zu dem Fall geschrieben wird.
Hallo zusammen 
,
Wir beobachten die Meldung zur Zeit und werden, sobald es Neuigkeiten gibt, Rückmeldung dazu geben.
auch ohne virtuellen “Brüllen” bekommst du hier eine Rückmeldung. Bitte beachte dazu unsere Netiquette.
Grüße,
Flo
So wie es im Moment aussieht geht es zur Zeit wieder ... mal schauen wie es weitergeht ...
Also VoLTE scheint zu gehen und WiFi Calling kann ich gerade nicht schauen, da ich nicht Zuhause bin.
Hallo,
WLAN Calling geht, VoLTE konnte ich hier noch nicht probieren.
Vielen Dank für die rasche Reaktion!
+4
Der Netzbetreiber erfüllt die gesetzlichen Vorgaben. Wenn die halt dämlich sind (😀Fläche statt Bevölkerung wäre die korrekte Vorgabe gewesen, die Lobby hat aber wieder mal Bevölkerung durchgedrückt) wird halt nicht in rumboldshausen mit seinen 487 Einwohnern ein Mast hingestellt.
75% der Bevölkerung lebt in einer Stadt. Eine Stadt hat in der Regel mindestens 10.000 bzw 25.000 Einwohner.
kann man sich also an den Fingern abzählen warum Deutschland das mieseste Netz (32 von 36) in Europa hat.
Lithauen, eines der ärmsten EU Länder liegt auf 4/32 !
Bei allen anderen Feldern ist es ähnlich. Die Rahemnbedingungen sind falsch.
Bei mir funktionieren WLAN Calls noch nicht. VoLTE scheint wieder zu gehen.
Jetzt geht beides wieder: Einmal Flugmodus und zurück. Problem war wohl dass das Telefon komplett aufgegeben hat es erneut zu probieren.
Ich kann jetzt auch bestätigen das beides wieder geht.
Hallo
ich wundere mich etwas dass es so lange gedauert hat den Fehler zu finden. Da dies ja ein deutschlandweites Problem war, hätte das doch auch am Sonntag jemand auffallen müssen? Sicher konnte man telefonieren und daher haben es nur die Leute gemerkt, die auf WLAN Calls (VoWifi) angewiesen sind oder sich die Symbole in ihrer Smartphone-Statusleiste ansehen und sich wundern warum der Rufaufbau so lange dauert.
Vielleicht solltet ihr die Netzüberwachung auch auf die “neuen” Technologien erweitern. Es sollte doch möglich sein, den IKE-Tunnelendpunkt (IPsec Tunnel für SIP-Calls) zu überwachen und regelmäßig mit einer Testsoftware aus dem öffentlichen Internet anzusprechen? Außerdem sollte es einen Test der VoLTE-Infrastruktur geben (ebenfalls Tunnel & SIP-Endpunkt).
Liebe Grüße,
Uwe Schindler
Es geht mal wieder kein WiFi Calling. Sowohl bei mir mit dem S10+ als auch bei meiner Freundin mit dem Mate 10 Pro. Hat o2 schon wieder Probleme damit?
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
