Reference:Update Server

Configuration of the Update-Server

It is possible to update the firmware and configuration of a large number of innovaphone devices in a distributed environment by automated means.

This is done by storing the configuration and firmware information on a standard Web server, which in turn is called up the individual devices.

There are two modules in the device which work in tandem. The first is known as "UP0" and acutally executes the upload and download of configuration information as well as the download of updated firmware. UP0 is controlled by commands as detailed below. The second module is known as "UP1". It serves to poll a given website for changed configuration information. If certain conditions are met, UP1 will issue commands to UP1 to perform the requested updates.

System requirements

• One or more Web server(s) accessible by the devices.
• The Web servers tested were MS IIS and the Apache server. It should, however, also work with all other common Web servers.
• For best results, the Web server should be able to manage a large number of simultaneous HTTP sessions. MS Personal Web Server, for example, is not a suitable Web server, since it manages a maximum of 10 simultaneous HTTP sessions.

Installation

To be able to transfer device configurations onto the Webserver, the latter must allow HTTP PUT requests. All other functions require HTTP GET authorisation.

Since all HTTP requests are executed unauthenticated, the Web server must allow anonymous reading and possibly also anonymous writing.

To allow HTTP PUT commands on a MS IIS, the read and write check box must be enabled in the configuration of the relevant virtual directory.

Configuration

Detailed information on how the URL parameter of the update server is configured on the innovaphone devices may be found in the chapter entitled "Configuration/General/Update".

Note here that the URL parameter must point precisely to the location of the file with the contained maintenance commands. It is also to be noted that this URL (just like all other URLs used by innovaphone devices) does not support host names. Therefore, a valid IP address always has to specified.

If the URL happens to end with a ‘/’, then a standard file name based on the product description is used. If, for example, the URL is http://1.2.3.4/configs/ , then it is extended in the case of an IP1200 as follows: http://1.2.3.4/configs/update-ip1200.htm . The product name is specified in the first line in chapter "Configuration/General/Info". The file extension is irrelevant here. The extension *.txt or *.htm or no file extension at all is possible. In relation to URL specifications, note that some Web servers differentiate between upper case and lower case letters.

Running maintenance

The update file is immediately read and also immediately executed. After a device restart, the update server is automatically queried periodically in accordance with the interval set.

When the maintenance file has been successfully received, it is executed sequentially. Theoretically, all commands that can be transmitted to the device in a Telnet session or that occur in a configuration file can be used in the maintenance file.

Maintenance commands

Additional commands implemented specially for the update server are available. The maintenance file is executed every time (depending on the interval set), as soon as it is received.

Check command

In most cases, however, the maintenance file should be executed not every time as soon as it is received, but once only. Assuming that a secure configuration is to be loaded onto several devices, then it is best if this is done from one device. This can be achieved with the check command:

mod cmd UP1 check <final-command> <serial>

innovaphone devices have an internal variable that is initially empty (or empty if the device was reset with the standard settings) called UPDATE/CHECK. The check command compares the content of <serial> with the UPDATE/CHECK variable. If both match, all further processes of the maintenance file are terminated.

If they differ, the remaining processes are executed. When the last process has been executed, the UPDATE/CHECK variable is overwritten with the content of <serial>, and the content of <final-command> is executed. The following commands are usable content for <final-command>

• ireset: Resets the device as soon as it is not being actively used.
• reset: Resets the device immediately.
• iresetn: Resets the device as soon as it is not being actively used and a reset is required.
• resetn: Resets the device immediately if a reset is required.
• ser: no-op

Time command

Often it is preferred to perform such changes at particular times (for example, at night when no work is being done). This can be achieved with the times command:

mod cmd UP1 time [/allow <hours>]

The time command compares the current time with the content of <hours>. <hours> is a comma-separated list of specified hours, within which execution of the maintenance file is possible. If the content of <hours> with the restriction does not match, all further processes are terminated. The following hours are considered valid times, within which execution of the maintenance file makes sense.

mod cmd UP1 time /allow 12,22,23,0,1,2,3,4

With this command, execution of the maintenance file is allowed from 12:00 to 12:59 hrs and from 22:00 to 04:59 hrs. If the device does not have a time, all processes are terminated.

mod cmd UP1 time [/allow <hours>] [/initial <minutes>]

If the /initial parameter is set, no further commands are executed within the specified number of minutes <minutes>, once the device has been reset. This was implemented to avoid a firmware download and the overwriting of Flash memory during device installation.

mod cmd UP1 time /allow 12,22,23,0,1,2,3,4 /initial 6

With this specification, all processes of the maintenance file are suppressed within the first six minutes and within the valid times specified in the /allow parameter after every device restart. If the /initial parameter was set, new devices (or devices that were reset with the standard settings) can, after a restart, receive the maintenance file within the number of minutes specified in the /initial parameter, even if they lie outside the valid times as specified in the /allow parameter. This allows new devices to receive a current standard configuration quickly.

Prot command

To initiate a firmware update, the following command can be executed:

mod cmd UP0 prot <url> <final-command> <built-serial>

