cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
43597
Views
10
Helpful
39
Comments
Patrick Born
Cisco Employee
Cisco Employee

In the event that a SPA50xG IP phone experiences an interruption of power during a firmware upgrade, the phone's firmware images could be rendered unusable. If this occurs, the phone will display a message "SOS phone in recovery mode".

The phone will automatically attempt to acquire a valid image from the "last upgrade URL" that it knows about.

You can manually recover a SPA50xG phone from this state using the attached recovery utility. You can use the utility regardless of the firmware version of the phone.

Using the recovery utility

When the phone is trying to access the “last upgrade URL”, it will not be able to handle a recovery request from the PC. Once the phone gives up, you will be able to successfully use the recovery utility:

  1. Make sure the default TFTP port (69) is not occupied on the computer. For example if you have a TFTP server such as Pumpkin or SolarWinds running, shut the TFTP service down.
  2. You might have to disable the firewall or other security measures on the PC to allow TFTP to function properly.
  3. Run the recovery utility and enter the phone’s SN when prompted. You can use “FFFFFFFFFFFF” (12 ‘F’s) instead of the phone's serial number.
  4. The recovery utility should find the phone in recovery mode.
  5. Follow the instructions on screen to start the recovery process.
  6. Once the phone has recovered and rebooted, you can upgrade to the desired version of firmware.

<end>

Comments
Roman Iskhakov
Level 1
Level 1

Hello, Did you resolved your question?

Roman Iskhakov
Level 1
Level 1

Yes phone showing "SOS PhoneInRecoveryMode"

i tried many ways, connected to PC, throught switch, no luck

i recieved new 20 phones, two of them SOS problem, may be it is not only soft

can i send you packet trace file, may be you will notice somthing?

Dan Lukes
VIP Alumni
VIP Alumni

You can, of course. But if there is no packet received from phone, there is nothing to analyze.

If I understood correctly, the phones are new - so you may consider return them to seller.

 

Dan Lukes
VIP Alumni
VIP Alumni

Because of new CSC limit I need respond to self, not to you ...

If your trace contain no packet sent by phone (e.g. phone is silent) then there is nothing to analyze. As you claimed your devices are new, return broken phones to seller for replacement.

Roman Iskhakov
Level 1
Level 1

S.O.S Firmware Recovery Protocol Specification - useful info

yes i only see packets from my PC to 234.4.8.0 no answer from phone

Thank you for your help and time!

Dan Lukes
VIP Alumni
VIP Alumni

Then rate it ;-)

If you see no packet from phone, although it declare it is in SOS mode, then there is not so much you can do beyond return to seller.

By the way - it seems that phone in SOS mode seems not to wait for recovery handshaking forever. Few minutes past power on seems not to be problem, but if you will wait so long, the phone may not respond.

jonasd1986
Community Member

I have thow phones with "S.O.S Phone In Recovery Mode". One successfully went through recovery procedure, but anohter one requests file like spa4f6e.bin or spa5bcd or something like that (each time after reboot it requests another file). Do you have any suggestion? Thank you

Dan Lukes
VIP Alumni
VIP Alumni

Very unclear description of the issue.

So, you started recovery utility, it did it's work, the phone rebotted, then asked for a file ? Or not ?

Can you exactly describe the steps you did and the phones behavior ? Of course, don't forged to mention phone's recovery firmware version as well as version of recovery utility you are using.

Also, this is discussion about the document. You should start new discussion related to your issue.

 

jonasd1986
Community Member

It went successfully with 7.5.3 phone's recovery firmware version

ccedward030
Community Member

Thank you for the guide, it started me on the right track. My SPA514g was in SOS recovery mode but with no blinking lights. Following the above steps didn't work, the initial UDP identify request was being sent by the server, then the UDP id response was replied by the phone but nothing happened after that. The recovery utility would then fail saying it couldn't find any phones. Very strange since wireshark showed the phone responding.

I created my own firmware update request packet manually and found that the phone was trying to then id 10.10.10.1 before sending the TFTP request. Changing my IP to 10.10.10.1 got it past this and I started seeing a TFTP file request as the spec calls for, but I do not have a TFTP server that would respond on the multicast address. So... I reverted back to using the recovery utility with the new IP 10.10.10.1 and, it worked.

It appears Cisco uses 10.10.10.1 elsewhere as a default IP, so this isn't too surprising. I don't use that IP anywhere on my network and it wasn't in the config anywhere before my flash was initially interrupted which caused this issue.

