How can we help you today?
Start a new topic
Answered

SNOM PA1 firmware update issue > 8.7.5.75

Hello

New SNOM PA1 user here.

Out of the box, my unit shipped with v8.7.3.19.


I used these exact instructions, to successfully update to v8.7.5.35:

http://wiki.snom.com/Firmware/V8/PA1

ie copy the provisioning firmware link into the SNOM PA1 WebUI "Software Update" page. 

It worked without any issue.

This is the first link I found and followed - first Google Search result.


Now it seems like it's STILL actually an old firmware (this is not even hinted at from the wiki page) and has outdated CA certs and outdated SSL/TLS protocols, so I then found THIS:


http://wiki.snom.com/Firmware/V8_7_5_75_MRU_PA1

However, on attempting the same process as above, ie paste the provisioning link into the WebUI "software update" page, when I click the Load button - nothing happens.

I tried several times, with restarting both the PA1 and my PC, I also tried different browsers, including the oldest version of Internet Explorer available to me - same result.

For ref the exact link I am pasting is:

http://downloads.snom.com/fw/snomPA1-8.7.5.75-SIP-f.bin 


I can download the bin file manually - so I know it is a valid URL and the link is not dead.


I then read THIS small-font footnote:

 Important upgrade/downgrade instructions:
 * Any PA1 running an firmware >8.7.5.44 should not be downgraded to a version below 8.7.5.44.
 * This may lead to a deadlock situation where the firmware works, but the device cannot be updated anymore at all!
 * All versions lower than 8.7.5.44 are affected by this update procedure issue.
 * Only option left to get out from such deadlock situation is to use the network recovery procedure as described in our support How-to
 * If the downgrade is mandatory, use the 8.7.5.44 as an intermediate firmware downgrade step, before you finally install the desired/known as affected version!
 * Please note: if you experience the deadlock situation do not open an RMA case, as this is not a hardware/flash issue! 

And became very confused indeed. IF I am interpreting this instruction correctly, it says that that ALL versions lower than 8.7.5.44 are affected by a known update procedure issue. And yet the "official" stable release which the wiki points visitors to is... 8.7.5.35.

So although you CAN update to that - you're then stuck???

This certainly appears to be true in my case.

It ALSO seems to be incredible that there is no method for local browser-based manual firmware updates - y'know, like most every other router manufacturer allows??? (since I already have a copy of the .bin file)


I then started following instructions for the network recovery procedure:

https://helpdesk.snom.com/support/solutions/articles/6000134872-snom-pa1-tftp-recovery-procedure

For the record, my hardware variant = R4A, which I interpret as "newer than R3C".


Gathering together the rest of the bits required, I have now attempted this process around half a dozen times.

The PA1 bootup process NEVER gets past here:

Contacting TFTP-server and fetching the rescue file: red LED - ON green LED – ON

I have tried shorting Pin0 + 1 for well over 2mins.

I have tried shorting Pin0 + 1 for only 10seconds, only 5seconds etc, despite the instructions saying "You can disconnect the short after about 20 seconds after the PA1 boots up."

EACH attempt I have left the PA1 alone - with solidly-lit RED LED and GREEN LED, for at least half an hour.

There is no sign of progress in the SPLiT logs after it has done the TFTP server startup routine.


I have renamed the f/w file > snomPA1.bin as directed.

It is in:

C:\Temp\tftp - yes that is the exact case, (lowercase tftp as directed.)

The SPLiT exe is in C:\Temp (both nice short paths, so no issue with invalid path chars). I am running it as Admin.

I have allowed access through Windows Firewall for the SPLiT server, even though that isn't mentioned in the instructions, the logs show the service is running. I have enabled the debug selection as directed, and I have tried it both with the PC IP address of 192.168.37.38 and with localhost : 127.0.0.1

(yes, my PC IP address is statically set to 192.168.37.38 as directed)


I get the same result for every attempt - the PA1 boots and stays with solidly-lit red & green LEDs.


I have verified that my PC is definitely running 192.168.37.38, BUT I am unable to get a ping reply from 192.168.37.105, which according to the instructions SHOULD be the IP of the PA1 after boot with Pin0+1 shorted?

So it seems from everything I can tell that the BOOTUP process is NOT correctly going into recovery phase.


Here are the SPLiT logs showing that I have tried on both the recommended IP and localhost:


2019-10-24 10:24:54,875 DEBUG TFTP Server: Starting thread

2019-10-24 10:24:54,875 DEBUG TFTP Server port: 69

2019-10-24 10:24:54,875 INFO NOTICE: TFTP server starting on 192.168.37.38:69

