Description of problem: According to the dhclient-script and dhclient man pages, dhclient-up-hooks and dhclient-${interface}-up-hooks are called "immediately after dhclient brings an interface UP with a new IP address, subnet mask, and routes, in the REBOOT/BOUND states". That is not what actually happens in the script itself. The above hooks are called just after the new interface IP and broadcast addresses have been established, but *before* any routes, gateways and interface aliases and other options (like time zone) have been set (please look at dhclient-script:dhconfig() on line 334+), which is not how it is described in the above man pages. Version-Release number of selected component (if applicable): dhclient 4.2, FC17 How reproducible: Always Steps to Reproduce: 1. Self-evident from looking at the dhclient-script source supplied with the above package 2. 3. Actual results: See above. Expected results: The correct behaviour (and to adhere to the man pages) would be to push the following 5 lines of code: if [ -x ${ETCDIR}/dhclient-${interface}-up-hooks ]; then . ${ETCDIR}/dhclient-${interface}-up-hooks elif [ -x ${ETCDIR}/dhclient-up-hooks ]; then . ${ETCDIR}/dhclient-up-hooks fi further down *after* the static routes, gateways and interface alias have all been established, probably after the call to "make_resolv_config" on line 498. Additional info:
These up and down hooks is our addition to the upstream's enter and exit hooks. But yes, you are right, it doesn't work as described in dhclient-script(8).
Thanks! I don't really want to hijack this bug report, but I have another bug-bearer with regards to dhclient-script: Currently "/etc/resolv.conf" is hard-coded everywhere in this script, including in "network-functions" and "functions" (as part of the ifup/ifdown network scripts supplied by Fedora). This is not always practical, particularly if I wish to use the "standard" /etc/resolv.conf for my internal network configuration and use an internal dns/dnsmasq service running, servicing all internal networks - and I have 7 of them here - and use dhcp for my external interface and, by extension, the dhclient-script, which defines a separate resolv.conf file (which I call /etc/resolv.conf.external) in which the external dns servers are defined. As things stand, I had to copy, quite literally, the change_resolv_conf() function from network-functions into dhclient-script in order to use this different name. I also had to change all references to in in the entire script - very ugly and quite unpleasant job, prone to errors! The script should be made more flexible as to what resolv.conf file should be relied upon, possibly by defining the name of this file, as well as using its own change_resolv_conf() function (this is simply because the same function in network-functions has /etc/resolv.conf hard-coded there as well, which is another very bad practice). Just a suggestion - please let me know if you wish me to open a separate bug for this and I will. Many thanks.
Well, I understand it's tedious to change these things yourself, but I'm not fond of the idea of having our own change_resolv_conf(). For now I say no, sorry.
This bug has been fixed in dhcp-4.2.4-10.P1.fc17. You can find it here http://koji.fedoraproject.org/koji/buildinfo?buildID=349307 or wait for next dhcp update.
dhcp-4.2.4-15.P2.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/dhcp-4.2.4-15.P2.fc18
dhcp-4.2.4-13.P2.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/dhcp-4.2.4-13.P2.fc17
dhcp-4.2.4-15.P2.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
dhcp-4.2.4-13.P2.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.