Description of problem: The package dhcpcd is not available in Red Hat Enterprise Linux 3.0 on s390, but was present in the previous s390 release (Red Hat Linux 7.2). I have seen other bug reports that imply that dhclient became the 'default' DHCP client in RH 8.0. However, dhclient does not provide required support for s390 (specifically, the ability to request a broadcast reply from the DHCP server, required when using DHCP over z/VM Guest LANs). Either dhclient needs modification to support a request for a broadcast response (as defined in RFC2131, section 4.1), or dhcpcd needs to be made available for s390 (and installed in preference to dhclient). Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Try to install dhcpcd from install media OR 2. Try to configure a Guest LAN interface using DHCP Actual Results: 1. Package not found OR 2. Interface configuration fails (dhclient used as DHCP client) Expected Results: 1. Package found and installed OR 2. Interface configuration successful (dhcpcd used as DHCP client) Additional info: I accept that dhclient *should* be the preferred DHCP client, as it is supposed to be the "reference implementation" (from the ISC website). However, since it does not provide the required function as defined in the relevant RFC, an alternative needs to be made available.
Florian do you have a comment on this bug report? Dan
- RFC 1542 contains the following text: DISCUSSION: This addition to the protocol is a workaround for old host implementations. Such implementations SHOULD be modified so that they may receive unicast BOOTREPLY messages, thus making use of this workaround unnecessary. In general, the use of this mechanism is discouraged. - The cited RFC mentions "SHOULD" to detect this case and request a broadcast reply, so it is not a "MUST" requirement. - I assume the virtual guest LAN does not provide different "hardware adresses" to send packets to the different guests and that's the reason we have to send a broadcast reply in this case. Is this true? What is the output from "ifconfig" from at least two such Linux guests? How can this "no hardware addresses available" case be detected? (This should get fixed on the server side and maybe also on the client side as well.) - If different hardware addresses are available then things should work fine and I'd assume a Linux dhcp server to work fine for this setup. - dhcp could anyway be changed to allow requesting a broadcast reply. greetings, Florian La Roche
Google did show the following: MAC are available, but you might need a fixed z/VM to get them correctly or need kernel driver fixes to correctly query your MAC: http://www.mail-archive.com/linux-390@vm.marist.edu/msg18357.html So I assume this to be either a z/VM or a kernel driver issue to solve, not a dhcp client/server issue. greetings, Florian La Roche
z/VM is updated as required (the function worked with our RH 7.2 guests in the same z/VM system). Also, the driver updates required are present in the kernel patches for 2.4.21. The fixes you are referring to were made simply to get MAC addresses available; the following ifconfig output shows that we can see the MAC address: eth0 Link encap:Ethernet HWaddr 00:04:AC:00:00:0D inet addr:10.1.10.29 Bcast:10.1.10.255 Mask:255.255.255.0 UP BROADCAST RUNNING MTU:1492 Metric:1 RX packets:262 errors:0 dropped:0 overruns:0 frame:0 TX packets:186 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:23050 (22.5 Kb) TX bytes:31048 (30.3 Kb) Interrupt:3 The IBM redpaper you can find at http://www.redbooks.ibm.com/abstracts/redp3596.html has more information about this. You are correct, there is support missing from the z/VM Guest LAN (specifically, MAC unicast: the MAC addresses provided to the driver are for visual representation only, and allow the DHCP server to keep track of leases), but we do not know what timetable (if any) there is to include this support in Guest LAN. Broadcast reply provides a functional workaround to Guest LAN's lack of MAC unicast, exactly as the DHCP RFC allows for. Our guest cloning process currently relies on DHCP, so we face having to redesign and rewrite it just for RHEL 3.0... Cheers, Vic Cross
The above .pdf states this: - MAC addresses are available for Guest LAN - you are not guaranteed to get the same MAC address between multiple boots (which might limit the usefulness for some setups ;-) - MAC unicasts don't work. Not supporting MAC unicast is the real bug and from the information given I'd assume fixing the dhcp server should be the best thing todo. For mainframe you would broadcast the response if you get an error sending the unicast response (or just always send broadcast replies for mainframe?) What dhcp server are you using? Is z/VM not supporting MAC unicast and then still ships a dhcp server that fails if dhcp clients do not set the broadcast flag? Given the problems with MAC addressing you might also want to check if you want to pass some param to the kernel on bootup that is then used to determine the IP address and hostname of the Linux guest. greetings, Florian La Roche
*** Bug 120732 has been marked as a duplicate of this bug. ***
What became of this bug? Is it still an issue? Either: a. z/VM DHCP server needs to send MAC unicast replies b. We need to add support to dhclient to handle MAC broadcast replies c. We need include dhcpcd in the release for z/VM systems I'd need access to a z/VM system to implement (b). What would the customer like us to do about this problem?
I guess this bug is not still an issue - closing it.
An advisory 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-566.html