2019-10-24 10:24:54,875 DEBUG Server IP: 192.168.37.38

2019-10-24 10:24:54,875 DEBUG Server Port: 69

2019-10-24 10:24:54,875 DEBUG Network Boot Directory: tftp

2019-10-24 10:24:54,875 INFO TFTP service running

2019-10-24 11:37:55,230 DEBUG TFTP: Stopping thread

2019-10-24 11:37:55,230 DEBUG TFTP: Stopped thread

2019-10-24 11:37:55,230 ERROR Error during select()

2019-10-24 11:38:23,648 DEBUG TFTP Server: Starting thread

2019-10-24 11:38:23,648 DEBUG TFTP Server port: 69

2019-10-24 11:38:23,648 INFO NOTICE: TFTP server starting on 127.0.0.1:69

2019-10-24 11:38:23,648 DEBUG Server IP: 127.0.0.1

2019-10-24 11:38:23,648 DEBUG Server Port: 69

2019-10-24 11:38:23,648 DEBUG Network Boot Directory: tftp

2019-10-24 11:38:23,648 INFO TFTP service running


The "Error during select()" message is written when I press the "Stop TFTP Server" button in the SPLiT gui. No idea what it means.

This is frustrating. Can anyone please offer advice on what else I can try next?

TIA.


Best Answer

Hi Sean

Thanks for your reply.

I have never attempted to perform any downgrade.


I upgraded from 8.7.3.19 > 8.7.5.35 (according to the first set of instructions I found, here http://wiki.snom.com/Firmware/V8/PA1) - and now I can't upgrade any further.

I have been unsuccessful via all methods, as I wrote extensively it does NOT appear to be dropping into the recovery boot mode at all when shorting PIN 0 + 1.


That was nearly a month ago, so I am afraid I have put this device into production use running 8.7.5.35, and can no longer do any testing with it.

For ref I bought a second unit, which shipped also with 8.7.3.19.

I ignored the instructions at the first link in my long initial post, and instead went directly to 8.7.5.75 MRU1 (using these instructions: http://wiki.snom.com/Firmware/V8_7_5_75_MRU_PA1

That upgrade worked fine.


Please amend the instructions at THIS link:

http://wiki.snom.com/Firmware/V8/PA1

So that they instead ref the latest version 8.7.5.75, and do not cause any OTHER customers to have a unit stuck at 8.7.5.35 for reasons unknown like mine.


I think it would also be an advantage if these units could use a local bin file uploaded into the WebUI instead of only allowing via your provisioning servers (since if format/standards/refs on your provisioning server change then the upgrade process my break)

Yes I realise this is likely a deliberate restriction to reduce the attack surface & possibilities, but surely input sanitisation is a simple method these days...

Cheers,

Bryan


Bryan,


The firmware downgrade/upgrade issue occurs if you were to upgrade from 8.7.3.19 to 8.7.5.75 for example and then download to 8.7.5.35 or lower. Upgrading from 8.7.3.19 and then 8.7.5.35 would not prevent an upgrade to a higher version.


Were you able to resolve this with a TFTP or HTTP upgrade?


Regards,



Snom Support

Answer

Hi Sean

Thanks for your reply.

I have never attempted to perform any downgrade.


I upgraded from 8.7.3.19 > 8.7.5.35 (according to the first set of instructions I found, here http://wiki.snom.com/Firmware/V8/PA1) - and now I can't upgrade any further.

I have been unsuccessful via all methods, as I wrote extensively it does NOT appear to be dropping into the recovery boot mode at all when shorting PIN 0 + 1.


That was nearly a month ago, so I am afraid I have put this device into production use running 8.7.5.35, and can no longer do any testing with it.

For ref I bought a second unit, which shipped also with 8.7.3.19.

I ignored the instructions at the first link in my long initial post, and instead went directly to 8.7.5.75 MRU1 (using these instructions: http://wiki.snom.com/Firmware/V8_7_5_75_MRU_PA1

That upgrade worked fine.


Please amend the instructions at THIS link:

http://wiki.snom.com/Firmware/V8/PA1

So that they instead ref the latest version 8.7.5.75, and do not cause any OTHER customers to have a unit stuck at 8.7.5.35 for reasons unknown like mine.


I think it would also be an advantage if these units could use a local bin file uploaded into the WebUI instead of only allowing via your provisioning servers (since if format/standards/refs on your provisioning server change then the upgrade process my break)

Yes I realise this is likely a deliberate restriction to reduce the attack surface & possibilities, but surely input sanitisation is a simple method these days...

Cheers,

Bryan

Bryan,


Thank you for the update on your issue and the additional information.



Regards,


Snom Support

Login or Signup to post a comment