Bug 29529 - in.tftpd not allowing files to be uploaded to system
in.tftpd not allowing files to be uploaded to system
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: tftp (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Helge Deller
David Lawrence
:
: 30294 36738 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-02-26 04:44 EST by Andrew Watts
Modified: 2007-04-18 12:31 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-04-12 05:51:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Andrew Watts 2001-02-26 04:44:48 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)


I'm running a vanilla RedHat 7 installation and have turned in.tftpd
on in the xinetd.d folder "tftp" configuration file.

The in.tftpd daemon will serve files up to clients without any problem.

Placing files back onto the system from all clients attempted, results in 
a timeout on the client end. Clients used include a 
RedHat 5.1 system, a RedHat 6.2 system and various routers and
access devices. 

Further investigation shows that the tftp session sets up OK 
(/var/log/secure shows this). On some occasions the in.tftpd server 
generates a "read: Connection refused" (/var/log/messages shows this).

Using strace to attach to the running process, shows the process sitting 
in a "recv" call which times out about 10 times before finally
erroring out and closing the process. The system does receive the filename 
and path from the client, and seems to be waiting for that
file to be sent.

Using tcpdump shows the client attempting to send data to the server but 
the server not acknowledging the request to send.

The file which is being uploaded is on the system as an empty, fully 
writable file owned by nobody, but also checked as owned by root, and 
other system users. 

The file is never written to.

Reproducible: Always
Steps to Reproduce:
1. Turn in.tftpd on. (Default configuration)
2. Create a file in /tftpboot and make it writeable to all users
2. Attempt to upload a file to the system using that files name.

	

Actual Results:  File will not be written to.

Expected Results:  File should be written to.

No special network restrictions are setup on the system that would
stop this file transfer taking place. The system has had no changes
from the default RedHat 7 configuration.
Comment 1 Pekka Savola 2001-02-28 04:07:22 EST
This is a known problem due to a bug -- tftp puts don't work at all.

Corrected RPMs are available at e.g.: ftp://ftp.redhat.com/pub/redhat/beta/wolverine/en/OS/i386/RedHat/RPMS/


*** This bug has been marked as a duplicate of 18128 ***
Comment 2 Helge Deller 2001-03-01 11:14:18 EST
tftp-0.17-9 still doesn't fix tftp uploads
Comment 3 Pekka Savola 2001-03-01 13:42:09 EST
My tests indicate that it's tftp client that it's broken.  I grabbed tftp-0.16-5 compiled on RHL62, and uploads to 0.17-9 work
fine with it.

There are no compile warnings with tftp client 0.17-9 (except implicit declaration of memset, which doesn't cause this),
so this is most weird.  Perhaps reverting back to the beta for now might help ?
Comment 4 Helge Deller 2001-03-19 09:15:25 EST
*** Bug 30294 has been marked as a duplicate of this bug. ***
Comment 5 Tim Powers 2001-03-28 15:06:30 EST
I'm able to confirm that this is happening with 0.17-9. Get works, but put doesn't.

Tim
Comment 6 blaine 2001-04-12 05:51:07 EDT
A sniffer trace shows that tftp is failing to respond with correct block number 
to start the transfer.

The correct sequence is to ACK NR=0 . This would allow the client to begin the 
data transfer.

The failing tftp always responds to the TFTP WRQ with ACK NR=1 and the data 
transfer never gets started.
--
Blaine
Comment 7 Helge Deller 2001-04-18 15:42:06 EDT
This bug should now be fixed in tftp-0.17-11, available from rawhide or 
directly from ftp://people.redhat.com/hdeller/
Please also check your /etc/xinetd.d/tftp to have at least the following 
entries: 
        wait                    = yes
        user                    = root
        server                  = /usr/sbin/in.tftpd
        server_args             = -cs /tftpboot
        disable                 = no
(The -c in server_args enables the tftpd-server to create files),
and that user nobody has write-permissions on /tftpboot if you want to test 
uploads/puts.

Comment 8 Helge Deller 2001-04-20 17:50:58 EDT
*** Bug 36738 has been marked as a duplicate of this bug. ***
Comment 9 Tom Wood 2001-04-20 20:25:28 EDT
Version 0.17-11 still does not work.  No puts, no gets.  /etc/xinetd.d/tftp is as above, /tftpboot is owned by nobody.nobody, mode 777, file /tftpboot/testing is the same, tftp will not get the testing file.  Puts also don't work.
Comment 10 blaine 2001-04-20 23:33:27 EDT
I installed tftp-server-0.17-11 . Both puts and gets work for me. Check to see 
if your /usr/sbin/in.tftpd actually was updated.
Comment 11 Greg Adams 2001-04-24 08:42:59 EDT
The tftp-server-0.17-11still does not work . Using redhat rpm and did not
compile code. Has anyone had any luck? Does any  know if tftp compilied code
work? Below is my setup and log files. Does anyone have any suggestions? I have
verified that /usr/sbin/in.tftpd is updated.

[root@blacksun /]# ls -la /tftpboot
total 12
drwxrw-rw-    3 root     nobody       4096 Apr 24 08:26 .
drwxr-xr-x   20 root     root         4096 Apr 24 07:45 ..
drwxr-xr-x    2 root     root         4096 Mar  2 09:19 lost+found

secure log file.
Apr 24 08:27:29 blacksun xinetd[7628]: START: tftp pid=7633 from=198.168.200.1
Apr 24 08:27:49 blacksun xinetd[7628]: START: tftp pid=7635 from=198.168.200.1

messages log file no entries

federal.net.nih.gov#copy run tftp
Address or name of remote host []? 198.168.200.222
Destination filename [federal.net.nih.gov-confg]?
/tftpboot/federal.net.nih.gov-confg
TFTP: error code 2 received - Access violation

%Error opening tftp://198.168.200.222//tftpboot/federal.net.nih.gov-confg
(Undefined error)
federal.net.nih.gov#copy run tftp                      
Address or name of remote host []? 198.168.200.222              
Destination filename [federal.net.nih.gov-confg]? 
TFTP: error code 2 received - Access violation

%Error opening tftp://198.168.200.222/federal.net.nih.gov-confg (Undefined
error)
federal.net.nih.gov#

