On the latest stable release (24.10 on a RPi5), the MAC address on my eth1 interface changed from one value to another yesterday. Without, seemingly, any action by myself to cause it.
The interface is an external PCIe card. It's been working fine for a couple of months, going from latest snapshot to 24.10 when it was released (so a completely new install on to a new SD card).
This change been confirmed by my ISP who are helping me get IPv6 working again - one issue 'their' side may be due to the MAC address changing and static addresses getting confused...
It is a "Waveshare PCIe TO Gigabit RJ45 Ethernet Adapter Board", a "High-Performance Controller.Onboard Original High-Performance RTL8111H Chip". I bought an expensive 'proper' board from a reputable stockist that was DOA, but that's another story. This was less than 1/4 the cost from Amazon.
ethtool output
root@OpenWrt:~# ethtool eth1
Settings for eth1:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
Link partner advertised pause frame use: Symmetric Receive-only
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 0
Transceiver: external
Auto-negotiation: on
MDI-X: Unknown
Supports Wake-on: pumbg
Wake-on: d
Link detected: yes
I could, of course, set the MAC back to the original value, but that's another hard-coded configuration step. I will likely do that anyhow to prevent this issue happening again. Or swap eth1 and eth0, trusting that the Pi's onboard interface won't suddenly alter its MAC address.
Just keen to understand what would have caused this. It's not like I did a firmware update at 1400ish yesterday afternoon. I did happen to access the luci statistics page, to look (funnily, given I've now no IPv6 access) at the proportion of IPv4:IPv6 traffic. [1/3:2/3 if of interest]
Is your provider Vodafone? I am asking because I have some troubles in bridged modem mode and an openwrt router isn't working anymore although line, IP and DNS servers are present.
Not Vodafone - I’m on YouFibre. I have other issues with them around getting IPv6 connectivity on the router itself (another post on here a couple of weeks ago). But that is due to their set-up of having addresses assigned that aren’t publicly reachable, so traffic can go out but can’t get back.
Last night I spoofed the MAC address on the WAN interface to the ‘old’ value and my ‘old’ IPv6 address got assigned but a new non-static IPv4 also got assigned. Reverting back to the ‘new’ address got me my static IPv4 address back but the ‘wrong’ IPv6. This leads me to think the MAC address change has caused a confusion their end.
Some really cheap manufacturers don't bother to "burn in" a factory MAC since that requires the factory to file for an OUI and do accounting to make sure they don't make two boards with the same MAC. (Or they could buy chips already burned with the chip maker's OUI and unique MAC, but they will cost more than blank ones.) Not finding a factory MAC, the driver gives these a random MAC at startup.
Is the board marked with a label with a MAC on it?
Ahh, that makes total sense. I’ll check the physical board.
So a sensible action in any case would be to move the WAN to my Pi’s onboard ethernet connection which I’d imagine has a baked-on MAC. The LAN can use the cheap card and if its MAC changes no-one will notice or care.