Here’s an internal email I sent out to our UCS guys when I completed my first firmware update from 1.1(1l) to 1.2(1d):
I just wanted to give you a heads up that I had a lot of issues with having UCSM download an updated firmware package via TFTP or FTP. I was able to get the package downloaded via FTP at the end but thought I’d share the strange behavior I experienced in case you guys have to go through this exercise in the future.
Client’s UCS Firmware: 1.1(1l)
Latest UCS Firmware Bundle: 1.2(1d)
TFTP / FTP Software: 3CDaemon
TFTP Problem
As we all already know, TFTP does not require user credentials and it was the first method I tried but what I noticed was that UCSM would be able to connect to the TFTP server but would eventually fail. When reviewing the logs on 3CDaemon, I would see the following:
Looking deeper into the debugging logs of 3CDaemon, we will find the following entries:
May 31, 2010 15:20:13 Session 4, Peer 10.20.60.51 Retry. Block = 1. Retries left = 9
May 31, 2010 15:20:13 Session 2, Peer 10.20.60.51 Retry. Block = 1. Retries left = 7
May 31, 2010 15:20:13 Session 3, Peer 10.20.60.51 Retry. Block = 1. Retries left = 8
May 31, 2010 15:20:13 Session 4, Peer 10.20.60.51 TFTP: Thread: 648 Retry. Block = 1. Retries left = 9
May 31, 2010 15:20:13 Session 2, Peer 10.20.60.51 TFTP: Thread: 424 Retry. Block = 1. Retries left = 7
May 31, 2010 15:20:13 Session 3, Peer 10.20.60.51 TFTP: Thread: 524 Retry. Block = 1. Retries left = 8
May 31, 2010 15:20:13 Session 5, Peer 10.20.60.51 Client requests GET of file C:\UCS\ucs-k9-bundle.1.2.1d.bin.
May 31, 2010 15:20:13 Session 5, Peer 10.20.60.51 TFTP: Thread 716, Sent 512 bytes, Block Number = 1
May 31, 2010 15:20:13 Session 1, Peer 10.20.60.51 Retry. Block = 1. Retries left = 6
May 31, 2010 15:20:13 Session 1, Peer 10.20.60.51 TFTP: Thread: 380 Retry. Block = 1. Retries left = 6
May 31, 2010 15:20:18 Session 3, Peer 10.20.60.51 Retry. Block = 1. Retries left = 7
May 31, 2010 15:20:18 Session 5, Peer 10.20.60.51 Retry. Block = 1. Retries left = 9
May 31, 2010 15:20:18 Session 2, Peer 10.20.60.51 Retry. Block = 1. Retries left = 6
May 31, 2010 15:20:18 Session 4, Peer 10.20.60.51 Retry. Block = 1. Retries left = 8
May 31, 2010 15:20:18 Session 3, Peer 10.20.60.51 TFTP: Thread: 524 Retry. Block = 1. Retries left = 7
May 31, 2010 15:20:18 Session 5, Peer 10.20.60.51 TFTP: Thread: 716 Retry. Block = 1. Retries left = 9
May 31, 2010 15:20:18 Session 2, Peer 10.20.60.51 TFTP: Thread: 424 Retry. Block = 1. Retries left = 6
May 31, 2010 15:20:18 Session 4, Peer 10.20.60.51 TFTP: Thread: 648 Retry. Block = 1. Retries left = 8
May 31, 2010 15:20:18 Session 1, Peer 10.20.60.51 Retry. Block = 1. Retries left = 5
May 31, 2010 15:20:18 Session 1, Peer 10.20.60.51 TFTP: Thread: 380 Retry. Block = 1. Retries left = 5
I’ve tried cancelling the download job in UCSM and restarting probably 10 times after changing Windows security permissions and folder locations without any luck. What’s strange is that I had no issues downloading the file with Windows’ TFTP client. Seeing how I haven’t made any progress, I went ahead and moved onto FTP.
FTP Problem
As soon as I moved onto trying to download via FTP, I noticed that the connection would continuously say Session closed by peer.
Reviewing the 3CDaemon logs every time it logs the status above would indicate something different. What’s strange is that there are times when UCSM’s firmware download status would stay @ 2% and not error out. I tried anonymous access but wasn’t able to get that going either. What I ended up doing was redo-ing the firmware download process in UCSM again, saw the Session closed by peer message, then left the computer for a few hours. To my surprise, the package downloaded when I got back to the computer.
Unfortunately, I’m not exactly sure if some of my changes fixed some problems that was preventing the package from being downloaded. With that being said, one of the things I’m sure of is that the download process gets stuck at 2% for a long time before bytes get transferred so I would say give it at least 30 minutes before terminating the session if you suspect something is wrong.
3 comments:
i am currently experiencing the same problem, what disheartens me is that the ucs manager give the FSM status Download Fail. let me try and be patient and see whether it works.great post, im a big fun of your blog
same predicament but finally it worked.. demands patience
try this, 3cdaemon ftp server and tftpd here
Post a Comment