Bug 226260 - dhclient tells me $if is not dhcp-enabled even though it is
Summary: dhclient tells me $if is not dhcp-enabled even though it is
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: conf (show other bugs)
Version: 11.1-RELEASE
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-02-28 11:42 UTC by bas
Modified: 2018-07-29 17:24 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description bas 2018-02-28 11:42:46 UTC
I'm in the process of setting up bridging, so I add the following lines to /etc/rc.conf:

cloned_interfaces="bridge0"
ifconfig_bridge0="addm bge0 SYNCDHCP up"
ifconfig_bge0="up"

This works just fine. However, when I remove the files from /etc/rc.conf and instead add them to /etc/rc.conf.d/netif things break. The netif file does get processed, but /etc/rc.d/dhclient incorrectly throws the following warning:

'bridge0' is not a dhcp-enabled interface

In my view, it shouldn't make a difference whether I put my configuration in /etc/rc.conf or in /etc/rc.donf.d/netif but apparently it does.

I'm fairly attached to having separate files /etc/rc.conf.d because it makes managing the setup through Puppet just so much easier.
Comment 1 jpicalau+freebsd_bugzilla 2018-07-29 17:24:20 UTC
I just found this report while in the process of figuring out the same issue. I figure I should just as well provide some details and findings.

The reason why that configuration doesn't work when placed in /etc/rc.conf.d/netif is that the service that handles dhcp is dhclient, which goes and look for its configuration in /etc/rc.conf.d/dhclient.

Now, both netif and dhclient will also load /etc/rc.conf.d/network. (`load_rc_config network' in both of those services file). However, there is a comment against this loading line in /etc/rc.d/netif stating that this is loaded for compatibility, which I interpret as meaning that it might not work forever.

It seems like there is a more general issue with the /etc/rc.conf.d/ mechanism not being well-suited for handling variables used in network.subr. Any rc script including network.subr could start making use of a functionality that depends on one of those variables in the future and result in breakage for people having one of those set in /etc/rc.conf.d, but for another script. It would be good to get some clarity here in order to avoid such unexpected configuration issues.

In the meanwhile, I think it is prudent to use /etc/rc.conf for any variable that ends up being "shared" between rc scripts in this fashion.