Don't forget that even though packets might seem to come from a
sender, they might come from an intervening device. If a firewall is
in between a client and server and it doesn't see traffic on that
session for a certain period (say 2 hours) it might delete knowledge
of that session - and possibly follow up by sending a RST to the
client party.
Regards, Martin
MartinVisser99@xxxxxxxxx
On Mon, May 3, 2010 at 12:28 PM, sandeep nitta <sandeep.nitta@xxxxxxxxx> wrote:
> AFAIK, after RST, the connection need not start all over again.
>
> the RST might also be a reason if there are any malformed packets in
> the tcp stream.
>
> OR
>
> there the sender has already closed the port on whcih the connection
> was open some time back and hence the RST.
>
> OR
>
> the host has simply run out of resources.
>
>
> i dont find a definite answer to your questions, but these might be
> the possible reasons.
> if you can attach the trace file, people can look at that and probably
> analyze more.
>
> Thanks,
> Sadeep Nitta
>
>
>
> On Mon, May 3, 2010 at 6:04 AM, Jeff Bruns <jeff.bruns@xxxxxxxxx> wrote:
>> Greetings-
>> This is more of a beginners TCP question than it is a wireshark question,
>> but I haven't had much success finding the answer. I have a TCP transmission
>> that appears to have been delivered successfully and in its entirety, but
>> has an RST packet sent by the sender. There are no out of order packets,
>> packet retransmissions or other indications of stream interruption.
>>
>> It was my understanding that the reset flag was a request by the sending
>> party that the connection be reset and everything start over. That being the
>> case, I would have expected to have some packet loss or other stream issues
>> precipitate the RST flag. I also would have expected that immediately
>> following the RST flag, a new connection would be established and the whole
>> process repeated. There was no follow up connection or retransmission.
>>
>> I am close to understanding the purpose of the RST flag? Or am I way off?
>>
>> Thanks.
>>
>> ___________________________________________________________________________
>> Sent via: Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
>> Archives: http://www.wireshark.org/lists/wireshark-users
>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>> mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
>>
> ___________________________________________________________________________
> Sent via: Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
> Archives: http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
> mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
>
