[gPXE] [ipxe-devel] nomenclature to use...
Shao Miller
Shao.Miller at yrdsb.edu.on.ca
Tue Nov 9 08:40:21 EST 2010
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
More information about the gPXE
mailing list