Howto:Firmware Upgrade V11r2 V12r1
Applies To
This information applies to:
- All PBX devices
- All DECT devices
- Linux Application Platform
Migration Policy
Configuration Changes
Automatic Media Relay
Up and including v11r2, the PBX and relay have done media-relay for all calls between public and private network addresses. From v12r1 on, this is done only if Media Relay explicitly set to Auto
in the PBX or in a gateway interface.
Linux Application Platform and its applications
xx11/11xx gateways can host a LinuxPlatform as well. First LinuxImage which as well fits for the new hardware types is V10sr32 (Build 100210). This build contains TWO linux images labeled
- Image-6010-3.4.10 - for old hardware types
- Image-IPx11-4.4.0 - for new hardware types (xx11/11xx)
Pay attention to the definition of used "Linux Kernel file" at Linux/General - especially when moving configuration files from "old" to "new" hardware types.
Please note that there is no v12 version of the linux application platform, so you still will be using Linux Application Platform V10.00!
Known Problems
Main Memory (RAM) Considerations
New firmware always has more features which in turn requires more resources. Growing firmware will thus consume both more flash and RAM for sure. A given system configuration will run flawlessly after a firmware largely only if there is still enough memory left after boot. As a rough rule of thumb, a v12r1 release will consume 1.5MB RAM and 0.8MB flash more compared to a v11r2 firmware.
Standard configurations which are according to spec will run on all supported hardware. However, unusual configurations may not. It is a good idea to examine both flash and RAM memory left on high load situations in your existing configuration to see if there is enough resources left for an upgrade. Please find details in Reference:Device Health Check.
Special care has to be taken for old devices with less memory than suggested by current specs. Most notably, these are the older IP30x models (hardware build 306 or less, which had 16MB RAM as opposed to 32MB in the current models). We do not recommend to upgrade such old hardware to a current firmware version unless it has been determined that the configuration in question will work.
Flash Memory Considerations
New firmware comes with new code for new features which consumes more flash memory for the firmware image. For this reason, the IP800/IP22/IP24/IP38/IP302/IP305 may run out of flash memory during upgrade to v12r1. Here is the recommended procedure for upgrade on such devices:
- save entire configuration
- reset to factory defaults
- load saved configuration (this will reorganize flash memory usage)
- upgrade to new firmware
When there is still not enough flash memory available to store the new firmware, the web GUI will issue a Firmwareupdate failed:no space during firmware upload. If the firmware upload is done using the update client, a Error 0x00130001 Major FLASHMAN0 no space event will occur.
With the new firmware, the amount of flash memory allocatable for the LDAP directory (that is, PBX config and call lists) is less than before to accommodate for the larger requirements. It is reduced from 3200kB to 2816kB on the IP800 and from 3200kB to 2560kB on the IP22/IP24/IP38/IP302/IP305.
On older IP110, IP200a, IP230 and IP240 phones, the PPP module has been removed from the firmware to keep the flash memory allocatable for the LDAP directory (that is, local phone book and call lists) unchanged.
Following file naming applies:
ip110,ip200a,ip230,ip240.bin
support H.323 w/o PPPip110,ip200a,ip230,ip240
-sip.bin support SIP w/o PPPxxx-no-ppp.bin
files are obsolete
No /DRIVE/CX0 any more
The /DRIVE/CX0 announcement file encoder has been removed. Use the web based converter instead.
SIP Digest Authentication
We have implemented protection against Replay Attacks for the SIP Digest Authentication.
In v12 (or later) we exercise the "one-time digests" strategy. A formally correct Digest Response is not accepted a second time. A client is required to increment the "nc" parameter if it issues another request.
If the client does not support this requirement the PBX will reject the registration. There is a config option to disable the protection. But it is not recommended to disable this feature. It's a security feature.
# for SIP/UDP http://ip-of-pbx/!config change SIP /disable-digest-replay-check # for SIP/TCP http://ip-of-pbx/!config change TSIP /disable-digest-replay-check # for SIP/TLS http://ip-of-pbx/!config change SIPS /disable-digest-replay-check http://ip-of-pbx/!config write http://ip-of-pbx/!config activate
You get a hint with the SIP/2.0 401 Unauthorized message (wireshark pcap)
SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 192.168.88.142:5060;branch=z9hG4bK5d7b5284edaa9bed3e3a323dc78f4022;rport=5060;received=192.168.88.142 From: <sip:111@192.168.88.134>;tag=2469966351 To: <sip:111@192.168.88.134>;tag=1151509663 Call-ID: 3129114392@192_168_88_142 CSeq: 1903 REGISTER Content-Length: 0 Date: Fri, 06 May 2016 13:54:31 GMT Warning: Digest replay attack detected WWW-Authenticate: Digest realm="192.168.88.134",nonce="859b13f3852c5701116600903340032b",qop="auth",algorithm=MD5
We have added a new option to the SIP module. If you have problems to register your SIP client with an authentication. Please use the latest available version V12r1.
http://ip-of-pbx/!config [^] change SIP /no-authentication-info http://ip-of-pbx/!config [^] write http://ip-of-pbx/!config [^] activate
Some SIP clients did not support it or did not work well. So you have to disable the authentication-info.
The client has to support the
RFC-2617: nonce-count This MUST be specified if a qop directive is sent (see above), and MUST NOT be specified if the server did not send a qop directive in the WWW-Authenticate header field. The nc-value is the hexadecimal count of the number of requests (including the current request) that the client has sent with the nonce value in this request. For example, in the first request sent in response to a given nonce value, the client sends "nc=00000001". The purpose of this directive is to allow the server to detect request replays by maintaining its own copy of this count - if the same nc-value is seen twice, then the request is a replay.
Special Precaution required when upgrading IPxx11 Gateways from pre-V11r2 sr13 or any V12r1 preview
There is an issue with cache coherency when multiple device drivers access the internal flash memory. In particular, if the SSD is used (by Linux or WebDAV), wrong data may be read from the internal flash (resulting in lost PBX objects for example). This issue has been fixed in V11r2 SR14.
However, during a firmware upgrade, this may result in corruption of some inherent device information such as the device's MAC address.
See Support:Special Precaution required when upgrading IPxx11 Gateways from pre-SR14 Firmware Versions!
Replicating objects from a dynPBX as dynPBX (Standby PBX)
It’s necessary to a add a dynPBX Id in the configuration of a Standby PBX in V12 if you are trying to a replication objects from a dynPBX to a dynPBX. In V11 you had to leave it empty because it used its own Id to find it at the master.
Related Articles
- Howto:Guideline V5 to V6 upgrade
- Howto:Upgrade Issues V5 to V6
- Howto:Firmware Upgrade V6 V7
- Howto:Firmware Upgrade V7 V8
- Howto:Firmware Upgrade V8 V9
- Howto:Firmware Upgrade V9 V10
- Howto:Firmware Upgrade V10 V11r1
- Howto:Firmware Upgrade V11r1 V11r2
- Support:Special_Precaution_required_when_upgrading_IPxx11_Gateways_from_pre-SR14_Firmware_Versions
- Howto:Firmware Upgrade V12r1 V12r2
- Howto:Firmware_Upgrade_V12r2_V13r1