This document is aimed squarely at the Vodafone incarnation of this phone. This *may* work with other providers. You will possibly want to look at the SPA504 wipe procedure as its a similar process in more detail.
We have recently ended up with a load of these phones to go into my event stock. I was offered these at a daft price with no history. As these have WiFi they are VERY handy. They can be paired up with a 5V battery supply and they are instantly seriously useful at an event. After my experiences with the SPA504’s I wasn’t too worried and indeed when I flashed them up I was able to factory reset them all without any bother. Awesome….or so I thought.
Fast forward to today and I want to start getting these setup. I pop into the web interface, asked for a login, so enter the default (admin, no password) and get thrown out. Bum! Tried a few defaults, nothing. This doesn’t look so good all of a sudden. A quick look at the UI and the firmware customization is set to Vodafone…uh oh…this is feeling familiar. I can get to the firmware update screen though so I’ll blow the firmware away… no, that didn’t help either, arse! I’ve spent money on stands for this lot so I’d really like them working.
Off we go to Google, and we find dozens of threads on this, ok this isn’t looking great. So let’s do some sniffing, maybe the 504 process works…
On boot the phone is trying to pull the config off of the damn firewall, ok, this is odd, maybe my fault, but its not helpful, of all the places you don’t want a TFTP server your firewall is WAY up the list. I also then spotted it tried to go out to ctprov.ctukprod.ims.vodafone.pt in particular it’s after http://ctprov.ctukprod.ims.vodafone.pt/vfuk/base/ciscoSpa525g2.xml. A quick browse and it seems Vodafone have used a bit more intelligence than Gamma. Although the phone gets a response from the server I don’t with a browser, I’ll bet they are looking at user agent strings or there is more to it than that URL, either way I don’t care at this point as I know what file is needed.
A quick google finds a template config file which I will link below. The file was saved onto a handy web server so that it gave us http://192.168.223.3/vfuk/base/ciscoSpa525g2.xml (I’m not fussy about internal IP secrecy). You’d need to provide that tree though for this to work, the IP address we are going to fudge in a second.
As with most of our sites we use PF or SmoothWall, so this bit is easy. You need to be able to create a DNS override, some routers allow this but most basic units don’t. ctprov.ctukprod.ims.vodafone.pt was pointed to our web server with an override so the phone now gets our web server’s IP and not the provisioning server. A reboot of the phone and it started up, still locked, asked the web server for the file ( tail -f /var/log/httpd/access.log on most systems) and rebooted again. This is a Cisco product, this means nothing until tested. Upon reboot nothing has changed, this doesn’t feel great at this stage so I fire up the web UI….and the password has gone. We are in, the phones are useful again.
Now there is a Caveat here. I’ve not really played with the phones much. I don’t know for sure they won’t revert if that DNS fudge is removed, eg if they are plugged in elsewhere. However the web UI has a lot of options to stop auto provisioning so you *SHOULD* be able to stop it undoing your hard work. Of course if you want to provision these phones from a central location you’ll need to dig deeper.
You can find an example config file here which is what I used with no changes.
UPDATE:
Since posting this I have found out that these will partially revert to locked if allowed out in the big wide world. There are three fixes…
1) Block 85.205.252.214 at the firewall, or better still block the whole /24
2) Block port 80 from your IP phones getting to the outside world
3) in the UI, go to advanced mode, Provisioning tab and turn off “Provision Enable”
Which one you use is up to you, they all work.