VVX 400/410 firmware upgrade issues

[Anonymous]

We're currently running UC v5.5.1.11526 on our Metaswitch deployment, and are attempting to upgrade our VVXs to 5.5.2.8571 to take advantage of some new features.

The issue we're running into, and it seems to ONLY be affecting the VVX 400 and 410, is that the phone downloads and applies the new updater 5.7.2.21547, without issue but when attempting to download the firmware, 5.5.2.8571, it fails. Reviewing the logs from the phone, the upgrade fails because it reports a bda checksum, yet, eventually, the same phone, using the same provisioning server, will upgrade to 5.5.2.8571 as expected.

Here are (2) log entries, from the same phone; on the first log entry, the upgrade fails, on the second, the upgrade succeeds:

This is from the “failed” upgrade:

000028.261|copy |3|00|Download of 'sip-ps/0004f26b6b99.cfg' succeeded on attempt 1 (addr 1 of 1)
000028.262|cfg  |3|00|Prov|Updated file 0004f26b6b99.cfg
000028.295|cfg  |*|00|Prov|Starting to update
000028.321|copy |3|00|'http://PlcmSpIp:****@REMOVED_FOR_PRIVACY*/5.5.2.8571/3111-46162-001.sip.ld' from 'REMOVED_FOR_PRIVACY'
000028.321|copy |3|00|cfgProvSrvTypeGet()[4]
000028.594|cfg  |3|00|New load header information:
000028.594|cfg  |3|00|Code length:         0x02934B9C
000028.594|cfg  |3|00|Code Checksum:       0x0F584668
000028.594|cfg  |3|00|Options:             0x00000080
000028.595|cfg  |3|00|Recognized container image
000028.595|cfg  |3|00|New load header information:
000028.595|cfg  |3|00|Code length:         0x00728938
000028.595|cfg  |3|00|Code Checksum:       0x3B05051E
000028.595|cfg  |3|00|Options:             0x00000010
000028.600|cfg  |3|00|Updater is already present
000028.600|cfg  |3|00|Updater in container image 1 is not different
000028.601|cfg  |3|00|New load header information:
000028.601|cfg  |3|00|Code length:         0x0220B95C
000028.601|cfg  |3|00|Code Checksum:       0x0F57A585
000028.601|cfg  |3|00|Options:             0x00000002
000028.601|cfg  |3|00|Could not open application file for checking
000028.601|cfg  |3|00|Application in container image 2 is different
000028.601|cfg  |3|00|Using application
000030.602|cfg  |*|00|Prov|Updating the Application
000030.602|cfg  |3|00|Using compatible image 0
000036.603|copy |3|00|Download of 'sip-ps/vsetTrialUsers*/5.5.2.8571/3111-46162-001.sip.ld' succeeded on attempt 1 (addr 1 of 1)
000037.406|cfg  |4|00|Bad image checksum, expected=0x0F57794D  got=0x0F57A585
000038.086|cfg  |4|00|Prov|File REMOVED_FOR_PRIVACY/5.5.2.8571/3111-46162-001.sip.ld was not valid
000038.106|cfg  |3|00|Prov|Image has not changed
000038.107|cfg  |4|00|Prov|Provisioning failed
000038.131|cfg  |*|00|Prov|Finished updating configuration

This is from the “successful” upgrade:

000037.229|copy |3|00|Download of 'sip-ps/vsetTrialUsers*/5.5.2.8571/3111-46162-001.sip.ld' succeeded on attempt 1 (addr 1 of 1)
000041.118|cfg  |3|00|Good image signature
000041.886|cfg  |3|00|Stat results are: download 35699608, phone 0, fs free 168546304
000041.914|cfg  |3|00|Programming 35699608 bytes into tffs in 4K blocks
000045.052|cfg  |3|00|Extracting application files
000045.052|cfg  |3|00|New load header information:
000045.052|cfg  |3|00|Code length:         0x0220B95C
000045.053|cfg  |3|00|Code Checksum:       0x0F57A585
000045.053|cfg  |3|00|Options:             0x00000002
000310.365|cfg  |3|00|Finished extracting application files (OK)
000326.931|cfg  |3|00|File system is synchronized
000327.146|cfg  |*|00|Finished software update
000327.146|cfg  |*|00|Prov|Succeeded updating file 'http://PlcmSpIp:****@REMOVED_FOR_PRIVACY*/5.5.2.8571/3111-46162-001.sip.ld' from 'REMOVED_FOR_PRIVACY'
000327.150|cfg  |*|00|Prov|Image has been changed
000327.173|cfg  |3|00|Prov|Provisioning succeeded
000327.190|cfg  |*|00|Prov|Finished updating configuration
000327.193|boot |*|00|Using TFFS for flash load
000327.193|boot |*|00|Code length:         0x0220B95C
000327.193|boot |*|00|Code checksum:       0x0F57A585

Why did it fail on checksum 0x0F57A585 then eventually it says, “checksum 0x0F57A585 is ok”?  Why is it expecting a different checksum than what it is getting?  Why is the checksum issue only seem to be occurring on the 400 and 410?

Has anyone else run into this issue?

[SteffenBaierUK]

Hello rpenrod,

welcome to the Polycom Community.

We would need to see some of your configuration to check if this is valid but as already explained by our online team in ticket 1-6616116821 you need to work with SCANSOURCE COMMUNICATIONS to get a ticket opened for you as they can work with Polycom support.

Please ensure to provide some feedback if this reply has helped you so other users can profit from your experience.

Best Regards

Steffen Baier

Polycom Global Services