Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Cisco > Odd tftp problem

Reply
Thread Tools

Odd tftp problem

 
 
Tarvos{k}
Guest
Posts: n/a
 
      09-30-2005
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

Tarvos


 
Reply With Quote
 
 
 
 
Peter
Guest
Posts: n/a
 
      09-30-2005
Hi Tarvos,

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


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.

--
Peter from Auckland.

 
Reply With Quote
 
 
 
 
M.C. van den Bovenkamp
Guest
Posts: n/a
 
      09-30-2005
Tarvos{k} wrote:

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


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 With Quote
 
Tarvos{k}
Guest
Posts: n/a
 
      09-30-2005
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}


 
Reply With Quote
 
Merv
Guest
Posts: n/a
 
      09-30-2005

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

 
Reply With Quote
 
Merv
Guest
Posts: n/a
 
      09-30-2005

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

 
Reply With Quote
 
John Agosta
Guest
Posts: n/a
 
      10-01-2005
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




"Tarvos{k}" <(E-Mail Removed)> wrote in message
news:JQ3%e.11128$(E-Mail Removed)...
> 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
>
> Tarvos
>



 
Reply With Quote
 
anybody43@hotmail.com
Guest
Posts: n/a
 
      10-03-2005
> 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.


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 With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
tftp boot problem + Cisco 805 Andree Toonk Cisco 6 05-21-2009 07:46 PM
Odd behavior with odd code Michael Speer C Programming 33 02-18-2007 07:31 AM
booting router from tftp: image is stored within a sub-dir in tftp root Sharad Cisco 0 02-13-2007 11:31 AM
TFTP from a Cisco Catalyst 4006 problem Catalyst_user Cisco 5 03-22-2005 05:07 AM
Cisco 3640 - problem loading IOS from tftp? tige Cisco 1 06-30-2004 07:30 AM



Advertisments