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.
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.
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
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.
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;
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?