Bug 258257 - /etc/rc.d/netif handles renamed VLAN interfaces incorrectly
Summary: /etc/rc.d/netif handles renamed VLAN interfaces incorrectly
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: conf (show other bugs)
Version: 13.0-RELEASE
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-09-03 18:17 UTC by Matthew Kern
Modified: 2021-09-03 18:17 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Kern 2021-09-03 18:17:07 UTC
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