Shao Miller wrote:
carlyo...@keycomm.co.uk wrote:
*On Mon 08/11/10 6:09 PM , Shao Miller shao.mil...@yrdsb.edu.on.ca sent:
*
carlyo...@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
_______________________________________________
gPXE mailing list
gPXE@etherboot.org
http://etherboot.org/mailman/listinfo/gpxe
