[openbeosnetteam] Re: DHCP Stay Alive Question

Philippe,

Personal side note: Do you pronounce your name as "Phileep" or "Philip"?
I'd like to know so I can pronounce it correctly in my head when I read
your emails.  :-)

> David Enderson asked:
> > How solidified is the internal API in the Haiku netserver?
> 
> You mean "Haiku net stack", right?
> Because we don't have a "netserver" as in R5's net_server 
> design. Our stack overall design is shown here: 
>
http://philippe.houdoin.free.fr/phil/beos/openbeos/network_kit/overview.
html
>

Yes, I didn't know the correct term.  Thanks for the diagram link.  That
helped a lot.

> Beside this remark, nothing is solidified in our internal stack
> until R1. Currently, a stack kernel module should conform to the
> (very) simple API defined in current/headers/private/net/net_module.h.
>
> The internal API use for UDP packets, interfaces enumeration and
> interfaces setup is not solidified at all. The good side is that
> we can modify it the way we want/need. The bad side is that it
> can still evolve, breaking some code.

Yup, that is good and bad.  :-)

>> There has
>> been talk of integrating DHCP into what you have.  Do you know
exactly 
>> where it will go and how it will plug in?
>
> I guess we can consider DHCP being a protocol and making a network
> protocol kernel module make sense to me. However, currently your
> (C++) code can't be refactoring into a kernel module like this,
> before move from socket API to internal API to send and receive
> UDP packets, iterate and setup interfaces.

I agree.  What you said makes perfect sense that the DHCP client should
be a protocol module.

I knew whatever I wrote would have to be switched all around and maybe
be converted from C++ to C code.  I just tried to organize it well and
write something since I knew I wouldn't be able to guess the correct
format the first time.  When I get the DHCP conversation completely
working, it looks like my next task will be to make a kernel protocol
module.

Which existing kernel protocol module would you suggest I use as an
example to make mine from?

> 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?

>> The reason I ask is that the DHCP server will need to refresh IPs
when 
>> the lease time is up.  Do you plan to have the client running a 
>> looping thread, will the new netserver fire off an event to the DHCP 
>> client when the lease expires, or do you have another way of doing
it?  
>> I thought I would bring the issue up just in case it hadn't been 
>> thought of.
>
> While moved into the kernel stack, ther DHCP code can use the stack
> "net_timer" service to fired a callback on a specific DHCP expiration.
> That the way our ARP network protocol kernel module handle ARP entries
> expiration, if it's good enough for ARP it should works fine for DHCP
> expirations...
>
> - Philippe

That sounds like an excellent way to do the refresh.

I hope a signal can also be configured to be sent upon shutdown?  The
RFC says that good DHCP clients should send a release packet to the DHCP
server when it ceases to use the IP--such as times of system shutdown or
changing IP settings from dynamic to static.

---

Sorry if some of my comments regarding our team's status are from a bit
of ignorance.  I wanted to make sure I could finish the DHCP client
before I took the time to learn such things as setting up CVS and
installing the net stack.  I'll be doing these things shortly.

--David

Other related posts: