Requirements
- 7940 or 7960 phones
- A Linux machine to edit one of the required files (I haven't tried other methods in Windows machines but I have read it is possible), and possibly also to use as TFTP
- Windows TFTPD32 or CallManager as a TFTP, or tftpd-hpa in a Linux host
Procedure
- First we will set up the TFTP. If using TFTPD32, configure it in such a way that we can download files from it. A good test is to create a dummy file inside the root folder selected to server requests, and then from the same computer, on a command prompt type: tftp <IP used to listend to TFTP requests> get <name of the dummy file>.
- Download the firmware package you would like. In our case, we will be using cmterm-7940-7960-sccp.8-1-2.zip. Inside you will find 4 files:
- P00308010200.sbn
- P00308010200.loads
- P00308010200.bin
- P00308010200.sb2
- Put those files inside the TFTP path
- On the Linux machine, open a terminal
- Run VI to create the Universal Bool Loader:
- Press lower case 'i' to start introducing characters
- Type the SCCP load name that we have available in the TFTP, in our case it will be P00308010200 , without any extension
- Press escape, then press and hold shift + zz, this will save and exit the editor. I have had bad experiences with Windows editors because a space character is added at the end of the string, which makes the phone look for a file that the TFTP server can't find. This can be easily avoided if we all use Linux instead as our Operating System. This situation is documented in bug CSCdv19260
- Now we need another file, the SIPDefault.cnf. This file contains a statement called "image_version", and needs also to be included in the TFTP Path. The format to follow is image_version : "P00308010200". This one can be edited and saved in Windows I think. Here is an example file
- Put it in the TFTP path
- Configure the IP Phone to point to the computer running TFTPD32 as the TFTP server and reboot it
- In TFTPD32 an entry like this will be logged (refer to the troubleshooting section in case of troubles):
- Connection received from 172.30.2.81 on port 50209 [20/04 17:26:39.973]
Read request for file <P00306000300.loads>. Mode octet [20/04 17:26:39.973]
Using local port 3055 [20/04 17:26:39.973]
<P00306000300.loads>: sent 1 blk, 461 bytes in 0 s. 0 blk resent [20/04 17:26:39.989]
- At this point the phone will start installing the SCCP firmware and the next entries will be those related to a SCCP registration:
- Read request for file <CTLSEP00156219BB2F.tlv>. Mode octet [20/04 17:27:16.020]
- File <CTLSEP00156219BB2F.tlv> : error 2 in system call CreateFile The system cannot find the file specified. [20/04 17:27:16.035]Connection received from 172.30.2.81 on port 49980 [20/04 17:27:16.098]
- Read request for file <SEP00156219BB2F.cnf.xml>. Mode octet [20/04 17:27:16.098]
File <SEP00156219BB2F.cnf.xml> : error 2 in system call CreateFile The system cannot find the file specified. [20/04 17:27:16.113] - Connection received from 172.30.2.81 on port 49981 [20/04 17:27:16.145]
Read request for file <XMLDefault.cnf.xml>. Mode octet [20/04 17:27:16.145] - File <XMLDefault.cnf.xml> : error 2 in system call CreateFile The system cannot find the file specified. [20/04 17:27:16.160]
- No need to get those, we can now configure the phone manually to point to a different TFTP, most likely CallManager where it can then find its configuration file (SEP00156219BB2F.cnf.xml)
- If the phone still keeps asking for a SIP load (something like P0S3-8-12-00.loads), then create a SEP00156219BB2F.cnf.xml file with these contents, where P0030801SR02 is the name of the SCCP phone load:
<device>
<deviceProtocol>SIP</deviceProtocol>
<loadInformation model="IP Phone 7960">P0030801SR02</loadInformation>
</device>
Troubleshooting
Problem:
After pointing to TFTPD32 and resetting, the phone gets stuck in a loop. It will say "Configuring VLAN / Configuring IP / Resetting" and never finish. You read the TFTP logs and they complain about the phone trying to read a file that doesn't exist. CallManager TFTP traces will display a connection request with the correct file name, but it just won't find it. TFTPD32 is actually more efficient and detects a filename with strange characters. The linefeed looks like this:
Solution:
This is most likely the bug about the linefeed introduced by Windows text editors. Make sure the file goes out of the Linux machine as in step 5 without ever been opened in Windows, and then deposited in the TFTP path.
Solution:
If the file is being transferred from the linux PC to the TFTPD32 PC by email, I have had bad experiences with Outlook, the file will still get corrupted during download from Exchange. Use SCP to securel-copy it or just use a linux based TFTP server, or use Firefox to download the attachment. The file transaction should look like this: