Re: vport: set UP on ip assign
How about a flag that can be passed via ifconfig to disable the implicit up? Then netstart could use it to enaure that an interface is only brought up after it has finished configuration (which *is* a problem for pppoe and carp at least) and it suits people's finger memory for ifconfig? Of course keeping auto-up in any form only solves the actual user-facing problem and doesn't make it easier to cope with the kernel side for locking.
Re: vport: set UP on ip assign
Klemens Nanni wrote: > Then, finally, interfaces only go UP if users do `ifconfig ... up' > or hostname.* contain the word "up". Otherwise they stay DOWN. > > This would be a dead simple thing to reason. Yeah it is so reasonable in fact why don't we add a chunk to the top of netstart to force all interfaces people configured by hand down!?!?!?!?! Or hey force them all The chain of proposals written in these emails are not going to happen, because netstart and hostname.* are a CONVENIENCE and may not be authoritative wrt the actual configuration. At boottime they are close to authoritative, but netstart can be run later. I don't know why you have gone on this bizzare tangent that "everything must change". No, things don't need to change.
Re: vport: set UP on ip assign
And here is the root of the argument -- where it is all going towards. > If we decide to handle this in netstart alone, shouldn't all interfaces > behave like vport(4) and not mess with their state unless explicitly > requested to do so? the implication here, is let's go change all the drivers and network stack to not "auto-up", because netstart will handle it. Absolutely no, because noone has tested this in all configurations and all the new implications that are being ignored in this proposal because it is only trying to fix another small nit. I am not thrilled about where this is going. Yes, there are obscure corner cases configuring network device "graphs". And the answer is to keep re-arranging netstart? I'm not sure about that. And now the conversation heads towards "drivers should not come up automatically", and "drivers should be pre-created". I think this is just deck chair re-arrangement. Lots of people do manual configuration, where they DON'T USE sh netstart, and their fingers have memories ... but this proposal of "netstart does it", and "drivers don't do it", is basically telling them to register at a re-education camp. Another way of looking at this, is that the situation isn't that bad, because it makes the simple device/network usages very simple to use. OpenBSD isn't a brand-name enterprise switch or router. I'm familiar with the usage pattern on such devices. That does not mean I (or others) automatically require the "kind of implied atomicity" of only bringing up interfaces "late". Even on major routers/switches, this is such a small little thing -- the management of those devices requires that you to have brought the devices down before you make changes, otherwise there is no manual "up" step, because you as an admin left it "up" while you were making changes. So the transaction model you want to enforce here with netstart is only concerned with the "up" side, there is no implied "down", there cannot be an implied "down" side... unless you mean people should reboot to test? A bit of hyperbole, but why solve the "do not auto up" if during re-configuriaton people are very often already going to be up??? So, I do not understand the end-game of this proposal. I mean, beyond fresh boot. But now to tie this into "devices should not come up on their own", why does that even MATTER during the few moments of bring-up. Chasing ghosts? And yes I know the routing daemons are processing excessive messages, but isn't it their job to normally process potentially many more messages than this meager amount, and isn't it good that such code is actually being tested to behave correctly? In summary, there are undeal setups. Does it mean everything has to change those to satisfy those few odd cases? I don't see justification.
Re: vport: set UP on ip assign
On Wed, Nov 24, 2021 at 02:30:08AM +0100, Klemens Nanni wrote:
> On Tue, Nov 16, 2021 at 09:22:26AM +1000, David Gwynne wrote:
> > On Mon, Nov 15, 2021 at 02:31:42PM +, Klemens Nanni wrote:
> > > On Mon, Nov 15, 2021 at 01:37:49PM +, Stuart Henderson wrote:
> > > > On 2021/11/15 12:27, Klemens Nanni wrote:
> > > > > On Sun, Nov 14, 2021 at 07:04:42PM -0700, Theo de Raadt wrote:
> > > > > > I think physical interfaces should come up when something is
> > > > > > configured
> > > > > > on them, but virtual interfaces shouldn't -- mostly because the
> > > > > > order of
> > > > > > configuration is often muddled.
> > > > >
> > > > > So "inet6 2001:db8::1" in hostname.em0 will do the trick but
> > > > > hostname.vport0 would need another "up" for the same behaviour:
> > > > > that's
> > > > > rather confusing me as a user.
> > > >
> > > > hostname.* files are orthogonal to this; netstart can process all the
> > > > lines,
> > > > then if it has seen a line doing address configuration and has not seen
> > > > an
> > > > explicit "down", it can bring the interface up automatically at the end.
> > > > (if this changed, it would be a nightmare for users to do anything
> > > > else).
> > >
> > > Yes, netstart can and should deal with this correctly, just like you
> > > describe.
> > >
> > > > Users would need to make sure they have a netstart which does that if
> > > > updating a kernel, but that's just a case of matching kernel+userland
> > > > and is
> > > > nothing new for OpenBSD.
> > > >
> > > > The different behaviour would be apparent with separate runs of
> > > > ifconfig.
> > > > some scripts may need adapting and users might need to run "ifconfig XX
> > > > up"
> > > > themselves but I don't think that would be a problem.
> > >
> > > Agreed.
> > >
> > > Having the implicit-up logic entirely contained in netstart would make
> > > lifer much easier, both for network stack hackers and users, imho.
> >
> > this was my attempt at just that.
>
> Given netstart(8) always pulls interfaces UP or DOWN as the last step,
> surely this wouldn't be all, right?
Put differently: Such netstart change really just tries to abstract a
consistent behaviour across multiple interfaces doing it differently.
> Interfaces/drivers still pull themselves up, thus create route message
> churn, transition from initial DOWN to implicit UP due to address
> configuration to possibly administrative DOWN again due to "down" in
> hostname.*, etc.
So once/iff this change lands, I think all interfaces should do (or not
do) what netstart compensates for.
Once all interfaces avoid implicit state changes and only transition
upon administrative command (and possibly `autoconf'), the netstart
workaround --that's what it really is-- ought to be removed.
> If we decide to handle this in netstart alone, shouldn't all interfaces
> behave like vport(4) and not mess with their state unless explicitly
> requested to do so?
Then, finally, interfaces only go UP if users do `ifconfig ... up'
or hostname.* contain the word "up". Otherwise they stay DOWN.
This would be a dead simple thing to reason.
The netstart workaround itself already changes behaviour and tells users
to add a very specific line to their configuration -- a format which
really shouldn't have such specific requirements but instead should work
like regular `ifconfig' lines on the shell, btw.
So If that already needs attention, the final solution of no interface
doing implicit changes and netstart not doing any implicit stuff would
also eventually result in the simplest and most intuitive form of
configuration: "up" anywhere pulls UP, "down" anywhere pulls DOWN,
neither anywhere leaves interfaces at their creation default of DOWN.
> Not sure if the (now finally documented) implicit `up' in `autoconf'
> should stay after the netstart change, but that's another topic
> (pulling interfaces UP two times won't hurt, I guess).
>
> > the installer has its own netstart though, right?
>
> Yes, diff for that at the end after tweaking yours and adapting it.
>
> > Index: etc/netstart
> > ===
> > RCS file: /cvs/src/etc/netstart,v
> > retrieving revision 1.216
> > diff -u -p -r1.216 netstart
> > --- etc/netstart2 Sep 2021 19:38:20 - 1.216
> > +++ etc/netstart15 Nov 2021 23:20:00 -
> > @@ -71,6 +71,9 @@ parse_hn_line() {
> > dhcp) _cmds[${#_cmds[*]}]="ifconfig $_if inet autoconf"
> > V4_AUTOCONF=true
> > ;;
> > + down) _c[0]=
>
> This reset seems unneeded, `_c' isn't used afterwards and I don't
> undertand why you do it.
>
> > + _ifup=down
>
> So `_ifup' comes from ifstart() and not parse_hn_line().
>
> We use the "_" prefix to denote local variables...
>
> > + ;;
> > '!'*) _cmd=$(print -- "${_c[@]}" | sed 's/\$if/'$_if'/g')
> > _cmds[${#_cmds[*]}]="${_cmd#!}"
> > ;;
> > @@ -118,6 +121,7 @@
Re: vport: set UP on ip assign
On Tue, Nov 16, 2021 at 09:22:26AM +1000, David Gwynne wrote:
> On Mon, Nov 15, 2021 at 02:31:42PM +, Klemens Nanni wrote:
> > On Mon, Nov 15, 2021 at 01:37:49PM +, Stuart Henderson wrote:
> > > On 2021/11/15 12:27, Klemens Nanni wrote:
> > > > On Sun, Nov 14, 2021 at 07:04:42PM -0700, Theo de Raadt wrote:
> > > > > I think physical interfaces should come up when something is
> > > > > configured
> > > > > on them, but virtual interfaces shouldn't -- mostly because the order
> > > > > of
> > > > > configuration is often muddled.
> > > >
> > > > So "inet6 2001:db8::1" in hostname.em0 will do the trick but
> > > > hostname.vport0 would need another "up" for the same behaviour: that's
> > > > rather confusing me as a user.
> > >
> > > hostname.* files are orthogonal to this; netstart can process all the
> > > lines,
> > > then if it has seen a line doing address configuration and has not seen an
> > > explicit "down", it can bring the interface up automatically at the end.
> > > (if this changed, it would be a nightmare for users to do anything else).
> >
> > Yes, netstart can and should deal with this correctly, just like you
> > describe.
> >
> > > Users would need to make sure they have a netstart which does that if
> > > updating a kernel, but that's just a case of matching kernel+userland and
> > > is
> > > nothing new for OpenBSD.
> > >
> > > The different behaviour would be apparent with separate runs of ifconfig.
> > > some scripts may need adapting and users might need to run "ifconfig XX
> > > up"
> > > themselves but I don't think that would be a problem.
> >
> > Agreed.
> >
> > Having the implicit-up logic entirely contained in netstart would make
> > lifer much easier, both for network stack hackers and users, imho.
>
> this was my attempt at just that.
Given netstart(8) always pulls interfaces UP or DOWN as the last step,
surely this wouldn't be all, right?
Interfaces/drivers still pull themselves up, thus create route message
churn, transition from initial DOWN to implicit UP due to address
configuration to possibly administrative DOWN again due to "down" in
hostname.*, etc.
If we decide to handle this in netstart alone, shouldn't all interfaces
behave like vport(4) and not mess with their state unless explicitly
requested to do so?
Not sure if the (now finally documented) implicit `up' in `autoconf'
should stay after the netstart change, but that's another topic
(pulling interfaces UP two times won't hurt, I guess).
> the installer has its own netstart though, right?
Yes, diff for that at the end after tweaking yours and adapting it.
> Index: etc/netstart
> ===
> RCS file: /cvs/src/etc/netstart,v
> retrieving revision 1.216
> diff -u -p -r1.216 netstart
> --- etc/netstart 2 Sep 2021 19:38:20 - 1.216
> +++ etc/netstart 15 Nov 2021 23:20:00 -
> @@ -71,6 +71,9 @@ parse_hn_line() {
> dhcp) _cmds[${#_cmds[*]}]="ifconfig $_if inet autoconf"
> V4_AUTOCONF=true
> ;;
> + down) _c[0]=
This reset seems unneeded, `_c' isn't used afterwards and I don't
undertand why you do it.
> + _ifup=down
So `_ifup' comes from ifstart() and not parse_hn_line().
We use the "_" prefix to denote local variables...
> + ;;
> '!'*) _cmd=$(print -- "${_c[@]}" | sed 's/\$if/'$_if'/g')
> _cmds[${#_cmds[*]}]="${_cmd#!}"
> ;;
> @@ -118,6 +121,7 @@ vifscreate() {
> ifstart() {
> local _if=$1 _hn=/etc/hostname.$1 _cmds _i=0 _line _stat
> set -A _cmds
> + _ifup=up
except you define a global variable inside a function.
This should be local to ifstart() (deserving its prefix), which makes it
reach into the scope of parse_hn_line() (as is usual semantic with
`local' variables in at least ksh and bash).
I've added comments to reflect on this special use, as I'm unaware of
any other piece of shell code were we actively use function-local
variables up the call stack.
>
> # Interface names must be alphanumeric only. We check to avoid
> # configuring backup or temp files, and to catch the "*" case.
> @@ -145,6 +149,8 @@ ifstart() {
> while IFS= read -- _line; do
> parse_hn_line $_line
> done <$_hn
> +
> + _cmds[${#_cmds[*]}]="ifconfig $_if $_ifup"
Lastly, I'd say `_ifstate' because that equally means "up" and "down".
>
> # Apply the interface configuration commands stored in _cmds array.
> while ((_i < ${#_cmds[*]})); do
> Index: share/man/man5/hostname.if.5
> ===
> RCS file: /cvs/src/share/man/man5/hostname.if.5,v
> retrieving revision 1.77
> diff -u -p -r1.77 hostname.if.5
> --- share/man/man5/hostname.if.5 17 Jul 2021 15:28:31 - 1.77
> +++ share/man/man5/hostname.if.5 15 Nov 2021 23:20:01 -
> @@ -57,6 +57,9 @@ the administrator should not expect magi
>
Re: vport: set UP on ip assign
On Mon, Nov 15, 2021 at 04:25:54PM -0700, Theo de Raadt wrote:
> > + _cmds[${#_cmds[*]}]="ifconfig $_if $_ifup"
>
> I will be surprised if you can simply add "up" to potential
> ifconfig commandlines.
This does not amend "ifconfig foo0 bar ..." to ifconfig foo0 bar ... up"
if that's what you mean.
It's a single "ifconfig foo0 up" at the end.
This does work in every hostname.* file.
Re: vport: set UP on ip assign
> + _cmds[${#_cmds[*]}]="ifconfig $_if $_ifup"
I will be surprised if you can simply add "up" to potential
ifconfig commandlines.
Re: vport: set UP on ip assign
On Mon, Nov 15, 2021 at 02:31:42PM +, Klemens Nanni wrote:
> On Mon, Nov 15, 2021 at 01:37:49PM +, Stuart Henderson wrote:
> > On 2021/11/15 12:27, Klemens Nanni wrote:
> > > On Sun, Nov 14, 2021 at 07:04:42PM -0700, Theo de Raadt wrote:
> > > > I think physical interfaces should come up when something is configured
> > > > on them, but virtual interfaces shouldn't -- mostly because the order of
> > > > configuration is often muddled.
> > >
> > > So "inet6 2001:db8::1" in hostname.em0 will do the trick but
> > > hostname.vport0 would need another "up" for the same behaviour: that's
> > > rather confusing me as a user.
> >
> > hostname.* files are orthogonal to this; netstart can process all the lines,
> > then if it has seen a line doing address configuration and has not seen an
> > explicit "down", it can bring the interface up automatically at the end.
> > (if this changed, it would be a nightmare for users to do anything else).
>
> Yes, netstart can and should deal with this correctly, just like you
> describe.
>
> > Users would need to make sure they have a netstart which does that if
> > updating a kernel, but that's just a case of matching kernel+userland and is
> > nothing new for OpenBSD.
> >
> > The different behaviour would be apparent with separate runs of ifconfig.
> > some scripts may need adapting and users might need to run "ifconfig XX up"
> > themselves but I don't think that would be a problem.
>
> Agreed.
>
> Having the implicit-up logic entirely contained in netstart would make
> lifer much easier, both for network stack hackers and users, imho.
this was my attempt at just that.
the installer has its own netstart though, right?
Index: etc/netstart
===
RCS file: /cvs/src/etc/netstart,v
retrieving revision 1.216
diff -u -p -r1.216 netstart
--- etc/netstart2 Sep 2021 19:38:20 - 1.216
+++ etc/netstart15 Nov 2021 23:20:00 -
@@ -71,6 +71,9 @@ parse_hn_line() {
dhcp) _cmds[${#_cmds[*]}]="ifconfig $_if inet autoconf"
V4_AUTOCONF=true
;;
+ down) _c[0]=
+ _ifup=down
+ ;;
'!'*) _cmd=$(print -- "${_c[@]}" | sed 's/\$if/'$_if'/g')
_cmds[${#_cmds[*]}]="${_cmd#!}"
;;
@@ -118,6 +121,7 @@ vifscreate() {
ifstart() {
local _if=$1 _hn=/etc/hostname.$1 _cmds _i=0 _line _stat
set -A _cmds
+ _ifup=up
# Interface names must be alphanumeric only. We check to avoid
# configuring backup or temp files, and to catch the "*" case.
@@ -145,6 +149,8 @@ ifstart() {
while IFS= read -- _line; do
parse_hn_line $_line
done <$_hn
+
+ _cmds[${#_cmds[*]}]="ifconfig $_if $_ifup"
# Apply the interface configuration commands stored in _cmds array.
while ((_i < ${#_cmds[*]})); do
Index: share/man/man5/hostname.if.5
===
RCS file: /cvs/src/share/man/man5/hostname.if.5,v
retrieving revision 1.77
diff -u -p -r1.77 hostname.if.5
--- share/man/man5/hostname.if.517 Jul 2021 15:28:31 - 1.77
+++ share/man/man5/hostname.if.515 Nov 2021 23:20:01 -
@@ -57,6 +57,9 @@ the administrator should not expect magi
and the
per-driver manual pages to see what arguments are permitted.
.Pp
+Interfaces are implicitly configured to be brought up and running.
+This behaviour can be disabled by adding a line containing down to the file.
+.Pp
Arguments containing either whitespace or single quote
characters must be double quoted.
For example:
Re: [EXTERNAL] Re: vport: set UP on ip assign
Eichert, Diana wrote: > As a person who has spent a lot of time configuring network devices it > seems normal to explicitly bring an interface UP, whatever type of > interface. Some commercial routers and switches have explicit up operations. Others follow a change-and-commit model. But OpenBSD isn't a switch or a router. Many of our network configurations have followed the simpler model for a long time. The question is where to draw the line.
Re: vport: set UP on ip assign
On Mon, Nov 15, 2021 at 01:37:49PM +, Stuart Henderson wrote: > On 2021/11/15 12:27, Klemens Nanni wrote: > > On Sun, Nov 14, 2021 at 07:04:42PM -0700, Theo de Raadt wrote: > > > I think physical interfaces should come up when something is configured > > > on them, but virtual interfaces shouldn't -- mostly because the order of > > > configuration is often muddled. > > > > So "inet6 2001:db8::1" in hostname.em0 will do the trick but > > hostname.vport0 would need another "up" for the same behaviour: that's > > rather confusing me as a user. > > hostname.* files are orthogonal to this; netstart can process all the lines, > then if it has seen a line doing address configuration and has not seen an > explicit "down", it can bring the interface up automatically at the end. > (if this changed, it would be a nightmare for users to do anything else). Yes, netstart can and should deal with this correctly, just like you describe. > Users would need to make sure they have a netstart which does that if > updating a kernel, but that's just a case of matching kernel+userland and is > nothing new for OpenBSD. > > The different behaviour would be apparent with separate runs of ifconfig. > some scripts may need adapting and users might need to run "ifconfig XX up" > themselves but I don't think that would be a problem. Agreed. Having the implicit-up logic entirely contained in netstart would make lifer much easier, both for network stack hackers and users, imho.
Re: vport: set UP on ip assign
On 2021/11/15 12:27, Klemens Nanni wrote: > On Sun, Nov 14, 2021 at 07:04:42PM -0700, Theo de Raadt wrote: > > I think physical interfaces should come up when something is configured > > on them, but virtual interfaces shouldn't -- mostly because the order of > > configuration is often muddled. > > So "inet6 2001:db8::1" in hostname.em0 will do the trick but > hostname.vport0 would need another "up" for the same behaviour: that's > rather confusing me as a user. hostname.* files are orthogonal to this; netstart can process all the lines, then if it has seen a line doing address configuration and has not seen an explicit "down", it can bring the interface up automatically at the end. (if this changed, it would be a nightmare for users to do anything else). Users would need to make sure they have a netstart which does that if updating a kernel, but that's just a case of matching kernel+userland and is nothing new for OpenBSD. The different behaviour would be apparent with separate runs of ifconfig. some scripts may need adapting and users might need to run "ifconfig XX up" themselves but I don't think that would be a problem.
Re: vport: set UP on ip assign
On 2021 Nov 15 (Mon) at 13:58:08 +0100 (+0100), Claudio Jeker wrote: :On Mon, Nov 15, 2021 at 12:23:02PM +, Klemens Nanni wrote: ... :Sure people got used to this mode. I agree with dlg@ that the way that :this auto interface up happens is rather horrible from a network stack :view. Also it makes it impossible to configure an interface all the way :before bringing it up. This may be important for interfaces with more :complex configuration. : :The current behaviour is great for casual users (that does not really :care about network) but is annoying for network admins. : This behaviour caused no ends of problems for me when I was administering carp interfaces with several / many IPs assigned to them. Extremely painful to add multiple addresses to the carp cluster. :> > I've suggested previously that netstart should handle bringing an :> > interface up. look for "netstart: implicit up and explicit down for :> > hostname.if conf files" on tech@. I didn't hanve the energy to push :> > it forward though. :> :> I'll do the digging and try to catch up, thanks. : :Another option is to adjust ifconfig but then again one would like to do :the up last after running multiple ifconfig calls. ifconfig has its own :madness when it comes to execute multiple commands in one go. : That will address several situations, but I don't know if it covers all / enough of them. :> > dhcpd should cope with an interface being down too. It should be about :> > whetherthe addresses are right more than if the interface is up or not. : :I expect an interface that is down to remain down until I bring it up :again. Same goes the other way. ifconfig up/down should only be used to :implement admin shutdown. We fixed a few interfaces in the past that :played with IFF_UP in the driver. : 100% yes :-- ::wq Claudio : -- The plot was designed in a light vein that somehow became varicose. -- David Lardner
Re: vport: set UP on ip assign
On Mon, Nov 15, 2021 at 12:23:02PM +, Klemens Nanni wrote: > On Mon, Nov 15, 2021 at 12:00:18PM +1000, David Gwynne wrote: > > On Sat, Nov 13, 2021 at 11:59:59PM +, Klemens Nanni wrote: > > > Practically all interfaces pull itself up when IPs get assigned, but > > > vport(4) does not. > > > > Yes, I do (or don't do) this very deliberately when I get the chance. > > > > > This broke IPv4 networking for me on a router I switched from bridge(4) > > > to veb(4) because hostname.vport0 only contained the equivalent of > > > > > > descr LAN > > > inet 192.0.2.1 > > > inet6 2001:db8::1 > > > > > > e.g. the explicit "up" was missing. > > > > > > dhcpd(8) only considers UP interfaces to listen on during start; > > > being the only interface it could potentially listen on, dhcpd thus > > > ignored vport0 and failed to start. > > > > > > `ifconfig vport0 up && rcctl restart dhcpd' fixed this. > > > Adding "up" to thostname.vport0 also fixed it. > > > > > > Nonetheless, vport should UP itself as the rest does. > > > > My counter argument is that no interface should implicitly bring itself > > up when an address is configured because it has been a road block to > > figuring out how to lock the ioctl paths better, and it confuses error > > handling. If address config works, but the interface fails to come up, > > the address remains configured but we report an error. But it looks like > > configuring an address failed? Wat. > > That's a valid point, although I must say I never ran into this issue. > > I fear that users have come to rely on the implicit up semantics, i.e. > I doubt I'm the only one with hostname.* files lacking "up". Sure people got used to this mode. I agree with dlg@ that the way that this auto interface up happens is rather horrible from a network stack view. Also it makes it impossible to configure an interface all the way before bringing it up. This may be important for interfaces with more complex configuration. The current behaviour is great for casual users (that does not really care about network) but is annoying for network admins. > > I've suggested previously that netstart should handle bringing an > > interface up. look for "netstart: implicit up and explicit down for > > hostname.if conf files" on tech@. I didn't hanve the energy to push > > it forward though. > > I'll do the digging and try to catch up, thanks. Another option is to adjust ifconfig but then again one would like to do the up last after running multiple ifconfig calls. ifconfig has its own madness when it comes to execute multiple commands in one go. > > dhcpd should cope with an interface being down too. It should be about > > whetherthe addresses are right more than if the interface is up or not. I expect an interface that is down to remain down until I bring it up again. Same goes the other way. ifconfig up/down should only be used to implement admin shutdown. We fixed a few interfaces in the past that played with IFF_UP in the driver. -- :wq Claudio
Re: vport: set UP on ip assign
On Sun, Nov 14, 2021 at 07:04:42PM -0700, Theo de Raadt wrote:
> I think physical interfaces should come up when something is configured
> on them, but virtual interfaces shouldn't -- mostly because the order of
> configuration is often muddled.
So "inet6 2001:db8::1" in hostname.em0 will do the trick but
hostname.vport0 would need another "up" for the same behaviour: that's
rather confusing me as a user.
> David Gwynne wrote:
>
> > On Sat, Nov 13, 2021 at 11:59:59PM +, Klemens Nanni wrote:
> > > Practically all interfaces pull itself up when IPs get assigned, but
> > > vport(4) does not.
> >
> > Yes, I do (or don't do) this very deliberately when I get the chance.
> >
> > > This broke IPv4 networking for me on a router I switched from bridge(4)
> > > to veb(4) because hostname.vport0 only contained the equivalent of
> > >
> > > descr LAN
> > > inet 192.0.2.1
> > > inet6 2001:db8::1
> > >
> > > e.g. the explicit "up" was missing.
> > >
> > > dhcpd(8) only considers UP interfaces to listen on during start;
> > > being the only interface it could potentially listen on, dhcpd thus
> > > ignored vport0 and failed to start.
> > >
> > > `ifconfig vport0 up && rcctl restart dhcpd' fixed this.
> > > Adding "up" to thostname.vport0 also fixed it.
> > >
> > > Nonetheless, vport should UP itself as the rest does.
> >
> > My counter argument is that no interface should implicitly bring itself
> > up when an address is configured because it has been a road block to
> > figuring out how to lock the ioctl paths better, and it confuses error
> > handling. If address config works, but the interface fails to come up,
> > the address remains configured but we report an error. But it looks like
> > configuring an address failed? Wat.
> >
> > I've suggested previously that netstart should handle bringing an
> > interface up. look for "netstart: implicit up and explicit down for
> > hostname.if conf files" on tech@. I didn't hanve the energy to push
> > it forward though.
> >
> > dhcpd should cope with an interface being down too. It should be about
> > whetherthe addresses are right more than if the interface is up or not.
> >
> > >
> > > OK?
> > >
> > > Index: net/if_veb.c
> > > ===
> > > RCS file: /cvs/src/sys/net/if_veb.c,v
> > > retrieving revision 1.21
> > > diff -u -p -r1.21 if_veb.c
> > > --- net/if_veb.c 8 Nov 2021 04:15:46 - 1.21
> > > +++ net/if_veb.c 13 Nov 2021 23:47:58 -
> > > @@ -2122,6 +2122,10 @@ vport_ioctl(struct ifnet *ifp, u_long cm
> > > return (ENXIO);
> > >
> > > switch (cmd) {
> > > + case SIOCSIFADDR:
> > > + ifp->if_flags |= IFF_UP;
> > > + /* FALLTHROUGH */
> > > +
> > > case SIOCSIFFLAGS:
> > > if (ISSET(ifp->if_flags, IFF_UP)) {
> > > if (!ISSET(ifp->if_flags, IFF_RUNNING))
> > >
> >
>
Re: vport: set UP on ip assign
On Mon, Nov 15, 2021 at 12:00:18PM +1000, David Gwynne wrote:
> On Sat, Nov 13, 2021 at 11:59:59PM +, Klemens Nanni wrote:
> > Practically all interfaces pull itself up when IPs get assigned, but
> > vport(4) does not.
>
> Yes, I do (or don't do) this very deliberately when I get the chance.
>
> > This broke IPv4 networking for me on a router I switched from bridge(4)
> > to veb(4) because hostname.vport0 only contained the equivalent of
> >
> > descr LAN
> > inet 192.0.2.1
> > inet6 2001:db8::1
> >
> > e.g. the explicit "up" was missing.
> >
> > dhcpd(8) only considers UP interfaces to listen on during start;
> > being the only interface it could potentially listen on, dhcpd thus
> > ignored vport0 and failed to start.
> >
> > `ifconfig vport0 up && rcctl restart dhcpd' fixed this.
> > Adding "up" to thostname.vport0 also fixed it.
> >
> > Nonetheless, vport should UP itself as the rest does.
>
> My counter argument is that no interface should implicitly bring itself
> up when an address is configured because it has been a road block to
> figuring out how to lock the ioctl paths better, and it confuses error
> handling. If address config works, but the interface fails to come up,
> the address remains configured but we report an error. But it looks like
> configuring an address failed? Wat.
That's a valid point, although I must say I never ran into this issue.
I fear that users have come to rely on the implicit up semantics, i.e.
I doubt I'm the only one with hostname.* files lacking "up".
> I've suggested previously that netstart should handle bringing an
> interface up. look for "netstart: implicit up and explicit down for
> hostname.if conf files" on tech@. I didn't hanve the energy to push
> it forward though.
I'll do the digging and try to catch up, thanks.
> dhcpd should cope with an interface being down too. It should be about
> whetherthe addresses are right more than if the interface is up or not.
>
> >
> > OK?
> >
> > Index: net/if_veb.c
> > ===
> > RCS file: /cvs/src/sys/net/if_veb.c,v
> > retrieving revision 1.21
> > diff -u -p -r1.21 if_veb.c
> > --- net/if_veb.c8 Nov 2021 04:15:46 - 1.21
> > +++ net/if_veb.c13 Nov 2021 23:47:58 -
> > @@ -2122,6 +2122,10 @@ vport_ioctl(struct ifnet *ifp, u_long cm
> > return (ENXIO);
> >
> > switch (cmd) {
> > + case SIOCSIFADDR:
> > + ifp->if_flags |= IFF_UP;
> > + /* FALLTHROUGH */
> > +
> > case SIOCSIFFLAGS:
> > if (ISSET(ifp->if_flags, IFF_UP)) {
> > if (!ISSET(ifp->if_flags, IFF_RUNNING))
> >
>
Re: vport: set UP on ip assign
I think physical interfaces should come up when something is configured
on them, but virtual interfaces shouldn't -- mostly because the order of
configuration is often muddled.
David Gwynne wrote:
> On Sat, Nov 13, 2021 at 11:59:59PM +, Klemens Nanni wrote:
> > Practically all interfaces pull itself up when IPs get assigned, but
> > vport(4) does not.
>
> Yes, I do (or don't do) this very deliberately when I get the chance.
>
> > This broke IPv4 networking for me on a router I switched from bridge(4)
> > to veb(4) because hostname.vport0 only contained the equivalent of
> >
> > descr LAN
> > inet 192.0.2.1
> > inet6 2001:db8::1
> >
> > e.g. the explicit "up" was missing.
> >
> > dhcpd(8) only considers UP interfaces to listen on during start;
> > being the only interface it could potentially listen on, dhcpd thus
> > ignored vport0 and failed to start.
> >
> > `ifconfig vport0 up && rcctl restart dhcpd' fixed this.
> > Adding "up" to thostname.vport0 also fixed it.
> >
> > Nonetheless, vport should UP itself as the rest does.
>
> My counter argument is that no interface should implicitly bring itself
> up when an address is configured because it has been a road block to
> figuring out how to lock the ioctl paths better, and it confuses error
> handling. If address config works, but the interface fails to come up,
> the address remains configured but we report an error. But it looks like
> configuring an address failed? Wat.
>
> I've suggested previously that netstart should handle bringing an
> interface up. look for "netstart: implicit up and explicit down for
> hostname.if conf files" on tech@. I didn't hanve the energy to push
> it forward though.
>
> dhcpd should cope with an interface being down too. It should be about
> whetherthe addresses are right more than if the interface is up or not.
>
> >
> > OK?
> >
> > Index: net/if_veb.c
> > ===
> > RCS file: /cvs/src/sys/net/if_veb.c,v
> > retrieving revision 1.21
> > diff -u -p -r1.21 if_veb.c
> > --- net/if_veb.c8 Nov 2021 04:15:46 - 1.21
> > +++ net/if_veb.c13 Nov 2021 23:47:58 -
> > @@ -2122,6 +2122,10 @@ vport_ioctl(struct ifnet *ifp, u_long cm
> > return (ENXIO);
> >
> > switch (cmd) {
> > + case SIOCSIFADDR:
> > + ifp->if_flags |= IFF_UP;
> > + /* FALLTHROUGH */
> > +
> > case SIOCSIFFLAGS:
> > if (ISSET(ifp->if_flags, IFF_UP)) {
> > if (!ISSET(ifp->if_flags, IFF_RUNNING))
> >
>
Re: vport: set UP on ip assign
On Sat, Nov 13, 2021 at 11:59:59PM +, Klemens Nanni wrote:
> Practically all interfaces pull itself up when IPs get assigned, but
> vport(4) does not.
Yes, I do (or don't do) this very deliberately when I get the chance.
> This broke IPv4 networking for me on a router I switched from bridge(4)
> to veb(4) because hostname.vport0 only contained the equivalent of
>
> descr LAN
> inet 192.0.2.1
> inet6 2001:db8::1
>
> e.g. the explicit "up" was missing.
>
> dhcpd(8) only considers UP interfaces to listen on during start;
> being the only interface it could potentially listen on, dhcpd thus
> ignored vport0 and failed to start.
>
> `ifconfig vport0 up && rcctl restart dhcpd' fixed this.
> Adding "up" to thostname.vport0 also fixed it.
>
> Nonetheless, vport should UP itself as the rest does.
My counter argument is that no interface should implicitly bring itself
up when an address is configured because it has been a road block to
figuring out how to lock the ioctl paths better, and it confuses error
handling. If address config works, but the interface fails to come up,
the address remains configured but we report an error. But it looks like
configuring an address failed? Wat.
I've suggested previously that netstart should handle bringing an
interface up. look for "netstart: implicit up and explicit down for
hostname.if conf files" on tech@. I didn't hanve the energy to push
it forward though.
dhcpd should cope with an interface being down too. It should be about
whetherthe addresses are right more than if the interface is up or not.
>
> OK?
>
> Index: net/if_veb.c
> ===
> RCS file: /cvs/src/sys/net/if_veb.c,v
> retrieving revision 1.21
> diff -u -p -r1.21 if_veb.c
> --- net/if_veb.c 8 Nov 2021 04:15:46 - 1.21
> +++ net/if_veb.c 13 Nov 2021 23:47:58 -
> @@ -2122,6 +2122,10 @@ vport_ioctl(struct ifnet *ifp, u_long cm
> return (ENXIO);
>
> switch (cmd) {
> + case SIOCSIFADDR:
> + ifp->if_flags |= IFF_UP;
> + /* FALLTHROUGH */
> +
> case SIOCSIFFLAGS:
> if (ISSET(ifp->if_flags, IFF_UP)) {
> if (!ISSET(ifp->if_flags, IFF_RUNNING))
>
vport: set UP on ip assign
Practically all interfaces pull itself up when IPs get assigned, but
vport(4) does not.
This broke IPv4 networking for me on a router I switched from bridge(4)
to veb(4) because hostname.vport0 only contained the equivalent of
descr LAN
inet 192.0.2.1
inet6 2001:db8::1
e.g. the explicit "up" was missing.
dhcpd(8) only considers UP interfaces to listen on during start;
being the only interface it could potentially listen on, dhcpd thus
ignored vport0 and failed to start.
`ifconfig vport0 up && rcctl restart dhcpd' fixed this.
Adding "up" to hostname.vport0 also fixed it.
Nonetheless, vport should UP itself as the rest does.
OK?
Index: net/if_veb.c
===
RCS file: /cvs/src/sys/net/if_veb.c,v
retrieving revision 1.21
diff -u -p -r1.21 if_veb.c
--- net/if_veb.c8 Nov 2021 04:15:46 - 1.21
+++ net/if_veb.c13 Nov 2021 23:47:58 -
@@ -2122,6 +2122,10 @@ vport_ioctl(struct ifnet *ifp, u_long cm
return (ENXIO);
switch (cmd) {
+ case SIOCSIFADDR:
+ ifp->if_flags |= IFF_UP;
+ /* FALLTHROUGH */
+
case SIOCSIFFLAGS:
if (ISSET(ifp->if_flags, IFF_UP)) {
if (!ISSET(ifp->if_flags, IFF_RUNNING))
