DHCP client with minimal functionality and size

[Roy Marples]

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.name/dhcpcd


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Thor Lancelot Simon]

Post by Roy Marples
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].

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.

Thor

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Thor Lancelot Simon
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.

Post by Thor Lancelot Simon
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


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Joerg Sonnenberger]

Post by Roy Marples
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.

Post by Roy Marples
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.

Post by Roy Marples
3) It's marginally bigger than 10k on i386.

That's ok.

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

Joerg

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Martin Husemann]

Post by Joerg Sonnenberger
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.

Post by Joerg Sonnenberger

Post by Roy Marples
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

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Joerg Sonnenberger]

Post by Martin Husemann
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

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Joerg Sonnenberger

Post by Roy Marples
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.

Post by Joerg Sonnenberger

Post by Roy Marples
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.

Post by Joerg Sonnenberger

Post by Roy Marples
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


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Hubert Feyrer]

Post by Roy Marples
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_1133.html

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


- Hubert

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Brownlee]

Post by Roy Marples

Post by Joerg Sonnenberger

Post by Roy Marples
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?

[Roy Marples]

Post by David Brownlee

Post by Roy Marples

Post by Joerg Sonnenberger

Post by Roy Marples
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


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Joerg Sonnenberger]

Post by Roy Marples

Post by David Brownlee
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

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Steven M. Bellovin]

On Thu, 17 Jan 2008 15:18:29 +0100

Post by Joerg Sonnenberger

Post by Roy Marples

Post by David Brownlee
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.

Right, but it might be a better approach to build something more like
network manager to handle this. I agree that the current dhclient does
that very badly.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marles]

Post by Joerg Sonnenberger

Post by Roy Marples

Post by David Brownlee
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.

You've just described how every DHCP client operates without a link manager.
If you simply want the link manager to attempt a DHCP renewal (which is what I
think you're asking for) then it can simply call

dhcpcd -n $iface

The DHCP client shouldn't make this assumption as the user may have a more
exotic automated network setup.

Thanks

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Joerg Sonnenberger]

Post by Roy Marles
You've just described how every DHCP client operates without a link manager.

So, why do I have to run Yet Another Program?

Joerg

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Joerg Sonnenberger

Post by Roy Marles
You've just described how every DHCP client operates without a link manager.

So, why do I have to run Yet Another Program?

Because like most UNIX tools, it does one job very well and doesn't try to do
anything beyond that. I suggest you re-read the topic of this thread :)

Thanks

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Martin Husemann]

Post by Roy Marples
Because like most UNIX tools, it does one job very well and doesn't try to do
anything beyond that.

I disagree - it does it's own job not very well if I need to script it
with another tool for a simple & very common setup.

My idea would be to have it handle up/downs of the interfaces it deals with
automatically by default, but offer one option to not deal with them at all,
and another to just exit when the interface goes down.

Provide enouogh rope, but don't be inherently complex to use.

Martin

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Steven M. Bellovin]

On Thu, 17 Jan 2008 23:25:59 +0000

Post by Roy Marples

Post by Joerg Sonnenberger

Post by Roy Marles
You've just described how every DHCP client operates without a link manager.

So, why do I have to run Yet Another Program?

Because like most UNIX tools, it does one job very well and doesn't
try to do anything beyond that.

I agree -- it's very much the right way to do things.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Martin Husemann

Post by Roy Marples
Because like most UNIX tools, it does one job very well and doesn't try
to do anything beyond that.

I disagree - it does it's own job not very well if I need to script it
with another tool for a simple & very common setup.
My idea would be to have it handle up/downs of the interfaces it deals with
automatically by default, but offer one option to not deal with them at
all, and another to just exit when the interface goes down.
Provide enouogh rope, but don't be inherently complex to use.
Martin

The problem there is that wireless interfaces aren't down as such. The link
itself has to remain up for wireless to actually work. Then you have VPN
links, where the interface appears and disappears (depending on
configuration) when the link is working and when it isn't. You also have to
consider links such as ethernet bridging.

Basically there are many different kinds of links that the DHCP client would
have to know how to react to, and I'm pretty sure that the implementation for
each various across operating systems.

It's an awful lot of work to do what you suggest, for not much benefit. Link
managers already exist as such, dhcp clients already exist. Scripts are the
magic glue between them. I'm not suggesting that you write the scripts as I
and others already have. Well, for Linux and FreeBSD at any rate. I'm quite
new to NetBSD, but I see that it has no equivalent for devd which is a very
nice link manager.

Infact, have a look at devd if you've not already. It basically responds to
hardware events and then runs a command. Or a script if you will. Events
include plugging in mice, keyboards, blue tooth dongles...... and network
cables and IEEE802.11 links coming up.

