[ipxe-devel] [gPXE] nomenclature to use...

[Shao Miller]

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.htm>