Patch to prevent multiple dhclients starting on an interface

[David W. Hankins]

On Wed, Jun 15, 2005 at 11:57:50AM -0600, LaMont Jones wrote:
> Some (old??) Unixes would have the port remain busy so long as there was
> any association with it, including some time beyond the final close.
> Hence SO_REUSEADDR - which does suck for this case.

That's for TCP tho, no?  After close, UDP, BPF/LPF/RAW sockets never
stuck around to my memory.

Is this instead a holdover from having to have multiple daemons (multiple
interfaces) listen on the same port?

> It could check against basename(argv[0]), which would then just require
> that the client be the same name as ours.  Likewise, it could parse
> netstat -an output, which is probably even more OS-specific in format.
> 
> In the more-complete department, one could add a unix socket to the
> daemon, which the new one could try issuing commands through, and
> determine live/dead status that way....  Actually, long term, that's
> far better than talking to it with signals, although it's more code to
> deal with.

There's another need for the ability to send command-channel type
data to and from the dhcp client:

  http://people.redhat.com/dcbw/NetworkManager/index.html

Wherein the land of milk and honey is described...where web browsers
can ask the local dhcp client(s) for the WPAD option contents, rather
than sending their own INFORM (and all that implies).

-- 
David W. Hankins		"If you don't do it right the first time,
Software Engineer			you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins