VMware Cloud Community
dbutch1976
Hot Shot
Hot Shot
Jump to solution

TFTP not working using DNSMASQ - troubleshooting assistance please!

Hello,

I am attempting to get TFTP working using DNSMASQ on a Raspberry Pi host so that I can use to to boot ESXi hosts using Autodeploy and I'm not having much luck at all. I don't have much of a Linux background at all so I'm struggling with some basic troubleshooting and any help would be greatly appreciated. I know this may not be the best forum for this question but this forum as always been extremely helpful.

Here are the settings of my etc/dnsmasq.conf file:

domain-needed
bogus-priv
expand-hosts
domain=LEBRINE.local
enable-tftp
tftp-no-fail
tftp-root=/tftpboot
tftp-unique-root
pxe-service=0,"Raspberry Pi Boot"

I have uploaded the required tramp file ETC to /TFTPBOOT/ on the raspberrypi, I have used these commands to set the permissions:

chmod -R 777 /tftpboot
chown -R nobody /tftpboot

Permissions on the folder are as follow:

root@raspberrypi:/# ls -la /tftpboot/
total 2192
-rwxrwxrwx 1 nobody pi 0 Mar 21 12:11 '*'
drwxrwxrwx 2 nobody root 4096 Apr 2 06:18 .
drwxr-xr-x 22 root root 4096 Apr 3 09:20 ..
-rwxrwxrwx 1 nobody pi 223744 Apr 2 05:45 snponly64.efi
-rwxrwxrwx 1 nobody pi 228544 Apr 2 05:45 snponly64.efi.officialkey
-rwxrwxrwx 1 nobody pi 227320 Apr 2 05:45 snponly64.efi.testkey
-rwxrwxrwx 1 nobody pi 223744 Apr 2 05:45 snponly64.efi.vmw-hardwired
-rwxrwxrwx 1 nobody pi 228544 Apr 2 05:45 snponly64.efi.vmw-hardwired.officialkey
-rwxrwxrwx 1 nobody pi 227320 Apr 2 05:45 snponly64.efi.vmw-hardwired.testkey
-rw-r--r-- 1 root root 0 Apr 3 09:10 test
-rwxrwxrwx 1 nobody pi 0 Apr 3 09:10 tramp
-rwxrwxrwx 1 nobody pi 129547 Apr 2 05:45 undionly.0
-rwxrwxrwx 1 nobody pi 129547 Apr 2 05:45 undionly.kpxe
-rwxrwxrwx 1 nobody pi 100286 Apr 2 05:45 undionly.kpxe.debug
-rwxrwxrwx 1 nobody pi 104863 Apr 2 05:45 undionly.kpxe.debugmore
-rwxrwxrwx 1 nobody pi 129157 Apr 2 05:45 undionly.kpxe.nomcast
-rwxrwxrwx 1 nobody pi 129637 Apr 2 05:45 undionly.kpxe.vmw-hardwired
-rwxrwxrwx 1 nobody pi 129272 Apr 2 05:45 undionly.kpxe.vmw-hardwired-nomcast
-rw-r--r-- 1 root root 0 Apr 2 06:14 vms.csv
-rwxrwxrwx 1 nobody pi 50 Oct 7 14:08 VMs.csv

 

From an SSH session on the RapsberryPi itself (192.168.0.2) I have tried to test downloading serveral files, only one of which appears to succeed as shown below:

root@raspberrypi:/# tftp 192.168.0.2
tftp> GET test
?Invalid command
tftp> get test
tftp> get tramp
tftp> get vms.csv
[COLOR="Yellow"]tftp> get VMs.csv
Received 53 bytes in 0.0 seconds[/COLOR]


Testing externally from a windows machine I am not able to download anything at all, nor am I able to boot from the network using ESXi test machines configured to boot from LAN:

C:\>tftp 192.168.0.2 get tramp
Connect request failed
C:\>tftp 192.168.0.2 get test
Connect request failed
C:\>tftp 192.168.0.2 get VMs.csv
Connect request failed


