Bestimmen der Ursache für das Trennen von TCP-Verbindungen

Es gibt also einen Dienst, der einen Port überwacht, und es gibt einen Client, der eine Verbindung dazu herstellt (TCP-Protokoll). Der Client und der Server versuchen sich von Zeit zu Zeit gegenseitig zu "pingen". Dies ist beispielsweise der Client, der den Server anpingt:

00:34:04.343401 IP 192.168.1.10.57927 > myserver.com.mmcc: Flags [P.], seq 86470:86624, ack 6652727, win 4096, options [nop,nop,TS val 585141111 ecr 389969418], length 154 00:34:04.344196 IP myserver.com.mmcc > 192.168.1.10.57927: Flags [.], ack 86624, win 65535, options [nop,nop,TS val 389970019 ecr 585141111], length 0 00:34:04.344419 IP myserver.com.mmcc > 192.168.1.10.57927: Flags [P.], seq 6652727:6652833, ack 86624, win 65535, options [nop,nop,TS val 389970019 ecr 585141111], length 106 00:34:04.344467 IP 192.168.1.10.57927 > myserver.com.mmcc: Flags [.], ack 6652833, win 4092, options [nop,nop,TS val 585141112 ecr 389970019], length 0 

Es gibt jedoch einen besonderen Fall mit einem Mobilfunk- / GSM-Internetprovider, der kürzlich etwas in seinem Setup geändert hat, und die gleiche Verbindung bricht nach weniger als 15 Sekunden (!) Im Ruhezustand ab. Wenn Sie ständig im Sekundentakt Pakete senden und den Dienst aktiv nutzen, ist alles gut. Tun Sie nichts mehr und es endet damit, dass beide Parteien versuchen, die andere zu sprechen und keine Antwort erhalten. Dies geschieht natürlich zu zufälligen Zeitpunkten, aber alle innerhalb einer Minute nach der letzten Aktivität:

Client-Seite (die erste Zeile wird wiederholt, wobei sich nur etwa 45 Sekunden Zeitstempel unterscheidet):

00:44:57.224638 IP macpro.office.58180 > myserver.com.mmcc: Flags [P.], seq 99638:99792, ack 6984799, win 4096, options [nop,nop,TS val 585785321 ecr 389975387], length 154 00:45:03.319226 IP macpro.office.58180 > myserver.com.mmcc: Flags [R.], seq 99792, ack 6984799, win 4096, length 0 

Serverseite (geht genau so und dann stumm):

23:59:37.369320 IP 192.168.1.3.fmpro-internal > my.gprs.network.com.27581: P 59596370:59596460(90) ack 21549606 win 65535 <nop,nop,timestamp 389985343 586356990> 23:59:37.369415 IP 192.168.1.3.fmpro-internal > my.gprs.network.com.27581: F 90:90(0) ack 1 win 65535 <nop,nop,timestamp 389985343 586356990> 23:59:38.288366 IP 192.168.1.3.fmpro-internal > my.gprs.network.com.27581: FP 0:90(90) ack 1 win 65535 <nop,nop,timestamp 389985352 586356990> 23:59:40.288991 IP 192.168.1.3.fmpro-internal > my.gprs.network.com.27581: FP 0:90(90) ack 1 win 65535 <nop,nop,timestamp 389985372 586356990> 23:59:44.290952 IP 192.168.1.3.fmpro-internal > my.gprs.network.com.27581: FP 0:90(90) ack 1 win 65535 <nop,nop,timestamp 389985412 586356990> 

Dies geschieht auf verschiedenen Servern, die sich an verschiedenen Orten befinden und beim Testen mit verschiedenen Diensten, die offene Verbindungen aufrechterhalten, sowie mit verschiedenen Client-Computern. Das einzige, was zwischen ihnen gemeinsam ist, ist dieser mobile Internetzugang, der nur von Kunden genutzt werden darf. Nur wenn es verwendet wird, tritt das Problem auf.

Die Frage ist also, warum so etwas passiert und was ich tun kann, um zu verstehen, was wirklich vor sich geht.