Bug 18128
| Summary: | TFTP put doesn't work at all | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Need Real Name <roywalker_> | ||||||
| Component: | tftp | Assignee: | Bill Nottingham <notting> | ||||||
| Status: | CLOSED RAWHIDE | QA Contact: | |||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 7.0 | CC: | astark, billt, brian, chrismcc, citric, doug.cook, flyboyus, geoffrey, joseph.breu, mburger, michael_brock, pekkas, plonka, rvokal, signal, trash | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | i386 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2000-12-12 21:50:53 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Need Real Name
2000-10-02 19:50:01 UTC
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. 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! 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). 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? $ 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. 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. 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
}
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. 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.
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! 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).
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. I would surely like to see this fixed since I need it to save a router configuration. Is there a workaround? As I posted earlier, just get .16-5 rpm and just force the install. This overwrites .17 and works fine. 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.
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! 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. 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.
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. 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. 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 *** Bug 20643 has been marked as a duplicate of this bug. *** 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 *** Bug 20730 has been marked as a duplicate of this bug. *** 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. Created attachment 5522 [details]
revert back to tftpd from netkit so tftp puts also work
*** Bug 21299 has been marked as a duplicate of this bug. *** 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. 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. 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? I tested this is Public Beta, but unfortunately, gets only ;-( 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. 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 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 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 ;-) Created attachment 6251 [details]
patch to fix broken tftp puts with hpa tftp
The 2000-12-09 patch from pekkas 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);
Yeah, that looks much saner. Added patch for tftp put, and server args to start in chroot in tftp-0.17-6. Thanks for all the help (and patience). 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? 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 *** Bug 29529 has been marked as a duplicate of this bug. *** |