For those who run CHR systems , I think I found a bug

Information can be found here:

viewtopic.php?f=21&t=130356&p=641065#p641065

Since we are asked to make a new topic and there already is one.

@TomjNorthIdaho:
Does your ether1 have a static IP bind to it, and the DHCP is still coming back? Then it does actually sound like a bug. RouterOS should never change a configuration on its own..
Cause on my test CHR's (RC20>) we CAN NOT replicate your problem _after_ a restart. We only have a DHCP-Client on ether1 when first booted up. When we add a address, remove the dhcp-client and reboot it has the same configuration.

@MTStaff:
With first boot its fine that there is a DHCP-client for those who don't have access to console but this should be noted better somewhere.

BUT :
When you deploy with the use of a OVA and have a little control how to push the configuration (you can enter IP-addresses).
Why it still has a DHCP-client even when you don't configure it?

Does your ether1 have a static IP bind to it, and the DHCP is still coming back?

In one of my tests, I had both a static and a dynamic address on ether1.

Then it does actually sound like a bug. RouterOS should never change a configuration on its own..

It does change by itself. If you are very quick, you can login right after the CHR boots and do an "export". Then about 5 seconds later do another "export" and you will see it has automatically created a dhcp-client.
Anyway, it has been acknowledged by Mikrotik support as a bug, so there is probably no value in discussing/testing further until they've at least attempted to fix it.

Since we are asked to make a new topic and there already is one.

@TomjNorthIdaho:
Does your ether1 have a static IP bind to it, and the DHCP is still coming back? Then it does actually sound like a bug. RouterOS should never change a configuration on its own..
Cause on my test CHR's (RC20>) we CAN NOT replicate your problem _after_ a restart. We only have a DHCP-Client on ether1 when first booted up. When we add a address, remove the dhcp-client and reboot it has the same configuration.

@MTStaff:
With first boot its fine that there is a DHCP-client for those who don't have access to console but this should be noted better somewhere.

BUT :
When you deploy with the use of a OVA and have a little control how to push the configuration (you can enter IP-addresses).
Why it still has a DHCP-client even when you don't configure it?

re: Does your ether1 have a static IP bind to it, and the DHCP is still coming back? Then it does actually sound like a bug. RouterOS should never change a configuration on its own..