I feel like it's something simple like firewall or permissions, but I simply don't have the Linux troubleshooting skills. Can anyone assist?

 

 

 

 

 

Reply
0 Kudos
1 Solution

Accepted Solutions
dbutch1976
Hot Shot
Hot Shot
Jump to solution

Well I managed to fix this one myself. Long story short, I'm just learning Linux so I was copy pasting my setup. It wasn't until I decided to consolidate both my DHCP and DNS onto dnsmasq and reviewing my settings line by line that I found that there were some unnecessary settings.

Here are the steps I used to install dnsmasq:
https://fedoramagazine.org/dnsmasq-provide-dns-dhcp-services/#:~:text=dnsmasq%20is%20a%20lightweight....

And here are the final working settings in the /etc/dnsmasq.conf file:

#DNS settings
domain-needed
bogus-priv
expand-hosts
domain=LEBRINE.local
#TFTP settings
enable-tftp
tftp-no-fail
tftp-root=/tftpboot
tftp-unique-root
#Log locations
log-queries
log-facility=/var/log/dnsmasq.log
#DHCP settings
interface=eth0
bind-dynamic
dhcp-range=192.168.0.10,192.168.0.200,255.255.255.0,12h
dhcp-option=3,192.168.0.1
dhcp-option=6,192.168.0.2
dhcp-option=66,192.168.0.2
dhcp-option=67,undionly.kpxe.vmw-hardwired
#DHCP Reservations
dhcp-host=00:0c:29:2b:25:2F,vcdessloch.lebrine.local,192.168.0.11,infinite
dhcp-host=00:0c:29:d4:78:f5,d20.lebrine.local,192.168.0.21,infinite
dhcp-host=00-24-9B-67-7A-F1,YOGA,192.168.0.188,infinite


Hope this helps someone!

 

View solution in original post

Reply
0 Kudos
5 Replies
scott28tt
VMware Employee
VMware Employee
Jump to solution

Wouldn't this be a better place to ask? https://forums.raspberrypi.com/

 


-------------------------------------------------------------------------------------------------------------------------------------------------------------

Although I am a VMware employee I contribute to VMware Communities voluntarily (ie. not in any official capacity)
VMware Training & Certification blog
Reply
0 Kudos
dbutch1976
Hot Shot
Hot Shot
Jump to solution

You'd think so, but I have asked there, and as it turns out, the answer is no. 🤦🏼‍♂️

Reply
0 Kudos
dbutch1976
Hot Shot
Hot Shot
Jump to solution

Just in case anyone is having this same problem, here are the troubleshooting steps I have used so far which have help:

  1. From the TFTP source (assuming Linux, in this case Raspberry Pi)

    sudo ss -tulw
    sudo ss -tulw | grep tftp

Look for something like this:

udp UNCONN 0 0 0.0.0.0:tftp 0.0.0.0:*
udp UNCONN 0 0 *:tftp *:*

This should confirm that that the TFTP service is running and listening, and is not being blocked by the firewall

  1. From the TFTP server (assuming Linux, in this case Raspberry Pi) install  'iperf' 
    sudo apt-get install iperf

    Then run:

    sudo iperf -s -u -p 69

From another VM (In this case I'm using Ubuntu) install 'iperf'  (same as above)

Then run:

iperf -c [ip of the rpi server computer eg 192.168.1.2] -u -p 69
example:
iperf -c 192.168.0.2 -u -p 69

In my example my TFTP server:

pi@raspberrypi:~ $ sudo iperf -s -u -p 69
------------------------------------------------------------
Server listening on UDP port 69
Receiving 1470 byte datagrams
UDP buffer size: 176 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.0.2 port 69 connected with 192.168.0.136 port 58439 (peer 2.1.1-alpha)
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 3] 0.0-10.0 sec 1.25 MBytes 1.05 Mbits/sec 0.037 ms 1/ 895 (0.11%)

