Bug 46699

Summary: TFTP shutdown due to looping after multiple requests from same host
Product: [Retired] Red Hat Linux Reporter: Michael Will <mtwill>
Component: tftpAssignee: Elliot Lee <sopwith>
Status: CLOSED NOTABUG QA Contact: David Lawrence <dkl>
Severity: high Docs Contact:
Priority: high    
Version: 7.0   
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: 2001-07-30 13:05:20 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:

Description Michael Will 2001-06-29 21:16:57 UTC
Description of Problem:
The problem is another box (Lucent) is using TFTP to download code to the 
CPU's.  The first TFTP request is successful when the PROM request code, 
the CPU is then loaded and the TFTP server is then hit again with multiple 
request for multiple files (8 total).  Problem the request's for file are 
simultaneous, which the TFTP server begins to fill the first request, the 
second and following are denied and the TFTP server graceful shuts down 
due to a suspect LOOPING from the SERVER.  Technically it is NOT, just 
being hit with multiple request.  I believe the programmer simply place a 
security option here, to prevent denial of service attack which should be 
commended, but unfortunately the Lucent box issues multiple requests at 
once.

I downloaded a PC version (shareware) TFTP for testing making sure the 
TFTP and Lucent would work fine.  It did, however, it to showed multiple 
requests at one time.  However, PC programmers are not really in tune with 
DOS attacks and would NOT check for that possibility which the Lucent box 
is able to re-request the files and load fine.

Is there an option for turning this feature off (assuming my assumption is 
right)?  If my assumption is wrong, then there is a bug in the TFTP server 
that fails after multiple request from the same host.

We need to get this elevated to be worked on as a bug or for a solution.  
Please call me at (202) 530-3507 and let me know the status.


How Reproducible:
VERY! Every time we need to load the CPU's from the LUCENT Box.

Steps to Reproduce:
1. Startup INETD with TFTP
2. Force Lucent reboot
3. Loads one file, CPU reboots and then causes the TFTP to shut down.

Actual Results:
TFTP works with one, file fine, but fails after receving multiple requests 
at once.

Expected Results:
TFTP should remain up and acknowledging the requests.

Additional Information:
Running RedHat Linux 7.0 with the upgrade TFTP server version 0.17-12 
gotten from ftp://people.redhat.com/hdeller

Comment 1 Phil Knirsch 2001-07-30 12:14:31 UTC
*** Bug 49968 has been marked as a duplicate of this bug. ***

Comment 2 Ron Flory 2001-07-30 13:05:15 UTC
From what I can see, this problem results when the TFTP 'get' comes from a machine that is NOT known to a nameserver, which is probably queried as 
part of PAM or some other authorization check.   It appears that while NSlookups are being made, the TFTP server cannot reply to the client, causing the 
client to issue many retries.  If the embedded TFTP client is known to a nameserver, or present in the servers /etc/hosts file, the 'get' is granted almost 
immediately, however this is not practical in a manufacturing/engineering environment.

 Since TFTP is by its very nature insecure, and those using TFTP tend to be embedded devices that do NOT have a nameserver entry, I feel that all 
'name' checks should be removed (or at least made optional).  The xinetd config files already allow us to filter which IP's we will respond to, which at least 
lets us grant TFTP access to trusted local subnets while protecting us from TFTP attacks on other 'public' networks.


Comment 3 Michael Will 2001-07-30 20:32:06 UTC
This may not be a bug... Found an option in the xinetd.conf man pages that 
allows you to set the "loop" feature.  xinetd seems to have the built in 
security to turn off the service if the request comes in to often.  By starting 
xinetd with the -loop NNN option you can specify how many times a machine can 
request connections.   By setting this option, the TFTP server stayed on.

Feature instead of a bug.  Initially Red Hat stated it was a TFTP error, but 
looks like it is a feature in xinetd.

Michael