[Ns-bugs] [Bug 902] TCP socket does not properly notify application if there's a retransmit during FIN_WAIT
code@nsnam.ece.gatech.edu
code at nsnam.ece.gatech.edu
Fri Apr 30 12:49:16 PDT 2010
http://www.nsnam.org/bugzilla/show_bug.cgi?id=902
--- Comment #6 from Antti Mäkelä <zarhan at cc.hut.fi> 2010-04-30 15:49:15 EDT ---
(In reply to comment #5)
> received successfully. I guess I'm just curious, because I would like to
> understand how the fix for bug 818 may have caused this.
Now that I actually understand what happens I take back the idea that it
might have been a regression - probably never was - I just didn't notice it
before since the missing ACK flags were confusing things anyway.
> I'm also curious why RST is sent in the first packet capture with no
> retransmissions, but that is a bit off topic for this bug.
Oh drat. That might be something else. I guess we have stumbled on yet
another bug - this time at server end.
I checked my entire pcap, and noticed that on my batch of 30 tcp streams,
searching in wireshark with tcp.flags.reset == 1, I get about 3 flows that end
up with RST.
Something is going wrong in the sense that the client does not expect the
last ACK from server in this scenario.
Furthermore, in some cases the client sends a yet another ACK to the "last
ack" (yet this doesn't result in an RST from server!).
Yet in bulk of cases everything works.
Sigh...time to file yet another bug I guess. However, this is not *so*
critical as it does not affect closing - just that an extra packet (RST or
extra ACK) gets sent - but hardly a correct operation.
--
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the Ns-bugs
mailing list