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

[Shao Miller]

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://etherboot.org/pipermail/gpxe/attachments/20101109/c447d9c5/attachment.html