07-29-2014 11:28 AM
I have a customer with a deployment of CPI 1.3 and I have been tasked with upgrading it to CPI 2.1.
According to the Cisco documentation I need to apply "patch 4" from the CLI before I can upgrade.
I downloaded the file and when I try to tftp the file to the CPI server it fails every time. I have tried this from multiple working tftp/ftp servers without success.
unfortunately, I did not build out the CPI 1.3 server nor is the build documented or is there anyone onsite that knows anything about the deployment.
How do I confirm IPtables is running on the server from the CLI?
The server is not completing the file transfer and the log on the tftp server is:
Connection received from 192.168.10.50 on port 13806 [29/07 14:11:12.352]
Read request for file <PI_1_3_0_20-Update.4-16.tar.gz>. Mode octet [29/07 14:11:12.352]
Using local port 52190 [29/07 14:11:12.352]
Connection received from 192.168.10.50 on port 13806 [29/07 14:11:17.359]
Read request for file <PI_1_3_0_20-Update.4-16.tar.gz>. Mode octet [29/07 14:11:17.359]
Using local port 52204 [29/07 14:11:17.359]
Connection received from 192.168.10.50 on port 13806 [29/07 14:11:22.351]
Read request for file <PI_1_3_0_20-Update.4-16.tar.gz>. Mode octet [29/07 14:11:22.351]
Using local port 52217 [29/07 14:11:22.351]
Connection received from 192.168.10.50 on port 13806 [29/07 14:11:27.359]
Read request for file <PI_1_3_0_20-Update.4-16.tar.gz>. Mode octet [29/07 14:11:27.359]
Using local port 52233 [29/07 14:11:27.359]
Connection received from 192.168.10.50 on port 13806 [29/07 14:11:32.351]
Read request for file <PI_1_3_0_20-Update.4-16.tar.gz>. Mode octet [29/07 14:11:32.366]
Using local port 52252 [29/07 14:11:32.366]
TIMEOUT waiting for Ack block #1 [29/07 14:12:14.486]
TIMEOUT waiting for Ack block #1 [29/07 14:12:19.478]
TIMEOUT waiting for Ack block #1 [29/07 14:12:24.486]
TIMEOUT waiting for Ack block #1 [29/07 14:12:29.494]
TIMEOUT waiting for Ack block #1 [29/07 14:12:34.486]
I end up with a file that has no content as shown in the attached graphic.
09-17-2018 06:07 PM
TIMEOUT waiting for Ack block #1 I got the same banner and I solved it with the command 'IP TFTP Source-Interface'
Is a connectivity problem not from the configuration of the tftp server.
First. this banner show that the tftp session cannot start up correctly.
TFTP overall work like this It send a message to start the communication and need an ack to realize that the session is up (ack #1). In my case I had a lot of sub interfaces in the router but for a reason that I don’t know why the message never arrived to the tftp server, I would like to suppose the request of acknowledgment message took one incorrect sub interface and for this reason the packet lost. I checked with other device (Switch) that connected correctly with the tftp and checked which network ID I use and use the command "IP TFTP Source-Interface" in the router with the same sub interface which was in the switch network ID and it worked.
So, I think you have to ask you why the Ack message lost or don’t arrive to the tftp server?
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide