Che cosa causa l'invio di un flag di ripristino TCP / IP (RST)?

Sto cercando di capire perché la connessione TCP / IP della mia app continua a singhiozzare ogni 10 minuti (esattamente, entro 1-2 secondi). Ho eseguito Wireshark e ho scoperto che dopo 10 minuti di inattività l'altra estremità sta inviando un pacchetto con il flag di ripristino (RST) impostato. Una ricerca su Google mi dice "il flag RESET significa che il ricevitore è diventato confuso e quindi vuole interrompere la connessione", ma questo è un po 'meno dei dettagli di cui ho bisogno. Che cosa potrebbe causare questo? Ed è possibile che qualche router lungo il percorso ne sia responsabile o provenga sempre dall'altro endpoint?

Modifica: c'è un router (in particolare un Linksys WRT-54G) seduto tra il mio computer e l'altro endpoint - c'è qualcosa che dovrei cercare nelle impostazioni del router?

Un 'router' potrebbe fare qualsiasi cosa, in particolare NAT, che potrebbe comportare qualsiasi quantità di problemi con il traffico causati da bug ...

Uno dei motivi per cui un dispositivo invia un RST è in risposta alla ricezione di un pacchetto per un socket chiuso.

È difficile dare una risposta ferma ma generale, perché ogni possibile perversione è stata visitata su TCP sin dal suo inizio e tutti i tipi di persone potrebbero inserire RST nel tentativo di bloccare il traffico. (Alcuni "firewall nazionali" funzionano in questo modo, ad esempio.)

Esegui uno sniffer di pacchetti (ad esempio, Wireshark) anche sul peer per vedere se è il peer che sta inviando l'RST o qualcuno nel mezzo.

Ho appena trascorso un po 'di tempo a risolvere questo problema. Nessuna delle soluzioni proposte ha funzionato. Si è scoperto che il nostro amministratore di sistema ha assegnato per errore lo stesso IP statico a due server non correlati appartenenti a gruppi diversi, ma seduti sulla stessa rete. I risultati finali erano connessioni vnc interrotte in modo intermittente, browser che doveva essere aggiornato più volte per recuperare la pagina web e altre cose strane.

Alcuni firewall lo fanno se una connessione è inattiva per un numero x di minuti. Alcuni ISP impostano i loro router per farlo anche per vari motivi.

Al giorno d'oggi, dovrai gestire con grazia (ristabilire se necessario) quella condizione.

RST viene inviato dal lato che esegue la chiusura attiva perché è il lato che invia l'ultimo ACK. Quindi, se riceve FIN dal lato che esegue la chiusura passiva in uno stato sbagliato, invia un pacchetto RST che indica dall'altra parte che si è verificato un errore.

Se c'è un router che esegue NAT, specialmente un router di fascia bassa con poche risorse, invecchierà per prime le sessioni TCP più vecchie. Per fare questo imposta il RSTflag nel pacchetto che effettivamente dice alla stazione ricevente di chiudere (molto sgraziatamente) la connessione. questo viene fatto per risparmiare risorse.

Una cosa da tenere presente è che molti firewall Linux netfilter sono configurati male.

Se hai qualcosa come:

-A FORWARD -m state --state RELATED, ESTABLISHED -j ACCEPT

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

quindi il riordino dei pacchetti può far sì che il firewall consideri i pacchetti non validi e quindi generi ripristini che interromperanno connessioni altrimenti sane.

Il riordino è particolarmente probabile con una rete wireless.

Questo dovrebbe invece essere:

-A FORWARD -m state --state RELATED, ESTABLISHED -j ACCEPT

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

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

Fondamentalmente ogni volta che hai:

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

dovrebbe essere immediatamente seguito da:

... -m state --state INVALID -j DROP

È meglio rilasciare un pacchetto quindi generare un protocollo che potenzialmente interrompe il ripristino del tcp. I ripristini sono migliori quando sono probabilmente la cosa corretta da inviare ... poiché questo elimina i timeout. Ma se c'è qualche possibilità che non siano validi, possono causare questo tipo di dolore.

Questo perché c'è un altro processo nella rete che invia RST alla tua connessione TCP.

Normalmente RST sarebbe inviato nel seguente caso

• Un processo chiude il socket quando il socket che utilizza l'opzione SO_LINGER è abilitata
• Il sistema operativo sta eseguendo la pulizia delle risorse quando il processo esce senza chiudere il socket.

Nel tuo caso, sembra che un processo stia collegando la tua connessione (IP + porta) e continui a inviare RST dopo aver stabilito la connessione.