TR-069 CWMP Scenario Scripting Guide

Users may create CWMP scenarios to easily set and verify CWMP parameters on their device. CWMP scenarios are small text based scripts that define interactions between the CDRouter ACS and the CPE device under test.

There are two ways to execute CWMP scenario script files.

cwmpScenarioPath - This testvar specifies the location of a scenario script that will be executed by the cwmp_scenarios.tcl test module, which can be added to your test package to run among all other tests.
cwmpScenarioBootstrap - This testvar specifies the scenario script file that can be executed during the start procedure at the beginning of a test run. This can be useful if you need the ACS to perform custom configuration of the DUT prior to starting any tests.

To get started with CWMP scenarios, create a CWMP scenario script file on the local disk of your CDRouter system. The scenario script file may contain one or more “scenario” blocks denoted by the “CWMP” keyword. Each “scenario” contains one or more “commands” from the list below, which direct the ACS to send CWMP RPC messages to the DUT and interpret the response.

Once you have created your scenario script file, update your config file with the full path to your scenario file(s):

testvar cwmpScenarioPath /usr/cdrouter-data/custom/files/verification_scenario.cwmp
testvar cwmpScenarioBootstrap /usr/cdrouter-data/custom/files/bootstrap_scenario.cwmp

Scenario Script Format

Each CWMP scenario script file may contain one or more scenario blocks which are executed as a unit. Each scenario block is defined by the CWMP keyword and a unique name for the scenario block, followed by a list of commands to execute, all enclosed in curly braces (’{ }’).

CWMP example_scenario {

    <command> 
    <command> 
    <command> 
        :
        :
}

Each command is a keyword that may also have a number of arguments enclosed in curly braces. The table below lists all of the available commands that can be used in a scenario block:

Available Commands
GetParameterValues
SetParameterValues
GetParameterAttributes
SetParameterAttributes
AddObject
DeleteObject
GetParameterNames
Reboot
Open
Close
Delay
DelaySeconds
Log
Event
Download
Upload
TransferComplete

Simple Examples

Here is a simple CWMP scenario block that specifies a single command: GetParameterValues. This causes the ACS to send a GetParameterValues RPC to the DUT for the “Device.Time.” object path.

CWMP example_scenario {

  GetParameterValues {

    # get all the Time parameters
    parameter Device.Time.
  }
}

Some commands, like GetParameterValues correspond directly to a CWMP RPC method. In some cases, the command may contain additional arguments that tell CDRouter how to handle the result. For example, you can verify whether returned parameters match specific values by using the “verify” command.

CWMP example_scenario {

  GetParameterValues {

    # get all the Time parameters
    parameter Device.Time.

    # verify the NTPServer1 matches the expected address
    verify Device.Time.NTPServer1 5.6.7.8
  }
}

Scenario Commands

CWMP Scenarios contain commands that map directly to TR-069 RPCs. For example, to set specific parameters, use the SetParametervalues command. To read the values of parameters, use the GetParameterValues command. The AddObject and DeleteObject commands are used to create and delete instances.

GetParameterValues Command

The GetParameterValues command sends a GetParameterValues RPC request to the DUT.

GetParameterValues {
    ....
}

The command must specify one or more parameters using the parameter argument. This parameter may be a full or partial path, and may contain wildcards. (Note: wildcard support was added to CDRouter in version 11.3, and can only be used with CPE’s that support the TR-069 Amendment 6 specification.)

GetParameterValues {

  parameter Device.ManagementServer.URL
  parameter Device.Time.
  parameter Device.IP.Interface.*.Status

}

verify argument

The optional verify argument is used to verify any value returned by the GetParameterValues. By default, verify will check to ensure that the value of the specified parameter exactly matches <value>.
```
GetParameterValues {

  parameter Device.ManagementServer.URL verify
  Device.ManagementServer.URL "https://acs.cdroutertest.com/"

}
```
Additional keywords are available to modify this behavior. These keywords and their arguments must be specified in square brackets.
- [ any ]
  
  The any keyword ensures the parameter exists without regard for its value. This is useful for parameters such as packet counters which may be constantly changing. Empty (null) values are also acceptable.
```
verify Device.Time.NTPServer1 [ any ]
```
- [ accept … ]
  
  The verify argument can also be configured to accept a list of values using the syntax [ accept value1 value2 ... ] . The value returned by the GetParameterValues call will then be compared to the list of acceptable values.
```
verify Device.Time.NTPServer1 [ accept 5.5.5.5 5.5.5.6 ]
```
  To verify a boolean value that may return either true or 1:
```
verify Device.ManagementServer.PeriodicInformEnable [ accept true 1 ]
```
- [ regexp … ]
  
  The verify argument can compare the value returned by the GetParameterValues call against a TCL regular expression if the exact value is not known. Any valid TCL regular expression string may be used and should be enclosed in curly braces (’{}’).
```
verify Device.Time.NTPServer1 [ regexp {[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+} ]
```

block argument

One or more block arguments can be specified to perform custom validation on any parameter returned by the GetParameterValues call. The block argument is followed by a section of TCL code which can be designed to iterate over each parameter returned by the DUT and validate them individually as needed.

The special params TCL array variable contains all of the parameters returned by the GetParameterValues call as key,value pairs. The params array also contains a “count” index whose value is the number of parameters returned.

Validation code within the block can call the buddy::PASS or buddy::FAIL methods to report results into the test log file.

block {

    #- Make sure we did not get 0 parameters
    puts "Starting my own validation"

    set count $params(count)
    buddy::logInfo "I found $count parameters"
    if { "$count" == 0 } {
      buddy::FAIL "I was expecting 0 parameters"
    } else {
      buddy::PASS "Okay I did not find 0 parameter values"
    }

    #- Verify Device.DNS.Client.Server.{i}. Table
    set count [ llength [ array names params "Device.DNS.Client.Server.{i}.Status" ] ]
    puts "Received $count entries in Device.DNS.Client.Server.{i}. table."
    if { $count == $params(Device.DNS.Client.ServerNumberOfEntries) } {
        buddy::PASS "ServerNumberOfEntries parameter matches actual number of parameters received."
    } else {
        buddy::FAIL "ServerNumberOfEntries parameter does not match actual number of parameters received."
    }

    foreach i [array names params "Device.DNS.Client.Server.*.Status"] {
        if { $params($i) != "Enabled" } {
            buddy::FAIL "$params($i) is not Enabled."
        } else {
            buddy::PASS "$params($i) is Enabled."
        }
    }
}

SetParameterValues Command

This command will send a SetParameterValues RPC to the DUT with one or more parameters to modify with given values.

SetParameterValues {
    ....
}

parameter argument

The SetParameterValues command must specify a parameter using the “parameter” argument along with its value and its type.

SetParameterValues {

    parameter Device.ManagementServer.PeriodicInformEnable 1 boolean

}

Note that inclusion of the type attribute is required in a SetParameterValues request, according to section 3.5 of TR-069 Amendment 6. In order to support arbitrary, vendor-defined parameter names in CWMP scenario files, you must specify the type of the parameter you wish to set.

The ACS will automatically include this type in the outgoing XML “<Value …>” encoding of the SetParameterValues RPC message:

<cwmp:SetParameterValues>
    <ParameterList SOAP-ENC:arrayType="cwmp:ParameterValueStruct[1]">
        <ParameterValueStruct>
            <Name>Device.ManagementServer.PeriodicInformEnable</Name>
            <Value xsi:type="xsd:boolean">1</Value>
        </ParameterValueStruct>
    </ParameterList>
    <ParameterKey>cdrouter</ParameterKey>
</cwmp:SetParameterValues>

If the “parameter” argument is specified without a type field, the ACS will omit the type attribute in the outgoing XML “<Value>” encoding:

<cwmp:SetParameterValues>
    <ParameterList SOAP-ENC:arrayType="cwmp:ParameterValueStruct[1]">
        <ParameterValueStruct>
            <Name>Device.ManagementServer.PeriodicInformEnable</Name>
            <Value>1</Value>
        </ParameterValueStruct>
    </ParameterList>
    <ParameterKey>cdrouter</ParameterKey>
</cwmp:SetParameterValues>

faultcode argument

The faultcode argument is optional and may be used to specify an expected CWMP Fault Code value:
```
faultcode 9005
```
A CWMP scenario will create a FAIL result if a SetParameterValues command produces a SOAP fault. However, if a SOAP fault is expected, the expected faultcode may be configured. If a fault does not occur or the fault code does not match, the scenario will be set to a FAIL. This is very useful for negative testing.
```
SetParameterValues {
    parameter InternetGatewayDevice.WANDevice.1.does_not_exist
    faultcode 9003
}
```

GetParameterAttributes Command

The GetParameterAttributes command sends a GetParameterAttributes RPC request to the DUT.

GetParameterAttributes {
    ....
}

This command functions exactly the same as the GetParameterValues command.

The parameter argument is used to specify a parameter to request in the RPC.

GetParameterAttributes {
   parameter Device.DeviceInfo.UpTime
}

The verify argument can be used to validate the Notification values in the GetParameterAttributesResponse. All the special values, except regexp, can be used with verify in the GetParameterValues command.

GetParameterAttributes {
   parameter Device.DeviceInfo.UpTime

   # Only check if the parameter is i the response
   verify Device.DeviceInfo.UpTime [any]

   # Check if the Notification value is either 2, 4, or 6
   verify Device.DeviceInfo.UpTime [accept 2 4 6 ]

   # Check if the Notification value is 1
   verify Device.DeviceInfo.UpTime 1
}

SetParameterAttributes Command

This command will send a SetParameterAttributes RPC to the DUT with one or more parameters to modify with given values.

SetParameterAttributes {
    ....
}

The SetParameterAttributes command must specify a parameter using the “parameter” argument along with its Notification value as defined by Table 25 of TR-69 Amendment 6.

SetParameterAttributes {

    # Set an active notification on UpTime
    parameter Device.DeviceInfo.UpTime 2

}

This command only allows the setting of the parameter name and notification value in the SetParameterAttributes RPC. In the RPC that is sent to the DUT, NotificationChange will always be true, AccessListChange will always be false, and AccessList will always be empty.

The above example will result in the following SOAP message.

<cwmp:SetParameterAttributes>
  <ParameterList SOAP-ENC:arrayType="cwmp:SetParameterAttributesStruct[1]">
    <SetParameterAttributesStruct>
      <Name>Device.DeviceInfo.UpTime</Name>
      <NotificationChange>true</NotificationChange>
      <Notification>2</Notification>
      <AccessListChange>0</AccessListChange>
      <AccessList SOAP-ENC:arrayType="xsd:string[0]"/>
    </SetParameterAttributesStruct>
  </ParameterList>
</cwmp:SetParameterAttributes>

AddObject Command

Objects can be created using the AddObject command.

AddObject {
    ....
}

The path argument is used to specify the path for the object.

path <path to object>

The instance %<name>% argument is used to capture the instance number of the new object returned by the DUT. The instance number can be referenced in other scenario commands using %<name%. See the example below to see how this works.

instance %<name>%

DeleteObject Command

Objects can be deleted using the DeleteObject command.

DeleteObject {
    ....
}

The path argument is used to specify the path to the deleted object. Paths can reference instance values created in previous AddObject commands using %NAME%.

path <path to object>

CWMP port_map_example {

    # -- Create a Port Map
    AddObject {
        path InternetGatewayDevice.WANDevice.1.WANConnectionDevice.2.WANIPConnection.1.PortMapping.
        instance INSTANCE1
    }

    # -- Read all the default values
    GetParameterValues {
        parameter InternetGatewayDevice.WANDevice.1.WANConnectionDevice.2.WANIPConnection.1.PortMapping.%INSTANCE1%.
    }


    # -- Read again, but verify some of them
    GetParameterValues {
        parameter InternetGatewayDevice.WANDevice.1.WANConnectionDevice.2.WANIPConnection.1.PortMapping.%INSTANCE1%.
        verify InternetGatewayDevice.WANDevice.1.WANConnectionDevice.2.WANIPConnection.1.PortMapping.%INSTANCE1%.RemoteHost {}
        verify InternetGatewayDevice.WANDevice.1.WANConnectionDevice.2.WANIPConnection.1.PortMapping.%INSTANCE1%.ExternalPort {0}
    }


    # -- Set a parameter
    SetParameterValues {
        parameter InternetGatewayDevice.WANDevice.1.WANConnectionDevice.2.WANIPConnection.1.PortMapping.%INSTANCE1%.ExternalPort {BadValue}
        faultcode 9003
    }

    # -- Verify the Set
    GetParameterValues {
        parameter InternetGatewayDevice.WANDevice.1.WANConnectionDevice.2.WANIPConnection.1.PortMapping.%INSTANCE1%.ExternalPort
        verify InternetGatewayDevice.WANDevice.1.WANConnectionDevice.2.WANIPConnection.1.PortMapping.%INSTANCE1%.ExternalPort {0}
    }

    # -- Delete the Port Map
    DeleteObject {
        path InternetGatewayDevice.WANDevice.1.WANConnectionDevice.2.WANIPConnection.1.PortMapping.%INSTANCE1%.
    }

}

GetParameterNames Command

The GetParameterNames command must specify a parameter using the parameter argument. This parameter may be a full or partial path.

GetParameterNames {
    parameter <parameter path>
}

The writable argument is used to verify the writable status of any parameter returned by the GetParameterNames. The writable argument is optional and multiple writable arguments may be specified.

writable <parameter path> <true|false>

The nextlevel argument controls the nextlevel flag passed to the GetParameterNames RPC. It accepts values of true, false, 1, or 0.

CWMP get_parameter_names_example {
    GetParameterNames {
        # get all the Time parameters
        parameter InternetGatewayDevice.Time.

        nextlevel false

        # verify the writeable status for a few names
        writable InternetGatewayDevice.Time.NTPServer1 true
        writable InternetGatewayDevice.Time.CurrentLocalTime false
        writable InternetGatewayDevice.Time.X_00247B_UpdateFrequency true
    }
}

The GetParameterNames command was added in CDRouter 8.1.

Reboot Command

The Reboot command sends the Reboot RPC to the CPE. Note: The CWMP session is not automatically closed after the Reboot RPC is sent. It is possible to perform other CWMP actions in the current session. If desired, the Close command may be sent after the Reboot RPC to end the current session and start the reboot process.

CWMP reboot_example {
   Reboot
   Close
}

The Reboot command was added in CDRouter 8.1.

Open Command

The Open command will initiate a new CWMP session if a current session does not exist. The Open command ends when an Inform is received from the device and the ACS returns an InformResponse. This command is used for CWMP scenarios that want more control over the CWMP session timing. Normally, a CWMP session is created automatically by any command that requires a CWMP session.

The Open command was added in CDRouter 8.1.

Close Command

The Close command will end any current CWMP session.

The Close command was added in CDRouter 8.1.

Delay and DelaySeconds Commands

The Delay and DelaySeconds commands can be used to insert an arbitrary delay anywhere within the scenario file. This can be useful for investigating timing issues between successive RPCs.

CWMP Delay_example {
   # Pause for 60 seconds
   Delay 60000

   # Pause for 60 seconds
   DelaySeconds 60
}

The Delay command was added in CDRouter 9.0. The DelaySeconds command was added in CDRouter 12.11.

Log command

The Log command can be used to insert a user defined message into the log file. This command can be used anywhere within a scenario file.

CWMP log_example {
   Log "Here is an SPV for parameter X"
}

The Log command was added in CDRouter 9.0.

Event command

The Event command can be used to make the ACS wait for one or more specific CWMP Event Codes in the next Inform message sent by the DUT.

Event {
    code <Event code>
    timeout <seconds>
    verify <parameter> <value>
}

code The code argument is used to specify the Event Code to wait for. If multiple code arguments are specified, all Event Codes must be received in the same Inform message. A separate pass/fail result will be reported for each one. Any additional Event Codes received in the Inform message will be silently ignored.
```
Reboot
Close
Event {
    code "1 BOOT"
    code "M Reboot"
}
```
timeout The optional timeout argument can be used to specify how many seconds the ACS should wait for the event to occur. By default CDRouter will wait 300 seconds for an event to occur. If the event specified by code is not received within the timeout period, the Event command will FAIL.
```
Event {
      code "8 DIAGNOSTICS COMPLETE"
      timeout 120
}
```
verify The verify argument can be used to verify a specific parameter was included in in the Inform, and that the parameter has a specific value. The verify argument supports all the special values allowed by the verify argument in the GetParameterValues command.
```
Event {
    code "4 VALUE CHANGE"
    timeout 300
    verify Device.DeviceInfo.UpTime [ regexp {[0-9]+} ]
    verify Device.ManagementServer.URL [any]
    verify Device.ManagementServer.SoftwareVersion 52.3.18
}
```

Download command

The Download command can be used to send a TR-069 Download RPC request that specifies a URL for the DUT to download. The request also specifies what type of file the URL points to (eg. “firmware” or “config”). A “PASS” or “FAIL” will result depending on whether the DUT accepts or rejects the request.

If the DUT accepts the Download request, it will send a DownloadResponse to the ACS and attempt to fetch the specified URL. It will then report the result back to the ACS in a TransferComplete message when it has finished.

CDRouter will dynamically create a file server to handle all file transfers from the DUT. The file server will use the same address family and transport settings that ACS uses when communicating with the DUT. For example, if acsTransport is “https” and acsIp is an IPv6 address, then the file server will also use https and IPv6.

https://[3001:cafe:1::ff]:443/download/device_firmware_v1.3.bin

Note, the Download command is only used to send the Download RPC request and verify if the DownloadResponse was successful. The TransferComplete scenario command can then be used to verify whether the DUT was able to successfully fetch the URL.

Download {
    filetype       firmware
    filepath       /usr/cdrouter-data/custom/firmware/device_firmware_v1.3.bin
    faultcode      0
    delayseconds   0
    commandkey     "scenario download"
}

TransferComplete {
    faultcode    0
    timeout      30
    commandkey   "scenario download"
}

See the TransferComplete command below for details on processing TransferComplete messages from the DUT.

filetype
The filetype argument may be “firmware” or “config”, or any of the literal FileType enumerations specified in Sec A.3.2.8 of the TR-069 specification.
```
filetype firmware
filetype config
filetype "1 Firmware Upgrade Image"
filetype "2 Web Content"
filetype “3 Vendor Configuration File”
filetype “4 Tone File”
filetype “5 Ringer File”
filetype “6 Stored Firmware Image”
filetype "X <VENDOR> <Vendor-specific identifier>"
```
Any other string may be specified with this argument in order to test invalid Download FileType scenarios (see faultcode argument below).
filepath
The filepath argument specifies the full path to a file that the DUT will be directed to download. If this argument is not specified, CDRouter will create a Download URL with a dummy filename. An invalid file path may be used along with the TransferComplete command to test unsuccessful download scenarios.
```
Download {
    filetype firmware
    filepath /usr/cdrouter-data/custom/firmware/device_firmware_v1.3.bin
}
```
delayseconds
The optional delayseconds argument specifies the length of time that the DUT should wait before fetching the URL specified in the Download request. If not specified, the DUT should attempt to retrieve the file immediately.
faultcode
The optional faultcode argument can be used to indicate that the DUT is expected to reject the Download request from the ACS and return a CWMP Fault instead of aDownloadResponse. If this argument is specified, the Download command will “FAIL” if the DUT accepts the Download request or sends a CWMP Fault response with a different FaultCode value than expected.
```
Download {
    filetype "Invalid_File_Type"
    filepath /usr/cdrouter-data/custom/firmware/device_firmware_v1.3.bin
    faultcode 9003
}
```
The conditions that cause a Download request to be rejected are device-dependent and out of scope for this guide. See Sec A.3.2.8 of the TR-069 specification for information on possible causes of failures.
url
The optional url argument can be used to provide a custom URL to be used in the Download request sent to the DUT. In this case, the filepath argument will be ignored. This can be useful for providing alternative URL formats (eg. using domain names instead of IP addresses) to validate the DUT’s URL parsing. This argument can be used With the CDRouter ICS feature to download a URL from a remote server on a live network or the Internet.
```
Download {
    filetype  firmware
    url       https://myfileserver.cdroutertest.com/download/firmware_v1.bin
}
```
commandkey
The optional commandkey argument can be used to specify a unique string to be included in the Download request. The DUT should include this string in the corresponding TransferComplete message when the file transfer has been completed. The TR-069 specification limits the CommandKey string to 32 characters. Sending strings longer than this maximum may cause the DUT to reject the Download request.

Upload command

The Upload command can be used to send a TR-069 Upload RPC request that specifies a URL for the DUT to upload files to. The request also specifies what type of file the DUT should upload (eg. “config” or “log”). A “PASS” or “FAIL” will result depending on whether the DUT accepts or rejects the request.

If the DUT accepts the Upload request, it will send a UploadResponse to the ACS and attempt to upload its file to the specified URL. It will then report the result back to the ACS in a TransferComplete message when it has finished.

https://[3001:cafe:1::ff]:443/upload/device_log_file.txt

Note, the Upload command is only used to send the Upload RPC request and verify if the UploadResponse was successful. The TransferComplete scenario command can then be used to verify whether the DUT was able to successfully fetch the URL.

Upload {
    filetype       config
    filepath       /usr/cdrouter-data/custom/upload/device_log_file.txt
    faultcode      0
    delayseconds   0
    commandkey     "scenario download"
}

TransferComplete {
    faultcode    9010
    timeout      30
    commandkey   "scenario download"
}

See the TransferComplete command below for details on processing TransferComplete messages from the DUT.

