[openbeosnetteam] Re: DHCP Stay Alive Question
- From: "Philippe Houdoin" <philippe.houdoin@xxxxxxx>
- To: openbeosnetteam@xxxxxxxxxxxxx
- Date: Sat, 23 Oct 2004 18:09:13 +0200 CEST
> > I agree. What you said makes perfect sense that the DHCP client
> > should
> > be a protocol module.
>
> But that makes the DHCP code vulnerable to buffer overflow attacks.
Like pretty much all our code. That's not specific to DHCP. And not
even specific to kernelland.
It still an issue we must take care off, but I don't see why it matter
for DHCP protocol more than every others...
> Is there any use in making DHCP really live (as a whole) in the
> kernel?
It's not about "liveness in kernel" but "liveness in our stack".
As we choose to put our stack into kernel both for technical and
performance reasons, it make it "liveness in kernel" too, but that
something we all know from start when we choose the kernel stack road.
> I mean, if speed were an issue I would do it, but I cannot imagine
> any
> good reason to use that.
Simplicity?
It's a protocol and a network feature, considered as de-facto today.
ZeroConf would be in short time considered a de-facto feature, and it
needs a tigh DHCP and DNS support integration into the stack to works
fine.
It's a simple feature, too.
And it's very similar to BOOTP, which should work in a very limited
operating system environment (not userland space, for example).
But I agree, performance is not at all an issue here ;-)
> We could easily make the DHCP module run a dhcp_client userland app
> that
> cares for everything and communicates with the kernel module.
And increase complexity and dependency levels. What a userland's
dhcp_client can do better than a DHCP stack module can't?!
It doesn't mean we don't need a userland tool to turn on or off an
interface DHCP mode, because we still needs one.
It mean splitting DHCP "protocol" handling into parts (dhcp_client
handling discovery and setup, stack module waking up dhcp_client on
lease expiration) doesn't bring us any benefit. Or am I blind?
Or we put all DHCP protocol support into the stack or we put all in an
userland tool, using others tools to interact with the stack
(ifconfig). This second solution sounds too much Unixish to me, but
maybe it's only me...
> >>BTW, maybe it's a good occasion to write a kernel module exporting
> >>the basic (without DNS resolver support at start) sockets API to
> >>kernelland. That would help network-related drivers (netblock
> >>devices?) and kernel add-ons (network filesystems) but also porting
> >>your DHCP_client code...
> >
> >
> > Since I don't know the exact status of everything, I'll take your
> > word
> > on the fact that its needed. Are you saying this is needed before
> > I can
> > get my DHCP protocol module to work?
>
> It would be rather difficult without such an API module (and you code
> would not be portable).
David, your code is currently using sockets API, which from userland
point of view is perfectly fine.
To move it into a kernel module, where this API is not *currently*
available, there is two possibilities:
1) change your code so it use Haiku's stack internal API to create,
send and receive UDP packets
2) write a kernel module exporting the sockets API for every kernel
module. That, your code can be move more easily into kernelland.
2) is a task we planned to do one day anyway, but 1) may be not that
hard, considering the size of your current code.
- Philippe.
--
Fortune Cookie Says:
Eternal nothingness is fine if you happen to be dressed for it.
-- Woody Allen
Other related posts:
