topic onboard administrator CLI ftp/tftp issues in BladeSystem - General

onboard administrator CLI ftp/tftp issues

Bob_Vance — Thu, 15 May 2008 18:13:20 GMT

C7000, OA 2.20
ssh to CLI.
Can do all sorts of config.
BUT, having trouble with tftp and ftp for updating firmware.

TFTP:
Does not seem to work at all.
On any download from my tftp server (Linux RH4) it says
"not a valid OA firmware image."
even with a non-existent filename!
E.g.,
>update image tftp://10.1.0.99/tftpboot/hpoa220.bin
>update image ftp://nevis.testtrack/pub/hpoa220.binXX
both give same error.

Yet another box can do a 'tftp get' of the valid file with no problems

FTP:
Works fine for UPDATE IMAGE.
E.g.,
>update image ftp://nevis.testtrack/pub/hpoa220.bin

((notice that same bin file is copied to different locations
on my server for tftp versus ftp.
))

UPLOAD CONFIG:
With BOTH ftp and tftp,
it **ALWAYS** says it uploaded Successfully,
even when no file is copied at all.
E.g.,
> upload config tftp://nevis.testtrack/tftpboot/oacfg
> upload config ftp://nevis.testtrack/pub/oacfg

Even when I embed a userid:password with ftp,
AND when I give it a bogus userid, or give an invalid directory,
it always says "Successfully uploaded"
E.g.,
> upload config ftp://nevis.testtrack/pubNOT/oacfg

Further, UPLOAD CONFIG via TFTP never writes a file,
yet another system can 'tftp put' to the tftp server.

FTP DOES work, however (when you set up ftp permissions
properly for anonymous ftp (or use a valid id:pw)).

Has anybody else seen this, specifically the TFTP.
Is anyone having joy with this?
I can live with FTP, but am curious.

bv

Re: onboard administrator CLI ftp/tftp issues

Raghuarch — Thu, 15 May 2008 20:05:08 GMT

Hi Bob,

I have tried with TFTP and it always works fine for me.
i have a tftp client running in my windows box.
All i do is copy the Firmware to programs files and tftp desktop. and start tftp server.

update image tftp://X.X.X.X/hpem.rom

It works fine. are you pointing to correct location.

upload config tftp://X.X.X.X/testscript.cfg
download config tftp://X.X.X.X/testscript.cfg

Re: onboard administrator CLI ftp/tftp issues

Bob_Vance — Thu, 15 May 2008 20:53:16 GMT

Thanks.
What version of the OA do you have?

There is definitely a bug in my 2.20. I get
"Success..."
even when I give it an invalid IP or a non-existen host !!!!
E.g.,
>upload config tftp://nohost.nowhere/tftpboot/oacfg

Immediately comes back with "Success", while a
> ping nohost.nowhere
immediately comes back with an "Unknown host"

At least I know it works somewhere.

bv

Re: onboard administrator CLI ftp/tftp issues

Ken Miller_3 — Wed, 10 Sep 2008 14:38:54 GMT

Hello,

I too believe tftp protocol is broken for firmware updates. I have tested 2.02, 2.10, 2.20, and 2.25. All of these versions successfully update with ftp protocol; however, using tftp protocol always results "OA_Flash: Invalid flash image." In the standby OA syslog.

Yet, I can consistently tftp the very same file to a Linux client from the very same Linux deployment server and every time I receive the correct checksum. Given that the file with this checksum installs successfully using FTP and tftp copies from this very server succeeds to Linux clients, I can only conclude that it is tftp protocol that is broken within the OA firmware upgrade software.

Here are the commands that work (using latest firmware, same is true since 2.02):

OA> update image ftp://172.20.51.1/hpoa225.bin

# tftp 172.20.51.1 -c get /opt/cmu/ntbt/tftp/hpoa225.bin /tmp/hpoa225.bin
# md5sum /tmp/hpoa225.bin
3e950535b3eb030af7016c4667f67f06 /tmp/hpoa225.bin
# md5sum /srv/ftp/hpoa225.bin
3e950535b3eb030af7016c4667f67f06 /srv/ftp/hpoa225.bin
#

And here's the command that does not work:

OA> update image force tftp://172.20.51.1/opt/cmu/ntbt/tftp/hpoa225.bin

Is there a more appropriate place to report this bug? I am automating this process for large clusters with either SLES 10 or RHEL5 and would very much like to use TFTP instead of FTP.

Thanks and Regards,

== k ==

Re: onboard administrator CLI ftp/tftp issues

Bob_Vance — Wed, 10 Sep 2008 14:54:20 GMT

Thanks for the corroboration!

bv