tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Retiring dhclient

On Thu, Nov 24, 2011 at 11:25:27AM -0500, Ted Lemon wrote:
> On Nov 24, 2011, at 3:53 AM, Thor Lancelot Simon wrote:
> > Perhaps it would be better to set the MTU only if it actually differs from 
> > the
> > MTU already configured on the adapter?
> A lot of those configuration parameters are weird to me.   Why should the 
> DHCP server have a better idea of what the MTU should be than the client 
> does?   These were put in the spec for completeness, and I suppose it's not 
> out of the question that they might be useful, but it seems unlikely that 
> they would be useful by default.

[Ow, ow, ow!  Please limit your line length to 80 chracters when posting to
 the NetBSD mailing lists!]

Consider the case in which you want to take machines out of the vendor's
shipping box, do no firmware-level configuration, have them autoboot
from the network, and run, with no client-side configuration at all.

If you are not running a 1500 MTU, how else *do* you tell them what MTU
to use?  Generally, if you want to avoid doing any network configuration on
the client side because you are using DHCP, why should you have to set the MTU
by hand?

So I think it's reasonable for the server to send the MTU, but -- since
for some MTU values and some adapter types the client *has to* reset its 
PHY or even part of its MAC to do an MTU change -- the DHCP client
software should be careful not to try to change the value on the adapter
if the new value received from the server is the same as what was already

Home | Main Index | Thread Index | Old Index