DHCP client with minimal functionality and size

Hi List

Whilst perusing the NetBSD site, I came across a SoC project
about
writing a minimal DHCP userland client.

Well, I have written such a client - dhcpcd [1].
It's more DHCP feature rich out of the box than dhclient and
has full
support for NetBSD, FreeBSD, Darwin and Linux. It also
supports non MMU
devices (ie, no fork) so is suitable for embedded devices.
Infact, it is
used by at least two embedded device makers I know of.

As of version 3.1.8 it became 2-clause BSD licensed, and
3.1.9 finally
supporting NetBSD fully so it can be imported into the base
system.

That's the sell, but it also doesn't match all the SoC
requirements.
1) It does not interact with the kernel DHCP part in any
way.
2) It does not interact with WLAN keys in any way or form
(and shouldn't
either imo)
3) It's marginally bigger than 10k on i386.

When compiled with all the feaures in, with -O2 on
FreeBSD/i386 it
weighs in at 57k. With all the features compiled out and
using -Os it
comes in at 36k. It can go even smaller, but then you start
to lose some
DHCP functionality. I can't give you sizes for NetBSD as my
machine is
amd64 and the disk died this morning :/ But I assume sizes
will be
similar.

Anyway, that's it. If someone wants to take this futher feel
free. I'm
not sure if my subscription to this list worked, so if
anyone wants to
get back it maybe a good idea to at least CC me directly.

Thanks

Roy

[1] http://roy.marples.nam
e/dhcpcd

On Wed, 2008-01-16 at 07:08 -0500, Thor Lancelot Simon
wrote:
> This is the "dhcpcd" whose main() used to be
1-space indented and
> was declared as "int main(argn, argc,
argv)"?
> 
> Please tell me there are two programs named
"dhcpcd" because I never,
> ever, ever want to look at the source code to that one
again.

dhcpcd-3 is a ground up re-write.

The only similarity between dhcpcd-3 and dhcpcd-1 is that
the user
interface is pretty much the same.

>From my git repo [1]
int main(int argc, char **argv)


Thanks

Roy

[1]
http:/
/git.marples.name/?p=dhcpcd/.git;a=blob_plain;f=dhcpcd.c;hb=
0cb69edd45db5ebe0c21913e05712d91e9e42121

On Wed, Jan 16, 2008 at 10:27:39AM +0000, Roy Marples
wrote:
> That's the sell, but it also doesn't match all the SoC
requirements.
> 1) It does not interact with the kernel DHCP part in
any way.

IMO this is a weak requirement anyway. It would be nice if
it can get
thte lease from the kernel at start time, but it shouldn't
strictly be
necessary.

> 2) It does not interact with WLAN keys in any way or
form (and shouldn't
> either imo)

It should only be able to deal with link changes.

> 3) It's marginally bigger than 10k on i386.

That's ok.

Thanks, I'll take a look at the code.

Joerg

On Wed, Jan 16, 2008 at 02:30:56PM +0100, Joerg Sonnenberger
wrote:
> IMO this is a weak requirement anyway. It would be nice
if it can get
> thte lease from the kernel at start time, but it
shouldn't strictly be
> necessary.

Yeah, and even that is not realy needed, as the server will
usually just
reassign it.

> > 2) It does not interact with WLAN keys in any way
or form (and shouldn't
> > either imo)
> 
> It should only be able to deal with link changes.

I'm not sure what is the best way to plug all things needed
together here,
and there certainly are multiple solutions. I think the way
ISC dhclient
allows this mostly fits to static ifconfig nwkeys, and with
wpa/psk
things would get messy anyway.

With wpa_supplicant running in parallel it is indeed enough
to have the dhcp
client react on link changes.

Martin

On Wed, Jan 16, 2008 at 04:23:13PM +0100, Martin Husemann
wrote:
> With wpa_supplicant running in parallel it is indeed
enough to have the dhcp
> client react on link changes.

That was the intention. ISC dhclient doesn't deal well with
roaming
already, so this is actualyl a change to improve the current
situation.

Joerg

On Wed, 2008-01-16 at 14:30 +0100, Joerg Sonnenberger
wrote:
> On Wed, Jan 16, 2008 at 10:27:39AM +0000, Roy Marples
wrote:
> > That's the sell, but it also doesn't match all the
SoC requirements.
> > 1) It does not interact with the kernel DHCP part
in any way.
> 
> IMO this is a weak requirement anyway. It would be nice
if it can get
> thte lease from the kernel at start time, but it
shouldn't strictly be
> necessary.

