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: [email protected]
Reporter: [email protected]
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.
