Bug 18128 - TFTP put doesn't work at all
TFTP put doesn't work at all
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: tftp (Show other bugs)
7.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Bill Nottingham
:
: 20643 20730 21299 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-10-02 15:50 EDT by Need Real Name
Modified: 2014-03-16 22:16 EDT (History)
16 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-12-12 16:50:53 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
revert back to tftpd from netkit so tftp puts also work (1016 bytes, patch)
2000-11-19 09:48 EST, Pekka Savola
no flags Details | Diff
patch to fix broken tftp puts with hpa tftp (585 bytes, patch)
2000-12-09 16:53 EST, Pekka Savola
no flags Details | Diff

  None (edit)
Description Need Real Name 2000-10-02 15:50:01 EDT
Regardless of the permisions set on the tftp directory and/or the files in 
that directory, an error 2 : access denied is always returned.  I have 
tried running tftp as root and as a specified user and it always returns 
that error.
Comment 1 Pekka Savola 2000-10-02 16:01:05 EDT
Do you have

server_args = /tftpboot

or equivalent in tftpd configuration (should be there by default)?  With previous 
versions, it defaulted to this, but now you have to explicitly define it.
Comment 2 Need Real Name 2000-10-02 16:55:08 EDT
Yes.  That line is there by default.  Regardless of the permisions you put on 
the directory and files inside it, you can't save or retreive them with tftp.  
Try it!
Comment 3 Pekka Savola 2000-10-02 17:08:20 EDT
You must use

You must specify the full path, like

get /tftpboot/test.file

not 

get test.file

This was also IIRC changed; previously the both worked, I think.   

If you want to omit /tftpboot, use '-s' in server_args, see in.tftpd(8).



Comment 4 Need Real Name 2000-10-02 18:50:18 EDT
Tried that, started tftp with root (can't chroot with any other account 
apparently) and I can get it to start the connection, but it will never 
finish.  I did get it work ONE time by cranking the block size to 4096.  Do I 
need to specify something else?
Comment 5 Pekka Savola 2000-10-03 15:31:52 EDT
$ tftp other.host
tftp> get testfile
Received 9602185 bytes in 5.9 seconds

Seems to work just fine with me without tweaking block size options 
or anything.

You might want to analyze it with tcpdump/strace or a higher level
of debugging in xinetd.

Comment 6 Need Real Name 2000-10-03 15:48:45 EDT
Don't sweat it.  I have tried MULTIPLE times on several different boxes and 
couldn't get it to work.  Loaded .16-5 on there and set everything back to 
default and works like a charm.  There is still a SERIOUS problem with .17-5 
server.  Maybe it is with the documentation, but a problem is there none the 
less.
Comment 7 Joseph W. Breu 2000-10-03 18:34:59 EDT
putting to the tftp server also returns an unspecified error.

The directory is 777 and so is the file that I am trying to write to.

service tftp
{
	disable			= no
	socket_type		= dgram
	wait			= yes
	#user			= nobody
	user			= root
	log_on_success		+= USERID
	log_on_failure 		+= USERID
	server			= /usr/sbin/in.tftpd
	#server_args		= /tftpboot
	server_args		= -s /tftpboot
}
Comment 8 Pekka Savola 2000-10-04 01:48:53 EDT
Works fine for me, with the exact same configuration, with or 
without 777 permissions.  So, I think some debug output is required...

.16-5 and .17-5 are different codebases IIRC.   
The latter is based on H. Peter Anvin's port of OpenBSD tftpd.
Comment 9 Charles R. Anderson 2000-10-06 02:59:38 EDT
Why was the status set to RESOLVED?   Please explain how this is NOTABUG, since
I am having the same trouble.  If I drop in the old netkit server, it works. 
The new tftp-hpa server just hangs on TFTP puts (gets work fine, though).  Here
is a trace from the client:

