'; Troubleshooting | Incognito Help
Array
(
    [0] => Array
        (
            [version] => 4.3
            [language] => en
        )

    [1] => Array
        (
            [version] => 4.2
            [language] => en
        )

    [2] => Array
        (
            [version] => 4.1
            [language] => en
        )

    [3] => Array
        (
            [version] => 4.0
            [language] => en
        )

    [4] => Array
        (
            [version] => 3.5
            [language] => en
        )

    [5] => Array
        (
            [version] => 3.4
            [language] => en
        )

    [6] => Array
        (
            [version] => 3.3
            [language] => en
        )

    [7] => Array
        (
            [version] => 3.2
            [language] => en
        )

    [8] => Array
        (
            [version] => 3.1
            [language] => en
        )

    [9] => Array
        (
            [version] => 4.2
            [language] => fr
        )

    [10] => Array
        (
            [version] => 4.2
            [language] => es
        )

)
Rel: acs/references/acs/dita/troubleshooting
URI: acs/references/troubleshooting
=== Tags ===
Array
(
    [879] => troubleshooting
)

=== Related ===
Array
(
)

Troubleshooting

Check this section for solutions to some common issues.

Logging Information

Table 1. Logging Level
Level Type Details
OFF ALL Disables logging.
L0 (Min) AUD0, WARN, ERROR Essential minimal logging. For example, service start/stop notifications, error messages, and warning messages.
L1   No additional logging information at this level.
L2 DEBUG2, ERROR Basic information about queries in addition to L0 information.
L3 (Max) DEBUG3 Comprehensive information about service activity.

Monitoring Logs

To display service activity in real-time, that is, to view commands as they are executed and view service traffic, you can monitor logs through the console.

Note: Monitoring logs in real-time for prolonged periods may adversely affect service performance. Therefore, it is recommended for troubleshooting and testing purposes only.

To enable this feature, you must configure the REMOTELOGLEVEL and REMOTEPORT parameters using the ACS CLI. Set the remote log level to ‘Level 3 (Max)’.

Table 2. Service Configuration Properties
Name Value Type Possible Values Default Description
REMOTELOGLEVEL STRING MIN, L0, L1, L2, L3, MAX, OFF OFF Level of logging detail to use for telnet logging MIN’ and ‘L0’ are the same. ‘MAX’ and ‘L3’ are the same. Specifying ‘OFF’ disables logging. Use high log levels for debugging purposes only.
REMOTEPORT IP ADDRESS:PORT *:0 Interface to which logs are sent for telnet logging. Use a wildcard (*) to bind to all available interfaces. Use a port number higher than 1024, since ports 1 to 1024 are reserved. Set port to 0 to disable remote service monitoring.

Monitor logs by SSH

After logging in to the service by SSH, use the following syntax:

# tail -F <log file name>

Monitor logs by telnet

Use the following syntax to connect to the service through telnet:

# telnet host.example.com -p 12345

Cannot Connect to Service Through Telnet

If you are unable to connect to a service using telnet, the telnet port may already be in use or may be held in a listening state. Change the port to a new number and try the connection again.

Reading Logs

All log lines follow the same basic format:

Date Time [Log Level] <Thread ID> Type

For example:

2012-05-25 11:43:01 [DEBUG2] <pool-12-thread-37> TR69:
2012-05-25 09:19:25 [DEBUG3] <pool-6-thread-619> WSDL:

Discovery Errors

Check this section for common errors that can occur when a device is trying to complete the discovery process for the first time.

It is recommended that you set your log levels to L3 (Max) for troubleshooting.

Note: The logs should show the device contacting the service. If there are no requests from the device in the logs, start troubleshooting by ensuring that the ACS URL the device is using is correct and that it is routable from the device subnet. Inspect the logs for errors such as “Discovery Disabled”. Check for traffic being blocked by a firewall.

Discovery Failed

During the discovery process, the service uses the RPCs GetParameterName and GetParameterValue to send a message to the device to obtain all device-supported parameter names and values.

The device response is the output of a complete list of parameters. The error “Discovery Failed” occurs when a device is unable to transfer the complete list of parameters. This can happen for several reasons. For example, when there are memory or CPU processor limitations, or when the vendor firmware version uses an incomplete implementation of the TR-069 standard.

How to correct a “Discovery Failed” error, depends on whether ACS has a matching device model record. Navigate to Device Models and search for the model.


