tech-net archive

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

Re: Retiring dhclient

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

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.

Better behaviour would be to mark these faulty drivers as not having working link detection as my marking it down then up during a simple MTU change is clearly broken in my eyes. Basically they should not set IFM_AVALID.



Home | Main Index | Thread Index | Old Index