Fedora Core1: dhcpcd fails to get IP address

[Runar Jørgensen]

Greetings

Recently I upgraded from RedHat 2.4.18 to Fedora Core1 (kernel 2.4.22).
Since then my 2.4.18 kernel still gets IP through DHCP client, but using kernel 2.4.22
fails to get proper IP through DHCP client. No change in the server.
I've compiled pcnet32 driver for the new kernel, it loads fine. I
have link (se below), HW is correct detected (se below), but still dhcpcd
fails to get IP both on boot and when I try /etc/sysconfig/network-scripts/ifup eth0.
Here what's in /var/log/messages

Apr 13 15:37:31 rujpc kernel: ip_tables: (C) 2000-2002 Netfilter core team
Apr 13 15:37:31 rujpc kernel: pcnet32.c:v1.27a 10.02.2002 tsbogend@alpha.franken.de
Apr 13 15:37:31 rujpc kernel: PCI: Found IRQ 11 for device 00:0e.0
Apr 13 15:37:31 rujpc kernel: pcnet32: PCnet/FAST+ 79C972 at 0xc400, 00 30 84 6c 64 d3
Apr 13 15:37:31 rujpc kernel: tx_start_pt(0x0c00):~220 bytes, BCR18(9861):BurstWrEn BurstRdEn NoUFlow
Apr 13 15:37:31 rujpc kernel: SRAMSIZE=0x1700, SRAM_BND=0x0800, assigned IRQ 11.
Apr 13 15:37:31 rujpc xinetd: xinetd startup succeeded
Apr 13 15:37:31 rujpc kernel: eth0: registered as PCnet/FAST+ 79C972
Apr 13 15:37:31 rujpc kernel: pcnet32: 1 cards_found.
.
.
.
Apr 13 16:10:11 rujpc dhcpcd[2238]: timed out waiting for a valid DHCP server response
Apr 13 16:18:44 rujpc dhcpcd[2300]: timed out waiting for a valid DHCP server response

Exactly same info in /var/log/dhcpd.log

If I try to do this manually

# ifup eth0

Determining IP information for eth0... failed.


Here's my installs
# rpm -qa|grep -i dhcp
dhcpcd-1.3.22pl1-7
dhcp-3.0pl2-6.16

Snip from /etc/sysconfig/hwconf
class: NETWORK
bus: PCI
detached: 0
device: eth0
driver: pcnet32
desc: "Advanced Micro Devices [AMD]|79c970 [PCnet32 LANCE]"
vendorId: 1022
deviceId: 2000
subVendorId: 1259
subDeviceId: 2450
pciType: 1
pcibus: 0
pcidev: e
pcifn: 0

snip from network info
# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:30:84:6C:64:D3

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:4720 (4.6 Kb)
Interrupt:11 Base address:0xc400

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:16 errors:0 dropped:0 overruns:0 frame:0
TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:1204 (1.1 Kb) TX bytes:1204 (1.1 Kb)

# service network status
Configured devices:
lo eth0 eth0.FAST_IP
Currently active devices:
lo eth0

# mii-tool eth0
eth0: 10 Mbit, half duplex, link ok
# ip link show
1: lo: mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
3: eth0: mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:30:84:6c:64:d3 brd ff:ff:ff:ff:ff:ff


Here's /sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
ONBOOT=yes
BOOTPROTO=dhcp

I've run, with debugging on in /etc/syslog.conf,
# /sbin/dhcpcd -d eth0
dhcpcd: MAC address = 00:30:84:6c:64:d3

And got in /var/log/dhcpcd.log
Apr 14 17:24:09 rujpc dhcpcd[2456]: broadcasting DHCP_REQUEST for 192.168.1.102
Apr 14 17:25:09 rujpc dhcpcd[2456]: timed out waiting for DHCP_ACK response
Apr 14 17:25:09 rujpc dhcpcd[2456]: broadcasting DHCP_DISCOVER
Apr 14 17:26:09 rujpc dhcpcd[2456]: timed out waiting for a valid DHCP server response

Nothing I can make anything out of. I think I have this version
# strings /sbin/dhcpcd |grep Daemon
DHCP Client Daemon v.1.3.22-pl1

I'm out of debugging/fixingoptions. Hopefully someone can point
me in the right direction. What am I missing to get this on the net
with the 2.4.22 kernel?

Regards,
Runar Jørgens

[U.SivaKumar_2]

Hi,

Have you tried stopping firewall ?.

#iptables -F

Give ifup command again.

regards,

U.SivaKumar.

[Runar Jørgensen]

Hello
Thnks for the tip. I'm not experienced at all with iptables so this is what I tried.

# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination
# iptables -F
# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

