Kickstart NFS fails to find a DHCP address

[Bernard McAuley]

Hi,

After trawling through the e-mail archives, I've found several users
with a similar problem, but I haven't found a 'good' solution - so I'm
hoping that somebody can help me.

I have a PC attached via a cisco switch (and yet port fast is enabled!)
to a DHCP server, from which I'm trying to kickstart (via NFS but that
isn't particularly relevant) using a redhat 8.0 boot disk.  When the
boot starts the machine looks for a DHCP address, fails to get one and
so the boot stops there. (PUMP returns the messages:  No DHCP reply
received)

However, if I boot into a full linux installation (Red Hat 7.2 in this
case) and run pump I obtain an IP address without problems.

Looking at the DHCP server is it responding to the DHCPDISCOVER requrest
and offering out an IP addres but the machine refuses to pick up the IP
address.

I've put a hub between the switch and the client and used Ethereal to
monitor the traffic to and from the machine and with an installation
these are the first 2 transactions that I get:-

Frame 12 (342 bytes on wire, 342 bytes captured)
Ethernet II, Src: 00:09:5b:61:38:5a, Dst: ff:ff:ff:ff:ff:ff
Internet Protocol, Src Addr: 0.0.0.0 (0.0.0.0), Dst Addr:
255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: bootpc (68), Dst Port: bootps (67)
Bootstrap Protocol

Frame 15 (357 bytes on wire, 357 bytes captured)
Ethernet II, Src: 00:02:55:aa:7e:3d, Dst: ff:ff:ff:ff:ff:ff
Internet Protocol, Src Addr: physerv1.phyworks-ic.com (192.168.181.200),
Dst Addr: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: bootps (67), Dst Port: bootpc (68)
Bootstrap Protocol

Frame 17 (342 bytes on wire, 342 bytes captured)
Ethernet II, Src: 00:09:5b:61:38:5a, Dst: ff:ff:ff:ff:ff:ff
Internet Protocol, Src Addr: 0.0.0.0 (0.0.0.0), Dst Addr:
255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: bootpc (68), Dst Port: bootps (67)
Bootstrap Protocol

Frame 18 (357 bytes on wire, 357 bytes captured)
Ethernet II, Src: 00:02:55:aa:7e:3d, Dst: ff:ff:ff:ff:ff:ff
Internet Protocol, Src Addr: physerv1.phyworks-ic.com (192.168.181.200),
Dst Addr: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: bootps (67), Dst Port: bootpc (68)
Bootstrap Protocol

The frames continue for a short while, but the PC never picks up on the
returning DHCPOFFER packets (which aren't delayed by a long period).

Compare this to the transaction whilst using PUMP:-

Frame 5 (357 bytes on wire, 357 bytes captured)
Ethernet II, Src: 00:02:55:aa:7e:3d, Dst: ff:ff:ff:ff:ff:ff
Internet Protocol, Src Addr: physerv1.phyworks-ic.com (192.168.181.200),
Dst Addr: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: bootps (67), Dst Port: bootpc (68)
Bootstrap Protocol

Frame 6 (590 bytes on wire, 590 bytes captured)
Ethernet II, Src: 00:09:5b:61:38:5a, Dst: ff:ff:ff:ff:ff:ff
Internet Protocol, Src Addr: 0.0.0.0 (0.0.0.0), Dst Addr:
255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: bootpc (68), Dst Port: bootps (67)
Bootstrap Protocol

Frame 7 (342 bytes on wire, 342 bytes captured)
Ethernet II, Src: 00:02:55:aa:7e:3d, Dst: ff:ff:ff:ff:ff:ff
Internet Protocol, Src Addr: physerv1.phyworks-ic.com (192.168.181.200),
Dst Addr: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: bootps (67), Dst Port: bootpc (68)
Bootstrap Protocol

Frame 8 (590 bytes on wire, 590 bytes captured)
Ethernet II, Src: 00:09:5b:61:38:5a, Dst: ff:ff:ff:ff:ff:ff
Internet Protocol, Src Addr: 0.0.0.0 (0.0.0.0), Dst Addr:
255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: bootpc (68), Dst Port: bootps (67)
Bootstrap Protocol

Frame 9 (342 bytes on wire, 342 bytes captured)
Ethernet II, Src: 00:02:55:aa:7e:3d, Dst: ff:ff:ff:ff:ff:ff
Internet Protocol, Src Addr: physerv1.phyworks-ic.com (192.168.181.200),
Dst Addr: 255.255.255.255 (255.255.255.255)
User Datagram Protocol, Src Port: bootps (67), Dst Port: bootpc (68)
Bootstrap Protocol

Can anybody suggest whats going on here?  Earlier posts have suggested
that the DHCP request is timed out too soon, but the time stamps on the
install and the pump run are roughly the same (just under 1 second).
I'm digging into the sources now, but I really don't want to be
rebuilding anaconda if I can help it!

Regards,


Bernard McAuley