[TLDK-1] TLDK is mishandling FIN packets #6
Description
Problems happens with dpdk-probe, code at https://github.com/weka-io/dpdk-probe/tree/tcp.
Run with:
dpdk-probe -- --ip=<ip> --static-arp=<client arp entry>
Open a connection to <ip> port 7. Anything sent is echoed back. When you close down the client side, however, a trace dump shows that the FIN packet gets ignored (as well as all duplicates).
On the server (DPDK) side, the error callback for the session gets called, but the packets themselves are rejected with errno 34 (Numerical result out of range).
I believe the root cause is that TLDK does not count the FIN as occupying a sequence number that needs to be ACKed, in violation of RFC 793 section 3.3:
We have taken advantage of the numbering scheme to protect certain control information as well. This is achieved by implicitly including some control flags in the sequence space so they can be retransmitted and acknowledged without confusion (i.e., one and only one copy of the control will be acted upon). Control information is not physically carried in the segment data space. Consequently, we must adopt rules for implicitly assigning sequence numbers to control. The SYN and FIN are the only controls requiring this protection, and these controls are used only at connection opening and closing. For sequence number purposes ... the FIN is considered to occur after the last actual data octet in a segment in which it occurs.
I believe this is causing TLDK to consider the FIN a retransmission, rather than new data that needs to be acknowledged.