the net.eth0 script is written to assume that dhcpcd is the dhcp client on the system. It needs to be reworked so that is supports all of the dhcp clients in portage since there is now a virtual/dhcpc for the dhcp clients. Reproducible: Always Steps to Reproduce: 1. emerge -c dhcpcd 2. emerge another dhcp client. 3. restart the network. Actual Results: the network didn't restart because the dhcp client is missing. Expected Results: net.eth0 should detect or allow the system administrator to configure which dhcp client he will use through /etc/conf.d/net.
I can think of a couple of ways to do this. 1) put variables in /etc/conf.d/net that allow a system administrator to choose which dhcp client to use. or 2) set up the script to test for the existence of all possible dhcp clients in portage. I like the idea of letting the system administrator select the client. What does everyone think?
1. emerge -c dhcpcd 2. emerge another dhcp client. 3. restart the network. Presently step 3 would fail to stop the interface because it depends on calling dhcpcd to stop itself. This isn't truly required, but is correctly modular because it keeps dhcpcd-specific knowledge out of net.eth0. This will become increasingly important if we support multiple dhcp clients. Since the dhcp clients don't actually conflict with each other (they can be installed simultaneously) my gut feeling is that each ebuild should provide a script to start/stop the client which can be called in a common manner from net.eth0. save_options/get_options can be used in net.eth0 to "remember" which dhcp client was used to start the interface, so the appropriate script can be called to stop it as well. Quick question: What is the point? Do other dhcp clients have something in particular that dhcpcd lacks? (You can provide a quick answer and I'll be happy)
I'm marking this dependent on bug 19695 because any changes to the net.eth0 script should take place in the new version at http://dev.gentoo.org/~agriffis/net.eth0 instead of the current version
My thinking here is that I don't know of any dhcp packages that just contain a server, so if you are running a dhcp server on one interface and a dhcp client on another interface, the way things are currently set up you will end up with 2 dhcp clients on your system, and since dhcpcd is hard coded into net.eth0 you can't use the other client and get rid of dhcpcd if you don't want to use dhcpcd.
well, the thing I would think is that it comes down to choice :) for instance, I prefer udhcp (both as a client and a server, though these days I've shifted to dnsmasq as the server), and either way the default dhcpc is cruft for me. I know a few people in this situation actually :P
Thanks guys, that's the kind of material I needed :^) I'll work on a prototype of what I mentioned in comment #2 using dhcpcd, since I already have the example of how to control it in the existing net.eth0. When we've demonstrated the viability of the proto then we can apply the same logic to the other clients
may I ask what the current state of this bug is? dhcpcd happens to be the least configurable dhcp client available...
It's something I still plan to work on, but at the moment it has been back burner since there have been more pressing bugs
Maybe this suggestion have to be an own bug, but it would also be nice to have a dhcpc fallback similar to current fallback so that I have a dhcpc with -t 999999 working in background. I find it very usefull then starting w/o cable plugged in. Otherwise I have to plug in the cable and restart net.eth0.
I am using the "free.fr" provider with its excelent service in France. Yesterday, I rebooted by modem/router/pbx/whatever-it-really-is and I got stumped: dhcpcd is no longer able to get the IP address! After some googling I discovered that there is more than one dhcp client :+) I tried dhclient and it worked, but this is something to keep in mind (and to include in the installation documentation!): there are dhcp servers "in the wild" that won't work with dhcpcd and thus they will need a full dhclient from ISC... One more argument in favour of chosing dhcp for net.* scripts
*** This bug has been marked as a duplicate of 8917 ***
