TFTP isn't working
-
This may be a stupid question but does Hyper V do any filtering or routing?
-
Mine doesn’t.
-
Is it possible iptables are active?
-
Easy to find out…
[CODE]iptables -L[/CODE]
EDIT: Although he did say he disabled UFW.
-
[quote=“Wayne Workman, post: 44932, member: 28155”]You’d be correct about that.
Not trying to sound harsh but, without knowing what OS you’re using (your install log would tell us that), I can’t provide the exact commands you would run for troubleshooting.
Check if the TFTP service is running. If you want specifics, we need specifics.
You might want to make sure Option 067 is correct, also. Generally, that should be set to undionly.kpxe[/quote]
Ubuntu 12.04, FOG 1.2.0. first thing I said.
Option 66 and 67 are correct.
-
sudo iptables -L
shows
Chain INPUT (policy Accept)
target prot opt source destinationChain FORWARD (policy Accept)
target prot opt source destinationChain OUTPUT (policy Accept)
target prot opt source destination -
$Sudo status tftpd-hpa shows:
tftpd-hpa start/running, process 1172I can also complete a tftp session to localhost.
-
does the switch have a redirector back to the ubuntu system?
Meaning is there firewalls blocking otherwise?
I ask this because you state locally you can tftp get the file, but outside of it you can’t. -
[quote=“Kyle Nash, post: 44948, member: 29243”]Ubuntu 12.04, FOG 1.2.0. first thing I said.
[/quote]Sorry about that. I get carried away sometimes.
-
[quote=“Tom Elliott, post: 44955, member: 7271”]does the switch have a redirector back to the ubuntu system?
Meaning is there firewalls blocking otherwise?
I ask this because you state locally you can tftp get the file, but outside of it you can’t.[/quote]Shouldn’t be. Its just a hyperv virtual switch with the default settings.
Just verified that I can see udp port 69 from other places on the network via nmap. I wonder if some of my random twiddling around changed that. Still get a tftp timeout, unfortunately.
-
Does this file exist? What’s in it?
[CODE]/etc/xinetd.d/tftp[/CODE]
What value does it have for server_args ? That’s the actual location of your tftp folder.Can you try to change permissions on /tftpboot to 444 and try again? (Read only for everyone)
[CODE]chmod -R 444 /tftpboot[/CODE]After that, try restarting the service:
[CODE]sudo service xinetd restart[/CODE]Also, how valuable is this FOG install? Did you just build it? Does it have images on it? Are other things running on it? Is it a clean install? How many times have you ran the installer for FOG?
Also, when I get to work tomorrow, I’ll share my exact Hyper-V Virtual Switch settings here, along with my NIC bindings/bridging setup. I remember it being something of a headache to get working correctly…
Resources used:
[url]http://ubuntuforums.org/showthread.php?t=1806090[/url]
[url]http://www.thegeekstuff.com/2010/07/tftpboot-server/[/url]
[url]http://askubuntu.com/questions/201505/how-do-i-install-and-run-a-tftp-server[/url]#LetsMakeScripts
-
I’ve just done a fog setup today with the same (or very similar) problem. I can manually tftp and download a file:
Erics-iMac:~ eric$ tftp
tftp> connect 192.168.0.1
tftp> get boot.txt
Received 865 bytes in 0.0 secondsYet when I PXE boot a device, I get this:
[IMG]https://www.dropbox.com/s/fdyj95k3azzi948/Screenshot 2015-04-03 16.39.37.png?dl=1[/IMG]
Maybe the wrong files are available?
eric@fogbox:/tftpboot$ ls -al
total 2572
drwxr-xr-x 2 fog root 4096 Apr 3 14:57 .
drwxr-xr-x 25 root root 4096 Apr 3 15:49 …
-rw-r–r-- 1 fog root 840 Apr 3 14:57 boot.txt
-rw-r–r-- 1 root root 293 Apr 3 14:57 default.ipxe
-rw-r–r-- 1 fog root 389009 Apr 3 14:57 ipxe.kkpxe
-rw-r–r-- 1 fog root 389057 Apr 3 14:57 ipxe.kpxe
-rw-r–r-- 1 fog root 388044 Apr 3 14:57 ipxe.krn
-rw-r–r-- 1 fog root 389073 Apr 3 14:57 ipxe.pxe
-rw-r–r-- 1 fog root 25340 Apr 3 14:57 memdisk
-rw-r–r-- 1 fog root 16794 Apr 3 14:57 pxelinux.0.old
-rw-r–r-- 1 fog root 165088 Apr 3 14:57 snponly.efi
-rw-r–r-- 1 fog root 101989 Apr 3 14:57 undionly.kkpxe
-rw-r–r-- 1 fog root 102037 Apr 3 14:57 undionly.kpxe
-rw-r–r-- 1 fog root 382650 Apr 3 14:57 undionly.kpxe.INTEL
-rw-r–r-- 1 fog root 102053 Apr 3 14:57 undionly.pxe-rw-r–r-- 1 fog root 147728 Apr 3 14:57 vesamenu.c32
Or perhaps one of these settings is wrong? (under FOG configuration > FOG settings):
[IMG]https://www.dropbox.com/s/qwsg7etna22ehp0/Screenshot 2015-04-03 16.43.53.png?dl=1[/IMG]I’m relatively new to FOG, but have plenty of linux experience. I’m happy to do troubleshooting. I’m also happy to dive in to some technical documentation on how FOG works to figure it out myself (can anyone link me to some, my google fu is weak today). Any pointers would be much appreciated.
-
@buzzzz: AFAIK these are two very different issues. Your TFTP seems to work fine. My guess is that your next-server/filename settings might be broken or an intermediate layer 3 switch is tampering with the filename (don’t laugh, seen this a couple of times!). I think you should get into wireshark/tcpdump to really see what’s going on.
[CODE]sudo tcpdump -i eth0 -w tftp_dump.pcap udp[/CODE]
Startup the client then, wait till it fails, stop tcpdump (ctrl+c), transfer the PCAP file to your PC and examine it using wireshark (helpful display filters are ‘bootp’ and ‘tftp’)…@Kyle Nash: State ‘open|filtered’ is not a great answer but actually it’s all you can ask from a normal scan. UDP protocol doesn’t have a 3-way-handshake and is therefore is not that easy to scan than TCP is. UDP scanning is more a reverse kind of thing. IF you get a closed answer you know it is closed but if you don’t get an answer it could be for several different reasons (port is open but does not answer because you send a UDP packet with empty payload, packet was lost, packet was silently dropped, ICMP rate-limiting on the server kicked in -> no ICMP answer). Making a long story short… You need to send UDP data to find out if TFTP is working via remote access. Either use a normal tftp client (I know you tried it before) or give nmap a shot:
[CODE]sudo nmap -sU -p 69 --script tftp-enum.nse <tftp-server-ip>[/CODE]Could you please run tcdpump on your FOG server too (see above)? Boot up the client and examine the dump file using wireshark. My guess is that you see DHCP traffic (display filter bootp) but no tftp traffic. In case that’s true take a closer look at the DHCP packets (next-server, filename options). Are those all correct?
What does your network setup look like? Could you connect the client to the FOG server using a hub or dump mini switch just for testing. Possibly one of your intermediate switches or routers is blocking TFTP…
-
Thanks Uncle Frank, I’ll get testing now, and open another thread when I’m done. Sorry I didn’t mean to hijack your thread Kyle Nash!
-
In addition to what Uncle Frank said, the next server / filename is DHCP options 066 and 067… if that helps…
I would highly recommend building the pcap file as he said (if you don’t have luck with the other ideas), this guy has solved more issues by dredging through pcap files than you would think…
-
[quote=“Kyle Nash, post: 44926, member: 29243”]chmod 777 on /tftpboot… didn’t do the trick.[/quote]
I’d like to add that [CODE]chmod 777 /tftpboot[/CODE] will only change permissions on the /tftpboot folder, not the files in it!
Use the recursive flag for everything in a directory to inherit the permissions you assign…
[CODE]chmod -R 777 /tftpboot[/CODE]
If that doesn’t work, try this… I’ve read in some posts on the net that TFTP won’t work for remote users unless the files it’s giving are READ ONLY for everyone else… Because this is TFTP’s [U]only[/U] security… I know many give the folder 777 permissions, but this is just pure curiosity… and can be changed back easily.
[CODE]chmod -R 444 /tftpboot[/CODE]
-
Some Hyper-V screen shots for one of our servers that is running FOG…
Bear in mind, I configured a static IP for the FOG server via the Fedora 21 OS.
NIC Overview
[IMG]http://s10.postimg.org/fu5oos6fd/NIC_overview.png[/IMG]NIC 2
[IMG]http://s7.postimg.org/8ce5q3dnv/NIC2.png[/IMG]Hyper-V virtual adapter
[IMG]http://s10.postimg.org/pisdcw4jt/Hyper_V_virtual_adapter.png[/IMG]Hyper-V virtual adapter IPv4 properties
[IMG]http://s23.postimg.org/71n5syxsb/Hyper_V_Virtual_Adapter_ip4.png[/IMG]Hyper-V virtual adapter - IPv6 properties
[IMG]http://s10.postimg.org/fv1w6gsnd/Hyper_V_Virtual_Adapter_ipv6_properties.png[/IMG]Virtual Switch - Overview
[IMG]http://s21.postimg.org/3viul08yf/Virtual_Switch_Overview.png[/IMG]Virtual Switch - Extensions
[IMG]http://s28.postimg.org/urj4bvykt/Virtual_Switch_Extensions.png[/IMG]Virtual Switch - MAC address range
[IMG]http://s11.postimg.org/z0zvoujnn/Virtual_Switch_Mac_Address_Range.png[/IMG]FOG NIC - Overview
[IMG]http://s17.postimg.org/dshdq4omn/FOG_NIC_Overview.png[/IMG]FOG NIC - Hardware Acceleration
[IMG]http://s12.postimg.org/t2orzls7h/FOG_NIC_Hardware_Acceleration.png[/IMG]FOG NIC - Fail Over
[IMG]http://s7.postimg.org/vliubq57v/FOG_NIC_Fail_over.png[/IMG]FOG NIC - Advanced Features
[IMG]http://s21.postimg.org/4vrizohnb/FOG_NIC_Advanced_Features.png[/IMG] -
[quote=“Wayne Workman, post: 44960, member: 28155”]Does this file exist? What’s in it?
[CODE]/etc/xinetd.d/tftp[/CODE]
What value does it have for server_args ? That’s the actual location of your tftp folder.[B]That file does not exist.[/B]
Can you try to change permissions on /tftpboot to 444 and try again? (Read only for everyone)
[CODE]chmod -R 444 /tftpboot[/CODE]After that, try restarting the service:
[CODE]sudo service xinetd restart[/CODE][B]Done, didn’t fix it. :([/B]
Also, how valuable is this FOG install? Did you just build it? Does it have images on it? Are other things running on it? Is it a clean install? How many times have you ran the installer for FOG?
[B]Install isn’t valuable at all. Nothing on it. Nothing else running on it. Have only run the installer once.[/B]
Also, when I get to work tomorrow, I’ll share my exact Hyper-V Virtual Switch settings here, along with my NIC bindings/bridging setup. I remember it being something of a headache to get working correctly…
[B]That would be immensely helpful. I’m guessing that’s the problem.[/B]
Resources used:
[url]http://ubuntuforums.org/showthread.php?t=1806090[/url]
[url]http://www.thegeekstuff.com/2010/07/tftpboot-server/[/url]
[url]http://askubuntu.com/questions/201505/how-do-i-install-and-run-a-tftp-server[/url]#LetsMakeScripts[/quote]
-
How are you running DHCP? What is it on?
Also, can you try making this file?
[CODE]/etc/xinetd.d/tftp[/CODE]
[CODE]service tftp
{
protocol = udp
port = 69
socket_type = dgram
wait = yes
user = nobody
server = /usr/sbin/in.tftpd
server_args = -s /tftpboot
disable = no
}[/CODE]restart the service
[CODE]sudo service xinetd restart[/CODE]Test tftp
Create a file named test.txt with some content in /tftpboot path of the tftp server
[CODE]sudo echo “Is my TFTP service working?” > /tftpboot/test.txt[/CODE]On some other system follow the following steps.
[CODE]tftp x.x.x.x
tftp> get test.txt
//Sent 159 bytes in 0.0 seconds
tftp> quit
cat test.txt[/CODE] -
[quote=“Uncle Frank, post: 44969, member: 28116”]@buzzzz: AFAIK these are two very different issues. Your TFTP seems to work fine. My guess is that your next-server/filename settings might be broken or an intermediate layer 3 switch is tampering with the filename (don’t laugh, seen this a couple of times!). I think you should get into wireshark/tcpdump to really see what’s going on.
[CODE]sudo tcpdump -i eth0 -w tftp_dump.pcap udp[/CODE]
Startup the client then, wait till it fails, stop tcpdump (ctrl+c), transfer the PCAP file to your PC and examine it using wireshark (helpful display filters are ‘bootp’ and ‘tftp’)…@Kyle Nash: State ‘open|filtered’ is not a great answer but actually it’s all you can ask from a normal scan. UDP protocol doesn’t have a 3-way-handshake and is therefore is not that easy to scan than TCP is. UDP scanning is more a reverse kind of thing. IF you get a closed answer you know it is closed but if you don’t get an answer it could be for several different reasons (port is open but does not answer because you send a UDP packet with empty payload, packet was lost, packet was silently dropped, ICMP rate-limiting on the server kicked in -> no ICMP answer). Making a long story short… You need to send UDP data to find out if TFTP is working via remote access. Either use a normal tftp client (I know you tried it before) or give nmap a shot:
[CODE]sudo nmap -sU -p 69 --script tftp-enum.nse <tftp-server-ip>[/CODE]Could you please run tcdpump on your FOG server too (see above)? Boot up the client and examine the dump file using wireshark. My guess is that you see DHCP traffic (display filter bootp) but no tftp traffic. In case that’s true take a closer look at the DHCP packets (next-server, filename options). Are those all correct?
What does your network setup look like? Could you connect the client to the FOG server using a hub or dump mini switch just for testing. Possibly one of your intermediate switches or routers is blocking TFTP…[/quote]
Ran TCP dump / wireshark.
First: DHCP isn’t being handled by the FOG server, but by our DHCP server. That all seems to be working correctly. I can’t actually access the fog server with a standalone TFTP client let alone via PXE boot or whatever.
tcpdump/wireshark show absolutely no data from the client machine, or the machine doing the scanning. I actually even ran a scan from another virtual server on the same host/virtual switch. Looking like this may be a hyperv issue. Any ideas?
