Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 113260 - On fedora no /etc/dhclient-eth0.conf produced, while windows-compatible config is easily generated
Summary: On fedora no /etc/dhclient-eth0.conf produced, while windows-compatible confi...
Alias: None
Product: Fedora
Classification: Fedora
Component: dhcp
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: David Cantrell
QA Contact:
Depends On:
Blocks: 171491 FC6Target
TreeView+ depends on / blocked
Reported: 2004-01-11 14:13 UTC by Stef Van Vlierberghe
Modified: 2007-11-30 22:10 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2007-01-31 16:13:08 UTC

Attachments (Terms of Use)

Description Stef Van Vlierberghe 2004-01-11 14:13:40 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)

Description of problem:
Risk to "look bad" compared to M$S (95/98/98SE/ME/2000/XP) due to DHCP
config problem, which could be solved if anaconda were to configure
dhclient to send a client-identifier containing a byte 1 followed by
interface HWaddr, as could be done with following bash command :

ifconfig eth0 | 
grep  HWaddr | 
sed -e 's/^.*HWaddr \(.*\)$/send dhcp-client-identifier 01:\1;/' >

Had this problem also in Redhat 7,8 and 9, understood it using Fedora.

Using a dual-boot Windows/Linux I experienced for years that switching
Linux->Windows would always work, while switching Windows->Linux would
always fail to start up Networking. By monitoring the network using
ethereal on a separate computer I discovered that Windows sends a
client-identifier option in the DHCP DISCOVER message, and the effect
of this is that Linux won't get a DHCP lease unless it also sends the
same client identifier.

Since years I used a workaround : type ipconfig /release in windows
before shutdown and boot Linux. This has many problems (often
forgotten, need to reboot windows to retry, XP requires Admin rights
to do it so when the children switch off XP I can choose between
giving them Admin rights on XP or get Linux boot with network failure).

The problem doesn't seem a technical challenge, it is mainly
problematic because non-expert users will need days, months or years
to figure out what to do to get rid of the annoying symptom.

Problem is also described in :

Version-Release number of selected component (if applicable):
/etc/dhclient-eth0.conf needs dhcp-client-identifier

How reproducible:

Steps to Reproduce:
1. service network start -> FAILED
2. command in report to create config
3. service network start -> OK

Actual Results:  I am now in a state of happiness and wish the same
for those still grinding their teeth.

Expected Results:  I wish that when I install the next fedora version,
the dhcp connect will work out-of-the-box.

Additional info:

anacondaks.cfg contains "network --device eth0 --bootproto dhcp"

package versions :

kernel: 2.4.22-1.2115.nptl

Comment 1 Mike McLean 2004-03-24 02:27:29 UTC
Reporter writes
> Can you please advise me if this is fixed, or how to
> get a bugfix integrated, in Fedora/Redhat XXX ? 

Comment 2 Mitch 2004-06-14 20:24:05 UTC
making it so the dhclient also sends "Red Hat Enterprise Linux/Fedora
Core Linux" as the vendor class identifier would also be use full(or
something like it).

I've been telling my users to type this as root: 

echo "send vendor-class-identifier \"Red Hat Linux\"" >>

But getting it added by default would be a very nice addition to both
RedHat Enterprise and Fedora Core (As both are used here).  

Comment 3 Stef Van Vlierberghe 2004-11-28 15:58:52 UTC
Same bug in Fedora Core3 test3, same workaround applies.

Comment 5 Jason Vas Dias 2006-03-07 22:31:49 UTC
All users have to do is set the DHCP_HOSTNAME variable in the network scripts
environment, and then the dhclient-${interface}.conf script will be set up
correctly to send the host-name dhcp option.
Yes, it would be nice if system-config-network could configure this with the GUI -
but the mechanism is in place for it to work.
NOTE: correctly set up dhcp servers should be set up to do the DDNS update 
      themselves automatically, not requiring clients to send the host-name

Comment 7 Jason Vas Dias 2006-03-07 23:08:21 UTC
Perhaps this bug should be closed - it is possible to set up.

The original point of the bug was that dhclient does not send a dhclient
identifier with a '1' byte preceding it - sorry I misread it initially.

This also can be easily set up in the network scripts, now that dhclient 
supports a -I 'dhcp-client-identifier' option - you could make this setting
in /etc/sysconfig/network-scripts/ifcfg-ethX :

DHCLIENTARGS=-I' 01:'`ip link show $interface | sed -n '/link\/ether/{s/^.*ether
//;s/\ .*$//;p}'
Then dhclient would send the dhclient identifier of 01: followed by the
ethernet address. 

This is purely a peculiarity of Windows DHCP servers that contravenes the 
DHCP RFCs that they need the 01: byte preceding a dhcp-client-identifier
option to use the ethernet address - RFC conformant dhcp servers simply
use the ethernet address if no dhcp-client-identifier option is specified.

Using a 'vendor-class-identifier' is entirely dependant on the site
specific dhcp server configuration , but also can be easily set up
in dhclient-${interface}.conf .

dhclient also now uses a global 'dhclient.conf', which will take effect
if no 'dhclient-${interface}.conf' exists - the 'vendor-class-identifier'
setting could go in there.

In short, I think we provide enough mechanisms to enable users to customize
dhclient operation; it is up to users to use them to implement site specific
policy. So I think this bug can probably be closed.

Comment 8 Miloslav Trmač 2006-03-07 23:15:39 UTC
(Just a small note: writing shell constructs like that in ifcfg-* will probably
break badly once s-c-network or other tools attempt to edit the files.)

Comment 9 Jesse Keating 2006-08-18 01:38:25 UTC
Moving this to target from Blocker.

Comment 10 David Cantrell 2007-01-31 16:13:08 UTC
Workaround exists for this as noted in comment #7 using the -I switch for
dhclient.  It's Windows-specific, so it shouldn't be the default for all systems.

Regarding vendor-class-identifier and anaconda, we now send the string
'anaconda-SYSNAME RELEASE MACHINE' as obtained from uname(2).  An example string
is: anaconda-Linux 2.6.19-1.2895.fc6 i686

Closing this bug.

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