Date: Fri, 20 Feb 2026 15:25:11 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 293312] fetch fails to time out during either transfer or lookup (see 293124) Message-ID: <bug-293312-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293312 Bug ID: 293312 Summary: fetch fails to time out during either transfer or lookup (see 293124) Product: Base System Version: 14.3-STABLE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: bin Assignee: bugs@FreeBSD.org Reporter: karl@denninger.net I'm not convinced this really is where it appears to be but since I'm redirected here we are. I have seen this intermittently for a very long time but finally got a reproducing link from an associate. Note that the target address DOES resolve (per "dig" or "curl" for that matter) and also DOES connect (per "curl" and complete.) In EVERY CASE if fetch is run to this target it hangs. It does NOT time out although it is specified to do so, and it is not intermittent either -- it hangs every time from multiple FreeBSD machines both on 14.3-RELEASE and also on 14.4-STABLE -- and the same problem is one I've noted for quite some time but did not report as I had no *reliable* way to make it happen -- if it hanged a second attempt would succeed, etc. Now that I have a reproduceable link it merits being reported. I am not convinced that the problem is in resolution simply because it works under curl and in addition drill, dig and nslookup all return a correct host address. The target is a "CNAME" with both IPv6 and IPv6 addresses although using either "dig" or "drill" with no switches only returns (as expected) the CNAME and correct IPv4 resolution for it thus while it LOOKS like it is hanging there I'm not convinced (e.g. buffering of output to stdout may be involved here.) Redirecting the command's output to a file along with stderr (e.g. >/tmp/xxx 2>&1) does not show when the ^C is delivered, obviously, but appears to indicate the *transfer* timed out rather than the lookup. Target on emailed request (its not my site; I do know the owner personally) and entering the target into a browser -- or using curl -- works as expected. Run with ktrace; It hangs with -vv in the same place. Note that curl to the same target completes. [karl@NewFS ~]$ ktrace fetch -T 2 -vv -o /tmp/fetch.tmp https:{elided} scheme: "https" user: "" password: "" host: "{elided}" port: "0" document: "......(elided).jpg" ---> {elided}:443 resolving server address: {elided}:443 ^CSSL options: 82004850 Peer verification enabled Using OpenSSL default CA cert file and path Verify hostname TLSv1.3 connection established using TLS_AES_256_GCM_SHA384 Certificate subject: /CN={elided} Certificate issuer: /C=US/O=Let's Encrypt/CN=E7 requesting https:{elided}jpg >>> GET {elided} HTTP/1.1 >>> Host: {elided} >>> Accept: */* >>> User-Agent: fetch libfetch/2.0 >>> Connection: close >>> <<< HTTP/1.1 200 OK <<< Server: nginx/1.28.1 <<< Date: Fri, 20 Feb 2026 14:26:11 GMT <<< Content-Type: image/jpeg <<< Content-Length: 348401 <<< Last-Modified: Thu, 05 Feb 2026 04:12:24 GMT content length: [348401] <<< Connection: close last modified: [2026-02-05 04:12:24] <<< ETag: "698418a8-550f1" <<< Expires: Thu, 31 Dec 2037 23:55:55 GMT <<< Cache-Control: max-age=315360000 <<< Strict-Transport-Security: max-age=63072000 <<< Accept-Ranges: bytes <<< offset 0, length -1, size -1, clength 348401 fetch: transfer timed out fetch: transfer interrupted $ kdump -tcst -f ktrace.out >ktrace.txt Output (~2Mb) is at http:///www.denninger.net/ktrace.txt -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-293312-227>