Thanks for your suggestions. Changing to broadcast didn't help me. This is very frustrating. Sometimes it will work, then you reboot and it just won't work anymore. I've got wireshark going on a machine connected to a hub that the iPXE client is also connected to. I connected this hub to see a complete replication of all the client's traffic, just in case the switch port monitor was lying to me. The iPXE client is receiving reach and every DHCP ACK extremely quickly after it sends out DHCPREQUESTs, but it's just ignoring them. Wireshark looks like: DHCPDISCOVER DHCPOFFER DHCPDISCOVER DHCPOFFER DHCPREQUEST DHCPACK DHCPREQUEST DHCPACK DHCPREQUEST DHCPACK DHCPREQUEST DHCPACK DHCPREQUEST DHCPACK But iPXE looks like DHCPDISCOVER DHCPOFFER DHCPDISCOVER DHCPOFFER DHCPREQUEST DHCPREQUEST DHCPREQUEST DHCPREQUEST DHCPREQUEST Weirdly, even on the best, working reboots, it always does the discover twice, even though iPXE acknowledges that it recieved the first one. I'm just not sure what to do. How do I turn up the verbosity even more? I just did make bin/ipxe.bin DEBUG=dhcp. I tried DEBUG=dhcp:4, DEBUG=dhcp:8, DEBUG=dhcp:15, and there was no more output.
-Mike On May 18, 2011, at 6:21 PM, Michael Brown <[email protected]> wrote: > On Wednesday 18 May 2011 15:19:22 Michael Cirineo wrote: >> So how can I ensure that iPXE uses #define BOOTP_FL_BROADCAST 0x8000 when >> doing DHCP? I'm experimenting with a broadcast response instead of >> unicast, that's how my other PXE clients are set up. > > If you're using ISC dhcpd, you can try forcing it to send a broadcast > response > using > > always-broadcast on; > > in /etc/dhcpd.conf. > > The default behaviour of iPXE is to request a broadcast response only if the > chaddr isn't capable of holding the current link-layer address (i.e. if the > network interface is IPoIB rather than Ethernet). > > Michael
_______________________________________________ ipxe-devel mailing list [email protected] https://lists.ipxe.org/mailman/listinfo/ipxe-devel