tftp flie
# 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		= -cs /tftpboot
	disable			= no
}

Comment 12 Helge Deller 2001-04-24 09:28:23 EDT
please try

ln -s /tftpboot /tftpboot/tftpboot 
chown nobody.nobody /tftpboot/tftpboot

on your TFTP-server and send again.

Comment 13 Helge Deller 2001-04-24 10:03:26 EDT
Please ignore my last comment -
Try the following steps instead:

rm -rf /tftpboot/tftpboot # in case you already created /tftpboot/tftpboot
ln -s . /tftpboot/tftpboot
chmod 775 /tftpboot/tftpboot
chown nobody.nobody /tftpboot
chmod 775 /tftpboot

which creates the symlink /tftpboot/tftpboot and fixes the owner and 
read/write permissions.

Comment 14 Greg Adams 2001-04-24 10:55:48 EDT
added the following commands and still could not get tftp-server to work.

ln -s /tftpboot /tftpboot/tftpboot 
chown nobody.nobody /tftpboot/tftpboot

no messages in log file

Secure file log
Apr 24 10:40:14 blacksun xinetd[7628]: START: tftp pid=7733 from=192.168.200.1
Apr 24 10:40:37 blacksun xinetd[7628]: START: tftp pid=7735 from=192.168.200.1
Apr 24 10:40:57 blacksun xinetd[7628]: START: tftp pid=7737 from=192.168.200.1

error message from cisco router
federal.net.nih.gov#copy run tftp
Address or name of remote host []? 192.168.200.222
Destination filename [federal.net.nih.gov-confg]? 
TFTP: error code 2 received - Access violation

%Error opening tftp://192.168.200.222/federal.net.nih.gov-confg (Undefined
error)
federal.net.nih.gov#copy run tftp  
Address or name of remote host []? 192.168.200.222
Destination filename [federal.net.nih.gov-confg]? /tftpboot/federal.net.nih.gov
TFTP: error code 2 received - Access violation

%Error opening tftp://192.168.200.222//tftpboot/federal.net.nih.gov (Undefined
error)
federal.net.nih.gov#copy run tftp                
Address or name of remote host []? 192.168.200.222              
Destination filename [federal.net.nih.gov-confg]?
/tftpboot/t/federal.net.nih.goftpboot/federal.net.nih.gov
TFTP: error code 2 received - Access violation

%Error opening tftp://192.168.200.222//tftpboot/tftpboot/federal.net.nih.gov
(Undefined error)
federal.net.nih.gov#Connection closed by foreign host.
[root@blacksun /root]# 

Comment 15 Greg Adams 2001-04-24 11:01:38 EDT
added the following commands as suggested.
chmod 775 /tftpboot
chown 775 /tftpboot/tftpboot

This made the tftp-server to work correctly.
Thanks
Comment 16 Jay Cuthrell 2002-02-21 15:34:46 EST
In case anyone else was searching for this here is some more output from 
devices trying to put files:

# copy log boot.log tftp 192.168.1.100 /tftpboot/test
Connecting (\)
%% Transfer rejected by server

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