I have a fixed IP address assigned via DHCP to a machine that I just updated to F31.
After the update, I was slightly surprised when it didn't come up on its fixed IP address. After looking through the logs, the DHCP server is now apparently getting a DHCP request from a different MAC address, apparently the bridge's MAC address. I updated the DHCP config, and brought the network connection down/up, and it came up on its fixed IP address, normally.
In F30, the kernel was kernel-5.3.11-200.fc30.x86_64, and it's now kernel-5.3.11-300.fc31.x86_64, of course; so this doesn't look like a kernel change.
The relevant data is:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master vnet0 state UP group default qlen 1000 link/ether 00:30:48:fc:83:fa brd ff:ff:ff:ff:ff:ff inet6 fe80::230:48ff:fefc:83fa/64 scope link valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 00:30:48:fc:83:fb brd ff:ff:ff:ff:ff:ff 4: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 96:03:13:50:00:eb brd ff:ff:ff:ff:ff:ff inet 192.168.0.2/24 brd 192.168.0.255 scope global dynamic vnet0 valid_lft 603710sec preferred_lft 603710sec inet6 fe80::9403:13ff:fe50:eb/64 scope link valid_lft forever preferred_lft forever
Up until F30, the DHCP server was seeing requests from 00:30:48:fc:83:fa, and now the DHCP server is seeing requests from 96:03:13:50:00:eb.
I'm hoping that, at least, the bridge won't be getting random MAC addresses with every boot?
On Sat, 16 Nov 2019 13:04:50 -0500 Sam Varshavchik wrote:
DHCP server is now apparently getting a DHCP request from a different MAC address, apparently the bridge's MAC address.
Yep, for some reason (they are calling a "bug") the bridge no longer gets the same MAC as the one physical interface attached to it. You can make things normal again by adding the HWADDR="same mac as physical interface" parameter to the ifcfg-<bridge> file.
On Sat, 16 Nov 2019 13:48:43 -0500 Tom Horsley wrote:
You can make things normal again by adding the HWADDR="same mac as physical interface" parameter to the ifcfg-<bridge> file.
Wups! I tell a lie. The parameter you need is MACADDR, not HWADDR.
Here's my ifcfg-br0:
# Networking Interface DEVICE=br0 TYPE=Bridge BOOTPROTO=static GATEWAY=192.168.1.1 IPADDR=192.168.1.106 IPV6INIT=no NETMASK=255.255.255.0 ONBOOT=yes PEERDNS=no USERCTL=no NM_CONTROLLED=no MACADDR=74:d0:2b:2b:7a:b4
Tom Horsley writes:
On Sat, 16 Nov 2019 13:48:43 -0500 Tom Horsley wrote:
You can make things normal again by adding the HWADDR="same mac as physical interface" parameter to the ifcfg-<bridge> file.
Wups! I tell a lie. The parameter you need is MACADDR, not HWADDR.
So, it's HWADDR in the ifcfg for the actual physical interface, and MACADDR for TYPE=Bridge?
Well, since a bridge isn't really hardware, I guess you don't want to call this a hardware address…
On Sat, 16 Nov 2019 14:18:17 -0500 Sam Varshavchik wrote:
So, it's HWADDR in the ifcfg for the actual physical interface, and MACADDR for TYPE=Bridge?
Actually you can use MACADDR on a physical interface as well to spoof a different mac. Anything that queries the mac is being mediated by the kernel, so the kernel can tell everyone else anything it pleases :-).
On Sat, Nov 16, 2019 at 7:05 PM Sam Varshavchik mrsam@courier-mta.com wrote:
I have a fixed IP address assigned via DHCP to a machine that I just updated to F31.
After the update, I was slightly surprised when it didn't come up on its fixed IP address. After looking through the logs, the DHCP server is now apparently getting a DHCP request from a different MAC address, apparently the bridge's MAC address. I updated the DHCP config, and brought the network connection down/up, and it came up on its fixed IP address, normally.
In F30, the kernel was kernel-5.3.11-200.fc30.x86_64, and it's now kernel-5.3.11-300.fc31.x86_64, of course; so this doesn't look like a kernel change.
The relevant data is:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master vnet0 state UP group default qlen 1000 link/ether 00:30:48:fc:83:fa brd ff:ff:ff:ff:ff:ff inet6 fe80::230:48ff:fefc:83fa/64 scope link valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 00:30:48:fc:83:fb brd ff:ff:ff:ff:ff:ff 4: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 96:03:13:50:00:eb brd ff:ff:ff:ff:ff:ff inet 192.168.0.2/24 brd 192.168.0.255 scope global dynamic vnet0 valid_lft 603710sec preferred_lft 603710sec inet6 fe80::9403:13ff:fe50:eb/64 scope link valid_lft forever preferred_lft forever
Up until F30, the DHCP server was seeing requests from 00:30:48:fc:83:fa, and now the DHCP server is seeing requests from 96:03:13:50:00:eb.
I'm hoping that, at least, the bridge won't be getting random MAC addresses with every boot?
There was a thread here earlier this month about having to set the bridge MAC address with "MACADDRESS=mac_address_of_eth0" to ensure that vnet0 inherits the same MAC address of its first slave.
This must be an NM issue because ip behaves "normally":
# ip l sh dev wlo1 | g ether link/ether 18:56:80:7e:d3:da brd ff:ff:ff:ff:ff:ff
# ip l add dummy0 type dummy
# ip l sh dev dummy0 | g ether link/ether ea:e4:fb:6f:97:b1 brd ff:ff:ff:ff:ff:ff
# ip l add bridge0 type bridge
# ip l sh dev bridge0 | g ether link/ether fa:1b:c7:58:5a:b3 brd ff:ff:ff:ff:ff:ff
# ip l set dev dummy0 master bridge0
# ip l sh dev bridge0 | g ether link/ether ea:e4:fb:6f:97:b1 brd ff:ff:ff:ff:ff:ff
#
networkd had the same problem as NM but it's apparently been fixed
-
Sam Varshavchik -
Tom H -
Tom Horsley