Date:        Mon, 19 May 2003 23:42:27 +0100
    From:        Lee W <lee@unassemble.co.uk>
    Message-ID:  <3EC95DD3.2020404@unassemble.co.uk>

  | It seems as the dhclient-script was at fault:-
  | 
  | #!/bin/sh
  | #
  | # $NetBSD: dhclient-script,v 1.4 2002/04/10 10:11:41 enami Exp $

Ah yes, that's a bug that was fixed almost a year ago, but hasn't been
pulled up to the 1.6 branch.   The current version (in -current) of
the dhclient-script has that fixed (that's 1.5, though that version
might not ever get to the 1.6.* NetBSD branch, something containing the
fix might, and should).

Could someone who knows how possibly send in a pullup request for this
for the 1.6 branch, so it is at least fixed before 1.6.2 ?

Whoever does that could look at bin/21109 and bin/21110, fix those,
and then get a pullup for at least 21109 done as well.

  | What I did was move the code for creating the resolv.conf file outside 
  | of the checks for length of $new_domain_name & $new_domain_name_servers. 
  |   Consequently this allowed the resolv.conf file to be created.
  | 
  | Can anyone tell if what I have done will cause me any future trouble? 
  | I would hate to think that I have compromised my shiny new install.

You won't have a problem as long as the DHCP server keeps on sending
the nameserver option.   But if it doesn't always, then you will cause
an empty resolv.conf file to get generated, which is worse than just
leaving whatever was there before.

The version of the script in -current just checks that new_domain_name_servers
isn't a null string, deleting the check for new_domain_name completely.
I'd suggest that you do the same.

You really want the "fi" moved back to where it was - the way that you
now have it, you can overwrite resolv.conf without saving the old one
(which also probably doesn't matter to you now, but might someday).
If deleting the test completely was the correct fix, you'd want to
delete it completely, not leave the test around the "save the old file"
part, but not around the "make a new file" piece.

In -current the function is ...

make_resolv_conf() {
        if [ ! -z "$new_domain_name_servers" ]; then
                if [ -f $RESOLV ]
                then
                        while read line; do
                                case $line in
                                "$SIGNATURE"*)
                                        ;;
                                *)
                                        mv $RESOLV $RESOLV.save;;
                                esac
                                break
                        done < $RESOLV
                fi
                echo "$SIGNATURE$(date)" > $RESOLV
                if [ ! -z "$new_domain_name" ]
                then
                        echo search $new_domain_name >> $RESOLV
                fi
                for nameserver in $new_domain_name_servers; do
                        echo nameserver $nameserver
                done >> $RESOLV
        fi
}

That's not perfect (the PR 21109) but is better than what's apparently
in 1.6.1 and also better that your current solution.

As general advice to everyone - if you find what you suspect is a bug
in something other than an up to date -current, go check the cvsweb
interface on www.netbsd.org and see if the bug has perhaps already
been fixed by someone else.   If not it can also be a good idea (though
much harder) to scan the PR database, and see if there's a bug report
describing your problem.

kre