TFTP Error

Unanswered Question
Sep 20th, 2005

I'm trying to copy an IOS to a 3825, the IOS file is 32.1 MB, and when I try to make a copy tftp flash I get the "No such file or directory" message error on the CLI console, but in the log of my tftp server I get a error message that says: "TFTP Error from requesting c3825-adventerprisek9-mz.123-T4.bin : File too large for TFTP Protocol"

I didn't knew that the TFTP was limited by the size of the files.

Does someone know how can I upload this IOS image in my router??


3825 log:


3825#copy tftp flash

Address or name of remote host []?

Source filename [c3825-adventerprisek9-mz.123-14.T4.bin]? c3825-adventerprisek9-mz.123-14.T4.bin

Destination filename [c3825-adventerprisek9-mz.123-14.T4.bin]?

Accessing tftp://

%Error opening tftp:// (No such file or directory)



I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.7 (3 ratings)
scottmac Tue, 09/20/2005 - 14:06

Give 3COM 3CDaemon a try (it's also free).

Make sure you use version 2.0 or higher; version 1 has a file size limitation and some ugly bugs.

3CD is great: it's a TFTP server, an FTP server, and a Syslog server ... later versions can also be a TFTP Client.

It's all I use anymore. Great for classroom use too.



gdelarosa Wed, 09/21/2005 - 09:43

Thanks muca!

I also use solar winds tftp server, but something it's happening with IOS images larger than 16 MB that won't let you transfer it.

I'm tring with a ftp server, but it isn't working...

Richard Burts Wed, 09/21/2005 - 17:42

The design of the TFTP protocol does produce a size limitation (it is based on the size of the field for sequencing numbers that are part of the TFTP packet). Many TFTP server implementations have this limitation. This is why the original post was describing errors on the TFTP server.

As several posts have pointed out there are several implenentations of TFTP server which get around the size limitation. If you use one of those implementations the transfer of large files should work.

It has also been suggested that using FTP is an alternative. I would suggest that you should seriously consider using FTP for image transfers. My reasons are more than the fact that FTP does not have the same size limitation. In fact FTP is a much more efficient protocol for transferring large image files. In TFTP the packets are small and TFTP server sends one packet and waits for an acknowledgement of that packet before it sends the next one. In FTP it uses maximum size packets. And FTP will send several packets before waiting for an acknowlegement (the window size). This means that FTP is orders of magnitude faster in transfering large files than TFTP. I have recently been transfering image files over VPN IPSec/GRE connections. I find that TFTP transfers may time out and abort the transmission. I find that I can transfer the image much faster with FTP.

So I suggest using FTP for image transfers both on the basis of size limitations and also on the efficiency of the transfer and the amount of time that it will take to perform the transfer.



carlosv Tue, 10/04/2005 - 08:12


Maybe I`m missing something but I`ve never had a succesful IOS transfer via FTP. The connection begins but stalls after 32/40 KB. I`ve tried using ip ftp passive but stalls the same. I`ve done this on several routers (2620, 3660, 7600) and different IOS, big or small it just stalls. Maybe the problem is the software (Win XP, GuildFTP Server). Mind you, I tried only for educational pourposes, So I havent dug enough.

The command I use is this:

copy ftp://carlos:carlos@ flash:

Any Ideas?

Richard Burts Tue, 10/04/2005 - 09:11


I do not know why you have had this problem. I have used FTP many times to transfer IOS images. While I have had a few times when the transfer was not successful (timed out or had excessive errors) most of the transfers I have done have been successful. I generally use the command copy ftp: flash: and then fill in server address and file name when prompted. I have trouble believing that the form of the command would make any difference so I have also tried the command your way and it worked for me ok. I am not familiar with that ftp server and do not know if the issue might be related to it.



carlosv Tue, 10/04/2005 - 11:02

Would you be so nice to tell me which FTP server & OS are you using? just to know what to use when the need arises.

Thank you.


Richard Burts Thu, 10/06/2005 - 18:09


I have been slow to respond because there were some things that I needed to check (and because I was surprised at some of what I found and had to re-verify it).

Most of the FTP transfers that I have done recently have been at a customer site. Their FTP server is a Unix box and the FTP software is the software that came with it. My experience has been that the copy started, ran quickly and efficiently, and was much faster and more efficient than TFTP.

When you commented that the FTP software that you use would hang and you asked for suggestions about what to use I decided to see if I could give you a Windows suggestion. I have had good success with the 3COM 3CDaemon software (which was mentioned in one of the posts in this thread) and decided to try it. Much to my amazement when I initiated an FTP transfer with that software I encountered your symptoms. I could see on th PC software that the software transmitted a small amount of data and stopped and the copy process appeared to be hung. I did some things to investigate what was happening including running the copy while sniffing the wire. I saw the session initiated, the transfer start, and the router sent a reset to interrupt the transfer.

As I did things to investigate what is happening I started a copy, looked at what was going on, got interrupted by something, and discovered that if I waited a really long time (about 10 to 20 minutes) the transfer started again and this time it transferred the entire file. So I have done a successful IOS load using 3COM 3CDaemon.

I think that I understand part of what is happening but not while there is such a severe delay. The copy command in IOS (and I think this is the same whether it uses TFTP or FTP) starts a transfer to verify that the address given is an appropriate server, that permissions are ok for the transfer, and that the file name specified does exist and can be transferred. The IOS then interrupts the transfer and checks things like is there enough room in flash for the new file, asks if flash should be cleared, and etc. After the IOS has done its housekeeping it initiates another transfer of the file which should complete successfully. I believe that the delay you see is the time while IOS is doing its checking. I do not know why it was quick when copying from the Unix server and is so long when copying from the Windows server. If I find anything else to explain this or find a way to reduce the delay I will post again.



carlosv Mon, 10/10/2005 - 08:04

Hello Rick,

I did some research too. It seems to me that this is DNS related but I can't tell for sure. I did some tests with my Windows laptop and a Unix server, at first, I had the usual problems, then I registered my laptop on the DNS server running at the Unix box (the routers & computers I´m using are configured to point at this DNS server). And voila! the FTP transfer worked fast and flawlessly. To be sure, I erased the DNS registration and changed the IP address of my laptop so I didn't have a cached DNS resolution, but I was baffled when the FTP worked without problems again. That's why I'm still unsure if this is related or not.

Since the OS difference is the only thing I could suspect maybe there's something in the MS TCP/IP stack which causes this behaviour. Maybe the FTP code in IOS is waiting for DNS resolution all the time.

Anyway... thank you for the time you put in this

issue and I hope we could find a definitive answer.



milan.kulik Mon, 08/14/2006 - 01:31

Hi Rick,

I've got exactly the same experience with the 3Com 3CDaemeon.

But I noticed something more:

On my Checkpoint firewall I can see error messages:

"SmartDefense: The packet was modified due to a potential Bounce Attack (Telnet Options)".

When I disable the FTP SmartDefense protection on my Firewall, then the FTP behaviour is exactly the same you described (it's successfull with a 10 minutes pause in between).

So it looks like Cisco FTP implementation is not 100% correct?

Best regards,

Milan Kulik


This Discussion