From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030 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;/' > /etc/dhclient-eth0.conf 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 : http://www.isc.org/ml-archives/dhcp-server/2000/12/msg00152.html http://stuwww.kub.nl/people/b.vannunen/linux-man12.php3 http://www.linuxvalley.it/encyclopedia/ldp/howto/HOWTO/mini/DHCP/x74.html Version-Release number of selected component (if applicable): /etc/dhclient-eth0.conf needs dhcp-client-identifier How reproducible: Always 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 : busybox-anaconda-0.60.5-6 anaconda-images-9.2-3 anaconda-9.2-2 anaconda-help-9.2-1 anaconda-runtime-9.2-2 kernel: 2.4.22-1.2115.nptl
Reporter writes > Can you please advise me if this is fixed, or how to > get a bugfix integrated, in Fedora/Redhat XXX ?
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\"" >> /etc/dhclient-eth0.conf But getting it added by default would be a very nice addition to both RedHat Enterprise and Fedora Core (As both are used here).
Same bug in Fedora Core3 test3, same workaround applies.
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 option.
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.
(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.)
Moving this to target from Blocker.
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.