We're currently running UC v18.104.22.16826 on our Metaswitch deployment, and are attempting to upgrade our VVXs to 22.214.171.12471 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 126.96.36.19947, without issue but when attempting to download the firmware, 188.8.131.5271, 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 184.108.40.20671 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*/220.127.116.1171/3111-46162-001.sip.ld' from 'REMOVED_FOR_PRIVACY' 000028.321|copy |3|00|cfgProvSrvTypeGet() 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*/18.104.22.16871/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/22.214.171.12471/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*/126.96.36.19971/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*/188.8.131.5271/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?
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.
Polycom Global Services