Repository navigation
Released IP not offered again to the same client after reboot #2242
Description
Here is how I reproduce this issue:
- The lease time is set to one hour
- "Ignore Client Identifier (Option 61)" — it does not matter whether it is on or off
- After a cold boot, I reboot the machine within 5 minutes
Batocera then gets a new IP.
Here is the DHCP log on reboot:
[2026-10-19 22:54:54 UTC] [192.168.10.100:68] DHCP Server released IP address [192.168.10.100] that was leased to BATOCERA.lan.local [AA-BB-CC-DD-EE-01] for scope: lan
[2026-10-19 22:54:54 UTC] DHCP Server successfully saved scope file: /etc/dns/scopes/lan.scope
[2026-10-19 22:55:22 UTC] [0.0.0.0:68] DHCP Server offered IP address [192.168.10.101] to BATOCERA [AA-BB-CC-DD-EE-01] for scope: lan
[2026-10-19 22:55:22 UTC] [0.0.0.0:68] DHCP Server leased IP address [192.168.10.101] to BATOCERA [AA-BB-CC-DD-EE-01] for scope: lan
[2026-10-19 22:55:24 UTC] DHCP Server successfully saved scope file: /etc/dns/scopes/lan.scope
And the tcpdump on reboot:
22:54:54.736626 IP (tos 0x0, ttl 64, id 28295, offset 0, flags [DF], proto UDP (17), length 576)
192.168.10.100.68 > 192.168.10.1.67: [udp sum ok] BOOTP/DHCP, Request from aa:bb:cc:dd:ee:01, length 548, xid 0x486d0c45, Flags [none] (0x0000)
Client-IP 192.168.10.100
Client-Ethernet-Address aa:bb:cc:dd:ee:01
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Release
Server-ID (54), length 4: 192.168.10.1
22:55:22.260247 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 576)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from aa:bb:cc:dd:ee:01, length 548, xid 0xd23e7bb6, secs 6, Flags [Broadcast] (0x8000)
Client-Ethernet-Address aa:bb:cc:dd:ee:01
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Discover
MSZ (57), length 2: 576
Parameter-Request (55), length 8:
Subnet-Mask (1), Default-Gateway (3), MTU (26), Unknown (252)
NTP (42), Domain-Name (15), Domain-Name-Server (6), Hostname (12)
Client-ID (61), length 7: ether aa:bb:cc:dd:ee:01
Hostname (12), length 8: "BATOCERA"
22:55:22.262919 IP (tos 0x0, ttl 64, id 22230, offset 0, flags [DF], proto UDP (17), length 337)
192.168.10.1.67 > 255.255.255.255.68: [bad udp cksum 0x06f8 -> 0xffb9!] BOOTP/DHCP, Reply, length 309, xid 0xd23e7bb6, secs 6, Flags [Broadcast] (0x8000)
Your-IP 192.168.10.101
Server-IP 192.168.10.1
Client-Ethernet-Address aa:bb:cc:dd:ee:01
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Offer
Server-ID (54), length 4: 192.168.10.1
Lease-Time (51), length 4: 3600
RN (58), length 4: 1800
RB (59), length 4: 3150
Subnet-Mask (1), length 4: 255.255.255.0
BR (28), length 4: 192.168.10.255
Default-Gateway (3), length 4: 192.168.10.254
NTP (42), length 4: 192.168.10.254
Domain-Name (15), length 9: "lan.local"
Domain-Name-Server (6), length 4: 192.168.10.253
22:55:22.275899 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 576)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from aa:bb:cc:dd:ee:01, length 548, xid 0xd23e7bb6, secs 6, Flags [Broadcast] (0x8000)
Client-Ethernet-Address aa:bb:cc:dd:ee:01
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Request
Requested-IP (50), length 4: 192.168.10.101
Server-ID (54), length 4: 192.168.10.1
MSZ (57), length 2: 576
Parameter-Request (55), length 8:
Subnet-Mask (1), Default-Gateway (3), MTU (26), Unknown (252)
NTP (42), Domain-Name (15), Domain-Name-Server (6), Hostname (12)
Client-ID (61), length 7: ether aa:bb:cc:dd:ee:01
Hostname (12), length 8: "BATOCERA"
22:55:22.276919 IP (tos 0x0, ttl 64, id 22232, offset 0, flags [DF], proto UDP (17), length 337)
192.168.10.1.67 > 255.255.255.255.68: [bad udp cksum 0x06f8 -> 0xfcb9!] BOOTP/DHCP, Reply, length 309, xid 0xd23e7bb6, secs 6, Flags [Broadcast] (0x8000)
Your-IP 192.168.10.101
Server-IP 192.168.10.1
Client-Ethernet-Address aa:bb:cc:dd:ee:01
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: ACK
Server-ID (54), length 4: 192.168.10.1
Lease-Time (51), length 4: 3600
RN (58), length 4: 1800
RB (59), length 4: 3150
Subnet-Mask (1), length 4: 255.255.255.0
BR (28), length 4: 192.168.10.255
Default-Gateway (3), length 4: 192.168.10.254
NTP (42), length 4: 192.168.10.254
Domain-Name (15), length 9: "lan.local"
Domain-Name-Server (6), length 4: 192.168.10.253
A Ubuntu machine does not trigger this behavior: after the same reboot sequence, it is offered its previous IP.
Note that there is no release event in the DHCP log for the Ubuntu machine.
[2026-10-19 22:58:17 UTC] [0.0.0.0:68] DHCP Server offered IP address [192.168.10.102] to ubuntu [AA-BB-CC-DD-EE-02] for scope: lan
[2026-10-19 22:58:17 UTC] [0.0.0.0:68] DHCP Server leased IP address [192.168.10.102] to ubuntu [AA-BB-CC-DD-EE-02] for scope: lan
[2026-10-19 22:58:24 UTC] DHCP Server successfully saved scope file: /etc/dns/scopes/lan.scope
The related tcpdump:
22:58:03.788611 IP (tos 0xc0, ttl 64, id 10355, offset 0, flags [DF], proto UDP (17), length 293)
192.168.10.102.68 > 192.168.10.1.67: [udp sum ok] BOOTP/DHCP, Request from aa:bb:cc:dd:ee:02, length 265, xid 0xc30fccd0, secs 40, Flags [none] (0x0000)
Client-IP 192.168.10.102
Client-Ethernet-Address aa:bb:cc:dd:ee:02
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Release
Client-ID (61), length 19: hardware-type 255, xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
22:58:17.354663 IP (tos 0xc0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 329)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from aa:bb:cc:dd:ee:02, length 301, xid 0xd2a68c40, secs 1, Flags [none] (0x0000)
Client-Ethernet-Address aa:bb:cc:dd:ee:02
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Discover
Client-ID (61), length 19: hardware-type 255, xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
Parameter-Request (55), length 12:
Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Hostname (12)
Domain-Name (15), MTU (26), Static-Route (33), NTP (42)
URL (114), Unknown (120), Classless-Static-Route (121), Unknown (162)
MSZ (57), length 2: 1472
SLP-NA (80), length 0""
Hostname (12), length 14: "ubuntu"
22:58:17.355630 IP (tos 0x0, ttl 64, id 35573, offset 0, flags [DF], proto UDP (17), length 337)
192.168.10.1.67 > 255.255.255.255.68: [bad udp cksum 0x06f8 -> 0xaeee!] BOOTP/DHCP, Reply, length 309, xid 0xd2a68c40, secs 1, Flags [none] (0x0000)
Your-IP 192.168.10.102
Server-IP 192.168.10.1
Client-Ethernet-Address aa:bb:cc:dd:ee:02
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Offer
Server-ID (54), length 4: 192.168.10.1
Lease-Time (51), length 4: 3600
RN (58), length 4: 1800
RB (59), length 4: 3150
Subnet-Mask (1), length 4: 255.255.255.0
BR (28), length 4: 192.168.10.255
Default-Gateway (3), length 4: 192.168.10.254
Domain-Name-Server (6), length 4: 192.168.10.253
Domain-Name (15), length 9: "lan.local"
NTP (42), length 4: 192.168.10.254
22:58:17.356883 IP (tos 0xc0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 339)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from aa:bb:cc:dd:ee:02, length 311, xid 0xd2a68c40, secs 1, Flags [none] (0x0000)
Client-Ethernet-Address aa:bb:cc:dd:ee:02
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Request
Client-ID (61), length 19: hardware-type 255, xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
Parameter-Request (55), length 12:
Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Hostname (12)
Domain-Name (15), MTU (26), Static-Route (33), NTP (42)
URL (114), Unknown (120), Classless-Static-Route (121), Unknown (162)
MSZ (57), length 2: 1472
Server-ID (54), length 4: 192.168.10.1
Requested-IP (50), length 4: 192.168.10.102
Hostname (12), length 14: "ubuntu"
22:58:17.358798 IP (tos 0x0, ttl 64, id 35574, offset 0, flags [DF], proto UDP (17), length 337)
192.168.10.1.67 > 255.255.255.255.68: [bad udp cksum 0x06f8 -> 0xabee!] BOOTP/DHCP, Reply, length 309, xid 0xd2a68c40, secs 1, Flags [none] (0x0000)
Your-IP 192.168.10.102
Server-IP 192.168.10.1
Client-Ethernet-Address aa:bb:cc:dd:ee:02
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: ACK
Server-ID (54), length 4: 192.168.10.1
Lease-Time (51), length 4: 3600
RN (58), length 4: 1800
RB (59), length 4: 3150
Subnet-Mask (1), length 4: 255.255.255.0
BR (28), length 4: 192.168.10.255
Default-Gateway (3), length 4: 192.168.10.254
Domain-Name-Server (6), length 4: 192.168.10.253
Domain-Name (15), length 9: "lan.local"
NTP (42), length 4: 192.168.10.254
Is there a way to offer the previously released IP address?
Activity
Apachez- commentedon Oct 20, 2026
What kind of OS is this first box?
I know that windows behaves differently when it comes to DHCP regarding if it will be sending broadcast or unicast but that usually ends up not getting an IP at all if that would be the case here.
Would using option82 be a possibility for you? That is whatever is connected to SW2-15 will always get the same lease no matter what the dhcp or duid is being used?
ShreyasZare commentedon Oct 20, 2026
Thanks for the post. This is expected since the client released its lease when it rebooted and thus there is no guarantee that it will get the same IP address again.
In case of Ubuntu, the client did not release lease but remembered it and asked to renew the same lease when it booted. Thus it kept the same IP address.
If you need the client to have same IP then use the context menu option for the lease to convert the dynamic lease to a reserved lease. That will cause the client to always have the same IP address.
But unless you host something on the client that requires static IP, it really does not matter what IP the client got assigned since you can always reach it with its domain name when you have the Domain Name option configured for the scope.
NEOhidra commentedon Oct 20, 2026
A Linux distro.
It sound good - it will be a good fit for non complaint clients also.
NEOhidra commentedon Oct 20, 2026
Isnt it there a DHCPRELEASE message at 22:58:03.788611 ?
According to 3.1 Client-server interaction - allocating a network address the steps for requesting an IP address are:
Reclaiming an IP address is a process with different steps - if the client remembered it then look at 3.2 Client-server interaction - reusing a previously allocated network address and the steps are:
To me it looks more like the first case - Client-server interaction - allocating a network address.
It does not look to be a case of Ubuntu trying to reuse a previously allocated network address - plus Technitium is ignoring the Ubuntus release message.
ShreyasZare commentedon Oct 21, 2026
@NEOhidra Thanks for the response. There is not enough data to know how the DHCP transaction went. The logs are just specific snippets and the config is not known too.
In any case, a DHCP server can assign any random IP address to clients even when a client requests a specific IP address. Why the DHCP Server choose a specific dynamic IP is something that depends on its internal state too and not always predictable.
If the requirement is to have a specific IP on the client then the only option is to configure a reserved lease. That is the only solution here. There is really nothing to fix at the DHCP server end regarding what dynamic IP is to be selected for a client.
NEOhidra commentedon Oct 21, 2026
The tcpdump does not qualify as descriptive enough about a lease delegation?
What would you use/what procedure do you qualify as descriptive enough - regarding the network communication with DHCP clients?
ShreyasZare commentedon Oct 21, 2026
The tcpdump does not tell if the DHCP server ignored Ubuntu client's release message. The logs you shared may have missed the release entry. Its also not clear if the lease way dynamic or reserved. If it was reserved then it makes sense that the DHCP server offered the same IP.
Again, in any case, there is really nothing to say why a client got a specific IP while the other got the one it had previously leased. Its dynamic IP and you cannot expect the DHCP server to give same IP to clients as there is no internal table to remember what each client was assigned after the lease expires or is released.
Apachez- commentedon Oct 21, 2026
That and option82.
Reserved lease gives the same IP no matter where the client is located.
Option82 gives the same IP no matter what is connected to a physical location (such as SW2-INT15).
A cornercase is how the DHCP server behaves if it detects that the client is no longer present even without a RELEASE from the client.
Then the old IP address is technically available again in the random pool but should not be selected as first option in case previous client returns. Dunno if technitium use the strict mode as in if client is gone then the IP is up for grab or loose mode where it will avoid give out previously leased IP's until really needed.