Updating NMC Firmware Without FTP (FTP Disabled)

[netadmin_at_princessauto.com_apc]

Hello,

We would like to update the firmware on our AP9630 devices to v6.0.6.

The download links for firmware updater allow for download of a program that updates NMC firmware via FTP.

We have disabled FTP on all of our UPS devices in favour of the more secure SCP, so this is not appropriate for us to update with. For the benefit of those using FTP, I'll also point out that it doesn't appear to support use of a non-standard FTP port either even though the NMC supports using a non-standard port  (perhaps it is possible to use the updater with a non-standard port but if so, the way to do it is not obvious).

What are the instructions to update NMC firmware via SCP? What files need to be put in which folders, and what needs to happen to make them active? What must happen with the old (i.e. current) firmware places being replaced?

[voidstar_apc]

I can't help you with SCP, but for your other questions:

1) You don't need to use the updater. The updater comes as a self-extracting executable, and you can rename it with a .zip extension to get the constituent files. Then you can use the command line FTP program, which accepts a port, to copy the AOS file in first. After the transfer finishes, the NMC will reboot and then you can FTP in the APP file.

2) Like with config.ini, the firmware files are not real files on the device. The update overwrites part of the previous firmware. If the update fails (either AOS or APP), the working AOS is retained so the card will still accept updates and you can re-attempt.

Maybe someone else here knows more about using scp with the NMC.

[netadmin_at_princessauto.com_apc]

From what we can tell from using a non-NMC FTP server with the firmware updater, here is the procedure that it uses :

