Was bewirkt, dass ein TCP / IP-Reset (RST) -Flag gesendet wird?

Ich versuche herauszufinden, warum die TCP / IP-Verbindung meiner App alle 10 Minuten (genau innerhalb von 1-2 Sekunden) immer wieder Schluckauf hat. Ich habe Wireshark ausgeführt und festgestellt, dass das andere Ende nach 10 Minuten Inaktivität ein Paket mit gesetztem RST-Flag (Reset) sendet. Eine Google-Suche sagt mir, dass "das RESET-Flag anzeigt, dass der Empfänger verwirrt ist und die Verbindung abbrechen möchte", aber das ist ein wenig zu kurz für das Detail, das ich brauche. Was könnte das verursachen? Und ist es möglich, dass ein Router auf dem Weg dafür verantwortlich ist, oder würde dies immer vom anderen Endpunkt kommen?

Bearbeiten: Zwischen meinem Computer und dem anderen Endpunkt befindet sich ein Router (insbesondere ein Linksys WRT-54G). Gibt es etwas, nach dem ich in den Router-Einstellungen suchen sollte?

Ein "Router" könnte alles tun - insbesondere NAT, was jede Menge fehlerbehafteten Durcheinander mit dem Verkehr beinhalten könnte ...

Ein Grund, warum ein Gerät eine RST sendet, ist die Reaktion auf den Empfang eines Pakets für einen geschlossenen Socket.

Es ist schwierig, eine feste, aber allgemeine Antwort zu geben, da jede mögliche Perversion seit ihrer Einführung auf TCP besucht wurde und alle möglichen Personen möglicherweise RSTs einfügen, um den Datenverkehr zu blockieren. (Einige 'nationale Firewalls' funktionieren zum Beispiel so.)

Führen Sie einen Paket-Sniffer (z. B. Wireshark) auch auf dem Peer aus, um festzustellen, ob der Peer den RST sendet oder jemand in der Mitte.

Ich habe gerade einige Zeit damit verbracht, dieses Problem zu beheben. Keine der vorgeschlagenen Lösungen hat funktioniert. Es stellte sich heraus, dass unser Systemadministrator versehentlich zwei unabhängigen Servern, die verschiedenen Gruppen angehören, aber im selben Netzwerk sitzen, dieselbe statische IP zugewiesen hat. Die Endergebnisse waren zeitweise unterbrochene vnc-Verbindungen, ein Browser, der mehrmals aktualisiert werden musste, um die Webseite abzurufen, und andere seltsame Dinge.

RST wird von der Seite gesendet, die das aktive Schließen ausführt, da es die Seite ist, die die letzte Bestätigung sendet. Wenn es also FIN von der Seite empfängt, die das passive Schließen in einem falschen Zustand ausführt, sendet es ein RST-Paket, das der anderen Seite anzeigt, dass ein Fehler aufgetreten ist.

Einige Firewalls tun dies, wenn eine Verbindung x Minuten lang inaktiv ist. Einige ISPs stellen ihre Router auch aus verschiedenen Gründen so ein.

In der heutigen Zeit müssen Sie diesen Zustand ordnungsgemäß behandeln (nach Bedarf wiederherstellen).

Wenn ein Router NAT ausführt, insbesondere ein Low-End-Router mit wenigen Ressourcen, werden die ältesten TCP-Sitzungen zuerst gealtert. Zu diesem RSTZweck wird das Flag im Paket gesetzt, das die empfangende Station effektiv anweist, die Verbindung (sehr unanständig) zu schließen. Dies geschieht, um Ressourcen zu sparen.

Beachten Sie, dass viele Linux-Netfilter-Firewalls falsch konfiguriert sind.

Wenn Sie etwas haben wie:

-EIN VORWÄRTS -m Zustand - Zustand VERBUNDEN, GEGRÜNDET -j AKZEPTIEREN

-A FORWARD -p tcp -j REJECT --reject-with tcp-reset

Dann kann eine Neuordnung von Paketen dazu führen, dass die Firewall die Pakete für ungültig hält und somit Zurücksetzungen generiert, die dann ansonsten fehlerfreie Verbindungen unterbrechen.

Eine Neuordnung ist besonders bei einem drahtlosen Netzwerk wahrscheinlich.

Dies sollte stattdessen sein:

-EIN VORWÄRTS -m Zustand - Zustand VERBUNDEN, GEGRÜNDET -j AKZEPTIEREN

-A FORWARD -m state --state INVALID -j DROP

-A FORWARD -p tcp -j REJECT --reject-with tcp-reset

Grundsätzlich immer, wenn Sie:

... -m state --state RELATED, ESTABLISHED -j ACCEPT

es sollte sofort gefolgt werden von:

... -m Zustand - Zustand UNGÜLTIG -j TROPFEN

Es ist besser, ein Paket zu verwerfen, als einen potenziell protokollstörenden TCP-Reset zu generieren. Zurücksetzen ist besser, wenn sie nachweislich das Richtige sind ... da dadurch Zeitüberschreitungen vermieden werden. Aber wenn es eine Chance gibt, dass sie ungültig sind, können sie diese Art von Schmerz verursachen.

Dies liegt daran, dass im Netzwerk ein anderer Prozess RST an Ihre TCP-Verbindung sendet.

Normalerweise wird RST im folgenden Fall gesendet

• Ein Prozess schließt den Socket, wenn der Socket mit der Option SO_LINGER aktiviert ist
• Das Betriebssystem führt die Ressourcenbereinigung durch, wenn Ihr Prozess beendet wird, ohne den Socket zu schließen.

In Ihrem Fall scheint es, als würde ein Prozess Ihre Verbindung (IP + Port) verbinden und nach dem Herstellen der Verbindung weiterhin RST senden.