Port-i386 archive

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

Re: 6.0.1 upgrade dhcp problem

On 05/02/2013 13:43, Thor Lancelot Simon wrote:
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?


So what should we do when wanting to detect valid carrier lost changes while changing the MTU?

>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.

The absence of MTU implies the driver default is fine.
So consider the use case of a laptop changing to network A which wants 1492 and then to network B which has no MTU value set. Can we make the assumption that 1492 will work on network B? Should we force 1500 on the driver?

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.

I can easily add code not to ask for an MTU change if it's the same, but surprised a driver that forces PHY reset doesn't check either.



Home | Main Index | Thread Index | Old Index