Odd tftp problem

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).

Cheers.............pk.

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.

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?

Tarvos{k}

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

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

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

-ja

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.

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.