Pihole DHCP acting up

I have been using a pihole (in a VM) for a while now (around 4yrs I think) with very little issue, its been great, however an issue started randomly yesterday and i'm pulling my hair out trying to figure it out.

Start of the issue

I have around 23 devices on the LAN, some windows, some linux, and some IoT devices.
Starting around 11am yesterday i noticed that my main PC had a different IP than usual (I have it set as reserved in the pihole) so that sent me looking at why - turns out that the Wifi Extender had somehow turned its DHCP server on - so that was disabled and a quick release/renew and all is well again right?

Wrong.

Now most of my VMs and none of the IoT devices will get an IP from the pihole - all I see is screens of:

DHCPDISCOVER(eth0) 00:60:<redacted>
DHCPOFFER(eth0) 192.168.0.19 00:60:<redacted>
DHCPDISCOVER(eth0) 38:b4:<redacted>
DHCPOFFER(eth0) 192.168.0.106 38:b4:<redacted>

etc in the pihole log.

Strangeness continues
I have a SFF PC that handles about 5 vms, one of which being the pihole
The 3 linux VMs on the same machine refuse to get an IP from the pihole, but the windows ones will....

All the physical windows PCs seem to get an IP ok (I have tested around 5 at the moment) but NONE of the IoT devices will.

I also run a pxe server - which runs on the same host, reserved IP, and that works fine too!

I'm beginning to think there is something more nefarious going on, but I thought i'd ask here for any ideas!

Back to the Router!
Just to keep my sanity, I disabled the pihole dhcp and enabled it on the router - with moderate success. All the linux VMs and the IoT devices are now back on, but I cant use the pxe server with this method.

Debug Token:

https://tricorder.pi-hole.net/my0zUAdt/

Many Thanks,
Mike.

Those MACs you show would indicate Bosch and some Hausgeraete equipment.
Are you positive that those are your VM MACs?

I took a snapshot of the list, but they are the IoT devices, but the list is a lot longer than that...
Another update from me, I built a brand new VM and fresh install of pihole (both the latest ubuntu and pihole binaries) with the exact same results; windows VMs/and physical machines are fine, as are phones (android), but the issues lies with linux VMs and IoT devices.

A complete, successful DHCP negotiation sequence would have DHCPDISCOVER (client), DHCPOFFER (server), DHCPREQUEST (client), DHCPACK (server). Note that the procedure for a client renewing an existing lease about to expire would be shorter, starting with DHCPREQUEST.

Your logs demonstrate that Pi-hole has correctly reacted to a client's DHCPDISCOVER with a DHCPOFFER, but the client fails to request the lease.
This could suggest that Pi-hole's offer was not received by the client, or that the client is discarding the offer, and silently so.

Some devices would be looking for some vendor-specific options in the DHCP offer - however, that kind of behaviour is usually tied to same-manufacturer devices, so I'd consider both your Wifi extender as well as Pi-hole unlikely to provide those. i.e. the respective devices should never have worked at all.

If the client were to reject the offered IP because it thinks that IP is already in use by some other machine, then it should NAK the offer, not silently discard it and broadcast a new discover.

Still, is it possible that some of your devices would claim a static IP as configured manually on device, instead of requesting a DHCP lease, and that those IP may conflict with Pi-hole's offers?

Hi Again,

Thanks for responding.
I will admit its all strange as the windows clients all work fine.

I took the extender out of the equation after the dhcp error and not turned it back on, so its not doing much of anything until I get this resolved.

The only configured static I have is for the pihole (and the host it runs on), all the other systems use IP reservations so they get the same IP each time.

I have however turned the dhcp off on the pihole and back on on the router - without changing anything else, and everything connected and works fine (physicals/VMs and IoT devices) so it cant be network. it has to be something on the pihole.

I cant see anything that may have changed in the last few days that would cause this though.

Does that main PC runs Windows?
If so, try to actually release the lease first with below one on a CMD prompt:

ipconfig /release

And get a fresh one with below:

ipconfig /renew

FYI, those Windows systems (and most others) keep track of what IP was supplied to them before.
Most of the times stored on disk so its reboot persistent.
And when requesting a new lease, they request to have that same IP assigned again via the DHCP client option 50 --> "Requested IP address".

EDIT:

