Re: 6.0.1 upgrade dhcp problem

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

    Date:        Thu, 7 Feb 2013 18:21:36 +1000
    From:        Ray Phillips <r.phillips%uq.edu.au@localhost>
    Message-ID:  <p05200f1ccd390edd09ad@[192.168.37.112]>

You didn't cc Roy on your message - I forwarded a copy to him - as this
all involves dhcpcd we should probably keep seeking his input.

  | / isn't writeable but other partitions are:

OK, that all looks fine, and I understand why -U fails now, so this
one is no longer a mystery.


  | I tried dhcpcd's -U switch before attempting to configure the NIC, 
  | just to see what it'd say:
  | 
  | # dhcpcd -U fxp0
  | dhcpcd[55]: fxp0: no lease to dump

That's what it should do.

  | # dhcpcd --nohook mtu fxp0
  | dhcpcd[57]: version 5.5.4 starting
  | dhcpcd[57]: Kernel is not configured to accept IPv6 RAs
  | dhcpcd[57]: fxp0: carrier acquired
  | dhcpcd[57]: fxp0: carrier lost
  | dhcpcd[57]: fxp0: waiting for carrier
  | dhcpcd[57]: fxp0: carrier acquired
  | dhcpcd[57]: fxp0: broadcasting for a lease
  | dhcpcd[57]: fxp0: offered 192.168.36.135 from 192.168.36.24
  | dhcpcd[57]: fxp0: ignoring offer of 192.168.36.135 from 192.168.36.1
  | dhcpcd[57]: fxp0: acknowledged 192.168.36.135 from 192.168.36.1

This time I finally looked at that (rather than just seeing the addresses
were there and looked reasonable) - note that there are offers from
192.168.36.24 and 192.168.36.1, which from your configuration is what
we expect to happen, dhcpcd claims to be ignoring the offer from 192.168.36.1
but then ack's that offer ???

Roy - is this just a case of printf error, or is there some real bug there?

I don't see how this can really be an explanation for what is happening
to your config, but I also don't know the code inside dhcpcd.

  | dhcpcd[57]: fxp0: checking for 192.168.36.135
  | dhcpcd[57]: fxp0: leased 192.168.36.135 for 604800 seconds
  | dhcpcd[57]: forked to background, child pid 60
  | #
  | # ifconfig fxp0
  | fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
  |          capabilities=1400<TCP4CSUM_Rx,UDP4CSUM_Rx>
  |          enabled=0
  |          address: 00:10:dc:7b:92:a9
  |          media: Ethernet autoselect (100baseTX full-duplex)
  |          status: active
  |          inet6 fe80::210:dcff:fe7b:92a9%fxp0 prefixlen 64 scopeid 0x3

That ifconfig must have been delayed a little more than some of yourother 
examples, as carrier has returned in this one - it is fairly clear that
it had been lost, as all the interface config has gone.

  | This created some files in /var and /tmp:

Sorry about sending you on that wild goose chase...

  | But dhcpcd -U still didn't give any output:
  | 
  | # dhcpcd -U fxp0

It turns out that is expected with the way dhcpcd is set up on the
install media - the -U option is implemented by running the
dhcpcd-hooks/02-dump script, but the NetBSD sysinst (boot CD)
image doesn't include that one, so there is nothing to actually
produce any output.

Instead it includes 99-print-sysinst which is what creates the
/tmp/dhcpcd-lease* files (normally dhcpcd doesn't leave dregs in /tmp)

  | # cat /tmp/dhcpcd-lease
  | 
  | Is that what `dhcpcd -U fxp0' was intended to display?

It is a superset - with -U (the 02-dump script) only some of that info
would be printed (and it would be sorted - I'd guess that the reason the
script is not present is that the sort program is also not present).
If it were under my control, I'd either make a new 02-dump script, without
the sort (which is just to improve the human interface) or a dummy sort
program (script) that was just "cat" (though that may end up confusing
people who come across it in other contexts).

Right now I have no more suggestions on what to try (or rather, what
I wold do next would require buiding new boot images with diagnostics
added to the fxp driver, and perhaps more in dhcpcd, to try and work out
just what operation causes the interface reset.)  Perhaps someone else
might have some other idea.

kre