The CPE WAN Management Protocol described by Broadband Forum TR-069 is a remote procedure call (RPC) based protocol. That is, it consists of two applications that interact directly with each other through a set of defined methods - in the case of TR-069, this includes device functions like Reboot, Download, etc., as well as operations that affect the device’s data model - a set of objects and parameters and the metadata surrounding them.
Most TR-069 testing involves exercising these RPCs to ensure that a CWMP enabled device behaves correctly when the RPCs are called - for example, the device actually reboots, or settings on the device are updated after a SetParameterValues call. However, it is equally important that a device’s data model parameters are valid both internally and when communicating them over CWMP. This includes being valid XML, having the correct data type, and ensuring that a parameter’s values are within the range or options defined in the data model.
XML Validity
The most basic thing you can do when validating TR-069 messages is to compare them to the XML schema they are based on using an xml validator like xmllint. CDRouter includes xmllist, and you can use it by setting up a tr69XMLCapturePath testvar and running xmllint from the command line. Problems at this level are fundamental, and may trip up an ACS’s XML parser when attempting to complete a TR-069 interaction.
Parameter validation
In addition to validating that a CPE’s CWMP messgages are readable by an ACS, it is doubly important to test that the values reported (and presumably, stored) by the CPE match the syntax of the parameters as they are specified in the official CWMP device data models. This includes basic syntax like using the correct data type, but also abiding by the range restrictions or enumeration options defined in the data model.
For example, let’s examine the Device.WiFi.AccessPoint.{i}.Security. object in the Device:2 data model. This object contains the ModesSupported parameter, whose description says:
Comma-separated list of strings. Indicates which security modes this AccessPoint instance is capable of supporting. Each list item is an enumeration of:
- None
- WEP-64
- WEP-128
- WPA-Personal
- WPA2-Personal
- WPA-WPA2-Personal
- WPA-Enterprise
- WPA2-Enterprise
- WPA-WPA2-Enterprise
This means that, although the XML data type is “String”, the parameter is further restricted to contain a comma separated list of values specified in this enumeration. Providing values outside of this list, or typographical errors, will not be recognized by an ACS and can cause interoperability problems.
CDRouter can validate individual parameters to ensure they use the correct syntax. It uses the official CWMP data models as reference, and tests each parameter specified in a Profile that the DUT says it supports. This behavior can be turned on and off using the cwmpDataValidation testvar.
What about vendor extensions to enumerations or parameters?
Ideally, a device should utilize the SupportedDataModel table specified in the Device:2, Device:1, and InternetGatewayDevice:1 data models to point an ACS towards an xml document that decribes all of the objects, parameters, and their syntax that they support. In this case, handling vendor extensions is easy - the ACS is explicitly told what they will be.
Unfortunately, not many devices today support this feature, though that is changing as newer service providers take up TR-069 for the first time. In the meantime, CDRouter users can specify a custom profile to tell CDRouter what the parameter names are to test. You can also specify their syntax so you can perform this crucial testing on any device regardless of its custom data model.
