https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=298773
Bug ID: 298773
Summary: possible race condition caused problem with bridge
device initialisation in rc.conf & netif
Product: Base System
Version: 15.1-RELEASE
Hardware: amd64
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: conf
Assignee: [email protected]
Reporter: [email protected]
A FreeBSD 15.1 system has an IP binding on its single ethernet device re0.
Bastille is installed. This requires use of a bridge device which bastille
defines as bridge0 but then alias/names re0bridge for subsequent use.
FreeBSD 15 deprecates direct IP binding on the base ethernet device. Thus in
/etc/rc.conf:
ifconfig_re0="inet 192.168.1.16/24 up" has to be moved to re0bridge.
but
ifconfig_re0="up"
cloned_interfaces="lo1 bridge0"
ifconfig_bridge0_name="re0bridge"
ifconfig_re0="up"
ifconfig_re0bridge="addm re0 inet 192.168.1.16/24 up"
does not work. however the subsequent ipv6 binding:
ifconfig_re0bridge_ipv6="inet6 2401:2000:6660::16/64"
does work.
The use of the autobridge_re0bridge command in rc.conf to define re0 as a
member of the bridge appears to invoke alternate paths which work:
# jails
bastille_enable="YES"
ifconfig_re0="up"
# bridge for bastille.
cloned_interfaces="lo1 bridge0"
ifconfig_lo1_name="bastille0"
ifconfig_bridge0_name="re0bridge"
autobridge_interfaces="re0bridge"
autobridge_re0bridge="re0"
ifconfig_re0bridge="inet 192.168.1.16/24 up"
ifconfig_re0bridge_ipv6="inet6 2401:2000:6660::16/64"
succeeds in both ipv4 and ipv6.
the same problem happens if # service netif restart is invoked.
I therefore suspect a pathway in /etc/rc.d/netif or a code path invoked via
that path in rc processes through /etc/rc.conf has some kind of race condition,
around interface renaming and binding the inet phase.
I have not investigated if bastille can cope without the interface name binding
to re0bridge, I appreciate that might also avoid this problem.
The deprecation of interface direct binding of IP addresses is bringing this to
the fore. I think it would help to either find the race condition, or to
document that the interface binding should be done via autobridge, not inline
via addm.
--
You are receiving this mail because:
You are the assignee for the bug.
