cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1737
Views
0
Helpful
11
Replies

SPA122 not reboot after loading config file

Kevin tech
Level 1
Level 1

SPA122 ATA voice adapter, Version 1.3.0 (008_Customer_Test)

I'm facing a problem, when I tried to upload the configuration file into ATA via TFTP with DHCP option 66, the box does not restart after loading the file. Device has the factory default profile, so according to Cisco SPA1x2 ATA Provisioning Guide (chapter "TFTP provisioning") it able to obtain a TFTP server IP address directly from the DHCP server through DHCP option 66.

From this guide: "If a Profile_Rule is configured with the filepath of that TFTP server, the device downloads its profile from the TFTP server when it is connected to a LAN and powered up. If the device has the factory default profile, when powered up it resyncs to this file on the local TFTP server specified by DHCP option 66."
I tried this method in local LAN with DHCP and TFTP server running, TFTP show config file has been requested and sent to SPA122, no errors, but SPA never reboots. Wireshark also show that TFTP transaction was OK, I can see the request, the response, then the acknowledgment.  The configuration file was compiled with Profile Compiler (SPC) Tool.

1 Accepted Solution

Accepted Solutions

Just reset device to factory default, then save it's configuration.

does this method supports only binary .cfg config or XML file too?

On debugging/test version of firmware ? There's nothing like "expected behavior" of the firmware version you are using. It may not support import of external provisioning file at all.

It works on casual releases, but it mean nothing here.

View solution in original post

11 Replies 11

Dan Lukes
VIP Alumni
VIP Alumni

Device will reboot if a value of critical option become changed by new configuration. It seems not to be your case. May be no option value has been changed by new configuration - for example because new configuration is considered invalid at all. No way to just guess. Configure syslog&debug of voice application and capture it (beware - we need no kernel syslog captured by device itself). It will reveal more.

Note that you need to compile configuration by SPC tool dedicated to your particular firmware version. But I suspect you have no such SPC compilator - no SPC for 1.3.0 (008_Customer_Test) firmware subversion has been released at all.

Also note, this way of provisioning is insecure. Unauthorized subject can download any configuration from FTP, extract SIP credentials from it, then mimic other's identity. Bill fraud may occur.

Hi,

Thanks for the prompt reply.

Yes, I didn't find such SPC compiler tool targeted for 1.3.0 (008_Customer_Test), so I just used the latest SPC tool vers. 1.4.1 -- this tool not works with firmware v1.3.0?
Which SPC tool version should work with SPA122 firmware vers. 1.3.0?

This way of provisioning is within our lab local LAN, not on customer side, just a quick way to test config, therefore it secure.

1.3.0 (008_Customer_Test) is not standard release as far as I know. There may be no SPC compiler available for it and other version SPC may not work. You should use latest firmware whenever possible.

This way of provisioning is within our lab local LAN, not on customer side, just a quick way to test config, therefore it secure.

Then forget SPC compiler at all and deliver configuration as just XML file instead. You can create it from scratch or you can use blank factory default configuration as template. But even here no template for 1.3.0 version as such version has never been released to public.

1.3.0 (008_Customer_Test) is not standard release as far as I know. There may be no SPC compiler available for it and other version SPC may not work. You should use latest firmware whenever possible.

This way of provisioning is within our lab local LAN, not on customer side, just a quick way to test config, therefore it secure.

Then forget SPC compiler at all and deliver configuration as just XML file instead. You can create it from scratch or you can use blank factory default configuration as template. But even here no template for 1.3.0 version as such version has never been released to public.

Same thing, ATA not reboots when xml configuration file uploaded, too.

OK. It's either

  1. issue with the provisioning file itself, or with the method you are using to serve it to SPA122.

OR

  1. firmware issue.

As 1.3.0 is unreleased firmware, moreover, 008_Customer_Test is an test revision not expected to be used in production I would like to recommend you to upgrade first. Use latest version available, then try again to use provisioning file.

If you wish to debug issue on your current version (for whatever reason) you must turn on debugging and capture the log. Or we have nothing to analyze.

Well, first I want rule out configuration file problems.
Even if 1.3.0 (008_Customer_Test) is a non-standard release, not expected to be used in production, it should have the default configuration file, tailored for that particular FW version. Where I can find sample of that default config file?

Regarding above provisioning method of deploying configuration from local TFTP server use DHCP option 66, does this method supports only binary .cfg config or XML file too?

Just reset device to factory default, then save it's configuration.

does this method supports only binary .cfg config or XML file too?

On debugging/test version of firmware ? There's nothing like "expected behavior" of the firmware version you are using. It may not support import of external provisioning file at all.

It works on casual releases, but it mean nothing here.

Anonymous
Not applicable

You claimed answer correct, but I don't  know you has created XML configuration that works with 1.3.0 firmware, or you upgraded the device.

Just curious ...

I wasn't able to upload configuration, neither the CFG nor the XML types. So will try to upgrade the firmware to the latest version. 

It could be memory issue, but not sure. All configuration settings are stored in non-vol NAND Flash memory, right?

You claimed the device doesn't reboot after successful upload, not you are unable to upload configuration at all.

Well, regardless the exact issue, upgrade from current so suspicious firmware version to recent sounds good idea.

All configuration settings are stored in non-vol NAND Flash memory, right?

No documentation about it, thus I'm guessing only - but yes, I'm almost sure it's stored in flash. But we should wish it's not flash issue. Firmware is stored in flash also.

This is the solution?