mac address changes on each reboot

[oupala]

I have a problem and the problem is simple to explain: the mac address of my raspberry pi 1 changes on each reboot.

It make dhcp and nat config hard to maintain.

Do you have such behaviour on your raspberries?

[goranche]

🤔 no... could you provide the output from cat /proc/cpuinfo

[oupala]

Sure! Here is my cpuinfo file:

>cat /proc/cpuinfo 
processor	: 0
model name	: ARMv6-compatible processor rev 7 (v6l)
BogoMIPS	: 697.95
Features	: half thumb fastmult vfp edsp java tls 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xb76
CPU revision	: 7

Hardware	: BCM2708
Revision	: 0000
Serial		: 00000000481f76bc

[goranche]

the Revision number in that output is 0000, which is wrong (I've "heard" about boards like that; also. the serial number can be all zeros)...
it's likely there is a problem with these values...

what board exactly is this happening on?
(raspberry pi 1 doesn't really exist, I'm guessing you meant Model B, but what revision, RAM?, ...)

[oupala]

Thanks for pointing the origin of the problem @goranche

In fact, I have 2 raspberries, whose /proc/cpuinfo are the following:

>cat /proc/cpuinfo 
processor	: 0
model name	: ARMv6-compatible processor rev 7 (v6l)
BogoMIPS	: 697.95
Features	: half thumb fastmult vfp edsp java tls 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xb76
CPU revision	: 7

Hardware	: BCM2708
Revision	: 0000
Serial		: 00000000481f76bc

>cat /proc/cpuinfo 
processor	: 0
model name	: ARMv6-compatible processor rev 7 (v6l)
BogoMIPS	: 697.95
Features	: half thumb fastmult vfp edsp java tls 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xb76
CPU revision	: 7

Hardware	: BCM2708
Revision	: 000e
Serial		: 00000000807cd7d5

Their both Model B Rev 2 (revision 000e) but one of them seems to be broken and to have lost its revision (see reference).

I bought both of them at the same time, and both went well for months and years.

And now, for no particular reason, one of the raspberries went wrong and lost its revision.

I'd like to know why. If anyone has a clue about that, please tell me!

[goranche]

you could try adding the following to config.txt:

program_board_rev=e

boot, and check cpuinfo... and then remove... hope this helps

disclaimer: this of course is not guaranteed to do anything, and might break stuff :D
I'm not taking any blame... also, it's the reason why I first wanted to know about the actual board, because I have no idea what happens if you set it to the wrong revision... 🤔 I have a couple of older boards that are gathering dust, might try it out 😅

[goranche]

also, just to be sure... does the serial number change between boots?
because there is also a directive to program the serial number (to a random number, at least)

[oupala]

The serial number does not seem to change between boots.

[oupala]

Adding program_board_rev=e to config.txt seems to have no effect. :-(

[goranche]

huh... 🤔 I'm not sure about the "e", you might try 14, since it's supposed to be hex

other than that... I'm out of ideas, sorry 😉

[Mausy5043]

The serialnumber is hardcoded into the SoC. It cannot be changed. If it appears changed this may mean that the firmware is in someway altered. Possibly an SEU

How old is the image on your SD? i.e. When did you install it?

[goranche]

The serialnumber is hardcoded into the SoC

not really, no... that would make production of the SoCs way too expensive...

the serial number (as well as the hardware revision) can be written to, but I'm not sure with which version of the firmware (or possibly hardware) this was removed from the public interface (mainly because of licensing the mp4 stuff)... but it was possible to change the number (to a random number one)

how else do you think the hardware revision could be set to 0? 😉
and if you google around, you'll find reports of the same thing happening to the serial number as well

[oupala]

I still haven't found a solution for this problem.

However, I found a workaround that consist in hard coding a mac address as described in this post (see post from dRm on Tue May 26, 2015 2:06 am).

To apply this workaround, just edit the file /boot/cmdline.txt and add the mac address parameter:

dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p6 rootfstype=ext4 elevator=deadline rootwait smsc95xx.macaddr=91:90:5e:df:8c:85

I'm still looking for a real solution.

[Zeerix]

@oupala What firmware version is installed on the "broken" Pi? Did you make an "apt-get upgrade" recently?

I just noticed that both my RPis (2B and 3B) have the same problem (Revision = 0000, can't say anything about the MAC because I don't use eth0), whenever I boot with the new firmware package: raspberrypi-bootloader-nokernel 1.20170427-1.
When I boot with the older package, the Revision is back to normal.

[goranche]

When I boot with the older package, the Revision is back to normal.

oh, that's not good... 🤔

[oupala]

@Zeerix I'm using raspbian-ua-netinst v1.0.9 (from this repo).

I first discovered this problem yesterday while reinstalling raspbian from scratch as described in the doc.

I don't know which firmware is installed, but it should be the one installed by the installation process of raspbian-ua-netinst.

[oupala]

Maybe this thread can give a clue on what's happening.

Extract:

The raspberry pi passes the revision, serial number, mac address as
parameters to the kernel during boot. When i start via u-boot, u-boot
receives this parameters and does not pass them to the kernel. Thats why
the revision field is empty.

[Mausy5043]

Could there be a relation with #472?

[goranche]

interesting... possible that something in a package (probably kernel or boot related) changed...
might take a look... some time this week... I hope 😒

[goranche]

Could there be a relation with #472?

doubt it... possible, but unlikely

[Zeerix]

Could there be a relation with #472?

My guess: Kernel is old (May 2016), firmware is new (April 2017) and something changed in how things are passed between them.

[Zeerix]

I don't know which firmware is installed, but it should be the one installed by the installation process of raspbian-ua-netinst.

That's the newest firmware in Raspbian, which just got updated.

Myself wrote:

When I boot with the older package, the Revision is back to normal.

I just updated to kernel 4.9 from the Raspbian repository, and the Revision is back to normal. So again, my guess is that the old kernel is incompatible with the new firmware package.

After the update, uname -a shows this:
Linux pi3 4.9.0-2-rpi2 #1 SMP Raspbian 4.9.13-1+rpi3 (2017-05-18) armv7l GNU/Linux

[oupala]

I noticed that my both raspberry pi have the same kernel but different firmware. One is working ok, the other one has the problem.

• the one that is ok

>uname -a
Linux pi2-ok 4.4.0-1-rpi #1 Debian 4.4.6-1+rpi14 (2016-05-05) armv6l GNU/Linux
>sudo /opt/vc/bin/vcgencmd version
May 20 2016 19:02:21 
Copyright (c) 2012 Broadcom
version faf071dd4885c5ac1a89483d35a5326e7f69495f (clean) (release)

• the one that has the problem

>uname -a
Linux pi2-ko 4.4.0-1-rpi #1 Debian 4.4.6-1+rpi14 (2016-05-05) armv6l GNU/Linux
>sudo /opt/vc/bin/vcgencmd version
Apr 27 2017 17:21:38 
Copyright (c) 2012 Broadcom
version 17af5814bb19dbb7c70ccd2c845b80a160943811 (clean) (release)

I wonder how is raspbian-ua-netinst managing kernel and firmware version at first install and at reinstall. Maybe @diederikdehaas has an idea about that!

[Mausy5043]

There's definitely an upstream problem. This morning's install:

=================================================
raspbian-ua-netinst
=================================================
Revision git~93d2a91
Built on Sun Jun 11 10:09:10 CEST 2017
Running on Raspberry Pi version unknown
=================================================
https://github.com/debian-pi/raspbian-ua-netinst/
=================================================
Starting HWRNG succeeded!
Copying boot files... OK
=================================================
=== Start executing installer-config.txt. ===
=== Finished executing installer-config.txt. ===
=================================================

Network configuration:
 ip4_addr = dhcp
 ip6_addr = disable
 online_config = 

Waiting for eth0... 
OK
Configuring eth0 for IPv4 using DHCP... 10.0.1.225/24
Time set using ntpdate to... Sun Jun 11 08:16:26 UTC 2017

Installation started at Sun Jun 11 08:16:07 UTC 2017.


=================================================
    No Raspberry Pi hardware detected!!
Value of cpu_revision variable: '0000'
         Building for Pi 1, 2 and 3.         
=================================================

[Mausy5043]

End of the log:

Configuring apt:
  Copying raspbian repo to sources.list... OK
  Replacing __RELEASE__ with jessie... OK
  Adding raspberrypi.org gpg key to apt-key.
  Copying ./raspberrypi.org.list to /etc/apt/sources.list.d/... OK
  Copying ./01vcgencmd.pref to /etc/apt/preferences.d/... OK
Updating package lists... OK
Installing bootloader package (=firmware)... OK
Installing libraspberrypi-bin package (=vcgencmd,raspistill,raspivid,etc)... OK
Configuring bootloader to start the installed system...
Adding boot config for kernel version: '4.9.0-2-rpi'
Copying kernel to /boot/kernel.img... OK
Adding boot config for kernel version: '4.9.0-2-rpi2'
Copying kernel to /boot/kernel7.img... OK
Adding boot config for kernel version: '4.9.0-2-rpi2'
Creating default cmdline.txt... OK
=================================================
=== Start executing post-install.txt. ===

After the reboot:

pi@rbian ~ $ uname -a
Linux rbian 4.9.0-2-rpi #1 Raspbian 4.9.13-1+rpi3 (2017-05-18) armv6l GNU/Linux
pi@rbian ~ $ cat /proc/cpu
cpu/     cpuinfo
pi@rbian ~ $ cat /proc/cpuinfo
processor	: 0
model name	: ARMv6-compatible processor rev 7 (v6l)
BogoMIPS	: 697.95
Features	: half thumb fastmult vfp edsp java tls
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xb76
CPU revision	: 7

Hardware	: BCM2835
Revision	: 0010
Serial		: 00000000b72f8406

Odd.

[Mausy5043]

Installing with #475 (installer using kernel 4.9) in place resulted in (ignoring, for the moment, the HWRNG error):

=================================================
raspbian-ua-netinst
=================================================
Revision git~93d2a91
Built on Sun Jun 11 11:50:54 CEST 2017
Running on Raspberry Pi version 1
=================================================
https://github.com/debian-pi/raspbian-ua-netinst/
=================================================
Starting HWRNG error reading from entropy source:: No such device
FAILED! (continuing to use the software RNG)
Copying boot files... OK
=================================================
=== Start executing installer-config.txt. ===
=== Finished executing installer-config.txt. ===
=================================================

Network configuration:
  ip4_addr = dhcp
  ip6_addr = disable
  online_config =

Waiting for eth0...
OK
Configuring eth0 for IPv4 using DHCP... 10.0.1.93/24
Time set using ntpdate to... Sun Jun 11 10:01:27 UTC 2017

Installation started at Sun Jun 11 10:01:06 UTC 2017.

So, using kernel 4.9 seems to fix this.

pi@rbian ~ $ uname -a
Linux rbian 4.9.0-2-rpi #1 Raspbian 4.9.13-1+rpi3 (2017-05-18) armv6l GNU/Linux
pi@rbian ~ $ cat /proc/cpuinfo
processor	: 0
model name	: ARMv6-compatible processor rev 7 (v6l)
BogoMIPS	: 997.78
Features	: half thumb fastmult vfp edsp java tls
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xb76
CPU revision	: 7

Hardware	: BCM2835
Revision	: 0010
Serial		: 00000000b72f8406

[mutability]

FWIW:

I maintain a sdcard image (https://flightaware.com/adsb/piaware/build) which is built via raspbian-ua-netinst. The piaware software, for historical installs, relies on the hardware MAC address to identify the user.

Recently there have been a spate of reports from users who have done a package upgrade from older images, which will upgrade the firmware but not the kernel IIRC, who then end up with randomly assigned MACs and so lose their feeder<->user association.

So far I have not managed to reproduce it on my own Pi but it sounds like the same problem described here and the kernel vs. firmware mismatch is a pretty big clue which I will investigate some more..

edit: reproduced the same problem by upgrading the bootloader but not the kernel.

[Mausy5043]

PR #475 will fix this.

[dam09fr]

Hello,
I've this problem too with my RPI3.
/proc/cpuinfo gives me "Revision : 000000" with Kernel 4.4 and mac changes every time I reboot my Pi.
Since I update to 4.9 kernel the problem is gone and /proc/cpuinfo gives me "Revision : a02082"
Hope it'll help.

[oupala]

Does anyone knows how and when this could be fixed?

Is it just a matter a merging pr #475 ?

[BenjaminHae]

When you're on an already installed system running an upgrade and then fixing /boot/config.txt worked for me:

kernel=vmlinuz-4.9.0-2-rpi
initramfs initrd.img-4.9.0-2-rpi followkernel

If you plan to reinstall #475 should solve it.

[oupala]

As I'm testing the full installation of a raspbian home server via ansible, I need to reinstall the system in order to test my playbook.

I have to wait for the merge request then.

[kpfleming]

If you are building your own installer from the v1.1.x branch, you can merge the pull request locally, or you can clone the pull request branch (do a search for "github clone pull request") and then build from that branch.

[oupala]

It appears that #475 has been merged on 15 Jul while release v1.1.1-beta3 has been published on 3 Aug.

I should then be able to test this beta release.

[oupala]

The release v1.1.1-beta3 seems to fix the bug as I succeeded to install it (so #485 seems to be fixed also) and boot with a MAC address that does not change.

I can't tell if I got the original MAC address as I can't remember it, but cat /proc/cpuinfo gives me Revision : 000d.

So I guess the problem has been fixed upstream. But I can't tell how it would work with the old 1.0.x installer.

[kunli0]

This just happened to me... I installed network-manager to utilize nmcli, however it kept saying the wlan0 was unavailable. I rebooted the pi zero w and it still wouldn't work, so I went back to square one and set up the wifi using wpa_supplicant.conf. Upon doing so I was able to connect via wifi but unable to SSH. I rebooted a couple of times and found the MAC address was changing each time. I removed network-manager, rebooted, and everything is back to normal.

[tomasz-wiszkowski]

yeah, it still happens. I don't think anything mentioned above helps on RPi 3.

• applying hw ether via /etc/network/interfaces.d takes effect only after i manually restart networking service,
• applying smsc95xx.macaddr=xx:xx:xx:xx:xx:xx takes no effect,

a simple update ended up as a painful troubleshooting for me. I have no clue how or when is this mac address generated, but instead of tinkering i am pretty much trying to figure out how to fix this randomization thing.

[Zeerix]

yeah, it still happens. I don't think anything mentioned above helps on RPi 3.

Which installer version do you use? And which kernel?

[tomasz-wiszkowski]

I use raspbian stretch, lite, updated recently to kernel 4.9.41-v7+ (dc4@dc4-XPS13-9333).

My CPU has a valid revision (a22082) but that doesn't stop wlan driver from randomizing mac address. Something else must be going on.

[Zeerix]

Are you actually using this installer? Because, I don't think it uses kernel 4.9.41 at all.

If yes, try installing with the most recent version.
If not, you probably need a firmware package upgrade, but this is not the place to ask.

[tomasz-wiszkowski]

I used installer, and then issued apt-get update && apt-get upgrade.

FWIW i see the correct mac address reported via udevadm monitor -up. Also, after pulling kernel 4.9.56-v7+ with rpi-update the problem persists, but now the response to 'ip link set dev...' and 'ifconfig hw ether' is: SIOCSIFHWADDR: Is a directory, so i'm essentially stuck with this behavior for good.

[tomasz-wiszkowski]

for anyone who wanders here with same problem and need immediate remedy:

edit /etc/network/interfaces.d/wlan0 file and put there:

auto wlan0
iface wlan0 inet dhcp
  pre-up /sbin/ip link set dev wlan0 address xx:xx:xx:xx:xx:xx

this seems to be working. sadly, that's only a work-around for the problem, not actual fix.

[Mausy5043]

@tomasz-wiszkowski :

I used installer, and then issued ...

Which version of the installer are you talking about.
Did you build from source? Which branch?
Or did you download a release? Which one

[tomasz-wiszkowski]

https://www.raspberrypi.org/downloads/raspbian/

i thought i mentioned this 5 comments above. Unless that's not the installer you're asking for, i probably need a little more clarifications. Googling around for 'raspberry pi installer' doesn't give any other information than installer images, so i figure that's what you were looking for...?

[Mausy5043]

For support on the Raspberry Pi Foundation's distribution you can use their forums:

https://www.raspberrypi.org/forums/

[marklester]

Found a post on the rpi forums. Apparently NetworkManager can randomize your mac to make it harder to people to snoop on traffic.

Here is a blog post on how to turn it off.
https://blog.muench-johannes.de/networkmanager-disable-mac-randomization-314
in case it goes down:

To disable the MAC address randomization create the file

  /etc/NetworkManager/conf.d/100-disable-wifi-mac-randomization.conf

with the content:

[connection]
wifi.mac-address-randomization=1
 
[device]
wifi.scan-rand-mac-address=no

[latel]

@marklester this works like charm

[GHSTUDIO1]

I realize this is an old thread....but the solution posted above doesn't work if you install the home assistant image....it only works if you install the docker/supervised image. I can't get to /etc/network/manager even with "terminal" addins.

How do you disable the security feature that changes the MAC on a raspberry pi 3?

[SysGh-st]

This is still a problem today. Just set up a brand new fresh out of factory Raspberry Pi 4 Model B. Installed a freshly downloaded raspian image two days ago from this posts date.
All MAC addresses (LAN and WLAN) randomizes each time the device reboots, and upon restarting the interfaces.
Mentioned "solution" about Network Manager does not work. I suspect it doesn't use Network Manager unless one installs and activates it, which I have not.

[diederikdehaas]

For support on the Raspberry Pi Foundation's distribution you can use their forums:

https://www.raspberrypi.org/forums/

This has nothing to do with this installer. Use the appropriate channels for your issue.