YES (on every different CHR 6.4 and newer)
example configuration
ethe1 static IP addredd
ether2 static IP address
ether3 no IP address (this will be a dhcp-server)
ether4 no IP address (used for out-of-band Winbox MAC management)
There is no dhcp-client anywhere in the configuration - untill I reboot it.
After a reboot , there is a dhcp-client auto-injected into the configuration.
- - -
I am starting to think this might be a security hole and could lead to un-wanted IP addresses and un-wanted routes.
example:
A CHR has a WAN with a static IP address and optionally a default route
The CHR is also doing BGP and/or OSPF
If the up-stream WAN of the CHR has two or more other routers - and one of the upstream routers is a dhcp-server. Below are some of the possible problems I can think of that deserve some thoughts because of the auto-injected dhcp-client:
- The CHR now has two IP addresses on the WAN (one static and one from the dhcp-client auto-injected configuration.
- The CHR might now have a default route injected from the dhcp-client
- If a default route was supposed to be learned from BGP and/or OSPF , a new default route might now be injected into the CHR because of the now has an auto-injected default-route, resulting in two different 0.0.0.0/0 default routes - and these default routes might point to different up-stream WAN connected routers.
- BGP and OSPF routes might now be contanimated with an additional route from the auto-injected dhcp-client configuration
- With the auto-injected dhcp-client setting, is it now possible to hijack or kill a CHR that has a WAN on your network. Example, Your ISP has a /24 WAN and 10 customers on that /24 from your ISP have CHRs with static IP addresses -and- suppose somebody anywhere puts a dhcp-server on that WAN - then - anybody who reboots their CHR now gets what ever IP address was assigned to them from the dhcp-server and also received a default route to what ever the dhcp-server pointed it to. When a CHR on the /24 WAN network reboots, that CHR can receive corrupt network killing IP address and routes - and possibly get a duplicate IP address already used by something else on the /24 network - now resulting in another network now having problems also.
North Idaho Tom Jones

I've seen this recently with a few of my fresh installs. Best workaround I've found is to leave a dhcp client on the interface but disable it. It won't regenerate and if you can live with it there but disabled it won't trouble you again.

I've seen this recently with a few of my fresh installs. Best workaround I've found is to leave a dhcp client on the interface but disable it. It won't regenerate and if you can live with it there but disabled it won't trouble you again.

Funny - I did disable it on my CHR systems. After a reboot, there would be a new enabled dhcp-client and the one had disabled.
Then when I disabled the 2nd dhcp-client (now I had two disabled dhcp-client settings, another reboot would auto add a 3rd enabled dhcp-client.

As a work around, I just disabled the dhcp package. Not a good work-around but a work-around until it gets fixed.

North Idaho Tom Jones

We are aware of this problem. Hopefully it will be fixed in v6.42

We are aware of this problem. Hopefully it will be fixed in v6.42

mrz ,
Thank you - Thank you - Thank you for this information/post.
I'm looking forward to v6.42

FYI - On one of my CHRs, I need ether1 to be a dhcp-server --- however - with the auto inject of dhcp-client on ether1 after a reboot , I end up with a static IP address on ether1 and a dhcp-client on ether1 --- which I suspect will end up with two different IP addresses on ether1 and possibly two different default-routes

North Idaho Tom Jones

Odd.

I actually emailed support about this and the response was that it is intentional to create dhcp-client on ether1. I was advised to disable it and ignore if not needed.

It was probably intentional to create this client on initial boot when the config is empty, much as a default configuration is created on initial boot of the small routers.
However, in the case of recent CHR releases it was creating this thing even on a running config. I have seen it happen as well.

However, on my CHR running 6.42rc30 I have not seen it anymore, it has static addresses on ether1 and ether2 and no more spontaneous dhcp clients so far.

On my rc30, it's still adding the dhcp-client every time, regardless of whether a static address is on ether1 or whether you've disabled the previously auto-created dhcp-client.
i.e. it's no different to how it was when I reported this bug to support a month ago.

Hello, I can confirm this bug, dhcp client comes back, screwing up my routes for starters.
If I disable it, another entry gets enabled after reboot.
If I delete it, another entry gets created after reboot.
Only does this if there is an actual dhcp server around the network I suspect.

This is CHR why is Mikrotik not fixing this serious issue?

And it gets worse, the initial topic viewtopic.php?f=21&t=130356&start=100 was closed due to 6.41.2 being released, but the bug was not fixed.
So somebody had to create another ticket.

It is not happening for everyone. There must be some other setting or feature that makes it happen.

Putting ether1 in a bridge stops it happening because you can't have a dhcp-client on a slave interface.

Congratulations, great workaround...
@mikrotik - have a definitive fix?

Putting ether1 in a bridge stops it happening because you can't have a dhcp-client on a slave interface.

I did not have this problem with 6.42rc30 but now I installed 6.42rc35 and the problem is back!

It's like Lassie on steroids. I have three CHRs to play with (bugfix/current/rc with latest versions), and it happens on all of them, even though there's static IPv4 address configured on at least on one of available interfaces.

I get the idea that it might be good if the router doesn't make it easy to end up without address and thus inaccessible in some scenarios. But it's not good to make it unavoidable. There must be a way to turn this behaviour off. Add something like this if you must, but make it possible:

DHCP client is required on CHR installations since most of cloud services provide only access through IP address and you do not have direct access to console.

In order to make it happen, CHR checks if there is an IP address on ether1 interface or on bridge if ether1 is in it. If there is no IP address or DHCP client, then one is created automatically.

If client is disabled, then still new one will be created in case it was disabled by accident.

If there is a static IP address on ether1 (or bridge) new DHCP client will not be added.

DHCP client is required on CHR installations since most of cloud services provide only access through IP address and you do not have direct access to console.

In order to make it happen, CHR checks if there is an IP address on ether1 interface or on bridge if ether1 is in it. If there is no IP address or DHCP client, then one is created automatically.

But why not apply this config once after initial boot, like the default config of the low-end routers, and then not touch it afterward when the user decides to remove this item?
When I remove all config on a low-end-router it becomes inaccessible just as well, and the config is not changed to avoid it.
The problem is not that this client is automatically added after initial boot, the problem is that it is re-applied after the user has removed it.

Remember the user may even be managing the router only via IPv6 and not at all desires to have an IPv4 address on it.
Also, the mechanism you depict apparently does not work correctly, as on my CHR with ether1 and ether2 both with static address it still adds the DHCP client on ether2.
(in this CHR the ether ports are swapped between VMware config and RouterOS names, no idea why, reported before)

Well, the approach with ether1 does sound reasonable, and I'd probably not complain if it worked as described. The trouble is, it doesn't work at all.

First problem, what is ether1? I have three CHRs in VMware Player. Interfaces listed in Player's UI match the order in .vmx file (ethernet0-ethernetX). But they appear in different order in CHRs:

CHR1 (6.40.6): ether2, ether3, ether4, ether1
CHR2 (6.41.2): ether2, ether3, ether4, ether1
CHR3 (6.42rc37): ether2, ether4, ether5, ether1, ether3

I have all interfaces renamed, but these are "default-name" parameters taken from "/interface ethernet export verbose" and paired using MAC addresses.

Second problem, the behaviour is not predictable. If dhcp client got added where default-name=ether1, then I'd say it's just a problem with interface order. But when I do few reboots, while removing existing dhcp client before doing so, I end up with new dhcp client not only on ether1, but also on ether2, empty bridge, disabled ovpn-out1, disabled cap1. No interface seems to be safe. Whether ether1 does have a static address or not, doesn't seem to matter.

To anybody who accepts an auto-added dhcp-client injected onto ether1 after reboot , I ask this question:

What do you think would happen if every program that can run in an x86 environment were to suddenly inject a dhcp-client into the 1st Ethernet after a update then after every reboot ?
The networking world would C--R-R---A-A-A----S-S-S-S--------H-H-H-H-H

I don't wanna die this way... Just fix the dam thing and remove the auto-inject of dhcp-client after a reboot. Orrrrrrr at the very least , allow the admin to somehow turn-it-off.

North Idaho Tom Jones

I don't see any vocal supporters of this feature here. I looks like I might win myself, if there was any contest. And I just wrote that I could live with it, if it worked correctly (i.e. only add dhcp client to first interface, if it doesn't have either static address or dhcp client already). That way it couldn't suddenly break. And it sounds like it could help some people, to not make their router inaccessible. But I'd still prefer to have an option to turn it off completely.

On the other hand, maybe it's not worth it at all (except as first time default config). You can enter wrong static address, wrong routes, disable whole interface, lock yourself out with firewall rules, ... So "fixing" just one way how you can make router inaccessible doesn't help that much.

If the whole purpose of the auto-injection of a dhcp-client on a CHR ether1 is for remote access to assist in CHR recovery, then at least do it correctly and with some options to do the following:
- A), 1-st check if there is already an IP address on ether1
- B), 2-nd check if dhcp-client is disabled
-- If either then do not auto-inject a dhcp-client into the configuration after a reboot

