sd.org; s=dkim; t=1718194677; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=r+VQit+D9XEUxHVm75FRFIuSb59x5uiBgBADuKT7zgE=; b=H7fLsv60Tr6D3I2nVUlRzUnwU2/fzr3zXijtz4L9rKDAO1pdAljgM9vhs+RCxqlQ2Ab3av 5v7TDQYvvh/C6vdCdAjHWGKwyXQBVGBuvsZGTFs1zY9el+9iXlZy++R1SjAMr48NqnHoqM KjwmGHuewfYDeouulzR2AKPpmnmlLv94JhPE5uIa0cr6la0eEz1XYKODP2EkKDTlTUN+96 C/UgTXRsbD9PTBXdP9IXbMJiM+xq2Yaus8DjjYVXktjBUuWdK8Bha7gZW77BVzlr+4w+ua fl+tL+r0PYmgvS336EFRg59hn0vbnVLQc3EL1o+fCP68sNeNMwP5pfMB31tEmg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1718194677; a=rsa-sha256; cv=none; b=LSEIZjOTzKKsTIR/g8Nj+MO/C4ZV1HMlAH2CO6sofJH7K9t6+lZPuavgBpcjVZZ+0gHt56 W6bE+wSWMfudWJTe5w1eFVju4kStT9bSwG7dcg4E+ToZ+LLD3O3mjPmYdETkheEU3abdqw xujW38/o/rtvcSIz4nFPTDYXDGHYYMWhhEOEABapSKv3rX5z/fiozCZeAmMc/d+ywEZfNh BIkOgU9VUnZksUgo1wJ9q7aemDUF6Ie9mCC2+bY0VJMU0QBxiu4vvfy6JhV4SQTIGCtcHs a8pY4iPhuIHfel/BDfAtCvNajYgxkIPMTv7WqgxWTW3jinMHfgTf4PKNL7WbWQ== 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=1718194677; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=r+VQit+D9XEUxHVm75FRFIuSb59x5uiBgBADuKT7zgE=; b=O1TD/923nYYrqI0U4iedhYw3/xR0IoHdQOl5WQY8GiVl4eqwx0HmElSKVXmp7zYVZrELA5 4vITlkD5aIXGTmgssGKGQFoNLV603U1l4xlsazTBCBzNKFunMDjkD2WV23BTczx2NuhUKE aay6L/VIstxgkeK5PGDDtI25EHvAny/iC6lhn/Gmqc+TcX4ieAxhmUpTRbcPP4Uv5UFQvE wf3y6UIPQ9CzY557rcw2/NKlgcykhdkQqcIXgeBbiqw258JhMj22rApgQcC21EY11n7Spk 1JzhjCzYTb3mP7iRJU686kWSHC6TYkBKHuu723POd2lOI6G+bNYD1bPDrC7sUg== Received: from mail.evolve.de (mail.evolve.de [213.239.217.29]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.evolve.de", Issuer "R3" (verified OK)) (Authenticated sender: grembo/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Vzl1J4Tjrz185R; Wed, 12 Jun 2024 12:17:56 +0000 (UTC) (envelope-from grembo@freebsd.org) Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id 6e3650cc (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 12 Jun 2024 12:17:54 +0000 (UTC) Date: Wed, 12 Jun 2024 14:15:49 +0200 From: Michael Gmelin To: "Poul-Henning Kamp" Cc: Michael Gmelin , Ronald Klop , current@freebsd.org Subject: Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out Message-ID: <20240612141549.058ec756.grembo@freebsd.org> In-Reply-To: <202406121128.45CBScQ1010455@critter.freebsd.dk> References: <202406120747.45C7lRGZ009491@critter.freebsd.dk> <413984193.6719.1718185609109@localhost> <202406121039.45CAdal6010274@critter.freebsd.dk> <20240612125217.68483cf9.grembo@freebsd.org> <202406121128.45CBScQ1010455@critter.freebsd.dk> X-Face: $wrgCtfdVw_H9WAY?S&9+/F"!41z'L$uo*WzT8miX?kZ~W~Lr5W7v?j0Sde\mwB&/ypo^}> +a'4xMc^^KroE~+v^&^#[B">soBo1y6(TW6#UZiC]o>C6`ej+i Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEWJBwe5BQDl LASZU0/LTEWEfHbyj0Txi32+sKrp1Mv944X8/fm1rS+cAAAACXBIWXMAAAsTAAAL EwEAmpwYAAAAB3RJTUUH3wESCxwC7OBhbgAAACFpVFh0Q29tbWVudAAAAAAAQ3Jl YXRlZCB3aXRoIFRoZSBHSU1QbbCXAAAAAghJREFUOMu11DFvEzEUAGCfEhBVFzuq AKkLd0O6VrIQsLXVSZXoWE5N1K3DobBBA9fQpRWc8OkWouaIjedWKiyREOKs+3PY fvalCNjgLVHeF7/3bMtBzV8C/VsQ8tecEgCcDgrzjekwKZ7TwsJZd/ywEKwwP+ZM 8P3drTsAwWn2mpWuDDuYiK1bFs6De0KUUFw0tWxm+D4AIhuuvZqtyWYeO7jQ4Aea 7jUqI+ixhQoHex4WshEvSXdood7stlv4oSuFOC4tqGcr0NjEqXgV4mMJO38nld4+ xKNxRDon7khyKVqY7YR4d+Cg0OMrkWXZOM7YDkEfKiilCn1qYv4mighZiynuHHOA Wq9QJq+BIES7lMFUtcikMnkDGHUoncA+uHgrP0ctIEqfwLHzeSo+eUA66AqzwN6n 2ZHJhw6Qh/PoyC/QENyEyC/AyNjq74Bs+3UH0xYwzDUC4B97HgLocg1QLYgDDO1v f3UX9Y307Ew4AHh67YAFFsxEpkXwpXY3eIgMhAAE3R19L919nNnuD2wlPcDE3UeT L2ytEICQib9BXgS2fU8PrD82ToYO1OEmMSnYTjSqSv9wdC0tPYC+rQRQD9ESnldF CyqfmiYW+tlALt8gH2xrMdC/youbjzPXEun+/ReXsMCDyve3dZc09fn2Oas8oXGc Jj6/fOeK5UmSMPmf/jL+GD8BEj0k/Fn6IO4AAAAASUVORK5CYII= List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Wed, 12 Jun 2024 11:28:38 +0000 "Poul-Henning Kamp" wrote: > -------- > Michael Gmelin writes: > > > You can do an interface route hack > > I think you misunderstand the situation. I completely understand the situation and I can feel your pain, I just wanted to throw in how to reach the default gateway when using a /32 mask. Hence me ending with "in the context of deciding on default behavior when no mask is given this is probably not very helpful". Maybe no news for those following this thread, so sorry if the noise annoyed you. > > We are talking about people who have /etc/rc.conf files which relied > on how default netmasks have worked for nearly three decades, > > Now that we have changed that default, many of them will see a > single line rapidly scroll off their console, and a set of very > bewilding symptoms of DNS not working correctly. We had similar breaking changes with the route command[0] (personally I really would like to support the same syntax for ip/netmasks that is accepted by pf.conf, but that's off-topic). If I remember correctly, there was also a breaking change in the syntax on how to create vlandev's recently. > > The solution is not for them to apply some weird, complex and > unnecessary interface configuration. Agreed. > > The solution is for us to not break their configuration in the first > place, or at least make it much more obvious to them, where the > problem is to be found. Agreed as well. > > Defaulting to a /8 netmask for 192.168.x.y does not make *any* sense > ever. Agreed - for RFC1918 addresses at least applying the natural default netmasks (/8, /10, and /16) would feel more logical. The question is if adding all this magic actually makes sense, or if it wouldn't be better to just not accept an IP without netmask anymore (like suggested, make it emit a warning or even make it an error). Ideally, this should have been a warning/deprecation notice a while ago. Going back to previous behavior is probably not an option at this point. One way forward could be to support validating interface settings in rc.conf by using the a "check" or "configtest" subcommand - this is already used by many rc scripts (e.g., `service pf check`, `service nginx configtest`). So there could be `service netif check`, which can be run manually as well as automatically as part of freebsd-update/pkgbase (ideally on a updated config files, but **before** the installation is actually done). It could also run automatically during boot and display an error + sleep 5 in case it finds any issues to warn the admin. Adding such `check` subcommands could actually benefit many rc scripts (e.g., `service mountlate check`). Being able to call check on all rc scripts supporting it with one command could also help admins to identify problems early and therefore give more confidence when reboot testing configuration changes. Best Michael [0]https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276092 -- Michael Gmelin