I've been waiting to ask this question, since I knew that there were several other issues in the previous firmware related to boot-time provisioning; I was hoping that the new firmware would address mine, too. No such luck, it seems.
I work at an ITSP and we use many of the SPA series devices with our service, including the SPA 502, 504, 508, 509, 514, 525G2, and (previously) the SPA 2102. Our DHCP servers provide Option 66 in the DHCP Offer statement, but since our provisioning servers don't use the default <address of server>/spa$PSN.cfg file location to auto-configure the devices, our Option 66 provides a whole URL, instead of strictly the server name/address. That's to say our Option 66 provides an ASCII value like "http://address-of-server/path-to-file".
All of the other SPA devices parse this value properly, do a DNS lookup of the "address-of-server" portion, and then proceed to properly download the profile for the appropriate device from our provisioning server.
In the case of the SPA 122, however, it seems that it is not parsing the Option 66 value before doing a DNS lookup on it. What I'm seeing in my Wireshark captures is that the SPA122 is doing a DNS lookup of "http://address-of-server/path-to-file", instead of just looking up "address-of-server". These DNS lookup requests, of course, fail, and having failed to retreive it's Profile, the SPA 122, at this point, just sits there, idly waiting for further manual configuration.
Considering the volume of devices that we use, manually configuring each of these ATA units is not at all desirable.
If I log into the ATA via it's private interface (at the 192.168.15.1 IP on the Ethernet interface) and manually provide the same "http://address-of-server/path-to-file" value in the profile rule field, or in a resync URL ("http://192.168.15.1/admin/resync?http://address-of-server/path-to-file"), Wireshark does show that the device goes out and downloads it's profile successfully, but it never seems to reboot to apply the new profile to the device. So another manual step is required in manually power-cycling the ATA, once the profile has been downloaded.
At that point, the SPA 122 does download the correct profile settings from our provisioning servers, apply the settings, and reboot again to activate the new settings, all on it's own, the way I'd expect it to.
Is there any plans to change this behaviour to match the rest of the SPA product line, so that the SPA 122 will actually parse the Option 66 value before doing a DNS lookup on it? And how long are we likely to have to wait for this change to occur? (Weeks? Months?)
I figured out the same behaviour, but also with my SPA-3102. Actually the standard does not allow option 66 offering a complete URL.
If you have the opportunity to set up a TFTP server on a fixed IP server (what is quite easy :-) you could provide the spa122.cfg file that itselfs provides the complete profile rule. That's how I do it when there is need to configure a batch of devices.
I understand that, and honestly, if I had been involved in the design of the provisioning system initially, that's the way that I would have preferred to do it. I wasn't involved in the initial design, however, and now, we have hundreds, if not thousands, of these SPA devices deployed on various networks throughout our customer base.
Changing the way our provisioning system works at this point is not an option, since it would involve a huge number of man-hours to reconfigure all of our deployments. Management won't go down that road unless absolutely necessary.
Please contact me at paborn at cisco so I can work with you on resolving any issues and potentially enhancing the product.
Both you and Eik are correct. I've worked with the product management team and as a result, have submitted enhancement CDETS# CSCub77438 to have the SPA1xx devices behave in the same way as the SPA IP phones.
I do not have any tentative dates for this feature at this time.
Thanks for helping us enhance our products.
Option 66 is dedicated to name of TFTP server. If some CIsco devices allow full URL here, then it is non-standard extension. And undocumented, as far as I know. It is dangerous to depend on undocumented behavior.
Unfortunatelly, TFTP (only standard interpretation of option 66) offer no authentication nor encryption. It mean it can be used for provisioning of "Profile Rule" only. Separate HTTPS server is required for full provisioning then.
Options 159 and 160 are used by Cisco for "full URL" provisioning on many devices (including, for example SPA50xG phones). It's very bad news that the SPA12 doesn't support them.
HTTPS client is implemented within device already, so it's not software limitation nor computing power issue.
I would like to see support for options 159/160 (with https method allowed) on SPA1x2. Simple (e.g. no maintenance of TFTP server just for purpose of bootstrap provisioning of SPA1x2 devices, even it is easy) and unified (same system of secure bootstrap provisioning for all Cisco's SIP client devices) system reduce total cost of ownership.
Don't be confused by product specification ( http://www.cisco.com/en/US/prod/collateral/voicesw/ps6790/gatecont/ps10024/ps10029/datasheet_C78-691107.html . Yes, it mention the support of options 159 and 160, but it's not what we are speaking of here.
DHCP server within SPA122 can send those options to DHCP clients on LAN side.
But internal DHCP client doesn't ask those options from DHCP server on WAN side. Even worse - internal DHCP client will will fail at all when server inserts unsolicited option 160 to it's reply (i tried it with "https://test-provisioning.......cz/Cisco/Provisioning.php?PRVST=-2" URL, firmware 1.2.1(004) ).
Thanks for raising this issue. I've opened enhancements CDETS# CSCub70600 to have 159 and 160 added to the SPA1xx ATA devices.
good idea! May I also suggest to add a 'boot provision' feature, that is also available via IVR.
That includes 2 more options:
'Startup_Provision_Mode' may be on of 'None | TFTP | HTTP | HTTPS'
'Startup_Provision_Server' may be an IP or FQDN.
Both options shall be settable via IVR, e.g. options 300 / 301 and 310 / 311.
The requested files are /spa$PN.cfg and /spa$MAC.cfg, of wich at least one should be available.
After changing one of theese options the device shall reboot and execute the startup provision until before the standard provision routines engage. After success (existing option 'Failure on FNF') the 'Startup_Provision_Mode' must be reset to 'None', so that next time the device boots up only the standard procedures apply.
The new function must be available in newly shipped deviced!
The reason for this is to simplify the first setup after installing a fabric new device (especially SPA122, that has no web access on it's main port, sadly) in a location where no DHCP-Options server and/or TFTP server locally is available (e.g. SOHO/POS/public places). In the named config files a firmware update may be triggered and a more sophisticated provisioning, besides as an IVR admin password and so on.
I hope that's a good idea - it would ease my setups with the SPA122 that is now (shipped FW 1.0.1) VERY uncomfortable!
Thanks for the enhancement suggestion. I've shared your input with the product management team and have opened enhancement CDETS# CSCub77463 to track your idea.
I don't have any tentative dates at this time, but your input will not be ignored.
Can you possibly confirm what the status is with the enhancement CDETS# CSCub77463.
I'm currently running of SPA-112 Firmware 1.3.1 and still dont see the SPA-112 ATA parse option 66 when set to ascii and HTTP provisioning URL "http://provisioining-server/provisioining-path"
I have the same problem when trying DHCP option 160
Is there any other workaround as I cannot change my DHCP option 66/160 due to mutiple vendors using the same provisioning path.
There is workaround. Most Cisco devices, including SPA112 identify itself in DHCP messages (vendor-class-identifier option). Most of DHCP servers can send different replies based on such identification. So, you can send different option 66 for devices based on vendor and type. Read documentation of your DHCP server for mdre information about it or ask in a forum related to your DHCP server.
Please take a look at my post at https://supportforums.cisco.com/message/3844031#3844031 where I confirm that CDETS# CSCub70600 for including DHCP OPTION 159 and 160 are now in version 1.3.1(003) of the SPA112, SPA122, and SPA232D ATAs.
The enhancement CDETS#that you refer to is related to Eik's suggestion of using the IVR to set the provisioning parameters. This CDETS is assigned but has not yet been worked on. I've no indication of if or when work will be done on this CDETS.
Use this reference document to locate SPA ATA resources