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
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.
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.
TFTP works with one, file fine, but fails after receving multiple requests
TFTP should remain up and acknowledging the requests.
Running RedHat Linux 7.0 with the upgrade TFTP server version 0.17-12
gotten from ftp://people.redhat.com/hdeller
*** Bug 49968 has been marked as a duplicate of this bug. ***
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.
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.