TFTP: transfer time out on RHEL 6 server

Question

I am hitting a wall here trying to get tftp to work using RHEL 6 as a server. The error, from the client, is simply "transfer timed out". On the server, I can see udp 69 traffic coming in from my client but I do not see any packets returning to the client. In the logs I can see xinetd is processing the request. On the server I am running tftp version:

tftp-server-0.49-8.el6.x86_64

Here is the command I run from the client.

tftp -v 192.168.100.10 -c get file

Tcpdump server side:

13:54:02.136438 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 49)
192.168.100.11.37126 > 192.168.100.10.tftp: [udp sum ok]  21 RRQ "file" netascii

And this repeats over and over until the transfer times out. Here is my logfile:

Jul 26 13:54:22 server in.tftpd[7068]: RRQ from 192.168.100.11 filename file

And this also repeats over and over until the transfer times out. My config:

service tftp
{
    disable = no
    socket_type             = dgram
    protocol                = udp
    wait                    = yes
    user                    = root
    server                  = /usr/sbin/in.tftpd
    server_args             = -v -v -v -s /var/lib/tftpboot
    per_source              = 11
    cps                     = 100 2
    flags                   = IPv4
}

Iptables rule is at the top:

[root@server tftpboot]# iptables -L --line-numbers | grep tftp
1    ACCEPT     udp  --  anywhere             anywhere             state NEW udp dpt:tftp

Kernel modules are loaded:

[root@server tftpboot]# lsmod | grep tftp
nf_conntrack_tftp       4814  0 
nf_conntrack           79537  4     nf_conntrack_tftp,nf_conntrack_ipv4,nf_conntrack_ipv6,xt_state

SELinux is permissive:

[root@server tftpboot]# getenforce 
Permissive

I have allowed all in hosts.allow:

xinetd : ALL

And I know the service is listening:

[root@server tftpboot]# lsof -i :69
COMMAND    PID USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
in.tftpd  7023 root    0u  IPv4 11763412      0t0  UDP *:tftp 
xinetd   32761 root    5u  IPv4 11763412      0t0  UDP *:tftp 
[root@server tftpboot]# netstat -anp | grep ":69"
udp        0      0 0.0.0.0:69                  0.0.0.0:*                                7023/in.tftpd

world has RX on the tftpboot dir:

[root@server lib]# ll | grep tftp*
drwxr-xr-x.  2 root      root     4096 Jul 26 12:17 tftpboot

And world has read on the files inside. Other things I have tried.

1) Using tcp instead of udp = FAIL

2) Moving the tftp root directory = FAIL

3) And as you can see I already have verbose logging turned on for tftp

4) Changing the user in the config = FAIL

I am at a loss at this point. Has anyone run into this problem before?

UPDATE: Here is my full iptables config:

*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [1:136]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p udp -m udp --dport 69 -m state --state NEW,ESTABLISHED -  j ACCEPT
-A INPUT -j DROP
COMMIT

Also, I have disables iptables and still get the same transfer timed out message.

UPDATE#2 - I have also added the following into iptables but iptables is not happy.

-A INPUT --sport 1024: --dport 1024: -m state --state ESTABLISHED -j   ACCEPT
-A OUTPUT --sport 1024: --dport 1024: -m state --state ESTABLISHED,RELATED -j ACCEPT

Error:

iptables: Applying firewall rules: iptables-restore v1.4.7: unknown option `--sport'

UPDATE #3

Not that this may help, but I was curious to see if in fact I saw related packets coming and and leaving the firewall. Here is a snapshot of the two rules I inserted to allow both 69 to and from the client as well as the ports needed for the data transfer.

Before transfer started:

 5      245 ACCEPT     udp  --  *      *       192.168.10.11         0.0.0.0/0           udp dpt:69 state NEW,ESTABLISHED 
   0        0 ACCEPT     udp  --  *      *       192.168.10.11         0.0.0.0/0           udp spts:1024:65535 dpts:1024:65535 state   ESTABLISHED 
--
   0        0 ACCEPT     udp  --  *      *       0.0.0.0/0             192.168.10.11      udp spt:69 state ESTABLISHED 
  30      960 ACCEPT     udp  --  *      *       0.0.0.0/0             192.168.10.11      udp spts:1024:65535 dpts:1024:65535 state  RELATED,ESTABLISHED

After transfer attempt:

   10      490 ACCEPT     udp  --  *      *       192.168.10.11        0.0.0.0/0           udp dpt:69 state NEW,ESTABLISHED 
    0        0 ACCEPT     udp  --  *      *       192.168.10.11            0.0.0.0/0           udp spts:1024:65535 dpts:1024:65535 state      ESTABLISHED 
 --
   0        0 ACCEPT     udp  --  *      *       0.0.0.0/0             192.168.10.11      udp spt:69 state ESTABLISHED 
   58     1856 ACCEPT     udp  --  *      *       0.0.0.0/0             192.168.10.11      udp spts:1024:65535 dpts:1024:65535 state  RELATED,ESTABLISHED

So this tells me its not the firewall and if I don't see return packets with tcpdump its something in between, perhaps maybe the application itself.

The return packet from the server uses a source port number different from 69 that it picks randomly (see http://tftp-server.com/tftp-server-help/tftp-protocol.html), so it is probably a firewall problem. Check out http://unix.stackexchange.com/questions/99270/iptables-rules-for-tftp-server, a question which describes the same symptoms you're experiencing. — Jeremy Dover, Jul 26 '16 at 20:09
You are not allowing ICMP. This will definitely cause you various connectivity problems, even if it isn't the cause of this particular problem. — Michael Hampton, Jul 26 '16 at 21:49
Jeremy - I looked at that link and tried a couple of those statements but getting an error. I have edited my question to include that. — user53029, Jul 26 '16 at 21:55
On Update #2, you are getting an error because you need to add -p udp to your syntax, before --sport. Otherwise iptables has no context for the port numbers. — Jeremy Dover, Jul 27 '16 at 00:11
Ok made the changes but still no luck. Not sure what else to try. — user53029, Jul 27 '16 at 12:16
First, please confirm that iptables rules you dumped in UPDATE 1, are the ones you got from CLI (I see a "- j" in the second "-A INPUT" with several spaces in beween and.. I guess it's wrong); Also, I saw references to 192.168.100.11, 192.168.100.10 and 192.168.10.11: 3 IPs seems too much :-) ; Afterwards, can you tell us if you've made some tests without any king of iptables filtering? Also, it would be useful to check relevant log messages logged by the tftpd daemon (/var/log/syslog, I guess): is the daemon telling something (that we are simply ignoring)? — Damiano Verzulli, Jul 31 '16 at 08:55

HBruijn · Answer 1 · 2016-07-26T20:42:04.567

Since you're using the state module in your iptables configuration to only allow NEW connections on the tftp port and you only posted an excerpt from your firewall config:

1 ACCEPT udp -- anywhere anywherestate NEWudp dpt:tftp

is that rule in the INPUT chain and is there also a generic -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT rule? (If so, that rule should probably be the first rule in your INPUT chain.)

Because although the UDP protocol itself is stateless the conntrack modules still seem to maintain some state information for UDP and you might have a case where the first UDP packet is accepted and every subsequent packet is regarded as either part of an "established" or "related" session rather than "new" and rejected.

I've updated my question to include all of my iptables config. I am still having the problem with or without iptables on. — user53029, Jul 26 '16 at 21:45

TFTP: transfer time out on RHEL 6 server

1 Answers1