Known bug since at least Red Hat 9. Have a look at the knowledge base at 
www.vmware.com and search for DHCP. Article nr. 977 explains a workaround. 

This sounds like a vmware issue in that it's not reporting link status properly.

According to

http://www.vmware.com/support/guestnotes/doc/guestos_redhat90.html

here copy & paste:

Getting a DHCP Address in a Red Hat Linux 9.0 Virtual Machine 

When a Red Hat Linux 9.0 guest operating system tries to get a DHCP address, the attempt may fail 
with an error message that states the link is down. On ESX Server, this happens only if you are using the 
vlance driver for your network connection. 

To work around this problem, become root (su -) and use a text editor to edit the following files in the 
guest operating system. If only one of these files exist, make the change for that file only. 

/etc/sysconfig/network-scripts/ifcfg-eth[n] 

/etc/sysconfig/networking/devices/ifcfg-eth[n] 

In both cases, [n] is the number of the Ethernet adapter - for example, eth0. 

Add the following section to each of these two files: 

check_link_down () { 

return 1; 

} 

Exactly; they're removing the test completely; apparently their vlance driver
doesn't report link state right.

No. pcnet32 kernel driver reports on link on any AMD network device without MII.
Get physical Amd79C970A and watch same error report.

Take a look at the driver. pcnet32_ioctl calls pcnet32_ethtool_ioctl for
SIOCETHTOOL. pcnet32_ethtool_ioctl calls mii_link_ok for ETHTOOL_GLINK.
mii_link_ok calls mii->mdio_read and checks whether BMSR_LSTATUS set. pcnet32's
mdio_read always returns 0 for mii-less devices (if (!lp->mii) return 0);

So driver incorrectly reports no link. Two fixes possible: either properly
implement link status for non-mii case (find whether one of BCR LED registers is
set to track link status, and then read this LED value) or make this ioctl call
returning an error.

Unfortunately I cannot reopen the bug. But it does not change that it is bug in
the kernel, and not in the VMware.

Reopening then; kernel does sound appropriate.

Still the same on kernel used by Fedora Core 1: 2.4.22-1.2115.nptl

How is this different from:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=104711

Some solutions are suggested there.

104711 is newer, and so should be closed as a duplicate. Besides that 
I do not think that we should paper over the pcnet32 driver bug in 
initscript (as 104711 suggests), instead of fixing bug in the kernel.

*** Bug 111683 has been marked as a duplicate of this bug. ***

FYI, I built 2.6.0-test11 to test and got the same "no link" when 
running against a modified Fedora Core 1.

Any suggestions to getting this moved to the kernel list?

Sorry, I see that is it in the kernel component, but I did not see 
anything related on bugzilla.kernel.org.  I was not sure which is 
more appropriate.  

This bug is still not fixed in kernel-2.4.22-1.2166.

Created attachment 97831 [details]
fix proposal

fixes pcnet32_ethtool_ioctl function to only rely on result from mii_link_ok()
when mii is actually available. In cases where mii is not available, assume
link is okay as this is the only way we're ever going to get this working!!!

Please try it out and let me know if it is usable! If it is, i'll try to get it
submitted upstream!

It looks as if it has been a while since anyone touched that driver,
so theres a good chance it'll work on earlier versions (including 2.4)
as well... This fix was tested on kernel 2.6.2-1.87 and only under
VMware, where it works!

What's that binary garbage patch attachment?

Thats a gzipped patch file... the only reason i gzipped it was because
I had to move it across some windows boxes and wanted to make sure i
didn't get any encoding problems (just as a safety precaution) sorry
for the inconvenience - I should have added that to the description!

I've created a second version of the patch for this problem!

I've send it to maintainer and am awaiting some comments...

The new version will actually detect link on the device and does not
just assume that the link is up!

Tested with kernel 2.6.2-1.87 under VMware and is working like a charm!

Created attachment 97917 [details]
updated version of the previously submitted patch!

please note that this patch was made against pcnet32.c taken from 2.6.3-bk3
kernel snapshot.

will do proper link detection even on devices that is not mii-capable!

patch tested/accepted by upstream maintainer(brazilnut.com). it
should be included in 2.6.3-bk9 from www.kernel.org. I don't know
about the 2.4 kernel although maintainer submitted for 2.4 as well!

Fixed in rawhide kernel 2.6.3-1.116 - tested and works here

This bug can be closed.

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=104711 is a dupe.

The fix is in vanilla kernel trees for both 2.4 and 2.6 and has been
for a while, please just close this bug

*** Bug 115598 has been marked as a duplicate of this bug. ***

Reopening and changing product to RHEL3, so we can track this for the
next QU.

I'm getting this bug in RHEL 3 AS U3. I've traced the problem to the 
check_link_down function defined in /etc/sysconfig/network-
scripts/network-functions file. It has something to do with 
check_mii_tool or check_ethtool. Serendipitously, I found that if I 
run check_link_down twice, it succeeds the second time. I don't know 
what this means, but I hope it provides a clue to the developer. This 
seems to be the basis of VMWare's workaround. Before I saw their 
solution, I solved it by adding a preceding call to check_link_down 
in /sbin/ifup. This works, but it is a pain because it is an extra 
step in installing a whole lot of RHEL 3 boxes. This is my 
modification to /sbin/ifup:
From:
if check_link_down ${DEVICE}; then
    echo $" failed; no link present. Check cable?"
    if link set dev ${DEVICE} down >/dev/null 2>&1
    exit 1
fi

To:

check_link_down ${DEVICE}
if check_link_down ${DEVICE}; then
    echo $" failed; no link present. Check cable?"
    if link set dev ${DEVICE} down >/dev/null 2>&1
    exit 1
fi

Andrew Robinson

The fix is made to the kernel. However i'm not sure if Red Hat has
backported the fix to the latest RHEL3AS kernel...

A fix for this problem has just been committed to the RHEL3 U4
patch pool this evening (in kernel version 2.4.21-20.10.EL).

An errata has been issued which should help the problem 
described in this bug report. This report is therefore being 
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files, 
please follow the link below. You may reopen this bug report 
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2004-550.html

*** Bug 154106 has been marked as a duplicate of this bug. ***