From nobody Tue Apr 16 12:45:54 2024 X-Original-To: virtualization@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4VJkKv4bJlz5Gnsh for ; Tue, 16 Apr 2024 12:45:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4VJkKv3b4Zz42Ff for ; Tue, 16 Apr 2024 12:45:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1713271555; a=rsa-sha256; cv=none; b=rxO2XS9WQw91dFKCmuQi6r2L2bWnxunllP/tj/Y3p9HbnG6U3mmP6HvhSHRM+EwkQWJPj1 nV2RkgDPxPmGYMQChTnxQjT7LWvqT/Ca+lkCgWP/EeFjYM57RVmobhoLzSwkWqZpIZui+a Xe6mjiAo1+fW3KQVQSm/Daz3LT3/coF/Ot5a126i3fbSDNPMDJIIQc8mML8ZGUBYs2c1VI sxVDQzgoocgQNwKQx7ioA6u3NNf7XD9D/RO4najntHTRa4LG8UDZM3bFvfWvlqfqiiOhGQ f8JvhqQDDUqv7Y9GI5HQRSTAAMxKboc4nYNKRKsjGpkq8ufX2b+weR8Rf/UI8A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1713271555; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rUIL9UBXA88BCUDyH4U+tcTOxxmh9WDIR4fKphWPNg4=; b=iCM3WCGCGfb/9ZhkrKz4veWrXqwmSw+0u/55krLWvmrTh7wO3iokaSq2MRnHHxLBNBxqSQ C84YRmJ3nfLHawTtgQxQXP1Qq2sEwukLCsKnAT6xwdMA2F79lhjmTDb04NvdA27OQcvpO+ fy+Q6TbA8iuD2b+py7lQGPTccDD28nGrFnOiVhieOu3bQu0AC+obnKIIGqL2ekkfYq4IyD gDc61IqIXolLUUS7qUvOuSGCxH+LSNDpFVyNOFt3YgdlNqSDHVsUVWnvLxmkfxgJ1fKyas bsCX7vO4xk16mJdr1HneFHvGLnUISrefJwvadyQDP95mJgtWU+NFtx9D+wcHCg== Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 4VJkKv38wTzjpT for ; Tue, 16 Apr 2024 12:45:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 43GCjtVg086337 for ; Tue, 16 Apr 2024 12:45:55 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 43GCjtUc086336 for virtualization@FreeBSD.org; Tue, 16 Apr 2024 12:45:55 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: virtualization@FreeBSD.org Subject: [Bug 278338] bhyve deletes tap LINK0 flag (regression) Date: Tue, 16 Apr 2024 12:45:54 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bhyve X-Bugzilla-Version: 13.3-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: pmc@citylink.dinoex.sub.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: virtualization@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated List-Id: Discussion List-Archive: https://lists.freebsd.org/archives/freebsd-virtualization List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-virtualization@freebsd.org Sender: owner-freebsd-virtualization@FreeBSD.org MIME-Version: 1.0 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D278338 --- Comment #2 from Peter Much --- (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.=