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.

Would love to see it in ROS v6 or v7.

+10000

I need this feature too

+10000

I need this feature too

+100000

I need this feature too

+1 for 'Force sending of DHCP options to clients'

+1 for 'Force sending of DHCP options to clients'

Can't boot pxelinux without 209 and 210 options, but mikrotik don't force it.

+1
really need this feature.
other routers like merlin, openwrt, ddwrt etc all support this feature.
really hope mikrotik can support it too.
thanks!

+1

This feature REALLY DOES SOMETHING to my home network.
My IPTV box need to be sent the option 60 and option 125.


Big thanks!!!

+1

I need DHCP option 160 for Captive Portal ID (https://tools.ietf.org/html/rfc7710)

Unclear. How is this different from the already available option here?
this should be compatible with IPoE and such

Unclear. How is this different from the already available option here?

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)

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.

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 .

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.

agree
I use Raspberry Pi with dnsmasq to be the dhcp server.

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)

+1

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?

Many thanks!

+1;

+1
I run around 100 small Mikrotiks for just simple tasks and now I bought a bigger one where I have 100 devices connected wich need the DHCP-Options to be forced without request.
Can any developer please add this feature to DHCP-Server

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)

china telecom doesn`t want you to use your own router ,so they make the dhcp option problem .
you can use the router , which they provide and under their supervision, without the dhcp option problem.
You have limited access to their router . you only can change the Lan ip ,dhcp pool ,ssid and pw.
static pat ? no
vpn ? no
firewall ? no
qos ? no

It should be super to select wich option to FORCE in the DHCP server settings

+1

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)

china telecom doesn`t want you to use your own router ,so they make the dhcp option problem .
you can use the router , which they provide and under their supervision, without the dhcp option problem.
You have limited access to their router . you only can change the Lan ip ,dhcp pool ,ssid and pw.
static pat ? no
vpn ? no
firewall ? no
qos ? no

Not only in China, see the same behavior with Telus 4K set-top box, not sure if that apply to all set-top box or just new install in my area

+10000

Please give this option!!!

Alternatively, if Mikrotik can support dhcp option 55 which allows defining which options to send, we can work around this issue. But it is not possible either.

When there is some option that fixes your problem, you can add it. That has been possible for a long time.

It`s end of 2019 , still don`t have the force dhcp option . I don`t think it`s a difficult feature .Please add it .

Is this being planned in a feature?
Really start to need this. Hate it to have to run a separate DHCP server in the network only for forcing some options.

Now it's 2020. Does Mikrotik have any plan on this feature? without this, I have to run a separate DHCP server in my LAN to provide required feature. Really pls Mikrotik to consider this requirement.

I need to force option 252 out so that I can let the devices know to use a new or different web proxy. So anything MikroTik can do, sooner the better.

+1 - seriously needed.

Since 2 years i wait for this additional feature, I'm already waiting for forcing dhcp options.

Thank you to the development of the RouterOS-Team and Happy Eastern 2020 and keep health without Corona!

+1 feature request

+1 we need this feature as well!

The new RFC7710-Draft states this as well:

DHCP servers MAY send the Captive Portal option without any explicit request.

https://tools.ietf.org/html/draft-ietf- ... 7710bis-11

Official answer from Mikrotik-support:

Hello,
Thank you for your request. We will consider implementing such an option.
Best regards,

Fingers crossed!

I have found that quite a lot of Android clients won't request DHCP option 121, classless static routes and I am not able to push routes to them unless explicitly forced by the DHCP server. I am quite surprised this has not been implemented in RouterOS after all this years...

I am quite surprised this has not been implemented in RouterOS after all this years...

In fact you should be more surprised that the Android developers, after all those years, could not be bothered to put an option request in their DHCP request for all options that they can process. After all, that is the standard for the DHCP protocol.

I partecipated to this discussion and agree with both points of view.
a) the client device SHOULD follow the dhcp protocol correctly and ask the right option.
b) the DHCP server could force some options to fix broken clients.

I understend the view "the client is broken, please fix the server".
The reality is that a lot of manifacturers simply IGNORE the correct DHCP protocol's behaviour. For example AVM on fritzbox receives opt43 but NOT ASKS FOR IT. So we cannot provision AVM devices on a network where the mikrotik is the dhcp server, and it is really a bad situation for us. We use a separate DHCP server, or in some situations, the relay.

