Re: misc/60870: Downing a interface in the same subnet as the nfs-root freezes the system

["netbsd%lissners.de@localhost via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR misc/60870; it has been noted by GNATS.

From: netbsd%lissners.de@localhost
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: misc/60870: Downing a interface in the same subnet as the
 nfs-root freezes the system
Date: Tue, 13 Oct 2026 23:05:09 +0200

 Am 13.10.26 um 4:50 PM schrieb Robert Elz via gnats:
 > The following reply was made to PR misc/60870; it has been noted by GNAT=
 S.
 >=20
 > From: Robert Elz <kre%munnari.OZ.AU@localhost>
 > To: gnats-bugs%netbsd.org@localhost
 > Cc:
 > Subject: Re: misc/60870: Downing a interface in the same subnet as the n=
 fs-root freezes the system
 > Date: Tue, 13 Oct 2026 21:48:36 +0700
 >=20
 >       Date:        Tue, 13 Oct 2026 12:10:01 +0000 (UTC)
 >       From:        "netbsd%lissners.de@localhost via gnats" <gnats-admin%NetBSD.or@localhost=
 g>
 >       Message-ID:  <20261013121001.22F5C1A923E%mollari.NetBSD.org@localhost>
 >  =20
 >     | Expected behaviour:
 >     | The ip-address is automatically removed from wm1 before
 >     | downing the interface.
 >  =20
 >   While that might make your problem go away, it isn't the right
 >   thing to do - interfaces are sometimes taken down & up again in
 >   order to do some sort of re-init on the hardware as the interface
 >   comes back up.  The configured IP address is intended to remain,
 >   it won't work when the network is down, but will again as soon as
 >   it comes back up.
 >  =20
 >   If you want to delete the address first, you can just do that.
 >  =20
 >     | My(!) expectation is not: A switchover to wm1 as the interface
 >     | handling the nfs-root when downing wm0. Would be nice, though :-)
 >  =20
 >   If routing were set up correctly, that would work.   In fact, with the
 >   dubious (really incorrect) config that you have, it is already working=
 .
 >   That was the source of the problem.
 >  =20
 >   Your default route, and the route to the nfs server started out via yo=
 ur
 >   wm0 interface (and are shown that way).   When you (mis-)configured wm=
 1
 >   you added an interface reaching the same destination, with a longer
 >   netmask (a more specific route) - the kernel would have switched to th=
 at
 >   one for all destinations reachable via that path - ie: everything on
 >   192.168.10/24 - that's why you have ARP entries:
 >  =20
 >   192.168.10.2       3c:a6:2f:3e:25:35  UHL         -        -      -  w=
 m1
 >   192.168.10.6       08:00:27:b3:81:f0  UHL         -        -      -  w=
 m1
 >   192.168.10.2       3c:a6:2f:3e:25:35  UHL         -        -      -  w=
 m0
 >   192.168.10.6       08:00:27:b3:81:f0  UHL         -        -      -  w=
 m0
 >  =20
 >   on both interfaces to the same destination, the wm0 ones were the
 >   originals, then the system switched to using wm1 when that one was
 >   configured.
 >  =20
 >   When wm1 goes down, without anything removing that routing (which
 >   removing the address would do), the system lacks a working path to
 >   the destination, and as that's your NFS server for / everything is
 >   just going to hang until wm1 comes back again - but without the
 >   ability to run anything any more that would be a very long time!
 >  =20
 >   But you have the solution already:
 >  =20
 >     | What also works is giving the interface a ip in another network:
 >     | >>>
 >     | ifconfig wm1 192.168.100.97
 >     | ifconfig wm1 down
 >     | <<<
 >  =20
 >   In that case, wm1 is not providing access to 192.168.10/24 addresses,
 >   so packets to those addresses will not be sent that way.   You could
 >   "fix" that with additional routing.
 >  =20
 >   This is the way that IP was designed to work - every network interface
 >   gets a distinct, and unique, network prefix, just for it, and for noth=
 ing
 >   else.   These days, in the IPv4 world, that's limited to being within =
 your
 >   local NAT free area, as there just aren't enough unique prefixes for
 >   everyone, but there are plenty for you to use on your LAN that you don=
 't
 >   need to cheat the addressing the way you are attempting.
 >  =20
 >   kre
 >  =20
 
 
 Hi,
 
 thanks for your answer. Your right, the netmask is the problem.
 When I do a "ifconfig wm1 192.168.10.97/20" (same netmask as for wm0) I=20
 can down wm1 without freezes.
 
 That solves the thing for me.
 You can close the issue.
 
 Thanks a lot!
 
 Kind regards
 Ekkehard
 
 (Pitty that Claude did not mention the netmask, though).