PXE-T01: File Not Found Error

george1421

@easybizit Yes that’s right (and still disappointing that its not working).

The next steps

In the pxe-service lines add ,192.168.2.99

pxe-service=X86PC, "Boot to FOG", undionly, 192.168.2.99

This sends the for IP address as part of the “boot to fog” request. Don’t forget to restart dnsmasq when you make this change.

Now if you have no success with the above add. The next thing is to capture what is going down the wire to see what communication is going on and what is missing. We’ll use tcpdump on the fog server to capture this communication. You could use wireshark on a third computer instead of tcpdump, but we’ll go the tcpdump route: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

Capture the pxe boot process and then post the output.pcap file here so we can look at the pxe boot dialog. Out side of that I would say this is a normal pxe booting process.

I guess the next step is to attempt to get undionly.0 via another system. So if you have another linux system or if you install the tftp client on a windows system. Can you download undionly.0 from the FOG server?

I have to say this is a unique case, its not normally this difficult to get devices to pxe boot. Another test would be to see if you can just pxe boot a physical system to remove any issues with the virtual environment. I seriously doubt this is the issue since everything is flowing what I would consider normal.

easybizit

@george1421 Thank you again. No luck with the pxe-service line:

See attached the pcap file:

0_1490611720374_output.pcap

I needed to modify the tcpdump command a smidge to make it work:

tcpdump -w /output.pcap port 67 or port 68 or port 69 or port 4011 -i ens33

george1421

@easybizit reading through the pcap this is what I see:

First of all this appears to be a good pcap (meaning it should be working!!).

packet 1 (discover)
pxe booting client vmware
firmware: IA x86 (legacy mode)

packet 2 (dhcp offer dnsmasq)
next-server: 192.168.2.99
boot-file: undionly.kpxe
Your ip: 0.0.0.0 (this is good since dnsmasq doesn’t supply IP addresses for dhcp-proxy)

packet 3 (dhcp offer dhcp server)
next-server: not given
boot-file: not given
Your IP: 192.168.2.110

packet 4 (request [client announcing I need to know this stuff])
(various item requested not relevant)

packet 5 (ack from dhcp server)
(here is the stuff you asked for that I know about)

packet 6 (proxyDHCP request from client to dnsmasq server)
I haven’t been able to figure out how to decode this line. I assume the client is asking the proxyDHCP server about the file it needs.

packet 7 (proxyDHCP request from client to dnsmasq server)
I haven’t been able to figure out how to decode this line either.

packet 8 (client asking tftp server for file size of undionly.0)

packet 9 (client asking tftp server for the file undionly.0)

now I would have expected to see additional tftp request since undionly.0 can not fit in just one packet.

easybizit

@george1421 hmmm, ok. I’ll try it on a physical machine and see if its not just an issue with the vm’s that I’m using. It will take me a day or so to get a lab up and running. Let you know ASAP.

Thank you once again for your support, incredible how well you look after the community :).

george1421

@easybizit It looks like I forgot to include this, I dreamed it, or thought and the forgot it.

Using a windows computer (for windows install the tftp application) or another linux computer. Use tftp and attempt to download the undionly.0 file from the fog server. That will test to see if the file “could” be acquired by the target computer. It bugs me that it “should” be working, but is not.

easybizit

@george1421 Hi! Sorry, my boss send me on a three week escapade with a days notice, I’m back now. Eureka! I think we may have found the problem. I can tftp many files but not the undionly.0 file. See below:

0_1492915734649_undionly failure.jpg

How do I fix that? Could it be permissions on the other side of the sym link?

george1421

@easybizit You do need to create the symbolic link between undionly.0 and undionly.kpxe for that bit to work.

ln -s /tftpboot/undionly.kpxe /tftpboot/undionly.0
ln -s /tftpboot/ipxe.efi /tftpboot/ipxe.0

easybizit

@george1421 Here is the contents of the tftpboot directory (just resnapped it):

0_1492916346293_tftboot folder.PNG

Does this look right?

george1421

@easybizit yes that looks correct.

easybizit

@george1421 hmm… So why won’t it grab the file on PXE boot? I’m afraid I’m not strong in this area but I get the feeling that there something really silly that I’ve missed.

george1421

@easybizit can you download the file manually via tftp?

easybizit

@george1421 I can grab the undionly.kxpe but not the undionly.0. ‘I get connect request failed’

george1421

@easybizit Well that one is a bit confusing. I’m not seeing anything wrong.

Lets replace the link with a real file.

cp /tftpboot/undionly.kpxe /tftpboot/undionly.0

And then try with the tftp again from a remote windows client.

easybizit

@george1421 alt text

So what’s up with the sym link? Its working perfectly now.

george1421

@easybizit That is an excellent question!!

Has selinux been set to permissive? The sym link should work no problem…

easybizit

@george1421 0_1492917380843_conf file.png
Here is the latest copy (I rebuilt the box to a different environment but had the same issue this is the latest copy, hence I think I’ve done something dumb).

dasti

This post is deleted!

dasti

I had exactly the same problem with some old pc/laptops (i.e. hp probook 4411s) but not on recent pc

fog 1.3.0rc8 on debian
the dhcp server was handled by a juniper switch ex3300 junos 12.3R10.2
made some test with a pfsense vm v2.3.2 acting as a dhcp server

When I captured packets on the server, I noticed that the client was requesting a files that did not exist so I decided to mirror the port and capture the complete process as I was expecting something with the dhcp

the main difference seems to be that the juniper dhcp includes the filename in the option 67 (in addition of being also in the "boot file name¨ ) and pfsense doesn’t, and some legacy computer seems to not handle that properly and adds some caracters at the end of the filename which make the tftp request wrong which makes the tftp server to not understand what file is requested

here’s my notes from the captures

differences in dhcp offer (dhcp answer to the client)
    
                        JUNIPER (not working)               PFSENSE (working)
------------------------------------------------------------------------------------
server hostname         10.0.5.90                           "not given"
dhcp option 67          undionly.kpxe                       "not set"



differences in TFTP read request (client asks the file to the pxe-tftp server)

                        JUNIPER (not working)               PFSENSE (working)
------------------------------------------------------------------------------------
source file             undionly\377                        undionly.kpxe
in details              undionly\357\277\275                undionly.kpxe
hexa before "octetsize" ff00                                00



differences in TFTP server answer (from pxe-tftp server to client)

                        JUNIPER (not working)               PFSENSE (working)
------------------------------------------------------------------------------------
answer                  error code (5) file not found       option acknowledgement

I hope the can be helpfull to you !

PXE-T01: File Not Found Error

144

12.0k

17.3k

155.2k