Bugzilla – Bug 499
TCP ACK flag not always set after connection established
Last modified: 2009-03-17 18:07:29 UTC
Created attachment 377 [details] screenshot As the summary says.
Created attachment 378 [details] patch to fix
I have some questions about this and the patch. - TCP should always set the ACK flag once the connection is synchronized. So, just looking at the trace, it seems that the bug may rather be in not setting an ACK flag. - is the ESP intentional here, or is this an indication of something else that may be wrong with the TCP payload? ESP should not have an SPI that is all zeros.
(In reply to comment #2) > I have some questions about this and the patch. > > - TCP should always set the ACK flag once the connection is synchronized. So, > just looking at the trace, it seems that the bug may rather be in not setting > an ACK flag. I also tried to always set the ACK flag, but it made things worse (all connections were not established). I guess lack of skill on my part. I have no idea which approach is better, I am no TCP expert, I am merely responding to the wireshark warning. With the patch TCP works equally well (i.e. not very well, but that is a different story) and wireshark doesn't complain anymore. > > - is the ESP intentional here, or is this an indication of something else that > may be wrong with the TCP payload? ESP should not have an SPI that is all > zeros. > I do not know why wireshark sees ESP. This is supposed to be just 'dummy' onoff application data.
From http://www.faqs.org/rfcs/rfc793.html Acknowledgment Number: 32 bits If the ACK control bit is set this field contains the value of the next sequence number the sender of the segment is expecting to receive. Once a connection is established this is always sent. It says nothing about the ack number having to be zero, and it says the ack number should always be sent after connection established. So I think you are right, Tom.
Created attachment 398 [details] adds acks to all data packets Summary of the patch: Everywhere we called SendPendingData() formerly, now we call it such that it will tack on an ACK flag to every outgoing data packet, so long as the socket is connected. Change the receiver logic so that it can handle data+ACKs in the same packet. Gustavo, does this fix the issue you are seeing?
Comment on attachment 398 [details] adds acks to all data packets That appears to fix the problem.
Fixed in ns-3-dev 4269:78d709bebd55