Re: 6.0.1 upgrade dhcp problem

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

    Date:        Tue, 5 Feb 2013 21:20:02 +1000
    From:        Ray Phillips <r.phillips%uq.edu.au@localhost>
    Message-ID:  <p05200f16cd36772e1a66@[192.168.37.112]>

  | However, I mustn't have tried configuring sk0 in the problem PC with the 
  | non-serial-console CD because when I tried it today it worked fine.

That's odd, I unless there is a power supply issue (com ports use power
to transmit, video just uses power all the time...) i would not expect
that which boot blocks you are using, or where the console is directed
would make any difference (it isn't as if there are any kernel printfs
happening at the relevant times, so we don't even have timing differences
as a hypothesis.)

It also seems that the sk config using dhcpcd might sometimes work, but
usually fails - and we do not yet have a reliable way to know which to
expect on any particular boot.   Is that a reasonable assessment of the
current results?

It is also interesting to note, that as I read its code, the sk driver
never resets for a MTU change - when it gets ENETRESET from ether_ioctl()
in only does anything special if the ioctl command was manipulating the
multicast address sets (SIOCADDMULTI & SIOCDELMULTI ioctls).

So, if the issue was MTU, the sk driver should be immune - but it isn't.

  | Continuing on with replies to your suggestions...
  | 
  | I can't replace the power supply in the problem PC; its a small form 
  | factor box and I don't have a spare.

Even with what I wrote just above, I do not really believe it would
make a difference as if the power supply was marginal, you'd probably
be seeing other problems, and in any case, carrier wouldn't only be
going away just as dhcpcd is configuring, and not any other time.

  | Using dhcpcd's -K switch worked (without attempting to configure the 
  | NICs from sysinst's menu first):
  | 
  | dhcpcd[47]: fxp0: leased 192.168.36.135 for 604800 seconds
  | dhcpcd[47]: forked to background, child pid 52
  | # ifconfig fxp0
  | fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500

I note there that the MTU set is 1500.   That is what it would be if
no MTU was being configured.   This suggests that the DHCP server that
dhcpcd is actually willing to listen to, is not attempting to configure
some strange mtu - if it is sending the option to set it to 1500, that
should be a no-op (if the analysis in my previous message is correct)
as that would be a no change, so no reset type operation.

  | Sorry this has dragged on for so long.  Thanks for your tenacity. 
  | It's looking like sticking with dhclient might be the best solution 
  | for this machine.

Perhaps, though we know now that dhcpcd can be made to configure the
network (with -K) so you could certainly use it that way - and even better,
if Roy's suggestion

        dhcpcd --nohook mtu fxp0

happens to work, that would be an even better solution.   For most practical
uses, dhcpcd is a better client to use than dhclient (the one notable
exception is when your purpose is to test, or even more, stress test, a
dhcp server or its configuration, but that's not a common use.)

I'm not sure that the MTU config is the actual problem however (that usage
would provide valuable evidence) - it could be something else that we
haven't thought of yet that is causing the problem.

kre