Bug 46699
Summary: | TFTP shutdown due to looping after multiple requests from same host | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Michael Will <mtwill> |
Component: | tftp | Assignee: | 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
*** 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 |