1&1 Mobilfunknetz technische Aspekte (VoLTE, Wifi Calling, Roaming & uvm.)

Vielleicht kann hrgajek mit dem Timer Problem auf 1&1 zugehen, Tickets beim Drillisch Support kann man sich jedenfalls schenken?

Insgesamt muss man wohl feststellen das die Technik von 1&1 offenbar selbst andere Netze nutzt sonst wäre ihnen das sicher aufgefallen.

Ich habe es 3 mal versucht über den Drillisch Support. Dort versteht niemand das Problem. Es wird nur mit unpassenden Textbausteinen geantwortet.

Ob 1&1 selbst überhaupt etwas "merkt", bezweifle ich, da sie den gesamten Netzbetrieb an Rakuten Symphony ausgelagert haben.

Zitat:

Zusätzlich stellt Rakuten als Systemintegrator sicher, dass alle Netzkomponenten reibungslos interagieren. So profitiert 1&1 von den weitreichenden Erfahrungen, die Rakuten in den letzten Jahren beim Betrieb des weltweit ersten Open RANs in Japan gemacht hat.

so weitreichend sind die Erfahrungen dann wohl doch nicht

wahndreieck Bitte eine e-mail (gajek @ teltarif.de) an mich mit allen Details und dem Satz, dass ich Deine Kontaktdaten an 1&1 weiterleiten darf.

Das 1&1 Mailbox System scheint auch noch nicht so rund zu laufen. Ich hatte "zwei neue Nachrichten und eine gespeicherte Nachricht". Nach dem Löschen der beiden neuen Nachrichten (jeweils quittiert durch "die Nachricht wurde gelöscht") habe ich erneut die Mailbox abgefragt.

Ergebnis: zwei neue Nachrichten und keine gespeicherte Nachricht.

Zitat von wahndreieck

Insgesamt muss man wohl feststellen das die Technik von 1&1 offenbar selbst andere Netze nutzt sonst wäre ihnen das sicher aufgefallen.

Brieftauben?

Zitat von hrgajek

wahndreieck Bitte eine e-mail (gajek @ teltarif.de) an mich mit allen Details und dem Satz, dass ich Deine Kontaktdaten an 1&1 weiterleiten darf.

Mail hast du, bin mal gespannt ob da was bei rumkommt.

Zitat von wihev14596

Damit kann man nicht einmal SSH benutzen. Tolles "modernstes 5G-Netz", das die da haben.

Die Anzahl von SSH-Nutzern im Netz dürfte überschaubar sein. Außerdem lässt sich das bei SSH clientseitig mit einem "Keep-Alive" sehr einfach lösen (z.B. unter Linux mit "ServerAliveInterval=60") .

Es geht doch nicht nur um SSH, sondern darum, dass alle Hintergrundsessions von Apps mit Push Funktion(Telegram, Whatsapp, Gmail, usw.) netzseitig geschlossen werden nach 120 Sekunden Inaktivität. Keine dieser Apps sendet alle 60 Sekunden einen Keepalive, da wäre der Akku zu schnell leer. Ein typischer tcp-idle-timeout auf einer Firewall ist 3600 Sekunden und nicht 120.

Also das Problem kann ich mit 4 verschiedenen 1&1/Drillisch Verträgen (2 migriert, 2 neu abgeschlossen) nicht nachstellen. Weder gibt es Probleme mit Push-Funktionen von Telegram, Signal oder diversen Push-TANs von Finanzdienstleistern noch werden SSH Verbindungen termininert. Hierzu habe ich mehrere SSH-Verbindungen ohne KeepAlive auf einen ansonsten ungenutzten VPS gemacht und mittels "tcpdump -n -i ens192 host 61.8.155.47 >> dump.txt" kontrolliert, dass auch kein sonstiger Traffic vom Testrechner (via Hotspot im 1&1 Netz) und dem VPS entstanden ist. Auch nach >30 min/1800s Wartezeit ohne Eingabe war jede SSH session noch aufgebaut.

Die IPv4 NAT-Adressen variierten leider nur innerhalb der 61.8.155.x Range, also vermutlich desselben Core Datacenters - so dass diese Aussage vielleicht nicht allgemeingültig für das gesamte 5G Netz von 1&1 ist - aber ein grundsätzliches Problem lässt sich ausschließen.

Meine Zeit als App-Programmierer liegt schon etwas zurück, aber spätestens seit Android 8 kann eine App auch keine TCP session über einen längeren Zeitraum offenhalten, um so auf Push-Nachrichten zu warten. Diese werden von diversen Stromsparmechanismen mindestens "schlafen gelegt". Der offizielle Weg zur asynchronen Kommunikation läuft über das "Android Notification API", das mit vielfältigen Netzunterbrechungen klarkommt und dann die jeweilige App wieder "aufweckt".

Es gab mal eine Zeit (ca. August/September), da liefen die PDU-Sessions im 1&1 nicht stabil und sind ab und zu "hängeblieben" - es erfolgte also gar kein Datentransfer mehr und ein Neustart der "mobile Daten" bzw. "Flugmodus an/aus" war nötig. Aktuell ist mir das aber nicht mehr untergekommen.

Zitat von kammann

Die IPv4 NAT-Adressen variierten leider nur innerhalb der 61.8.155.x Range, also vermutlich desselben Core Datacenters - so dass diese Aussage vielleicht nicht allgemeingültig für das gesamte 5G Netz von 1&1 ist - aber ein grundsätzliches Problem lässt sich ausschließen.

Aus dem Kontext lässt sich nur sagen das Problem tritt bei dir nicht auf, daraus lässt sich Grundsätzlichkeit ebenso wenig ableiten.

Zitat

Meine Zeit als App-Programmierer liegt schon etwas zurück, aber spätestens seit Android 8 kann eine App auch keine TCP session über einen längeren Zeitraum offenhalten, um so auf Push-Nachrichten zu warten. Diese werden von diversen Stromsparmechanismen mindestens "schlafen gelegt". Der offizielle Weg zur asynchronen Kommunikation läuft über das "Android Notification API", das mit vielfältigen Netzunterbrechungen klarkommt und dann die jeweilige App wieder "aufweckt".

Auch heute lassen sich die Batterie Optimierungen abstellen (aber ja Standard ist das von dir beschriebene), bei mir ist ist jedenfalls so das die Verbindung zum Google FCM (Firebase Cloud Messaging) abreißt damit klappt keinerlei Push mehr.