$ cat /var/lib/dhcp/dhclient.leases
lease {
  interface "eth0";
  fixed-address 10.0.0.145;
  option subnet-mask 255.255.255.0;
  option routers 10.0.0.1;
  option dhcp-lease-time 86400;
  option dhcp-message-type 5;
  option domain-name-servers 10.0.0.2,10.0.0.4;
  option dhcp-server-identifier 10.0.0.2;
  option dhcp-renewal-time 37963;
  option ntp-servers 10.0.0.3;
  option broadcast-address 10.0.0.255;
  option dhcp-rebinding-time 70363;
  option host-name "hak01";
  option domain-name "home.dehakkelaar.nl";
  renew 6 2024/02/03 20:36:04;
  rebind 0 2024/02/04 07:22:46;
  expire 0 2024/02/04 11:50:03;
}
lease {
  interface "eth0";
  fixed-address 10.0.0.145;
  option subnet-mask 255.255.255.0;
  option routers 10.0.0.1;
  option dhcp-lease-time 86400;
[..]
$ sudo tcpdump -nvvvi eth0 '(udp port 67 or udp port 68) and ether host 00:16:3e:XX:XX:XX'
[..]
13:32:35.367303 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 00:16:3e:XX:XX:XX, length 300, xid 0x4cacd34, Flags [none] (0x0000)
[..]
            Requested-IP Option 50, length 4: 10.0.0.145

Hi deHakklar,

Yes I have done this on 5 machines now, physical and VMs; all windows work fine.
Even rebooting and removing any reserved IPs, windows machines have worked

Just to check this is a pihole issue and NOT a config issue on my side, I have rebuilt a new pihole again, left vanilla and then enabled DHCP (while disabling the DHCP on the router)

The results are below:

20:Jan 17 09:46:20 dnsmasq-dhcp[5846]: DHCP, IP range 192.168.0.21 -- 192.168.0.251, lease time 1d
32:Jan 17 09:46:38 dnsmasq-dhcp[5846]: DHCPDISCOVER(eth0) 00:15:5d:00:9d:01
33:Jan 17 09:46:38 dnsmasq-dhcp[5846]: DHCPOFFER(eth0) 192.168.0.157 00:15:5d:00:9d:01
34:Jan 17 09:46:38 dnsmasq-dhcp[5846]: DHCPREQUEST(eth0) 192.168.0.157 00:15:5d:00:9d:01
35:Jan 17 09:46:38 dnsmasq-dhcp[5846]: DHCPACK(eth0) 192.168.0.157 00:15:5d:00:9d:01 YYYYYYYY
66:Jan 17 09:46:52 dnsmasq-dhcp[5954]: DHCP, IP range 192.168.0.21 -- 192.168.0.251, lease time 1d
106:Jan 17 09:47:16 dnsmasq-dhcp[5954]: DHCPDISCOVER(eth0) 192.168.0.5 b4:2e:99:3d:8b:dc
107:Jan 17 09:47:16 dnsmasq-dhcp[5954]: DHCPOFFER(eth0) 192.168.0.169 b4:2e:99:3d:8b:dc
108:Jan 17 09:47:18 dnsmasq-dhcp[5954]: DHCPDISCOVER(eth0) 192.168.0.5 b4:2e:99:3d:8b:dc
109:Jan 17 09:47:18 dnsmasq-dhcp[5954]: DHCPOFFER(eth0) 192.168.0.169 b4:2e:99:3d:8b:dc
110:Jan 17 09:47:26 dnsmasq-dhcp[5954]: DHCPDISCOVER(eth0) 192.168.0.5 b4:2e:99:3d:8b:dc
111:Jan 17 09:47:26 dnsmasq-dhcp[5954]: DHCPOFFER(eth0) 192.168.0.169 b4:2e:99:3d:8b:dc
112:Jan 17 09:47:26 dnsmasq-dhcp[5954]: DHCPREQUEST(eth0) 192.168.0.169 b4:2e:99:3d:8b:dc
113:Jan 17 09:47:26 dnsmasq-dhcp[5954]: DHCPACK(eth0) 192.168.0.169 b4:2e:99:3d:8b:dc XXXXXXXX
265:Jan 17 09:47:31 dnsmasq-dhcp[6066]: DHCP, IP range 192.168.0.21 -- 192.168.0.251, lease time 1d
485:Jan 17 09:48:14 dnsmasq-dhcp[6066]: DHCPDISCOVER(eth0) 00:15:5d:00:9d:0b
486:Jan 17 09:48:14 dnsmasq-dhcp[6066]: DHCPOFFER(eth0) 192.168.0.167 00:15:5d:00:9d:0b
487:Jan 17 09:48:14 dnsmasq-dhcp[6066]: DHCPDISCOVER(eth0) 00:15:5d:00:9d:0b
488:Jan 17 09:48:14 dnsmasq-dhcp[6066]: DHCPOFFER(eth0) 192.168.0.167 00:15:5d:00:9d:0b
489:Jan 17 09:48:18 dnsmasq-dhcp[6066]: DHCPDISCOVER(eth0) 00:15:5d:00:9d:0b
490:Jan 17 09:48:18 dnsmasq-dhcp[6066]: DHCPOFFER(eth0) 192.168.0.167 00:15:5d:00:9d:0b
499:Jan 17 09:48:25 dnsmasq-dhcp[6066]: DHCPDISCOVER(eth0) 00:15:5d:00:9d:0b
500:Jan 17 09:48:25 dnsmasq-dhcp[6066]: DHCPOFFER(eth0) 192.168.0.167 00:15:5d:00:9d:0b
510:Jan 17 09:48:32 dnsmasq-dhcp[6208]: DHCP, IP range 192.168.0.21 -- 192.168.0.251, lease time 1d
538:Jan 17 09:48:44 dnsmasq-dhcp[6208]: DHCPDISCOVER(eth0) 00:15:5d:00:9d:0b
539:Jan 17 09:48:44 dnsmasq-dhcp[6208]: DHCPOFFER(eth0) 192.168.0.167 00:15:5d:00:9d:0b
557:Jan 17 09:49:15 dnsmasq-dhcp[6208]: DHCPDISCOVER(eth0) 00:15:5d:00:9d:07
558:Jan 17 09:49:15 dnsmasq-dhcp[6208]: DHCPOFFER(eth0) 192.168.0.163 00:15:5d:00:9d:07
559:Jan 17 09:49:18 dnsmasq-dhcp[6208]: DHCPDISCOVER(eth0) 00:15:5d:00:9d:0b
560:Jan 17 09:49:18 dnsmasq-dhcp[6208]: DHCPOFFER(eth0) 192.168.0.167 00:15:5d:00:9d:0b
561:Jan 17 09:49:18 dnsmasq-dhcp[6208]: DHCPDISCOVER(eth0) 00:15:5d:00:9d:07
562:Jan 17 09:49:18 dnsmasq-dhcp[6208]: DHCPOFFER(eth0) 192.168.0.163 00:15:5d:00:9d:07
563:Jan 17 09:49:24 dnsmasq-dhcp[6208]: DHCPDISCOVER(eth0) 00:15:5d:00:9d:07
564:Jan 17 09:49:24 dnsmasq-dhcp[6208]: DHCPOFFER(eth0) 192.168.0.163 00:15:5d:00:9d:07
608:Jan 17 09:49:40 dnsmasq-dhcp[6208]: DHCPDISCOVER(eth0) 00:15:5d:00:9d:07
609:Jan 17 09:49:40 dnsmasq-dhcp[6208]: DHCPOFFER(eth0) 192.168.0.163 00:15:5d:00:9d:07
669:Jan 17 09:50:15 dnsmasq-dhcp[6208]: DHCPDISCOVER(eth0) 00:15:5d:00:9d:07
670:Jan 17 09:50:15 dnsmasq-dhcp[6208]: DHCPOFFER(eth0) 192.168.0.163 00:15:5d:00:9d:07
673:Jan 17 09:50:21 dnsmasq-dhcp[6208]: DHCPDISCOVER(eth0) 00:15:5d:00:9d:0b
674:Jan 17 09:50:21 dnsmasq-dhcp[6208]: DHCPOFFER(eth0) 192.168.0.167 00:15:5d:00:9d:0b

YYYYYY and XXXXXX are windows clients (one physical, one VM) on both brand new IPs that haven't been given before on these clients

The others that are stuck in this DISCOVER/OFFER dance are both linux VMs, given enough time all the other clients will expire and start this dance also.

I have run the tcpdump command you suggested on one of the VMs; as below:

mike@piholevm2:~$ sudo tcpdump -nvvvi eth0 '(udp port 67 or udp port 68) and ether host 00:15:5d:00:9d:0b'              

tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:01:04.239059 IP (tos 0xc0, ttl 64, id 47865, offset 0, flags [none], proto UDP (17), length 328)
    192.168.0.18.67 192.168.0.167.68: [bad udp cksum 0x834f -0x1152!] BOOTP/DHCP, Reply, length 300, xid 0x4208bc88, secs 770, Flags [none] (0x0000)
          Your-IP 192.168.0.167
          Server-IP 192.168.0.18
          Client-Ethernet-Address 00:15:5d:00:9d:0b
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message (53), length 1: Offer
            Server-ID (54), length 4: 192.168.0.18
            Lease-Time (51), length 4: 86400
            RN (58), length 4: 43200
            RB (59), length 4: 75600
            Subnet-Mask (1), length 4: 255.255.255.0
            BR (28), length 4: 192.168.0.255
            Domain-Name-Server (6), length 4: 192.168.0.18
            Domain-Name (15), length 3: "lan"
            Default-Gateway (3), length 4: 192.168.0.1
            END (255), length 0
            PAD (0), length 0, occurs 3

10:02:05.414284 IP (tos 0xc0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 305)
    0.0.0.0.68 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 00:15:5d:00:9d:0b, length 277, xid 0x4208bc88, secs 834, Flags [none] (0x0000)
          Client-Ethernet-Address 00:15:5d:00:9d:0b
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message (53), length 1: Discover
            Client-ID (61), length 7: ether 00:15:5d:00:9d:0b
            Parameter-Request (55), length 11:
              Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Hostname (12)
              Domain-Name (15), MTU (26), Static-Route (33), NTP (42)
              Unknown (119), Unknown (120), Classless-Static-Route (121)
            MSZ (57), length 2: 576
            Hostname (12), length 5: "hub02"
            END (255), length 0

I assume the bad checksum on the offer is an issue here?

Using the same tcpdump command, I released/renew'd a windows machine; as below:

mike@piholevm2:~$ sudo tcpdump -nvvvi eth0 '(udp port 67 or udp port 68) and ether host 00:15:5D:00:9D:01'
tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
10:05:20.738681 IP (tos 0x0, ttl 128, id 64176, offset 0, flags [none], proto UDP (17), length 328)
    192.168.0.157.68 192.168.0.18.67: [udp sum ok] BOOTP/DHCP, Request from 00:15:5d:00:9d:01, length 300, xid 0x122778d1, Flags [none] (0x0000)
          Client-Ethernet-Address 00:15:5d:00:9d:01
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message (53), length 1: Release
            Client-ID (61), length 7: ether 00:15:5d:00:9d:01
            END (255), length 0
            PAD (0), length 0, occurs 47
10:05:25.768868 IP (tos 0x0, ttl 128, id 34738, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 00:15:5d:00:9d:01, length 300, xid 0x2018ce0, Flags [none] (0x0000)
          Client-Ethernet-Address 00:15:5d:00:9d:01
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message (53), length 1: Discover
            Client-ID (61), length 7: ether 00:15:5d:00:9d:01
            Requested-IP (50), length 4: 192.168.0.157
            Hostname (12), length 7: "win11vm"
            Vendor-Class (60), length 8: "MSFT 5.0"
            Parameter-Request (55), length 14:
              Subnet-Mask (1), Default-Gateway (3), Domain-Name-Server (6), Domain-Name (15)
              Router-Discovery (31), Static-Route (33), Vendor-Option (43), Netbios-Name-Server (44)
              Netbios-Node (46), Netbios-Scope (47), Unknown (119), Classless-Static-Route (121)
              Classless-Static-Route-Microsoft (249), Unknown (252)
            END (255), length 0
            PAD (0), length 0, occurs 6
10:05:25.768974 IP (tos 0xc0, ttl 64, id 53819, offset 0, flags [none], proto UDP (17), length 328)
    192.168.0.18.67 192.168.0.157.68: [bad udp cksum 0x8345 -0x8421!] BOOTP/DHCP, Reply, length 300, xid 0x2018ce0, Flags [none] (0x0000)
          Your-IP 192.168.0.157
          Server-IP 192.168.0.18
          Client-Ethernet-Address 00:15:5d:00:9d:01
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message (53), length 1: Offer
            Server-ID (54), length 4: 192.168.0.18
            Lease-Time (51), length 4: 86400
            RN (58), length 4: 43200
            RB (59), length 4: 75600
            Subnet-Mask (1), length 4: 255.255.255.0
            BR (28), length 4: 192.168.0.255
            Domain-Name-Server (6), length 4: 192.168.0.18
            Domain-Name (15), length 3: "lan"
            Default-Gateway (3), length 4: 192.168.0.1
            END (255), length 0
            PAD (0), length 0, occurs 3

Which worked ok.

Any further ideas?
In the meantime i'm going to use the router and look into alternatives for the pihole, see if I have any further success with them.

Thanks for all that have looked/replied.
Mike.

1 Like

If you'd monitor comms when your router does DHCP, you'd likely see the same.

UDP checksum calculation is normally done by NIC hardware, so you are unlikely to see a correct checksum until the packet would pass through a h/w interface, which is not happening in a VM.

The first dump is a bit confusing bc it starts with an Offer from the server (192.168.0.18) followed by a Discover from the client (0.0.0.0).
While usually its the other way around:

The second dump just confirms what was pointed out already:

You could install Wireshark on that Windows host to see if its sending a DHCP request.
Could also sniff on the hypervisor host as well if possible.

For comparison, below a successful release/renew on a tinker client VM of mine and a Raspberry Pi hosting the Pi-hole DHCP service.

Client VM:

$ sudo dhclient -v -r eth0
[..]
Listening on LPF/eth0/00:16:3e:xx:xx:xx
Sending on   LPF/eth0/00:16:3e:xx:xx:xx
Sending on   Socket/fallback
DHCPRELEASE of 10.0.0.145 on eth0 to 10.0.0.2 port 67
$ sudo dhclient -v eth0
[..]
Listening on LPF/eth0/00:16:3e:xx:xx:xx
Sending on   LPF/eth0/00:16:3e:xx:xx:xx
Sending on   Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
DHCPOFFER of 10.0.0.145 from 10.0.0.2
DHCPREQUEST for 10.0.0.145 on eth0 to 255.255.255.255 port 67
DHCPACK of 10.0.0.145 from 10.0.0.2
bound to 10.0.0.145 -- renewal in 42915 seconds.

Raspi:

$ sudo tail -F /var/log/pihole/pihole.log | grep dhcp
Jan 17 18:40:57 dnsmasq-dhcp[8137]: DHCPRELEASE(eth0) 10.0.0.145 00:16:3e:xx:xx:xx
Jan 17 18:41:40 dnsmasq-dhcp[8137]: DHCPDISCOVER(eth0) 10.0.0.145 00:16:3e:xx:xx:xx
Jan 17 18:41:40 dnsmasq-dhcp[8137]: DHCPOFFER(eth0) 10.0.0.145 00:16:3e:xx:xx:xx
Jan 17 18:41:40 dnsmasq-dhcp[8137]: DHCPREQUEST(eth0) 10.0.0.145 00:16:3e:xx:xx:xx
Jan 17 18:41:40 dnsmasq-dhcp[8137]: DHCPACK(eth0) 10.0.0.145 00:16:3e:xx:xx:xx hak01
$ sudo tcpdump -nvvvi eth0 '(udp port 67 or udp port 68) and ether host 00:16:3e:xx:xx:xx'
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
18:40:57.312665 IP (tos 0x0, ttl 64, id 5792, offset 0, flags [DF], proto UDP (17), length 328)
    10.0.0.145.68 > 10.0.0.2.67: [udp sum ok] BOOTP/DHCP, Request from 00:16:3e:xx:xx:xx, length 300, xid 0x3f0aaf68, Flags [none] (0x0000)
          Client-IP 10.0.0.145
          Client-Ethernet-Address 00:16:3e:xx:xx:xx
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Release
            Server-ID Option 54, length 4: 10.0.0.2
            Hostname Option 12, length 5: "hak01"
            END Option 255, length 0
            PAD Option 0, length 0, occurs 43
18:41:37.578003 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 00:16:3e:xx:xx:xx, length 300, xid 0xa82c970e, Flags [none] (0x0000)
          Client-Ethernet-Address 00:16:3e:xx:xx:xx
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Discover
            Requested-IP Option 50, length 4: 10.0.0.145
            Hostname Option 12, length 5: "hak01"
            Parameter-Request Option 55, length 13:
              Subnet-Mask, BR, Time-Zone, Default-Gateway
              Domain-Name, Domain-Name-Server, Option 119, Hostname
              Netbios-Name-Server, Netbios-Scope, MTU, Classless-Static-Route
              NTP
            END Option 255, length 0
            PAD Option 0, length 0, occurs 28
18:41:40.867397 IP (tos 0xc0, ttl 64, id 57812, offset 0, flags [none], proto UDP (17), length 346)
    10.0.0.2.67 > 10.0.0.145.68: [bad udp cksum 0x15ea -> 0x4e5d!] BOOTP/DHCP, Reply, length 318, xid 0xa82c970e, Flags [none] (0x0000)
          Your-IP 10.0.0.145
          Server-IP 10.0.0.2
          Client-Ethernet-Address 00:16:3e:xx:xx:xx
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Offer
            Server-ID Option 54, length 4: 10.0.0.2
            Lease-Time Option 51, length 4: 86400
            RN Option 58, length 4: 43200
            RB Option 59, length 4: 75600
            Subnet-Mask Option 1, length 4: 255.255.255.0
            BR Option 28, length 4: 10.0.0.255
            Domain-Name Option 15, length 14: "home.dehakkelaar.nl"
            NTP Option 42, length 4: 10.0.0.3
            Domain-Name-Server Option 6, length 8: 10.0.0.2,10.0.0.4
            Default-Gateway Option 3, length 4: 10.0.0.1
            END Option 255, length 0
18:41:40.869831 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)
    0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 00:16:3e:xx:xx:xx, length 300, xid 0xa82c970e, Flags [none] (0x0000)
          Client-Ethernet-Address 00:16:3e:xx:xx:xx
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Request
            Server-ID Option 54, length 4: 10.0.0.2
            Requested-IP Option 50, length 4: 10.0.0.145
            Hostname Option 12, length 5: "hak01"
            Parameter-Request Option 55, length 13:
              Subnet-Mask, BR, Time-Zone, Default-Gateway
              Domain-Name, Domain-Name-Server, Option 119, Hostname
              Netbios-Name-Server, Netbios-Scope, MTU, Classless-Static-Route
              NTP
            END Option 255, length 0
            PAD Option 0, length 0, occurs 22
18:41:41.392302 IP (tos 0xc0, ttl 64, id 57846, offset 0, flags [none], proto UDP (17), length 353)
    10.0.0.2.67 > 10.0.0.145.68: [bad udp cksum 0x15f1 -> 0x757d!] BOOTP/DHCP, Reply, length 325, xid 0xa82c970e, Flags [none] (0x0000)
          Your-IP 10.0.0.145
          Server-IP 10.0.0.2
          Client-Ethernet-Address 00:16:3e:xx:xx:xx
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: ACK
            Server-ID Option 54, length 4: 10.0.0.2
            Lease-Time Option 51, length 4: 86400
            RN Option 58, length 4: 43200
            RB Option 59, length 4: 75600
            Subnet-Mask Option 1, length 4: 255.255.255.0
            BR Option 28, length 4: 10.0.0.255
            Domain-Name Option 15, length 14: "home.dehakkelaar.nl"
            Hostname Option 12, length 5: "hak01"
            NTP Option 42, length 4: 10.0.0.3
            Domain-Name-Server Option 6, length 8: 10.0.0.2,10.0.0.4
            Default-Gateway Option 3, length 4: 10.0.0.1
            END Option 255, length 0

5 packets captured
5 packets received by filter
0 packets dropped by kernel

Hey Guys,

After a lot of testing and a call with Microsoft, I have now it working again.

Bottom line, Windows 11 24H2 - not sure why yet, I have a call with MS tomorrow to discuss, but I am back online again.

DHCP and PXE are all working perfectly, without any change on the servers or clients, something in 24H2 was blocking the ACK requests, only on certain clients, strange one.

I rolled back my host to 23H2 and we're all golden again

Thanks to all that replied, or read about my plight, and I hope this helps someone else out there.

Mike.

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.