> | Hm.  I see that I misunderstood the purpose of the
> | EXITHOOKS/exit_with_hooks().
> |
> | So, dhclient, itself, would need to be modified?
>
> Unfortunately yes. But I am not feeling like touching the code right
> now since it appears it is not using signals at all at this point.

A tangential comment/buglet is found near the bottom, but I'd rather put
the meat of the message up front.  (^&


dhclient-script defines RESOLV and uses it in only 2 places.  That
suggests to me that it's for more than to save typing.  The best way to
keep in synch with that variable is to only touch $RESOLV from that
script.  So even if dhclient may need modification, dhclient-script should
probably do the actual work.

Tracking a bit through the code, when doing a release (dhclient -r),
dhclient-script gets invoked with reason=RELEASE.

 (a) This $reason isn't documented in the dhclient-script man-page.
     Is the man-page out of synch with some external source, or just
     neglected?

 (b) The code for handling this in dhclient-script (coalesced with
     FAIL and a few other reasons) looks like a good place to put the
     restore-saved-data snippet.

     Since that case deletes route information, either one may already
     lose the route to one's name-server, or the dhclient-script needs to
     be re-invoked to re-init its lease.  I.e., either the code's already
     broken, or this change wouldn't affect people running multiple
     dhclients.

     Even more briskly: I think only dhclient-script needs changes.

So...if I were to make the changes that I outlined previously, but instead
used the FAIL/RELEASE/etc. case to restore saved data, does this sound
workable?  (dhclient.c is ~45 pages of text, and I consider a ~400-line
main() to be inherently yucky.  So, my grasp of dhclient is certainly less
than masterful.  I also don't use DHCP much, so I haven't actually tested
this, yet.  But...I think that this would all work.)

(Minor refinement: For uniformity, a ``# DHCP-generated'' comment line
should be used in resolv.conf, either in place of or in addition to the
``# dhclient-script generated'' comment that I originally suggested.
That way, automated dection doesn't have to care which program created the
file, only that it's from DHCP, hence of only ephemeral value and also
easily replaced.)


 -----


Hm.  Lines 226/227 in dhclient.c appear to be in conflict in the 1.5.2
release.  The format string is describing the ``max'' length for an
interface name; the actual number output is the length of the supplied
string, {(long)strlen (argv [i])}.  Probably the value supplied should be
{sizeof tmp -> name}.  Is this fixed in -current?  The context, if you
care, is:

    if (strlen (argv [i]) > sizeof tmp -> name)
            log_fatal ("%s: interface name too long (max %ld)",
                       argv [i], (long)strlen (argv [i]));

(Two 8-space <TAB>'s removed to make it fit a little more nicely in
email...(^&)

(I can submit a PR this if someone really wants---but it looks like a
simple typo that might as well be fixed w/o a PR.)


  ``I probably don't know what I'm talking about.'' --rauch@math.rice.edu