Bug 67524

I just tried a trivial test of the tftp-0.29-2 (client & server) that are in rawhide, with 
successful results. Thus I will need information on how to reproduce the problem here..

My xinetd configuration on the server is:
service tftp
{
        socket_type             = dgram
        protocol                = udp
        wait                    = yes
        user                    = root
        server                  = /usr/sbin/in.tftpd
        server_args             = -s /usr/lib/X11/ncd
        disable                 = no
        only_from               = 146.130.180.0/24
}

When I try bootptest

 /usr/sbin/bootptest -f /usr/lib/X11/ncd/configs/Xncd19r feynman
I get
Sending to 146.139.52.128 (request) htype:0 hlen:0 xid:23834 secs:10
C:146.139.180.81 file:"/usr/lib/X11/ncd/configs/Xncd19r" vend-rfc1395
no response from feynman

On feynman, I see in the log messages that bootps is started by xinetd, but the
tftp part never starts.

If I try tftp directly from the client, I gettftp>  get
/usr/lib/X11/ncd/configs/Xncd19r
tftp: Xncd19r: Permission denied

The file is world readable so it should be accessible.  Also, I see nothing in
feynman's log indicating that tftpd is even started.

All of this worked on Redhat 6.2. When I upgraded the system to 7.3, the
configuration files
that I used in 6.2 no longer worked. I am probably making a mistake in the
setup, but I can't 
find out enough information to see where the error is. I have also seen the
message
"tftp server deactivated due to looping" in the system log when I tried testing
repeatedly.

dkl,

I have experienced exactly the same problem as kovacs.gov. However,
instead of trying to utilize bootp, I am trying to tftp cisco configs from
routers and switches to my tftp server, re:
copy startup tftp at the cisco enable command line.

I have 3 servers, 2 of which I upgraded from RH7.2 (tftp server ran perfectly on
RH7.2) to RH7.2. The 3rd server is a fresh install of RH7.3. I configured tftp
on the server with a fresh install to see if something went sideways during the
upgrade on the other 2 servers. Exactly the same result on the fresh install
server as the 2 upgraded servers.

RH7.3 package - tftp-server-0.28-2.i386.rpm
Error message on all 3 servers is as follows:

"Jul 16 10:15:00 hellcat in.tftpd[pid#]: cannot bind to local socket: Address
already in use"

"Jul 16 10:15:00 xinetd[pid#]: Deactivating service tftp due to excessive
incoming connections. Restarting in 2 seconds."

These error messages repeat a number of times because a Cisco Router will try to
send the configuration to the tftp server for aproximately 10 seconds.

server is configured as follows:

ipchains is configured to allow tftp udp traffic through the firewall.

-A input -s xxx.xxx.xxx.xxx/255.255.255.255 -d 0/0 69 -p udp -j ACCEPT

tftp traffic is coming through else there would be no entries in
/var/log/messages

/tftpboot is set to drwxrwxrwx

/etc/xinetd.d/tftp is configured as follows:

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

bounce xinetd

/etc/rc.d/init.d/xinetd restart

netstat -pan | grep xinetd provides the following:

upd	0	0.0.0.0:69		0.0.0.0:*			pid#/xinetd

so it appears that it is ready to go.

of course /sbin/chkconfig --list says tfpt: on

From /var/log/messages, it appears that something has grabbed the socket or
there is a lock on it.

At this point, I am at a loss as to where to go look for the lock or what ever.

I am assuming that tftp-0.29-2 should be ftp-0.28-2, perhaps a typo???? 

just tried a trivial test of the tftp-0.29-2 (client & server) that are in
rawhide, with 
 successful results. Thus I will need information on how to reproduce the
problem here..

Hi
  I have exactly the same problem - tftp doesn't work when connecting
from other hosts but it works when connecting from localhost.
  I narrowed it down a bit and I think the actual problem is related to
kernel or xinetd-ipv6. When xinetd is used - tftp works perfectly, regardless
presence (or absence) of ipv6 support in kernel (i use kernel-smp-2.4.18 for
i586). when xinetd-ipv6 is used (it happens when NETWORKING_IPV6 is set to
yes in /etc/sysconfig/network) tftp doesn't work. I also have this kind of
problem with mftp and I guess it may affect all udp services started by xinetd-ipv6.
  Hope it helps.

Tomek

Tomek,

I check on your suggestions in my three systems. I am not running ipv6 at all.

I just retested to see if I could tftp in my Cisco configs. Same undefined error
as far as what Cisco reports and nothing in the log files to give a clue as to
where to go look.

Red Hat TAC still wants to reproduce the error. I have posted everything that I
have done on each of these three servers. I wish I would get a clue as to where
to go look for the problem.

Hi
  I rechecked my findings on other system and I am quite positive that
the problem is related to IPv6.
  To find out if you have IPv6 running check:
lsmod (see if ipv6 module is loading)
ifconfig (check if inet6 addr is displayed)
ps auxw | grep xinetd-ipv6 (to see if xinetd or xinted-ipv6 is running).
  The problem is specific to Redhat 7.3 with:
- it's own tftp server
- tftp server from redhat 7.2
- tftp server from latest limbo beta.
  Now, what I tried (and you can as well) to narrow down a problem:
1. Run ethereal and check if you have only tftp requests (they always come
to port 69) or responeses and transfers as well (they use unpriviledged
ports on both ends). In my case I see tftp request but I don't get any
response on the wire. Use standard tftp client from distribution for all
of these tests to check if the problem is related to server or just to
your cisco client.
2. Run in single user mode. Start network (service network start) making
sure NETWORKING_IPV6 in /etc/sysconfig/network is not set to yes and that
net-pf-10 in /etc/modules.conf is aliased to off (alias net-pf-10 off).
Start tftpd in standalone mode (in.tftpd -l -s /tftpboot) and see if tftp
started to work. If tftp works - the problem is somewhere else, if not - the
problem is very likely with tftp itself.
3. If tftp worked in previuos step start services one by one 
(service servicename start) with exception of xinetd and see when tftp
ceases to work. If it stops working you now now the offending service.
4. If it still works - kill tftp daemon and start xinetd and check if
it still works. If it doesn't - repeat steps 2 & 3 but this time after
starting network start xinetd and check if tftp works, if so - proceed with
step 3.
5. If tftp under xinetd worked - turn on ipv6:
modprobe ipv6
service xinetd restart
and check if it still works.
6. If it works:
service xinetd stop
Add the following line to /etc/sysconfig/network
NETWORKING_IPV6=yes
and:
service xinetd start.
This time xinetd-ipv6 starts. Check tftp.
7. By now you should know what happend (I hope...).

Tomkep,
I just checked my server and I don't have any of the IPv6 stuff running.
I tried running the tftp client in standalone mode using:
/usr/sbin/in.tftpd -l -s /tftpboot
(after disabling the tftp startup in xinetd)

Then, I tried a test using the tftp client on another system:
>tftp -v feynman.hep.anl.gov
Connected to feynman.hep.anl.gov (146.139.52.128), port 69

On feynman, I have enabled logging in the firewall for tftp connections and I
see:
Aug 15 17:41:03 feynman kernel: Packet log: input ACCEPT eth0 PROTO=17
146.139.180.81:1226 146.139.52.128:69 L=69 S=0x00 I=0 F=0x4000 T=63 (#15)

So,  the request is getting through the firewall.

When I try to get a file:

tftp> get /tftpboot/ncd/configs/rgb.txt
getting from feynman.hep.anl.gov:/tftpboot/ncd/rgb.txt to rgb.txt [netascii]
Error code 1: File not found

Note, on feynman I have : ls /tftpboot/ncd/rgb.txt 
/tftpboot/ncd/rgb.txt

So the file is there!

I enabled extra logging when I started the tftp server and repeated the test: In
the sys log I got:
Aug 15 22:57:00 feynman in.tftpd[25275]: RRQ from 146.139.180.81 filename
/tftpboot/ncd/rgb.txt 
Aug 15 22:57:00 feynman in.tftpd[25275]: sending NAK (1, File not found) to
146.139.180.81
All this is consistent, except that the file exists.


I have installed  tftp-0.28-2.i386.rpm and  tftp-server-0.28-2.i386.rpm off the
Redhat 7.3 CD.

So, I can't get the server to work in even a simple standalone test.

You have to skip /tftpboot from get command as "-s /tftpboot" option
puts tftp server in chroot jail. Are you also sure about paths? They
seem to differ (/tftpboot/ncd/configs/rgb.txt and /tftpboot/ncd/rgb.txt).

Tomek

Tomek,

KO, I will give this a try. Probably won't get all the way throught it today. I
have 2 infrastructure jobs that pretty much have me buried. New customers coming
in with stub routes. I have to get the infrastructure done, the cisco gear
configed and passing gas.

I will advise as to the results.

thx

::tc :-)

This bug seems to be a duplicate of bug 55789.

Two different problems caused by IPv6 enabled and wrong retrieval path. Sounds 
resolved.

Bug is triggered by the -l argument in the server args line.

	server_args		= -l -c -s /tftpboot # WILL FAIL AS DESCRIBED
	server_args		= -c -s /tftpboot    # WILL WORK

I neglected to add that I hit this using Redhat 9.  removing -l from server_args
solved the problem.