Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 452678 - TFTP-server times out from remote hosts
Summary: TFTP-server times out from remote hosts
Alias: None
Product: Fedora
Classification: Fedora
Component: xinetd
Version: 9
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Jan Zeleny
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2008-06-24 13:48 UTC by Chuck
Modified: 2009-03-19 14:51 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-03-19 14:51:55 UTC

Attachments (Terms of Use)
Screen shot - Host administratively prohibited (deleted)
2008-06-25 14:01 UTC, Chuck
no flags Details

Description Chuck 2008-06-24 13:48:34 UTC
Description of problem:


tftp server only accepts connections from localhost, all remote requests seem to
time out.  Firewall and SELinux are disabled on the host.  Tested on localhost

tftp -c get pxelinux.cfg/default
Result: Successful

tftp localhost -c get pxelinux.cfg/default
Result: Successful

Routing Table:
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface       *        U     0      0        0 eth0
link-local      *          U     0      0        0 eth0
default         UG    0      0        0 eth0

eth0      Link encap:Ethernet  HWaddr 00:E0:B8:D0:11:E0  
          inet addr:  Bcast:  Mask:
          inet6 addr: fe80::2e0:b8ff:fed0:11e0/64 Scope:Link
          RX packets:109741 errors:0 dropped:0 overruns:0 frame:0
          TX packets:62328 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:151985399 (144.9 MiB)  TX bytes:4451829 (4.2 MiB)

lo        Link encap:Local Loopback  
          inet addr:  Mask:
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:18719 errors:0 dropped:0 overruns:0 frame:0
          TX packets:18719 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:3206201 (3.0 MiB)  TX bytes:3206201 (3.0 MiB)

How reproducible:

Steps to Reproduce:
1.  Install tftp-server with xinetd, start the service.
2.  Config for /etc/tftp:

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

3. Config for /etc/xinetd.conf

# This is the master xinetd configuration file. Settings in the
# default section will be inherited by all service configurations
# unless explicitly overridden in the service configuration. See
# xinetd.conf in the man pages for a more detailed explanation of
# these attributes.

# The next two items are intended to be a quick access place to
# temporarily enable or disable services.
#	enabled		=
#	disabled	=

# Define general logging characteristics.
	log_type	= SYSLOG daemon info 
	log_on_failure	= HOST
	log_on_success	= PID HOST DURATION EXIT

# Define access restriction defaults
#	no_access	=
#	only_from	=
#	max_load	= 0
	cps		= 50 10
	instances	= 50
	per_source	= 10

# Address and networking defaults
#	bind		=
#	mdns		= yes
	v6only		= no

# setup environmental attributes
#	passenv		=
	groups		= yes
	umask		= 002

# Generally, banners are not used. This sets up their global defaults
#	banner		=
#	banner_fail	=
#	banner_success	=

includedir /etc/xinetd.d
4. Put text file in /tftpboot/pxelinux.cfg/default

5. To be sure not rights issue, changes /tftpboot to 777 recursively.

5. On a remote host ran:

tftp -c get pxelinux.cfg/default

Actual results:

Return code 69 from tftp, text output of "Transfer timed out."

Expected results:

default text file downloaded to cwd.

Additional info:

Comment 1 Jan Safranek 2008-06-25 11:53:31 UTC
Can't reproduce the bug, everything works correctly in my environment with your
configuration. There must be something wrong in your network setup. Please check
that both the server and the client are not behind a firewall or NAT and (using
tcpdump, wireshark or so) if the TFTP messages from client arrive at the server
and back.

Comment 2 Chuck 2008-06-25 14:01:48 UTC
Created attachment 310266 [details]
Screen shot - Host administratively prohibited

I don't want to waste your time if this isn't a bug but on 64 bit version I get
this message, "Host administratively prohibited", when selinux and firewall are
disabled.  The only reason I am bringing this up again is because this has
worked without error on previous version of fedora, versions 5-8.

Comment 3 Chuck 2008-06-25 14:05:22 UTC
If I kill iptables, everything works ok, is this a bug with the firewall
configuration tool?

Comment 4 Jan Safranek 2008-06-26 08:41:47 UTC
It's _probably_ not 64-bit related. What does 'iptables -L' say when you disable
the firewal using the system-config-firwall tool? Does 'service iptables stop'
help afterwards? 

Comment 5 Chuck 2008-06-26 11:55:42 UTC
With IPTables Running and Firewall disabled:

[root@fog ~]# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            state
ACCEPT     icmp --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:ssh 
REJECT     all  --  anywhere             anywhere            reject-with

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
REJECT     all  --  anywhere             anywhere            reject-with

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination 

With IPTables Stopped:

[root@fog ~]# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Comment 6 Jan Safranek 2008-06-26 12:53:49 UTC
it looks good at the first sight.. The best you can do is to compare it with
Fedora8, if you have it at hand, and reassign the bug to system-config-firewall
(or whatever you used to create the rules)

Comment 7 Fedora Admin XMLRPC Client 2009-03-19 07:32:49 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 8 Jan Zeleny 2009-03-19 14:51:55 UTC
From previous comments I understand that this is not a bug => closing it

Note You need to log in before you can comment on or make changes to this bug.