carlyoung at keycomm.co.uk wrote: > > *On Mon 08/11/10 6:09 PM , Shao Miller Shao.Miller at yrdsb.edu.on.ca sent: > * > > carlyoung at keycomm.co.uk wrote: >> Hi all. >> >> ... ... ... > > I know this NIC. :) It's the (previously NetXen) QLogic "Phantom" NIC. > >> This has apparently been shipped with a "gPXE" client and I am >> having some interoperability problems with a PXE boot server in >> that the client sends a boot request with an empty boot filename >> despite the DHCP ack containing a filename (for TFTP access). > > Can you capture the DHCP transaction with Wireshark or 'tcpdump' > and filter it for DHCP and share the resulting packets as an > e-mail attachment? I don't quite understand what you mean by the > client sending an empty boot filename. Do you mean it makes a TFTP > request with an empty filename? If so, do you have a Control-B > CLI? If so, can you please try: > > dhcp net0 > show filename > > and report whether or not you got a filename from the DHCP service? > > > Thanks Shao, > I have attached gpxe.cap. You can see the DHCP ACK in frame 14 with a > boot file name present and frame 15 shows a TFTP read with an empty > filename. I managed to find out version of gPXE client this morning - > apparently it is 0.9.9 embedded. > I can't do the CLI operations currently - I will have to ask for those > to be performed on my behalf. > I just want to know if I should be looking at getting the gPXE client > 'fixed' or the server or what...
Yes frame 14 is key. Your DHCP service appears to hand out a PXE menu to clients. I'm assuming that the client times out by not pressing F8, then performs another DHCP request; this time, already having the IP address it previously negotiated. I would guess that the presence of the IP address and/or the direction of this DHCP request directly to the DHCP server implies the PXE menu timeout occurred. The DHCP server's subsequent ACK finally contains a boot filename. In this case, it makes sense that it sends something whose filename suggests that the client merely fall-through to booting its HDD. Why, such a file could even be the two bytes 0xCD 0x18. :) However, the filename strikes me as unusual: #MPCPathBoot#\boothd I am now investigating to see whether there's a parsing problem with such an odd-looking filename. Please stay tuned. - Shao Miller -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20101109/3884991b/attachment.html>
