TFTP: тайм-аут передачи на сервере RHEL 6

Я упираюсь в стену, пытаясь заставить tftp работать с использованием RHEL 6 в качестве сервера. Ошибка от клиента - это просто "время ожидания передачи истекло". На сервере я вижу трафик UDP 69, поступающий от моего клиента, но я не вижу пакетов, возвращающихся к клиенту. В журналах я вижу, что xinetd обрабатывает запрос. На сервере я использую tftp версию:

tftp-server-0.49-8.el6.x86_64

Вот команда, которую я запускаю от клиента.

tftp -v 192.168.100.10 -c get file

Сторона сервера tcpdump:

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

И это повторяется снова и снова, пока не истечет время передачи. Вот мой лог-файл:

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

И это также повторяется снова и снова, пока не истечет время передачи. Моя конфигурация:

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 находится вверху:

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

Загружены модули ядра:

[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 разрешает:

[root@server tftpboot]# getenforce 
Permissive

Я разрешил все в hosts.allow:

xinetd : ALL

И я знаю, что сервис слушает:

[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    

В мире есть RX в каталоге tftpboot:

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

И мир прочитал файлы внутри. Другое, что я пробовал.

1) Использование tcp вместо udp = FAIL

2) Перемещение корневого каталога tftp = FAIL

3) И как видите, у меня уже включено подробное ведение журнала для tftp

4) Смена пользователя в конфиге = FAIL

Я сейчас в растерянности. Кто-нибудь раньше сталкивался с этой проблемой?

ОБНОВИТЬ: Вот моя полная конфигурация iptables:

*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

Кроме того, я отключил iptables и все еще получаю то же сообщение об истечении времени ожидания передачи.

ОБНОВЛЕНИЕ # 2 - Я также добавил следующее в iptables, но iptables недоволен.

-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

Ошибка:

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

ОБНОВЛЕНИЕ # 3

Не то, чтобы это могло помочь, но мне было любопытно посмотреть, действительно ли я видел, как связанные пакеты приходят и покидают брандмауэр. Вот снимок двух правил, которые я вставил, чтобы разрешить как 69 к клиенту, так и от него, а также порты, необходимые для передачи данных.

До начала передачи:

 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 

После попытки переноса:

   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 

Таким образом, это говорит мне, что это не брандмауэр, и если я не вижу ответных пакетов с tcpdump, это что-то среднее, возможно, само приложение.