Description of problem: Cisco IOS version 12.2 has problems with tftp-server 0.32 as shipped with RHEL3. The problems as already been corrected in version 0.37 though... from http://www.kernel.org/pub/software/network/tftp/CHANGES: Changes in 0.37: Fix a pathology where a client sending ACKs for the wrong packet can prevent proper retransmission. This is the fix that Cisco IOS 12.2 and probably other tftp clients need. Please publish an errata with 0.37 !
tftp 0.38 will be in RHEL4b1 (and FC3t2) so the issue will definitely be resolved in the future. I don't know about doing a RHEL3 erratum - will see how high it gets on the TODO stack :)
The reference to the fix in 0.37 was due to a mis-diagnosis. The problem that they are encountering is a high total transfer time due to excessive Socerer's Apprentice Syndrom related packets. The following is a small segment from one of their transfers: No. Time Source Destination Info 1 0.000000 172.20.249.100 172.20.249.254 Acknowledgement, Block: 896 2 0.000042 172.20.249.254 172.20.249.100 Data Packet, Block: 897 3 0.000222 172.20.249.100 172.20.249.254 Acknowledgement, Block: 896 4 0.000234 172.20.249.254 172.20.249.100 Data Packet, Block: 897 5 0.000447 172.20.249.100 172.20.249.254 Acknowledgement, Block: 896 6 0.000460 172.20.249.254 172.20.249.100 Data Packet, Block: 897 7 0.000642 172.20.249.100 172.20.249.254 Acknowledgement, Block: 897 8 0.000655 172.20.249.254 172.20.249.100 Data Packet, Block: 898 9 0.000978 172.20.249.100 172.20.249.254 Acknowledgement, Block: 897 10 0.000991 172.20.249.254 172.20.249.100 Data Packet, Block: 898 11 0.002183 172.20.249.100 172.20.249.254 Acknowledgement, Block: 897 12 0.002196 172.20.249.254 172.20.249.100 Data Packet, Block: 898 13 0.002415 172.20.249.100 172.20.249.254 Acknowledgement, Block: 897 14 0.002427 172.20.249.254 172.20.249.100 Data Packet, Block: 898 15 0.002634 172.20.249.100 172.20.249.254 Acknowledgement, Block: 897 16 0.002647 172.20.249.254 172.20.249.100 Data Packet, Block: 898 17 0.002827 172.20.249.100 172.20.249.254 Acknowledgement, Block: 898 18 0.002840 172.20.249.254 172.20.249.100 Data Packet, Block: 899 The tftp-0.28-malta.patch being applied to the RHEL3 RPM violates the RFC specifications and is causing this behavior. Intentionally breaking the default behavior should be enabled via an optional flag (if it is left in at all).
Please do NOT ship 0.38. It has a serious timeout bug that can cause the server to go into a packet-spew mode. This bug has been fixed in 0.39.
0.39 is in FC3 devel tree now, sans the malta patch.
PING. Any possibility of this happening in RHEL3? Some of us have cable modems to boot ya know :)
I'm hoping for an update *before* U4... there are a boatload of Cisco routers running IOS version 12.2 that don't work with what Red Hat is shipping today :-(
A response of "no" is better than a response of "..." ;-)
Hmm probably that was the alias getting added. This bug is now also a blocker for something else, possibly (hopefully) an internal UPD4 tracking bug? I'm guessing this is prep for the UPD4 beta spin, we're about due. FWIW Red hat typically doesn't do version bumps between the quarterly releases. Some nonsense about QA I think... ;-)
It will be the part of RHEL3-U4 and it won't come out earlier. I'm sorry for your problems but it has to go through QA as it's version "bump" as Nathan mentioned.
Thanks for the update! The new version is muchly welcomed.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2004-532.html