Thanks

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Pierre Pronchery]

Howdy,

Post by Steven M. Bellovin
On Thu, 17 Jan 2008 15:18:29 +0100

Post by Joerg Sonnenberger

Post by Roy Marples

Post by David Brownlee
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.

Right, but it might be a better approach to build something more like
network manager to handle this. I agree that the current dhclient does
that very badly.

I think I can comment on that: I am using ifwatchd to monitor the
carrier status of my ethernet port (-c). I have a list of known networks
that I detect using arping; some of which I configure static IP, others
that I should fire dhclient.

There is however a major inconvenience with the current dhclient: when
started, it ifdowns and ifups the interface. This triggers ifwatchd over
and over again, so I have to actually stop ifwatchd before I fire
dhclient. Obviously, that's not very useful.

Roy, is your implementation behaving likewise?
Would anyone have a better idea on how to do this? FWIW the original
patch in PR 23191 already mentioned this problem.

Anyway, I would therefore tend to agree with the UNIX philosophy here:
- I think the DHCP client should just be a client (which is avoiding
unsuspected side-effects when triggered manually)
- I really like that the process of actually setting up the network
doesn't imply using DHCP.

HTH,

[Roy Marples]

Post by Pierre Pronchery
I think I can comment on that: I am using ifwatchd to monitor the
carrier status of my ethernet port (-c). I have a list of known networks
that I detect using arping; some of which I configure static IP, others
that I should fire dhclient.
There is however a major inconvenience with the current dhclient: when
started, it ifdowns and ifups the interface. This triggers ifwatchd over
and over again, so I have to actually stop ifwatchd before I fire
dhclient. Obviously, that's not very useful.
Roy, is your implementation behaving likewise?

No, dhcpcd never downs the interface as this can kills wireless links amongst
other things. Instead it simply removes currently assigned addresses.

Thanks

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Young]

Post by Roy Marples
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.

It sounds like Roy's client is perfectly fine for most uses, and we
should import it. Even if some users must use ifwatchd+dhcpcd to get
the full complement of features that they desire, on i386 that's

~57k (dhcpcd) + ~10k (ifwatchd) = ~67k total

Compare with ~308k for dhclient alone.

Compatibility with dhclient-script would be nice.

Roy, I have a few questions.

1) Have you tested running more than one dhcpcd on the same system,
each instance on a different interface?

2) Does the IPV4LL support do "claim & defend" per the RFC, or does it
rely on the kernel to do the defense? Does it DTRT if IPV4LL numbers
collide?

3) Are you eligible for Summer of Code? NetBSD still needs a compact
DHCP server. If you are eligible, that would be a great GSoC project
for you to propose.

Dave

[Joerg Sonnenberger]

Post by David Young
~57k (dhcpcd) + ~10k (ifwatchd) = ~67k total

IMO 57KB is still quite a bit for the client only.

Joerg

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by David Young
Compatibility with dhclient-script would be nice.

And not very feasable. dhcpcd can be scripted to an extent, but not as much as
dhclient.

Post by David Young
Roy, I have a few questions.
1) Have you tested running more than one dhcpcd on the same system,
each instance on a different interface?

Yes. Infact that's how it was desgined. However, it only works well on Linux
boxes as you can have multiple default routes seperated by metric (lowest
wins), something which no BSD as yet supports. I could try and make each
dhcpcd instance talk to each other so one could replace the routes if one
fails and on the same subnet or provided different routes, but I've not done
that as yet as I think route metrics are a better idea.

Post by David Young
2) Does the IPV4LL support do "claim & defend" per the RFC, or does it
rely on the kernel to do the defense? Does it DTRT if IPV4LL numbers
collide?

It defends it's address about every 10 seconds, during which time it tries to
obtain a DHCP address. Sadly, IPv4LL suffers the same issue as above - the LL
route needs to work across >1 interface, which does not work on any BSD I
know of.

Infact, that would be a good SoC project. Allow NetBSD to support metrics in
routes.

Post by David Young
3) Are you eligible for Summer of Code? NetBSD still needs a compact
DHCP server. If you are eligible, that would be a great GSoC project
for you to propose.

No I'm not :)
I'm in gainful full time employment, but have been a SoC mentor for Gentoo.
I have the time to be a mentor for projects I know well, but not to be a
student. I'm an ex Gentoo dev, but still maintain the init system as an
external project which I aim to put into pkgsrc-wip soon as it boots my BSD
boxes also.

Has dnsmasq been considered? It's very compact, feature rich but GPL.

Thanks

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Joerg Sonnenberger

Post by David Young
~57k (dhcpcd) + ~10k (ifwatchd) = ~67k total

