W dniu 16.05.2025 o 23:38, Kristof Provost pisze:
On 16 May 2025, at 23:26, Marek Zarychta wrote:
W dniu 16.05.2025 o 22:38, Kristof Provost pisze:
On 15 May 2025, at 21:32, Marek Zarychta wrote:
W dniu 15.05.2025 o 20:59, Cy Schubert pisze:
In message [email protected],
Cy Schubert writes:
Over the last couple of days epair(4) fails to set
up when an IP address is
specified.
bob# service jail onestart test2
Starting jails: cannot start jail "test2":
epair0a
ifconfig: ioctl (SIOCAIFADDR): Invalid argument
jail: test2: /sbin/ifconfig epair0a inet 10.1.1.70
netmask 0xffffff00 up:
failed
.
bob# ifconfig epair0a inet 10.1.1.70 netmask
0xffffff00
ifconfig: ioctl (SIOCAIFADDR): Invalid argument
bob# ifconfig epair0a inet up
bob#
This regression is caused by b61850c4e6f6.
Yes, it requires at least head up, similar to old one,
known from fibs :
WARNING: Configuring address on bridge(4) member has been
turned off by default. Consider tuning
net.link.bridge.member_ifaddrs if needed.
The error message should not suggest changing the sysctl. This
is a configuration error and will lead to subtle and
unexpected problems.
The intent is for the sysctl to go away and for this to be
entirely disallowed, without a way to bypass the check in 16.0.
As Lexi pointed out in another e-mail: users should assign
addresses to the bridge, never to bridge member interfaces.
—
Kristof
Thanks for the statement. Some may consider this a POLA violation.
If you insist on removing the sysctl, it will require additional
work to update all existing vm-bhyve and jail setups before
upgrading to 16.0-RELEASE, whenever it is released.
Only the misconfigured ones. There’s no reason to ever assign IP
addresses to member interfaces.
Again, |ifconfig bridge0 inet 192.0.2.1/24| is perfectly okay and will
continue to work. |ifconfig bridge0 addm epair0a ; ifconfig epair0a
inet 192.0.2.1/24| is not.
The documentation has had this warning for a long time: “If the bridge
host needs an IP address, set it on the bridge interface, not on the
member interfaces.“
https://docs.freebsd.org/en/books/handbook/advanced-networking/index.html
It should probably have been more prominent, but preventing
foot-shooting is better than warning about the foot-shooting.
—
Kristof
Got it - that sounds like a solid plan. Updating incompatible setups,
one by one, before the release of FreeBSD 16.0-RELEASE will help reduce
last-minute issues and make the transition smoother.
Cheers
Marek
