[Bug 258257] /etc/rc.d/netif handles renamed VLAN interfaces incorrectly

From: <bugzilla-noreply_at_freebsd.org>
Date: Fri, 03 Sep 2021 18:17:07 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258257

            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="DHCP"
vlans_re0="3 10"
ifconfig_re0_3="inet 192.168.3.8/24"
ifconfig_re0_10_name="re0.l"
ifconfig_re0_l="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 netif 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, modified:

ifconfig_re0="DHCP"
vlans_re0="3 10"
ifconfig_re0_3="inet 192.168.3.8/24"
ifconfig_re0_10="inet 192.168.10.8/24 name re0.l"
ifconfig_re0_l="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 address
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 needs 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. This is
because we're still in a strange state, since "service netif stop" leaves the
re0.l interface existing.

It seems to me that the correct solution looks like this: childif_create should
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 determine
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 scripts
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 expect
to happen, see
https://forums.FreeBSD.org/threads/renamed-vlan-interface-needs-netif-restart-to-start.81904/post-530039

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