IMO 57KB is still quite a bit for the client only.

With the ARP checking, NTP, NIS, DUID, IPV4LL, resolvconf and writing/reading
info files support removed it weighs in at 36k compiled at -Os.
We could get even more brutal and stop supporting some nice DHCP specific
features such as SIP, classless routes, BPF filters, and others.

For a metric, udhcpc binary weighs in at 26k on Gentoo/Linux i386. And that
does it's interface/routing/resolv config via scripts - dhcpcd does it all in
the binary.

So the question is do you want features or small code?

Let me put it anoher way. Linux has 4 dhcp clients available. Only udhcpc is
smaller than dhcpcd, but dhcpcd has more out of the box working features than
any other client. And it's not that much bigger than udhcpc when compared to
pump and the very bloaty dhclient.

Thanks

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by David Young
It sounds like Roy's client is perfectly fine for most uses, and we
should import it.

I suppose that if you import it, you won't be interested in any Linux specific
code, so to make life easy I'll work on splitting that out into separate
files. I've already re-factored the code around the BSD style a little more
from the latest released version.

Thanks

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Joerg Sonnenberger

Post by David Young
~57k (dhcpcd) + ~10k (ifwatchd) = ~67k total

IMO 57KB is still quite a bit for the client only.

OK, I'm now curious - what sort of size would you expect for the client that
is entirely in C?

Thanks

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Huang]

Post by Roy Marples
OK, I'm now curious - what sort of size would you expect for the client that
is entirely in C?

I dunno, but doesn't Etherboot <http://www.etherboot.org/wiki/> fit a
NIC driver and PXE boot client (which includes a DHCP client) and more
into less than 32K?
--
Name: Dave Huang | Mammal, mammal / their names are called /
INet: ***@azeotrope.org | they raise a paw / the bat, the cat /
FurryMUCK: Dahan | dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 31 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA
+ PL++



--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by David Huang

Post by Roy Marples
OK, I'm now curious - what sort of size would you expect for the client that
is entirely in C?

I dunno, but doesn't Etherboot <http://www.etherboot.org/wiki/> fit a
NIC driver and PXE boot client (which includes a DHCP client) and more
into less than 32K?

Etherboot isn't a general purpose DHCP client.
It's sole purpose is to configure a basic interface enough to pull a boot
image from the network. Of course, feel free to correct me if I'm wrong.

Thanks

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Huang]

Post by Roy Marples
Etherboot isn't a general purpose DHCP client.
It's sole purpose is to configure a basic interface enough to pull a boot
image from the network. Of course, feel free to correct me if I'm wrong.

Fair enough :)

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Laight]

Post by Joerg Sonnenberger

Post by David Young
~57k (dhcpcd) + ~10k (ifwatchd) = ~67k total

IMO 57KB is still quite a bit for the client only.

Is that a challenge ?

David

[Roy Marples]

Post by David Laight

Post by Joerg Sonnenberger

Post by David Young
~57k (dhcpcd) + ~10k (ifwatchd) = ~67k total

IMO 57KB is still quite a bit for the client only.

Is that a challenge ?

I see it as such :)
I've already re-tooled the DHCP handling section of the code that deals with
client configuration so it uses code to access the DHCP message directly
instead of a custom structure.

But I'd like to gather peoples opinions on what size a feature rich DHCP
client should be.
Remember, dhcpcd is written purely in C. dhclient for all it's bloat still
relies on dhclient-script and it's supporting binaries is as ifconfig, route,
etc.

So if 57k is "quite a bit", what is "optimal"?

Thanks

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Zafer Aydogan]

Post by Roy Marples

Post by David Laight

Post by Joerg Sonnenberger

Post by David Young
~57k (dhcpcd) + ~10k (ifwatchd) = ~67k total

IMO 57KB is still quite a bit for the client only.

Is that a challenge ?

I see it as such :)
I've already re-tooled the DHCP handling section of the code that deals with
client configuration so it uses code to access the DHCP message directly
instead of a custom structure.
But I'd like to gather peoples opinions on what size a feature rich DHCP
client should be.
Remember, dhcpcd is written purely in C. dhclient for all it's bloat still
relies on dhclient-script and it's supporting binaries is as ifconfig, route,
etc.
So if 57k is "quite a bit", what is "optimal"?
Thanks
Roy

I think 57k is very small.
I would like to see it in tree and replace dhclient, because of
dhclient's inability to request an IP in background. For example, if
you plug in your ethernet cable after you have booted.


Zafer.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Brownlee]

Post by Roy Marples

Post by David Laight

Post by Joerg Sonnenberger

Post by David Young
~57k (dhcpcd) + ~10k (ifwatchd) = ~67k total

