Odd tftp problem

Greetings all,

The other day during my CCNA class we were working on transfering the IOS to a switch by tftp. During the process we got some odd characters on the hyperterminal display during the transfer. Instead of getting all !'s we had several (proabably 5 spaced out on each line) O's (letter o not zero). Many of us have looked for some explaination but no one seems to be able to find one. The image came through just fine, but we are all curious as to what this might mean, including the instructor who has never seen this in the many years he had worked on any of Cisco's products. The switch is a

2950 and the image was being moved from a local tftp server in the same room.

Thanks for any help


Reply to
Loading thread data ...

Hi Tarvos,

I think you may find that the O indicates a error in that block and the block was retransmitted. This is most likely if you are using a HUB or Half-Duplex segment that has other traffic on it at the time the transfer is running, and the sending end detected a collision (IE an OUTPUT error).


Reply to

That's an 'O'out of order packet. It means that the router received (say) packet 5 before it got packet 4. Shouldn't really happen on a LAN, though...

copy Command Character Descriptions

Character Description ! For net transfers an exclamation point indicates that the copy process is taking place. Each exclamation point indicates the successful transfer of ten packets (512 bytes each).

. For net transfers a period indicates the copy process timed out. Many periods in a row typically mean that the copy process may fail.

O For net transfers an uppercase O indicates a packet was received out of order and the copy process may fail.

e For flash erasures, a lowercase e indicates a device is being erased.

E An uppercase E indicates an error. The copy process may fail.

V A series of uppercase Vs indicates the progress during the verification of the image checksum.

Reply to
M.C. van den Bovenkamp

I appreciate the answers that have been sent, but the question I have about this is that if tftp uses udp then sequence shouldn't matter. Or is there some other "order/sequence" that I hadn't heard about involved?


Reply to

If you take a look at the TFTP RFC 1350 you will see that TFTP packets contain a block number within each packet.

Reply to

If you take a look at the TFTP RFC 1350 you will see that TFTP packets contain a block number within each packet.

Reply to

The TFTP session can sometimes fail. To help determine why a TFTP session failed, TFTP generates an "E" character if it receives an erroneous packet, and an "O" character if it receives an out-of-sequence packet. A period (.) indicates a timeout. The transfer session may still succeed even if TFTP generates these characters, but the output is useful for diagnosing the transfer failure


Reply to
John Agosta

As I understand it TFTP was designed to use as little code as possible and is therefore basiclly quite crude. It uses: - 512 byte blocks - each block is numbered (with a 16 bit unsigned - 0-65535) - the sender sends the (n + 1)th block when it receives the acknowledgement for the n th block

- there must be some way of detecting the last block (read the RFC)

Given these constraints (particularly the third one) out of order blocks should not occur, ever.

So what could be causing them?

Duplicated packets within the network could cause them.

e.g. Block n gets duplicated

The receiver is expecting block n, it gets the first one and acknowledges it it is then expecting block n+1 but it gets block n again and flags it as out of order.

e.g Ack n gets duplicated.

the receiver gets block n and sends the Ack. On receiving the ack the sender send block n+1. The receiver receives block n+1 and sends Ack n+1 The duplicate Ack n then appears at the Sender The Sender sends block n+1 (again).

Note that in these cases the duplicated packet stream continues to the end of the file.

tftp is limited to 32M Byte files 512 * 65535

I have heard that some implementations incorrectly use signed integers internally for the block counter and are therefore limited to 16M files.

512 * 32767.

To investigate this use a packet sniffer to see what is going on. You can probably very easily run one on the tftp server.

On Windows; winpcap and ethereal (and windump) are worth getting to know.

On unix: pcap, ethereal, tcpdump.

Linux, for example sems to come with tcpdump built in.

I seem to recall that some tftp inplementations were flawed and caused duplicate packets. This is catastrophic since every duplicate packet creates an additional stream that goes on to the end of the file.

I like tftpd32.exe (I am on windows). I don't like the tftpd that cisco

had on their web site a few years ago.

Reply to

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.