Zero touch provisioning from F/W 7.3.7 up to 7.6.1

[brantwinter2004]

Hi - I spent an entire day trying to get automate the zero touch provisioning of SPA504G phones from the lowest possible F/W 7.3.7 up to the current 7.6.1.

• I have DHCP option 66 set to the web server address (example only) "http://192.168.10.10/provisioning" (note it is http as the old phones I don't think have the root CA's compatible with currently issued Cisco CA certs).
• I factory reset handsets
• They have an initial profile_rule of /spa$PSN.cfg
• I place an initial config file, spa504G.cfg, in /provisioning on the web server and confirm the URL works via a browser.
• The phones boot, I see them get an IP and the DHCP 66 option but then in the NGINX server log I see them try and get spa504G from the root of the webserver, not, /provisioning.
• I then set up a TFTP server ( I don't want one of these on the network to be honest) and the phones do pick up the config file from provisioning.
• The next issue, the old firmwares don't seem to support the evaluative logic in upgrade rules, ie:
• ($SWVER lt 7.5.2b) ? http://192.168.10.10/provisioning/spa50x-30x-7-5-2b.bin | http://192.168.10.10/provisioning/spa50x-30x-7-6-1.bit

So I am a bit stuck, I need to ensure I can get phones from the lowest possible F/W revision up to 7.6.1.

I know I have to get them to at least 7.5.2b before 7.6.1.

I want the spa504G.cfg file to come via a http server, not TFTP, and I then want to replace the profile_rule with a https:// URL to the proper config file.

The initial spa504G.cfg file needs to get the phone up to F/W 7.5.2b and then I can do the 7.6.1 F/W upgrade via the final xml profile_rule URL.

I found that in the spa504G.cfg file I could put the downgrade revision limit to 7.6.1 ad then the would prevent a 7.6.1 phone being downgraded to 7.5.2b after a factory reset.

I also thought that if the DHCP 66 option could not set the path as well as the IP to the initial .cfg file I may need to set up a virtual host for the URL name and just put it in the root of the virtual server.

Any help would be appreciated but the requirement is simple to get an SPA504G witg F/W 7.3.7 up to 7.6.1 with my current XML config on it.

On a side note, the 7.6.1 SPC tool would not run under Linux - kept giving a 'segmentation fault'.

[brantwinter2004]

I have just tested DHCP option 159 vs 150 on firmware 7.6.1. I can confirm that I get no HTTP request from the phone to web server if I use DHCP option 150 but I do if I use DHCP option 159 for the php URL.

[Dan Lukes]

I'm unsure here - 159 with IP or 160 with name may be used on SPA5xx interchangeably. But 159 will not work on some other models (SPA112) - the CN in certificate needs to be the same as name in URL. Thus IP with option 159 can't be used.

Option 160 works with all modes (with the exception of SPA1xx with 1.0.x firmware - it doesn't support such kind of provisioning at all).

[Dan Lukes]

So sorry - I'm using it for so long time, so I remembered it incorrectly. We use neither option 150 nor 159 but option 160.

I will edit all previous comments to correct it (so futire readers will not be confused).

[brantwinter2004]

OK great !

[brantwinter2004]

Out of interest, why do you pass the SW ver back in via the upgrade_rule URL ?

SW='.$_GET["SW"];

  if (cmp_ver($_GET["SW"], ">=", "7.5.2b")) {
    $upgrade_rule = 'https://$A/Cisco/spa50x-30x-7-5-5.bin?SW='.$_GET["SW"];
  } else {
    $upgrade_rule = 'https://$(A)/Cisco/spa50x-30x-7-5-2b.bin?SW='.$_GET["SW"];
  }

[Dan Lukes]

Well, I have syslog&debug turned on on all phones connected - and we are collecting all those messages. But it's a lot of data and it's not easy to filter it.

Such option allow me to see what firmware version has been upgrade easilyd in the Apache log.

If you are interested in my upgrade rule, you may be interested in my Profile_rule as well ? ;-) :

'https://$(A)'.$_SERVER['SCRIPT_NAME'].'?MAC=$MA;PSN=$PSN;Product=$PN;Serial=$SN;SW=$SWVER;HW=$HWVER;CERT=$CCERT;IP=$IP;EXTIP=$EXTIP;PRVST=$PRVST;UID1=$UID1;GPP_O=$O;GPP_P=$P'

Note the $EMS and $MUID must not be used here. Moreover, $CERT must not be used in Report_Rule.

[brantwinter2004]

Dan - You said, "But you can request certificate signed by CA recognized by both 7.3.7 as well as 7.6.1 firmware." 

I don't see where the self service portal gives me an option to generate a cert signed by both old and new CA's. I get the option to choose one or the other:

[Dan Lukes]

You has misunderstood.  A firmware may recognize more than one CA as trusted. SO you need no certificate signed by two authorities - you need certificate signed by the authority recognized by both (all) firmwares supported.

For SPA504G use the CA listed on first line (under 'Select product'). It should work for 7.3.7 as well as 7.6.1