Bug 238741 - [tcp] RACK stack causes connections to hang
Summary: [tcp] RACK stack causes connections to hang
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 12.0-RELEASE
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-net (Nobody)
Depends on:
Reported: 2019-06-21 10:52 UTC by adrik
Modified: 2020-10-23 15:21 UTC (History)
4 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description adrik 2019-06-21 10:52:28 UTC
When using the RACK tcpip stack, fetch will hang and eventually generate a timeout.
To reproduce the problem:

# uname -a
FreeBSD mail.xxx.yyy 12.0-RELEASE-p6 FreeBSD 12.0-RELEASE-p6 r349226 MAIL  amd64
# kldload tcp_rack
# sysctl net.inet.tcp.functions_default=rack
# fetch https://cpan.metacpan.org/authors/id/I/IS/ISHIGAKI/JSON-PP-4.03.tar.gz

When using wget, the same url can be retrieved without problems.
Comment 1 adrik 2019-06-28 13:44:44 UTC
I think the problem might be related to the selected TCP Congestion Control algorithm.
If I select Cdg as the TCP Congestion Control algorithm:

# kldload cc_cdg
# sysctl net.inet.tcp.cc.algorithm=cdg

Tcp connections will sometimes hang and finally timeout.
When this happens, the socket Send-Q is not empty and will never drain, so some or all data is never sent.

# netstat -6n
Active Internet connections
Proto Recv-Q Send-Q Local Address          Foreign Address        (state)
tcp6       0    383 2a02:xxxx:yyy:18.56748 2a04:4e42:9::729.443   ESTABLISHED

The same happens with IPv4 and IPv6 connections.
If I change the TCP Congestion Control to any other algorithm, the problem doesn't exist anymore.
I did a quick test with NewReno, Cubic, HTcp and Chd as the selected TCP Congestion Control algorithm and all work.