It can re-request the lease based on how the interface is
currently
configured using the -r option. It does not do this by
default. That
should be satisfactory.

> > 2) It does not interact with WLAN keys in any way
or form (and shouldn't
> > either imo)
> 
> It should only be able to deal with link changes.

Hmmmm. I disagree here. Link managers, such as
wpa_supplicant, should
call a generic network script to say "link
up/down" and then either
configure static ip or do dhcp.

Gentoo uses this approach very well. Although I am slightly
biased as I
wrote that part of Gentoo ;) This is going outside the scope
of this
discussion though.

> > 3) It's marginally bigger than 10k on i386.
> 
> That's ok.
> 
> Thanks, I'll take a look at the code.

Great! It's currently being re-formatted so that it looks
good in
editors that don't use my vim rules though.

Thanks

Roy

On Wed, 16 Jan 2008, Roy Marples wrote:
> Link managers, such as wpa_supplicant, should
> call a generic network script to say "link
up/down" and then either
> configure static ip or do dhcp.

Yup, that works fine with wpa_supplicant & ifwatchd
now,
see http://www.feyrer.de/NetBSD/blog.html/nb_20070816_113
3.html

It fires up dhclient if it detects that wpa_supplicant has
negotiated a 
link.


  - Hubert

On Wed, 16 Jan 2008, Roy Marples wrote:

>>> 2) It does not interact with WLAN keys in any
way or form (and shouldn't
>>> either imo)
>>
>> It should only be able to deal with link changes.
>
> Hmmmm. I disagree here. Link managers, such as
wpa_supplicant, should
> call a generic network script to say "link
up/down" and then either
> configure static ip or do dhcp.
>
> Gentoo uses this approach very well. Although I am
slightly biased as I
> wrote that part of Gentoo ;) This is going outside the
scope of this
> discussion though.

 	Just to clarify - so in this model unplugging and
replugging in an
 	ethernet cable would be expected to run a script which
would kill
 	and potentially restart dhcpdc?

-- 
 		David/absolute       -- www.NetBSD.org: No hype required
--

On Wed, 2008-01-16 at 16:10 +0000, David Brownlee wrote:
> On Wed, 16 Jan 2008, Roy Marples wrote:
> 
> >>> 2) It does not interact with WLAN keys in
any way or form (and shouldn't
> >>> either imo)
> >>
> >> It should only be able to deal with link
changes.
> >
> > Hmmmm. I disagree here. Link managers, such as
wpa_supplicant, should
> > call a generic network script to say "link
up/down" and then either
> > configure static ip or do dhcp.
> >
> > Gentoo uses this approach very well. Although I am
slightly biased as I
> > wrote that part of Gentoo ;) This is going outside
the scope of this
> > discussion though.
> 
>  	Just to clarify - so in this model unplugging and
replugging in an
>  	ethernet cable would be expected to run a script
which would kill
>  	and potentially restart dhcpdc?
> 

Yes, as there is no guarantee the the cable you unplugged is
the same
one you plug in. For example, you could be configuring your
network
based on arpinging set gateways. Here's a sample config you
could
achieve with this in Gentoo.

arping="192.168.0.1"
config_192168000001="192.168.0.99/24"
dns_servers_192168000001="192.168.0.1"
dns_domain_192168000001="foo.com"
config_bge0="arping"
fallback_bge0="dhcp"

Thanks

Roy

On Wed, Jan 16, 2008 at 04:26:10PM +0000, Roy Marples
wrote:
> >  	Just to clarify - so in this model unplugging
and replugging in an
> >  	ethernet cable would be expected to run a script
which would kill
> >  	and potentially restart dhcpdc?
> > 
> 
> Yes, as there is no guarantee the the cable you
unplugged is the same
> one you plug in. For example, you could be configuring
your network
> based on arpinging set gateways. Here's a sample config
you could
> achieve with this in Gentoo.

This is exactly why I asked for the DHCP client to deal with
this. Keep
the currently configured lease and try to validate it / get
a new one.
This is what Windows is doing with the exception of dropping
the old
lease when it can't get a new one. This is the most sensible
behaviour.

Joerg