IMO 57KB is still quite a bit for the client only.

Is that a challenge ?

I see it as such :)
I've already re-tooled the DHCP handling section of the code that deals with
client configuration so it uses code to access the DHCP message directly
instead of a custom structure.
But I'd like to gather peoples opinions on what size a feature rich DHCP
client should be.
Remember, dhcpcd is written purely in C. dhclient for all it's bloat still
relies on dhclient-script and it's supporting binaries is as ifconfig, route,
etc.
So if 57k is "quite a bit", what is "optimal"?

I think 57K is a good size for a full feature DHCP client.
Certainly compared to the 350K of dhclient.

Yes, it would be nice to have a tiny, minimal featured dhcp client
for specific uses, but that is much less important if your main
client is 57K as opposed to 350K.

Is there anything dhclient does that dhcpcd does not? How about
people migrating who have /etc/dhclient-enter-hooks and/or
/etc/dhclient-exit-hooks?

[Steven M. Bellovin]

On Wed, 2 Apr 2008 14:40:27 +0200

Post by Zafer Aydogan
I would like to see it in tree and replace dhclient, because of
dhclient's inability to request an IP in background. For example, if
you plug in your ethernet cable after you have booted.

Sure it handles that; it just doesn't wake up immediately. See the
'retry' parameter in dhclient.conf(5).


--Steve Bellovin, http://www.cs.columbia.edu/~smb

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Joerg Sonnenberger]

Post by Zafer Aydogan
I would like to see it in tree and replace dhclient, because of
dhclient's inability to request an IP in background. For example, if
you plug in your ethernet cable after you have booted.

See my requirement for link state support in DHCP.

Joerg

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Zafer Aydogan]

Post by Steven M. Bellovin
On Wed, 2 Apr 2008 14:40:27 +0200

Post by Zafer Aydogan
I would like to see it in tree and replace dhclient, because of
dhclient's inability to request an IP in background. For example, if
you plug in your ethernet cable after you have booted.

Sure it handles that; it just doesn't wake up immediately. See the
'retry' parameter in dhclient.conf(5).

retry doesn't work at all.
It is set by default to 5 minutes, but somehow it happens nothing
after 5 minutes.

Post by Steven M. Bellovin
--Steve Bellovin, http://www.cs.columbia.edu/~smb

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by David Brownlee

Post by Roy Marples
So if 57k is "quite a bit", what is "optimal"?

I think 57K is a good size for a full feature DHCP client.
Certainly compared to the 350K of dhclient.
Yes, it would be nice to have a tiny, minimal featured dhcp client
for specific uses, but that is much less important if your main
client is 57K as opposed to 350K.

I've been working on dhcpcd more than I'd like since someone said 57k stripped
was quite a bit. I've re-structured the code so that OS specific stuff is now
in small files outside the main code. I've also moved to get the
configuration suff from the DHCP message directly instead of populating a
custom structure. Lastly, some parts of the code have been optimized to make
it smaller.

The end result on NetBSD-4/i386 is ..... 47k un-stripped, 41k stripped :)
I could also save ~600 bytes by merging all the .c files into one and
compiling that. However, I do have one feature to add which may take up a k
or two.

It's currently under-going a bit of regression testing to make sure that
nothing is broken after this, but it's looking very good right now. Hopefully
I'll release it next week.

Post by David Brownlee
Is there anything dhclient does that dhcpcd does not? How about
people migrating who have /etc/dhclient-enter-hooks and/or
/etc/dhclient-exit-hooks?

That's the main bug bear really. dhcpcd does ALL it's configuration itself
without the need for scripts. dhcpcd can call a script when a dhcp lease is
gained or lost, but it's only supplied with information about the lease it
just gained. This script cannot stop or change the way dhcpcd goes about
configuring the system based on the lease.

However, you can stop dhcpcd from say installing default routes,
touching /etc/resolv.conf or doing any ntp changes through command line
options.

Also, the curret dhcpcd is hardcoded to a small list of parameters to request
and make available to the script. One of the goals with the new framework is
to allow the user to request parameters to be made available to the script
which previous dhcpcd didn't care about. This is the missing feature I
mentioned earlier, and it's the one thing that dhclient can to that dhcpcd
currently cannot.

Thanks

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Thor Lancelot Simon]

Post by Roy Marples
However, you can stop dhcpcd from say installing default routes,
touching /etc/resolv.conf or doing any ntp changes through command line
options.

Doing any NTP changes? Please, say more.

I don't want C programs mucking with my daemon configuration files.

Thor

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Thor Lancelot Simon

Post by Roy Marples
However, you can stop dhcpcd from say installing default routes,
touching /etc/resolv.conf or doing any ntp changes through command line
options.

