Both elements are stock, and 'up2date' current

The tftp-server which shipped with RHL 8.0 is not functional for remote hosts. 
It will only work with localhost (which, admittedly, is about as useless as it
can be)

[root@ftp bin]# rpm -qa | grep glibc
glibc-kernheaders-2.4-7.20
glibc-common-2.2.93-5
glibc-devel-2.2.93-5
glibc-2.2.93-5


tcpdump: listening on eth0
12:45:21.835033 dhcp-94.victim.lan.2070 > ftp.victim.lan.tftp:  40 RRQ
"/lts/vmlinuz-2.4.9-ltsp"
12:45:25.789076 dhcp-94.victim.lan.2071 > ftp.victim.lan.tftp:  40 RRQ
"/lts/vmlinuz-2.4.9-ltsp"
12:45:31.846823 dhcp-94.victim.lan.2072 > ftp.victim.lan.tftp:  45 RRQ
"/lts/vmlinuz-2.4.9-ltsp"
12:45:35.784764 dhcp-94.victim.lan.2073 > ftp.victim.lan.tftp:  45 RRQ
"/lts/vmlinuz-2.4.9-ltsp"
12:45:43.693429 dhcp-94.victim.lan.2074 > ftp.victim.lan.tftp:  45 ACK block 0
12:45:55.556423 dhcp-94.victim.lan.2075 > ftp.victim.lan.tftp:  45 ACK block 0
12:46:11.373762 dhcp-94.victim.lan.2076 > ftp.victim.lan.tftp:  45 ACK block 0

The tftp client notes taht it is getting an 'open timeout' -- for the
tftp-server never turns around the conversation.

wrappers are not an issue -- I have them set:

ALL:   ALL@ALL

No iptables on the box, so no firewall issue.


