I am attempting to get a really simple TFTP server up and running for the purpose of working as an IPXE boot server.
However everything I seem to do doesn't seem to work to get the server to be able to communicate with a remote client. I can get the client to communicate across localhost which seems to work great.
tftp $TFTP_SERVER -c get README
While this works great on local host, it defeats the purpose of having a server who can talk remotely.
The tftp config file reads as follows:
[root@ipxe tmp]# cat /etc/xinetd.d/tftp
# default: off
# description: The tftp server serves files using the trivial file transfer \
# protocol. The tftp protocol is often used to boot diskless \
# workstations, download configuration files to network-aware printers, \
# and to start the installation process for some operating systems.
service tftp
{
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -vvvvv -c -s /ipxe/
disable = no
per_source = 11
cps = 100 2
flags = IPv4
}
NOTE: FOR DEBUGGING PURPOSES I HAVE DONE THE FOLLOWING:
I have disabled the firewall:
[root@ipxe ~]# service iptables stop
iptables: Setting chains to policy ACCEPT: filter [ OK ]
iptables: Flushing firewall rules: [ OK ]
iptables: Unloading modules: [ OK ]
[root@ipxe ~]# chkconfig iptables off
I have disabled SELinux because it sucks.
[root@ipxe tmp]# cat /etc/selinux/config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of these two values:
# targeted - Targeted processes are protected,
# mls - Multi Level Security protection.
SELINUXTYPE=targeted
I have also rebooted a large number of times.
No matter what I seem to try, even changing CentOS version to 7 and repeating the process, the most I can get from tftp is:
Jan 30 22:52:01 ipxe xinetd[2013]: START: tftp pid=2265 from=192.168.10.186
Jan 30 22:52:01 ipxe in.tftpd[2266]: RRQ from 192.168.10.186 filename README
Jan 30 22:52:06 ipxe in.tftpd[2267]: RRQ from 192.168.10.186 filename README
Jan 30 22:52:11 ipxe in.tftpd[2268]: RRQ from 192.168.10.186 filename README
Jan 30 22:52:20 ipxe in.tftpd[2269]: RRQ from 192.168.10.186 filename README
Jan 30 22:52:25 ipxe in.tftpd[2270]: RRQ from 192.168.10.186 filename README
Jan 30 22:52:30 ipxe in.tftpd[2271]: RRQ from 192.168.10.186 filename README
Jan 30 22:52:35 ipxe in.tftpd[2272]: RRQ from 192.168.10.186 filename README
Jan 30 22:52:40 ipxe in.tftpd[2275]: RRQ from 192.168.10.186 filename README
I can obviously ping the system and ssh into it and there seems to be no network issues of any kind that I can see.
What in heaven's name am I missing here? What is the next logical line in diagnosis of the issue? I'm almost ready to file a bug on the issue.
Best Answer
Turns out that when testing TFTP, you have to punch a hole through both the server AND the client's firewall. That doesn't make a lot of sense since most of the articles online will talk about selinux as well as disabling the firewall on the tftp server.
The server was working fine and even though I tried it from multiple different operating system types, from Windows to Linux to Mac, all 3 of those different tftp clients need to have a rule put into their firewall to allow access to tftp.
Normally, this is accompanied by a message in the tftp server which will say something to the tune of "No route to host", but that step was omitted for some reason.
If you were like me and are not sure what to do even though you have followed all of the direction. Make sure you punch a hole through the client's firewall as well.