Results in the following when client does not specifically request option 67, bootfile-name is not populated and option 67 is not present:
Bootstrap Protocol (Offer)
Message type: Boot Reply (2)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0x7e1ed939
Seconds elapsed: 0
Bootp flags: 0x0000 (Unicast)
Client IP address: 0.0.0.0 (0.0.0.0)
Your (client) IP address: 10.0.100.2 (10.0.100.2)
Next server IP address: 10.0.100.1 (10.0.100.1)
Relay agent IP address: 10.0.100.1 (10.0.100.1)
Client MAC address: xxxx (xx:xx:xx:xx:xx:xx)
Client hardware address padding: 00000000000000000000
Server host name not given Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type (Offer)
Option: (54) DHCP Server Identifier
Option: (51) IP Address Lease Time
Option: (1) Subnet Mask
Option: (3) Router
Option: (6) Domain Name Server
Option: (255) End
If the client specifically requests option 67, mikrotik will return the following, again bootfile-name is not populated but option 67 is present-
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type (Offer)
Option: (54) DHCP Server Identifier
Option: (51) IP Address Lease Time
Option: (1) Subnet Mask
Option: (3) Router
Option: (6) Domain Name Server Option: (67) Bootfile Name
Length: 12
Bootfile Name: filename.ext
Option: (255) End
Per testing with other DHCP servers (windows/cisco) when specifying option 67, the bootfile-name packet header is always populated and the Option: (67) packet header is not present. This stands true both when client requests and does not request option 67.
When I refer to the client requesting option 67, I am referring to “Option (55): Parameter Request List” sent in the DHCP discover.
Not sure if I have a miss-configuration or this is a potential bug, any thoughts or insight?
I’m on v6.28, and its working for some of my client device types as well. I’m running into issues where client devices don’t request option 67 but I need to send to them anyways. I mainly wanted to point out there is a difference between how mikrotik handles option 67 when it comes to the bootfile-name packet header vs other DHCP server vendors.
I have the same problem using the 6.31 firmware. When I specified the Boot File Name in the DHCP Network setting the DHCP Offer package goes with the “Boot file name: MyBootFile.bin”. But when I use a custom DHCP Option 67 to specify the boot file name in particular DHCP lease, I capture (with Wireshark) a DHCP Offer package with “Boot file name not given”.
The DHCP Offer has the option 67 specified with the file name, but as “dancms” said the problem is visible in the DHCP “header”.
Jarda, thank for your quick response. I have update to the last RouterOS 6.33 version and I test it again. I attach you the configuration and packet capture of a Working and a NotWorking DHCP Offer packet. If I remove the Boot File Name in the DHCP Network configuration, the clients are not able to connect or accept the DHCP Offer because the packet is not specifing the boot file name (check the CaptureNotWorking image). Have a look at the ConfigNotWorking image and you could check that I sent the Option 67 with the same TFTP file name. The option 67 “Serv5M” is working correctly in other devices, so this is not the problem.
If it helps, I have attached the log.
AGAIN, THANK YOU VERY MUCH!!!
If you are working with bootp clients, you need to use next-server and boot-file-name instead of dhcp options. Bootp is not compatible with dhcp options.
Thanks for your responses. Yes, I must use the ‘Boot File Name’ from the DHCP Network configuracion. I was searching a way to specify the ‘Boot File Name’ based on an individual Lease, as I do with a DHCP Option parameter. Some devices work with the DHCP Option 67, but other need the Boot File Name.
Thank you again. Regards.