Date: Tue, 16 Apr 2024 00:44:22 +0000 From: bugzilla-noreply@freebsd.org To: virtualization@FreeBSD.org Subject: [Bug 278338] bhyve deletes tap LINK0 flag (regression) Message-ID: <bug-278338-27103-VPNjYzLiz5@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-278338-27103@https.bugs.freebsd.org/bugzilla/> References: <bug-278338-27103@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278338 crest@rlwinm.de changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |crest@rlwinm.de --- Comment #1 from crest@rlwinm.de --- It's expected that a tap interface goes down if you close it causing the addresses and routes to removed. It's annoying for a routed bhyve setup, but can be avoided by using the vmnet cloner instead of the tap cloner to create your interfaces. You should be able to get the behaviour I assume you want for a routed bhyve deployment from vmnet. I'm not sure what's the correct way to deal with the link0 flag if the tap interface is already configured before bhyve opens it. I can see arguments both way (trusting the user to really know and intentionally set each bitfield they twiddled with vs. bringing the device into its default configuration to clean up any corrupted state left over from the previous opening of the device by some other software that also used tap0). The only way to cover both cases would probably to add one more configuration option similar to noinit for serial ports. -- You are receiving this mail because: You are the assignee for the bug.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-278338-27103-VPNjYzLiz5>