It would be PERFECT for a RouterOS to have the FORCE OPTION flag... and maybe a vendor specific options as a real DHCP server. It will be a wonderful move to have more and more place in the networks.

This simple feature has been requested since 2013 in this thread viewtopic.php?t=75443,
And it's almost 2021, 8 years passed, really disappointed!

I wrote to support today.
they answered me:


----------
Hello,
Thank you for your request. We will implement such feature support in one of the next RouterOS version 7 beta releases:
https://mikrotik.com/download.
Best regards,
Artūrs C.

Hi Maggiore81,

any update ?
in version 6.49 we now have a api.json file, and some more info on https://help.mikrotik.com/docs/pages/vi ... d=56459266

still the problem with RFC7710, no DHCP force sent by mikrotik and no DHCP-redirect on DHCP-force detect of Captive Portal

I'l like to have this : https://globalreachtech.com/ietf-cappor ... reachtech/

easy to do in linux (named.conf ...)

no news.
that option is not implemented and they dont want to implement in ROS 6.x

It is still my opinion that it is pretty lame that devices support some DHCP option but they do not put the option number in the request.
That plainly is a bug in the device, the maintainer should fix that rather than rely on the DHCP server breaking the protocol and sending option values that weren't requested.
Now if that is part of some supplier lock-in scheme (like a settopbox requiring some option but not requesting it, so it will only work with the supplier router that sends it), I can sort of understand it.
But when it is a "new option to make behavior of captive portals more predictable" it is just plain dumb to not request the option when you do support its handling.

Yes pe1chl 1000+

incredible how mikrotik decide to approach this feature req.

others like packetfence (linux ..) solved the problem --> https://github.com/inverse-inc/packetfence/issues/5638

why Mikrotik still wait ??

Please give us a valid answer, thanks

Yes pe1chl 1000+

incredible how mikrotik decide to approach this feature req.

It looks like you do not understand the matter!
MikroTik already supports the sending of arbitrary DHCP options to clients. You can define them using the Options, Option Sets, and Vendor Classes tabs of
the DHCP server configuration.

This should be sufficient to send that option 114 to your clients, as is described in that github article. As long as the client requests this option.

This topic is about something else: BROKEN clients that expect to receive some DHCP option without having requested them.
That is in fact a bug in the client, not in the server (in this case a MikroTik router)!

You should compare a DHCP server to a shop, e.g. an online shop. The client orders some items from the shop, and receives a package back containing some of those items. E.g. it has ordered item number 1,2,3,10 and it receives 1,2 and 10. It does not receive 3 because the store does not have it.
That is how it is supposed to work.

Now the people above are screaming: hey MikroTik, you should allow us to configure the store so that it always sends item 10, even when the client only ordered item 1,2 and 3. All clients should receive item 10 even when they did not order it!
However, the store was never able to do that in the standard, it is something that people have invented as a workaround for clients that forget to order item 10 even though they need it.

This is the user forum, no one notices?
Everyone should ask directly at support@mikrotik.com instead of randomly writing their opinion here.

It looks like you do not understand the matter!
MikroTik already supports the sending of arbitrary DHCP options to clients. You can define them using the Options, Option Sets, and Vendor Classes tabs of
the DHCP server configuration.

This should be sufficient to send that option 114 to your clients, as is described in that github article. As long as the client requests this option.

This topic is about something else: BROKEN clients that expect to receive some DHCP option without having requested them.
That is in fact a bug in the client, not in the server (in this case a MikroTik router)!

You should compare a DHCP server to a shop, e.g. an online shop. The client orders some items from the shop, and receives a package back containing some of those items. E.g. it has ordered item number 1,2,3,10 and it receives 1,2 and 10. It does not receive 3 because the store does not have it.
That is how it is supposed to work.

Now the people above are screaming: hey MikroTik, you should allow us to configure the store so that it always sends item 10, even when the client only ordered item 1,2 and 3. All clients should receive item 10 even when they did not order it!
However, the store was never able to do that in the standard, it is something that people have invented as a workaround for clients that forget to order item 10 even though they need it.

Fair Enough, but could Mikrotik add a switch to enable/disable force response DHCP option, that will be greate helpful to some enviroments.

You should compare a DHCP server to a shop, e.g. an online shop. The client orders some items from the shop, and receives a package back containing some of those items. E.g. it has ordered item number 1,2,3,10 and it receives 1,2 and 10. It does not receive 3 because the store does not have it.
That is how it is supposed to work.

