TFTP PXE-T01: File Not Found
-
I think I have explained myself in a wrongful manner. What I mean is: The FOG settings are set up to use DHCP 10.0.1.10
10.0.0.15 is FOG server -
@MadsMagnus said i:
I think I have explained myself in a wrongful manner. What I mean is: The FOG settings are set up to use DHCP 10.0.1.10
10.0.0.15 is FOG serverFair enough, understand I’m trying to get a picture of your environment. OK just to be clear for me 10.0.1.10 is your Windows DHCP server, then where does the 10.0.1.14 come into play?
I need to leave in a minute for my commute into the office. So I’ll be off for about 1hr. We can get this worked out we just need to get all of the actors identified.
-
No problem. 10.0.1.14 is our redundant DNS/DHCP server. Its a part of the Windows server envoirment we have here.
-
@MadsMagnus ok so you have option 66 and 67 set on both dhcp servers?
The next step now that we know the actors involved is to get a network capture of the dhcp and tftp process. Just for a little background dhcp is a broadcast based protocol, so you can capture the dhcp conversation between the target computer and the dhcp server from any device connected to the same subnet/broadcast domain. So knowing this you could install wireshark on any computer set the filters for only dhcp (ports 67 and 68) and capture the dhcp traffic into a pcap file. Since we also have a question about tftp we can’t do this since tftp is a unicast call (from the target to the tftp server only), so with this in mind we need to install tcpdump on your FOG server (since it will be part of the tftp communications). So go ahead and install wireshark on your windows computers and tcpdump on your fog server.
Now once tcpdump is installed what you will do is launch the tcpdump program and then boot the target computer until you get the file not found error and then you will abort the tcpdump program with a ctrl-C. That will produce the pcap file we need. Understand that this pcap file will contain all of the information you are issuing out via dhcp. Most of it is not a security concern, the only thing that one might take issue with is that your internal dns name will be in this file. So to ease your security concerns you should review the content of this pcap file with wireshark. I also challenge you to see if you can spot the problem. We know the actors involved now. So if you see a conversation with a device that is not a known actor or data that is being sent incorrectly you found the problem. Don’t worry if you can figure it out you can post your pcap file here so we can look at it.
The tcpdump command you need is:
tcpdump -w output.pcap port 67 or port 68 or port 69So this command will listen for any communication on port 67 (dhcp req) port 68 (dhcp answer), and port 69 (tftp) and output the results into the output.pcap file. This command will not capture any other traffic. When you have your output.pcap file you can either inspect it with wireshark if you want to see if you can figure out what is going on or post it here and one of us can take a look.
-
Okay I will do that but… 1 thing at a time here. I just updated my fog to trunk by following the SVN wiki guide. Now my fog is broken/webacces does not work. When I try to reinstall it simply just ends at “Restarting Apache2 for fog vhost… Failed!”. I have tried restarting apache, mysql and tftpd-hpa with no succes. I remember updating via SVN broken my last attempt at FOG on Ubuntu 12 too.
Strange huh? Somehow I dont think sniffing trafic is very useful atm
-
@MadsMagnus OK start a new thread with that in the subject line. There are others who had the same issue. I know that Ubuntu 14.04 will work successfully with FOG 1.2.0 trunk. I was going to address the trunk upgrade later since the dhcp/tftp is not related to the version of FOG you are using ATM. Come back to this thread when you get the fog upgrade resolved.
-
@george1421 Will do. Thank you george.
-
Okay so as a part of the webacces fix, i upgraded to version 7785. This clearly did the trick, as now the clients also seem to PXE boot properly. However now, as I am trying to do a registration of my W10 image, it is just stuck at “bzImage…” etc. The dots just seem to keep going. I will be leaving in a sec so I will see how it stands tomorrow. But I suppose I have to open another thread, as the issue has changed, correct? I would imagine we are seeing that the VMs NIC isn’t recognized by the base kernel.
-
@MadsMagnus Well that great you got the first part going.
As for this new issue, you should create a new thread. But I am interested to know what hardware are you trying to boot? It sounds like you are getting through the iPXE kernel OK and now FOS (Fog linux OS) is not decompressing very well.
-
It is just a random VM machine running off a Dell server - not sure which kind. I just checked up on the machine this morning and it is still just at “bzImage …” with like a million dots by now…