(Nothing's changed?). Then try to bring the network back up.

# ifup eth0

Determining IP information for eth0... failed.

Unfortunately Still no go.
Regards,
Runar Jørgens

[Alexander Chuzhoy]

Can you put another PC on the same HUB with the station trying to get it's IP from DHCP?

If so -open network monitor and that PC and see what's going on.
Generally to get IP fro mDHCP you should see 4 entries:
DHCP Discover
DHCP Offer
DHCP request
DHCP ack

Try to see where is the problem
Best regards

[Runar Jørgensen]

Hello

Unfortunately I don't have easy access to another PC nor a hub I can play with. Maybe tomorrow.

However, I did something else. I unplugged fiber to se if I gould get the net up with a dummy IP. Like this.

ifcfg-eth0:

DEVICE=eth0
IPADDRESS=160.160.1.123
NETMASK=255.255.255.0
NAME=eth0
ONBOOT=yes

# service network start
(All appears OK)

Guess what? Nothing! Not with ifconfig -a at least. No assigned IP address. Could it be something with the driver pcnet32 that I'm using?
How can I check that this driver is setup correctly?

Regards,
Runar Jørgensen

[Steven E. Protter]

Firewall seems likely a contributatory cause.

Also, if it works off the network and not on, there could be a conflict with another machine. PErhaps there are not enough dhcp leases on the network.

I think you plan is solid though and await further results.

SEP

[dirk dierickx]

isn't dhcpcd depreciated already for a long time? 'dhclient' is the prefered dhcp client now afaik.

[Jarle Bjorgeengen]

Correct Dirk,

and dhcpcd is not part of fedora, but dhclient is. dhcpcd must be remains from the old RedHat.

I think you need to uninstall dhcpcd, and install dhclient from fedora distro.

Rgds Jarle

[Runar Jørgensen]

Hello y'all

Thanks for all your suggestions. The tip on iptables helped me to get
CUPS going again yesterday. Only to discover today when I rebooted into
kernel 2.4.22 that the problem still persisted.


I followed up your suggestions regarding iptables. Actually when I had
a look yesterday I had both ipchains and iptables active at levels 2
through 5. I removed the ipchain packages and have now

# /sbin/service iptables status
Firewall is stopped.
# chkconfig --list iptables
iptables 0:off 1:off 2:off 3:off 4:off 5:off 6:off

I'm unfortunately not able to test against another PC and a HUB. I have
to see if I can fix this without.

I installed dhclient-3.0.1rc12-4. The 2.4.18 kernel still gets it
network info perfectly using dhclient, however the 2.4.22 kernel is still a
dud. I've got some info in /var/log/messages though.

Apr 16 11:03:03 rujpc kernel: ip_tables: (C) 2000-2002 Netfilter core team
Apr 16 11:03:04 rujpc dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
Apr 16 11:03:11 rujpc dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 15
Apr 16 11:03:26 rujpc dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
Apr 16 11:03:34 rujpc dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
Apr 16 11:03:42 rujpc dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9
Apr 16 11:03:51 rujpc dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 13
Apr 16 11:04:04 rujpc dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 1
Apr 16 11:04:05 rujpc dhclient: No DHCPOFFERS received.

I'm curious. Can this be a faulty configured kernel problem or a faulty
confgiured/compiled pcnet32 driver or something else?

Thanks for all your suggestions. Keep them coming.

Regards,
Runar Jørgens

[Greg Wojtak]

Is the mii-tool output matching what you're expecting? And are you using autonegotiation or forcing the speed and duplex of the NIC? I have seen this sort of behaviour from DHCP before when I have had mismatched speed/duplex settings (ie, one side is autonegotiating and the other is not). Can you also try giving it an IP manually and making sure that network traffic works that way, just to be sure the physical layer (hardware, cables) is good?

[Roberto Polli]

Did you check on internet if that kernel is ok? I'm not sure but i read somewhere that on fedora core 1.a some packages are faulty.
Try to get kernel from fedora core 1.c...
Maybe it helps.

Peace, R.

[Robert Binkhorst]

Hi Runar,

Three things I'd try in addition to the other suggestions:
1. Check that your modules are loaded correctly, do a lsmod under your old kernel, and check that they are still running with your new kernel (this sound like it's alright though, but you could be running a different module).
2. Check the startup parameters for your module in /etc/modules.conf, and try a couple of different options (make sure that the path is correct).
3. Check your routing table to see if your traffic is send somewhere.

HTH,

Robert

[Runar Jørgensen]

Hello

Sorry for the delay.

Let me start of with the reply to the output of mii-tool. I have no reason to suspect the output to be wrong.
# mii-tool -v eth0
eth0: 10 Mbit, half duplex, link ok
product info: AdHoc AH101LF rev 11
basic mode: 10 Mbit, half duplex
basic status: link ok
capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
advertising: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD

Am I forcing speed or autonegotiating. Ooops! I don't know. How can I check that?

I have earlier tried to set an IP manually, using ifcfg-eth0 file. (ref. earier in the log.)

About the kernel source: I'm not familiar with the terms fedora Core 1a and c. What I have is

kernel-utils-2.4-9.1.101.fedora
kernel-source-2.4.22-1.2115.nptl
kernel-2.4.22-1.2115.nptl
kernel-smp-2.4.22-1.2115.nptl

The things with modules is interessting. I'm sure lsmod gives same output. I also realize that some work needs to be done in /etc/modules.conf

This is what I have on my current driver:

alias eth0 pcnet32

No options. this seems to suffice for 2.4.18-kernel.

However, there is one issue here.
The stock pcnet32.c (ver. pcnet32.c:v1.25kf 26.9.1999 tsbogend@alpha.franken.dec)
did not support the use of fiber. The source was patched to support fiber. The current version is
#define DRV_NAME "pcnet32"
#define DRV_VERSION "1.27a"
#define DRV_RELDATE "10.02.2002"

From the changelog in the source I can't see if the fiber patch is included. Anyone know if there is a patch for the use of fiber. I found the patch at
http://www.lustt.org/projects.shtml, but this site is down.

I don't have access to a mediaconverter at the moment, so I need this to work on fiber.

[Martin P.J. Zinser]

Hi,

looks like a known bug to me. Check

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=85537

for details.

Greetings, Martin

[Roberto Polli]

Hi all,
"releases" of fedora are indexed by a couple:
NumberLetter; eg the first release is 1a, the there are patches/upgrades marked 1b and 1c, so
fedora 1c is the latest release of Fedora and the kernel is only on of the package.

I Think you can configure yum, upgrade all the package you need (dhclient ... and maybe the kernel), and then check if errors persist.
This should be a quick sol.

Peace, R.

[Runar Jørgensen]

Hello y'all

The 85537-bug at RedHat is known, I do agree. Some time ago I read through that bug and there are two main diffreneces.

With the 2.4.22 kernel I do get suspected info from both ethtool and mii-tool, but not when I'm using the 2.4.18 kernel (mii-tool crashes as reported in the bug, and ethtool reports "no available info"), but I do manage to negotiate an IP form the DHCP server with the 2.4.18 kernel.

The second main point of difference is that I'm not able to negotiate an IP nor can I establish a manual IP adress with the 2.4.22 kernel. So, I'm sorry to say that I don't think the bug #85537 applies to my case.

But thanks for the hint though.

About yum, I've tried up2date and it seems to work, I haven't tried yum. Doesn't seem to be installed on my system.

I had a look at the options list for pcnet32.c

/*
* table to translate option values from tulip
* to internal options
*/
static unsigned char options_mapping[] = {
PCNET32_PORT_ASEL, /* 0 Auto-select */
PCNET32_PORT_AUI, /* 1 BNC/AUI */
PCNET32_PORT_AUI, /* 2 AUI/BNC */
PCNET32_PORT_ASEL, /* 3 not supported */
PCNET32_PORT_10BT | PCNET32_PORT_FD, /* 4 10baseT-FD */
PCNET32_PORT_ASEL, /* 5 not supported */
PCNET32_PORT_ASEL, /* 6 not supported */
PCNET32_PORT_ASEL, /* 7 not supported */
PCNET32_PORT_ASEL, /* 8 not supported */
PCNET32_PORT_MII, /* 9 MII 10baseT */
PCNET32_PORT_MII | PCNET32_PORT_FD, /* 10 MII 10baseT-FD */
PCNET32_PORT_MII, /* 11 MII (autosel) */
PCNET32_PORT_10BT, /* 12 10BaseT */
PCNET32_PORT_MII | PCNET32_PORT_100, /* 13 MII 100BaseTx */
PCNET32_PORT_MII | PCNET32_PORT_100 | PCNET32_PORT_FD, /* 14 MII 100BaseTx-FD */
PCNET32_PORT_ASEL /* 15 not supported */
};

I was hoping to find an debugging option which was available in the older version. Is there anyone that recognizes any other of these options that I can use. It would be useful to see in more detail what the driver is actually doing.

Should I report a bug regarding the fiber connector not working? Where?

Regards,
Runar Jørgense

[Roberto Polli]

reporting bugs:
try
google: bugzilla fedora redhat
Pax,r

[mounterriver]

I have a similar problem in Fedora 2.
Everything works fine with the Fedora 1.90(FC2 test 1). The system is unable to determine IP......

[mounterriver]

someone say that there is a bug in the kuzdu. I
stopped kuzdu during startup and it works.

[Runar Jørgensen]

Greetings.

I'm really pleased that observations and proposals still are being submitted to this thread.

Mounterriver: Bug in kudzu you say. Hmm....
What version of kudzu do you use I'm using:

$ rpm -q kudzu
kudzu-1.1.36.1-1

Wouldn't a bug in kudzu also affect my
2.4.18 kernel?

Regards,
Runar Joergensen

[mounterriver]

Runar,I am using kudzu-1.1.62-1 comes with the fedora core 2.If your system configuration is stable, just disable kudzu. In my case, it brings up the network. It is not likely a bug in the kernel, because I have upgraded my kernel to 2.6.6 because of the nvidia graphical acceleration card driver problem.

[mounterriver]

RunarForget to mention that you are using kernel 2.4.22 fedora core 1. Then it might also be a bug in the kernel. try to disable the kudzu first and see whether it brings up the network. The bug in fedora core 2 affects the dhcp using some 3com nic.