Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 03 Sep 2021 18:17:07 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 258257] /etc/rc.d/netif handles renamed VLAN interfaces incorrectly
Message-ID:  <bug-258257-227@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D258257

            Bug ID: 258257
           Summary: /etc/rc.d/netif handles renamed VLAN interfaces
                    incorrectly
           Product: Base System
           Version: 13.0-RELEASE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: conf
          Assignee: bugs@FreeBSD.org
          Reporter: mkern@alconconstruction.com

For the case I'm describing, I have a network interface re0 (driver doesn't
matter), and I need to bring up the main interface, as well as VLANs 3 and =
10.
The interface for vlan10 needs to be renamed, from re0.10 to re0.l. Here are
the relevant lines from rc.conf, for how I understand to configure this:

ifconfig_re0=3D"DHCP"
vlans_re0=3D"3 10"
ifconfig_re0_3=3D"inet 192.168.3.8/24"
ifconfig_re0_10_name=3D"re0.l"
ifconfig_re0_l=3D"inet 192.168.10.8/24"

However, this does not work. The first time through netif, re0 and re0.3 are
brought up properly, and re0.10 with no configuration is created. Then, when
devd starts, it discovers a not-yet-setup re0.10, and eventually calls neti=
f to
start re0.10. This time, netif finds the line to rename re0.10, and does so=
 -
and then fails to find any more information for configuring re0.10, and so
leaves me with re0.l with no configuration.

At this point, running "service netif restart re0.l" (or even without
explicitly naming the interface) will set up re0.l properly. However the
intention is for the interface to come up automatically.

For now, I've discovered a functioning workaround. The above config, modifi=
ed:

ifconfig_re0=3D"DHCP"
vlans_re0=3D"3 10"
ifconfig_re0_3=3D"inet 192.168.3.8/24"
ifconfig_re0_10=3D"inet 192.168.10.8/24 name re0.l"
ifconfig_re0_l=3D"inet 192.168.10.8/24"

In this case, the first boot through ends up mostly working properly - this
time, childif_create feeds that full line into ifconfig, which sets the add=
ress
and renames it all at once. The next step, which calls "ifconfig re0.10 up"
fails, but the interface ends up in the up state anyway. The last line need=
s to
be present to ensure that restarting netif works - since on any time through
after the first, re0.l is discovered and explicitly brought up by name. Thi=
s is
because we're still in a strange state, since "service netif stop" leaves t=
he
re0.l interface existing.

It seems to me that the correct solution looks like this: childif_create sh=
ould
go through all the steps that netif_start does, rather than skipping to
ifn_start (in particular, it needs to call the ifnet_rename function). In
addition, netif_start (and childif_create as described above) should determ=
ine
whether ifnet_rename actually renamed what we're working on, and switch to =
that
new name for the remainder of the function. Unfortunately, I must leave the
exact details of the implementation up to someone who understands these scr=
ipts
and how they relate to each other better than I do.

For a slightly more detailed run through of what's happening, and what I ex=
pect
to happen, see
https://forums.FreeBSD.org/threads/renamed-vlan-interface-needs-netif-resta=
rt-to-start.81904/post-530039

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-258257-227>