I’ve got a device (https://www.synaccess-net.com/np-02b) that “works elsewhere” but has issues getting DHCP lease from a Mikrotik (hEX PoE@RouterOS 6.47) and I don’t seem to be able to make it work. It runs in circles of discover-offer-request-nak at pretty intense rate. Attached is a packet capture from a direct connect between the device and a ethernet port on mikrotik (no devices in between, no bridge on mikrotik). Searching forums/wiki wasn’t fruitful unfortunately…
Maybe there is some logging or something that could give a hint on why the request is NAKed by RouterOS I missed? The usual logging or dhcp logging just goes along the lines of the packet capture, revealing no additional info…
I’m afraid that the DHCPREQUEST from that box breaks RFC2131:
DHCPREQUEST - Client message to servers either (a) requesting offered parameters from one server and implicitly declining offers from all others,
(b) confirming correctness of previously allocated address after, e.g., system reboot, or
(c) extending the lease on a particular network address.
…
The client receives one or more DHCPOFFER messages from one or more servers. … The client broadcasts a DHCPREQUEST message that MUST include the ‘server identifier’ option to indicate which server it has selected, …
The DHCP Server Identifier Option (54) is missing in the DHCPREQUEST messages in your capture.
Ah, thanks, I actually omitted reading the RFC because of the “works elsewhere” (which it actually does in quite a few implementations).
I see now how the RFC requires the server identifier in reply to offer after selecting state at the table at section 4.4.1 https://tools.ietf.org/html/rfc2131#section-4.4.1 and mentions that at a few other places too…