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
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
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Try to install dhcpcd from install media
2. Try to configure a Guest LAN interface using DHCP
Actual Results: 1. Package not found
2. Interface configuration fails (dhclient used as DHCP client)
Expected Results: 1. Package found and installed
2. Interface configuration successful (dhcpcd used as DHCP client)
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
Florian do you have a comment on this bug report?
- RFC 1542 contains the following text:
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
- dhcp could anyway be changed to allow requesting a broadcast reply.
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:
So I assume this to be either a z/VM or a kernel driver issue to
solve, not a dhcp client/server issue.
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
RX bytes:23050 (22.5 Kb) TX bytes:31048 (30.3 Kb)
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...
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.
Florian La Roche
*** Bug 120732 has been marked as a duplicate of this bug. ***
What became of this bug? Is it still an issue?
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.