FreeLists / openbeosnetteam / [openbeosnetteam] Re: DHCP Project Specs Needed

[Philippe Houdoin <philippe.houdoin@xxxxxxx>]

Quoting Axel Dörfler:
> Is there any situation where the DHCP negotation has to be started by a
> kernel component? If not, I would rather put it in userland.

Lease expiration (which could be *before* expected time) & client release at
stack shutdown, a future integration with automatic configuration thru ZeroConf
support for example.

But I agree, today we can accomplish this also from userland too, relying on a
daemon to listen on DHCP packets and some script+tool to send the DHCP release
packet at stack shutdown.

I just consider DHCP being a de-facto low level network stack feature these
days, and a good DHCP implementation should use ARP protocol too to
double-check leased addresses.
I can't see how splitting DHCP support into userland DHCP client app, a DHCP
listener daemon app and some script make it simpler and integrated than a
single DHCP kernel module. Except for the userland vs kernelland.

> Don't we need a replacement for inetd anyway? Couldn't we have a
> net_server that takes over inetd services as well as DHCP (as an add-
> on, possibly)?

A super inetd? Like Apple's launchd?
Indeed we need an inetd-like support.
That's maybe a better way to do it, yes. But what if someone kill inetd then?
No more automatic lease expansion?


-