Bridge, static MAC.

C

CeXP1917

FreeBSD 15.0-RELEASE-p5, trying set static MAC address for bridge. In rc.conf:
Code: 
ifconfig_bridge0="ether xx:xx:xx:xx:70:70"
ifconfig_bridge0="inet 192.168.xxx.xxx netmask 255.255.255.0 addm igc1 addm igc2 addm igc3"
ifconfig_bridge0_ipv6="inet6 myulaaddr prefixlen 64 up"
In logs:
Code: 
Mar 31 21:59:44 host kernel: bridge0: Ethernet address: xx:xx:xx:xx:07:5d

MAC is static, but tail of address is changed. Is this a bug or I missing something?
 
There are two ifconfig_bridge0 variable in the rc.conf the the former (ether ...) is overwritten and has no effect.
Change the second ifconfig_bridge0 to ifconfig_brige0_alias0. (see /etc/defaults/rc.conf)
 
Common trap to fall into, yes. rc.conf is essentially a shell script that only contains variable assignments, don't treat them as 'commands'. rc.conf isn't parsed, it gets sourced.

Code: 
foo="FOO"
foo="BAR"

echo $foo
This prints "BAR" because the second assignment overruled the first.
 
Found: a "up" word in ifconfig_bridge string with ifconfig_igbX="... up" before.

Now with create_args everything work fine.

SirDice said:
isn't parsed, it gets sourced.
Click to expand...
Strange, on server with latest 14 this works:
Code: 
cloned_interfaces="bridge0"
create_args_bridge0="inet6 auto_linklocal"
ifconfig_bridge0="ether static_macaddr"
ifconfig_bridge0="inet ipaddr netmask mask up"
 
CeXP1917 said:
Found: a "up" word in ifconfig_bridge string with ifconfig_igbX="... up" before.
Click to expand...
Any unconfigured interface defaults to 'down', when you configure it; ifconfig_igb0="..." it's automatically set to "up". However, if you configure a VLAN on top of an interface you need to make sure the parent interface is "up", or else it would be "down"; i.e. not functional.
So you'll see things like this:
Code: 
vlans_igb0="10 20"
ifconfig_igb0="up"
ifconfig_igb0_10="inet 1.2.3.4 netmask 255.255.255.0"
ifconfig_igb0_20="inet 5.6.7.8 netmask 255.255.255.0"

CeXP1917 said:
Strange, on server with latest 14 this works:
Click to expand...
No, it won't. How rc.conf is handled hasn't changed since I started with 3.0. It has always been sourced (multiple times) through /etc/rc.subr (which is a collection of functions all rc(8) scripts use).
 
SirDice said:
No, it won't. How rc.conf is handled hasn't changed since I started with 3.0. It has always been sourced (multiple times) through /etc/rc.subr (which is a collection of functions all rc(8) scripts use).
Click to expand...
But somehow that two lines worked on 14. Maybe changes in 15 made sourcing more strict.
Code: 
# diff rc.subr-14 rc.subr-15 
...
1537c1971
<                       . /etc/defaults/rc.conf
---
>                       $_dot /etc/defaults/rc.conf
...
 
Sigh, it's a shell script. How the shell deals with variables hasn't changed in over 40 years, probably even longer.

Code: 
dice@molly:~/temp % cat my.conf
ifconfig_blah="something"
ifconfig_blah="else"
dice@molly:~/temp % cat rc.sh
#!/bin/sh

. my.conf

echo $ifconfig_blah
dice@molly:~/temp % sh rc.sh
else
 
If the order of creation of cloned interfaces are same, it tends to get the same MAC address nowadays (I do not remember from which version exactly).
Updating the OS may break these 'conditions'.
I think, what op thought it worked, is just a normal behavior without overridden settings, and updating the OS or hardware revealed that it did not really work as op intended.
 
You must log in or register to reply here.
Back
Top