Doing any NTP changes? Please, say more.
I don't want C programs mucking with my daemon configuration files.

By default, dhcpcd will request a list of NTP servers to use from the DHCP
server. If none are given then dhcpcd does nothing. Otherwise it will
create /etc/ntpd.conf, and /etc/ntp.conf to work with this information. If
dhcpcd knows about the init system (it does for NetBSD rc) then it will also
restart ntp if it had to change the file.

This can be disabled with the -N option.

It currently does similar for NIS also.

Thanks

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Bernd Ernesti]

Post by Roy Marples

Post by Thor Lancelot Simon

Post by Roy Marples
However, you can stop dhcpcd from say installing default routes,
touching /etc/resolv.conf or doing any ntp changes through command line
options.

Doing any NTP changes? Please, say more.
I don't want C programs mucking with my daemon configuration files.

Neither do I. At least not enabled by default.

Post by Roy Marples
By default, dhcpcd will request a list of NTP servers to use from the DHCP
server. If none are given then dhcpcd does nothing. Otherwise it will
create /etc/ntpd.conf, and /etc/ntp.conf to work with this information. If
dhcpcd knows about the init system (it does for NetBSD rc) then it will also
restart ntp if it had to change the file.

And you will lose your old ntpd.conf that way.

I hope that this will never make it into NetBSD, if things like this are
enabled by default.

Post by Roy Marples
This can be disabled with the -N option.
It currently does similar for NIS also.

Huh?

You mean you would start NIS if the other side provides NIS services?
That is not very desirable when you just want an ip address.

Bernd

P.S. Reply-to and Mail-Followup-To is set.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Brownlee]

Post by Roy Marples

Post by David Brownlee

Post by Roy Marples
So if 57k is "quite a bit", what is "optimal"?

I think 57K is a good size for a full feature DHCP client.
Certainly compared to the 350K of dhclient.
Yes, it would be nice to have a tiny, minimal featured dhcp client
for specific uses, but that is much less important if your main
client is 57K as opposed to 350K.

I've been working on dhcpcd more than I'd like since someone said 57k stripped
was quite a bit. I've re-structured the code so that OS specific stuff is now
in small files outside the main code. I've also moved to get the
configuration suff from the DHCP message directly instead of populating a
custom structure. Lastly, some parts of the code have been optimized to make
it smaller.
The end result on NetBSD-4/i386 is ..... 47k un-stripped, 41k stripped :)
I could also save ~600 bytes by merging all the .c files into one and
compiling that. However, I do have one feature to add which may take up a k
or two.

Thats and even better size :)

Post by Roy Marples
It's currently under-going a bit of regression testing to make sure that
nothing is broken after this, but it's looking very good right now. Hopefully
I'll release it next week.

Post by David Brownlee
Is there anything dhclient does that dhcpcd does not? How about
people migrating who have /etc/dhclient-enter-hooks and/or
/etc/dhclient-exit-hooks?

That's the main bug bear really. dhcpcd does ALL it's configuration itself
without the need for scripts. dhcpcd can call a script when a dhcp lease is
gained or lost, but it's only supplied with information about the lease it
just gained. This script cannot stop or change the way dhcpcd goes about
configuring the system based on the lease.
However, you can stop dhcpcd from say installing default routes,
touching /etc/resolv.conf or doing any ntp changes through command line
options.

As other people have mentioned its probably best to have
the default behaviour of dhcpcd to be changing no more than
dhclient, to avoid annoying people.

Can it take the options from a config file also (I know, more
parsing code, more size...)

Post by Roy Marples
Also, the curret dhcpcd is hardcoded to a small list of parameters to request
and make available to the script. One of the goals with the new framework is
to allow the user to request parameters to be made available to the script
which previous dhcpcd didn't care about. This is the missing feature I
mentioned earlier, and it's the one thing that dhclient can to that dhcpcd
currently cannot.

As a thought rather than having them as optional parameters it could
always either set them in the environment or pass them in as a list
of VAR1=value1 VAR2=value2

[Roy Marples]

Post by David Brownlee
As other people have mentioned its probably best to have
the default behaviour of dhcpcd to be changing no more than
dhclient, to avoid annoying people.

I can understand that.
I'll ask the maintainers of dhcpcd in some Linux distros as that change would
affect them as it's changing a long standing default behaviour.

However, I do think it's fair that if you request an option that dhcpcd knows
about, such as NTP servers, then it will configure them for you.

Post by David Brownlee
Can it take the options from a config file also (I know, more
parsing code, more size...)

Not presently. I'm also not convinced of a need for one as you can set all the
options via the command line.

Post by David Brownlee

