Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
- Cisco Community
- Technology and Support
- Small Business Support Community
- Small Business Support Knowledge Base
- S.O.S Firmware Recovery Protocol Specification
Options
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
8032
Views
0
Helpful
1
Comments
Options
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
on 09-15-2013 05:03 AM
Firmware may be lost in device for number of reasons. There is special vendor's application that can resolve such condition. Unfortunately, such application is available for Windows only. It's not so optimal for maintenance of remote network which is separated from standard office's network for the security purpose.
You either add Windows computer with remote access to voice network just because you may need it sometime, or physical presence on site is required to solve the problem.
First approach increase total cost of ownership and may be considered security issue. The second one will increase downtime.
As the recovery protocol is simple, someone may want to implement recovery application for an other system already used in it's voice network. Following specification may help with it.
========================================================================= Reference Manual of S.O.S. Firmware Recovery Protocol of SPA IP Phones ------------------------------------------------------------------------- * INFORMATIONS ARE PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED * WARRANTIES ARE DISCLAIMED. IN NO EVENT NO ONE THAN YOU WILL BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, LOSS OF DATA) * ARISING IN ANY WAY OUT OF THE USE OF INFORMATIONS IN THIS DOCUMENT ------------------------------------------------------------------------- Informations provided herein are compiled from various information source and/or based on observation. They are not derived from an official vendor documentation nor they has been verified by vendor. They has been tested on limited test of devices.
Note that English is not author's native language. ========================================================================= 1. Introduction S.O.S. Firmware Recovery Protocol is simple multicast based UDP protocol dedicated to communication with devices that lost their main firmware. Protocol is built on a client-server model. Throughout the remainder of this document, the term client refers to computer and/or process used by administrator during process of recovery, the term server refers to damaged device. Devices with working standard firmware (e.g. devices not in S.O.S. mode) doesn't speak this protocol and ignore it's packets silently. 2. Packet Format All numbers shown are decimal, unless indicated otherwise. Multibyte values are stored in network order. Strings are C-style strings. The protocol packets (both requests and responses) are enclosed in a multicast IP UDP datagram. In the IP and UDP header of a request, the client fills in its own IP address and port 4811 as source and multicast IP 234.4.8.10 and port 4810 as destination. Server will respond to multicast IP 234.4.8.10 and port 4811. The size of data portion of UDP request is 160B. Requests of other size should be silently ignored by server. Server's responses have size 100B. 3. Identify device Identify request is used to fetch various parameters of device in S.O.S mode. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 00 | cmd (1) | unknown (3) | +---------------+-----------------------------------------------+ 04 | tag (4) | +---------------------------------------------------------------+ 08 | | ~ serial (20) ~ ~ ~ 24 | | +---------------------------------------------------------------+ 28 | | ~ unknown (132) ~ ~ ~ 156| | +---------------------------------------------------------------+ Figure 1: Format of a Identify request message FIELD OCTETS DESCRIPTION ----- ------ ----------- cmd 1 Message op code. Always 0 for Identify request tag 4 Message signature. Always string 'RECM' serial 20 (string) serial number of queried server or string 'FFFFFFFFFFFF' unknown -- fill them by zero Servers specified by request's serial number or all servers if wildcard serial 'FFFFFFFFFFFF' filled should respond with Identify response message. Servers not selected by serial number should discard request silently. Client should wait 2.5s for responses. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 00 | cmd (1) | unknown (3) | +---------------+-----------------------------------------------+ 04 | tag (4) | +---------------------------------------------------------------+ 08 | | ~ serial (20) ~ ~ ~ 22 | | +---------------------------------------------------------------+ 28 | | ~ type (20) ~ ~ ~ 44 | | +---------------------------------------------------------------+ 48 | | +-- mac (6) --+-------------------------------+ 52 | | | +-------------------------------+-- --+ 56 | | ~ fwver (20) ~ ~ ~ 68 | | +-- --+-------------------------------+ 72 | | | +-------------------------------+-- --+ 76 | | ~ hwver (20) ~ ~ ~ 88 | | +-- --+-------------------------------+ 92 | / ip (4) | +------------------------------- ------------------------------+ 96 | / port (2) | +---------------------------------------------------------------+ Figure 2: Format of a Identify response message FIELD OCTETS DESCRIPTION ----- ------ ----------- cmd 1 Message op code. Always 1 for Identify response tag 4 Message signature. Always string 'RECM' serial 20 (string) serial number of server type 20 (string) device model mac 6 (binary) MAC address of device fwver 20 (string) recovery firmware version hwver 20 (string) hardware version of device ip 4 (binary) IPv4 address of device port 2 (binary) meaning not known 4. Load Firmware "Load Firmware" order the server to load the firmware using TFTP protocol. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 00 | cmd (1) | unknown (3) | +---------------+-----------------------------------------------+ 04 | tag (4) | +---------------------------------------------------------------+ 08 | | ~ serial (20) ~ ~ ~ 22 | | +-------------------------------+-------------------------------+ 28 | port (2) | unknown (2) | +-------------------------------+-------------------------------+ 32 | | ~ path (128) ~ ~ ~ 156| | +---------------------------------------------------------------+ Figure 3: Format of a Load Firmware request message FIELD OCTETS DESCRIPTION ----- ------ ----------- cmd 1 Message op code. Always 2 for Load Firmware tag 4 Message signature. Always string 'RECM' serial 20 (string) serial number of queried server port 2 (binary) port of TFTP server path 128 (string) name of firmware's file Servers specified by request's serial should reply with Load Confirm message and fetch firmware from TFTP server. Servers not selected by serial number should discard request silently. Client should wait 2.5s for responses. The Load Confirm response content is exact copy of Load Firmware request (including cmd byte) with exception that size of path option is reduced to 68 (not to excess of 100B of total size of response message). Despite there is 128B reserved for file name in request, it seems that first 67B is accepted by server only. 5. TFTP session Based on Load Firmware order, the device will start standard TFTP session. The destination address of TFTP request will be set to IP 234.4.8.10 and port as specified within "Load Confirm" message. File to load should be standard binary firmware file published by device vendor. Note that there may be some restrictions. For example, on SPA5xx is not possible to upgrade pre-7.5.2b firmware to a post-7.5.2b firmware. Those restrictions apply to recovery firmware loading as well. 6. Compatibility Implementation of the protocol has been tested on SPA504G only but should work on all SPA* IP Phones and ATA class devices (including former Linksys products). =========================================================================
Labels:
Comments
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
01-08-2019
10:55 PM
Special application provider where you can download it?
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:
Customers Also Viewed These Support Documents