TCP reset

[Verwijderd]

Hallo,

Heb een gedetailleerde vragen over TCP/IP;

Tijdens het onderzoeken van unscheduled application disconnects ontdekte ik dat TCP een packet stuurt met de RST flag op 1. Nu is mijn hamvraag;

(1) Treedt een TCP reset alleen op door fout in de TCP- of applicatielagen?
(2) Of kan het ook veroorzaakt worden door een fout in de lager gelegen netwerklagen?

Bovenstaande is belangrijke input voor het bepalen van de oorzaak van de problemen op de applicatielaag.

Bij voorbaat dank, net-werker

[TrailBlazer]

een reset kan enkel geinitieerd worden door een hogere laag. Het zou erg vreemd zijn als een laag2 protocol. Opeens laag3 pakketten gaat versturen

[CyBeR]

Verwijderd schreef op 19 mei 2004 @ 08:59:

(2) Of kan het ook veroorzaakt worden door een fout in de lager gelegen netwerklagen?

Niet direct. Wel indirect. Als 't kabeltje dusdanig lang los zit dat er een timeout optreedt bijvoorbeeld.

[TrailBlazer]

Ok dan zal inderdaad als gevolg van de signalen die het laag 3 proto van het laag2 proto krijgt het laag3 proto een reset sturen

[Verwijderd]

Wanneer wordt de RST verstuurd? Gedurende een lopende transmissie of tijdens de handshake?

[Nvidiot]

Een reset wordt gestuurd wanneer:
* SYN request naar poort waar niet naar geluisterd wordt
* Applicatie/socket wordt afgebroken in plaats van netjes gestopt
* Na een niet gedetecteerde reboot van de server weer een data pakketje ontvangen (client denkt dat de verbinding open is en stuurt dus gewoon weer data)


Dit alles uit TCP/IP Illustrated Volume 1 van W. Richard Stevens (geweldig boek over tcp/ip)

[Verwijderd]

JeroenR > De TCP reset wordt gedurende een open TCP socket gestuurd.

TCP Illustrated suggereert inderdaad dat een TCP reset alleen optreedt door fouten in de transmissie of hogere (applicatie) lagen.

De netwerkkabel eruit trekken zou dus GEEN TCP reset maar een nette afsluiting (FIN) van de TCP connectie moeten geven.

[SED]

Bekijk dit artikel eens..

http://kerneltrap.org/node/view/3072

[mindwise]

Het lijkt me fysiek onmogelijk om als de kabels eruit liggen een nette fin - fin/ack - ack sequence te krijgen.

Er zal bij gebrek aan kabel lijkt mij een 'timeout' plaatsvinden.

* or was this tooooo obvious?