I use my router’s DHCP service to assign predictable IP addresses based on MAC addresses, so that my /etc/host tables can be the same across a variety of systems (OSX, Raspbian, openSUSE).
On TW 5.1.3, after copying the /lib/firmware/brcm/brcmfmac43455-sdio.raspberrypi,3-model-b-plus.txt over from a LEAP 15.1 install, I see that it has the assignment
macaddr=b8:27:eb:74:f2:6c
but ifconfig shows
ether da:2e:87:81:1f:e7
and, in fact, changes with reboot.
I’m not sure what’s changing the MAC address on me: is there a way to ensure a fixed MAC address for the wlan0 device?
It’s an issue that has been reported and asked about several times in these Forums…
Sometimes someone comes up with a solution, and sometimes the problem comes back so I took another look around just now…
Found the following article with promising solutions…
I’m not in front of my RPi Zero right now (the problem you describe affects all Pies) so I can’t verify whether uboot has a cmdline.txt file, but if it does, then the first solution that is mentioned in many places could work but I’m going to guess that the file might not be found in uboot (used by everything that’s not Rasbian).
Still, if uboot doesn’t have cmdline.txt, I know there is a similar configuration file that is read on bootup, there is documentation where you can specify such things as Display parameters, special I/O, environmentals, etc
The second solution looks promising, although I haven’t tried it on a RPi, I’ve run the macchanger app several times on regular PCs and it does what is expected well.
I recommend installing it, since it changes your MAC address long after the network is set up by the system defaults, so should over-write successively to whatever you want.
And if macchanger doesn’t work, then the idea behind what it’s supposed to do inspires me to do the same by defining your MAC address in /etc/sysctl.conf. If you need to set this up and can’t figure out how to do this on your own, post here and I’ll figure out what the entry should be.
Good Morning, TSU,
… and thanks. No cmdline.txt in uboot. And I don’t see anything in sysctl.conf that would let me set the MAC address on the internal WiFi device.
But I did just download macchanger on my TW 5.1.3 install, so I may be able to make it work that way. Good suggestions! Much appreciated!
This is one of the reasons (besides non-functional clones of SD-cards and unreliable updates) why I don’t use opensuse on raspis anymore (besides some cards with functional installs which I don’t touch anymore but only use them as-is). This “random-MAC” feature is a pain. No way to get rid of it via entering a cloned MAC in NetworkManager? Haven’t tried recently…
Just confirming that the macchanger solution works. Did a “zypper in” on my TW 5.1.3 install, ran it, and got this:
Pi-6:/boot # macchanger -r wlan0
Current MAC: 36:8b:93:c2:c2:5d (unknown)
Permanent MAC: b8:27:eb:c1:63:ae (Raspberry Pi Foundation)
New MAC: aa:a5:ba:53:04:bf (unknown)
Did an “ifdown wlan0”, “macchanger -m b8:27:eb:c1:63:ae wlan0” to change back to the permanent MAC address, and then checked again:
Pi-6:/boot # macchanger -m b8:27:eb:c1:63:ae wlan0
Current MAC: aa:a5:ba:53:04:bf (unknown)
Permanent MAC: b8:27:eb:c1:63:ae (Raspberry Pi Foundation)
New MAC: b8:27:eb:c1:63:ae (Raspberry Pi Foundation)
A subsequent “ifup wlan0” resulted in the WiFi having the correct IP address assigned by my router’s DHCP service. So this approach works.
I’ll see if I can figure out how to run macchanger in the startup process so the WiFi comes up with the right IP address each time.
I could, of course, just assign a static IP address to the device, and in the end that might be the smartest way to go.
Whoever thought that it’s a good idea to randomize MAC addresses, as a new default standard, should be … castigated. To SUSE_RASPUTIN’s point. But I don’t think this is an openSUSE issue … it seems to have been done somewhere upstream.
****! Went back to my TW system 15 min later and something had changed the MAC address and done an “ifdown” - “ifup” sequence, so the IP address had been changed.
Reverting to static IP looks like the best solution.
Curious what might have changed on your system and over-ride macchanger…And if your MAC really been reset (perhaps likely but should be verified to make sure it’s something unrelated)
If and only if your MAC had really changed, then
I’d expect that running macchanger manually followed by restarting the network service (systemctl restart network) if needed should have fixed the problem again…
The /etc/sysctl.conf solution I mentioned wouldn’t have anything useful in it by default… You would find the User mode command that would ordinarily be run in a console manually(In your case set a MAC address, likely a spoof command) and insert that into the /etc/sysctl.conf file. Ordinarily, this file is used for other things but for decades people have taken advantage of what it can do and its timing (late in the boot process) which allows commands to over-ride system settings which might be fixed and cannot be changed without re-compiling the kernel.
Yeah, me, too. I’d kill and uninstall that app if I could figure out what it is.
If and only if your MAC had really changed, then
I’d expect that running macchanger manually followed by restarting the network service (systemctl restart network) if needed should have fixed the problem again…
This behavior is getting weirder and weirder.
I was away all day yesterday. Checked this morning, and the IP had been changed (at least once in the last 24 hours) but the wlan0 IP address was the same!
Became root and checked, and the IP was the same (wrong) value but the MAC address was different (again, 2 minutes later!)
Did the “ifdown” - “macchanger -m” - “ifup” sequence and the MAC was the internal Pi wlan0 MAC address (as it should be) and the IP was the correct, router-DHCP-assigned IP address I want it to be.
So it appears that any boot-time hack I might do to get a persistent IP in this new environment would be undone some arbitrary time later. Again, it looks like static IP is the only solution unless (as I suspect) this is a bug and will get fixed in a future release.
The /etc/sysctl.conf solution I mentioned wouldn’t have anything useful in it by default… You would find the User mode command that would ordinarily be run in a console manually(In your case set a MAC address, likely a spoof command) and insert that into the /etc/sysctl.conf file. Ordinarily, this file is used for other things but for decades people have taken advantage of what it can do and its timing (late in the boot process) which allows commands to over-ride system settings which might be fixed and cannot be changed without re-compiling the kernel.
Since something is changing the MAC address dynamically right now, I think any boot-time solution is going to be insufficient to fix the problem.
Let’s see if this gets fixed upstream.
Ah, I see that “zypper dup” is prepared to install 5.1.5 over 5.1.3:
The following product is going to be upgraded:
openSUSE Tumbleweed 20190520-0 -> 20190602-0
Yeah, that didn’t work. Something wrong with the package:
Retrieving: python3-cairo-1.18.0-1.2.aarch64.rpm ...............................................................[error (12.6 KiB/s)]
Downloaded data exceeded the expected filesize '153.0 KiB' of 'http://download.opensuse.org/ports/aarch64/tumbleweed/repo/oss/aarch64/python3-cairo-1.18.0-1.2.aarch64.rpm'.
Tried it a couple of times and got the same result. I’ll try again later and hope it’s fixed.
Thanks for the suggestion and the link, Karl – that might be worth trying, and I’ll bookmark the link for future testing.
But this seems to have been resolved on my RPi-3B+ with with the 5.1.5 update. I’ve rebooted a couple of times and let it sit idle for several hours, and the MAC address has been persistently the permanent hardware address (no randomization) and the IP is correctly assigned by the DHCP service as a result.
Given the time I’ve put into this over the last few days, I think I won’t tinker with it any more right now, but I’ll look at the systemd approach when I’ve got a bit more time.
But perhaps someone can point me to some documentation about the current state of wicked vs NetworkManager. It appears that I have to run both, but I’m not sure which one I should be managing. NetworkManager.conf seems to have no effect, but it has to be running. I need an overview of how this stuff fits together, but something current and in the openSUSE environment.
But if systemd lets me get rid of both and manage from one place, that would be a win! Is this the direction openSUSE is going?
Actually you need only one of wicked, NetworkManger and systemd-networkd. Each of them works well on my i7-6700K and and i3-4130 machines. Problems occur with installing many operating systems and frequent updating. While I am using Tumbleweed for most of the time, rebooting into Fedora and later returning to Tumbleweed would render the network adapter inoperable and some more annoyances. systemd-networkd turned out to be the most robust for the above machines.