Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 145849 - ifup behaves incorrectly when mii-tool can't determine link status
ifup behaves incorrectly when mii-tool can't determine link status
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: initscripts (Show other bugs)
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Bill Nottingham
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2005-01-22 05:52 EST by Wouter Liefting
Modified: 2014-03-16 22:52 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-01-25 01:00:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Wouter Liefting 2005-01-22 05:52:48 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.3)
Gecko/20050104 Red Hat/1.4.3-3.0.7

Description of problem:
When mii-tool is correctly able to determine the link status of an
interface, all is well: when the link is ok, dhclient is started, when
link is not ok, [failed] is shown. However, when mii-tool is not able
to determine the link status (because either mii-tool does not support
the network adapter, or because the network adapter does not support
this), the scripts automatically assume that there's no link and will
not start dhclient.

This is particularly annoying for me because the emulated ethernet
adapter in VMWare (when running RHEL3 as guest OS) has not implemented
link state checking functionality (link is always on, after all).

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Install RHEL3 under VMWare with DHCP
2. Reboot

Actual Results:  Does not get an IP address, does not start dhclient

Expected Results:  Should get an IP address

Additional info:

Simple fix, but a little more scripting might be required for
production use:

File /etc/sysconfig/network-scripts/network-functions: Line 237-238
now reads:

  echo $output | LC_ALL=C grep -q "link ok" && return 1
  echo $output | LC_ALL=C grep -q "no link" && return 0 || return 2

Change this to:

  echo $output | LC_ALL=C grep -q "link ok" && return 1
  echo $output | LC_ALL=C grep -q "no link" && return 0 || return 1

and all is well.
Comment 1 Bill Nottingham 2005-01-25 01:00:29 EST
Your change means 'assume the link is up in case mii-tool fails to
determine link status one way or another'.

This is a change of behavior and is actually incorrect.

The current algorithm:
- returns link up if *either* mii-tool or ethtool report link up
- returns link up if *both* mii-tool and ethtool report that they're
  unable to check

What your change will do will cause it to return the link as up,
if, for example, ethtool claims 'link down' and mii-tool claims
"I don't know". That's not correct.
Comment 2 Wouter Liefting 2005-01-25 07:00:41 EST
Somehow behaviour was only present when using the original RHEL3,
unupdated. An update somewhere along the line has fixed this. I should
have tested this on an updated system.

Sorry for wasting everybodies time.

Note You need to log in before you can comment on or make changes to this bug.