It ended up being something with DHCP failover, not exactly sure what, but removing the failover relationship fixed the issue.
-- Matt Fogleman
Network Administrator
Unionville-Chadds Ford School District
(o) (610) 347-0970 x3332
This is a staff email account managed by Unionville-Chadds Ford School District. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender.Disclaimer
The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.
This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website.
Original Message:
Sent: 6/28/2024 3:35:00 AM
From: cordless
Subject: RE: Client DHCP Timeout when clock inaccurate
In the message is stated "Client Offer timeout" means the infrastructure has seen the offer by DHCP Server but the Client did not acknowledge.
I doubt that is has something to do with PST or EST. When I am in the US with my Device sets to CET it also works in another timezone.
Question now is why the Apple Device (all or just a couple?) don´t acknowledge the DHCP Offer.
I would use the PCAP option in Live Events and analyse the PCAP in Wireshark to see if the Client is reacting on the offer.
Server send NAK could be caused by a) Client is requesting an IP Address which is in use by another Client or b) because the IP Scope has no IP Addresses available.
Another Question, do you use RFC4833 in DHCP Server? This is an option where you can give Timezone information via DHCP to the Client. DHCP Option 100, 101
DHCP option 100: time zone POSIX string as in IEEE 1003.1
DHCP option 101: time zone as a string like in the TZ database (eg: Europe/Paris)
Maybe Apple has an issue with that.
https://support.apple.com/guide/iphone/change-the-date-and-time-iph65f82af3e/ios#:~:text=Go%20to%20Settings%20%3E%20General%20%3E%20Date,automatically%20determine%20the%20local%20time.
Original Message:
Sent: Jun 27, 2024 03:14 PM
From: mfogleman
Subject: Client DHCP Timeout when clock inaccurate
Yeah I don't think it's the DHCP server since the same exact device if plugged into ethernet will get an IP address fine from the same DHCP server. It also works on SSIDs on our controller based WiFi from the same DHCP server.
Original Message:
Sent: Jun 27, 2024 02:33 PM
From: FerC
Subject: Client DHCP Timeout when clock inaccurate
Hi Matt.
I´m not expert on DHCP server settings. Maybe the logs from the dhcp server tell us more information about:
- the request reaches the server.
- if the server responds to the client.
- Take a packet capture on the controller if the SSID is on tunnel mode or from Central.
Also, you can test other dhcp server (switch core) and check if the behavior persists.
Original Message:
Sent: Jun 27, 2024 01:11 PM
From: mfogleman
Subject: Client DHCP Timeout when clock inaccurate
This is on an Open network with no .1x or PSK. Devices that have their clock correct have no issue, neither do wired devices using the same DHCP server.
-- Matt Fogleman
Network Administrator
Unionville-Chadds Ford School District
(o) (610) 347-0970 x3332
This is a staff email account managed by Unionville-Chadds Ford School District. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender.Disclaimer
The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.
This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website.
Original Message:
Sent: 6/27/2024 9:59:00 AM
From: FerC
Subject: RE: Client DHCP Timeout when clock inaccurate
Also, Did apple device finished 802.1x authentication or use pre-share key?
did you try using a different SSID only with pre-share key in order to validate that DHCP it is OK?
When use other device (android, windows) works as expected?
Original Message:
Sent: Jun 26, 2024 03:23 PM
From: mfogleman
Subject: Client DHCP Timeout when clock inaccurate
The Apple devices we receive come in with their time set to PST and we are in EST. When connecting them to the device enrollment SSID we have, they will get "Client DHCP Timeout" errors.
Connecting these devices to the wired network that shares the same DHCP server is working as expected. We are also migrating to Central, and on our local controller hosted APs it is working as expected as well.
Is there something in Central that has a time difference tolerance to cause the DHCP request to timeout?