Firmware Upgrade Failure: SPA303 & SPA504G

Aaron Mount · ‎06-26-2018

Hello — I'm running ragged trying to figure this out and would appreciate some help from the community.

I'm having some unusual issues when trying to upgrade the firmware of a SPA303 (running 7.6.2b) and a SPA504G (running 7.6.0).

First — I must be able to upgrade via provisioning alone. An upgrade from the local network, or triggered via the http://<ipaddress>/upgrade?<url> method is not a viable solution.

If I start with a working phone, change the upgrade rule on the provisioning server, and force a resync, the device will fail to upgrade even though the new upgrade rule is reflected in the device's config. For example, on my SPA303:

Old upgrade rule: '($SWVER lt 7.5.2b) ? https://<domain>/firmware/spa50x-30x-7-5-2b.bin | ($SWVER lt 7.6.2b) ? https://<domain>/firmware/spa50x-30x-7-6-2b.bin'

New upgrade rule: '($SWVER lt 7.5.2b) ? http://<domain>/firmware/spa300/spa50x-30x-7-5-2b.bin |($SWVER lt 7.6.2d) ? https://<domain>/firmware/spa300/spa50x-30x-7-6-2d.bin'
Although the server's apache access log displays a GET entry for the config file, the access log never sees the GET of the firmware binary.

If I start with a working phone and use the http://<ipaddress>/upgrade?<url> method, the firmware upgrades as expected.

If I start with a factory default phone, and have it configured with the above "new upgrade rule" from the beginning, it will get configured and upgrade correctly.

I don't understand why the upgrade process would fail depending on the method or state of the phone.

My situation seems similar to "cisco spa 51x and 50x Failed - Not Reachable for firmware 7.6.2b , 7.6.2c , 7.6.2d only." After trying to troubleshoot SSL issues, I instead decided to eliminate the issue by using HTTP to download the binaries. No improvement.

I also decided to eliminate the second $SWVER condition, to simplify it further. Still no luck but slightly different behavior. For example, the upgrade rule on my SPA504 is now:

'($SWVER lt 7.5.2b) ? http://<domain>/firmware/spa500/spa50x-30x-7-5-2b.bin | http://<domain>/firmware/spa500/spa50x-30x-7-6-2d.bin'

My 504 downloads the binary and gives every indication it's installing it, but when it reboots it's still running 7.6.0.

Syslog/debug messages don't show anything helpful, only that the "upgrade failed."

What is going on?

Dan Lukes · ‎06-26-2018

First — I must be able to upgrade via provisioning alone. An upgrade from the local network, or triggered via the http://<ipaddress>/upgrade?<url> method is not a viable solution.

I'm unsure i understand. There are different methods to tell the phone where to fetch new firmware - provisioned configuration, phone menu, WWW UI, http://<ipaddress>/upgrade?<url> - but all those methods do the same - they tell phone where to fetch the firmware. With no exception, firmware need to be fetched by phone itself from either TFTP, FTP or HTTP server. It's the only method of firmware upgrade supported.

Old upgrade rule: '($SWVER lt 7.5.2b) ? https://<domain>/firmware/spa50x-30x-7-5-2b.bin | ($SWVER lt 7.6.2b) ? https://<domain>/firmware/spa50x-30x-7-6-2b.bin'

Nothing like it is allowed as far as I know. See Cisco Small Business IP Telephony Devices Provisioning Guide:

Comparison can relate one of three types of literals:

Integer values

Software or hardware version numbers

Doubled-quoted strings

Note that version numbers take the form of three non-negative integers separated by periods (major, minor, and build numbers), plus an optional alphanumeric string in parentheses

Neither 7.5.2b nor 7.6.2b follow such format - it may be compared for equality or inequality only (arithmetic comparisons are defined for integers and version numbers only).

While you can try it, use of undocumented constructs needs to be considered unsafe - while it may work with particular firmware build, it may not work with other one.

I don't understand why the upgrade process would fail depending on the method or state of the phone.

Even if 0.0.0x string is recognized as version string, history still needs to be taken into consideration. Once phone has been updated, it does not attempt to upgrade again until either the rule itself is modified or the effective combination of scheme + server + port + filepath is changed, following macro expansion and evaluation of the rule.

I don't know the exact reason why your phone doesn't upgrade. Turn on syslog&debug messages (highest level possible) and catch them - they may reveal more.