Re: Netconfig Fail

Ray Olszewski
2005-10-07T05:49:48Z

OK, Peter. Thanks for the added detail. I see one interesting thing.

Peter wrote:
[...]
> broadcasting DHCP_REQUEST for 192.169.231.250
> Oct 7 07:58:11 Peter dhcpcd[2293]: timed out waiting for DHCP_ACK response
> Oct 7 07:58:11 Peter dhcpcd[2293]: broadcasting DHCP_DISCOVER
>
> whereas when I still could connect with onboard LAN card:
>
> DHCP_ACK received from (192.169.224.1)
> Oct 2 12:17:51 localhost dhcpcd[104]: sending DHCP_REQUEST for 192.169.232.12
> to 192.169.224.1

In the first entry, Slackware's dhcpcd is asking any DHCP server to
assign to it IP address 192.169.231.250. In principle this is OK;
normally, it would mean that the system has previously received this
address assignment and wants to get the same address again. (My LAN
machines, the ones on DHCP that is, do this same thing when they renew
addresses.) When it gets no response, it then asks (the DHCP_DISCOVER)
for any DHCP server to respond as available to give *any* addresses. You
don't quote what happens next, but I'm guessing it's another "timed out
waiting" message ... maybe several, since DHCP clients are normally very
persistent in looking for servers.

But the second (on-mobo NIC) part of the report identifies a *different*
DHCP server as the one it is getting an acknowledgment from. (Am I
correct in assuming this is also from a Slackware log, BTW?)

To figure out what is going on, you want to look at other stuff that is
near these messages but that you didn't quote to us in your reply.

In the on-mobo-NIC case, look before what you sent us to see if the DHCP
client there is sending DHCP_REQUEST to 192.169.224.1 or if the
DHCP_ACK here is a response to a DHCP_DISCOVER.

In the PCI-NIC case, first check the timestamp you left off the first
(DHCP_REQUEST) message to see if it is far enough before 07:58:11 to
observe the time lag you see. Then see if anything is logged in response
to the DHCP_DISCOVER message that dhcpcd sends out.

Then check for corresponding log entries in the Fedora and DSL runs, to
see how they are actually finding their DHCP servers.

Then, using some version of your setup that gets an IP address, find out
if the DHCP server Slackware wants to use is ping'able.

The core of your problem is that in the Slackware case, you don't get a
response to a DHCP_DISCOVER message ... which would be a DHCP server
identifying itself to you as a source of address assignments.

Why this happens depends in part on what you find when you check the
things I mention above.

One other thing. You wrote:

> nd in fedora4 w/o -a flag. Note the second line missing in slack.
>
> eth1 Link encap:Ethernet HWaddr 00:08:A1:8C:44:5A
> inet addr:192.169.232.15 Bcast:192.169.255.255 Mask:255.255.224.0
> inet6 addr: fe80::208:a1ff:fe8c:445a/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:145 errors:0 dropped:0 overruns:0 frame:0
> TX packets:136 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:26493 (25.8 KiB) TX bytes:11880 (11.6 KiB)
> Interrupt:10 Base address:0xec00

What is interesting to me is not that the second line is present (it is
what I would expect, the difference between a configured and an
unconfigured interface), but that Fedora thinks your pci NIC is eth1,
not eth0. Does that version have an eth0 (it must; use the -a flag to
find out about it)? What is it? Can we see its ifconfig -a report?

I really don't know what this difference means, but it does make me
doubt whether the two cases (Fedora and Slack) are really the same in
*all* respects other than the choice of distro.

Oh yes, last thing. In Slackware, you report:

> This is in slackware
> /sbin/ifconfig -a
> eth0 Link encap:Ethernet HWaddr 00:08:A1:8C:44:5A
> BROADCAST MULTICAST MTU:1500 Metric:1
> RX packets:12 errors:0 dropped:0 overruns:0 frame:0
> TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:1000
> RX bytes:1896 (1.8 Kb) TX bytes:4720 (4.6 Kb)
> Interrupt:10 Base address:0xec00

Note there are RX packets and bytes, so the system is receiving
something, on a guess some response to its broadcast packets. In the
worst case, run a sniffer (ethereal, tcpdump) on the system while trying
to get a DHCP assignment.