BAD MSG: ' The siaddr field was being improperly set to the server-identifier when responding to DHCP messages. RFC2131 clarified the siaddr field as meaning the 'next server in the bootstrap process', eg a tftp server. The siaddr field is now left zeroed unless next-server is configured.
Cheers, Tim Sent from my iPhone On 19 Jul 2010, at 11:49, Michael Brown <mbrown at fensystems.co.uk> wrote: > On Monday 19 Jul 2010 10:19:22 Tim Wright wrote: >> First-time poster so please be gentle! >> >> We're seeing a few issues when attempting to PXE boot new HP systems with >> the QLogic NetXen onboard NICs (gPXE 0.9.9 embedded). I'm raising this >> directly with HP, but thought I'd post here too to see if anyone has any >> thoughts. >> >> We use Lucent QIP (which I believe is just ISC DHCPd under the covers) >> *and* Microsoft RIS/WDS for our provisioning system for all x86 operating >> systems. QIP provides the IP lease, while RIS is configured to provide just >> the additional boot options. Systems which do not have a matching UUID in >> Active Directory will boot to the "OS Chooser" menu (startrom.com) by >> default. >> >> My question is why is gPXE trying to load startrom.com (boot file name >> provided by proxydhcp), from the next-server provided by QIP (rather than >> proxydhcp/next-server)? I'm pulling my hair out here! I've read the Wiki >> article regarding MSRIS, but I don't seen to be even getting to that stage? > > If you've raised the issue with HP then it's likely to bounce down to me > eventually, since I'm the one who wrote the driver for NetXen. :) > > The problem in your case is that options from the DHCP server (QIP) are > deemed > to override options from the ProxyDHCP server. This part is as per the PXE > specification. However the PXE spec also states that all options must come > from a single source (i.e. we shouldn't be taking the next-server from one > source and the filename from another). This latter part is quite awkward to > do > within iPXE, which has many more potential sources of options (e.g. non- > volatile options stored on the NIC, options set via the command line) than > are > envisioned by the PXE spec. > > Why is the QIP server providing a next-server address at all? It sounds as > though in your setup you are wanting the next-server and filename to be > provided only by the RIS/WDS server. > > The easiest fix (if you can do it) would be to stop the QIP server from > handing > out its apparently spurious next-server address. > > (Redirected to the ipxe-devel list.) > > Michael
