Re: 6.0.1 upgrade dhcp problem

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Tue, Feb 05, 2013 at 01:28:01PM +0000, Roy Marples wrote:
> On 05/02/2013 12:59, Thor Lancelot Simon wrote:
> 
> Really? I was under the impression MTU was purely a software thing.
> But then I'm no driver expert.

Lots of hardware (particularly old hardware) rejects oversized packets.
To be told size-to-reject is larger than it used to be, on some particularly
dumb hardware, requires a much fuller reset than one would like.

> Is there anyway of knowing this from userland?

No.

> >If the MTU is being "changed" to the default, can't dhcpcd leave it
> >alone?  Or is that already the case, and on this network, can we thus
> >assume the MTU is not 1500?
> 
> The problem here is when the link is lost, dhcpcd restores the MTU
> to the prior value.

So, don't do that!  Simple enough, no?  Why not leave the MTU entirely
alone unless one receives an MTU from the server which is different from
that already configured on the interface?  At least, look at what it is
already and skip changing it when you can.

If the link comes back up and has a different MTU, then obviously an
MTU change is unavoidable.  But changing it to the "prior value" just
so it can in all likelihood be changed to the "current value" -- since
both are 1500 almost all of the time -- seems like a very bad idea.

Thor