DHCP allows the server to forcibly send options to clients, even when they aren’t requested.
This is supported in ~all other DHCP servers, including ISC (“dhcp-parameter-request-list”) and dnsmasq (“–dhcp-option-force”).
There are a lot of use cases, including:
Setting pxeboot and netboot parameters
Telling Android clients to use less bandwidth (“ANDROID_METERED” via option 43)
Setting specific routes, e.g. for client isolation, by sending Option 121
Setting interface MTUs (for jumbo frame networks, or networks with downstream encapsulation, etc.)
This feature has been requested a few times on the forum, and is the only reason we can’t currently use Mikrotik’s DHCPd – and instead have to run our own dnsmasq installation.
According to what OP wrote, it differs in that this options are only sent if client explicitly requests them. And it seems there are DHCP clients in the wild that do respect some options on receive even if they don’t requested them.
I do not think that forcing all options to all clients is a good idea, however conditional vendor specific options based on vendor class id (opt 60), would be nice feature to have.
It is very helpful for some iptv box in china will check the option 125 value but it do not send the option request, some dhcp server such as dnsmasq widely used in other system as merlin,openwrt,tomato also support "“force option”, we hope ros can support the feature so I could no longer need another ddwrt based router to provide dhcpd as I used now.
+1 That would be a great feature for us. We need to force send the DHCP Option 43 to our CPEs, because some CPEs are not requesting it explicitly. I think it should be an optional checkmark for every DHCP option. Here the code what we are doing on our isc-dhcp:
Isn’t this in general a case of “my client is broken so please fix your server”?
It would be better to send change requests to the client manufacturer to tell them to request the options they support in the reply.
(after all, that is the idea behind the protocol)
When you need it , it will be really useful.
And that’s the only reason why i don’t use ROS as the system of my main Router.
In China millions user need to force add option-125 to activate our IPTV devices, and UBNT OpenWRT dnsmasq both support force-dhcp-options to against our ISP.
Only ROS can’t do this.
Yes，I am from China.
Because of the china telecom 4K IPTV devices need force option-125.
I have google “ros force dhcp option” since 2016.
Now time is 2018 , it disappointed me again .
Ok but why don’t you request china telecom to put the option 125 request in the DHCP request packet?
That would be the normal way of handling a DHCP option.
When china telecom does not honor this request in 2 years time, you can write them that you are disappointed.
But writing here that you are disappointed that MikroTik is not supporting devices that break the protocol seems a little unfounded.
(even when other manufacturers do that)
Hello, I need this feature, too.
I have an Service Access Router from Nokia, this Router would discover the IP address from the dhcp server. But it need’s the option 58 and 59 in the offer.
I’ve wiresharked the requests and don’t see the options, so I added to the options in the list and make an optionset and add this to the the dhcp server configuration.
But the ROS didn’t add it to the offer.
I tested it with an other option like 121 “classless”, and this works. It will be offered in the response without the client didn’t requested it.
Are there any hope that these functions will be available in next ROS Versions or did I some mistakes?