TFTP Problems
-
@bacelo said:
well the fogserver ip is 10.1.8.1
Interesting, I though I would have seen this address in the PXE header. What is host 10.1.8.254? That is the object that is managing your DHCP for your site. If your fog server is 10.1.8.1 and you have it setup for dhcp, but your addresses are being handed out by 10.1.8.254 then your bootp values are probably not getting to the pxe client.
-
so what should i do to test it out to see what I am doing wrong
-
@bacelo Again, what is 10.1.8.254 ?? Who owns it?
That is the device you need to set dhcp options 66 and 67 in/on. Once you do that, the pxe client should boot into the fog menu. My intuition is telling me that 10.1.8.254 is your firewall/internet router.
Once you get that working, you MUST make sure that the dhcp server in fog is not used or you will have IP address conflicts.
-
ok I will do that and I will get back with news
-
ok so I checked that everything is correct with the DHCP server as it should be configed as it shows in the wiki page for Cicso and the firewall in ubunto is inactibe and still nothing
-
Sorry for intentionally being dense here. What is device 10.1.8.254 ?
Are you still getting the same exact error message as you posted below?
-
it is on a server on a quarentine network
-
Well now I’m confused. Here is what you posted before.
This is what it shows when I try to boot to the fogserver:
CLIENT MAC ADDR: 00 22 64 BB 04 DF GUID: 0CD117C8 1FDC DD11 BBDA 64BB04DF0022
CLIENT IP: 10.1.8.59 MASK IP: 255.255.255.0 DHCP IP: 10.1.8.254
GATEWAY IP: 10.1.8.254
PXE-E32: TFTP open yimeout
TFTP…And you also stated
well the fogserver ip is 10.1.8.1
I’m only seeing a single subnet net here. And all devices mentioned are on 10.1.8.0/24 subnet. The root of the issue I see so far is that the FOG server 10.1.8.1 is not being used for dhcp so any settings you make to FOG will not impact the booting process so far. But the client is reporting that 10.1.8.254 is being used for dhcp booting (which I’m still suspecting is a router). Reading a bit more into the what as not been said yet. Since you introduced the concept of a quarantine network, I get the feeling that 10.1.8.254 is a router interface that has a dhcp-relay setup on it that points to a master dhcp server some place else on another network.
I’m trying to help here but I’m not getting the big picture of how this is setup.
-
@bacelo said:
ok so I checked that everything is correct with the DHCP server as it should be configed as it shows in the wiki page for Cicso…
I am not getting this. Which DHCP server config did you check? 10.1.8.1 (not being used by the client as you can see in the DHCP timeout) or 10.1.8.254 (again, what system is this? Do you have access to this device?)… What wiki are we talking about FOG wiki or Cisco wiki? URL?
We need more information to be able to help you.
-
In case it helps clarify things - I’ll explain briefly how the network booting process works with FOG.
A DHCP service runs on some machine somewhere.
A host turns on… (This host is on the same network that DHCP is running on.)
Discovery
The host broadcasts to the network “Hey, I need an address.”Offer
The DHCP service hears the broadcast, and then broadcast’s back “Here use this address and these options…”Momentary pause
The host & server momentarily listen on the network for any objections from other hosts (a host with the same IP will broadcast “No you can’t use that, I already have it!”)Request
The host then responds to the DHCP server with yet another broadcast and says “Ok, I want this address”.Acknowledge
The server hears that and then responds with a broadcast saying “OK, you’ve got it, I’ve made note.”So now… the HOST has an IP and configuration for that IP. The configuration (in FOG’s scenario) also contains DHCP Options 066 and 067. 66 is the “Next-Server” and 67 is the “Boot-file”. These options are sent out in the DHCP Offer (above).
The host will then ask the Next-Server for the Boot-File using TFTP.
The TFTP Server (usually the FOG server) will respond with the requested file.
And then other things begin happening… but you’re not getting even this far - you’re host isn’t getting an address from the FOG server, it’s getting an address from another DHCP server elsewhere - and THAT DHCP server is not configured correctly to hand out options 066 and 067.
Now then…
Hopefully you can see how having two DHCP Services on a network with one not configured will simply not work 100% of the time (and maybe none of the time). This is what @george1421 and @Sebastian-Roth were talking about. If there is a pre-existing DHCP Service running on the network, you need to edit that. We happen to have a full guide written just for doing this: https://wiki.fogproject.org/wiki/index.php/Modifying_existing_DHCP_server_to_work_with_FOG
-
Ok , Yes the DHCP is not controlled by the fog server it is the network configuration it my be a router I am not sure. I do know that the DHCP server that hey are using in as it is in the Wiki fog page as it is for the cisco setup. Know sould I tell them to change the 10.1.8.254 to 10.1.8.1 will this help??
-
@bacelo said:
Ok , Yes the DHCP is not controlled by the fog server it is the network configuration it my be a router I am not sure. I do know that the DHCP server that hey are using in as it is in the Wiki fog page as it is for the cisco setup. Know sould I tell them to change the 10.1.8.254 to 10.1.8.1 will this help??
No what they have is fine, as long as you can set the options 66 and 67 for your 10.1.8.x scope to point to your FOG server and the boot file undionly.kxpe on that dhcp server. That is what’s missing here. That is why we are trying to figure out what 10.1.8.254 is.
-
Ok I am going to format the linux and install it all over again. what version of linux do you recommend???
-
@bacelo Go with CentOS 7, or Fedora 23 Server.
For newcomers to Linux, you’ll be better off with CentOS because there is more documentation for it. It’s 100% Red Hat Enterprise Linux compatible, any commands that work with RHEL work with CentOS - and the RHEL / CentOS distros generally have about a 2 to 3 year lifecycle whereas Fedora has a 2 to 3 month life cycle.
I myself prefer Fedora, but CentOS 7 is rock solid.
But 1.2.0 won’t install on CentOS 7, you’ll need to use FOG Trunk. There’s article for it in the WiKi.
-
@bacelo said:
Ok I am going to format the linux and install it all over again.
But this won’t actually make PXE work for you. You need to get in contact with whoever is in charge for 10.1.8.254 and hopefully he’s willing to add options 66 and 67 for you.
-
@Sebastian-Roth he already did and it still didn’t work
-
Have you looked through this already? https://wiki.fogproject.org/wiki/index.php/Tftp_timeout
Start with sections on restarting tftp service and “Other Troubleshooting” (trying TFTP by hand)…
Either the TFTP on FOG server is not running properly OR the DHCP is not pointing to the correct IP address.
-
There’s this article too.
https://wiki.fogproject.org/wiki/index.php/Troubleshoot_TFTP
-
I still haven’t got it working:(
The DHCP is being managed by the cisco device it is a quarentine network that is being maneged by some one other then me and I can only speak to him on the phone. So I am going to try to explain how I installed the fog server. So I followed this video: https://www.youtube.com/watch?v=QXHD-IQZigE
the only thing that I did different was the versions of the fog server. -
Unfortunately, if your DHCP IP addresses are coming from this cisco device you are at the mercy of the owner of that dhcp server. No configuration that you can do with fog will help since the cisco dhcp server tells the client what to do next. Now if you want to pxe boot from a usb flash drive then you can regain some level of control and not need to make any dhcp server setting changes, but this will also require a special boot drive any time you want to boot into the pxe menu.
The other option is to shut off the dhcp relay between the network where the FOG server is and this other network, Then you will need to ensure that fog is setup to issue IP addresses for your local network. I see this as being a risky step because now FOG will supply all IP addresses for your side of the firewall.
Please help us build the FOG community with everyone involved. It's not just about coding - way more we need people to test things, update documentation and most importantly work on uniting the community of people enjoying and working on FOG!
