TFTP Problems
-
yes, I think so
-
@bacelo said:
yes, I think so
That is not a reassuring answer. Where do your clients get their dhcp addresses from?
Are the clients on the same subnet as the FOG server? -
@bacelo Which one? Do you have access to a Windows DHCP server?
-
I am using the fogserver as DHCP
-
@bacelo Do you have another DHCP service running on the subnet?
What OS did you install FOG 1.2.0 on? Did you configure/disable the firewall? Is SELinux turned on? Is the TFTP Service running?Have you gone through this? https://wiki.fogproject.org/wiki/index.php/Troubleshoot_TFTP
-
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… -
@bacelo The error indicates that the tftp process could not download the file that is defined. Can we safely assume that 10.1.8.254 is the IP address of the FOG server (one might think that the .254 may be a router address in some installations)?
-
well the fogserver ip is 10.1.8.1
-
@bacelo said:
well the fogserver ip is 10.1.8.1
Then you have another DHCP service running on your subnet.
Are you doing this at home or work?
-
At a school
-
@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