Bug 77794 - tftp-server-0.29-3 and glibc 2.2.93 in RHL 8.0 do not work
tftp-server-0.29-3 and glibc 2.2.93 in RHL 8.0 do not work
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: tftp (Show other bugs)
8.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Elliot Lee
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-11-13 13:17 EST by R P Herrold
Modified: 2007-04-18 12:48 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-11-13 13:18:01 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)

  None (edit)
Description R P Herrold 2002-11-13 13:17:53 EST
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.
Comment 1 R P Herrold 2002-11-27 12:40:03 EST
I am not convinced, after further debugging and experimenting with alternative
tftpservers and  -tname options, that my initial report suspecting the RHL
tftp-server and glibc was accurate;  It may have been hardware, xinetd, or PXE
client configuration related.

I am closing this ticket, and will re-open if I can get a clean test case
demonstrating the tie-in -- but for present, I myself am unconvinced that glibc
issues is an accurate statement of the causitive issue.

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