Re: RST flag at end of TCP transmission

[Jeff Bruns <jeff.bruns () gmail com>]

Sake-
Thanks for the explanation. This has been an ongoing issue, as we've been
experiencing what I believe is an abnormally large amount of packet loss.
We're part of a business VPN provided by Comcast Cable, with a Cisco 2800
series router as our gatekeeper. I'm just about at the point of calling
Comcast and having them take a look, but if you've ever dealt with comcast
you understand my hesitation.

We have very few devices connected to the network, none of which should be
consuming large amounts of bandwidth. A recent speed test on my network
shows 6.21Mb/s down and 3.21Mb/s up. I often use pingtest.net to measure
jitter, delay and packet loss, but for some reason I can't get the test to
connect from my network. Likewise I've tried using iperf to evaluate my
network's bandwidth but most non-standard ports are blocked. I've attached a
pcap dump file with an example of the packet loss I'm experiencing. This has
been occurring on a daily basis sometimes 5 or 6 times a day.

Based on the dump file, can you find any indication suggesting the source of
the problem is inside the network? I've been under the assumption that the
data loss is happening before the packets hit my local network, somewhere
out in Comcast's network. Any ideas of further diagnosing the source of the
data loss?

Thanks again-

Jeff

On Mon, May 3, 2010 at 11:58 AM, Sake Blok <sake () euronet nl> wrote:

> On 3 mei 2010, at 17:32, Jeff Bruns wrote:
>
> > Thank you for your reply. As suggested, I've attached the wireshark dump
> file for the TCP transmission in question.
>
> As you said, this looks like a normal completed TCP session, except for the
> ending of it.
>
> In frame 16, the client sends the final data to the printer and sets the
> FIN flag to tell the printer it wants to end the session. That FIN is ACKed
> in frame 19, the printer has seen the FIN, otherwise it would have sent an
> ACK of 3898 instead of 3899. In frame 21 it sends its own FIN back to the
> client, however, this FIN is not ACKed by the client. In frame 22 the
> printer retransmits it's FIN, but by now, the client does not have the
> session open any more, so it sends back a RST to the printer.
>
> So what could be the problem? First of all, why does the printer send its
> FIN 2 seconds after receiving the FIN from the client. This however should
> not directly be  problem. What is a problem is that the client does not send
> an ACK after receiving the FIN from the printer.
>
> Hope this helps,
> Cheers,
>      Sake
>
>
> ___________________________________________________________________________
> Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>             mailto:wireshark-users-request () wireshark org
> ?subject=unsubscribe

Attachment: TCPwithPacketLoss.pcap
Description:

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe