Date: Tue, 16 Apr 2024 12:45:54 +0000 From: bugzilla-noreply@freebsd.org To: virtualization@FreeBSD.org Subject: [Bug 278338] bhyve deletes tap LINK0 flag (regression) Message-ID: <bug-278338-27103-VQo5Acs4wZ@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/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D278338 --- Comment #2 from Peter Much <pmc@citylink.dinoex.sub.org> --- (In reply to crest from comment #1) crest, thank You for explaining the rationale behind this. So this is rathe= r a /cultural/ change, then. I.) Yes, it is expected that the tap goes down on closing. And then the address= es and routes are removed. This was a problem here, but then the tap manpage states: " and has all of its configured addresses deleted unless the device [...] has IFF_LINK0 flag set." Which is where I found this, and why I did implement it that way. And it did work well all the time, up to 13.3 Apparently this behaviour is the purpose of the LINK0 flag here - probably = the only purpose. II.) "trusting the user to really know and intentionally set each bitfield they twiddled with".=20 That was always the tradition with unix: assuming that the operator does kn= ow what they are doing, and allowing them to shoot themeselves into the foot, = if so desired. (Because otherwise they would use some other OS where they can = pay for being nannied.) So the actual issue is now a cultural one, it is that we do no longer trust= the user (to know why they set LINK0). III.) Given that, let me elaborate on the technological impact assessment of this change of confidence, as a matter of surprize: 1. on the desktop, xterms don't open anymore 2. anaysis shows, the DNS replies are botched, and therefore the xterms cannot correctly resolve the DISPLAY host. 3. there are no errors in the named log. 4. BIND was recently updated, but the log shows it was reinstalled at the same version (otherwise we would have spent another couple of hours analysing possibly incompatible changes there). 5. detailed analysis of the resolver log shows, queries are hitting the wrong BIND view, and therefore get bogus answers (this is a 6-way named: lan/public/rootslave each authoritative and caching) 6. they are hitting the wrong BIND view because apparently they come from a bogus IP address 7. the bogus IP address is found on the tap interface 8. it is put there by net/dhcpcd 9. net/dhcpcd also was reinstalled at the same version (luckily) 10. detailled analysis shows that net/dhcpcd is putting that address there only when there is none present yet (this is also one of those pieces of software that does far too many things on it's own discretion) 11. Then finally: the addresses do disappear when a guest is rebooted=20 /from the inside/ (And installing quarterly pkg updates was the first time this was done after release of 13.3) This is not really funny. It is what one gets from surprizes.=20 Or, as I usually put it: /distrust/ just makes things far more complicated - and the price is usually paid by others. IV.) I don't see reason for a configuration choice or option. If you want to res= et the configuration of a pre-exsting tap on bhyve startup, then you could as = well just remove all the configured IP addresses alongside - then things would s= tart to fail rightaway and we would immediately see that there is an issue. Otherwise, if there are already addresses there, they are probably there fo= r a purpose. And if LINK0 was set alongside with these addresses, then that is = also probably there for a purpose. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-278338-27103-VQo5Acs4wZ>