PXE-T01: File Not Found Error

[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:

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):

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

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
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 !