Unfortunately, the workaround of adding the remote host to the local /etc/hosts
(which works around the mysql issue, does not work here.  add to /etc/hosts

COMPARE and NOTICE: The syslog messages from tftp-server did not contain the
resolved name but rather the IP alone -- interface with the resolver is
seemingly the issue.  tcpdump is NOT having name lookup issues.

[root@ftp xinetd.d]# date
Wed Nov 13 12:48:33 EST 2002

[root@ftp xinetd.d]# tcpdump port 69
tcpdump: listening on eth0
12:48:36.559284 dhcp-94.victim.lan..2070 > ftp.victim.lan..tftp:  40 RRQ
"/lts/vmlinuz-2.4.9-ltsp"
12:48:40.495367 dhcp-94.victim.lan..2071 > ftp.victim.lan..tftp:  40 RRQ
"/lts/vmlinuz-2.4.9-ltsp"
12:48:46.576582 dhcp-94.victim.lan..2072 > ftp.victim.lan..tftp:  45 RRQ
"/lts/vmlinuz-2.4.9-ltsp"
12:48:50.518509 dhcp-94.victim.lan..2073 > ftp.victim.lan..tftp:  45 RRQ
"/lts/vmlinuz-2.4.9-ltsp"
12:48:58.427166 dhcp-94.victim.lan..2074 > ftp.victim.lan..tftp:  45 ACK block 0
12:49:10.290172 dhcp-94.victim.lan..2075 > ftp.victim.lan..tftp:  45 ACK block 0
12:49:26.107511 dhcp-94.victim.lan..2076 > ftp.victim.lan..tftp:  45 ACK block 0

7 packets received by filter
0 packets dropped by kernel

(extract from /var/log/messages)

Nov 13 17:45:41 ftp in.tftpd[26412]: RRQ from 10.250.0.94 filename
/lts/vmlinuz-2.4.9-ltsp
Nov 13 17:45:45 ftp in.tftpd[26413]: RRQ from 10.250.0.94 filename
/lts/vmlinuz-2.4.9-ltsp
Nov 13 17:46:45 ftp in.tftpd[26417]: RRQ from 10.250.0.94 filename
/lts/vmlinuz-2.4.9-ltsp
Nov 13 17:46:49 ftp in.tftpd[26418]: RRQ from 10.250.0.94 filename
/lts/vmlinuz-2.4.9-ltsp
Nov 13 17:46:55 ftp in.tftpd[26419]: RRQ from 10.250.0.94 filename
/lts/vmlinuz-2.4.9-ltsp
Nov 13 17:46:59 ftp in.tftpd[26420]: RRQ from 10.250.0.94 filename
/lts/vmlinuz-2.4.9-ltsp
Nov 13 17:48:46 ftp in.tftpd[26443]: RRQ from 10.250.0.94 filename
/lts/vmlinuz-2.4.9-ltsp
Nov 13 17:48:50 ftp in.tftpd[26444]: RRQ from 10.250.0.94 filename
/lts/vmlinuz-2.4.9-ltsp
Nov 13 17:48:56 ftp in.tftpd[26445]: RRQ from 10.250.0.94 filename
/lts/vmlinuz-2.4.9-ltsp
Nov 13 17:49:00 ftp in.tftpd[26446]: RRQ from 10.250.0.94 filename
/lts/vmlinuz-2.4.9-ltsp
Nov 13 17:50:00 ftp in.tftpd[26450]: RRQ from 10.250.0.94 filename
/lts/vmlinuz-2.4.9-ltsp
Nov 13 17:50:04 ftp in.tftpd[26451]: RRQ from 10.250.0.94 filename
/lts/vmlinuz-2.4.9-ltsp
Nov 13 17:50:10 ftp in.tftpd[26452]: RRQ from 10.250.0.94 filename
/lts/vmlinuz-2.4.9-ltsp
Nov 13 17:50:14 ftp in.tftpd[26453]: RRQ from 10.250.0.94 filename
/lts/vmlinuz-2.4.9-ltsp
[root@ftp bin]# date
Wed Nov 13 12:50:30 EST 2002
[root@ftp bin]#


This looks quite similar to the glibc induced problems with in mysql -- see
ticket 75297 "mysql-server-3.23.49-3 and mysqlclient9-3.23.22-6 and
php-mysql-4.1.2-7.3.4 RHL 7.3 when I update to the new glibc update series
glibc-2.2.5-40, it stops working -- "

Bottom line: -- a local server can connect fine -- a remote one, not in
/etc/hosts, cannot.

Test environment -- I had been trying teh Peter Arvin tftp-server, and it has
the same issued with the resolver.

[root@ftp bin]# locate tftp | grep rpm
/var/ftp/pub/mirror/redhat/rawhide/SRPMS/tftp-0.29-3.src.rpm
/var/ftp/pub/mirror/ORC/tftp-hpa/tftp-hpa-0.32-1.i386.rpm
/var/ftp/pub/mirror/ORC/tftp-hpa/tftp-hpa-0.32-1.src.rpm
/var/ftp/pub/install/ftpinstall/RedHat/RPMS/tftp-0.29-3.i386.rpm
/var/ftp/pub/install/ftpinstall/RedHat/RPMS/tftp-server-0.29-3.i386.rpm
/etc/xinetd.d/tftp.rpmsave
/home/herrold/dl/tftp-hpa-0.32-1.i386.rpm
[root@ftp bin]# rpm -e tftp-hpa
[root@ftp bin]# rpm -Uvh
/var/ftp/pub/install/ftpinstall/RedHat/RPMS/tftp-server-0.29-3.i386.rpm
Preparing...                ########################################### [100%]
   1:tftp-server            warning: /etc/xinetd.d/tftp created as
/etc/xinetd.d/tftp.rpmnew
########################################### [100%]
[root@ftp bin]# mv /etc/xinetd.d/tftp /etc/xinetd.d/tftp-hpa.rpmold
[root@ftp bin]# mv /etc/xinetd.d/tftp.rpmnew /etc/xinetd.d/tftp
[root@ftp bin]# service xinetd restart
Stopping xinetd:                                           [  OK  ]
Starting xinetd:                                           [  OK  ]
[root@ftp bin]# rpm -Uvh
/var/ftp/pub/install/ftpinstall/RedHat/RPMS/tftp-0.29-3.i386.rpm
Preparing...                ########################################### [100%]
   1:tftp                   ########################################### [100%]


Session extract showing it working for localhost conencts ...

[root@ftp bin]# tftp localhost
tftp> get /lts/vmlinuz-2.4.9-ltsp
Received 1117242 bytes in 3.4 seconds
tftp>

so it is working locally -- just not remotely.