I have searched through entire internet and none of the solutions I found worked, so probably its time to ask for help.

I have Raspberry Pi 3B+ and i want it to work (for privacy reasons):

  • with VPN,
  • with disabled ipv6,
  • spoofing MAC address on startup, ideally to a random address.

I manage Pi headless through ssh and vnc server, which may be a problem, because I don't see what is happening after resetting networking.
Pi have connection to internet through router on eth0 port. My router is set to ipv4 and have ipv6 disabled, I set it to give IPs in range to, router's address is

  1. After clean instal of Raspbian Stretch i connect through ssh and set basic config, update & upgrade all packages.
  2. Then I set static ip by adding lines to dhcpcd.conf (geany /etc/dhcpcd.conf):

    • interface eth0
    • noipv6
    • static ip_address=
    • static routers=
    • static domain_name_servers=
  3. After that, I disable ipv6 by editing ipv6.conf (geany /etc/modprobe.d/ipv6.conf):

    • uncomment line: alias ipv6 off
    • add line: blacklist ipv6

I also add comments to lines that contain ipv6 at hosts (geany /etc/hosts) and add line "AddressFamily inet" to sshd_config (geany /etc/ssh/sshd_config).

  1. Next, I install openvpn (apt-get install openvpn resolvconf network-manager-openvpn), add my configuration file and set openvpn to start on boot by uncommenting AUTOSTART="all" (nano /etc/default/openvpn).

  2. At this point i have perfectly working Pi with VPN and disabled ipv6. The problem begins when I want to change/spoof MAC address.
    I tried to use macchanger and different commands (like "hw ether"), but nothing worked and I got stuck here. There are no internet connection on Pi and it is not possible to reach him through local network.

I took my Pi to a friend (since i dont have monitor) to check what is going on after i change MAC address. It turned out that after changing MAC system does not get new IP from router and sometimes set Local-Link IP (169.254.x.x) or wierd (10.0.x.x), but sometimes nothing happen at all and stay without any IP address.
I tried to manage changing MAC address without static IP, but it was the same - Local-Link IP or nothing at all.

Those are examples of commands I tried:

  • ifconfig eth0 down; macchanger -r eth0; ifconfig eth0 up
  • ifconfig eth0 down; ifconfig eth0 hw ether [pasted random mac]; ifconfig eth0 up

Also I was trying to stop network services before and restart them after spoofing MAC, but non of them helped:

  • service network-manager stop/start/restart
  • service networking stop/start/restart
  • systemctl restart dhcpcd

I also tried changing default route (found it in one of tutorials while doing research) but it also have not worked.

  • route add default gw

After reboot everything is back to the state from step 5 and Pi works normally with original MAC address. Anyone have idea how to solve this and set spoofing MAC address?

edit 1:

I found out that problem only exist on eth0 port (which I want to use because it is faster). When I change MAC address on Pi's wlan0 port, it normally get new IP from router after I reset DHCP. I use this command to successfully change MAC on wlan0:

  • ifconfig wlan0 down && macchanger -r wlan0; ifconfig wlan0 up; systemctl restart dhcpcd

Any ideas why this work on wlan0 but when I do the same sequence for eth0 it does not get new IP?

  • 1
    00:00:00:00:00:aa Are you sure this is the correct/valid address? – Fabian Jun 8 at 12:07
  • 2
    What OS are you running? Most of the commands you are running are meaningless on Raspbian Stretch sudo systemctl restart dhcpcd should restart networking, but I suggest you reboot. What do you mean by "how to make it work?" - What IT? 169.254.x.x is NOT a static address it is a Link-local address Why on earth do you want to change MAC? – Milliways Jun 8 at 12:32
  • 2
    service may still exist for backward compatibility but probably not forever -- you should stop using it and instead, as Milliways points out, use systemd commands. – goldilocks Jun 8 at 13:03
  • The point about the link local address is it is one that will never work for anything; you need an address appropriate to the subnet you are on and that is not one. If you are not sure what that is, try without a static IP and check what you get from the router. At least the first three numbers need to be the same. Also, just because you want a static IP does not mean the router will allow it (i.e., it may not work if you use it). You need to configure the router to do that. You need to sort these problems out before you tackle the MAC issue. – goldilocks Jun 10 at 10:49
  • "This was just example." if you mask things it's ok but please make it clear, say it in your question, else it can be misleading (the rest of your comment is addressed not to me, right?) – Fabian Jun 10 at 13:51

I had same problem with Raspberry Pi 3 B+. Try changing MAC in the kernel. In




The kernel starts with new MAC and DHCPD works.

Try removing the /24 from your static IP address, although I suspect this is more of a network-related problem than a pi-related problem...

Your router hears from a device (your pi) with a certain mac address - let's just use :aa for the sake of example (assume this is a valid mac address, baked into the pi's hardware) that it is going to take the static IP .110. Your router then associates :aa with the IP .100 and assigns it that DHCP lease. Your router should be set up for a certain amount of time to allot that DHCP lease for. When you randomize your mac and your pi tries to rejoin the network via your router, your router sees 'I have a [new] device trying to take the .110 IP, but that's reserved for the device :aa ... I'm not giving this new device an IP that's already reserved.'

You may be able to solve this by forcing the pi to notify the router that it is terminating the DHCP lease before randomizing the mac, and then the new mac will be able to acquire the specified static IP once randomization is complete.

However, it might be a better idea to move your static IP outside of the DHCP range, for deconfliction purposes. That way there is no lease that the DHCP server on your router is managing, and you may be able to get more granular control of your IP, using only the pi's static IP configuration.

A middle-ground might also include turning off static IP settings in the pi and letting DHCP assign consecutive IPs for testing purposes; it shouldn't be too hard to iterate through DHCP-assigned IPs starting at the bottom of the pool to ensure your mac randomization is still allowing the router to assign an IP. (This would eliminate one of your potential problems and confirm all is working well in one configuration).

Theoretically, depending on your router, DHCP server, and level of network-fu, you could even make a dedicated DHCP server on eth0 of your router (if that is the eth0 you referenced earlier) and limit that DHCP server to only one IP - while disabling static IP settings on your pi.


  • Try release/renewing your DHCP lease before/after mac randomization (maybe dhcpd can do this? I apologize, it's been a while since I tried dhcp control at that level).
  • Try moving your static IP out of the DHCP range; this might remove the router's management of that IP.
  • Try disabling static IP for temporary testing purposes while you confirm that mac randomization does indeed work.

Please do cite your solution once you find one; this sounds like a useful implementation for any privacy-aware individual looking to use a pi for similar uses.

  • /24 does not make any difference and as far as I know, it should be there. You may be right about static IP, because my router show two devices on one IP after changing MAC - original one with name i set and new one with "unknown" name (but it is the same RPI with changed MAC). To avoid this I turned off static IP. When I set static IP outside DHCP range, it does not make any change - Pi still set himself Link-Local IP (169.x.x.x). My router does not have option to set dedicated DHCP for a chosen interface, it have one built-in for all ports and it can not be changed. – user87309 Jun 12 at 10:14

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.