Now what might be a useful new features could be something like this:
- Instead of a DHCP package, break it up into a DHCP-Client package and a DHCP-Server package.
- How about a Cisco like true / independent VRF management interface with an isolated routing tables which runs on ether1 where the VRF-Management package can be disabled or removed.
- Or , how about making the auto inject of dhcp-client on ether1 a default enabled package. Then allow the ability to disable and/or remove this package.

North Idaho Tom Jones

I just can't wait for CHR v6.42 to be released (where the auto-inject of DHCP-Client is no longer on ether1 after a reboot) !!!

I have a CHR with a static IP address on ether1 - however the outside network ether1 is connected to also has a DHCP-Server !!!!
And this CHR is operating as a DHCP-server on my ether2 (so the dhcp package can simply not be disabled)
Grrrrrr ,

Hopefully the fix will be out soon and be in v6.42

North Idaho Tom Jones

I just can't wait for CHR v6.42 to be released (where the auto-inject of DHCP-Client is no longer on ether1 after a reboot) !!!

The latest 6.42rc39 still has this bug!!!
So first there has to be an rc that fixes the bug, and only then a release of 6.42 would help you.

WARNING
Warning to all CHR admins !!!
CHR ROS version 6.41.3 will change your configuration to include a DHCP-CLIENT on ether1.
There is nothing you can do to make it go away or remove it.
If you remove the DHCP-CLIENT from your configuration and reboot your CHR, a DHCP-CLIENT will again appear in the configuration on ether1.
If you disable the DHCP-CLIENT in your configuration and reboot your CHR, a second DHCP-CLIENT will again appear in the configuration on ether1 - now you have a disabled DHCP-CLIENT and an enabled DHCP-CLIENT on ether1.
If you disable the DHCP-CLIENT on ether1 and reboot and disable it and reboot it and disable it 10 times, you will have a bunch of disabled DHCP-CLIENTs on ether1 and a new enabled DHCP-CLIENT on ether1.

The only partial work-around is to disable the CHR 64-bit DHCP package. Note - If you disable the DHCP package, then your CHR can no longer be a DHCP-CLIENT or a DHCP-SERVER in your network.

Interestengely, the x86 32-Bit ROS does NOT have this same problem.

North Idaho Tom Jones

This is just yet another repetition of what we know already.
See post #14 for a work-around, while the madness of this thing continues.

This is just yet another repetition of what we know already.
See post #14 for a work-around, while the madness of this thing continues.

YUP - that works

I thought I had tried the ether1 to a bridge and not have it worked (must of been something else)
Anyways - thanks

North Idaho Tom Jones

It looks like latest rc changed something, at least my testing CHR doesn't add dhcp client to random interfaces anymore. I guess it might have to do something with:

What's new in 6.42rc52 (2018-Mar-26 12:41):

...
*) chr - fixed interface matching by name on VMware installations;

It looks like latest rc changed something, at least my testing CHR doesn't add dhcp client to random interfaces anymore.

Agreed. I put a static IP address on ether1 and deleted the dhcp-client, then rebooted, and no dhcp-client came back afterwards.

On disabling DHCP-CLIENT on aws CHR instance, i lost access to the CHR, even with private ip's from another machine on the same subnet.

disable internet detect fix the problem

I have the same problema.
In eth1 is conected a ONT pppoe working fine, but suddenly stop working. In ip -> dhcp client i see the fuc___ config. I delete it or disable it, and all working again.
It's a bug?

disable internet detect fix the problem

Thanks that solved my problem!