I have one particular embedded device that can't get a DHCP lease from RouterOS devices. I've been trying with both hEX Refresh and today with a new RB5009UPr+S+. Today's work is running RouterOS 7.23.2.
Doing some packet sniffing, the device sends a Discover, gets an Offer, sends a Request, and then gets a NAK.
I enabled logging of the dhcp topic on the Mikrotik, and when it receives the request packet from the problem device, it notes lease offered, init-reboot, extending, lease is only offered. Vs when a normal PC connects, then it logs lease offered, addressed to me and it sends an ACK.
What might cause this difference in behavior? I'm guessing the embedded device's DHCP client is doing something wrong that other DHCP servers don't care about, but I don't know what that might be.
I enabled logging of the dhcp topic on the Mikrotik, and when it receives the request packet from the problem device, it notes lease offered, init-reboot, extending, lease is only offered. Vs when a normal PC connects, then it logs lease offered, addressed to me and it sends an ACK.
In general, comparing DHCP REQUEST messages from working and the problematic client in Wireshark probably shows what upsets the ROS DHCP server in a way it NAKs the request.
Start with XID (Transaction Id) and CHADDR (client mac address) fields
The challenge I faced there is that those differences are humongous. The embedded device sends an extremely minimal REQUEST packet, whereas the PC sends a very rich one, and I have no straight forward way to change which items are in which.
Your original message mentioned:
If sniffing with wireshark, does the SIADDR field of the problematic client's DHCP REQUEST message contain the correct IP? It should be the DHCP server's IP, same as sent to the client in the SIADDR field of the DHCP OFFER message.
This could be the reason for the missing addressed to me in the logs and the NAK response.
And this rings a bell. The embedded device indeed doesn't populate the DHCP server IP into that field.
I think I can take that to the device vendor and see if they'll fix their firmware, thanks!
I edited the REQUEST address part because I see clients successfully get leases without it on a RB5009. The plan was to strike it but somehow I deleted it.
However, there was an issue in the forum somewhere about ROS DHCP server getting confused by the order of requested options in REQUEST messages, mostly affecting IoT/ Embedded clients.
And if it takes to long to figure it out, open a ticket. MikroTik should know what causes the differences in your logs („only offered“, „addressed to me“).
Doing more digging, the SIADDR field wasn't exactly the issue, but it pointed in the right direction. The DHCP spec requires the client to include the address of the DHCP server it's responding to in option 54, and this client isn't doing that. According to the RFC, lack of that option makes the REQUEST packet match the INIT-REBOOT state described in the RFC and which matches the Mikrotik logs, so I'm pretty confident I have my smoking gun and filed a report with the embedded device vendor
https://datatracker.ietf.org/doc/html/rfc2131#section-4.3.2 indicates that it's required when a client is confirming an offer in the SELECTING state. If it doesn't include it, then it's the INIT-REBOOT state where the client is trying to confirm an old lease. But since the client (in my case) never completed the SELECTING/REQUESTING/BOUND state flow (i.e. never got a confirmed lease via DHCPACK), the DHCP server is well within its rights to NACK the attempt to reacquire a lease that was never issued.