1. Retrieve "data.txt" from FTP root folder (shouldn't be necessary for SCP upgrade)
2. Retrieve "config.ini" from FTP root folder (shouldn't be necessary for SCP upgrade)
3. Retrieve "event.txt" from FTP root folder (shouldn't be necessary for SCP upgrade)
4. Upload boot monitor image ("apc_hw05_bootmon_102.bin") to FTP root folder
5. Wait for reboot
6. Upload os image ("apc_hw05_aos_606.bin") to FTP root folder
7. Wait for reboot
8. Upload application image ("apc_hw05_sumx_606.bin") to FTP root folder
9. Wait for reboot
10. Retrieve "data.txt" from FTP root folder (shouldn't be necessary for SCP upgrade)

[ this is assuming no language pack install, as is the case for us ]

Can we just do steps 4-9 using SCP instead of FTP to accomplish the upgrade?

[BillP]

Yes, the process would be the same no matter how you update the firmware - same order for the files, wait for reboot, etc. The log files are just pulled by the wizard we offer for determing the firmware version at the top of the file and for back up purposes.

And no, the upgrade utility we have today does not support a non default port but a future revision likely will.

Here are the instructions we have for SCP for reference: How do I upgrade the firmware on an APC Network Management Card? | FAQs | Schneider Electric US

[netadmin_at_princessauto.com_apc]

SCP doesn't seem to be working from either WinSCP (Windows) or scp (Linux - OpenSSH) to an NMC running v5.1.7.

For scp, the following shows up in the NMC logs when attempting to copy:

     02/12/2014  15:09:47  System: SSH/SCP: File transfer failed.

     02/12/2014  15:09:47  System: SSH/SCP: File transfer started.

Linux side:

[user@host ~]$ scp -v -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no ~/apc_hw05_bootmon_102.bin upsadminaccount@upsname.domain.internal:/apc_hw05_bootmon_102.bin

Executing: program /usr/bin/ssh host upsname.domain.internal, user upsadminaccount, command scp -v -t -- /apc_hw05_bootmon_102.bin

OpenSSH_5.6p1, OpenSSL 1.0.0j-fips 10 May 2012

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: Applying options for *

debug1: Connecting to upsname.domain.internal [10.1.2.3] port 22.

debug1: Connection established.

debug1: identity file /home/user/.ssh/id_rsa type -1

debug1: identity file /home/user/.ssh/id_rsa-cert type -1

debug1: identity file /home/user/.ssh/id_dsa type -1

debug1: identity file /home/user/.ssh/id_dsa-cert type -1

debug1: Remote protocol version 2.0, remote software version cryptlib

debug1: no match: cryptlib

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_5.6

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug1: kex: server->client 3des-cbc hmac-md5 none

debug1: kex: client->server 3des-cbc hmac-md5 none

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<2048<8192) sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

debug1: SSH2_MSG_KEX_DH_GEX_INIT sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

Warning: Permanently added 'upsname.domain.internal,10.1.2.3' (RSA) to the list of known hosts.

debug1: ssh_rsa_verify: signature correct

debug1: SSH2_MSG_NEWKEYS sent

debug1: expecting SSH2_MSG_NEWKEYS

debug1: SSH2_MSG_NEWKEYS received

debug1: Roaming not allowed by server

debug1: SSH2_MSG_SERVICE_REQUEST sent

debug1: SSH2_MSG_SERVICE_ACCEPT received

debug1: Authentications that can continue: password

debug1: Next authentication method: password

upsadminaccount@upsname.domain.internal's password:

debug1: Authentication succeeded (password).

Authenticated to upsname.domain.internal ([10.1.2.3]:22).

debug1: channel 0: new [client-session]

debug1: Entering interactive session.

debug1: Sending environment.

debug1: Sending env LANG = en_US.UTF-8

debug1: Sending command: scp -v -t -- /apc_hw05_bootmon_102.bin

debug1: channel 0: free: client-session, nchannels 1

debug1: fd 0 clearing O_NONBLOCK

debug1: fd 1 clearing O_NONBLOCK

Transferred: sent 1656, received 1528 bytes, in 1.0 seconds

Bytes per second: sent 1701.9, received 1570.4

debug1: Exit status -1

lost connection

[BillP]

Off the top of my head, I was wondering if this was the same issue as https://bugzilla.mindrot.org/show_bug.cgi?id=1814 where there is an extra hyphen..

Have you tried multiple clients for this function too? I am definitely aware of a few issues with OpenSSH..I was wondering if pscp worked for you, for example, or WinSCP - not sure if you could just try to confirm if we are just having a problem with OpenSSH.

[netadmin_at_princessauto.com_apc]

We have similar problems when trying to copy using WinSCP from a Windows host :

>winscp.com upsadminaccount:@upsname.domain.internal /command "put apc_hw05_bootmon_102.bin /apc_hw05_bootmon_102.bin"

Searching for host...

Connecting to host...

Authenticating...

Using username "upsadminaccount".

Authenticating with pre-entered password.

Authenticated.

Starting the session...

Host is not communicating for more than 15 seconds. Still waiting...

Warning: Aborting this operation will close connection!

(A)bort:

Connection has been unexpectedly closed. Server sent command exit status 0.

Error skipping startup message. Your shell is probably incompatible with the application (BASH is re

commended).

No session.

winscp>

This holds true whether the copy destination is "/" or "/apc_hw05_bootmon_102.bin". It also holds true if using the WinSCP GUI.

We don't even see the failed file transfer in the NMC logs when using WinSCP :

02/12/2014  16:46:01  System: Console user 'upsadmina...' logged out from

                            10.1.2.3.

02/12/2014  16:43:01  System: Console user 'upsadmina...' logged in from

                            10.1.2.3.

[BillP]

Good morning. I spent the last hour or two looking at this. I also had an issue with WinSCP and in the debug log, it also looked as though it somehow logged in via the CLI (SSH) based on the output it echoed. So, I was confused by that. The SSH/SCP portion of the code is not updated in every revision unfortunately too.

For the short term, I did get pscp to successfully transfer files. I am not sure if that is an option for you at least to get moving in your upgrades.

In the next day, since v5.1.7 is not the latest release, I am going to see what I can find with upgrading v6.X.X devices via SCP and see if it is fixed there, and if not, log an issue to be reviewed ASAP.

Here is the syntax below from my successful pscp transfer via v5.1.7 (please note, you can skip bootmonitor if the bundled version is already the same as what is on the card so I did that):

(I just reflashed to v5.1.7)

C:\Users\Angela\Desktop>pscp -v C:\Users\Angela\Desktop\FW\apc_hw05_aos_517.bin apc@10.218.44.169:apc_hw05_aos_517.bin

Looking up host "10.218.44.169"

Connecting to 10.218.44.169 port 22

Server version: SSH-2.0-cryptlib

Using SSH protocol version 2

We claim version: SSH-2.0-PuTTY_Release_0.63

Doing Diffie-Hellman group exchange

Doing Diffie-Hellman key exchange with hash SHA-1

The server's host key is not cached in the registry. You

have no guarantee that the server is the computer you

think it is.

The server's rsa2 key fingerprint is:

ssh-rsa 2048 a2:0c:a1:1f:9a:07:de:ca:b9:14:52:49:7d:a0:c3:19

If you trust this host, enter "y" to add the key to

PuTTY's cache and carry on connecting.

If you want to carry on connecting just once, without

adding the key to the cache, enter "n".

If you do not trust this host, press Return to abandon the

connection.

Store key in cache? (y/n) y

Host key fingerprint is:

ssh-rsa 2048 a2:0c:a1:1f:9a:07:de:ca:b9:14:52:49:7d:a0:c3:19

Initialised AES-256 CBC client->server encryption

Initialised HMAC-SHA1 client->server MAC algorithm

Initialised AES-256 CBC server->client encryption

Initialised HMAC-SHA1 server->client MAC algorithm

Using username "apc".

apc@10.218.44.169's password:

Sent password

Access granted

Opening session as main channel

Opened main channel

Primary command failed; attempting fallback

Started a shell/command

Using SCP1

Connected to 10.218.44.169

Sending file apc_hw05_aos_517.bin, size=2288640

apc_hw05_aos_517.bin      | 2235 kB |  21.5 kB/s | ETA: 00:00:00 | 100%

Fatal: Received unexpected end-of-file from server

Repeated the same for the sumx 5.1.7 file. There are a few System: SSH/SCP: File transfer started. in my logs as expected and my firmware has been loaded successfully again and I can log in.

I'll report back on any further findings. My current thought is we are aware of issues with OpenSSH v5 in general and then now WinSCP.

[netadmin_at_princessauto.com_apc]

Re: Never versions of OpenSSH :

[ from : Google Groups ]

>It was confirmed that openssh can't connect to the server with a server string

>'SSH-2.0-cryptlib' using diffie-hellman-group-exchange-sha1 and 3des-cbc with

>SSH2_MSG_KEX_DH_GEX_REQUEST(1024<7680<8192).

This manifests itself as shown:

[user@host ~]$ scp -v -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no ~/apc_hw05_bootmon_102.bin upsadminaccount@upsname.domain.internal:/apc_hw05_bootmon_102.bin

Executing: program /usr/bin/ssh host upsname.domain.internal, user upsadminaccount, command scp -v -t /apc_hw05_bootmon_102.bin

OpenSSH_6.4, OpenSSL 1.0.1e-fips 11 Feb 2013

debug1: Reading configuration data /etc/ssh/ssh_config

debug1: /etc/ssh/ssh_config line 51: Applying options for *

debug1: Connecting to upsname.domain.internal [10.1.2.3] port 22.

debug1: Connection established.

debug1: identity file /home/user/.ssh/id_rsa type -1

debug1: identity file /home/user/.ssh/id_rsa-cert type -1

debug1: identity file /home/user/.ssh/id_dsa type -1

debug1: identity file /home/user/.ssh/id_dsa-cert type -1

debug1: identity file /home/user/.ssh/id_ecdsa type -1

debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_6.4

debug1: Remote protocol version 2.0, remote software version cryptlib

debug1: no match: cryptlib

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug1: kex: server->client 3des-cbc hmac-md5 none

debug1: kex: client->server 3des-cbc hmac-md5 none

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<7680<8192) sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

Received disconnect from 10.1.2.3: 2: Handshake failed

lost connection

[netadmin_at_princessauto.com_apc · Accepted solution]

The following will start a transfer from OpenSSH 6.4 (specify to use blowfish as the cipher), but we had the file copy stall out on us (over LAN) :

scp -v -c blowfish -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no ~/apc_hw05_bootmon_102.bin upsadminaccount@upsname.domain.internal:/apc_hw05_bootmon_102.bin