This command downloads new firmware (if available) from the specified URL onto the device. Finally, the <final-command> is executed. innovaphone devices have an internal variable that is initially empty (or empty if the device was reset with the standard settings) called UPDATE/PROT. The prot command compares the content of <build-serial> with the UPDATE/PROT variable. If both match, no firmware is downloaded. If the UPDATE/PROT variable is not set (new devices or after a device restart), the content of <build-serial> is compared with the built number of the current firmware. Once the firmware has been successfully downloaded, the UPDATE/PROT variable is overwritten with the content of <build-serial> . Note that the <build-serial> parameter is not compared with the firmware version currently loaded. It is the responsibility of the administrator to keep this standard.

If the <url> parameter ends with a slash (‘/’), a standard firmware file name is appended to the URL depending on the product description (for example, IP1200.bin for an IP DECT system).

mod cmd UP0 prot http://192.168.0.10/firm/ip1200.bin ireset 04-5656

The command
mod cmd UP0 prot http://192.168.0.10/firm/ ireset 04-5656

determines whether the firmware version 04-5656 was already installed. If this is not the case, the current firmware is downloaded from the address 192.168.0.10/firm/ip1200.bin, the UPDATE/PROT internal variable is overwritten with 04-5656 and, finally, the device is reset as soon at it is not being actively used.

Boot command

With the boot command, the boot code is updated and this is done in the same way as with the prot command.

mod cmd UP0 boot <url> <final-command> <built-serial>

The command
mod cmd UP0 boot http://192.168.0.10/firm/ ireset 205

determines whether the boot code version 205 was already installed. If this is not the case, the current boot code is downloaded from the address 192.168.0.10/firm/boot1200.bin, the UPDATE/BOOT internal variable is overwritten with the version number of the downloaded boot code (205) and, finally, the device is reset as soon as it is not being actively used.

Bmc command (only for DECT devices)

With the bmc command, the DECT radio code ( aka burst mode controller firmware or BMC code ) is updated and this is done in the same way as with the prot command.

mod cmd UP0 bmc <url> <final-command> <built-serial>

The command
mod cmd UP0 bmc http://192.168.0.10/firm/ ireset PCS04fd

determines whether the DECT radio code PCS04fd was already installed. If this is not the case, the current DECT radio code is downloaded from the address 192.168.0.10/firm/ccfp1200.bin, the UPDATE/BMC internal variable is overwritten with PCS04fd and, finally, the device is reset as soon at it is not being actively used.

SCFG command

If the UP0 interface is being used, then the device configuration can be stored on a Web server.

mod cmd UP0 scfg <url>

This command instructs the device to upload its current configuration to the <url>. This can be achieved with the HTTP PUT command. The url must be writable. The following constants can be used in the url:

Sequence	Replaces	Example
#F	kernel build number	08-12345
#B	boot code build number	401
#H	hardware build	102
#h	Device hardware number	IP1200-03-0d-f0
#m	MAC address of the device	00-90-33-03-0d-f0
#d	Current date and time	20051010-170130
#bn	rolling backup index	3
#i	(one of) the local ip-address	192.168.0.1

The rolling backup number loops over 0 .. n-1 for each backup.

CFG command

A configuration file may be loaded using the

mod cmd cfg <url> <final-command> <serial>

command. The file will be read, all configuration commands in there executed and a final config write appended. Please note that no activation will be done implicitly. Thus, you will likely either use reset as <final-command> or use ser and have a config activate and iresetn follow.

Example

A Web server exists at the address 192.168.0.10 with a subdirectory called configs. In this directory, there are two further subdirectories, in which the current firmware files for all innovaphone devices are stored. Clients provide the DHCP server with the option #215 as http://192.168.0.10/configs/. In this directory, there is a file update-ip1200.htm , which processes the following lines:

 mod cmd UP1 times /allow 23,0,1,2,3,4 /initial 6
 mod cmd UP0 scfg http://192.168.0.10/configs/saved/#h.txt
 mod cmd UP0 prot http://192.168.0.10/configs/04-5679 ser 04-5679
 mod cmd UP1 check ser 20040330-01
 config change PHONECFG0 /coder G729A,60, /lang eng /protect
 config change PHONEAPP0 /f4-10 BellOff /f4-v0 %1BE /f5-10 BellOn /f5-v0 %1BF
 config write
 config activate
 iresetn

This example demonstrates how the configuration of a device is stored on a Web server; all IP1200 devices are then instructed to load/update the firware version 04-5679 in the time period 23:00 hrs to 04:59 hrs. New devices are updated after a restart and after the specified six minutes have elapsed. The devices are configured so that they use the G729 codec with a frame size of 60ms, the language setting is English and the configuration is write-protected. Therefore, only an administrator with appropriate authorisation can change this file. In addition, two standard functions were programmed for the device.

There is also the file update-ip3000.htm, which reads the following two lines:

 mod cmd UP1 time /allow 23,0,1,2,3,4
 mod cmd UP0 prot http://192.168.0.10/configs/04-5679 /ser 04-5679

IP3000 devices are updated to firmware version 04-5679 in the time period 23:00 hrs to 04:59 hrs.

Using an innovaphone box as web server

Any box with a CF slot and a CF card installed can serve as web server platform to read update scripts, firmware files, configuration files or to save configurations from V6 SR1 on.

Asynchronous operation

The commands prot boot bmc and cfg run asyncronous. The status of the current upload command can be shown with the status command

mod cmd UP0 status

In most cases a syncronous operation is preferred, in this case the /sync option can be used:

mod cmd UP0 /sync prot ...