tftp client targetting the wrong server [dhcp relay, kea, option 66]
-
Hello,
We are successfully using Fog for 5 years, as a standalone [FOG+dhcp+tftp] server (
xx.yy.20.221).Now, we would like to stop using the embedded dhcp server, and use a different external dhcp server (```xx.yy.0.4``). We are using this ISC KEA server for years as well, so we have setup our network to allow the dhcp relay between the FOG clients subnets to our KEA DHCP server.
On the FOG server, we have stopped the dhcpd server, we have reconfigured the
.fogsettingsto make sure it won’t run on the local FOG server :dodhcp='n' bldhcp='0' dhcpd=''and we have re-launched the
installfog.shscript.On the KEA DHCP external server, we have setup a dedicated subnet with the specific options :
... "option-data": [ { "name": "routers", "data": "xx.yy.20.250" }, { "code": 66, "data": "xx.yy.20.221", "always-send": true, "name": "tftp-server-name" }, { "code": 67, "data": "undionly.kkpxe", "always-send": true, "name": "boot-file-name" } ] ...When trying to boot a FOG client host, which is located in the fog client hosts subnet, I can see that the DHCP traffic is correctly done, the client is getting an ip from the server, through the relay. The KEA DHCP is correctly sending the client the 66 and 67 options (tftp-server-name and bootfile name), but I can also see (tcpdump sniffing) that the fog host client host is requesting the tftp bootfile to the KEA dhcp server, though the tftp server has not changed its location, and still resides on the FOG server!
Through the FOG project documentation, I’ve found information about using an external DHCP server, but there where nothing about changing the TFTP, which I don’t want.
In the FOG system settings, I have double checked that the TFTP server is pointing to the FOG server.
If someone is using an external DHCP to server dhcp queries : are you also hosting the tftp service on the dhcp server, or did you add an additional setup I may have forgotten?
Thank you.
-
Hi @george1421 ,
Thank you for your answer, which helped me to push even further the digging amongst tons of forums and docs.
What you wrote was right, about the fact that were indeed two sets of fields to manage - this information is clearly mentioned nowhere - and in Kea, here is how to set it up : you don’t specify it as an “option-data”, but as a statement directly inside the subnet definition :
{ "id": xx, "subnet": "xx.32.20.0/24", "pools": [ { "pool": "xx.32.20.1 - xx.32.20.200" } ], "next-server": "xx.32.20.221", // <----- Thank you George ;-) "option-data": [ { "name": "routers", "data": "xx.32.20.250" }, { "code": 66, "data": "xx.32.20.221", "always-send": true, "name": "tftp-server-name" }, { "code": 67, "data": "undionly.kkpxe", "always-send": true, "name": "boot-file-name" } ] }Quite tricky to find!
Have a nice day.
-
@nec There is two sets if fields that need to be updated. There are the bootp fields in the ethernet header next-server and boot-file AND the dhcp fields option 66 and 67 that need to be set. Depending on who programmed the pxe boot code the target computer could look at either set of values (bootp or dhcp). Many dhcp servers set both just to be sure.
You should use wireshark on a witness computer with the capture filter of
port 67 or port 68Start wireshark and pxe boot the target computer to the error. Stop collecting data and look at the OFFER packet you should have one packet for every dhcp server that hears the DISCOVER packet.Make sure if you only expect one dhcp server to respond that there is only one offer packet. Now look at the offer packet, in the ethernet header the next-server and boot-file is properly specified. Also validate the dhcp values 66 and 67. My bet there is something missing in the offer packet. If you can’t find the issue upload the pcap here and we can look at it.
-
Hi @george1421 ,
Thank you for your answer, which helped me to push even further the digging amongst tons of forums and docs.
What you wrote was right, about the fact that were indeed two sets of fields to manage - this information is clearly mentioned nowhere - and in Kea, here is how to set it up : you don’t specify it as an “option-data”, but as a statement directly inside the subnet definition :
{ "id": xx, "subnet": "xx.32.20.0/24", "pools": [ { "pool": "xx.32.20.1 - xx.32.20.200" } ], "next-server": "xx.32.20.221", // <----- Thank you George ;-) "option-data": [ { "name": "routers", "data": "xx.32.20.250" }, { "code": 66, "data": "xx.32.20.221", "always-send": true, "name": "tftp-server-name" }, { "code": 67, "data": "undionly.kkpxe", "always-send": true, "name": "boot-file-name" } ] }Quite tricky to find!
Have a nice day.
-
[[undefined-on, N nec, ]]
-
@nec Good find, but I would also say that you are missing the boot-file (or whatever its called) at the pool level. That is the bootp part of the pxe booting. When you look at the pcap from the witness computer on the same subnet as the pxe booting computer. You should see both sets of values set.
I have no idea what Kea dhcp server is but the config file looks similar to the linux standard ISC-DHCP dhcp server.
-
@george1421 said in tftp client targetting the wrong server [dhcp relay, kea, option 66]:
@nec Good find, but I would also say that you are missing the boot-file (or whatever its called) at the pool level. That is the bootp part of the pxe booting. When you look at the pcap from the witness computer on the same subnet as the pxe booting computer. You should see both sets of values set.
OK, I get that, though I must admit that the config file I’ve shown here is sufficient and working in that particular context.
I have no idea what Kea dhcp server is but the config file looks similar to the linux standard ISC-DHCP dhcp server.
ISC started the development of Kea in 2014, ten years ago, with the objective to replace the venerable ISC-DHCPD.
As stated here, ISC has set the end-of-life of ISC-DHCPD in 2022.(On a personal POV, it broke my heart)
