Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out
On 2024-06-12 00:47, Poul-Henning Kamp wrote: I had a machine with this line in /etc/rc.conf: ifconfig_bla0="192.168.87.11" I found out the hard way, that this defaults to /8 now. The main symptom was that DNS was /really/ busted, which makes sense when none of the DNS servers in the 192/8 "swamp" can be reached. Since we all know that it is always DNS(SEC), I spent a lot of time having fun with that, before I noticed the /8 netmask on the interface. I agree that the class A/B/C netmask assumptions should have died long ago. But from a foot-shooting point of view, it makes no sense to default 192.168/16 to a /8 netmask. If we're going to default to /8, at the very least ifconfig should spitting out a very noisy warning and wait 5 seconds before proceeding, when the netmask is not explicitly specified. But I also think we can do better than /8. One option is to go for "limit the damage in RFC1918" and default them according to their size: reach: 10/8 172.16/12 192.168/16 That will prevent the DNS weirdness I had to figure out, and probably still DWIM in most cases. Another option is to default all three to /24, which in my experience is how people deploy RFC1918. A third option is to default any missing netmask to /24 instead of /8, which would be what I would personally have done in the first place. I couldn't agree more. CPEs, WiFi AP's and most other network(ing) equipment that most users encounter, generally default to a /24 (255.255.255.0). IMHO this would result in the least amount of POLA. :) Poul-Henning --Chris
Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out
On Wed, 12 Jun 2024 at 12:16, Michael Gmelin wrote: > > So this is simply a bug. > > I opened a code review request to fix this: > https://reviews.freebsd.org/D45570 Thank you. An EN for 14.0 and 14.1 (as suggested in your review) is certainly warranted. As for the path forward, what do folks think about changing the warning into an error in main in the near future (prior to 15.0)? That would provide about four years of releases that emit the warning, hopefully enough time for users to notice and update their configuration.
Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out
On Wed, 12 Jun 2024 15:35:58 + "Poul-Henning Kamp" wrote: > > Michael Gmelin writes: > > > @phk From which version did you upgrade? > > To be totally honest: I'm not entirely sure. Probably 13.x > @Bjoern I checked again, I'm pretty sure the problem was introduced in https://cgit.freebsd.org/src/commit/?id=4bf44dd73bc0a (this was part of adding netlink into the code). The preparation work by the late Mike Karels was consistent, as one can see in 13.x. So basically the behavior on 13.x is: - ifconfig bla0 10.1.1.1 => 10.1.1.1/8 - ifconfig bla0 192.168.1.1 => 192.168.1.1/24 This is in line with one would expect. On 14.x it's the opposite. The code in 4bf44dd73bc0a68b73f7ee50d52adf5d7cda3eb8 introduced a function to emulate the previous behavior. This function uses IN_CLASSX_NSHIFT as bitmask - therefore 10.1.1.1 uses /24 and 192.168.1.1 uses /8. To fix the code, one has to actually use the bitmask, which is (32 - IN_CLASSX_NSHIFT). So this is simply a bug. I opened a code review request to fix this: https://reviews.freebsd.org/D45570 Best Michael -- Michael Gmelin
Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out
Michael Gmelin writes: > @phk From which version did you upgrade? To be totally honest: I'm not entirely sure. Probably 13.x -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out
On Wed, 12 Jun 2024 15:11:14 + (UTC) "Bjoern A. Zeeb" wrote: > On Wed, 12 Jun 2024, Bjoern A. Zeeb wrote: > > > On Wed, 12 Jun 2024, Michael Gmelin wrote: > > > >> > >> > >> On Wed, 12 Jun 2024 14:36:35 + > >> "Poul-Henning Kamp" wrote: > >> > >>> > >>> Bjoern A. Zeeb writes: > >>> > > I had a machine with this line in /etc/rc.conf: > > > > ifconfig_bla0="192.168.87.11" > > > > I found out the hard way, that this defaults to /8 now. > > Did you track it down to a specific change? I.e. is this > ifconfig/netlink or the old kernel change from like two years(?) > ago? > > Do you have a time window when this broke as that'll help people > to bisect? > >>> > >>> I have no idea, sorry, I just freebsd-updated this one box... > >>> > >> > >> I just tried on 14.0-p6, same there: > >> > >> # ifconfig vtnet0 192.168.87.11 > >> ifconfig: WARNING: setting interface address without mask is > >> deprecated, default mask may not be correct. > >> > >> Interestingly, `ifconfig vtnet0 10.0.0.1` uses "/24" whereas > >> 192.168.87.11 uses "/8". > >> > >> This dates back to: > >> https://cgit.freebsd.org/src/commit/?id=4bf44dd73bc0a > > > > No it pre-dates that chnage. > > > > It goes back to d8237b95552807e937fc389c7e2237679ef0c984 and related > > changes. > > Sorry I hit send too early > > And I think it came out of > > commit 2f35e7d9fa03f27543f347cd6277af5bfc6a7e95 > commit 20d59403961d531467cfab22163f49c131cc8b55 > Hm, the deprecation warning was introduced in 2021 and was already part of 13.1 it seems: https://cgit.freebsd.org/src/commit/?id=4dbba5ab609c9 Going through these various commits, default behavior changed. Just tried on 13.2, where 10.x.x.x gave me /8 and 192.168.x.x gave me /24. @phk From which version did you upgrade? Best -- Michael Gmelin
Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out
On Wed, 12 Jun 2024, Bjoern A. Zeeb wrote: On Wed, 12 Jun 2024, Michael Gmelin wrote: On Wed, 12 Jun 2024 14:36:35 + "Poul-Henning Kamp" wrote: Bjoern A. Zeeb writes: I had a machine with this line in /etc/rc.conf: ifconfig_bla0="192.168.87.11" I found out the hard way, that this defaults to /8 now. Did you track it down to a specific change? I.e. is this ifconfig/netlink or the old kernel change from like two years(?) ago? Do you have a time window when this broke as that'll help people to bisect? I have no idea, sorry, I just freebsd-updated this one box... I just tried on 14.0-p6, same there: # ifconfig vtnet0 192.168.87.11 ifconfig: WARNING: setting interface address without mask is deprecated, default mask may not be correct. Interestingly, `ifconfig vtnet0 10.0.0.1` uses "/24" whereas 192.168.87.11 uses "/8". This dates back to: https://cgit.freebsd.org/src/commit/?id=4bf44dd73bc0a No it pre-dates that chnage. It goes back to d8237b95552807e937fc389c7e2237679ef0c984 and related changes. Sorry I hit send too early And I think it came out of commit 2f35e7d9fa03f27543f347cd6277af5bfc6a7e95 commit 20d59403961d531467cfab22163f49c131cc8b55 -- Bjoern A. Zeeb r15:7
Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out
On Wed, 12 Jun 2024, Michael Gmelin wrote: On Wed, 12 Jun 2024 14:36:35 + "Poul-Henning Kamp" wrote: Bjoern A. Zeeb writes: I had a machine with this line in /etc/rc.conf: ifconfig_bla0="192.168.87.11" I found out the hard way, that this defaults to /8 now. Did you track it down to a specific change? I.e. is this ifconfig/netlink or the old kernel change from like two years(?) ago? Do you have a time window when this broke as that'll help people to bisect? I have no idea, sorry, I just freebsd-updated this one box... I just tried on 14.0-p6, same there: # ifconfig vtnet0 192.168.87.11 ifconfig: WARNING: setting interface address without mask is deprecated, default mask may not be correct. Interestingly, `ifconfig vtnet0 10.0.0.1` uses "/24" whereas 192.168.87.11 uses "/8". This dates back to: https://cgit.freebsd.org/src/commit/?id=4bf44dd73bc0a No it pre-dates that chnage. It goes back to d8237b95552807e937fc389c7e2237679ef0c984 and related changes. -- Bjoern A. Zeeb r15:7
Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out
On Wed, 12 Jun 2024 14:36:35 + "Poul-Henning Kamp" wrote: > > Bjoern A. Zeeb writes: > > > > I had a machine with this line in /etc/rc.conf: > > > > > > ifconfig_bla0="192.168.87.11" > > > > > > I found out the hard way, that this defaults to /8 now. > > > > Did you track it down to a specific change? I.e. is this > > ifconfig/netlink or the old kernel change from like two years(?) > > ago? > > > > Do you have a time window when this broke as that'll help people to > > bisect? > > I have no idea, sorry, I just freebsd-updated this one box... > I just tried on 14.0-p6, same there: # ifconfig vtnet0 192.168.87.11 ifconfig: WARNING: setting interface address without mask is deprecated, default mask may not be correct. Interestingly, `ifconfig vtnet0 10.0.0.1` uses "/24" whereas 192.168.87.11 uses "/8". This dates back to: https://cgit.freebsd.org/src/commit/?id=4bf44dd73bc0a -m -- Michael Gmelin
Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out
Rodney W. Grimes writes: > *Stomps off my soap box, hands phk a bandaid for the bite mark (always, > always specify critical values even if they are the default), and > retreats to the background* /me hands Rod a glass of lemonade: "It's OK, you're welcome on my lawn :-)" -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out
> > Michael Gmelin writes: > > > You can do an interface route hack > > I think you misunderstand the situation. > > 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. > > The solution is not for them to apply some weird, complex and > unnecessary interface configuration. > > 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. > > Defaulting to a /8 netmask for 192.168.x.y does not make *any* sense ever. Why have I been bitching for 20 years about how the project just changes "defaults" that effect how a system behavies without any change by the user. In my book these are just plainly WRONG and well, have and continue to bite someone in the ass. No one else seems to complain unless it bites THEM in the ass, well there is ALWAYS and THEM so the project should be far more considerate than they have been, IMHO, about bitting asses, as those asses are connected to the hands that feed this project by growth. It is not that hard to intruduce NEW behavior yet retain the OLD behavior with lots of warning that it is exepcted to change or go away in the future. *Stomps off my soap box, hands phk a bandaid for the bite mark (always, always specify critical values even if they are the default), and retreats to the background* > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > p...@freebsd.org | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. -- Rod Grimes rgri...@freebsd.org
Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out
Bjoern A. Zeeb writes: > > I had a machine with this line in /etc/rc.conf: > > > > ifconfig_bla0="192.168.87.11" > > > > I found out the hard way, that this defaults to /8 now. > > Did you track it down to a specific change? I.e. is this > ifconfig/netlink or the old kernel change from like two years(?) ago? > > Do you have a time window when this broke as that'll help people to > bisect? I have no idea, sorry, I just freebsd-updated this one box... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out
On Wed, 12 Jun 2024, Poul-Henning Kamp wrote: I had a machine with this line in /etc/rc.conf: ifconfig_bla0="192.168.87.11" I found out the hard way, that this defaults to /8 now. Did you track it down to a specific change? I.e. is this ifconfig/netlink or the old kernel change from like two years(?) ago? Do you have a time window when this broke as that'll help people to bisect? -- Bjoern A. Zeeb r15:7
Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out
Hi, > On 12 Jun 2024, at 12:28, Poul-Henning Kamp wrote: > > Defaulting to a /8 netmask for 192.168.x.y does not make *any* sense ever. +1 -- Bob Bishop r...@gid.co.uk
Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out
Van: Poul-Henning Kamp Datum: woensdag, 12 juni 2024 12:39 Aan: Ronald Klop CC: curr...@freebsd.org Onderwerp: Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out Ronald Klop writes: > What do you thing about defaulting to /32 on a missing netmask? > An interface with 1 IP address without any information about the network. All traffic can go to the gateway. I dont think that will work ? The gateway will not be inside any of the attached networks, so you have no route to it ? Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. Ai. Of course. Typed quicker than I was thinking. :-) Well. Then it is maybe best to just error out on boot with a misconfigured network. Or revert back to the pre-14.1 behavior because of POLA. I'll leave it up to you and will make sure I configure my interfaces with a netmask. Regards, Ronald.
Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out
On Wed, 12 Jun 2024 11:28:38 + "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
Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out
Michael Gmelin writes: > You can do an interface route hack I think you misunderstand the situation. 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. The solution is not for them to apply some weird, complex and unnecessary interface configuration. 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. Defaulting to a /8 netmask for 192.168.x.y does not make *any* sense ever. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out
On Wed, 12 Jun 2024 10:39:36 + "Poul-Henning Kamp" wrote: > Ronald Klop writes: > > > What do you thing about defaulting to /32 on a missing netmask? > > An interface with 1 IP address without any information about the > > network All traffic can go to the gateway. > > I dont think that will work ? > > The gateway will not be inside any of the attached networks, so you > have no route to it ? > You can do an interface route hack sysrc static_routes="gateway default" sysrc route_gateway="-host 1.2.3.4 -interface bla0" sysrc route_default="default 1.2.3.4" This is actually quite useful in some setups, but in the context of deciding on default behavior when no mask is given this is probably not very helpful. Cheers -- Michael Gmelin
Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out
Ronald Klop writes: > What do you thing about defaulting to /32 on a missing netmask? > An interface with 1 IP address without any information about the network All > traffic can go to the gateway. I dont think that will work ? The gateway will not be inside any of the attached networks, so you have no route to it ? Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
Re: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out
Van: Poul-Henning Kamp Datum: woensdag, 12 juni 2024 09:47 Aan: curr...@freebsd.org Onderwerp: 14.1-R rc.conf/ifconfig netmask issue was really hard to figure out I had a machine with this line in /etc/rc.conf: ifconfig_bla0="192.168.87.11" I found out the hard way, that this defaults to /8 now. The main symptom was that DNS was /really/ busted, which makes sense when none of the DNS servers in the 192/8 "swamp" can be reached. Since we all know that it is always DNS(SEC), I spent a lot of time having fun with that, before I noticed the /8 netmask on the interface. I agree that the class A/B/C netmask assumptions should have died long ago. But from a foot-shooting point of view, it makes no sense to default 192.168/16 to a /8 netmask. If we're going to default to /8, at the very least ifconfig should spitting out a very noisy warning and wait 5 seconds before proceeding, when the netmask is not explicitly specified. But I also think we can do better than /8. One option is to go for "limit the damage in RFC1918" and default them according to their size: reach: 10/8 172.16/12 192.168/16 That will prevent the DNS weirdness I had to figure out, and probably still DWIM in most cases. Another option is to default all three to /24, which in my experience is how people deploy RFC1918. A third option is to default any missing netmask to /24 instead of /8, which would be what I would personally have done in the first place. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. What do you thing about defaulting to /32 on a missing netmask? An interface with 1 IP address without any information about the network. All traffic can go to the gateway. Regards, Ronald.
14.1-R rc.conf/ifconfig netmask issue was really hard to figure out
I had a machine with this line in /etc/rc.conf: ifconfig_bla0="192.168.87.11" I found out the hard way, that this defaults to /8 now. The main symptom was that DNS was /really/ busted, which makes sense when none of the DNS servers in the 192/8 "swamp" can be reached. Since we all know that it is always DNS(SEC), I spent a lot of time having fun with that, before I noticed the /8 netmask on the interface. I agree that the class A/B/C netmask assumptions should have died long ago. But from a foot-shooting point of view, it makes no sense to default 192.168/16 to a /8 netmask. If we're going to default to /8, at the very least ifconfig should spitting out a very noisy warning and wait 5 seconds before proceeding, when the netmask is not explicitly specified. But I also think we can do better than /8. One option is to go for "limit the damage in RFC1918" and default them according to their size: reach: 10/8 172.16/12 192.168/16 That will prevent the DNS weirdness I had to figure out, and probably still DWIM in most cases. Another option is to default all three to /24, which in my experience is how people deploy RFC1918. A third option is to default any missing netmask to /24 instead of /8, which would be what I would personally have done in the first place. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
