There's a ton of logspam when this kernel option is disabled. https://forums.freebsd.org/threads/59348/ https://forums.freebsd.org/threads/59367/ https://forum.pfsense.org/index.php?topic=125953.0 https://redmine.pfsense.org/issues/7293 This either needs to detect the (lack of) kernel support properly and not spam the syslog, or a compile flag to disable the feature.
The idea is that TCP_FASTOPEN is always enabled, and can be enabled or disabled at run-time. What you see is merely BIND9 warning you when you start it that TCP_FASTOPEN is currently not available. It is by no mean an error, and can be safely ignored.
Thanks for response. While I get the idea, the idea is unfortunately mis-implemented. I wouldn't expect a message like "socket.c:5681: unexpected error:" to be a warning that can be safely ignored, plus the logspam is rather annoying and useless.
Feel free to report the fact that it should be a warning, or something, to the ISC. On the "spam" issue, how often do you get it ? After looking for it very hard in my logs, it seems it only happens once per ip:port it listens to, and then, only when it starts, and then never again. I hardly call that spam.
(In reply to Mathieu Arnold from comment #3) Yeah, the problem here is the box has 10 dual-stack VLANs, so this "warning" is logged 30 times on every BIND (re)start, resulting in 60 lines of junk. As for ISC, I gave up on their top-secret issue tracker that's only resulting in tons of duplicates and noise in my mailbox. Perhaps someone has a directly usable contact with them, I don't. net.inet.tcp.fastopen.enabled apparently defaults to disabled on FreeBSD and this is causing user confusion as linked in the bug report, so I thought I'd report it.
*** Bug 223595 has been marked as a duplicate of this bug. ***
Yes, this is in fact "log spam", particularly because the logging level named/bind defaults to for the use-of-fastopen error condition is quite loud (I noticed it from dmesg -a). It absolutely will concern DNS administrators when seen. People using binary kernel/world updates will not be able to cleanly work around this problem, only those who build kernel/world from source. Bug 223595 has further details, as well as very quick BIND source code references/review for what's going on. There is no way to disable this feature at compile/configure-time easily; it requires post-configure config.h modification (s/#define ISC_PLATFORM_HAVETFO 1/#undef ISC_PLATFORM_HAVETFO/g), which can be done in a port Makefile easily. The actual code in BIND 9.11.2 is in lib/isc/unix/socket.c even says that (use of) this feature in BIND is experimental. Other ports default to *disabling* TCP fastopen support (example: Bug 206338) because FreeBSD's kernel defaults to having it disabled. Given that dns/bind910 is now being marked as to-be-EoL'd-June-2018 per ISC and FreeBSD's pkg audit, can we please do something about this? The above post-configure sed would do the trick. Historically though, reporting problems of this nature to an upstream vendor, when OS-specific (and respecting kernel defaults), has fallen onto the responsibility of the port maintainer, unless a user feels passionate enough to do it themselves. Like doktonotor, I do not wish to deal with ISC's weird bug reporting system. But the FreeBSD Project used to have very close involvement with the folks at ISC (ex. Mark Andrews). Is this no longer the case? BIND is one of those "high-importance" ports.
If TCP fast open is still experimental (as the RFC 7413 actually states), I guess it should be a compile-time switch or configuration option in BIND 9.11 to disable the support of it. Maybe the port maintainer can add an option for it?
This was changed to only complain once some time ago, so, closing this.
(In reply to Mathieu Arnold from comment #8) Sorry, but I don't understand your point. As Jeremy reminded in comment #6, we are speaking about a pretty important port and I think it's worth giving it a bit of care: even if that warning can be safely ignored, don't you agree with me that it would be better to add an option to disable TCP fast open at compile time?
There is no knob to disable TCP_FASTOPEN ind BIND9 9.11, so, it cannot be made optional. When BIND9 builds, if it finds the OS supports TCP_FASTOPEN, it is built with TCP_FASTOPEN. If TCP_FASTOPEN is not enabled, named will warn, once, when it opens the socket. If *you* want it to not complain, you can patch lib/isc/unix/socket.c around line 5696 to remove the warning, or to remove the whole setsockopt(2) call block.
(In reply to Mathieu Arnold from comment #10) I'm running the GENERIC kernel, where TCP_FASTOPEN is not enabled if I understood correctly, but dns/bind911 still seems to build with TCP_FASTOPEN, because it complains at each service startup. But it should be possible to add a knob in port's Makefile which enable patching lib/isc/unix/socket.c. I'm surely not a "FreeBSD porter", but I think I'll be able to do this (from now to BIND 9.10 EoL date). I'll post here the result if I'll be able to create the patch. In the mean time, I'll continue running 9.10 on my production servers. Thanks for the explanations.
Created attachment 189801 [details] patch for net/bind911 to disable experimental TCP_FASTOPEN I've been faster than I expected! :) Please find the attached file bind911.patch I just uploaded. It's working for me when applied to the current port version: the new option TCP_FASTOPEN is disabled by default, thus applying the patch contained in files/extrapatch-disable-rfc7413. This prevents named to log useless error messages each time it starts. I'd be glad if you guys can review it and commit to Ports repository.
I think this patch is a bit overkill. As I said in c#6, and also covered in the last paragraph of initial comment of Bug 223595: > ... There is no way to disable this feature at compile/configure-time easily; it requires post-configure config.h modification (s/#define ISC_PLATFORM_HAVETFO 1/#undef ISC_PLATFORM_HAVETFO/g), which can be done in a port Makefile easily. All that should be necessary is something roughly like this in the port Makefile (the config.h pathname will need to be verified): post-configure: @${REINPLACE_CMD} -e 's/#define ISC_PLATFORM_HAVETFO 1/#undef ISC_PLATFORM_HAVETFO/' ${WRKSRC}/config.h Many ports do this, but off the top of my head see editors/vim/Makefile for an example. Someone else can figure out how to make this conditional/based around an OPTION flag. I'm 100% certain it's possible; it may involve use of a different target name (ex. post-configure-TCP_FASTOPEN-off); ports framework has changed substantially since my days as a committer.
Created attachment 189911 [details] Makefile patch to disable TCP_FASTOPEN (In reply to Jeremy Chadwick from comment #13) After a bit of test, I just verified that this lighter patch, which adds only few lines in the Makefile (please see attached file bind911-makefile.patch), is able to do the same job well.
A commit references this bug: Author: mat Date: Tue Jan 30 13:44:45 UTC 2018 New revision: 460385 URL: https://svnweb.freebsd.org/changeset/ports/460385 Log: Add a TCP_FASTOPEN option (default on) to allow not building it in. [1] It is annoying because it outputs one line saying it cannot enable TCP_FASTOPEN when the deamon starts. While there, discover that FILTER_AAAA is always enabled in 9.12+ and no longer an option, so remove it. PR: 217288 [1] (based on) Reported by: doktornotor mailinator com Sponsored by: Absolight Changes: head/dns/bind9-devel/Makefile head/dns/bind911/Makefile head/dns/bind912/Makefile
(In reply to commit-hook from comment #15) RFC 7413 was inclued in the 12-current GENERIC kernel 2 weeks ago (#1). dns/bind911 has this option enabled by default, which adversely affects (albeit in a minor way with log-file noise) all non-current users. A lot of package users of bind are going to be annoyed by the apparent lack of consideration. The maintainer should consider changing this option, TCP_FASTOPEN, to off by default - at least until FreeBSD12 is released. Ref #1 Feb 26, RFC7413 enabed by default in amd64, arm64 kernels https://svnweb.freebsd.org/base?view=revision&revision=330002 #2 https://tools.ietf.org/html/rfc7413 - so you can be the judge of its efficacy.