Re: Retiring dhclient

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Thu, Nov 24, 2011 at 05:53:25PM +0000, Roy Marples wrote:
> On 24/11/2011 17:44, Joerg Sonnenberger wrote:
> >On Thu, Nov 24, 2011 at 12:23:55PM -0500, Thor Lancelot Simon wrote:
> >>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
> >>configured.
> >
> >BTW, this is exactly what I meant in my initial mail. I think we want to
> >add support for suppressing this link state messages to the net/if.c
> >logic for informing userland. I.e. if the link goes down now and comes
> >back in the next $X seconds, consider it normal behavior of the PHY
> >reset and not as unplugged cable.
> 
> I disagree. Consider the case where a laptop goes into standyby when
> connected. The correct behaviour on resume is to send notify
> userland that link is down and then link is back up only if one is
> currently connected. This could be a very small timewindow, but is
> the correct behaviour so the client can re-negoiate the correct
> information if it has changed network in the meantime.

This isn't what I am talking about. Suspend/resume involves an explicit
IF_DOWN/IF_UP cycle, so it doesn't matter here. I am talking about
ifconfig $nic $option with option not including down. This should IMHO
not trigger a link state message, even if e.g. setting promisc mode,
changing MTU or multicast filters require a PHY reset.

Joerg