Bug 111540 - dhcpcd not present in RHEL3, was present in previous release (RH7.2)
dhcpcd not present in RHEL3, was present in previous release (RH7.2)
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: dhcpcd (Show other bugs)
3.0
s390 Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
:
: 120732 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-12-04 19:07 EST by Vic Cross
Modified: 2007-11-30 17:06 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-08-25 19:00:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Vic Cross 2003-12-04 19:07:57 EST
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.
Comment 1 Daniel Walsh 2003-12-29 06:47:53 EST
Florian do you have a comment on this bug report?

Dan
Comment 2 Florian La Roche 2003-12-29 14:43:59 EST
- 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
Comment 3 Florian La Roche 2003-12-29 15:09:56 EST
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
Comment 4 Vic Cross 2003-12-29 17:51:05 EST
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
Comment 5 Florian La Roche 2003-12-30 04:15:19 EST
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
Comment 6 Jason Vas Dias 2004-08-04 18:22:21 EDT
*** Bug 120732 has been marked as a duplicate of this bug. ***
Comment 7 Jason Vas Dias 2004-08-12 14:39:06 EDT
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? 
Comment 8 Jason Vas Dias 2004-08-25 19:00:35 EDT
I guess this bug is not still an issue - closing it.
Comment 9 John Flanagan 2004-12-21 14:42:08 EST
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

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