And my TFTP client:
dbutch@ubuntutmp:~$ iperf -c 192.168.0.2 -u -p 69
------------------------------------------------------------
Client connecting to 192.168.0.2, UDP port 69
Sending 1470 byte datagrams, IPG target: 11215.21 us (kalman adjust)
UDP buffer size: 208 KByte (default)
------------------------------------------------------------
[ 1] local 192.168.0.136 port 58439 connected with 192.168.0.2 port 69
[ ID] Interval Transfer Bandwidth
[ 1] 0.0000-10.0154 sec 1.25 MBytes 1.05 Mbits/sec
[ 1] Sent 896 datagrams
[ 1] Server Report:
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 1] 0.0000-10.0141 sec 1.25 MBytes 1.05 Mbits/sec 0.036 ms 1/895 (0.11%)
dbutch@ubuntutmp:~$

  1. Finally, to confirm once and for all that the TFTP server is configured correctly and is indeed able to send the tramp file:

    From the ubuntu client server:

    dbutch@ubuntutmp:~$ tftp 192.168.0.2
    tftp> get tramp
    Received 111 bytes in 0.0 seconds
    tftp>

    So it's working! Great. Now here's my problem, when I attempt to boot one of my autodeploy clients I get the following:

dbutch1976_0-1649699157354.png

dbutch1976_1-1649699186922.png

 

 

  1. Next, to confirm my DHCP setting I downloaded a utility called DHCPtest-0.7-win64.exe. This appears to confirm that that my DHCP server settings including option 67 are set correctly:

dbutch1976_2-1649699208161.png

 

  1. I go back to my unbuntu test VM and I confirm that I can download both the tramp file and undionly.kpxe.vmw-hardwired:

dbutch1976_3-1649699233527.png

 

So this is where I get stumped. I'm not sure exactly what's happening when I boot the test client or which point they are failing on. Are they receiving the tramp and undionly.kpxe.vmw-hardwired files? If so what is causing them to fail to boot at that point? 

 

 

 







 

 

 

 

 

 

 

Reply
0 Kudos
dbutch1976
Hot Shot
Hot Shot
Jump to solution

I was able to confirm independently that the client is definitely able to receive the tramp file. I did this by deleting the contents of the directory, which cause the autodeploy clients to boot with an error specific to the tramp file:

dbutch1976_0-1650020365995.png

 

Once I upload the unpacked contents of the deploy-tftp.zip to the TFTP server the error now changes to this:

dbutch1976_1-1650020509081.png

Google hasn't been much help in resolving this. Can anyone tell me what stage of the boot process this is that the client is failing at? What happens in the boot process after the tramp file has been downloaded by the client?

Please help!

Reply
0 Kudos
dbutch1976
Hot Shot
Hot Shot
Jump to solution

Well I managed to fix this one myself. Long story short, I'm just learning Linux so I was copy pasting my setup. It wasn't until I decided to consolidate both my DHCP and DNS onto dnsmasq and reviewing my settings line by line that I found that there were some unnecessary settings.

Here are the steps I used to install dnsmasq:
https://fedoramagazine.org/dnsmasq-provide-dns-dhcp-services/#:~:text=dnsmasq%20is%20a%20lightweight....

And here are the final working settings in the /etc/dnsmasq.conf file:

#DNS settings
domain-needed
bogus-priv
expand-hosts
domain=LEBRINE.local
#TFTP settings
enable-tftp
tftp-no-fail
tftp-root=/tftpboot
tftp-unique-root
#Log locations
log-queries
log-facility=/var/log/dnsmasq.log
#DHCP settings
interface=eth0
bind-dynamic
dhcp-range=192.168.0.10,192.168.0.200,255.255.255.0,12h
dhcp-option=3,192.168.0.1
dhcp-option=6,192.168.0.2
dhcp-option=66,192.168.0.2
dhcp-option=67,undionly.kpxe.vmw-hardwired
#DHCP Reservations
dhcp-host=00:0c:29:2b:25:2F,vcdessloch.lebrine.local,192.168.0.11,infinite
dhcp-host=00:0c:29:d4:78:f5,d20.lebrine.local,192.168.0.21,infinite
dhcp-host=00-24-9B-67-7A-F1,YOGA,192.168.0.188,infinite


Hope this helps someone!

 

Reply
0 Kudos