THOMSON TR-069 Configuration Manual
Power
E
th
ern
et
W
LA
N
Plug-in
ISDN
Internet
DSL
TR-069 Configuration Guide
R7.4 and higher
Thomson Gateway
Thomson Gateway
TR-069 Configuration Guide
R7.4 and higher
Copyright
Copyright ©1999-2008 Thomson. All rights reserved.
Distribution and copying of this document, use and communication of its contents is not permitted without written authorization
from Thomson. The content of this document is furnished for informational use only, may be subject to change without notice,
and should not be construed as a commitment by Thomson. Thomson assumes no responsibility or liability for any errors or
inaccuracies that may appear in this document.
Thomson Telecom Belgium
Prins Boudewijnlaan, 47
B-2650 Edegem
Belgium
http://www.thomson-broadband.com
Trademarks
The following trademarks may be used in this document:
DECT is a trademark of ETSI.
Bluetooth® word mark and logos are owned by the Bluetooth SIG, Inc.
Ethernet™ is a trademark of Xerox Corporation.
Wi-Fi®, WMM® and the Wi-Fi logo are registered trademarks of the Wi-Fi Alliance®. "Wi-Fi CERTIFIED", "Wi-Fi ZONE",
"Wi-Fi Protected Access", "Wi-Fi Multimedia", "Wi-Fi Protected Setup", WPA", WPA2" and their respective logos are trademarks of the Wi-Fi Alliance®.
UPnP™ is a certification mark of the UPnP™ Implementers Corporation.
Microsoft®, MS-DOS®, Windows®, Windows NT® and Windows Vista® are either registered trademarks or trademarks
of Microsoft Corporation in the United States and/or other countries.
Apple® and Mac OS® are registered trademarks of Apple Computer, Incorporated, registered in the United States and
other countries.
UNIX® is a registered trademark of UNIX System Laboratories, Incorporated.
Adobe®, the Adobe logo, Acrobat and Acrobat Reader are trademarks or registered trademarks of Adobe Systems, Incor-
porated, registered in the United States and/or other countries.
Other brands and product names may be trademarks or registered trademarks of their respective holders.
Document Information
Status: v1.0 (May 2008)
Reference: E-DOC-CTC-20071119-0003
Short Title: Config Guide: TR-069 R7.4 and higher
E-DOC-CTC-20071119-0003 v1.0
i
Contents
About this TR-069 Configuration Guide ................................... 1
1 Introduction.................................................................................. 3
1.1 References and Related Documents ............................................................... 4
1.2 CWMP Transaction Sessions ........................................................................... 6
1.3 IGD Data model on the Thomson Gateway ................................................... 10
2 Configuring CWMP on the Thomson Gateway ...................... 13
2.1 Configuring TLS ............................................................................................ 14
2.1.1 TLS Client .............................................................................................................................................. 15
2.1.2 TLS Certificates .....................................................................................................................................16
2.2 Configuring CWMP........................................................................................ 18
2.2.1 CWMP Service Manager ......................................................................................................................19
2.2.2 CWMP Daemon as seen from the ACS............................................................................................... 21
2.2.3 CWMP Daemon towards the ACS.......................................................................................................24
2.2.4 Notification Rules .................................................................................................................................25
2.2.5 Runtime Variables ................................................................................................................................26
2.3 Configuring State Checks ............................................................................. 28
3 Firmware Upgrade and Configuration Update ....................... 31
3.1 Firmware Upgrade......................................................................................... 32
3.1.1 General Firmware Upgrade Mechanism ............................................................................................33
3.1.2 Single Memory Bank Firmware Upgrade...........................................................................................35
3.1.3 Dual Memory Bank Firmware Upgrade ..............................................................................................37
3.1.4 Firmware Upgrade with Reduced Memory Mode .............................................................................39
3.2 Configuration Update ................................................................................... 41
3.2.1 Configuration Update Mechanism......................................................................................................42
3.2.2 STS Files................................................................................................................................................44
3.2.3 Embedded STS (eSTS) Files................................................................................................................ 46
4 Monitoring and Diagnostics ..................................................... 47
4.1 View on Home Network ................................................................................ 48
4.2 Diagnostics ................................................................................................... 50
4.3 IP Ping Diagnostics Test ............................................................................... 54
E-DOC-CTC-20071119-0003 v1.0
ii
Contents
4.4 Retrieval of the Device Log ........................................................................... 56
4.5 Event Subscription ........................................................................................ 57
5 WAN Connections .....................................................................59
5.1 WAN Connection Device ............................................................................... 61
5.2 WAN PPP or IP Connection ........................................................................... 62
5.3 Connection Information ................................................................................ 65
5.4 Forwarding Entries........................................................................................ 66
6 Service Provisioning.................................................................. 69
6.1 VoIP ............................................................................................................... 70
6.2 WLAN ............................................................................................................ 73
6.3 Time .............................................................................................................. 76
6.4 DHCP Conditional Serving ............................................................................ 77
6.5 Queue Management ...................................................................................... 79
6.6 Stateful Inspection Firewall .......................................................................... 81
6.7 Access Rights................................................................................................ 85
6.8 NAT Application List ..................................................................................... 87
6.9 Dynamic DNS ................................................................................................ 90
6.10 Remote Access (Remote Assistance) ............................................................ 93
6.11 Parental Control ............................................................................................ 95
6.12 VLAN Provisioning (Layer2Bridging) ............................................................. 97
7 Zero-Provisioning ....................................................................101
E-DOC-CTC-20071119-0003 v1.0
1
About this TR-069 Configuration Guide
About this TR-069 Configuration Guide
Used Symbols
Terminology
Generally, the Thomson Gateway123 will be referred to as Wireless USB Adaptor in this TR-069 Configuration
Guide.
Typographical Conventions
Following typographical convention is used throughout this manual:
Sample text indicates a hyperlink to a Web site.
Example: For more information, visit us at www.thomson-broadband.com
.
Sample text indicates an internal cross-reference.
Example: If you want to know more about guide, see “1 Introduction” on page 7”.
Sample text indicates an important content-related word.
Example: To enter the network, you must authenticate yourself.
Sample text indicates a GUI element (commands on menus and buttons, dialog box elements, file
names, paths and folders).
Example: On the File menu, click Open to open a file.
Documentation and software updates
Thomson continuously develops new solutions, but is also committed to improving its existing products.
For more information on Thomson's latest technological innovations, documents and software releases, visit
us at http://www.thomson-broadband.com
.
A note provides additional information about a topic.
A caution warns you about potential problems or specific precautions that need to be taken.
E-DOC-CTC-20071119-0003 v1.0
2
About this TR-069 C
onfiguration Guide
Overview
This TR-069 Configuration Guide provides technical information on TR-069 and how this relates to the
various Thomson Gateway products. In the first chapter, a brief introduction to the TR-069 CWMP protocol
and the TR-098 IGD data model is presented. The following chapter gives detailed information on the
configuration of CWMP on the Thomson Gateway using CLI commands. The last chapters focus on the
different use cases that are currently supported using CWMP.
This document is structured as follows:
Topi c Page
“1 Introduction” 3
“2 Configuring CWMP on the Thomson Gateway” 13
“3 Firmware Upgrade and Configuration Update” 31
“4 Monitoring and Diagnostics” 47
“5 WAN Connections” 59
“6 Service Provisioning” 69
“7 Zero-Provisioning” 101
E-DOC-CTC-20071119-0003 v1.0
3
1| Introduction
1 Introduction
Introduction
This chapter provides a short introduction to the TR-069 CWMP protocol and the TR-098 IGD data model.
Overview
This chapter is structured as follows:
Topi c Page
“1.1 References and Related Documents” 4
“1.2 CWMP Transaction Sessions” 6
“1.3 IGD Data model on the Thomson Gateway” 10
E-DOC-CTC-20071119-0003 v1.0
4
1| Introduction
1.1 References and Related Documents
TR-069: CPE WAN Management Protocol (CWMP)
TR-069 specifies the CWMP protocol, which is used for remote management of CPE devices. The Thomson
Gateway supports CWMP. This allows the Thomson Gateway to be configured and monitored from a
management application running on a remote Auto-Configuration Server (ACS).
For more information on CWMP, see:
Technical Report “TR-069 - CPE WAN Management Protocol”, DSL Forum, May 2004.
Technical Report “TR-069 Amendment 1 - CPE WAN Management Protocol”, DSL Forum, November
2006.
TR-098: Internet Gateway Device (IGD) Data Model
TR-098 specifies the InternetGatewayDevice data model for TR-069 enabled devices. The Thomson Gateway
supports the IGD data model. This data model is a set of parameters, modelled in a tree structure, that can be
managed using CWMP.
For more information on the IGD data model, see:
Technical Report “TR-098 - Internet Gateway Device Version 1.1 Data Model for TR-069”, DSL Forum,
September 2005.
Technical Report “TR-098 Amendment 1 - Internet Gateway Device data model for TR-069”, DSL Forum,
November 2006.
Related documents
Several DSL-Forum documents are related to TR-069 and TR-098, specifying data models for devices other
than an IGD (for example STB, PCs, NAS), or specifying extensions of the IGD data model.
Following specifications are relevant to this configuration guide:
TR-064 “LAN-side DSL CPE configuration”, May 2004: this document provides a standard interface for
PC-based (LAN-side) install applications. It defines LAN-side CPE configuration.
TR-104 “Provisioning parameters for VoIP CPE”, September 2005: this document defines a generic
VoiceService data model for provisioning of VoIP CPEs, for example an Integrated Access Device (IAD) or
an Analogue Telephone Adapter (ATA). The model supports SIP, MGCP and H323 signalling protocols.
TR-106 Amendment 1 “Data model template for TR-069 enabled devices”, November 2006: this
document defines a Device data model for any TR-069 enabled LAN device that is not an IGD. This model
supports the DeviceSummary parameter.
TR-111 “Applying TR-069 to remote management of home networking devices”, December 2005: this
document defines two mechanisms that extend TR-069 with remote management of LAN devices behind
an Internet Gateway.
LAN Device-gateway association: this mechanism allows an ACS managing a LAN device to identify
the associated gateway through which that device is connected. The gateway and LAN device
exchange their device identity (OUI-product class-serial number) via DHCP option 125.
Connection Request via NAT gateway: this mechanism allows an ACS to initiate a TR-069 session
with a LAN device that is operating behind a NAT gateway. STUN (Simple Traversal of UDP through
NAT) is used between the LAN device and the ACS.
In addition, extensions to the Device and InternetGatewayDevice data models are defined.
WT-107 “Internet Gateway Device data model (TR-098 issue 2)”, September 2006: this document extends
the IGD data model with DHCP conditional serving, HPNAv3, MoCA, 802.1X,...
WT-135 “Data model for TR-069 enabled STB”: this document defines a STBDevice data model for a STB
(Set-Top Box) CPE as an extension of TR-069.
E-DOC-CTC-20071119-0003 v1.0
5
1| Introduction
WT-140 “TR-069 data model for storage service enabled devices”: this document defines a
StorageService data model for a device that maintains a storage service, such as a Network Attached
Storage (NAS) device, as an extension of TR-069.
PD-128 version 6 “Interoperability test plan for TR-069 plugfests”, June 2006: this document defines
TR-069 tests and their expected outcome. These tests are used during the TR-069 plugfests as tests to
perform. The DSL Forum regularly organizes TR-069 plugfest test events where all participating CPE
devices can test against all participating ACS servers. The document is also the de facto reference for
TR-069 testing by customers and ACS vendors.
Architecture
Following illustration shows the location of the specifications in the CWMP architecture:
Thomson firmware is interoperability tested with and by ACS partners.
ACS
DSLAM BRAS ACS
Access
Network
CPE
IP
Network
TR-069 CWMP (Am.1)
Provid
er
Helpde
sk
CPE
CPE
CPE
TR-064
LAN CPE Auto-Configuration
WT-135
S
TB Model
TR-104
VoIP Model
TR-098 (Am.1)
IGD Model
TR-111 CWMP
for home devices
TR-106 CWMP enabled
device model template
WT-140
Network Storage Model
E-DOC-CTC-20071119-0003 v1.0
6
1| Introduction
1.2 CWMP Transaction Sessions
What is a transaction session?
TR-069 defines a transaction session as a sequence of Remote Procedure Calls (RPCs), both requests and
responses. A transaction session is completed when both parties (CPE and ACS) have no messages left to
send.
The CPE has an important role:
All transaction sessions are established by the CPE.
The CPE maintains a TCP connection (persistent HTTP connection) for the duration of the session.
The CPE is also responsible for closing a transaction session.
Session establishment
All transaction sessions are established by the CPE, by sending an Inform RPC to the ACS.
We distinguish two types of transaction sessions:
CPE initiated sessions
Asynchronous ACS initiated sessions: the CPE establishes a transaction session to the ACS after receipt
of a Connection Request from the ACS.
E-DOC-CTC-20071119-0003 v1.0
7
1| Introduction
Inform events
The Inform RPC contains the Inform event argument, to indicate the cause(s) of the transaction session
establishment.
Following table gives an overview of the different Inform events and their use:
Initial handshake
The initial handshake between the CPE and the ACS takes place when the CPE contacts the ACS for the very
first time or due to a change of the ACS URL.
Following actions are taken during the initial handshake:
The CPE sends an initial Inform RPC with the “0 BOOTSTRAP” event.
The CPE authenticates itself to the ACS.
The ACS requests the list of methods that are supported by the CPE using the GetRPCMethods RPC.
The ACS activates the required services on the CPE, according to the “activation policies”. For example,
the ACS configures the voice service and wireless service.
Forced reboot
The Reboot RPC causes the CPE to reboot. This forced reboot might be desired to restart the Thomson
Gateway clearing all state.
Event Description
0 BOOTSTRAP The first time that the CPE contacts the ACS.
1BOOT After a power up or reset of the CPE.
2 PERIODIC The session is established on a periodic Inform interval.
3 SCHEDULED Scheduled by a ScheduleInform RPC.
4 VALUE CHANGE The value of a parameter of the Inform ParameterList argument
changed. This can be a parameter that is marked by the ACS for
notification (either active or passive) or a change of one of following
parameters:
InternetGatewayDevice.DeviceInfo.SoftwareVersion
InternetGatewayDevice.DeviceInfo.ProvisioningCode
InternetGatewayDevice.ManagementServer.ConnectionRequestURL
InternetGatewayDevice.WANDevice.{i}.WANConnectionDevice.{j}.
WAN{*}Connection.{k}.ExternalIPAddress
6 CONNECTION REQUEST The session is established due to an asynchronous connection request
from the ACS.
7 TRANSFER COMPLETE Indicates the completion of a Download (or Upload). The
TransferComplete RPC is called during this transaction session.
8 DIAGNOSTICS COMPLETE Completion of one or more diagnostics tests (e.g. IPPingDiagnostics)
M <method name> The Inform RPC is triggered by another RPC method (M = Master):
Reboot
Download
ScheduleInform
Upload (optional)
E-DOC-CTC-20071119-0003 v1.0
8
1| Introduction
When the CPE receives a Reboot RPC from the ACS, following steps are executed:
1 The ongoing transaction session is finalized. This means that all outstanding requests are sent and all
responses are received. After finalization, the ongoing transaction session is closed.
2 The CommandKey argument of the Reboot message must be remembered across the reboot via either:
Writing it to the memory prozone. This is a memory protected zone that is not reinitialized after a
“warm” reboot.
Writing it to the configuration file (user.ini).
3 A “warm” reboot is triggered.
4 After reboot, an Inform message is sent. The Event argument contains:
EventCode: “1 BOOT”, “M Reboot” and possibly other EventCodes.
CommandKey: the value of the CommandKey argument of the Reboot message is sent as
CommandKey for the EventCode “M Reboot”.
Session re-establishment
In some cases, the TCP connection is closed before the transaction session is completed. For example, the
session is interrupted by the ACS. If necessary, the CPE re-establishes the TCP connection to the ACS.
In this case, the Inform RPC contains:
Inform event: if the session is re-established because of a pending TransferComplete RPC to be sent to
the ACS, the Inform event is “7 TRANSFER COMPLETE”. In other cases, the Inform message contains the
undelivered Inform events from the interrupted session.
Cookie: the Inform message includes the transaction Cookie (if received from the ACS during the
transaction session) as HTTP header field.
Factory reset
The FactoryReset RPC resets the CPE to its factory default state. When a problem occurs and the cause is not
found, a reset to (pre-provisioned) ISP defaults via the FactoryReset RPC triggers the zero-provisioning use
case. Although some user configuration might be lost, a reset to factory defaults guarantees autoconfiguration and service activation as described in the “Zero-provisioning” use case.
When the CPE receives a FactoryReset RPC from the ACS, following steps are executed:
1 The ongoing transaction session is finalized. This means that all outstanding requests are sent and all
responses are received. After finalization, the ongoing transaction session is closed.
2 A reset to factory defaults is triggered.
1 The user configuration file (user.ini) is deleted.
2 A configuration load is performed: in absence of the user configuration file, the service provider
defaults (ISP.def) are loaded. In absence of these service provider defaults, factory defaults are
loaded.
Download
The Download RPC may be used by an ACS to cause the CPE to download a specified file from the designated
location.
When the CPE receives a Download RPC from the ACS, following steps are executed:
1 A DownloadResponse RPC is sent with Status argument set to 1 (the download is not yet completed).
2 The ongoing transaction session is closed.
3 Whether or not steps are executed before the file transfer, depends on the FileType argument of the
Download RPC. For more information, see “3.1 Firmware Upgrade” on page 32 and “3.2 Configuration
Update” on page 41.
E-DOC-CTC-20071119-0003 v1.0
9
1| Introduction
4 File transfer is initiated: a HTTP GET message is sent by the CPE to the file server.
5 File transfer is completed (or an error occurred).
6 A new transaction session to send the TransferComplete RPC is established after loading the downloaded
configuration file or firmware image. The exact steps depend on the FileType argument of the Download
RPC. For more information, see “3.1 Firmware Upgrade” on page 32 and “3.2 Configuration Update” on
page 41.
The Download RPC can also be triggered from the CLI. To this end, use the CLI command
:software download and provide the requested Download RPC parameters (filetype, url,
username, password, filesize, targetfilename).
E-DOC-CTC-20071119-0003 v1.0
10
1| Introduction
1.3 IGD Data model on the Thomson Gateway
Data model overview
Following illustration shows the IGD data model on the Thomson Gateway with (multiple instance) devices
and services:
InternetGatewayDevice
Layer3Forwarding
Service
DeviceConfig
Service
X_000E50_AccessRights
Service
ManagementServer
Service
Time
Service
UserInterface
Service
QueueManagement
Service
WANDevice
WANCommonInterfaceConfig
Service
LANDevice
WAN***InterfaceConfig
Service
WANConnectionDevice
WAN*LinkConfig
Service
LANDevice
Hosts
Service
* DSL, Ethernet
** IP, PPP
*** DSL, Ethernet
**** Ethernet, USB
LANHostConfigManagement
Service
DeviceInfo
Service
Layer2Bridging
Service
IPPingDiagnostics
Service
WAN**Connection Service
LAN****InterfaceConfig Service
WLANConfiguration Service
Services
X_000E50_Firewall
Service
X_000E50_Connection
Service
X_000E50_NATApplicationList
Service
X_000E50_DynamicDNS
Service
X_000E50_RemoteAccess
Service
X_000E50_ParentalControl
Service
VoiceService
Capabilities
Service
VoiceProfile Service
X_000E50_UAMapping
Service
PhyInterface Service
E-DOC-CTC-20071119-0003 v1.0
11
1| Introduction
Objects and parameters
The data model is a set of parameters, modelled in a tree structure. In this tree structure, an object is a
container for other objects and/or parameters.
Vendor specific objects and parameters
The name of a vendor specific parameter or object, not contained within another vendor specific object, has
the form X_<VENDOR>_VendorSpecificName. Names of parameters and objects within another vendor
specific object must not be prefixed.
<VENDOR> is a unique vendor identifier, which can be either an OUI (Organizationally Unique Identifier) or a
domain name. This OUI or domain name must be assigned to the organization that defined the parameter,
which is not necessarily the same as the vendor of the CPE or ACS.
For vendor specific parameters of the Thomson Gateway, i.e. Thomson Gateway proprietary parameters,
<VENDOR> has value 000E50.
Path names
To identify a parameter or object in the data model, path names are used. Both complete and partial path
names are supported:
Complete path name: a complete path name is the name of a parameter.
For example “InternetGatewayDevice.DeviceInfo.SoftwareVersion”.
Partial path name: a partial path name ends with a “.” (dot) and is the name of an object. If multiple
instances of an object can exist, the object name is followed by the place holder “{i}.”. To identify a single
object instance, this place holder must be replaced by an instance number.
For example “InternetGatewayDevice.DeviceInfo.” or “InternetGatewayDevice.WANDevice.{i}.”.
To identify the full data model tree, use the partial path name “InternetGatewayDevice.”.
Following illustration shows some examples:
InternetGatewayDevice.DeviceInfo.SoftwareVersion
Object
Object
Parameter
InternetGatewayDevice.WANDevice.1.WANConnectionDevice.1.WANPPPConnection.1.ExternalIPAddress
Object
Object instance
Parameter
Object instance
Object instance
E-DOC-CTC-20071119-0003 v1.0
12
1| Introduction
E-DOC-CTC-20071119-0003 v1.0
13
2| Configuring CWMP on the Thomson Gateway
2 Configuring CWMP on the Thomson Gateway
Introduction
This chapter describes in detail the configuration of CWMP on the Thomson Gateway using CLI commands.
This includes the configuration of the TLS/SSL client and certificates, the CWMP service manager and
daemon, and the state checks to detect service activity.
Overview
This chapter is structured as follows:
CWMP is not configurable via the GUI (Graphical User Interface).
Topi c Page
“2.1 Configuring TLS” 14
“2.2 Configuring CWMP” 18
“2.3 Configuring State Checks” 28
E-DOC-CTC-20071119-0003 v1.0
14
2| Configuring CWM
P on the Thomson Gatew
ay
2.1 Configuring TLS
Introduction
The use of TLS/SSL is optional.
Whether or not to use TLS/SSL is derived form the ACS URL scheme or file URL scheme:
If the URL scheme starts with https://, TLS/SSL is used.
If the URL scheme starts with http://, TLS/SSL is not used.
To display the transport protocol and port used by the HTTP and HTTPS services, execute following
commands:
Overview
This section is structured as follows:
=>:service system list name=HTTP
Idx Name Protocol SrcPort DstPort Group State
---------------------------------------------------------------------------------
1 HTTP tcp 80 enabled
=>:service system list name=HTTPs
Idx Name Protocol SrcPort DstPort Group State
---------------------------------------------------------------------------------
1 HTTPs tcp 443 enabled
Topi c Page
“2.1.1 TLS Client” 15
“2.1.2 TLS Certificates” 16
E-DOC-CTC-20071119-0003 v1.0
15
2| Configuring CWMP on the Thomson Gateway
2.1.1 TLS Client
Displaying the TLS client configuration
To display the configuration of the TLS client, execute following command:
Configuring the TLS client
To configure the TLS client, execute the command :tls acs-client config and specify one or more of
following parameters:
State: this parameter indicates the state of the TLS client. By default, the TLS client is enabled.
Auth-serv: if this parameter is enabled, the TLS client (Thomson Gateway) requests authentication of the
TLS server (ACS). By default, this parameter is enabled.
Valid-date: if this parameter is enabled, the TLS client checks the validity of the date of a received
certificate.
Valid-domain: if this parameter is enabled, the TLS client checks the domain of a received certificate.
For example, configure the TLS client as follows:
=>:tls acs-client config
SSL/TLS client for ACS state : enabled
Request server authentication : enabled
Check certificate validity date : disabled
Check certificate domain : disabled
=>:tls acs-client config state=enabled auth-serv=enabled valid-date=enabled
valid-domain=enabled
E-DOC-CTC-20071119-0003 v1.0
16
2| Configuring CWM
P on the Thomson Gatew
ay
2.1.2 TLS Certificates
TLS certificate validation
The Thomson Gateway supports two types of TLS/SSL authentication via certificate validation:
Client authentication: if the Thomson Gateway (TLS client) is requested by the ACS (TLS server) to send
its certificate, the Thomson Gateway must reply with its own certificate. Client authentication may be
useful if the ACS needs to send sensitive data to the Thomson Gateway.
Server authentication: the Thomson Gateway (TLS client) is responsible for checking the ACS (TLS
server) identity. Requesting the ACS to authenticate makes sure the Thomson Gateway connects to a
trusted ACS. This avoids malicious people to connect to the Thomson Gateway and reconfigure the
whole device.
Server authentication requires ACS certificate validation: the Thomson Gateway receives a server
certificate and validates this with a pre-provisioned CA (Certificate Authority) certificate.
TLS authentication via certificate validation is not supported for TLS/SSL between the Thomson Gateway and
the file server.
Listing Thomson Gateway certificate information
Only one certificate is used for client authentication.
This certificate can only be altered through file upload (using FTP or TR-069). If no certificate is found when
the Thomson Gateway is booting, it generates its own certificate and private/public key pair. The Thomson
Gateway signs the certificate using its own private key.
To display the certificate of the Thomson Gateway, execute following command:
=>:tls self cert list expand=enabled
1Subject : /CN=SpeedTouch 780/O=THOMSON/OU=0639JT008
Not Before : Jan 1 00:00:00 2005 GMT
Not After : Dec 31 00:00:00 2024 GMT
Issuer : /CN=SpeedTouch 780/O=THOMSON/OU=0639JT008
Key Strength : 1024 bit
Certificate : /dl/tls/cert0001.pem
-----BEGIN CERTIFICATE----MIIB9TCCAV6gAwIBAgIEirL3QTANBgkqhkiG9w0BAQUFADA/MRcwFQYDVQQDEw5T
cGVlZFRvdWNoIDc4MDEQMA4GA1UEChMHVEhPTVNPTjESMBAGA1UECxMJMDYzOUpU
MDA4MB4XDTA1MDEwMTAwMDAwMFoXDTI0MTIzMTAwMDAwMFowPzEXMBUGA1UEAxMO
U3BlZWRUb3VjaCA3ODAxEDAOBgNVBAoTB1RIT01TT04xEjAQBgNVBAsTCTA2MzlK
VDAwODCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAzzFG44ShTLd8mq8iGrsG
adtKkVJlgaL0DIykw4Tq++hanq6or0xVb51Vjn3spuVckZTvoMt+NZg9B8xAjP1V
v5gQcNFv3lmeB7x0Gcfcf5cCSGFlQ+eq7OLh3a9nVO0BPx3wcSBZ3hcxJtRaPzCU
r6kW3aVe/3JRle9MuzhKZTsCAwEAATANBgkqhkiG9w0BAQUFAAOBgQCU7J7L7n/c
Pony41ik6c7kXubwSsg0MRFxLVtkIlcVAc0rcY3CWA0Qd5l9ofP9+bkLeOTE8b54
3f94bsydlIUmh/8xBgcRxOSH9Ws06Dhp3RMwgmTzotl0KSwSAIJRM9gV/uPlrZgx
CLYxODvcT5KyJlKIISVPhWVjYU3yTo0lLw==
-----END CERTIFICATE-----
E-DOC-CTC-20071119-0003 v1.0
17
2| Configuring CWMP on the Thomson Gateway
Listing ACS certificate information
The Thomson Gateway uses pre-provisioned certificates for server authentication.
To list the pre-provisioned certificates on the Thomson Gateway, execute the command
:tls acs-
client cert list
.
Optionally, two parameters can be specified:
Index: if this parameter is used, the displayed list is restricted to the certificate with the corresponding
certificate index.
Expand: if this parameter is enabled, more information is displayed. A base64 dump of each displayed
certificate is shown.
Pre-provisioning ACS certificates
The Thomson Gateway can receive the pre-provisioned certificates for server authentication as follows:
File upload: through file upload (using FTP or TR-069).
Proceed as follows when using FTP:
1 Set up an FTP session from your PC to the Thomson Gateway.
2 Go to the /dl directory with the command
cd /dl.
3 Put the certificate on the Thomson Gateway. The command
put <filename> transfers the file
with name <filename> from the PC directory C:\Documents and Settings\<Username>\ to the
Thomson Gateway directory /dl.
4 Close the FTP session with the command
bye.
Customization: usually, the Thomson Gateway is pre-provisioned with the correct ACS certificates using
a customized build. The process of embedding the correct certificates in a software build is executed by
Thomson during customization, prior to delivery.
Currently, these certificates are not customizable using the customization wizard, but must be added
manually to the software build by Thomson.
Configuring the list of trusted ACS certificates
To add a certificate to the list of trusted certificates, execute following command:
To delete a certificate from the list of trusted certificates:
=>:tls acs-client cert list expand=enabled
=>:tls acs-client cert add filename=<filename>
=>:tls acs-client cert delete index=<filename>
E-DOC-CTC-20071119-0003 v1.0
18
2| Configuring CWM
P on the Thomson Gatew
ay
2.2 Configuring CWMP
Introduction
The implementation of CWMP on the Thomson Gateway is split up in two parts:
CWMP service manager: use the service manager to:
Enable or disable the CWMP client.
Assign a specific QoS label and route label to traffic originated by the CWMP client.
Enable or disable the CWMP connection request server.
Configure the port used by the CWMP connection request server to receive connection requests.
Enable or disable logging of the CWMP connection request server.
Configure the NAT portmap weight of the CWMP connection request server.
CWMP daemon: use the daemon to configure all other aspects of the CWMP protocol, including:
Operational mode.
Use of Periodic Inform RPCs.
Use of Connection Requests.
Session termination.
Authentication user names and passwords.
Overview
This section is structured as follows:
Topi c Page
“2.2.1 CWMP Service Manager” 19
“2.2.2 CWMP Daemon as seen from the ACS” 21
“2.2.3 CWMP Daemon towards the ACS” 24
“2.2.4 Notification Rules” 25
“2.2.5 Runtime Variables” 26
E-DOC-CTC-20071119-0003 v1.0
19
2| Configuring CWMP on the Thomson Gateway
2.2.1 CWMP Service Manager
Introduction
CWMP services consist of two services:
CWMP-C: the CWMP client service. The CWMP client is responsible for establishing connections to the
ACS and for sending Inform RPCs. The CWMP client has a state machine to track RPCs and report their
result (for example via a TransferComplete RPC).
CWMP-S: the CWMP connection request server service. The CWMP connection request server listens on
a TCP port for connection requests, performs HTTP authentication and triggers the CWMP client to
establish a connection to the ACS.
CWMP client
To display the attribute values of the CWMP client service, execute following command:
You can configure the value of following attributes:
State: by default, the CWMP client service is disabled.
To enable the service, execute following command:
Qoslabel: the Thomson Gateway supports application-based QoS label assignment. If the value of this
attribute differs from
none, all CWMP client originated data automatically has a QoS label assigned. This
QoS label determines the internal QoS class of the data.
To assign a specific QoS label to all data, for example the label “Interactive”, execute following
command:
Routelabel: the Thomson Gateway supports application-based Route label assignment. If the value of
this attribute differs from
none, all CWMP client originated data automatically has a route label assigned.
This route label can be used for IP forwarding. This enables forwarding all CWMP traffic over a particular
IP interface.
To assign a specific route label to all data, for example the label “Interactive”, execute following
command:
=>:service system list name=CWMP-C expand=enabled
Idx Name Protocol SrcPort DstPort Group
--------------------------------------------------------------------------------1 CWMP-C tcp
Description................ CPE Wan Management Protocol Client
Properties................. client
Attributes................. state port srcip qoslabel routelabel
User Managed Attributes..... state qoslabel routelabel
Attribute Values :
State...................... (administratively) disabled
Port....................... 0
Source Ip Selection........ auto
QOS Label.................. Management
Route Label................ None
=>:service system modify name=CWMP-C state=enabled
=>:service system modify name=CWMP-C qoslabel=Interactive
=>:service system modify name=CWMP-C routelabel=Interactive
E-DOC-CTC-20071119-0003 v1.0
20
2| Configuring CWM
P on the Thomson Gatew
ay
CWMP connection request server
To display the default attribute values of the CWMP connection request server service, execute following
command:
You can configure the value of following attributes:
State: by default, the CWMP connection request server service is disabled.
To enable the service, execute following command:
Port: this attribute is the port on which the connection request server listens for connection requests. The
default port is 51005.
To assign another port number to the port, execute following command:
Log: this attribute is used to enable or disable service logging in the syslog message buffer. By default,
logging is disabled.
To enable logging of the service, execute following command:
Natpmweight: the NAT portmap weight for the service. By default, this attribute has value 30.
To change the value of this attribute, execute following command:
=>:service system list name=CWMP-S expand=enabled
Idx Name Protocol SrcPort DstPort Group
--------------------------------------------------------------------------------1 CWMP-S tcp 51005
Description................ CPE Wan Management Protocol Server
Properties................. server
Attributes................. state port aclip aclif aclifgroup map log qoslabel
routelabel natpmweight
User Managed Attributes..... state port log natpmweight
Attribute Values :
State...................... (administratively) disabled
Port....................... 51005
QOS Label.................. None
Route Label................ None
NAT Portmap Weight ........ 30
Ip Access List............. any
Interface Access List...... any
Interface Group Access List any
Map List................... 51005
Logging.................... disabled
=>:service system modify name=CWMP-S state=enabled
=>:service system modify name=CWMP-S port=51006
=>:service system modify name=CWMP-S log=enabled
=>:service system modify name=CWMP-S natpmweight=30
E-DOC-CTC-20071119-0003 v1.0
21
2| Configuring CWMP on the Thomson Gateway
2.2.2 CWMP Daemon as seen from the ACS
Displaying configuration information
To obtain an overview of the CWMP daemon configuration as seen from the ACS, execute following
command:
Parameter description
To modify the configuration of the CWMP daemon as seen from the ACS, execute the command
:cwmp config and specify one or several of following optional parameters:
State: if this parameter is enabled, remote management of the Thomson Gateway by an ACS is allowed.
By default, remote management by CWMP is disabled.
Mode: one of two operational modes can be selected:
Read-only: if the operational mode is set to read-only, only read RPC methods are allowed.
A read-only mode is provided for customers that do not want to actively manage the CPE and do not
want to take any security risk. The read-only mode still allows building an inventory of the installbase CPE.
Full: to enable both read and write RPC methods, the operational mode must be set to full. This is the
default mode.
PeriodicInform: if this parameter is enabled, the CWMP client establishes a connection to the ACS
periodically. This means that the CWMP client sends an Inform RPC with a configurable frequency. The
frequency is defined by the parameter
periodicInfInt.
By default, this parameter is enabled.
PeriodicInfInt: if the parameter periodicInform is enabled, the value of this parameter specifies the
time in seconds (s) between two connection establishments.
By default, the parameter is set to 43200 s. This means that the CWMP client establishes a connection to
the ACS once every 12 hours.
=>:cwmp config
State : disabled
Mode : full
Max Envelopes : 2
Session Timeout : 60
No Ip Timeout : 180
Connection Request Port : 51005
Periodic Inform : enabled
Periodic Inform Interval : 43200 s
Connection Request : disabled
Connection Request UserName : 000E50-CP0452JT03Y
Connection Request PassWord : ********
Connection Request Path :
Connection Request Authentication : digest
Qos class : 12
Boot delay range between 0 and : 0 s
Amendment 1 Session Termination : disabled
Upgrade delay : disabled
Persistent Subscriptions : disabled
This parameter has the same value as the attribute state of the CWMP client service. For
more information, see “2.2.1 CWMP Service Manager” on page 19.
As more operators are performing TR-069 tests and become ready to deploy it, there is less use
and request for a read-only mode.
E-DOC-CTC-20071119-0003 v1.0
22
2| Configuring CWM
P on the Thomson Gatew
ay
SessionTimeout: this parameter is a number that specifies the HTTP session time-out in seconds (s).
When the CWMP client has received no HTTP messages from the ACS for this time period, the HTTP
session is closed.
By default, this time period is set to 60 s.
NoIpTimeout: this parameter is a number, specifying a time period in seconds (s). After the upload of a
new configuration file, it is possible that the modem can not reach the ACS any more. This means that
the IP connection is down. If this connection is not restored during the configured time period, a roll-back
mechanism is started and the initial configuration file is restored.
By default, the time period is set to 180 s (three minutes).
MaxEnvelopes: this parameter specifies the maximum number of SOAP envelopes that the CPE accepts
in a single HTTP response. The value of this parameter can be 1 or 2.
By default, the number of SOAP envelopes sent within one HTTP response is limited to 2.
ConnectionRequest: if this parameter is enabled, the CWMP client establishes a connection to the ACS
when it successfully receives a Connection Request notification. These Connection Request notifications
also use HTTP. However, in this case, the ACS acts as the HTTP client and the Thomson Gateway acts as
the HTTP server.
By default, this parameter is disabled.
ConnectionReqPath: this parameter specifies the path the ACS can use to reach the CWMP daemon on
the Thomson Gateway, for example for connection requests. It is used as last part of the
InternetGatewayDevice.ManagementServer.ConnectionRequestURL which is included in the
ParameterList of an Inform RPC.
The value of this parameter is only relevant if the parameter
ConnectionRequest is enabled.
ConnectionReqUserName: this parameter specifies a text string that must be used by the ACS as
username to log in. The value of this parameter is only relevant if the parameter
ConnectionRequest
is enabled.
The default username is <OUI> - <serial number>. This can be achieved using CLI environment variable
concatenation. To retrieve this information, execute following commands:
ConnectionReqPsswd: this parameter specifies a text string that must be used by the ACS as password to
log in. The value of this parameter is only relevant if the parameter
ConnectionRequest is enabled.
ConnectionReqAuth: both HTTP basic and digest authentication can be used for connection requests.
The value of this parameter is only relevant if the parameter ConnectionRequest is enabled. This
parameter is used to select the authentication method to be supported.
None: the ACS asynchronous connection requests are not authenticated.
Basic: HTTP basic authentication is used.
Digest: HTTP digest authentication is used.
By default, HTTP digest authentication is selected.
For more information on the roll-back mechanism, see “3.2.1 Configuration Update
Mechanism” on page 42.
This parameter has the same value as the attribute state of the CWMP connection request
server service. For more information, see “2.2.1 CWMP Service Manager” on page 19.
=>:env get var=_OUI
000E50
=>:env get var=_PROD_SERIAL_NBR
CP0452JT03Y
E-DOC-CTC-20071119-0003 v1.0
23
2| Configuring CWMP on the Thomson Gateway
Qos-class: this parameter specifies the internal QoS class of Thomson Gateway originated CWMP data.
The Thomson Gateway uses 16 internal QoS classes, numbered from 0 (low priority) through 15 (high
priority). With QoS enabled, this makes sure that upstream CWMP data is mapped into the desired QoS
queue, allowing prioritization or guaranteeing a minimum bandwidth.
By default, the assigned internal QoS class is 12.
Bootdelayrange: the CWMP client establishes a connection to the ACS on power up. In order to avoid that
several gateways contact the ACS simultaneously after a power failure, a boot delay range can be
specified. This way, excessive network load and ACS load after a power failure is avoided.
If the value of this parameter is larger than 0 seconds (s), a random value is calculated within this range
when the gateway starts up. This value is then used as wait period before connecting to the ACS. The
Inform RPC (with BOOT event) is only sent after this random number of seconds.
This parameter has a value within the range from 0 s through 1024 s. By default, the value of the
parameter is set to 0 s. This means that no wait period is used.
Upgradedelay: the CPE firmware upgrade process can contain several service interrupting steps, for
example if a reboot is required. If this parameter is enabled, the upgrade process is extended with state
checks. If these checks result in a “service ongoing” boolean parameter, service activity is detected and
the service interrupting steps can be delayed.
Am1Termination: session termination is configurable via CLI to be according to the original TR-069
specification or according to the TR-069 Amendment 1 specification.
If this parameter is disabled, session termination according to TR-069 is used. This means that the
CPE terminates a transaction session when all of the following conditions are met:
The ACS has no further requests to send to the CPE. The CPE can conclude this from one of the
following: the most recent ACS HTTP response contains no SOAP envelopes or the most recent
SOAP envelope received from the ACS contains a NoMoreRequests header element equal to 1.
The CPE has no further requests to send to the ACS.
The CPE has received all outstanding response messages from the ACS.
The CPE has sent all outstanding response messages to the ACS.
If this parameter is enabled, session termination according to TR-069 Amendment 1 is used. This
session termination differs from the original TR-069 specification in two aspects:
NoMoreRequests header element is deprecated. This header element will not be used any more.
The ACS concludes that the CPE has no further requests to send if the CPE has sent an empty
HTTP POST during the session (while HoldRequests is false). While according to the original
TR-069, the ACS concludes that the CPE has no further requests to send if the most recent HTTP
POST sent by the CPE is empty (while HoldRequests is false).
By default, the parameter is disabled.
PersistentSubscription: this parameter indicates whether or not persistent subscriptions are supported. If
the ACS has a persistent subscription for a specific parameter, the instance number of the corresponding
MBUS object is not changed after a reboot, for example when objects with a lower instance number are
deleted.
By default, this parameter is disabled.
This parameter is still available for backwards compatibility. However, it is recommended to
use the attribute qoslabel of the CWMP client service. For more information, see
“2.2.1 CWMP Service Manager” on page 19.
For more information on activity checks, see “2.3 Configuring State Checks” on page 28.
E-DOC-CTC-20071119-0003 v1.0
24
2| Configuring CWM
P on the Thomson Gatew
ay
2.2.3 CWMP Daemon towards the ACS
Displaying configuration information
To obtain an overview of the CWMP daemon configuration towards the ACS, execute following command:
The parameters and their default values are displayed as follows:
Parameter description
To modify the configuration of the CWMP daemon towards the ACS, execute the command
:cwmp server config and specify one or more of the following optional parameters:
Url: this parameter specifies the HTTP URL of the ACS.
Username: this parameter defines the username for authentication of the Thomson Gateway at the ACS.
The ACS default username is <OUI> - <serial number>. This can be achieved using CLI environment
variable concatenation. To retrieve this information, execute the following commands:
Password: this parameter defines the password for authentication of the Thomson Gateway at the ACS.
=>:cwmp server config
ACS url : http://acs-server.com
ACS username : 000E50-CP0452JT03Y
ACS password : ********
=>:env get var=_OUI
000E50
=>:env get var=_PROD_SERIAL_NBR
CP0452JT03Y
Loading...