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