Connected to my-tftp-server.
Mode: netascii Verbose: on Tracing: on
Rexmt-interval: 5 seconds, Max-timeout: 25 seconds
tftp> put /tftpboot/bar
putting bar to dustpuppy.WPI.EDU:/tftpboot/bar [netascii]
sent WRQ <file=/tftpboot/bar, mode=netascii>
received ACK <block=1>
discarded 5 packets
received ACK <block=1>
received ACK <block=1>
sent WRQ <file=/tftpboot/bar, mode=netascii>
sent WRQ <file=/tftpboot/bar, mode=netascii>
received ACK <block=1>
sent WRQ <file=/tftpboot/bar, mode=netascii>
received ACK <block=1>
sent WRQ <file=/tftpboot/bar, mode=netascii>
received ACK <block=1>
Transfer timed out.

tftp> 

/tftpboot directory listing follows:

drwxr-xr-x    2 root     root         1024 Oct  6 02:38 ./
drwxr-xr-x   24 root     root         1024 Sep 27 10:38 ../
-rw-rw-rw-    1 nobody   nobody          0 Oct  6 02:45 bar

The bar file I tried to 'put' is 36 bytes.

I straced the server:

#strace -p2166
recv(0, 0x806c064, 65468, 0)            = ? ERESTARTSYS (To be restarted)
--- SIGALRM (Alarm clock) ---
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigaction(SIGALRM, {0x8049da4, [], SA_RESTART|0x4000000}, {0x8049da4, [], SA_
RESTART|0x4000000}, 8) = 0
send(0, "\0\4\0\1", 4, 0)               = 4
rt_sigaction(SIGALRM, {0x8049da4, [], SA_RESTART|0x4000000}, {0x8049da4, [], SA_
RESTART|0x4000000}, 8) = 0
alarm(5)                                = 0
recv(0, "\0\2/tftpboot/bar\0netascii\0", 65468, 0) = 25
alarm(0)                                = 5
rt_sigaction(SIGALRM, {0x8049da4, [], SA_RESTART|0x4000000}, {0x8049da4, [], SA_
RESTART|0x4000000}, 8) = 0
alarm(5)                                = 0
recv(0, "\0\2/tftpboot/bar\0netascii\0", 65468, 0) = 25
alarm(0)                                = 1
rt_sigaction(SIGALRM, {0x8049da4, [], SA_RESTART|0x4000000}, {0x8049da4, [], SA_
RESTART|0x4000000}, 8) = 0
alarm(5)                                = 0
recv(0, "\0\2/tftpboot/bar\0netascii\0", 65468, 0) = 25
alarm(0)                                = 1
rt_sigaction(SIGALRM, {0x8049da4, [], SA_RESTART|0x4000000}, {0x8049da4, [], SA_
RESTART|0x4000000}, 8) = 0
alarm(5)                                = 0
recv(0, 0x806c064, 65468, 0)            = ? ERESTARTSYS (To be restarted)
--- SIGALRM (Alarm clock) ---
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigaction(SIGALRM, {0x8049da4, [], SA_RESTART|0x4000000}, {0x8049da4, [], SA_
RESTART|0x4000000}, 8) = 0
send(0, "\0\4\0\1", 4, 0)               = 4
rt_sigaction(SIGALRM, {0x8049da4, [], SA_RESTART|0x4000000}, {0x8049da4, [], SA_
RESTART|0x4000000}, 8) = 0
alarm(5)                                = 0
recv(0, "\0\2/tftpboot/bar\0netascii\0", 65468, 0) = 25
alarm(0)                                = 1
rt_sigaction(SIGALRM, {0x8049da4, [], SA_RESTART|0x4000000}, {0x8049da4, [], SA_
RESTART|0x4000000}, 8) = 0
alarm(5)                                = 0
recv(0, 0x806c064, 65468, 0)            = ? ERESTARTSYS (To be restarted)
--- SIGALRM (Alarm clock) ---
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigaction(SIGALRM, {0x8049da4, [], SA_RESTART|0x4000000}, {0x8049da4, [], SA_
RESTART|0x4000000}, 8) = 0
send(0, "\0\4\0\1", 4, 0)               = 4
rt_sigaction(SIGALRM, {0x8049da4, [], SA_RESTART|0x4000000}, {0x8049da4, [], SA_
RESTART|0x4000000}, 8) = 0
alarm(5)                                = 0
recv(0, 0x806c064, 65468, 0)            = ? ERESTARTSYS (To be restarted)
--- SIGALRM (Alarm clock) ---
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigaction(SIGALRM, {0x8049da4, [], SA_RESTART|0x4000000}, {0x8049da4, [], SA_
RESTART|0x4000000}, 8) = 0
send(0, "\0\4\0\1", 4, 0)               = 4
rt_sigaction(SIGALRM, {0x8049da4, [], SA_RESTART|0x4000000}, {0x8049da4, [], SA_
RESTART|0x4000000}, 8) = 0
alarm(5)                                = 0
recv(0, 0x806c064, 65468, 0)            = ? ERESTARTSYS (To be restarted)
--- SIGALRM (Alarm clock) ---
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
rt_sigaction(SIGALRM, {0x8049da4, [], SA_RESTART|0x4000000}, {0x8049da4, [],
SA_RESTART|0x4000000}, 8) = 0
send(0, "\0\4\0\1", 4, 0)               = 4
rt_sigaction(SIGALRM, {0x8049da4, [], SA_RESTART|0x4000000}, {0x8049da4, [],
SA_RESTART|0x4000000}, 8) = 0
alarm(5)                                = 0
recv(0,  <unfinished ...>

(at this point I ctrl-c'd the strace)

Also, it seems like the new tftp-hpa server is very light on logging, making
debugging permission problems, etc., very difficult.  If anyone is interested, I
have created a package that includes both the new (in.tftpd) and old
(in.tftpd-netkit) servers, both patched for increased syslogging.
Comment 10 Need Real Name 2000-10-06 13:54:27 EDT
I gave up trying to tell him that, he obviously is of the opinion that me and 
the 3 OTHER people that all had the same problem are wrong!  So I just went 
back to .16-5 and went on with life!
Comment 11 Pekka Savola 2000-10-06 13:59:14 EDT
The original poster primarily mentioned tftp get -- that does work just fine.

However, puts do seem to fail pretty badly.  That's reproducible.
I think the problem is with 

                  (*pf->f_send)(pf, ackbuf, ap-ackbuf);

and buffers giving false information but I don't know (65468 in this one vs. like 500 in 0.16).
Comment 12 Pekka Savola 2000-10-06 17:27:32 EDT
I take that back, that piece of code should be fine.

Anyway, I asked HPA if he'd have time to fix this problem; 
no luck and he doesn't use tftp puts at all himself.
Comment 13 Need Real Name 2000-10-12 03:58:44 EDT
I would surely like to see this fixed since I need it to save a router
configuration. Is there a workaround?
Comment 14 Need Real Name 2000-10-12 11:04:08 EDT
As I posted earlier, just get .16-5 rpm and just force the install.  This 
overwrites .17 and works fine.
Comment 15 Need Real Name 2000-10-12 16:42:59 EDT
I've spent a couple hours today looking at why tftpd can't receive
files, and have gotten pretty close to the problem using strace(1) and
tcpdump(1).

tcpdump shows that the tftpd provided with RedHat 7 (tftp-0.17-5)
appears to respond incorrectly in its ACK reply to the tftp client WRQ
commands.  RFC 1350 says:

   As an example, the following shows the steps used to establish a
   connection to write a file.  Note that WRQ, ACK, and DATA are the
   names of the write request, acknowledgment, and data types of
   packets respectively. [...]

      1. Host A sends  a  "WRQ"  to  host  B  with  source=  A's  TID,
         destination= 69.

      2. Host  B  sends  a "ACK" (with block number= 0) to host A with
         source= B's TID, destination= A's TID.

RFC 1350 also says:

                         2 bytes     2 bytes
                         ---------------------
                        | Opcode |   Block #  |
                         ---------------------

                         Figure 5-3: ACK packet

   Figure 5-3 depicts an ACK packet; the opcode is 4.  The  block
   number  in an  ACK echoes the block number of the DATA packet being
   acknowledged.  A WRQ is acknowledged with an ACK packet having a
   block number of zero.

Now, consider this correct Solaris tftp exchange as seen by tcpdump:

   10:56:52.048309 client.51300 > server.tftp: 18 WRQ "junk.file"
                            4500 002e 0000 0000 fe11 c4cc 8068 d802
                            8068 1f1f c864 0045 001a 119f 0002 6a75
                            6e6b 2e66 696c 6500 6f63 7465 7400
   10:56:52.078806 server.56390 > client.51300: udp 4 (DF)
                            4500 0020 02e3 4000 ff11 80f7 8068 1f1f
                            8068 d802 dc46 c864 000c 6334 0004 0000

The last byte of this latter packet is the important bit, it *must* be
zero.

But when you do this exchange with the aforementioned RedHat-provided
tftpd it shows the value as 1, as in:

   10:56:52.078806 server.56390 > client.51300: udp 4 (DF)
                            4500 0020 02e3 4000 ff11 80f7 8068 1f1f
                            8068 d802 dc46 c864 000c 6334 0004 0001

Note the trailing 0x01 byte.

So, it looks like tftpd is incorrectly ACKing a WRQ with "0004 0001"
rather than "0004 0000".  While "0004 0001" *is* the correct ACK for a
RRQ (get command) it is not right for a WRQ (put command).

I think the relevant place in the code might be line 765 of this file:

   $Id: tftpd.c,v 1.4 1999/09/26 07:12:54 hpa Exp $

but the code (in the recvfile function) is rather opaque.  It isn't
immediately obvious to me how to get it to answer back with a block of
zero in the initial ACK in response to the WRQ command.
Comment 16 Adam Stark 2000-10-13 09:49:56 EDT
I also tried a get last night and couldn't get it to work. I was trying to get
Linux onto a Sparc by tftping the boot file down but even with the -s I was
getting time outs.
	Not a lot of use I konw just another person stating they are having problems
with tftp!

Comment 17 Mike Burger 2000-10-13 14:16:09 EDT
Add me to the list...and I'm in a similar boat...I need to have various pieces of equipment download their current configs, and have the ability 
to upload updated configs, to the server.

FWIW, I noted the same problem with tftp-0.15-1, installed on my RH6.1 (Cartman) system.
Comment 18 Mike Burger 2000-10-22 08:10:39 EDT
I think I've got the answer, thanks to Craig Rodriquez on the Guinness list, to the get problem.

My /tftpboot directory permissions were not set right...they were drwxrwxrw-...they need to be at least drwxr-xr-x...that last x (o+x) was very important.

The put problem still persists.

An strace of the operation gives us:

512   select(10, [3 4 5 7 8 9], NULL, NULL, NULL) = 1 (in [5])
512   recvfrom(5, "\0", 1, MSG_PEEK, {sin_family=AF_INET, sin_port=htons(1047), sin_addr=inet_addr("207.8.143.110")}}, [16]) = 1
512   time([972216036])                 = 972216036
512   getpid()                          = 512
512   getpeername(5, 0x8070f00, [16])   = -1 ENOTCONN (Transport endpoint is not connected)
512   recvfrom(5, "\0\2server1.cfg\0octet\0", 8192, MSG_PEEK, {sin_family=AF_INET, sin_port=htons(1047), sin_addr=inet_addr("207.8.143.110")}}, 
[16]) = 20
512   getsockname(5, {sin_family=AF_INET, sin_port=htons(69), sin_addr=inet_addr("0.0.0.0")}}, [16]) = 0
512   open("/etc/hosts.allow", O_RDONLY) = 10
512   fstat(10, {st_mode=S_IFREG|0644, st_size=161, ...}) = 0
512   old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40018000
512   read(10, "#\n# hosts.allow\tThis file descri"..., 4096) = 161
512   read(10, "", 4096)                = 0
512   close(10)                         = 0
512   munmap(0x40018000, 4096)          = 0
512   open("/etc/hosts.deny", O_RDONLY) = 10
512   fstat(10, {st_mode=S_IFREG|0644, st_size=347, ...}) = 0
512   old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40018000
512   read(10, "#\n# hosts.deny\tThis file describ"..., 4096) = 347
512   read(10, "", 4096)                = 0
512   close(10)                         = 0
512   munmap(0x40018000, 4096)          = 0
512   fork()                            = 15748
512   time([972216036])                 = 972216036
512   time([972216036])                 = 972216036
512   getpid()                          = 512
512   rt_sigaction(SIGPIPE, {0x4015ada0, [], 0x4000000}, {SIG_IGN}, 8) = 0
512   send(6, "<86>Oct 22 08:00:36 xinetd[512]:"..., 73, 0) = 73
512   rt_sigaction(SIGPIPE, {SIG_IGN}, NULL, 8) = 0
512   select(10, [3 4 7 8 9], NULL, NULL, NULL <unfinished ...>
15748 setgid(0)                         = 0
15748 setgroups(0, [])                  = 0
15748 setuid(0)                         = 0
15748 rt_sigaction(SIGPIPE, {SIG_DFL}, {SIG_IGN}, 8) = 0
15748 rt_sigaction(SIGALRM, {SIG_DFL}, {0x805fb2c, [ALRM VTALRM PROF], 0x4000000}, 8) = 0
15748 rt_sigaction(SIGTSTP, {SIG_DFL}, {SIG_IGN}, 8) = 0
15748 rt_sigaction(SIGTTIN, {SIG_DFL}, {SIG_IGN}, 8) = 0
15748 rt_sigaction(SIGTTOU, {SIG_DFL}, {SIG_IGN}, 8) = 0
15748 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
15748 fcntl(5, F_SETFD, 0)              = 0
15748 dup2(5, 0)                        = 0
15748 dup2(5, 1)                        = 1
15748 dup2(5, 2)                        = 2
15748 close(5)                          = 0
15748 setsid()                          = 15748
15748 setrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=1024}) = 0
15748 close(6)                          = 0
15748 execve("/usr/sbin/in.tftpd", ["in.tftpd", "-s", "/tftpboot"], [/* 20 vars */]) = 0
15748 _sysctl({{CTL_KERN, KERN_OSRELEASE}, 2, "2.2.16-22", 9, NULL, 0}) = 0
15748 brk(0)                            = 0x808bc60
15748 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000
15748 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory)
15748 open("/etc/ld.so.cache", O_RDONLY) = 3
15748 fstat64(3, 0xbffff58c)            = -1 ENOSYS (Function not implemented)
15748 fstat(3, {st_mode=S_IFREG|0644, st_size=14463, ...}) = 0
15748 old_mmap(NULL, 14463, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40018000
15748 close(3)                          = 0
15748 open("/lib/libc.so.6", O_RDONLY)  = 3
15748 fstat(3, {st_mode=S_IFREG|0755, st_size=4776568, ...}) = 0 15748 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\274"..., 4096) 
= 4096
15748 old_mmap(NULL, 1196776, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x4001c000
15748 mprotect(0x40137000, 37608, PROT_NONE) = 0
15748 old_mmap(0x40137000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x11a000) = 0x40137000
15748 old_mmap(0x4013d000, 13032, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4013d000
15748 close(3)                          = 0
15748 munmap(0x40018000, 14463)         = 0
15748 getpid()                          = 15748
15748 socket(PF_UNIX, SOCK_DGRAM, 0)    = 3
15748 fcntl64(3, F_SETFD, FD_CLOEXEC)   = -1 ENOSYS (Function not implemented)
15748 fcntl(3, F_SETFD, FD_CLOEXEC)     = 0
15748 connect(3, {sin_family=AF_UNIX, path="      /dev/log"}, 16) = 0
15748 brk(0)                            = 0x808bc60
15748 brk(0x808bc80)                    = 0x808bc80
15748 brk(0x808c000)                    = 0x808c000
15748 chdir("/tftpboot")                = 0
15748 brk(0x808d000)                    = 0x808d000
15748 socket(PF_UNIX, SOCK_STREAM, 0)   = 4
15748 connect(4, {sin_family=AF_UNIX, path="/var/run/.nscd_socket"}, 110) = -1 ECONNREFUSED (Connection refused)
15748 close(4)                          = 0
15748 open("/etc/nsswitch.conf", O_RDONLY) = 4
15748 fstat64(4, 0xbffffa50)            = -1 ENOSYS (Function not implemented)
15748 fstat(4, {st_mode=S_IFREG|0644, st_size=1782, ...}) = 0
15748 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40018000
15748 read(4, "#\n# /etc/nsswitch.conf\n#\n# An ex"..., 4096) = 1782
15748 read(4, "", 4096)                 = 0
15748 close(4)                          = 0
15748 munmap(0x40018000, 4096)          = 0
15748 open("/etc/ld.so.cache", O_RDONLY) = 4
15748 fstat(4, {st_mode=S_IFREG|0644, st_size=14463, ...}) = 0
15748 old_mmap(NULL, 14463, PROT_READ, MAP_PRIVATE, 4, 0) = 0x40018000
15748 close(4)                          = 0
15748 open("/lib/libnss_files.so.2", O_RDONLY) = 4
15748 fstat(4, {st_mode=S_IFREG|0755, st_size=234205, ...}) = 0
15748 read(4, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0 !\0\000"..., 4096) = 4096
15748 old_mmap(NULL, 43948, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) = 0x40141000
15748 mprotect(0x4014b000, 2988, PROT_NONE) = 0
15748 old_mmap(0x4014b000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 4, 0x9000) = 0x4014b000
15748 close(4)                          = 0
15748 munmap(0x40018000, 14463)         = 0
15748 open("/etc/passwd", O_RDONLY)     = 4
15748 fcntl(4, F_GETFD)                 = 0
15748 fcntl(4, F_SETFD, FD_CLOEXEC)     = 0
15748 fstat(4, {st_mode=S_IFREG|0644, st_size=4114, ...}) = 0
15748 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40018000
15748 read(4, "root:x:0:0:root:/root:/bin/bash\n"..., 4096) = 4096
15748 close(4)                          = 0
15748 munmap(0x40018000, 4096)          = 0
15748 chroot(".")                       = 0
15748 setregid32(4294967295, 99)        = -1 ENOSYS (Function not implemented)
15748 setregid(4294967295, 99)          = 0
15748 setgid(99)                        = 0
15748 setresuid(ruid 4294967295, euid 99, suid 4294967295) = 0
15748 setuid(99)                        = -1 EPERM (Operation not permitted)
15748 ioctl(0, FIONBIO, [1])            = 0
15748 recvfrom(0, "\0\2server1.cfg\0octet\0", 65468, 0, {sin_family=AF_INET, sin_port=htons(1047), sin_addr=inet_addr("207.8.143.110")}}, [16]) = 
20
15748 fork()                            = 15749
15748 _exit(0)                          = ?
512   <... select resumed> )            = ? ERESTARTNOHAND (To be restarted)
512   --- SIGCHLD (Child exited) ---
512   sigreturn()                       = ? (mask now [])
512   wait4(-1, [WIFEXITED(s) && WEXITSTATUS(s) == 0], WNOHANG, NULL) = 15748
512   wait4(-1, 0xbffffc0c, WNOHANG, NULL) = 0
512   select(10, [3 4 5 7 8 9], NULL, NULL, NULL <unfinished ...>
15749 alarm(0)                          = 0
15749 close(0)                          = 0
15749 close(1)                          = 0
15749 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 0
15749 bind(0, {sin_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("0.0.0.0")}}, 16) = 0
15749 connect(0, {sin_family=AF_INET, sin_port=htons(1047), sin_addr=inet_addr("207.8.143.110")}}, 16) = 0
15749 stat("server1.cfg", {st_mode=S_IFREG|0644, st_size=9395, ...}) = 0
15749 send(0, "\0\5\0\2Access violation\0", 21, 0) = 21
15749 _exit(0)                          = ?

And a trace of the put operation from within tftp gives us:

newlinux:~>tftp newlinux
tftp> bin
tftp> verb
Verbose mode on.
tftp> trac
Packet tracing on.
tftp> put server1.cfg
putting server1.cfg to newlinux.compucomis.net:server1.cfg [octet]
sent WRQ <file=server1.cfg, mode=octet>
received ACK <block=1>
sent WRQ <file=server1.cfg, mode=octet>
received ACK <block=1>
sent WRQ <file=server1.cfg, mode=octet>
received ACK <block=1>
sent WRQ <file=server1.cfg, mode=octet>
received ACK <block=1>
sent WRQ <file=server1.cfg, mode=octet>
received ACK <block=1>
Transfer timed out.
Comment 19 brian@isu.edu 2000-10-23 16:22:00 EDT
Had the same problem with TFTP not working.  Installed the .16-5 server now it
works.  The only problem I have now is that if the server is run as "nobody"
serve_args "-s /tftpboot" seem to be only decoration as I must specify full path
and file name to write to a file.
Comment 20 brian@isu.edu 2000-10-23 16:39:31 EDT
OK looks like I lied regarding the .16-5 pacage.  If 
server_args = /tftpboot -s  then it works, but if
server_args = -s /tftpboot it does not work.

Comment 21 Brian Feeny 2000-11-08 21:18:26 EST
I can't believe all these people are being told tftp is basically fine, its
totally broke.

get's only work if you change the username to "root" from the default "nobody".

put's are just plain broke.  Setting "-s /tftpboot" doesn't work, like one
person pointed out
you actually have to do "/tftpboot -s" which is inconstant with the man page. 
And that
only gets "get's" to work.  I really hope this gets the attention it deserves,
tftpd is critical in 
an enterprise enviroment.

Brian
Comment 22 Pekka Savola 2000-11-11 09:48:43 EST
*** Bug 20643 has been marked as a duplicate of this bug. ***
Comment 23 Need Real Name 2000-11-15 15:06:24 EST
I upgraded a system from RH 6.2 to 7.0.  TFTP worked with 6.2 now under 7.0 it
does not. I do not
have a configuration problem, this is a bug! Redhat you need to hurry up and fix
this problem. Tftpd
is a critical service to network infrastructure. All routers, switches and hubs
depend on tftp for configurations,and software upgrades. 

Danny
Comment 24 Pekka Savola 2000-11-19 09:27:45 EST
*** Bug 20730 has been marked as a duplicate of this bug. ***
Comment 25 Pekka Savola 2000-11-19 09:47:15 EST
As there doesn't seem to be a solution for hpa tftpd, I'd suggest that tftp is 
backed out to netkit-tftp for now. It's even distributed with the tftp package.
Comment 26 Pekka Savola 2000-11-19 09:48:04 EST
Created attachment 5522 [details]
revert back to tftpd from netkit so tftp puts also work
Comment 27 Pekka Savola 2000-11-25 05:04:40 EST
*** Bug 21299 has been marked as a duplicate of this bug. ***
Comment 28 Marius Bezuidenhout 2000-11-29 06:07:24 EST
I seem to get a slightly different problem. Using tftp version .17-5 or .16-5
both does the same thing.

sent RRQ <file=X86PC/UNDI/linux-install/linux.1, mode=octet>
received DATA <block=1, 512 bytes>
sent ACK <block=1>
sent ACK <block=1>
sent ACK <block=1>
sent ACK <block=1>
sent ACK <block=1>
Transfer timed out.
Comment 29 Marius Bezuidenhout 2000-11-29 07:29:14 EST
Please ignore my last comment. I had two services with the same name.

Seems that if I set the user as root and the server args as /tftpboot -s. It
works fine.
Comment 30 Need Real Name 2000-12-08 10:59:51 EST
TFTP puts fail for me too, much the same way as mentioned above.  The "get" can 
be made to work if my user is set to "root", but the "put" always times out.  
Used to work in RH6.2 for me too.  I wonder why is this was not regression-
tested before RH7.0 was released?
Comment 31 Pekka Savola 2000-12-08 11:04:45 EST
I tested this is Public Beta, but unfortunately, gets only ;-(
Comment 32 Need Real Name 2000-12-08 14:05:50 EST
I must confess that reverting back to the 0.16 version of TFTP server as a long-
term solution would be a bummer, since that version is very inflexible in its 
refusal to allow creation of new files with the PUT operation.  The 0.17 
version has a "-c" flag that allows the creation of new files by the client, 
and this capability is normal for MS-WinNT TFTP services and TFTP services on 
Cisco router NVram.  While I don't begrudge RedHat its right to strictness as 
the default case, it would be regrettable if such flexibility (and consistency 
to other platforms) were not even available as an option.  So if anyone is 
counting, I'd vote to fix 0.17 and not just toss it out.
Comment 33 Need Real Name 2000-12-08 16:36:39 EST
This hole thing is a mess, and I4ve spent more time than reasonable on this 
issue. I4m VERY disappointed by redhat not taking any actions towards fixing 
these problems and not even making a clear statement here!

Reverting back is no acceptable option in my opinion. And next time I will 
consider using Debian (which works at least) or any other distribution that 
will respond to customers complaints.

In the meantime you might have a look at the yale-tftpd. I started to try it 
today and it seems to do what it is expected to do.

cheers
Comment 34 Mike Burger 2000-12-08 16:46:10 EST
Ok...let's not get too carried away.

Let us not forget that RedHat didn't develop the tftp server.  It is, after all, developed elsewhere.

It is not only quite possible, but quite probable, that users of other distributions, with the 0.17 version of tftpd, are having the same problem.

The thing that gets/got me is the original response that it was all our doing in having misconfigured it.

Regressing to a previous, known, working version should not be seen as an unacceptable option.  In fact, it's most often not only an 
acceptable option, but a better option.

No...I do not work for, nor am I related in any way to RHAT.  I'm just someone who does support for a living, and knows from whence all this 
comes.

Let's give them a chance to fix the bugs, if its within their capacity, or to RPM up a newer or working version.

--MAB
Comment 35 Pekka Savola 2000-12-09 16:51:33 EST
Ok, I hacked around a patch to fix puts.  I didn't quite understand what oacklen is used for, but it
seems to work nonetheless with every way I could conceive of.

Please beat this hard ;-)
Comment 36 Pekka Savola 2000-12-09 16:53:15 EST
Created attachment 6251 [details]
patch to fix broken tftp puts with hpa tftp
Comment 37 Need Real Name 2000-12-12 16:43:29 EST
The 2000-12-09 patch from pekkas@netcore.fi completely chops out the use of oap
and oacklen in the recvfile() function.  In fact they're needed to send the negotiated
options response from the server; so I believe that patch will completely break options
negotiation.

Here's my idea of how it should be done.  Works for me.

jcastle

*** tftp-hpa-0.14/tftpd/tftpd.c.orig	Sun Jul  9 03:30:34 2000
--- tftp-hpa-0.14/tftpd/tftpd.c	Tue Dec 12 13:59:57 2000
***************
*** 763,767 ****
  		timeout = 0;
  		
! 		if (!block++ && oap) {
  		     ap = (struct tftphdr *)ackbuf;
  		     acksize = oacklen;
--- 763,767 ----
  		timeout = 0;
  		
! 		if (!block && oap) {
  		     ap = (struct tftphdr *)ackbuf;
  		     acksize = oacklen;
***************
*** 772,775 ****
--- 772,776 ----
  		     acksize = 4;
  		}
+ 		block++;
  		(void) sigsetjmp(timeoutbuf,1);
  		bsd_signal(SIGALRM, timer);
Comment 38 Pekka Savola 2000-12-12 16:50:50 EST
Yeah, that looks much saner.  
Comment 39 Jeff Johnson 2001-01-06 16:16:15 EST
Added patch for tftp put, and server args to start in chroot in tftp-0.17-6.
Thanks for all the
help (and patience).
Comment 40 Geoffrey D. Bennett 2001-01-16 22:11:18 EST
Can the rawhide tftp-0.17-6 RPM be released as a Red Hat 7.0 errata?  I'd prefer
to stay current with the updates and never notice the bug rather than be bitten
by it (like I was this morning) and waste time to investigate it, decide that
it's a bug, go to bugzilla, find that it's fixed in rawhide, and then download
and install the rawhide version.

What's the point of
http://www.redhat.com/support/errata/rh7-errata-bugfixes.html if it's not for
this sort of thing?
Comment 41 Need Real Name 2001-01-20 15:02:09 EST
Why hasn't there been an errata bug fix?  I spent 2 hours trying to figure out
why tftpd was not working correctly and finnaly relized it had to be the program
itself.  I see the bug was resolved over a month ago that could of allowed me to
spend my time more productively if it had been included as an update.

Keep up the good work anyhow ;P
Comment 42 Pekka Savola 2001-02-28 04:07:10 EST
*** Bug 29529 has been marked as a duplicate of this bug. ***

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