Getting timeouts on TFTP on F15 as well as F14

[Frantisek Hanzlik]

Aaron Gray wrote:
> On 11 October 2011 00:05, Frantisek Hanzlik <franta at hanzlici.cz <mailto:franta at hanzlici.cz>>
> wrote:
> 
>     Aaron Gray wrote:
>     > On 10 October 2011 23:31, Frantisek Hanzlik <franta at hanzlici.cz
>     <mailto:franta at hanzlici.cz> <mailto:franta at hanzlici.cz <mailto:franta at hanzlici.cz>>>
>     > wrote:
>     >
>     >     Aaron Gray wrote:
>     >     > On 10 October 2011 22:20, Frantisek Hanzlik <franta at hanzlici.cz
>     <mailto:franta at hanzlici.cz>
>     >     <mailto:franta at hanzlici.cz <mailto:franta at hanzlici.cz>> <mailto:franta at hanzlici.cz
>     <mailto:franta at hanzlici.cz> <mailto:franta at hanzlici.cz <mailto:franta at hanzlici.cz>>>>
>     >     > wrote:
>     >     >
>     >     >     Aaron Gray wrote:
>     >     >     ...
>     >     >     >
>     >     >     >     4) if You use firewall (iptables), You should load nf_conntrack_tftp module,
>     >     >     >     for tracking ephemeral ports. That means /etc/sysconfig/iptables-config
>     should
>     >     >     >     contain line as:
>     >     >     >     ...
>     >     >     >     IPTABLES_MODULES="nf_conntrack_tftp"
>     >     >     >     ...
>     >     >     >     (other module is for NATting tftp connection)
>     >     >     >
>     >     >     >
>     >     >     > using localhost
>     >     >
>     >     >     loopback (lo interface) is subject to firewall rules too. And Your tcpdump
>     >     >     below show IP addresses 192.168.0.4 and 192.168.0.5 - they perhaps are not
>     >     >     at lo loopback interface?
>     >     >     Have You firewall active?
>     >     >
>     >     >
>     >     > I wrote a firewall rule :-
>     >     >
>     >     > -A INPUT -m state --state NEW -m udp -p udp --dport 69 -j ACCEPT
>     >
>     >     Then You should have (best at beginning of filter table rules) rule:
>     >
>     >     -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
>     >
>     >
>     > Okay.
>     >
>     >
>     >
>     >     (and nf_conntrack_tftp module listed in "/etc/sysconfig/iptables-config",
>     >     as I wrote before). You must restart iptables after these changes.
> 
>     Is nf_conntrack_tftp module loaded? You should obtain similar output:
>     # lsmod |grep tftp
>     nf_conntrack_tftp       3325  0
>     nf_conntrack           56162  4 nf_conntrack_tftp,nf_conntrack_ipv4,nf_conntrack_ipv6,xt_state
> 
> 
> No contrack_tftp running, but it is not needed with localhost TFTP test.

What You mean with "localhost TFTP test"? When You run iptables firewall,
You must consider EVERY connection, even if it is from tftp client running
at same machine as tftp server (e.g. with command "tftp 127.0.0.1 -c get FILE").
And it seems as Your tftp client run from machine with IP=192.168.0.5
and server run at another with IP=192.168.0.4, right?

> How do I load conntrack_tftp ?

You had it above - right "Fedora way" is specify module in file
"/etc/sysconfig/iptables-config", as value of IPTABLES_MODULES variable:

IPTABLES_MODULES="nf_conntrack_tftp"

(and then restart Your firewall: "service iptables restart").
But, for symplifying things (which is advisable, You solve this simple
problem third day!), when it isn't security risk, You can stop firewall:

service iptables stop

and run it again after verify tftp is OK without it.


>     >     >     >     5) /var/log/messages should contain entries as:
>     >     >     >     Oct 10 20:28:32 ns xinetd[1908]: START: tftp pid=5315 from=192.168.1.22
>     >     >     >     Oct 10 20:28:42 ns xinetd[1908]: EXIT: tftp status=0 pid=5315
>     duration=10(sec)
>     >     >     >
>     >     >     >
>     >     >     > Oct 10 21:09:07 gold xinetd[13402]: Exiting...
>     >     >     > Oct 10 21:09:12 gold xinetd[13650]: xinetd Version 2.3.14 started with
>     libwrap loadavg
>     >     >     > labeled-networking options compiled in.
>     >     >     > Oct 10 21:09:12 gold xinetd[13650]: Started working: 1 available service
>     >     >
>     >     >     There isn't nothing about that xinetd starts tftp daemon. Mentioned
>     >     >     "1 available service" is tftp?
>     >     >     This command show only tftp:
>     >     >
>     >     >     # grep '^[[:blank:]]*disable.*no' /etc/xinetd.d/*
>     >     >     /etc/xinetd.d/tftp:     disable = no
>     >     >
>     >     >
>     >     > I tested it and it is the only xinetd demon running
>     >     >
>     >     >
>     >     >     Next command display some similar at Your server?:
>     >     >     # netstat -a -n -p --ip|grep 69
>     >     >     udp        0      0 0.0.0.0:69 <http://0.0.0.0:69> <http://0.0.0.0:69>        
>       0.0.0.0:*      1595/xinetd
> 
>     What netstat now displays? Is xinetd listening at udp 69 ??
> 
> [root at XXXX ang]# netstat -a -n -p --ip|grep 69
> udp        0      0 0.0.0.0:69      0.0.0.0:*     1127/xinetd   

Okay, now when You connect with tftp client, You should see in /var/log/messages
entries from xinetd daemon about starting tftp daemon.

Bye