Weird behaviour with Raspberry Pi Zero W regarding DHCP IP address and MAC address

Question

I've tried to 'fix' the IP of my Raspberry Pi Zero W in the local network by creating a DHCP rule in the router: always allocate 192.168.0.109 to the MAC address of the Pi. I use a D-Link router and by default the reserved pool for DHCP is 192.168.0.100 to 192.168.0.199. I tried setting the IP outside of that range but got the error "IP address for 'raspberrypi' should within DHCP IP address range".

The problem is that it almost never works, sometimes it starts with the 'correct' IP but then switches, sometimes it starts out directly with a different IP. When I check in the router DHCP client list the Pi lists with it's actual network IP but a different MAC than it's supposed to have. When I check on the Pi with ifconfig it reports it's actual network IP (but not the 109 one, different ones) but the original MAC (The one used to create the DHCP rule that is not respected).

So my issue is that with the MAC the Pi reports it should have an IP, but it has a different IP and the router also says that it has a different MAC than it should. I tried both methods from this post (both the /etc/network/interfaces and the /boot/config.txt, I even checked to make sure I don't have network-manager installed, to no avail). I don't know what to try anymore and the behaviour continues. Any ideas or help?

Edit: I also saw mentioned in some other posts so I checked /proc/cpuinfo for the serial numbers and they're not all zeros, they seem OK, and I bought it from an authorized reseller, so I'm thinking it's not a counterfeit hardware problem. Everything works fine, including the networking, just not the IP/MAC addresses...

Answer 1

This is a dynamic failure and not having access to the network it's a little bit difficult to analyze. But I see two possibilities for the failure.

First: the mac address is fixed and bind to the hardware (you can change it but I don't take it into account here). So if you see a mac address that is not that from your raspi then it is not your raspi. It is another one but having the ip address 192.168.0.109. This can occur if the DHCP server is wrong configured. For example the pool for dynamic ip addresses is 192.168.0.100 to 192.168.0.200 and you bind 192.168.0.109 to the mac of your raspi then the DHCP server may have a conflict. Any other raspi asked for a dynamic ip address and get 192.168.0.109 from the pool. Next your raspi asked for its ip address and the DHCP server tries to give it 192.168.0.109 but there is already a device with that ip address on the network active. So what shall the DHCP server do? I think it will give an ip address from its pool. To avoid this you should bind an ip address to your raspi not contained in the pool, e.g. 192.168.0.201.

Second: there is a second DHCP server active on your network and both will reply to requests from devices. The quicker one wins. If your router wins your raspi will get the right ip address, if the unknown DHCP server wins it will get an ip address from the unknown pool.

If you are interested in more details you can look at Does dhcpcd prevent a remote DHCP server serving an IP address that is declared static? I have just asked for some days.

troubleshooting:
With the updated information about the D-Link router you should google for d-link router static ip address and ask in a D-Link forum how it works and why your router does not give the static ip address to your RasPi as configured.

Then you should search for the device in your network having the unknown mac address but getting the ip address 192.168.0.109. If you have found it look at its configuration, shut it down and look if your problem persists.

Verify that there is no second DHCP server running on your network. For this you can search for it with sudo tcpdump -i wlan0 -e -n port 67 or port 68. Another simple test is to temporary shut down your router and look if your devices still get ip addresses. Look at google find second dhcp server.

The RasPi gets the ip address that is offered to it. So far it looks that your issue is not related to Raspberry Pi.