chandu valesh wrote:
> In the attachment tshark_output_jupiter.pcap (this corresponds to the
> receiver) you can see the packet whose No (ethereal serial number) is
> 4645 is retransmitted in the packets whose Nos are 4659,4681,4711,4812.
I took a quick look at your trace. The reason for retransmission
is that the x..31 machine did not acknowledge the data sent from
x..55. So x..55 kept on retransmitting. And after some time,
x..55 side terminated the connection and sent a FIN. After this,
somehow x..31 finally sent out some data along with the ACK to the
FIN. But it is too late so x..55 sent out a RST to reset the
connection.
> the application in the receiver responds to the request immediately,
> but it is delayed and sent later along with the other messages in the
> packet whose No is 4985.
Did you capture the trace in the x..55 or x..31 side? From the
trace, it seems that there are some problems in the x..31 side
such that packets cannot reach x..55. Note that even if there
is no data to be sent from x..31 to x..55, the TCP stack in x..31
should still send out an ACK to acknowledge the data from x..51.
But this ACK is missing from the trace, hence the retransmission.
So if you can also capture traffic at x..31, we can compare the
two traces and see if there is a network problem or something else.
And does `netstat -s` show some errors, such as checksum errors?
--
K. Poon.
[EMAIL PROTECTED]
_______________________________________________
networking-discuss mailing list
[email protected]
