Re: [Bug 292322] Hastd failing to g_attach device on FreeBSD 15.0

Hi Glen

It looks like, that you are running the instances in a vm:
Please add more details of your vm setup.

If you have two physical machines at hand,
please try to reproduce the bug,
with two machines running native.

That way we can sort out,
if this is a genuine bug in freebsd,
or in the interaction with some vm

The freebsd network stack is believed to be quite solid.
It would be good, if you found a new bug.

But the networking on the vm's is not that solid, yet.
That looks like, what you are experiencing.

Please tell use more about your vm setup.
What is your host os?
Have you tried that with bhyve?

We are looking forward,
to make the virtualized networking rock solid.
This is why we have bhyve

Regards
~eike




> bugzilla-noreply@freebsd.org hat am 29.08.2026 21:38 CEST geschrieben:
> 
>  
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=292322
> 
> --- Comment #7 from Glen Barber <gjb@FreeBSD.org> ---
> I independently reproduced this exact issue while testing HAST for a project
> (two FreeBSD 15.1-RELEASE VMs).
> 
> Same symptom: primary stuck at degraded, secondary logging Unable to receive
> header from tcp://...: Operation timed out., and the same g_dev_taste ...
> failed to g_attach, error=6 kernel message.
> 
> Diagnostic detail that may help confirm the root cause: a packet capture during
> a role primary attempt shows a completely clean TCP three-way handshake
> followed by ~20 seconds of total silence in both directions before the
> connection times out — confirming the network layer is healthy and the primary
> genuinely never transmits anything. 'procstat -t' on the primary's worker
> process shows kernel threads parked in sbwait with no forward progress, and
> 'truss -H' confirms zero connect/send/recv syscalls occur — consistent with
> Martin's diagnosis of the worker blocking on recv(2)/MSG_WAITALL in the
> connection-migration path.
> 
> I also confirmed this is not 15-specific: pairing a FreeBSD 16.0-CURRENT node
> (main-n288684-420428718da7) with a 15.1-RELEASE node reproduces the identical
> failure, so the affected code path is still present in HEAD as of 2026-08-29.
> 
> -- 
> You are receiving this mail because:
> You are the assignee for the bug.