filetype
The filetype argument may be “config” or “log”, or any of the literal FileType enumerations specified in Sec A.4.1.5 of the TR-069 specification.
```
filetype config
filetype log
filetype “1 Vendor Configuration File”
filetype “2 Vendor Log File”
filetype “3 Vendor Configuration File <i>”
filetype “4 Vendor Log File <i>”
```
Any other string may be specified with this argument in order to test invalid Upload FileType scenarios (see faultcode argument below).
filepath
The filepath argument specifies the full path (including file name) on the local system where the ACS will save the uploaded file. If this argument specifies a file that already exists, that file will automatically be overwritten with the file uploaded by the DUT.

DUT will be directed to download. If this argument is not specified, CDRouter will create an Upload URL with a dummy filename. An invalid file path may be used along with the TransferComplete command to test unsuccessful download scenarios.
```
Upload {
    filetype log
    filepath /usr/cdrouter-data/custom/uploads/device_log_file.txt
}
```
delayseconds
The optional delayseconds argument specifies the length of time that the DUT should wait before uploading its file to the URL specified in the Upload request. If not specified, the DUT should attempt to upload the file immediately.
faultcode
The optional faultcode argument can be used to indicate that the DUT is expected to reject the Upload request from the ACS and return a CWMP Fault instead of aUploadResponse. If this argument is specified, the Upload command will “FAIL” if the DUT accepts the Upload request or sends a CWMP Fault response with a different FaultCode value than expected.
```
Download {
    filetype "Invalid_File_Type"
    filepath /usr/cdrouter-data/custom/uploads/device_log_file.txt
    faultcode 9003
}
```
The conditions that cause an Upload request to be rejected are device-dependent and out of scope for this guide. See Sec A.4.1.5 of the TR-069 specification for information on possible causes of failures.
url
The optional url argument can be used to provide a custom URL to be used in the Upload request sent to the DUT. In this case, the filepath argument will be ignored. This can be useful for providing alternative URL formats (eg. using domain names instead of IP addresses) to validate the DUT’s URL parsing. This argument can be used With the CDRouter ICS feature to upload to a URL at a remote server on a live network or the Internet.
```
Download {
    filetype  firmware
    url       https://myfileserver.cdroutertest.com/upload/device_log_file.txt
}
```
commandkey
The optional commandkey argument can be used to specify a unique string to be included in the Upload request. The DUT should include this string in the corresponding TransferComplete message when the file transfer has been completed. The TR-069 specification limits the CommandKey string to 32 characters. Sending strings longer than this maximum may cause the DUT to reject the Upload request.

TransferComplete command

The TransferComplete command can be used to verify the details received in a TransferComplete RPC message from the DUT following file transfer initiated by a prior Download or Upload command. The CWMP scenario script file must specify TransferComplete commands in the order they are expected to be received from the DUT. This may not always be possible if file transfers from multiple prior Download and Upload commands are being reported at the same time.

TransferComplete {
    faultcode    0
    timeout      30
    commandkey   "scenario download"
}

faultcode
The faultcode argument specifies the FaultCode value that the DUT is expected to send. A code of “0” indicates that the file transfer was successful.
timeout The optional timeout argument can be used to specify how long CDRouter should wait for the DUT to send the TransverComplete message to the ACS. If this is not specified, the value of the tr69DownloadTimeout testvar is used.
commandkey
The commandkey argument specifies the CommandKey string that the DUT is expected to send. The CommandKey in the TransferComplete message should match the string sent by the ACS in the corresponding Download or Upload request.

Run a single scenario from the CWMP scenario file

Rather than running all CWMP scenarios defined in the scenario file all at once, it is possible to run the scenarios one at a time by setting the following testvar:

testvar cwmpScenarioSingleMode   yes

If set to yes, then only a single CWMP scenario will be run for each iteration of the cwmp_scenario_1 test. If the CDRouter test package is defined such that the cwmp_scenario_1 test is repeated or looped, then each iteration of the cwmp_scenario_1 test will run a subsequent scenario.

This feature was added in CDRouter 8.1.

Product

Search Results

TR-069 CWMP Scenario Scripting Guide

Scenario Script Format

Simple Examples

Scenario Commands

GetParameterValues Command

SetParameterValues Command

GetParameterAttributes Command

SetParameterAttributes Command

AddObject Command

DeleteObject Command

GetParameterNames Command

Reboot Command

Open Command

Close Command

Delay and DelaySeconds Commands

Log command

Event command

Download command

Upload command

TransferComplete command

Run a single scenario from the CWMP scenario file