KTCP silently losing packets

[Mellvik]

[I've just noticed that this happens, not attempted to analyze what's going on yet]

When ktcp receives IP packets with checksum errors, it reports (prints) the error, then discards the packet. Fine, except the tcp level doesn't notice that there is a packet missing. Thus no NAK and no request for a retransmit. The incoming file (if it's a file transfer) ends up short - and ftp thinks everything is just fine.

The sending ftp client reports the correct number of bytes transferred - as expected, what the receiving ftpd thinks must be looked at.

[ghaerr]

I'm guessing this only occurs at the end of a received file, right? That would increase the chances this has something to do with a synchronization problem at the time a FIN is sent over the wire, specifically possibly if/when the sender initially sends a data packet with FIN set (which some TCP implementations do for efficiency) which gets dropped, then possibly resends a FIN only and/or ktcp gets confused in a CLOSE_WAIT state. It would also be nice to know whether the sender has entered a FIN_WAIT1/2 state or not after sending the final data packet + FIN, to rule out other possibilities, but not required.

I've looked hard at the ktcp tcp.c::tcp_process() and can't see an obvious problem, as that routine will (silently unless debug is on) drop TCP packets if any are received out of order, including DATA, DATA+FIN or FIN alone. I can see a case where a RST could cause a problem, but doubt that's being received.

That said, probably a good idea to get a trace with debug_tcp, debug_close debug_window and debug_tune on for sure.

Checking netstat output for IP Bad Checksum and TCP Dropped packet counts would also be informative, as the latter will show up when TCP packets are dropped on bad sequence numbers.

Thus no NAK and no request for a retransmit.

Of course, there are no NAKs, only ACKs sent/received. In most cases ktcp will wait for the sender to timeout for retransmits. IIRC ktcp only offensively ACKs when TCP sequence numbers don't match, but we might have stuck an ACK generation in there to kick start things moving in some abnormal cases. (All of this is for receive-only; ktcp auto-retransmits only operate on outgoing TCP data packets). This will also show up in a trace. ACKs are also sent after every data packet regardless of remaining window size.

[Mellvik]

I'm guessing this only occurs at the end of a received file, right?

I don't know - and I agree that that would explain the fact that there are no TCP level errors. Like you I did look briefly at the code and found nothing obvious. The idea is to come back to it later, induce errors via a driver and debug. The situation that triggered the checksum errors in this case was timing dependent and would go away with debug - unless it could be done in QEMU of course.