Same problem as here: SCALE not respecting dhcp reservation | TrueNAS Community
The IP address will not respect the reservation on my asus router. IP randomly bounces around in the middle of a file transfer. Manually releasing an renewing and it wont update to the correct IP.
I ended up setting the interface to a static IP so it isn’t using DHCP but something seems broken here…
You probably have the wrong MAC address configured in DHCP on your router.
Even if your DHCP reservation isn’t working you still shouldn’t see your IP address actually changing.
Once a lease is accepted by a client it should check in with the DHCP server once it reaches the half life of the lease time and ask to extend the lease. The leased IP address should only change if the DHCP server has handed out the address to another client (which shouldn’t happen).
You’re better off giving it a static address, though.
FWIW, if your server is changing it’s IP address while up and running that could well be feeding into the problems you mentioned in the other thread about apps not working…
I set it to static before I got the errors I posted in the other thread. and no the mac address is not incorrect in my router.
After setting this statically in TrueNAS I have not had an issue again… I verified the MAC is right on the DHCP reservation in my router.
same exact issue here, pfsense netgate 6100, I went to the lease it had, converted it to static reservation with the new IP I wanted to persist but it will NOT update itself, wireshark indicates it isn’t even sending the request out…
TrueNAS wouldn’t be the culprit, that’d be your dhcp server that’s not handing out the reservation.
That being said, are you sure you don’t have more than one dhcp server on the network? Getting a different lease is exactly what that sounds like. A dhcp client will attempt to renew its lease halfway through the set lease time and will tend to keep the same lease address for days if not months due to the renewal. That is unless something else is offering it a different address.
You really need to watch the dhcp traffic on the wire to see where this new address is coming from.
Check your DHCP logs if you’re using kea. It seems to not always restart correctly in the latest release(s) when updating settings. This just happened to me. I’m also using a 6100. There is at least one issue open regarding this bug on their redmine instance.
If you see logs “failed to bind fallback socket to address” stop the service in the UI, get on the shell, ps -A | grep kea and kill any old processes, then start it again in the UI.
You can also access the shell on truenas, delete the lease file in /var/lib/dhcp, remove the address from the interface ip addr del <address>/<mask> dev <interface> and run dhclient manually to check that you get the correct address after. Once I got kea in good shape on the netgate I got what I expected.