Post by Roy Marples
Also, the curret dhcpcd is hardcoded to a small list of parameters to
request and make available to the script. One of the goals with the new
framework is to allow the user to request parameters to be made available
to the script which previous dhcpcd didn't care about. This is the
missing feature I mentioned earlier, and it's the one thing that dhclient
can to that dhcpcd currently cannot.

As a thought rather than having them as optional parameters it could
always either set them in the environment or pass them in as a list
of VAR1=value1 VAR2=value2

I dislike environment for that, a config file would be better. Not sure what
you mean by VAR1=value1 though, as I'm just suggesting the list adding to the
list of parameters to request, not setting any values. So it could as easily
be done via a command line option.

Thanks

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Thor Lancelot Simon]

Post by Roy Marples

Post by David Brownlee
As other people have mentioned its probably best to have
the default behaviour of dhcpcd to be changing no more than
dhclient, to avoid annoying people.

I can understand that.
I'll ask the maintainers of dhcpcd in some Linux distros as that change would
affect them as it's changing a long standing default behaviour.
However, I do think it's fair that if you request an option that dhcpcd knows
about, such as NTP servers, then it will configure them for you.

...and we arrive at the reason why ISC dhclient has scripts for manipulating
the system. Some users are naive about their system and network
configurations and just want the DHCP client to "do magic" -- they don't know
about existing configuration files and don't care what it does to them.

Other users, on the other hand, have quite a bit of local configuration
state and under no circumstances want a network client program blindly
overwriting it -- but parsing the configuration file for daemon _X_ in a
small C program like a dhcp client should be is not practical.

For all the flaws of ISC dhclient the use of scripts for managing
configuration files after state changes, and the set of variables it
provides to them, are very well thought out. Done properly -- dhclient
does not do it properly! -- it should make a DHCP client smaller, not
larger, since all the work of writing ntp.conf etc. can be deferred to
the shell.

Thor

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Steven M. Bellovin]

On Fri, 11 Apr 2008 15:04:20 -0400

Post by Thor Lancelot Simon
For all the flaws of ISC dhclient the use of scripts for managing
configuration files after state changes, and the set of variables it
provides to them, are very well thought out. Done properly --
dhclient does not do it properly! -- it should make a DHCP client
smaller, not larger, since all the work of writing ntp.conf etc. can
be deferred to the shell.

Thanks; I was about to post the same thing. There are a fair number of
things I dislike about dhclient, but the scripts actually help the
size, since I already have a shell, ifconfig, etc., lying around.

--Steve Bellovin, http://www.cs.columbia.edu/~smb

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Thor Lancelot Simon

Post by Roy Marples
However, I do think it's fair that if you request an option that dhcpcd
knows about, such as NTP servers, then it will configure them for you.

...and we arrive at the reason why ISC dhclient has scripts for
manipulating the system. Some users are naive about their system and
network
configurations and just want the DHCP client to "do magic" -- they don't
know about existing configuration files and don't care what it does to
them.
Other users, on the other hand, have quite a bit of local configuration
state and under no circumstances want a network client program blindly
overwriting it -- but parsing the configuration file for daemon _X_ in a
small C program like a dhcp client should be is not practical.

So in other words, we need options to have 3 states

1) don't request it
2) request it, but don't do anything aside from pass it to the script
3) request it and do something with it

2 is only different from 3 if dhcpcd knows what to *do* with it.
Currently, dhcpcd knows to handle these
ip address/netmask/broadcast, static routes, routers, csrs, domain, domain
search, dns servers
These are all kind of required for basic dhcp operation, and will remain in
the dhcpcd binary itself.

dhcpcd also knows about hostname, mtu, nis and ntp (and openntp) and will
attempt to configure them for you. In the instances where it writes to a
config file (ntp, nis, dns), dhcpcd makes no attempt at parsing and blindly
overwrites. There is an argument this could be moved to a shell file.

The dhcpcd default has always been if we know how to configure it then do so
unless otherwise instructed. dhcpcd also has lots of users in the Linux world
who rely on this long standing behaviour.

So, if dhcpcd installs a default script to modify ntp and nis would that
satisfy the requirements? Distributions, such as Gentoo, Debian and SUSE
could then install the script by default whereas the more minimalistic ones
such as NetBSD could install the script in an example area.

Thanks

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Steven M. Bellovin
On Fri, 11 Apr 2008 15:04:20 -0400

Post by Thor Lancelot Simon
For all the flaws of ISC dhclient the use of scripts for managing
configuration files after state changes, and the set of variables it
provides to them, are very well thought out. Done properly --
dhclient does not do it properly! -- it should make a DHCP client
smaller, not larger, since all the work of writing ntp.conf etc. can
be deferred to the shell.