So here's how I got it working:

1. Connect phone directly to windows computer via ethernet

2. Manually set IP of the ethernet interface to 10.10.10.1.

3. Run recovery utility (FFFFFFFFFFFF as address).

4. Watch it *finally* find the device, connect, and allow me to update the firmware.

 

Also note, I've seen some reports in the forums that the S/N should actually be the MAC. This is wrong, at least the phone responds with it's actual S/N according to the packet spec, not the MAC. Not a big deal since I'm using the catch-all FFF's above.

I also don't see why you'd need a cross-over cable.

Dan Lukes
VIP Alumni
VIP Alumni

found that the phone was trying to then id 10.10.10.1 before sending the TFTP request.

It seems there's word missing in the sentence. What the phone is trying to do to 10.10.10.1 ?

It appears Cisco uses 10.10.10.1 elsewhere as a default IP,

I can deny it for SPA50x, SPA9xx, SPA1x2, SPA232D product line. It may be true for SPA514G (I can't verify as I have no such device), but it sounds suspicious because of shared code base with SPA[35]0x. Or it may be matter of recovery firmware version. All SPA50x I tried have either 7.4.4rec or 7.5.2rec recovery firmware version. Please disclose the recovery firmware version of your's SPA514G

I also don't see why you'd need a cross-over cable.

Because of Ethernet's nature. TX pair of one end must be connected to RX pins on other end and vice versa. Unless either end is MDI-X capable (e.g. can cross pairs by self) you need to cross them using cross-over cable. It seems your computer have Ethernet card with MDI-X feature thus you need no such cable.

ccedward030
Community Member

It seems there's word missing in the sentence. What the phone is trying to do to 10.10.10.1 ?

The phone was asking "Who has 10.10.10.1" to discover the MAC address. It was trying to ID 10.10.10.1.

Please disclose the recovery firmware version of your's SPA514G

7.5.1rec

It seems your computer have Ethernet card with MDI-X feature

You're right, a cross-over cable could be needed if the network card doesn't support Auto MDI-X. Auto MDI-X has been around since the early 2000's so I imagine it's hard to find a network card these days that doesn't support this? I could be wrong... I haven't had to use one since somewhere around the year 2000, but that's just my experience.

General comments...

I've seen here that the phone should be blinking red when it's in recovery mode. Mine was not, maybe there's a different stage of recovery mode that caused this behaviour?

I saw the phone calling back to the last known provisioning server, which is still active and uses http, but it wasn't able to successfully flash over http. I saw that GET on the provisioning server, but in wireshark I didn't see the full update bin file being transferred correctly. Lots of window errors that aren't there when updating from a working phone. Maybe the recovery software only supports tftp/udp?

This is all just speculation based on what worked/didn't in case it might help someone else down the road. I can definitively say that the only way the recovery utility saw my phone was when I set my local fixed IP to 10.10.10.1. No other network changes were made. Firewall was disable. I had tried 192.168.5.5 in an isolated setting (which was the old provisioning server), I'd also tried 192.168.5.6, and also the auto-assigned windows IP 169.x.x.whatever-it-is.

Phone was getting IP 192.168.5.200 from my local DHCP, confirmed with wireshark and DHCP logs.

Dan Lukes
VIP Alumni
VIP Alumni

As far as I know the MIC led blinking red mean there's no link on Ethernet port.

The recovery support TFTP only (see also S.O.S Firmware Recovery Protocol Specification). But if the phone's calling back to the last known provisioning server then it's not in recovery mode as far as I know. Also, phone in recovery mode doesn't speak DHCP.

ccedward030
Community Member

Dan, I did read that spec, which is how I was able to create a packet to instruct the phone to ask for a firmware update.

The phone was displaying "S.O.S phone in recovery mode" so I would be surprised if it wasn't, especially since it was responding to the recovery mode formed packets I was sending it.

I'm posting my experience here, hoping it will help someone else.

The first post in this spec says that the phone will try to contact last known upgrade URL, so it sounds like that is a normal feature of the recovery firmware. Perhaps it just doesn't know how to handle HTTP firmware upgrade? It did do an HTTP GET but wasn't able to handle the response. Maybe if my provisioning server was TFTP it would have succeeded.

My experience was that the phone *did* support DHCP in recovery mode.

Dan Lukes
VIP Alumni
VIP Alumni

OK. I have no SPA51xG phone here, but SPA50x. It have common code base, so I assumed same behavior, but such assumption may be wrong.

 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: