The Firmware Updater Wanted a Serial Cable I Didn't Have

A field story from the recycling pile: an APC Smart-UPS with a 2015-vintage network card that still carried the previous owner's config, an updater utility that demanded a serial connection I didn't own, and the part where the cable turned out to be for unbricking, not updating.

The setup

I pull gear out of the recycle pile the way other people check the classifieds. This find was an APC Smart-UPS SMT1000RM2UC, a 2U rack UPS built 04/21/2018, with a network management card slotted in the back: an AP9630, hardware revision 5, manufactured 02/02/2015. The card had a whole previous life stapled to it and the firmware to prove it.

The plan for this UPS is specific. It runs the backup-and-disaster- recovery box and the NAS I'm putting together for a customer, which means the network card matters: I want an alert when that gear is running on battery, and I want the card itself current and locked down before it goes into a rack at someone else's site.

Previous life, you ask. The card booted up on my bench still holding its last owner's fingerprints: a stale static IP address on a subnet I wasn't using anymore, a DHCP hostname that named a city several hundred miles from here, and a mail configuration pointed at somebody's Gmail account. An alerting system for a company that doesn't exist anymore. Also, the thing I want you to remember: zero events were wired to email. The previous owner had typed all those SMTP settings into a card that was never going to send a single message with them. Alerting theater. It happens more than you'd think.

The good news: the UPS part was fine. I put a fresh APCRBC132 battery in it on 10/05, and the card's own stored date field still said the battery was from 12/12/2022. That's the kind of thing that matters when a card computes its own "replace battery by" date off a stale field. I fixed the date with an SNMP write and got the card talking to the network. Well. Sort of.

First: what actually broke

Two things, and the first one is a good lesson in why devices disappear on networks.

The card was on the LAN the whole time, but it was invisible to every normal discovery method. It wasn't in DHCP leases because it wasn't asking. It wasn't in the router's ARP table because the router never had a reason to talk to it. My nmap sweeps missed it for the same reason. A device holding a stale static IP doesn't answer discovery probes, it just sits there silently on an address I wasn't even routing.

What found it: the switch fabric's MAC table. Layer 2 visibility works regardless of what IP a device does or doesn't hold. Once I saw the APC's MAC OUI on a port, I knew the card was alive; a packet capture then showed it occasionally talking to its old static address, which told me exactly which subnet it thought it lived on. I put a secondary IP on a Linux box on that subnet, pinged it, and there it was: a fully awake card with 2015 firmware (AOS 6.4.0, application module 6.4.0), SNMP v1 wide open, web UI on plain HTTP, telnet open on :23. Nine years of firmware evolution behind. From 2015. When this card was made, telnet-on-a-network-appliance was already embarrassing.

I wanted that firmware current before this UPS goes to work at a customer site. Which is where the app comes in.

The updater, the serial cable, and the wrong turn

I went to the vendor's site, found the firmware download for this card family, and grabbed the update utility. Ran it. It looked at my setup and announced it wanted a serial or USB connection to the card.

Here's the thing. The NMC2 has no USB port. And the serial console is an odd RJ45 port on the card that needs a special APC cable (the 940-1524C-type, RJ45 to DB9), which I did not own. So I did what any sensible person does: ordered the cable off eBay, from China, two weeks out, and set the project down.

Then, while the cable was in shipping limbo, I read the actual documentation instead of the utility's first screen. And that's when the whole premise fell apart.

The serial cable is for unbricking, not updating. A healthy NMC2 flashes over the network while it sits in the UPS.

The utility I had grabbed is part of the wrong tool family, the one that talks to the UPS mainboard. The network card has four documented ways to take firmware over the network: FTP, SCP (on 7.x), the web UI, and a Windows wizard. The card gets its power and network from the UPS's SmartSlot, so it has to be seated in the UPS to flash at all, but a flash only reboots the card. The UPS output never blinks. The cable I was waiting two weeks for? It's the XMODEM recovery path for a card too sick to boot normally. Insurance, not a requirement. It's still on order, and it has been promoted to brick-recovery insurance, which is honestly not a bad thing to own.

The upgrade path, done properly

This is where the PDF earns its keep. Schneider Electric publishes "Network Management Card 2 Firmware v7.0.4 for Smart-UPS and Single-Phase Symmetra Release Notes" as a PDF; it's family-wide documentation for the AP9630/31/35 line, and I read it in a copy hosted at criticalpowersupplies.co.uk: https://www.criticalpowersupplies.co.uk/downloads/apc/1636407005-9171-download4.pdf. It documents the order of operations and the landmines, and I'll spare you my old habit of skipping release notes. Three modules ship in one package, and the order is not optional:

1. bootmon (boot monitor, mine wanted 1.0.9), then
2. AOS (the operating system module), then
3. sumx (the application module for Smart-UPS).

Each module upload ends with the card rebooting itself. You wait for it to come back, verify it's answering, then send the next one. Skip the order and you can end up with an application module your OS can't load.

The landmines from the release notes that actually applied:

• The web-UI upload is broken in MS Edge (use Chrome or Firefox if you go that route).
• WinSCP's SCP mode is unreliable against these cards; FTP is the reliable path.
• Some old versions reset your email settings during upgrade. I was far enough back (6.4.0) that this one didn't apply, but it's exactly the kind of thing you want to know before the flash, not after.

Mechanically: the firmware package I downloaded from Schneider Electric's site was apc_hw05_aos722_sumx722_bootmon109.exe, a Windows .exe that is really a self-extracting archive. 7-zip opens it, and inside are the three firmware files I actually uploaded plus the official Windows wizard (NMCFirmwareUpdateUtility.exe) for the one-click route:

• apc_hw05_bootmon_109.bin (boot monitor)
• apc_hw05_aos_722.bin (operating system)
• apc_hw05_sumx_722.bin (application module)

I used plain command-line FTP, not the wizard. FTP in (binary mode, this matters), upload bootmon, close the connection, wait out the reboot, and repeat for AOS, then sumx. The card reboots in roughly a minute. The whole stack, three modules, is about seven minutes of work.

Attempt one: aborted, and the card lived

I want to be honest about attempt one, because it's the part a clean narrative would leave out and it's the part that matters.

My first script run pushed bootmon and got back a "530 Access denied." Login rejected. The card never took the file, never rebooted, never flinched. I verified it immediately: still answering ping, still reporting the old 6.4.0 strings over SNMP, output still online. Unharmed. Aborted clean.

Worth knowing: these cards have a failed-login lockout, so this is not a situation where you get to throw passwords at the wall. The factory-default credentials everyone quotes on the internet were not valid here, because the previous owner had changed them, which is the correct behavior for a card that once guarded a business's power. I had a working login from getting into the web UI earlier in the week, and that profile is what FTP wanted. Attempt two, with the real credentials, went off without a drama.

13:41:51, bootmon uploaded. 13:42:08, card drops. 13:42:34, card back, 36 seconds. Then the settle check, 13:44:35 AOS uploaded, back at 13:46:00 after 72 seconds. Then 13:47:42 sumx uploaded, back at 13:48:25. At 13:49:32 the card reported, over SNMP, the string I wanted: AOS 7.2.2, application module 7.2.2. 2015 to 2025-era firmware in seven minutes, and at no point in any of those reboots did the UPS stop passing power. That was the whole constraint: card-only operations, output never interrupted.

The battery data survived the upgrade too: replace date 10/05/2026 held, and the card recomputed its next-replacement estimate to 04/04/2031, which matches the three-to-five-year horizon a fresh battery earns. Capacity 100%, internal temp 28 C, load 22%. Inheritance complete: a dead company's UPS is now current and mine.

Hardening: closing everything I found open

A 2015 card with default SNMP and telnet open is not a "later" problem once it's on a LAN you care about. With 7.x on board, the fixes that weren't available before became a checklist:

The SNMP piece deserves its own sentence, because it's the one that could have bitten. SNMP write access on these cards can control the UPS, and mine had been sitting there on the factory-default write community, which means anyone on the same network could have told my UPS to do things. And I knew this, because I had used that default myself, two days earlier, to write the battery date. The tool that fixed my problem was also the standing risk. Both communities are now random strings that live in a credentials file with 0600 permissions on a Linux box, and nothing about them is printed anywhere else, including this post.

Also cleaned up: the previous owner's stale TCP/IP fallback settings, and their email receiver entry, disabled. Port scan after: :23 closed, :22 and :443 open, SNMP answering only with the new communities. Factory defaults rejected. One honest gap: the new write community has not been positively exercised with an actual write yet (my test SET bounced off a read-only OID), so it's documented as "verify before depending on it" rather than claiming victory.

HTTP stays open one more session: disabling it is a five-character config change, but I want the HTTPS-only state verified while I can still see both, not as a side effect. That's pass two, it's queued.

The email problem, or: a card that can't do modern TLS

With alerting now real instead of theater, the mail config needed to actually work. The previous owner's settings pointed at a public mail provider with implicit TLS on :465, and here I found the card's real limitation. Its firmware era predates modern cipher negotiations: when I probed the handshake, the card offers legacy CBC suites, and modern mail servers, quite reasonably, refuse them. The server and credentials were fine (I proved that from a Linux box with the same legacy suites and got the same dead handshake; with a modern suite, the same credentials authenticated successfully). The card's TLS stack is just too old to speak to a modern submission endpoint directly.

So the mail path is a hop: card to a small Linux box on the same LAN over plain SMTP (no auth, internal only), and that box relays outward through an already-hardened path. The card gets a config it can actually execute, and nothing legacy touches the internet. Proof it works, in order:

1. Told the card to email itself a 57 KB debug log archive. Watched it clear the local relay, the off-site relay, and get accepted by the mail provider.
2. Fired a real UPS self-test. The card generated the self-test event and its clearing event, and both arrived by email within seconds. Five test messages total landed in the inbox, zero in junk.

Two quirks discovered, both worth knowing before you rely on this card's email:

• The config import/export never includes email passwords. They're write-only, set through the command line over SSH. Good security design, mildly confusing the first time your exported config round-trips without them.
• Default policy on current firmware is to email every event, repeating every 2 minutes until cleared. Aggressive is one word for it. It's also exactly what you want for a power device: I will tune the noise later, deliberately, rather than start from silent and find a gap the hard way.
• Small one: the quick "green mode" self-test does not generate an on-battery event. A real input-power loss does. Know which self-test you're running when you test your alerting.

Also discovered while getting the SSH command line working: a one-shot ssh host command doesn't work against these cards (it routes into an internal file-transfer handler and errors out). You need an interactive PTY session with commands fed in on timing. Documented, used, works.

What I'd tell someone else

• A device missing from DHCP and ARP isn't missing. Read the switch's MAC table. Layer 2 sees everything that plugs in, regardless of what IP it thinks it has.
• If the firmware updater says it wants serial or USB, check whether there's a network path before you buy the cable. On the NMC2 family: FTP, SCP, web UI, or the Windows wizard, and the card must be seated in the UPS to do it.
• Flash order is bootmon, then AOS, then sumx. Wait for the self-reboot between each. Read the release notes PDF first; it will save you from Edge and WinSCP.
• The factory SNMP communities on a salvaged card are the previous owner's problem and your problem the moment it touches your LAN. Rotate them first, not last.
• Don't brute-force the login. The card locks out. Get the one working credential you need.
• Test email with a real event, not a config screen. And check the junk folder, because the card will not tell you where its mail went.

Still on the bench

The eBay serial cable lands in a couple of weeks and goes in a drawer as unbrick insurance. Pass two (HTTP off, HTTPS only) is queued and verified-safe to run. The SNMP write community gets a positive write test before anything depends on it. And when this rack moves to its permanent site at the customer, the IPs all change, so the documentation gets a re-IP pass. The firmware, the security posture, and the alerting are done.

Test environment: APC Smart-UPS SMT1000RM2UC (built 04/21/2018) with AP9630 NMC2 card (HW rev 5, built 02/02/2015); firmware AOS 6.4.0/sumx 6.4.0 upgraded to AOS 7.2.2/sumx 7.2.2 with bootmon 1.0.9 via package apc_hw05_aos722_sumx722_bootmon109.exe, flashed over FTP 2026-10-11, 13:41 to 13:49 MST; battery APCRBC132 installed 10/05/2026. UPS output was never interrupted during any step; all reboots were card-only. Part numbers are as-printed; serial numbers, network names, addresses, and credentials are deliberately omitted from this write-up.