Thanks; I was about to post the same thing. There are a fair number of
things I dislike about dhclient, but the scripts actually help the
size, since I already have a shell, ifconfig, etc., lying around.

The argument for not using ifconfig, route and friends is that they vary too
much between platforms. No so much on the BSD's, but it is on Linux.
I actually save code by writing it in C - one BSD implementation currently
fits all, one Linux implementation currently fits all. And the BSD/Linux
specific code isn't really that much.

For an idea, look how many scripts that dhclient ships with and how much code
could be re-used.

Thanks

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Brownlee]

Post by Steven M. Bellovin
On Fri, 11 Apr 2008 15:04:20 -0400

Post by Thor Lancelot Simon
For all the flaws of ISC dhclient the use of scripts for managing
configuration files after state changes, and the set of variables it
provides to them, are very well thought out. Done properly --
dhclient does not do it properly! -- it should make a DHCP client
smaller, not larger, since all the work of writing ntp.conf etc. can
be deferred to the shell.

Thanks; I was about to post the same thing. There are a fair number of
things I dislike about dhclient, but the scripts actually help the
size, since I already have a shell, ifconfig, etc., lying around.

Would you be happy if dhcpcd had options to disable various
of its setting actions and would call call out to a script at
those various points so you could have a similar setup to
dhclient?

[Joerg Sonnenberger]

Post by Roy Marples
1) don't request it
2) request it, but don't do anything aside from pass it to the script
3) request it and do something with it

I would split that into:
(1) The default request set obtained with the lease.
(2) An interface to query the current DHCP for additional records.

The second class can be used by a script.

Joerg

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Joerg Sonnenberger

Post by Roy Marples
1) don't request it
2) request it, but don't do anything aside from pass it to the script
3) request it and do something with it

(1) The default request set obtained with the lease.
(2) An interface to query the current DHCP for additional records.
The second class can be used by a script.

If you're happy with the default script that dhcpcd ships with to handle ntp
and nis if provided then I think we're in agreement :)

Thanks

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Bernd Ernesti]

Post by Roy Marples

Post by Joerg Sonnenberger

Post by Roy Marples
1) don't request it
2) request it, but don't do anything aside from pass it to the script
3) request it and do something with it

(1) The default request set obtained with the lease.
(2) An interface to query the current DHCP for additional records.
The second class can be used by a script.

If you're happy with the default script that dhcpcd ships with to handle ntp
and nis if provided then I think we're in agreement :)

I have read the thread by I don't know what is the real plan about dhcpcd.
Should it replace the current dclient?

If so then I'm not for going this way with the default handling of ntp
and NIS. Where the later is a really nono for me and the former should
at least make it possible to save the old config file, if it is enabled
by default at all.

Bernd


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by Bernd Ernesti

Post by Roy Marples
If you're happy with the default script that dhcpcd ships with to handle
ntp and nis if provided then I think we're in agreement :)

I have read the thread by I don't know what is the real plan about dhcpcd.
Should it replace the current dclient?

The current consensus is not in its present form.

Post by Bernd Ernesti
If so then I'm not for going this way with the default handling of ntp
and NIS. Where the later is a really nono for me and the former should
at least make it possible to save the old config file, if it is enabled
by default at all.

I think the whole point of it being in a script means that it's easier for a
distribution to control what happens by default.

dhcpcd has always had options NOT to configure everything the DHCP server
gives it, which some people seem to have missed :)

I think the current argument is wether it should do it or not by default.

Thanks

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Steven M. Bellovin]

On Sat, 12 Apr 2008 10:08:30 +0100 (BST)

Post by David Brownlee

Post by Steven M. Bellovin
On Fri, 11 Apr 2008 15:04:20 -0400

Post by Thor Lancelot Simon
For all the flaws of ISC dhclient the use of scripts for managing
configuration files after state changes, and the set of variables
it provides to them, are very well thought out. Done properly --
dhclient does not do it properly! -- it should make a DHCP client
smaller, not larger, since all the work of writing ntp.conf etc.
can be deferred to the shell.

Thanks; I was about to post the same thing. There are a fair
number of things I dislike about dhclient, but the scripts actually
help the size, since I already have a shell, ifconfig, etc., lying
around.

Would you be happy if dhcpcd had options to disable various
of its setting actions and would call call out to a script at
those various points so you could have a similar setup to
dhclient?

In general, I think that site-exits are good things -- I much prefer
customizing things without hacking code, since it makes much life much
easier when upgrading.

So -- yes, it would be useful. That said, my agreement with Thor was
on size, not functionality.


--Steve Bellovin, http://www.cs.columbia.edu/~smb

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[David Laight]

