Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[TLDK-1] TLDK is mishandling FIN packets #6

Open
vvalderrv opened this issue Jan 2, 2025 · 0 comments
Open

[TLDK-1] TLDK is mishandling FIN packets #6

vvalderrv opened this issue Jan 2, 2025 · 0 comments

Comments

@vvalderrv
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant