Corrupted bootfile name

[DJ...]

We are using FOG with Ubuntu 16.04 in a Guest VM and providing DHCP from the host server. When a client PC attempts to get the bootfile name from the DHCP server in order to tftp that bootfile an error is returned saying that the bootfile cannot be found.
DHCP is set up with
option tftp-server-name “192.168.30.2”;
next-server 192.168.30.2;
option bootfile-name “undionly.kpxe”;

which I believe to be correct. The problem arises in that the filename being returned is corrupted and packet sniffing indicates that the PC Client is trying to get “undionly.kpxeM-^? 7;{” - there being a string of strange characters at the end of the filename. Off course the PC Client tftp protocol then issues the error message that this file cannot be found.
We have tried changing the name of the bootfile-name to just a space character which results in the return of " M-? ^7" or other such string of semi-random characters.
Doing a manual tftp get from the PC Client after it has booted into Windows works fine, as does using a Linux Client, so the TFTP server works fine when asked to get the correct filename.
How do we get rid of these odd characters attaching themselves to the bootfile-name returned to the PC Client so it can then TFTP the desired undionly.kpxe file? Alternatively can anyone please suggest an appropriate debugging process.

with thanks
DJ…

[Quazz]

option bootfile-name “undionly.kpxe”;

Is incorrect

option bootfile-name "undionly.kpxe";

Is correct.

Fix your quotation marks (perhaps elsewhere too!) and it should work fine after restarting the dhcp server.

[george1421]

For reference here is an example of a isc-dhcp config file: https://wiki.fogproject.org/wiki/index.php/BIOS_and_UEFI_Co-Existence#Example_1

[DJ...]

Thanks for the suggestion but unfortunately quotes are not the problem. They possibly appeared different in this post because of the way the post was created but we have used vi directly on the server console and checked the dhcpd.conf file with dhcpd -t -cf dhcpd.conf and all checks out OK. We’ve also tried single quotes but checking the dhcpd.conf file then fails.
Getting to wits end with this problem, so all help greatly appreciated.

[DJ...]

@quazz Thanks for the suggestion but unfortunately quotes are not the problem. They possibly appeared different in this post because of the way the post was created but we have used vi directly on the server console and checked the dhcpd.conf file with dhcpd -t -cf dhcpd.conf and all checks out OK. We’ve also tried single quotes but checking the dhcpd.conf file then fails.
Getting to wits end with this problem, so all help greatly appreciated.

[Tom Elliott]

@dj as you’re using vi to edit please open the config and run:
:%s/\s\+$//e

Save and edit, and restart dhcp. I’m only guessing there’s a line or more with trailing whitspace as indicated by the ^M you’re seeing

[Tom Elliott]

Also check the option itself. Maybe delete the line and enter it by hand?

[DJ...]

@tom-elliott Thanks Tom but we’ve tried that many times. Giving an empty filename just upsets the test on dhcpd.conf and using a filename with a space still results in the additional strange characters. Anyway, we have solved (or rather avoided) this issue by commenting out the bootfile-name line and adding…

  class "Legacy" {
    match if substring(option vendor-class-identifier, 0, 20) = "PXEClient:Arch:00000";
    filename "undionly.kkpxe";
    }

which seems to work. Now having another problem with an error message on the PCclient saying “Mounting /image/dev on /images failed: Connection timed out”, when trying to upload or download an image.
Still… one step forward. Thanks.

[Tom Elliott]

@dj you tried removing the trailing white space from all lines?

Seems to me nfs isn’t running.

[DJ...]

We now have the client PC booting and downloading the undionly.kpxe file but had to use the above mentioned “class” option. Further investigating the “Connection timed out” issue has raised another set of problems/questions which I will followup in a new thread.