[En-Nut-Discussion] NutTcpStateActiveOpenEvent fails for "tiny" connections

[Harald Kipp]

Malte Marwedel wrote:
> some time ago, I reported, that the ftp server did not work with small 
> files:
> http://lists.egnite.de/pipermail/en-nut-discussion/2009-November/011418.html
> I traced down what the problem is, and found that  in
> NutTcpStateActiveOpenEvent(TCPSOCKET * sock)
> 
> if(sock->so_state == TCPS_SYN_SENT)
>    NutEventWait(&sock->so_ac_tq, 0);
> if (sock->so_state != TCPS_ESTABLISHED)
>    return -1;
> 
> Returns -1 because the so_state is already TCPS_CLOSE_WAIT.
> I can see with Wireshark, that the data bytes are properly transmitted 
> and the host sent already a FIN.
> 
> Is there any simple solution for the problem? I don't know not enough 
> about the TCP state machine to predict if some unwanted side effects 
> could happen if I replace it with
> if ((sock->so_state != TCPS_ESTABLISHED) && (sock->so_state != 
> TCPS_CLOSE_WAIT))

After analyzing the situation I think, that you are right and your
solution is correct as well.

Why wasn't this discovered earlier, as it applies to all TCP
connections, not just FTP?

Answer: It is most uncommon, that a client opens a connection and
receives some data from a server including a FIN.

Why did I never see this problem?

Answer: I found only very few FTP clients working reliable . A few weeks
ago I discovered, that Nut/OS FTP violates the RFC. It opens the
listening port before a transfer command, but should open it immediately
after the PASV command.

- Some clients don't care, those I found reliable.
- Some fall back to ACTIVE mode or do not use PASSIV mode by default.
Those I found unreliable and probably I experienced the problem you
discovered.
- Some simply break the connection.

I'm not yet sure, if your solution will completely fix it. But it is
definitely required.

And don't tell us, you are not familiar with the TCP state machine! This
was excellent detective work.

Harald