Subject: Re: dhclient
To: None <firstname.lastname@example.org>
From: Ted Lemon <email@example.com>
Date: 11/07/2004 16:51:18
On Nov 7, 2004, at 7:47 AM, Douglas Wade Needham wrote:
> I did not contribute them at the time
> due to being under contraints by a previous employer who wanted a hand
> in everything I did, even on my own machines and time. Ted, you
> interested in these simple diffs? If so, send them to you via ISC,
> NetBSD or PR them??
I'm not with the ISC anymore, so you'd have to send them to Dave
Hankins to get them into the ISC source. You should PR them in NetBSD
if you think they're worthwhile.
>> } Some wishes:
>> } * I have interfaces that come and go. dhclient
>> } should notice this.
>> How? By scanning the list of interfaces every second?
This is a trivial problem to solve - just listen on the routing socket.
I didn't do it in ISC because it's not portable, but there's no
reason not to have this in the NetBSD tree.
> Oh, and as for the shell script info talking about killing and
> restarting dhclient directly, I would actually recommend having
> /etc/rc.conf call another script which sets stuff releated to dhclient
> and other stuff which may change due to your mobility, and then using
> the rc.d scripts. This way, you do not need to worry about all sorts
> of other things associated with restarting dhclient or other programs.
> And you do not have to worry about munging /etc/rc.conf either.
Killing and restarting dhclient when interfaces come up and down is not
the way to go. It would work on a laptop where all network interfaces
are in PC cards, but in pretty much no other situation.
> No way to even begin on this one. You are much better off playing
> around with wrapper scripts which say "I have interfaces a, b, and c,
> we prefer b so I will set it up for that and restart dhclient." I did
> something like this years ago, and even put in hooks so that
> /etc/rc.conf and other paths would pick up the right info. But as for
> the single interface, if you want to have it listen just to port wi0,
> just add 'wi0' as an argument to the command line.
I think the right way to do this is to have a configuration manager
daemon that can recieve votes from other daemons about what to do about
the network. So if the DHCP client votes "the network has this
address" and there are no opposing votes, that's the address it gets.
But this is a lot of work.
The reason I went with a shell script for dhclient is that it works
when you're trying to be massively portable. I think it's the wrong
thing to do in the NetBSD tree. I would argue for putting more custom
code in C, or making it configurable. Either that, or have a decent
interpretive language as the extension language - e.g., python. This
would necessitate a version of python in /bin, of course. A lot of
milage could be gotten out of that, of course.