Ja 10 Min ist schon ganz gut. Aber eher das unterste Limit.
Ich würde Werte wie die typischen home CPEs nehmen.
Fritzboxen z.B haben.
TCP 900 Sekunden (15 Minuten)
UDP 300 Sekunden (5 Minuten)
Und für v6 könnte man 3600 Sekunden (1h) nehmen.
Das dürfte für die meisten Dienste passen.
Kann man nur spekulieren.
- Vielleicht tatsächlich ein Regionales Problem in einem oder mehreren der Core Rechenzentren. Falsche Konfiguration eingespielt oder teile vergessen.
- Endgeräteabhängig, vielleicht nimmt das Netz verschiedene Profile für bestimmte Endgeräte
Kann auch Protokollabhängig sein. Google nutzt für Verbindungen zur seiner Cloud neben TCP teilweise QUIC. Das ist UDP basierend und damit von kurzen Session-Timern weniger anfällig.
Gibt sicher noch x andere mögliche Punkte wo das zerbrechen könnte.
Edit: Fairerweise konnte ich den Fehler heute bisher auch nicht mehr nachvollziehen. Vielleicht hat 1&1 ja tatsächlich nach der Mail von Henning etwas angepasst.
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.
ZitatMeine 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.
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.
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.
Könnte ein kompatibilitätsproblem mit Gruppennachrichten zwischen Apple Clients und einigen von Carriern eingesetzten RCS Server Software sein.
Telekom und Vodafone verwenden ihre eigenen RCS implementationen, O2 die Google Jibe Cloud.
Hier in NRW bekomme ich immer zwischen 61.8.136.x-139.x, weiterhin mit TCP-Zwangstrennung nach 2 Minuten Inaktivität.
Es sind ja de facto IPv6-only-Zugänge.
Auch die v6 Sockets werden nach kurzer Zeit gekillt. Das ist also kein reines v4 Nat Thema.
Ja die NAT Timer sind viel zu aggressiv, meine GMX Free Tests waren auch eher enttäuschend.
1&1 scheint den NAT Pool erweitert zu haben.
Er geht soweit ich sehen konnte von 61.8.128.0 - 61.8.147.255 (insgesamt ein /20 + /22) also 5120 IPs.
Mir gelingt es nicht, einen Gruppenchat mit RCS auf iOS einzurichten. Mit iPhone-Gesprächspartnern und iMessage kein Problem, individuelle Android-Chats gehen mit RCS, aber sobald mehrere iMessages und eine Android-Nummer hinzugefügt werden sollen möchte das iPhone auf MMS springen, das hier natürlich deaktiviert ist. Klappt das bei jemandem zufällig?
Ich hab kein iPhone hier, aber das sollte gehen solange alle Teilnehmer rcs haben (und verbunden sind). Sonst wird der Chat auf Sms/mms umgestellt.
Teilweise wohl aber noch etwas wackelig.
