|Release Type||Release Number||Release Date|
|Original||CDRouter 10.5 Build 1||November 2, 2017|
|Maintenance Release 1||CDRouter 10.5 Build 2||December 6, 2017|
|Maintenance Release 2||CDRouter 10.5 Build 3||January 10, 2018|
|Maintenance Release 3||CDRouter 10.5 Build 4||February 6, 2018|
Note: CDRouter 10.5 includes many new features and configuration testvars. Old config files can be automatically upgraded to include all new CDRouter 10.5 testvars using the config upgrade utility.
CDRouter 10.5 Build 1 November 2, 2017
New Features and Enhancements
New test module for verifying wifi client associations
A new wifi test module (wifi.tcl) has been added to CDRouter. This test module includes five new tests that are designed to verify that the DUT supports various wifi client association scenarios and modes, and that the DUT’s wifi beacons contain the expected information.
These tests can be repeated to stress the DUT’s wireless AP making it possible to expose issues that only appear after a large number of wireless client disassociation / association sequences.
New ARP test module
A new ARP specific test module (arp.tcl) has been added to CDRouter. This module contains a variety of tests that verify the DUT’s behavior with respect to different types of ARP requests, ARP cache entries, and its susceptibility to ARP spoofing and potential DoS situations. Two new testvars have been introduced to define the expected behavior of the DUT with respect to ARP: arpMode and arpSupportGratuitous.
In addition, two tests which create a large number of ARP requests and replies have been added (arp_60 and arp_61). These tests are designed to stress the DUT’s ARP functionality and can be useful additions to existing test packages. These tests can trigger unexpected and potentially problematic ARP related issues in some devices.
The arp module also introduces a new type of CDRouter test that analyzes data generated from previous tests (arp_30 and arp_31). In these cases the data being analyzed is the ARP history of all LAN or WAN clients, respectively, that have been created up to the point where these tests were executed during a particular test run. To ensure that the largest possible data set is analyzed, these test should be executed at the end of a test run or at multiple points during a test run include some point near the end.
For more information please see our ARP testing guide which is available here.
New HTTP tests for verifying GET requests with a large number of headers
Six new HTTP tests have been added to CDRouter to verify GET requests over various transports using a large number of headers. While the HTTP RFCs do not limit the maximum number of header fields, some implementations limit the number of headers potentially causing problems for applications that depend on a large number of HTTP headers. These new tests are:
Test Module cdrouter_http_103 http.tcl cdrouter_http_206 http.tcl cdrouter_http2_106 http2.tcl cdrouter_http2_tls_106 http2-tls.tcl cdrouter_https_103 https.tcl cdrouter_https_206 https.tcl
The new testvar httpMaxHeaderCount, which defaults to 200, can be used to configure the number of headers included in each GET request.
New HTTP tests for verifying WebSocket functionality
Four new HTTP test cases have been added to CDRouter to verify HTTP WebSocket connections. These new tests are:
Test Module cdrouter_http_300 http.tcl cdrouter_http_301 http.tcl cdrouter_https_300 https.tcl cdrouter_https_301 https.tcl
New ICMP Time Exceeded test case
A new test case, cdrouter_icmp_30, has been added to the icmp.tcl module to complement the existing cdrouter_icmp_10 test. This new test verifies that an ICMP Time Exceeded packet is sent by the DUT for TCP packets with a TTL 1. The existing cdrouter_icmp_10 test case verifies the same behavior for UDP instead of TCP.
New tool to compare differences in test results
A new Results Diff tool has been added to CDRouter to allow test case results from different test runs to be compared in a side-by-side table. Users may select up to 5 different test runs from the Results page for the Results Diff tool to compare. For more details and examples, please see the “How can I compare multiple test results?” article in our Knowledge Base.
Move to Top, Move to Bottom buttons for package editing
There are now two new buttons in the package edit page. When adding tests or modules to a package, they get placed at the end of the list. Large packages can make it cumbersome to move tests/modules around. These new buttons allow you to move selected tests/modules to the top or bottom of the list.
Installing new license automatically loads new test suite
After loading a new license, either by clicking the Download & Install License button or by the drag and drop method, the CDRouter test suite will now be automatically updated. Restarting CDRouter is no longer required to load the updated test suite. Note that installing a new license on the command line via
cdrouter-cli -update-licensestill requires manually restarting CDRouter.
New cdrouter-clone utility available for the NTA1000
Users upgrading to a new NTA1000 hardware platform can use the new cdrouter-clone utility to automatically transfer their CDRouter data from the system being replaced. The cdrouter-clone utility will connect to the old system and transfer an exact copy of the entire CDRouter database. This simplifies the process of moving to a new platform and minimizes downtime by ensuring that all of the same config files, test packages and results from the old system are copied to the new NTA1000 in one step.
Please see ‘How to transfer CDRouter configs, packages, and results to a new NTA1000’ for details on using the cdrouter-clone utility.
Better handling of custom test paths
CDRouter’s handling of custom test paths has been refactored and improved. If there are bad custom test paths CDRouter’s web interface will now start up as normal (previously it would start up in recovery mode) and display a warning in the banner indicating that there are issues with the test path configuration. Clicking on the warning message will open the Preferences page where users can fix or remove any invalid custom test paths.
L2TP and PPTP WAN modes now support server configuration via FQDN
Historically, CDRouter required that the L2TP or PPTP WAN tunnel endpoint be manually configured via IP address within the DUT. CDRouter now supports configuration of the L2TP or PPTP WAN tunnel endpoint via FQDN. To enable this feature, a static DNS entry for the L2TP/PPTP WAN tunnel endpoint FQDN must be added to the CDRouter configuration file. For example, if the DUT is configured with an L2TP tunnel endpoint of
l2tp.qacafe.com, a static DNS entry that maps this domain name to the value of wanIspIp must be added:
testvar dnsHostname1 l2tp.qacafe.com testvar dnsIp1 18.104.22.168
New HTTP tests for verifying GET requests with a large number of headers
Six new HTTP tests have been added to CDRouter to verify IPv6 GET requests over various transports using a large number of headers. These new tests are:
Test Module ipv6_http_103 http.tcl ipv6_http_206 http.tcl ipv6_http2_106 http2.tcl ipv6_http2_tls_106 http2-tls.tcl ipv6_https_103 https.tcl ipv6_https_206 https.tcl
The new testvar httpMaxHeaderCount, which defaults to 200, can be used to configure the number of headers included in each of the test cases listed above.
New HTTP tests for verifying WebSocket functionality
Four new HTTP test cases have been added to CDRouter to verify IPv6 HTTP WebSocket connections. These new tests are:
Test Module ipv6_http_300 http-v6.tcl ipv6_http_301 http-v6.tcl ipv6_https_300 https-v6.tcl ipv6_https_301 https-v6.tcl
Support for Device:2 within the tr69_wireless test module
The tr69_wireless module has been updated to support Device:2 implementations. Because the Device:2 root data model does not provide the same configuration options for WPA/WPA2 cipher modes that are available in the InternetGatewayDevice:1 root data model, three new Device:2 specific WPA/WPA2 tests have been added: tr69_wireless_30, tr69_wireless_31, and tr69_wireless_32. The existing tr69_wireless_1, tr69_wireless_10, and tr69_wireless_11 test cases map directly to the Device:2 data model and have been updated to support it.
New test for verifying that wireless radio can be disabled via TR-069
A new test case, tr69_wireless_2, has been added to the tr69_wireless test module to verify that the DUT’s radio can be disabled via TR-069. This test supports both InternetGatewayDevice:1 and Device:2 implementations.
Received CWMP traffic can now be filtered by device serial number and OUI
CDRouter’s ACS now supports filtering of incoming CWMP sessions by device serial number and OUI. When enabled, the ACS will only respond to incoming CWMP traffic from the configured device. All incoming CWMP sessions from other devices will be ignored.
This feature allows CDRouter’s ACS to work better in environments where multiple devices are active and sending CWMP traffic to the ACS. To utilize this feature, the testvars tr69DeviceSn and tr69DeviceOui must be enabled and properly set to the values of the
SerialNumberreported by the DUT in the DeviceId portion of its Inform messages.
Added new testvars to allow for addtional configuraion of latency tests
Added the testvars perfLatencyAttempts, perfApplicationAttempts, and perfApplicationDelay to allow more configuration options when running the IPv4 and IPv6 application latency performance test cases. Each testvar definition includes more information on how they affect the test cases.
New Test Modules and Test Cases
New ARP test module
MODULE: arp.tcl DESCRIPTION: ARP functional test cases NEW TEST CASES: 13
New wifi test module
MODULE: wifi.tcl DESCRIPTION: WiFi client association and verification tests NEW TEST CASES: 6
New HTTP tests for verifying GET requests with a large number of headers
TEST: cdrouter_http_103 MODULE: http.tcl DESCRIPTION: Verify HTTP/1.0 GET connections with large number of headers
TEST: cdrouter_http_206 MODULE: http.tcl DESCRIPTION: Verify HTTP/1.1 GET connections with large number of headers
TEST: cdrouter_http2_106 MODULE: http2.tcl DESCRIPTION: Verify HTTP/2 GET connections with large number of headers
TEST: cdrouter_http2_tls_106 MODULE: http2.tcl DESCRIPTION: Verify HTTP/2 GET connections over TLS with large number of headers
TEST: cdrouter_https_103 MODULE: https.tcl DESCRIPTION: Verify HTTPS/1.0 GET connections with large number of headers
TEST: cdrouter_https_206 MODULE: https.tcl DESCRIPTION: Verify HTTPS/1.1 GET connections with large number of headers
New HTTP and HTTPS tests to verify WebSocket functionality
TEST:cdrouter_http_300 MODULE: http.tcl DESCRIPTION: Verify HTTP/1.1 WebSocket Ping message
TEST:cdrouter_http_301 MODULE: http.tcl DESCRIPTION: Verify HTTP/1.1 WebSocket Text message
TEST:cdrouter_http_300 MODULE: http.tcl DESCRIPTION: Verify HTTPS/1.1 WebSocket Ping message
TEST:cdrouter_https_301 MODULE: http.tcl DESCRIPTION: Verify HTTPS/1.1 WebSocket Text message
New test to verify that an ICMP Time Exceeded packet is sent for TCP traceroute with TTL 1
TEST: cdrouter_icmp_30 MODULE: icmp.tcl DESCRIPTION: Verify ICMP Time Exceeded packet is sent for TCP traceroute with TTL 1
New HTTP tests for verifying IPv6 GET requests with a large number of headers
TEST: ipv6_http_103 MODULE: http-v6.tcl DESCRIPTION: Verify IPv6 HTTP/1.0 GET connections with large number of headers
TEST: ipv6_http_206 MODULE: http-v6.tcl DESCRIPTION: Verify IPv6 HTTP/1.1 GET connections with large number of headers
TEST: ipv6_http2_106 MODULE: http2-v6.tcl DESCRIPTION: Verify IPv6 HTTP/2 GET connections with large number of headers
TEST: ipv6_http2_tls_106 MODULE: http2-v6.tcl DESCRIPTION: Verify IPv6 HTTP/2 GET connections over TLS with large number of headers
TEST: ipv6_https_103 MODULE: https-v6.tcl DESCRIPTION: Verify IPv6 HTTPS/1.0 GET connections with large number of headers
TEST: ipv6_https_206 MODULE: https-v6.tcl DESCRIPTION: Verify IPv6 HTTPS/1.1 GET connections with large number of headers
New HTTP and HTTPS tests to verify IPv6 WebSocket functionality
TEST:ipv6_http_300 MODULE: http.tcl DESCRIPTION: Verify HTTP/1.1 WebSocket Ping message
TEST:ipv6_http_301 MODULE: http.tcl DESCRIPTION: Verify HTTP/1.1 WebSocket Text message
TEST:ipv6_https_300 MODULE: http.tcl DESCRIPTION: Verify HTTPS/1.1 WebSocket Ping message
TEST:ipv6_https_301 MODULE: http.tcl DESCRIPTION: Verify HTTPS/1.1 WebSocket Text message
New Device:2 specific test cases in the tr69_wireless module
TEST: tr69_wireless_30 MODULE: tr69_wireless.tcl DESCRIPTION: Verify WPA wireless configuration (Device:2 only)
TEST: tr69_wireless_31 MODULE: tr69_wireless.tcl DESCRIPTION: Verify WPA2 wireless configuration (Device:2 only)
TEST: tr69_wireless_32 MODULE: tr69_wireless.tcl DESCRIPTION: Verify WPA/WPA2 wireless configuration (Device:2 only)
New test for verifying that the DUT’s wireless radio can be disabled
TEST: tr69_wireless_2 MODULE: tr69_wireless.tcl DESCRIPTION: Verify access point can be disabled (IGD & Device:2)
Bug Fixes and Notes
Resolved an issue associated with decoding and displaying 802.2 LLC packets in test logs. Previously CDRouter was not decoding these packets properly leading to warning messages in test logs whenever an 802.2 LLC packet was received.
CDRouter now uses TCL version 8.6.7.
The default value of the testvar portScanStop has been changed from ‘2048’ to ‘65535’. This modification has been made to address many recent security issues that were the result of open ports high in the range. By default CDRouter will now scan then entire port range rather than just a small subset of ports during firewall and dmz scans. Note that this change will result in significantly larger log files and longer run times for these tests in this release. [LH #3359]
Updated the various port scan tests in the firewall module to resolve an issue with certain implementations. Previously CDRouter would listen for and respond to all ARP requests received during the port scan tests. This was required to properly detect open ports due to virtual services. However, when renewing a WAN DHCP lease some implementations send ARP requests for the WAN gateway on the LAN. If this occurred during a firewall port scan test CDRouter would respond and overwrite the DUT’s ARP cache entry for the default WAN gateway with a bogus LAN side address. This would lead to a broken default route and failures for any subsequent tests that required LAN to WAN forwarding. This issue has been resolved with this release, and the new arp_50 test case has been added to explicitly test for this unexpected and insecure behavior within the DUT. [LH #3372]
The list of modules displayed in the Package Editor is now sorted alphabetically. [LH #3422]
The test case name located in the top left-hand corner of the log viewer is now linked to the documentation page for that test case.
CDRouter will now alert the user in the ‘start’ log if one or more custom test cases conflicts with and overwrites existing, pre-defined test cases. [LH #3363]
Resolved an issue with the skip logic for the test case cdrouter_dhcp_30 when multiple WAN interfaces are configured. [LH #3430]
Refactored CDRouter’s cleanup code to better handle various situations where a test run might be stopped. When a test is run stopped, either by the user or by a run-time option, CDRouter will clean up by actively bringing down any WAN connections, disassociating all wireless LAN clients, and releasing all DHCPv4 and DHCPv6 client addresses on the LAN. CDRouter also produces failures now if any wireless LAN interfaces are disassociated when entering or exiting a test case. [LH #3341]
Resolved an issue with the log viewer Auto-update feature in the latest versions of Google Chrome (versions 60+). [LH #3427]
The guest-v6 test module will now be automatically skipped if IPv6 is not enabled on the guest LAN interface (ie the testvar ipv6LanMode is set to a value of none). [LH #3442]
Addressed an issue with skip test logic for the dhcp-s test module when multiple LAN interfaces are defined and the primary LAN interface has the testvar lanMode set to a value of static. [LH #3453]
The tr69_wireless module now performs an additional IPv6 connectivity check when associating if IPv6 is enabled within CDRouter.
CDRouter now utilizes the parameter
Device.RootDataModelVersionto determine if a DUT supports the Device:2 root data model. This parameter was added to version 2.4 of the Device:2 data model. If not present, CDRouter will revert to its original behavior and examine the data model for the parameter
Device.IP.IPv4Enableto determine if a DUT supports the Device:1 or Device:2 root data model.
The tr69_1 test case has been updated to verify that the
Device.RootDataModelVersionparameter exists in Informs from the DUT if the DUT supports Device:2.4 or greater.
The constraints for the testvar cwmpProfileObject have been tightened. Prior to CDRouter 10.1 this testvar did not require the user to specify the version number. In CDRouter 10.1 and later releases, the version number is required. The config check for this testvar will now ensure that it is set to one of the following three values: ‘InternetGatewayDevice:1’, ‘Device:1’, or ‘Device:2’.
The start log now only displays the list of profiles that the DUT supports. This change reduces the number of profile related log messages displayed in the start log significantly. [LH #3415]
The tr69_51 and tr69_61 test cases have been modified to include an extra step of verification. Now, in addition to verifying that the port mapping works for the expected remote host address, these tests also verify that the port mapping does not work if other WAN hosts try to use it. [LH #3366]
Resolved a fatal error when parsing improperly formed ‘DUStateChangeComplete’ RPCs from the DUT in test od128_test_35.6. [LH #3425]
The tr69_wireless module has been updated to verify that all supported security modes are working when multiple modes have been configured. For example, in tests that configure the DUT for both WPA and WPA2, CDRouter will attempt to associate, pass traffic, and verify counter stats, using both WPA and WPA2 independently. Previously CDRouter’s wireless LAN client would be configured for ‘auto’ mode during the verification process and thus verify only a single mode of operation.
The od128_test_19.1 test case has been updated to cache and restore the WPA/WPA2 wireless security settings. This will help ensure that the DUT is left with its original wireless configuration at the end of the test. [LH #3395]
The default value of the nmapPorts testvar has been changed from the keyword ‘default’ to ‘0-65535’. As a result, all Nmap scans will now operate over the entire port range by default. Like the change that was made to the portScanStop testvar, the reason for this modification is to improve testing and help identify open ports high in the range that have been the cause of many recent security issues.
Note that this change will result in significantly larger log files and longer run times for the Nmap tests in this release. Some users may need to adjust the nmapScanTimeout testvar value to ensure that the Nmap tests run fully and do not timeout and exit early. [LH #3359]
- Resolved an issue with the IPv6 storage tests where a ‘couldn’t connect to server’ error was not producing a failure and leading to false positive test results. [LH #3434]
- Resolved an issue where a WLAN client using the mode WPA Enterprise (802.1X) would fail when using EAP-PEAP as the authentication method during the performance throughput test cases. [LH #3369]
CDRouter 10.5 Build 2 December 6, 2017
Bug Fixes and Notes
When enabled, CDRouter’s 3rd and 4th DNS servers will include the EDNS0 option in the DNS test cases, most notably dns_121 and dns_tcp_121. The 3rd and 4th DNS servers can be enabled using the testvars wanBackupDnsServer2 and wanBackupDnsServer3. [LH #3464]
Updated the logic in the cdrouter_dhcp_20 test case to be more strict about the order in which DHCP messages are received from the DUT. This resolves a possible false positive result in this test for some implementations. [LH #3499]
Resolved an issue in the cdrouter_dos_20 and cdrouter_dos_21 test cases where CDRouter dropped a packet that should have been sent to the DUT, resulting in a potential false positive test result. [LH #3491]
Additional type checking has been added to the optional syntax validation phase of all Data Model Profile tests (ie. Device2_profiles.tcl, InternetGatewayDevice1_profiles.tcl, etc.). If syntax validation is enabled, the XML-encoded data type of each parameter value returned by the DUT is compared against the parameter definition to ensure they match. Any inconsistencies are flagged and will cause a failure.
Resolved a fatal error condition in the tr69_51 and tr69_61 test cases when running with a small free network configuration that provides only one additional free network for testing. [LH #3347]
Resolved an issue when parsing custom CWMP profiles that define optional parameters within a partial path. Previously if the parent object was defined as Required CDRouter would treat all parameters under that object as required. Now, if a partial path under a required parent object is defined as Optional, CDRouter will treat all parameters under that partial path as optional as well. [LH #3482]
The order in which CDRouter loads CWMP profiles has been modified. In earlier releases CDRouter would load vendor defined (custom) profiles first, followed by all official profiles defined by the Broadband Forum. In this release the order is reversed - official profiles are loaded first, followed by all vendor defined profiles. This change makes it possible for users to modify the attributes of an official parameter by defining it in a vendor defined profile. Note that modifications made via the cwmpModifyParameters testvar are applied after all profiles are loaded. [LH #3409]
The tr69_210 and tr69_220 test cases have been updated to accommodate cases where the DUT may send additional “4 VALUE CHANGE” Event Codes to the ACS that are not related to the change in the WAN address. [LH #2314]
- The default values of the bbf069ACSURL and bbf069AlternateACSURL testvars have been modified to ‘http://acs1.broadband-forum.org' and ‘http://acs3.broadband-forum.org', respectively. Note that for SSL configurations, these testvars must be explicitly modified to specify a transport of https instead of http. [LH #3468]
- The constraints associated with CDRouter ICS have been updated. Specifically, CDRouter will now generate a warning if IPv4 or IPv6 ICS is enabled and there is no valid global IPv4 or IPv6 address available, respectively, on the ICS interface. In addition, IPv6 ICS is now restricted to configurations that utilize DHCPv6 prefix delegation (ie IPv6 WAN modes of DHCP, PPPoE, static, or autoconf). [LH #3475]
Resolved a fatal error during DOCSIS startup on systems that do not have the IPv6 add-on enabled. [LH #3495]
When the CM interface is rebooted or restarted CDRouter will now also wait for the eRouter interface, if present, to also restart before continuing. [LH #3489]
Updated the logic in the docsis_dhcp_20 test case to be more strict about the order in which DHCP messages are received from the DUT. This resolves a possible false positive result in this test for some implementations. [LH #3499]
Modified docsis_dhcp_4 and docsis_dhcp_5 to allow the DUT to send a DHCPRELEASE before restarting its DHCP process with a DHCPDISCOVER. [LH #3488]
CDRouter 10.5 Build 3 January 10, 2018
Bug Fixes and Notes
Support for PPPoA and ATM interfaces has been deprecated and will be removed in future releases of CDRouter. Please contact QA Cafe support for more details. [LH #3511]
Modified dns_45, dns_46, dns_tcp_45, and dns_tcp_46 to no longer use underscores in the domain name. [LH #2860]
Added a 5 ms delay after associating and authenticating via wireless to provide more time for the DUT to open the controlled port and allow traffic to flow. This modification was made after observing that some DUTs do not immediately open the controlled port leading to dropped packets and ultimately longer test durations. [LH #3446]
Resolved a WPA2 issue associated with group re-keying. In previous releases CDRouter would incorrectly drop key packets whenever a WPA2 group message was received. This would lead to warnings in test logs and cause some devices to disassociate CDRouter’s LAN client(s). This issue only impacted WPA2 configurations when re-keying occurred. [LH #3533]
Updated some tests in the static.tcl module to ensure that “next-hop” addresses in static routes (defined by staticRouteLanNextHop) are always assigned the same MAC address in any test for the entire test run. This will prevent erroneous test failures due to ARP caching in the DUT from one test to another. [LH #3538]
- Resolved an issue in the cdrouter_natmp_100, cdrouter_natmp_101, and cdrouter_natmp_102 test cases. These tests now properly verify an asymmetric traffic path by sending response traffic back to the DUT on an alternate WAN interface. This issue was introduced with the routing changes implemented within the 10.4 release of CDRouter. Earlier versions do not have this issue. [LH #3506]
Resolved an issue in the icmpv6_31 test case and the slaac-wan test module related to solicited Neighbor Advertisements sent by CDRouter on the WAN. In previous releases, the Router bit in all solicited NAs would be unset during these tests by CDRouter. This could cause some devices to lose WAN connectivity during these tests resulting in unexpected behavior. This issue has been resolved in this build. All solicited NAs will now have the Router bit set during these tests. [LH #3508]
Modified ipv6_dns_45, ipv6_dns_46, ipv6_dns_tcp_45, and ipv6_dns_tcp_46 to no longer use underscores in the domain name. [LH #2860]
Added ipv6_upnp_204 and ipv6_upnp_igd2_204 to the requires_ipv4 skip list. These tests use IPv6 for the transport of UPnP but require IPv4 to also be active, so that the DUT’s WAN’s IPv4 address may be modified and verified to have changed. [LH #3535]
Resolved an issue with the mapt_14 test case which was preventing CDRouter’s LAN client from sending packets with a source address “0.0.0.0”. [LH #3531]
Additional detail is now printed if CDRouter is unable to parse custom profile definitions from the cwmpProfilePath file. [LH #3516]
Updated the od128_test_16.5 test case to disable Passive Notification settings on the DUT before ending the test. [LH #3492]
When testing with a device that supports the XMPP protocol for Connection Requests, the DUT will only be configured with the minimum settings needed to enable it to connect to CDRouter’s XMPP server. In order to ensure that all XMPP-capable devices can connect, CDRouter will no longer attempt to configure additional XMPP settings that are not strictly required. [LH #3517]
Added a more accurate log message and clarified a few of the steps listed for test *tr69_210 to remove some confusion surrounding some of the test’s actions. [LH #3539]
The command key used by CDRouter during the OD-128 reboot test, od128_test_14.1, has been changed from
Rebooting for OD-128 test 14to
Rebooting for CDRouter test. This change was made to make the command key and subsequent logging more generic since this test is called in other test cases. [LH #3546]
The od128_test_14.1 test case has been updated to better handle wireless LAN clients. If wireless is used, CDRouter’s LAN client will be explicitly disassociated at the start of the test and restarted at the end of the test. [LH #3543]
Added some additional log messages to the DOCSIS TFTP server to display the full path of the config file that is being transferred. [LH #3515]
Fixed a copy error that prevented the docsisTftpBootFile from being written at the start of a test run if the file already exists. [LH #3512]
Added two new testvars storageSmbPacing and storageFtpPacing which allow users to configure a delay, in milliseconds, that is applied between client transactions within the various storage scaling tests. The default value is 0 milliseconds. [LH #3523]
Fixed a potential false positive condition when a DUT’s FTP server reports that too many sessions are active. This condition would sometimes not get reported as a failure in the FTP scaling test cases, ftp_52 and ftps_52. [LH #3521]
CDRouter 10.5 Build 4 February 6, 2018
Bug Fixes and Notes
Resolved an issue with the Device Connect feature in which HTTP 302 redirects, used by some devices for their management web page, were not being properly translated by CDRouter’s web proxy. [LH #3550]
Resolved a fatal error in cdrouter_dhcp_server_630 test when using a configuration with the combination of the wanMode testvar set to a value of static and the DNStoDHCP testvar set to a value of yes. [LH #3553]
Updated tests od128_test_16.2, od128_test_16.4, and od128_test_24.1. At the end of each test any notifications that were enabled are now properly disabled. This update prevents unexpected ‘4 VALUE CHANGE’ events related to these tests from impacting subsequent tests. [LH #3556]
Resolved an issue in which CDRouter’s ACS was not explicitly sending an empty string tag, <string></string>, in GetParameterNames and GetParameterValues RPCs when the root object from a custom profile could not be determined. [LH #3566]
The default value of the testvar acsSslVersion has been changed from sslv23 to tlsv1_2. This change ensures that by default CDRouter’s ACS complies with the current best practices defined in Section 3.3 of TR-069 Amendment 5, which states that SSL 3.0 and TLS 1.0 SHOULD NOT be used and that TLS 1.2 SHOULD be used instead. Any old configs that relied in the previous default value of sslv23 may need to be updated if the DUT does not support TLS 1.2. [LH #3575]
Updated test case tr69_410 to ensure that only one NTP server is available at any time and verify that the DUT is able to sync its clock with each one. [LH #3537]
- CDRouter’s ACS was updated to resolve a problem with the way HTTP Cookies are stored and verified during the 5_036_redirect_cookies test. The use of quotes around cookie values is now more consistent and based on the value of the acsCookieMode testvar. [LH #3559]
- Modified the criteria of a ‘PASS’ in the test cases ipv6_mdns_10 and ipv6_mdns_12 to only accept mDNS responses from the DUT’s IPv6 link-local address. This was modified to match what is specified in RFC 6762, section 3. [LH #3565]