Now the people above are screaming: hey MikroTik, you should allow us to configure the store so that it always sends item 10, even when the client only ordered item 1,2 and 3. All clients should receive item 10 even when they did not order it!
However, the store was never able to do that in the standard, it is something that people have invented as a workaround for clients that forget to order item 10 even though they need it.

Here is another analogue: jails should not exist, because the law does not allow you to do bad things. But in reality, people don't always follow the law, and nobody questions the usefulness of jails! Yes, some DHCP clients are broken. But it does not make this feature any less important. We are living in an imperfect world, and creating a feature that makes life easier is benefical for the users. (And not just for the users - I bet there are some users who replaced their MT router just because they did not want to operate an extra rasperry pi beside their routers...)

Summary: We need it because of lazy coders!!

This sounds like "I would rather not use Mikrotik products because there is no way to workaround DHCP client bugs in some 3rd party products, but keep using those buggy 3rd party products..."

@anav: Centered the point...

@andriys: Fantastic definition... Bravo!

Those who make these requests (solve the bugs of other manufacturers) can think nothing but themselves, because it suits him at that moment...
And if this option, once added, bothers other devices that instead have the software written wrong and do not go if they receive a option not required?
Or if MikroTik in doing so introduces (involuntarily) other BUGs for those who don't care about that option instead?

Summary: We need it because of lazy coders!!

I agree with you, totally. But we users of Mikrotik's RouterOS is innocent. And The Mikrotik's programmers we can rely on. Help us, please!

This sounds like "I would rather not use Mikrotik products because there is no way to workaround DHCP client bugs in some 3rd party products, but keep using those buggy 3rd party products..."

Not True, Because of we have no choice, Those buggy devices are provided by ISP. Change ISP is not so easy, and other ISPs just do the same thing.

Not True, Because of we have no choice, Those buggy devices are provided by ISP. Change ISP is not so easy, and other ISPs just do the same thing.

Not true, if the ISP device is needed to access Internet, the RouterBOARD coming after that
and is not the DHCP Server for the "unremovable ISP device" with broken DHCP Client...

The devices with broken DHCP can be only devices "clients" like VoIP phones, etc.

This sounds like "I would rather not use Mikrotik products because there is no way to workaround DHCP client bugs in some 3rd party products, but keep using those buggy 3rd party products..."

You make it appear like it was a choice. Actually the feature is needed because of the cases when you don't have a choice.

Those who make these requests (solve the bugs of other manufacturers) can think nothing but themselves, because it suits him at that moment...
And if this option, once added, bothers other devices that instead have the software written wrong and do not go if they receive a option not required?
Or if MikroTik in doing so introduces (involuntarily) other BUGs for those who don't care about that option instead?

I don't personally need this. But I understand why would others need it. It is the opposite of "think nothing but myself". It looks like you want to make this question emotional.

Adding an optional feature can only do wrong if you decide to use it...

It looks like you want to make this question emotional.

Why instead of asking MikroTik to fix the other toys' problems, they don't ask the manufacturer directly to fix the crap they did in DHCP Client?

It looks like you want to make this question emotional.

Why instead of asking MikroTik to fix the other toys' problems, they don't ask the manufacturer directly to fix the crap they did in DHCP Client?

Censorship in China is not a toy.

It looks like you want to make this question emotional.

Why instead of asking MikroTik to fix the other toys' problems, they don't ask the manufacturer directly to fix the crap they did in DHCP Client?

I think it is not the "problem of the toy". It is the problem of the user, who has no other choice.

The point is, asking Mikrotik to implement something that would allow others to keep violating the standards means encouraging those others to keep doing what they are doing. One should rather ask people violating the standards to stop doing that. You always have choice. In case your ISP provides you with an equipment that does not work in your standards-compliant network, ask them to provide you with another set of gears. If they refuse, don't buy their products/services. You always get what you pay for. Your choice.

The point is, asking Mikrotik to implement something that would allow others to keep violating the standards means encouraging those others to keep doing what they are doing. One should rather ask people violating the standards to stop doing that. You always have choice. In case your ISP provides you with an equipment that does not work in your standards-compliant network, ask them to provide you with another set of gears. If they refuse, don't buy their products/services. You always get what you pay for. Your choice.

It's ridiculous don't buy ISP products/services. Can Mikrotik provides Internet service in China?

