https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273557
--- Comment #9 from cr...@rlwinm.de --- (In reply to Bjoern A. Zeeb from comment #7) I get the impression you don't use the VMIO_SIOCIFFLAGS ioctl if possible and the existing code works if an IP socket can be created to invoke the SIOCGIFFLAGS ioctl on. Treating the inability to create a IP new socket as non-fatal would allow deploying bhyve in a jail, but it would still depend on the net.link.tap.up_on_open sysctl. I've looked for alternatives, but the VMIO_SIOCIFFLAGS ioctl is only API I've found that's useable from inside jail a without access to an IP stack. It would be possible to fall back to VMIO_SIOCIFFLAGS only if the IP socket creation fails and keep using an IP socket if possible. I would like bhyve to always use the ioctl directly on the tap device instead of bringing the interface up indirectly by name through a socket ioctl since it covers all cases with a single code path, but any fix that allows an unpatched bhyve to be started inside a jail with both IPv4 and IPv6 disabled would help. How would you like to proceed? I'll be at EuroBSDcon later this week. Is there anything I can do to help get a fix for this regression into FreeBSD 14.0 (and errata into the older releases if release engineering agrees)? -- You are receiving this mail because: You are the assignee for the bug.