Post by Roy Marples
However, I do think it's fair that if you request an option that dhcpcd knows
about, such as NTP servers, then it will configure them for you.

It is a right PITA working out how to stop some DHCP impelentations
overwriting your resolv.conf file, and configuring a default route
that isn't supplied by, or is different from the one returned by, the
DHCP server.

David

[matthew sporleder]

Post by Thor Lancelot Simon

Post by Roy Marples
However, you can stop dhcpcd from say installing default routes,
touching /etc/resolv.conf or doing any ntp changes through command line
options.

Doing any NTP changes? Please, say more.
I don't want C programs mucking with my daemon configuration files.

How is this different from messing with resolv.conf? The sun
server/client has an interesting set of configurations for handling
what to send/receive. (see dhcp_inittab(4))

I guess it'd be nice to give an option for enabling/disabling
everything is rfc2132 with like a -e(nable) ntp,lpr,foo -d(isable)
dns,bar and just document the defaults. It would also be nice if the
dhcp client could append instead of replace (or replace it's only its
own stuff (<option id="added_by_dhcp"> foo </option>) but then I
guess it would need to know a way to parse and modify (not just
create) each type of config file.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Thor Lancelot Simon]

Post by matthew sporleder

Post by Thor Lancelot Simon

Post by Roy Marples
However, you can stop dhcpcd from say installing default routes,
touching /etc/resolv.conf or doing any ntp changes through command line
options.

Doing any NTP changes? Please, say more.
I don't want C programs mucking with my daemon configuration files.

How is this different from messing with resolv.conf? The sun
server/client has an interesting set of configurations for handling
what to send/receive. (see dhcp_inittab(4))

I don't want C programs mucking with my configuration files. Period.

It is trivial to move this functionality from the DHCP client itself into
a shell script (or shell scripts) it invokes. It wouldn't be much harder
to maintain some compatibility with the scripts used by ISC dhclient, by
exporting the same variable names for old and new address, etc. Roy's
DHCP client would get smaller, and I wouldn't get my ntp.conf or resolv.conf
stomped if I didn't want them stomped.

Thor

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Roy Marples]

Post by David Laight

Post by Roy Marples
However, I do think it's fair that if you request an option that dhcpcd
knows about, such as NTP servers, then it will configure them for you.

It is a right PITA working out how to stop some DHCP impelentations
overwriting your resolv.conf file, and configuring a default route
that isn't supplied by, or is different from the one returned by, the
DHCP server.

You could always read the fine man page :)
Here, I'll quote to save everyone the effort of looking for it themselves

Restriciting behaviour
dhcpcd will try to do as much as it can by default. However, there are
sometimes situations where you don’t want the things to be configured
exactly how the the DHCP server wants. Here are some option that deal
with turning these bits off.

-A, --noarp
Don’t request or claim the address by ARP.

-G, --nogateway
Don’t set any default routes.

-L, --noipv4ll
Don’t use IPv4LL at all.

-M, --nomtu
Don’t set the MTU of the interface.

-N, --nontp
Don’t touch /etc/ntp.conf or restart the ntp service.

-R, --nodns
Don’t send DNS information to resolvconf or touch
/etc/resolv.conf.

-T, --test
On receipt of discover messages, simply print the contents of the
DHCP message to the console. dhcpcd will not configure the
interface, touch any files or restart any services.

-Y, --nonis
Don’t touch /etc/yp.conf or restart the ypbind service.

There, that wasn't that much of a PITA was it?

Thanks

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Thor Lancelot Simon]

Post by Roy Marples
There, that wasn't that much of a PITA was it?

Well, it's a PITA because, of course, it's not possible to make it
do what most people who maintain their own configuration files want, if
they're using DHCP at all: *provide* the information returned by the
server to code under their control, so they can use it, but not
*overwrite* the configuration files themselves.

For all its flaws, dhclient really gets this just right, and basically
every other dhcp client gets it very, very wrong.

[Roy Marples]

Post by Thor Lancelot Simon

Post by Roy Marples
There, that wasn't that much of a PITA was it?

Well, it's a PITA because, of course, it's not possible to make it
do what most people who maintain their own configuration files want, if
they're using DHCP at all: *provide* the information returned by the
server to code under their control, so they can use it, but not
*overwrite* the configuration files themselves.

You misundertand :)
I was pointing out that dhcpcd is well documented about enabling/disabling it
stamping on configuration files. I was not suggesting for one moment that
dhcpcd presently allowed the user to do anything beyond that.

Post by Thor Lancelot Simon
For all its flaws, dhclient really gets this just right, and basically
every other dhcp client gets it very, very wrong.

Not true. udhcpc from busybox does it like so also, and just like dhclient
it's not that great out of the box.

Thanks

Roy

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de