We were using many Cisco SPA112 units and prior to this many Linksys units.
Provisioning was very easy as the units looked for a default config that contained basic information for getting the units on the network and on the correct firmware. At that point the units would look for a config file for their specific MAC address config file name and the SIP server information we define in the default config.
The 200/201 units look only for their MAC address as a config file name out of the box. Operators do not want to manually input information into a unit so it will automatically provision from a provisioning network. We would request that the units be made to look for a default config file that is generic in name if a specific file (MAC address) doesn't exist. This woud make our lives much easier and let us properly provision these units again.
We also request a full list of config file params as they relate to the GUI config. We have been mapping these as needed, however this is not easy.
So you are looking for some generic file name in default conditions , some thing like R200-201.cfg ?
a two part would be great...
first get the generic file, to get the sip servers, network info and soforth, and then also pull mac.cfg to get the account specific information.
(haven't started playing with the auto provision yet) but if it currently can't pull the TFTP server location via DHCP, that would be great too.... realllly handy when a subscriber decides to factory default thier radio. re-provisions it back into service that way.
Again, if the unit would look for a 'Constant' provisioning filename {R200-R201.cfg}, rather than a 'Variable' one {MAC.cfg}, this would make much more sense from a provisioning standpoint and be easier to implement with people's existing systems.
Can we expect this change to be included in the next firmware release?
I now have provisioning from Option 66 working, thanks to the change suggested in this thread! The router boots up and requests an IP address via DHCP. The DHCP server is configured to send back Option 66 information which is the IP address of a TFTP server. The router then requests a file called Cambium-cnPilot-R.cfg from the TFTP server, which holds very little information, mainly just where to find the real configuration file (and also disables Option 66). Now the router fetches the real configuration file from our webserver. With some python scripting, we then look at the MAC address of the requesting router and return a custom configuration file that contains customer information like HostName and SIP configuration from our CRM system. Now the router compares its running configuration to that of the new configuration file it just fetched, and applies/reboots itself if needed. Slick!
FYI If you are updating a device to 4.3-R9 from another firmware, I found that the Config File name remains the same as prior to the firmware upgrade. You would need to factory default the unit to get the new filename to be Cambium-cnPilot-R.cfg, or you would need to change it manually or by some other method (template from Maestro maybe).
As I mentioned in the FYI of my last post, to get the Config File Name in 4.3+ to change to Cambium-cnPilot-R.cfg one needs to factory default the unit. This is becoming a bigger issue now.
I image this is standard practice with upgrading firmware, that fields aren't overwritten by default.
But, in order to get this zero-touch system to work as intended, this field needs to get updated from its previous default of "$(MA)" to "Cambium-cnPilot-R.cfg".
The code could be written so that only if the field is currently=$(MA), then update to Cambium-cnPilot-R.cfg