MIME-Version: 1.0 X-RT-Original-Encoding: utf-8 Content-Transfer-Encoding: binary Content-Type: text/plain; charset="utf-8" X-RT-Interface: Web Content-Disposition: inline References: <20170227041130.33E766544B34@rock.dv.isc.org> Message-ID: In-Reply-To: X-Mailer: MIME-tools 5.508 (Entity 5.508) RT-Send-CC: Content-Length: 1424 I agree with Mark, as of today enabling TCP Fast Open for a listening socket on FreeBSD requires compiling a custom kernel, tuning a sysctl value *and* an explicit setsockopt() call. That being said, the current state of things causes confusion for users and thus there is room for improvement. I implemented two things in rt44754: - an additional sysctl-based runtime check for TCP Fast Open support on FreeBSD, as suggested by Francis, which logs a one-time notice if TCP Fast Open support is available, but disabled by sysctl, - a configure option to forcibly disable TCP Fast Open support, as suggested in #45376. Thanks to the above: - BIND will no longer log setsockopt() errors when running on FreeBSD kernels completely lacking TCP Fast Open support. - BIND will only notify the user once that it is running on a FreeBSD kernel with TCP Fast Open support available, but disabled via sysctl. - BIND will still generate a proper error message when TCP Fast Open is available and enabled, but setsockopt() fails. - If at some point in the future FreeBSD decides to enable TCP Fast Open support by default, neither we nor BIND packagers will have to do anything in order for BIND to start using it. - If any other OS out there turns out to suffer from similar issues, we will have a ready-to-use compile-time workaround. Any thoughts on this are welcome.