Re: 6.0.1 upgrade dhcp problem

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Tue, 05 Feb 2013 16:42:53 +0000
    From:        Roy Marples <roy%marples.name@localhost>
    Message-ID:  <19fc219de358c434e2ea29c8fff93478%mail.marples.name@localhost>

  | We can modify the script to check this variable vs the new mtu before 
  | calling ifconfig - this check does not take place and I'm a little 
  | surprised it needs to be done.

I reasonably sure it does not - and what none of this recent discussion
explains is how on two systems, both with Intel ethernet (fxp driver)
both using NetBSD 6.0.1, both booting off the same CD, both configuring
the net with dhcpcd, one of them fails with carrier problems, and the
other does not.

It is certainly possible that there's something going on with MTU settings
that is causing that - but we do not yet have any actual evidence to
support that, and it is hard to explain why this would affect one of the
two systems an not the other one.

Further, everyone seems to be guessing as to what the code does, as best
I can tell, at least the intent of the current code, is that the drivers
will not re-init the hardware when the mtu is set, if the value does not
change (so adding code to the script to avoid configuring an unchanged mtu
doesn't seem as if it should have any effect).

That is, after an ioctl, the fxp driver does a reset if ether_ioctl
returns ENETRESET (and only then).

In the case of SIOCSIFMTU ether_ioctl() returns ENETRESET only if 
ifioctl_common() returns ENETRESET (at least as I read the code).

ifioctl_common() code for SIOCSIFMTU is

        case SIOCSIFMTU:
                ifr = data;
                if (ifp->if_mtu == ifr->ifr_mtu)
                        break;
                ifp->if_mtu = ifr->ifr_mtu;
                /*
                 * If the link MTU changed, do network layer specific procedure.
                 */
#ifdef INET6            
                nd6_setmtu(ifp);
#endif
                return ENETRESET;

(the "break" drops through to "return 0;".)

That is, if the mtu is not being changed, do nothing.  If it is being changed,
ENETRESET, which will cause the fxp driver to re-init.

Aside from being able to forget all the stuff about not doing the ifconfig
from dhcpcd's script if the mtu is not actually changing, this also tells
me (or at least strongly suggests) that the comments about "some drivers"
do a reset is only marginally true - the fxp driver in particular has no
idea why the ioctl() common routine is returning ENETRESET,  there's no
consideration at all as to whether the intel chips actually need a reset
to make a change to the MTU (aside from possibly if vlans are being enabled
and so the hardware needs to allow the extra 4 bytes, my rough reading of
the driver code suggests no, as the actual MTU value configured never seems
to be communicated to the chip, so I cannot imagine why resetting it would
achieve anything).   My guess is that most drivers are now this way (not that
they fail to communicate the mtu to their hardware, of that I have no idea,
but that they really have no clue whether or not a reset is actually useful,
and simply do one when ENETRESET says they should - it most probably got
like this when all the common code was yanked from the drivers.

Unfortunately, a simple ENETRESET from a generic routine that has no idea
at all whether a reset is needed, just that something that may affect
interface hardware config has changed, being passed back to a driver that
has no idea what has changed, just that some other code believes a chip
re-init might be required, is a recipe for way over-conservative programming,
where almost every change does a reset.    This just cannot be the right way.

That said, we should probably stop assuming that we have found the cause of
the problem until we actually have some evidence to support that, and
whatever that is, needs to explain why one system, with an fxp is having
the problem, whereas another also with an fxp, is not.

kre