2013-04-30 14:34:39 [ERROR] <pool-12-thread-15> TR69: (001e8c:WLAN:001e8cc691a9:Broadcom) Device discovery failed: The last discovery process was interrupted. The session was closed before the process was completed

2013-04-30 14:34:39 [ERROR] <pool-12-thread-15> (001e8c:WLAN:001e8cc691a9:Broadcom) Received an Inform request while waiting for a response from device. Creating a new session.

2013-04-30 14:34:39 [ERROR] <pool-12-thread-15> TR69: (001e8c:WLAN:001e8cc691a9:Broadcom) Device discovery failed: The last discovery process was interrupted. The session was closed before the process was completed

2013-04-30 14:34:39 [ERROR] <pool-12-thread-15> (001e8c:WLAN:001e8cc691a9:Broadcom) Failure to discover new device notification message sent to ACS

2013-05-04 16:39:02 [ERROR] <pool-12-thread-20> TR69: (CCEF48:Gateway:CBT154004NK:Cisco) Fault message received from CPE. Last sent command: GETPARAMETERVALUES. Description: Code='SOAP-ENV:Client'. Message=CWMP fault. DetailFaultCode='9001'. DetailFaultString=Request denied

2013-05-04 16:39:03 [ERROR] <pool-12-thread-20> TR69: (CCEF48:Gateway:CBT154004NK:Cisco) Received fault message 'Request denied' - Code '9001'. Last command: To be reviewed

2013-05-04 16:39:03 [ERROR] <pool-12-thread-20> TR69: (CCEF48:Gateway:CBT154004NK:Cisco) Device discovery failed: Fault message received from CPE. Last sent command: 
GETPARAMETERVALUES. Description: Code='SOAP-ENV:Client'. Message=CWMP fault. DetailFaultCode='9001'. DetailFaultString=Request denied. Use batch discovery

Matching Device Model Record

If the service has a matching device model record, select the device model and then select Discovery Algorithm. Change the device discovery algorithm to use Batch discovery and select a batch size. The service will request the parameters from the device in batches instead of all at once. Once the batch discovery algorithm is set for a device model, all subsequent devices will use that algorithm.

Note: It is recommended that you start testing with a batch size of 1 to confirm the device will synchronize. Then increase the batch to a larger size, such 50 or higher. Work your way down from that number until the device is synchronized. Network activity increases as the batch size gets smaller.

No Matching Device Model Record

If ACS does not have a matching device model record, you need to configure the batch discovery algorithm parameter in the ACS CLI to include the device manufacturer name. Separate names with a semicolon. For example:


USE_BATCH_DISCOVERY_ALGORITHM=Cisco;Motorola, Inc.;Technicolor;ZyXEL;Comtrend

DISCOVERY_BATCH_SIZE=1
Note: This value is case sensitive. You can find the manufacturer name in the “Discovery Failed” message.

Fault message received from CPE

This error indicates that during the RPC GetParameterName, the device reported a problem with a parameter name. The service is then unable to use that parameter name for the RPC GetParameterValue.


2011-08-12 12:06:28 [ERROR] <HttpServerWorker-18> TR69: (O: 90E6BA, P: R-4M-16M, S: 2255292): Device discovery failed: Fault message received from CPE. Last sent command: GETPARAMETERVALUES. Fault message description: Code='Client'. Fault message=CWMP fault. DetailFaultCode='9005'. DetailFaultString=Invalid Parameter Name

To move past this CPE problem, adjust the CWMP service configuration file, config.txt, to ignore the error.


IGNORE_DISCOVERY_ERRORS=true

Error Parsing Inform

The device is sending an invalid XML character and is causing the inform to fail.

Parsing Inform Example Error from Logs


013-08-08 13:32:05 [ERROR] <pool-12-thread-9> TR69: (0000CA:DOCSIS 3.0:D4PBSMEC6537657:Arris Interactive, L.L.C.)  Error parsing Inform
org.apache.axiom.om.OMException: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[2,4646]
Message: An invalid XML character (Unicode: 0x4) was found in the element content of the document.

This error indicates a problem with the firmware. Check with your vendor for a newer firmware version.

No Device Record in ACS

The device appears to complete the discovery process with no errors. Yet, there is no device record in ACS.

This error can occur when:
  • the RabbitMQ service is not running
  • the service license is incorrect or not set
  • multicast integration is incorrect or not set

Begin troubleshooting by checking the logs.

To check the RabbitMQ status:


# /etc/init.d/rabbitmq-server status

To start RabbitMQ:


# /etc/init.d/rabbitmq-server start
Top