As it is written above, there are two use cases for this feature:
- to work around protections against using foreign equipment by some ISPs. this "force sending of options" is only a single solution for that, because there are others that have different tricks like requiring a specific DSCP value or 802.1p priority to be used with their DHCP requests. so the "please add this" cycle never ends.
- to work around silly bugs in other people's equipment. see for example the Android DHCP option 121, that has nothing to do with protection, that is just a stupid bug! they should add the value 121 to the DHCP request and everybody is happy. no need to change a million routers when you can fix it in your own code.

It is not clear what is the best position for MikroTik to be in: to offer workarounds for ISP protections may also negatively impact the business (outright ban on selling equipment in such countries) so not offering it may in the end be better.

...outright ban on selling equipment in such countries...

Bravo! Probably that's the point...

...outright ban on selling equipment in such countries...

Bravo! Probably that's the point...

This is official reply to customers who live in "such countries"? So why you company have agencies in China? Sell products in China and reject needs request from China. It's very convenient say no to customers. It's a concept of philosophy what a Company can make money from customers. Create value and help customers to resolve problems Or say no to customers, blame where they live, what ISP they choose.

You need to realize that countries have more power over what is going on than companies.
Compare it to the situation in the USA. MikroTik sell WiFi equipment all over the world, but for the USA they have to make a special model that does not allow operation beyond the limits defined by the FCC. Authorities like the FCC exist all over the world, they tell local citizens to not exceed the rules of wireless transmission, but (so far) only the FCC tells manufacturers "hey, when you want to import stuff into the USA, you have to make sure it cannot exceed our rules".
So, special models are made for the USA that abide by these rules and cannot be modified by the customer, not even by flashing different firmware or changing some jumper.

It is either "you make that special model" or "you won't sell your stuff in the USA" and apparently MikroTik chose to make the special models.
Similar things could happen in other countries when the router facilitates "illegal activity". And "work around protection systems setup by an ISP" could be considered just that.

@pe1chl
I totally agree with you, there is nothing to add...

That is an acceptable answer for me too. The original explanation ("don't use that ISP) defied reality, but this one agrees with it, as far as I can tell.

Hello all,
Good news regarding this feature!!

From the miktrotik wiki (https://help.mikrotik.com/docs/display/ROS/DHCP):

According to the DHCP protocol, a parameter is returned to the DHCP client only if it requests this parameter, specifying the respective code in the DHCP request Parameter-List (code 55) attribute. If the code is not included in the Parameter-List attribute, the DHCP server will not send it to the DHCP client, but since RouterOS v7.1rc5 it is possible to force the DHCP option from the server-side even if the DHCP-client does not request such parameter:
ip/dhcp-server/option/set force=yes

Tested and working provisioning VOIP through unrequested option 43
Finally!! This made my day. Enjoy!

Edit: Available only through terminal. Can't see it on winbox's IP->DHCP SERVER menu yet.

Edit: Available only through terminal. Can't see it on winbox's IP->DHCP SERVER menu yet.

This is a special option, some types of configuration are usually performed by scripts ..

This is a special option, some types of configuration are usually performed by scripts ..

Special and tricky among some of you! I get it, I couldn't decide either if Mikrotik should include such an option or not, given the different answers that some of you have posted.

In my personal case, being stuck with my ISP for a year (by contract), with no chance to get VOIP credentials to avoid the use of their bugged router (they don't provide such info, instating you to use their devices). So I sniffed the traffic and realize that my ISP's router was provisioning voip through option 43, I configured my mikrotik's DHCP server with that option. Didn't work, the client wasn't asking for that parameter. For three days I've been doing countless tests with no luck at all. I thought I was hopeless until I checked DHCP's Wiki for ros v7 and found the FORCE parameter. It worked flawlessly. So, yes,I think we should thank Mikrotik for that. I personally do.

Hello all,

I've waited and followed this thread since 6 years. Now I tried to change my system to give up the 3rd party dhcp server, but for me the new feature doesn't work.
I tried to force the option codes 58 and 59.
Maybe this special values, are ignore the force-flag or something else are not accepted by the nokia device.
The dhcp request will be logged and a offer entry will shown in the lease table.
After the timeout of some seconds, the entry is removed and nothing happens.

But still, special thanks to all supporters and the Mikrotik support team.

We used successfully, option 43 works perfectly