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
*** 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. Michael