Shao Miller wrote: > 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.
As a matter of fact, we do have a problem with such an odd filename. You see, some HTTP URIs sometimes go something like http://webserver/page#section and we do some processing with #. While looking at this, I'd like to ask, though: Are you quite certain that the DHCP + PXE service is configured correctly? Could it be that #MPCPathBoot# is intended as a place-holder in the CA-Unicenter Managed PC Boot Server settings? A palce-holder for whatever the TFTP directory is supposed to be? - Shao Miller -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20101109/c447d9c5/attachment.html>
