CDRouter Support

CDRouter Demo Test Summaries (Full)

test-summary version 13.3

Test Case Descriptions

  • Modules: 29
  • Test Cases: 38

Below is a full description of the testcases in each module


basic.tcl

Initial connectivity tests to verify ARP and DHCP client are connected

Test Module Name Synopsis
Router responds to ARP request on LAN interface basic.tcl cdrouter_basic_1 Router responds to ARP request on LAN interface


    step 1. Send an ARP request to LAN client's default gateway
    step 2. Verify that a valid ARP response is received



dhcp-c.tcl

DHCP client tests for the WAN side of the router

Test Module Name Synopsis
DHCP client renews lease when current lease expires dhcp-c.tcl cdrouter_dhcp_1 DHCP client renews lease when current lease expires


    step 1. Wait for DHCP lease to expire
    step 2. Verify WAN client sends DHCPREQUEST for same IP address
    step 3. Reassign the same IP address



pppoe-c.tcl

PPPoE client tests for the WAN side of the router

Test Module Name Synopsis
PPPoE client restarts PPPoE Discovery when PPP LCP Echo-Requests fail pppoe-c.tcl cdrouter_pppoe_client_1 PPPoE client restarts PPPoE Discovery when PPP LCP Echo-Requests fail


    step 1. Turn off PPP LCP Echo-Reply on PPPoE server
    step 2. PPP client should send an LCP Echo-Request
    step 3. PPP client will not receive an LCP Echo-Reply
    step 4. Verify WAN PPPoE client sends PADI to restart PPPoE Discovery
            (wait upto 5 minutes for LCP to failover)
    step 5. Verify PPPoE client brings new PPPoE session up

    NOTE: Most PPPoE clients will terminate the existing PPPoE session after
    several LCP Echo-Requests have failed. However, some routers will
    simply initiate a new PPPoE session without sending a PADT. This
    test case does not FAIL the test if the existing PPPoE session is not
    terminated before starting a new PPPoE session. However, a warning
    will be issued.

    NOTE: The amount of time the test waits to recover the PPP based
    link can be configured by adjusting the testvar pppRestartTimeout.
    This variable contains the number of milliseconds to wait for
    PPP based protocols to recover. The default is 300000 (300 seconds).

    NOTE: By default, CDRouter will still respond to ICMP Echo
    Requests during this test. This allows the test to verify failure
    occurs because of PPP and not the ICMP Echo Replies. However, you
    can configure CDRouter to also ignore ICMP Echo Requests during
    this test by setting the testvar pppFailUsesICMP to yes.



chap.tcl

PPP CHAP tests for PPP based protocols on the WAN (PPPoE and PPTP)

Test Module Name Synopsis
PPP CHAP authentication with various size key lengths chap.tcl cdrouter_chap_10 PPP CHAP authentication with various size key lengths


    step 1. Terminate the current PPP session using LCP Terminate
    step 2. Set the new CHAP secret length to a new value (24 37 78 112 255)
    step 3. Verify PPPoE, PPTP, or L2TP client restarts the link
    step 4. Once LCP is up, send a new CHAP Challenge to peer
    step 5. Verify correct CHAP Response is received
    step 6. Repeat for each key length generating a new secret each time


    References:

    IETF RFC 1994 "PPP Challenge Handshake Authentication Protocol (CHAP)"

    https://tools.ietf.org/html/rfc1994


dhcp-s.tcl

DHCP server tests for the LAN side of the router

Test Module Name Synopsis
Verify DHCP server returns same IP address when client renews dhcp-s.tcl cdrouter_dhcp_server_1 Verify DHCP server returns same IP address when client renews


    step 1. Send a DHCPREQUEST for the current IP address
    step 2. Verify DHCP server sends DHCPACK


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4.3.2: DHCPREQUEST message

    https://tools.ietf.org/html/rfc2131#section-4.3.2


nat.tcl

NAPT tests for TCP, UDP, and ICMP

Test Module Name Synopsis
Outbound TCP connections use NAPT nat.tcl cdrouter_nat_1 Outbound TCP connections use NAPT


    step 1. Initiate an outbound TCP connection to HTTP server
    step 2. Verify the connection is established
    step 3. Send HTTP GET request to server
    step 4. Verify HTTP response is received
    step 5. Verify the IPv4 source address on the WAN side is the router's address
    step 6. Close TCP connection from LAN side


    References:

    IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)"

    https://tools.ietf.org/html/rfc3022


renum-dhcp.tcl

WAN side renumbering tests with DHCP on the WAN

Test Module Name Synopsis
Verify WAN client learns new IP address when WAN server renumbers renum-dhcp.tcl cdrouter_renumber_1 Verify WAN client learns new IP address when WAN server renumbers


     step 1.  Change the wanIspAssignIp address to a new address
     step 2.  Wait for DHCP lease to expire on WAN interface
     step 3.  Verify WAN client sends DHCPREQUEST for same IP address
     step 4.  Send DHCPNAK for that address
     step 5.  Verify DHCP WAN client restarts DHCPDISCOVERY and learns new IP
     step 6.  Verify new address responds to ping from LAN
     step 7.  Verify the old address no longer responds to ping from LAN
     step 8.  Verify new address responds to ARP request from WAN
     step 9.  Verify LAN client can ping remote host using new address
     step 10. Restore original IP address
     step 11. Verify LAN client can ping remote host

     NOTE: Step 8 will be skipped if testvar IPv4HopCount > 1 or testvar
     wanIspAssignGateway is defined as this indicates that the WAN client and
     WAN server are not on the same subnet.


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol"

    https://tools.ietf.org/html/rfc2131


renum-pppoe.tcl

WAN side renumbering tests with PPPoE on the WAN

Test Module Name Synopsis
Verify WAN PPPoE client learns new IP address when WAN server renumbers renum-pppoe.tcl cdrouter_renum_pppoe_1 Verify WAN PPPoE client learns new IP address when WAN server renumbers


    step 1. Change the wanIspAssignIp address to a new address
    step 2. Terminate the current PPPoE session with the client
    step 3. Verify WAN attempts to establish new PPPoE session
    step 4. Verify LAN client can ping remote host using new address
    step 5. Reset the WAN configuration to original IP address
    step 6. Verify the original PPPoE session has been reestablished

    NOTE: The amount of time the test waits to recover the PPP based
    link can be configured by adjusting the testvar pppRestartTimeout.
    This variable contains the number of milliseconds to wait for
    PPP based protocols to recover. The default is 300000 (300 seconds).


    References:

    IETF RFC 2516 "A Method for Transmitting PPP Over Ethernet (PPPoE)"

    https://tools.ietf.org/html/rfc2516


icmp.tcl

ICMP tests for generating various ICMP packets and NAPT of ICMP data

Test Module Name Synopsis
Verify ICMP Echo Requests (ping) work through router icmp.tcl cdrouter_icmp_1 Verify ICMP Echo Requests (ping) work through router


    step 1. Initiate an outbound ICMP Echo Request (ping) to a WAN destination
    step 2. Verify ICMP Echo Reply (ping response) is received



firewall.tcl

Firewall tests including port scans

Test Module Name Synopsis
Inbound TCP connections to public side HTTP port are blocked firewall.tcl cdrouter_firewall_1 Inbound TCP connections to public side HTTP port are blocked


    step 1. Initiate a WAN TCP connection to the router's public IP at port 80
    step 2. Verify the connection is not established
    step 3. Initiate a WAN TCP connection to the router's private IP at port 80
    step 4. Verify the connection is not established
    step 5. Initiate a LAN TCP connection to the router's private IP at port 80
    step 6. Verify the connection is established



ipsecpt.tcl

IPSEC based VPN pass through from the LAN to the WAN

Test Module Name Synopsis
Verify IKE packets pass through router on UDP port 500 ipsecpt.tcl cdrouter_ipsecpt_1 Verify IKE packets pass through router on UDP port 500


    step 1. Forward an IPSEC IKE packet from LAN to WAN
    step 2. Verify packets are passed in both directions



forward.tcl

Forwarding tests with different packet sizes and directions

Test Module Name Synopsis
Verify IPv4 TTL is decremented for forwarded packets forward.tcl cdrouter_forward_1 Verify IPv4 TTL is decremented for forwarded packets

    step 1. Forward an IP packet from a LAN client to the WAN
    step 2. Verify the TTL of the packet is decremented by 1


rip.tcl

RIPv1/v2 tests for LAN side of the router

Test Module Name Synopsis
Verify router sends RIPv1/v2 update on LAN side rip.tcl cdrouter_rip_1 Verify router sends RIPv1/v2 update on LAN side


    step 1. Listen for RIP reply from LAN side IP address of router
    step 2. Verify RIP version
    step 3. Verify source address of RIP reply

    NOTE: This test is only run if the 'ripSupported' configuration is
    set to 'yes'. The RIP version used for the test can be configured
    using the 'ripVersion' variable in your configuration file.


    References:

    IETF RFC 1058 "Routing Information Protocol"

    https://tools.ietf.org/html/rfc1058

    IETF RFC 2453 "RIP Version 2"

    https://tools.ietf.org/html/rfc2453


scaling.tcl

Scaling tests for maximum number of DHCP clients and connections (TCP, HTTP, VPN)

Test Module Name Synopsis
Verify all DHCP clients are operational scaling.tcl cdrouter_scale_1 Verify all DHCP clients are operational


    step 1. Determine the size of the IPv4 LAN address pool
    step 2. Create a DHCP client for each available IP address
    step 3. Verify each client obtains an IP address within the range
    step 4. Verify there are no address conflicts
    step 5. Verify each client can establish an outbound HTTP connection to the
            remote host on the WAN
    step 6. Verify each client can send/receive data over the HTTP connection
    step 7. Close each TCP connection
    step 8. Release all new DHCP client leases

    NOTE: The DHCP address pool size is set in your configuration file using
    the 'dhcpClientStart' and 'dhcpClientEnd' testvars. These values must
    match the values set on the DUT. The pool size used in the test may be
    reduced if the testvar 'ipv4MaxLanClients' is defined with a value in your
    configuration.

    One of the addresses remains in use through the test run for a host on the
    LAN side. This test will attempt to create clients for the pool size - 1.
    If you are using multiple LAN interfaces, the number of DHCP clients from
    each interface will also be subtracted from the DHCP pool size.

    NOTE: All DHCP clients created during this test will use unique MAC
    addresses that do not conflict with any DHCP reservations that may be
    defined. This test will also verify that all clients receive valid DHCP
    addresses from the dynamic pool. A failure will be generated if any client
    receives an invalid address from the DHCP server. Invalid addresses are
    defined as:

       * Addresses outside of the configured DHCP pool range
       * Excluded addresses defined by the 'dhcpClientExclude' testvar
       * Reserved addresses defined by the 'dhcpClientReservedIp[x]' and
         'dhcpClientReservedMac[x]' testvars


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol"

    https://tools.ietf.org/html/rfc2131


tr69.tcl

Additional TR-069 testing of the CPE device (beyond OD-128)

Test Module Name Synopsis
Verify Inform contains required parameters tr69.tcl tr69_1 Verify Inform contains required parameters


    step 1. Initiate a new CWMP connection using Connection Request URL
    step 2. Wait for new Inform from CPE
    step 3. Verify Inform contains required parameters
    step 4. For IGD 1.x, verify ExternalIPAddress of the default WAN interface
            is correct.

    Note that this test verifies the Inform requirements for CWMP 1.0 as
    defined in Broadband Forum TR-069 for IGD 1.x devices. The required
    Inform parameters for CWMP 1.1, defined in TR-069 Amendment 2, have
    been moved to TR-098 Amendment 2 Section 2.4.1. CWMP 1.1 specifies
    one additional required parameter as compared to CWMP 1.0
    InternetGatewayDevice.DeviceSummary.

    For newer IGD devices using the Device 2.0 data model, the required
    parameters are defined in TR-181 issue 2's data model with the forceInform
    attribute set to yes.

    NOTE: IGD devices based on 2.x are not required to include a WAN IP
    address.


    References:

    BBF CWMP Data Model InternetGatewayDevice:1.14 Root Data Model "TR-098 Issue 1 Amendment 8"

    https://cwmp-data-models.broadband-forum.org/tr-098-1-8-0.html

    BBF CWMP Data Model Device:1.14 Root Data Model "TR-181 Issue 1 Amendment 7"

    https://cwmp-data-models.broadband-forum.org/tr-181-1-7-0.html

    BBF CWMP Data Model Device:2.14 Root Data Model "TR-181 Issue 2 Amendment 14 Corrigendum 1"

    https://cwmp-data-models.broadband-forum.org/tr-181-2-14-1-cwmp.html

Test Module Name Synopsis
Verify GetParameterValues using empty string for top of hierarchy tr69.tcl tr69_10 Verify GetParameterValues using empty string for top of hierarchy


    step 1. Initiate a new CWMP connection using Connection Request URL
    step 2. Send GetParameterValues RPC using empty string
    step 3. Verify GetParameterValuesResponse or 9004 Soap Fault


    References:

    BBF TR-069 Issue 1 Amendment 6 "CPE WAN Management Protocol Version 1.4" Section A.3.2.2: GetParameterValues

    https://www.broadband-forum.org/download/TR-069_Amendment-6.pdf


basic-v6.tcl

Basic IPv6 extension header processing tests

Test Module Name Synopsis
Verify DUT forwards packets with multiple extension headers basic-v6.tcl ipv6_basic_1 Verify DUT forwards packets with multiple extension headers


    step 1. Generate a valid ICMPv6 Echo Request packet with the IPv6 Hop-by-Hop
    Options and Destination Options extension headers using the PadN and Pad1
    options, respectively

            Hop-by-Hop Options Header:
              Next Header        = 0x3c (Destination Options)
              Length             = 0x00 (8 bytes)
              Option Type        = 0x01 (PadN)
              Option Data Length = 0x04 (6 bytes)
              Option Data        = 0x00000000

            Destination Options Header:
              Next Header        = 0x3a (ICMP)
              Length             = 0x00 (8 bytes)
              Option Type        = 0x00 (Pad1)
              Option Type        = 0x00 (Pad1)
              Option Type        = 0x00 (Pad1)
              Option Type        = 0x00 (Pad1)
              Option Type        = 0x00 (Pad1)
              Option Type        = 0x00 (Pad1)

    step 2. Initiate an outbound ICMPv6 Echo Request to a WAN IPv6 destination
            using the extension headers generated in Step 1
    step 3. Verify that an ICMPv6 Echo Reply packet is received within 3 seconds


    References:

    IPv6 Ready Test Specification Core Protocols

    http://ipv6ready.org/docs/Core_Conformance_Latest.pdf

    IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4: IPv6 Extension Headers

    https://tools.ietf.org/html/rfc2460#section-4

    IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.2: Options

    https://tools.ietf.org/html/rfc2460#section-4.2

    IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.3: Hop-by-Hop Options Header

    https://tools.ietf.org/html/rfc2460#section-4.3

    IETF RFC 2460 "Internet Protocol, Version 6 (IPv6) Specification" Section 4.6: Destination Options Header

    https://tools.ietf.org/html/rfc2460#section-4.6


ndp.tcl

Neighbor Discovery Protocol and Router Advertisement tests for IPv6 devices

Test Module Name Synopsis
Verify DUT responds to Router Solicitations on the LAN ndp.tcl ipv6_ndp_1 Verify DUT responds to Router Solicitations on the LAN


    step 1. Send a Router Solicitation from the LAN
    step 2. Wait for a Router Advertisement from the DUT
    step 3. Verify the fields in the Router Advertisement


    References:

    IETF RFC 4861 "Neighbor Discovery for IP version 6 (IPv6)"

    https://tools.ietf.org/html/rfc4861


dhcpv6-pd.tcl

DHCPv6 prefix delegation tests for WAN to LAN IPv6 configuration

Test Module Name Synopsis
Verify client requests the assignment of an IPv6 prefix dhcpv6-pd.tcl dhcpv6_pd_1 Verify client requests the assignment of an IPv6 prefix


    step 1. Check existing DHCPv6 bindings on the WAN side of the CPE
    step 2. Verify whether or not prefix binding exists
    step 3. Verify Valid and Preferred lifetimes for binding
    step 4. Verify that the binding has not expired


    References:

    IETF RFC 3633 "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6" Section 12.1: Requesting router behavior

    The requesting router uses a Request message to populate IA_PDs with
    prefixes.  The requesting router includes one or more IA_PD options
    in the Request message.  The delegating router then returns the
    prefixes for the IA_PDs to the requesting router in IA_PD options in
    a Reply message.

    https://tools.ietf.org/html/rfc3633#section-12.1

Test Module Name Synopsis
Verify client renews prefix when current binding expires dhcpv6-pd.tcl dhcpv6_pd_2 Verify client renews prefix when current binding expires


    step 1. Wait for DHCPv6 client's current prefix binding
            T1 timer to expire
    step 2. Verify DHCPv6 client sends DHCPv6 Renew
    step 3. Verify Renew contains Server Identifier option (2) with correct
            server DUID
    step 4. Verify Renew contains IA_NA option (3) for same address
            prefix
    step 5. Send valid Reply to update binding


    References:

    IETF RFC 3633 "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6" Section 7: Overview of DHCP with Prefix Delegation

    Before the valid lifetime on each delegated prefix expires, the
    requesting router includes the prefix in an IA_PD option sent in a
    Renew message to the delegating router.  The delegating router
    responds by returning the prefix with updated lifetimes to the
    requesting router.

    https://tools.ietf.org/html/rfc3633#section-7


dhcpv6-s.tcl

DHCPv6 server tests for the LAN side of the router

Test Module Name Synopsis
Verify server assigns same address after client restart dhcpv6-s.tcl dhcpv6_server_1 Verify server assigns same address after client restart


    step 1. Restart DHCPv6 on LAN client without sending a Release to the server
    step 2. Verify that the server assigns an address to the client
    step 3. Verify that the address assigned by the server is the same as the
            client's original address


    References:

    IETF RFC 3315 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" Section 18.2.1: Receipt of Request Messages

    https://tools.ietf.org/html/rfc3315#section-18.2.1


6to4.tcl

6to4 tunnel tests for connecting IPv6 hosts over IPv4 networks

Test Module Name Synopsis
Verify IPv6 Router Advertisements include 6to4 prefix based on IPv4 WAN 6to4.tcl ipv6_6to4_1 Verify IPv6 Router Advertisements include 6to4 prefix based on IPv4 WAN


    step 1. Listen for IPv6 RA from DUT
    step 2. Verify RA contains 6to4 prefix based on public IPv4 WAN
    step 3. Verify 6to4 prefix contains a valid lifetime


    References:

    IETF RFC 3056 "Connection of IPv6 Domains via IPv4 Clouds" Section 2: IPv6 Prefix Allocation

    https://tools.ietf.org/html/rfc3056#section-2


6rd.tcl

6rd tunnel tests for connecting IPv6 hosts over IPv4 networks

Test Module Name Synopsis
Verify IPv6 Router Advertisements include 6rd prefix based on IPv4 WAN 6rd.tcl ipv6_6rd_1 Verify IPv6 Router Advertisements include 6rd prefix based on IPv4 WAN


    step 1. Listen for IPv6 RA from DUT
    step 2. Verify RA contains 6rd prefix based on public IPv4 WAN
    step 3. Verify 6rd prefix contains a valid lifetime


    References:

    IETF RFC 5969 "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)"

    https://tools.ietf.org/html/rfc5969


icmp-v6.tcl

ICMPv6 tests for baseline ICMPv6 not including Neighbor Discovery

Test Module Name Synopsis
Verify ICMPv6 Echo Requests work through DUT icmp-v6.tcl icmpv6_1 Verify ICMPv6 Echo Requests work through DUT


    step 1. Initiate an outbound ICMPv6 Echo Request to a WAN IPv6 destination
    step 2. Verify ICMPv6 Echo Reply is received


    References:

    IETF RFC 4443 "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification"

    https://tools.ietf.org/html/rfc4443


snmp.tcl

SNMP related test cases from the LAN side of the device

Test Module Name Synopsis
Verify SNMP agent supports MIB walk snmp.tcl snmp_100 Verify SNMP agent supports MIB walk


    step 1. Start the SNMP manager on the LAN using the settings and
            options defined for the default SNMP user
    step 2. Verify that the SNMP manager is able to walk the SNMP
            agent's MIB by sending consecutive GetNextRequest PDUs
            starting with the SNMPv2-SMI::internet OID
    step 3. Verify that the SNMP agent responds to the GetNextRequests
            sent by the SNMP manager


    References:

    IETF RFC 1157 "A Simple Network Management Protocol (SNMP)"

    https://tools.ietf.org/html/rfc1157

    IETF RFC 1901 "Introduction to Community-based SNMPv2"

    https://tools.ietf.org/html/rfc1901

    IETF RFC 3410 "Introduction and Applicability Statements for Internet Standard Management Framework"

    https://tools.ietf.org/html/rfc3410

Test Module Name Synopsis
Verify SNMP agent supports GetRequest snmp.tcl snmp_101 Verify SNMP agent supports GetRequest


    step 1. Start the SNMP manager on the LAN using the settings and
            options defined for the default SNMP user
    step 2. Send a GetRequest PDU to the SNMP agent for the
            SNMPv2-MIB::sysDescr OID
    step 3. Verify that the SNMP agent responds to the GetRequest sent
            by the SNMP manager


    References:

    IETF RFC 1157 "A Simple Network Management Protocol (SNMP)"

    https://tools.ietf.org/html/rfc1157

    IETF RFC 1901 "Introduction to Community-based SNMPv2"

    https://tools.ietf.org/html/rfc1901

    IETF RFC 3410 "Introduction and Applicability Statements for Internet Standard Management Framework"

    https://tools.ietf.org/html/rfc3410


nmap.tcl

Nmap based IPv4 portscan tests from the LAN side of the device

Test Module Name Synopsis
Nmap IPv4 TCP Connect scan nmap.tcl v4_lan_tcp_connect_info Nmap IPv4 TCP Connect scan


    step 1. Initiate a Nmap IPv4 TCP Connect scan from the LAN
    step 2. Display the final Nmap report

    References:

    Nmap Network Scanning "The Official Nmap Project Guide to Network Discovery and Security Scanning"

    https://nmap.org/book/toc.html

Test Module Name Synopsis
Nmap IPv4 TCP Syn scan nmap.tcl v4_lan_tcp_syn_info Nmap IPv4 TCP Syn scan


    step 1. Initiate a Nmap IPv4 TCP Syn scan from the LAN
    step 2. Display the final Nmap report

    References:

    Nmap Network Scanning "The Official Nmap Project Guide to Network Discovery and Security Scanning"

    https://nmap.org/book/toc.html


nmap-v6.tcl

Nmap based IPv6 portscan tests from the LAN side of the device

Test Module Name Synopsis
Nmap IPv6 TCP Connect scan nmap-v6.tcl v6_lan_tcp_connect_info Nmap IPv6 TCP Connect scan


    step 1. Initiate a Nmap IPv6 TCP Connect scan from the LAN
    step 2. Display the final Nmap report

    References:

    Nmap Network Scanning "The Official Nmap Project Guide to Network Discovery and Security Scanning"

    https://nmap.org/book/toc.html

Test Module Name Synopsis
Nmap IPv6 TCP Syn scan nmap-v6.tcl v6_lan_tcp_syn_info Nmap IPv6 TCP Syn scan


    step 1. Initiate a Nmap IPv6 TCP Syn scan from the LAN
    step 2. Display the final Nmap report

    References:

    Nmap Network Scanning "The Official Nmap Project Guide to Network Discovery and Security Scanning"

    https://nmap.org/book/toc.html


smb.tcl

SMB IPv4 storage tests

Test Module Name Synopsis
Verify SMB server responds to a service lookup smb.tcl smb_1 Verify SMB server responds to a service lookup


    step 1. Resolve the SMB server name using DNS or NetBIOS
    step 2. Start a new SMB client on the LAN
    step 3. Verify that the SMB client is able to log in to the SMB server and
            perform a service lookup
    step 4. Verify that the SMB server responds to the service lookup request


Test Module Name Synopsis
Verify SMB server allows directory listing smb.tcl smb_2 Verify SMB server allows directory listing


    step 1. Resolve the SMB server name using DNS or NetBIOS
    step 2. Start a new SMB client on the LAN
    step 3. Verify that the SMB client is able to log in to the SMB server and
            perform a directory listing
    step 4. Verify that the SMB server responds to the directory listing

    NOTE: CDRouter's SMB client will perform a directory listing on the folder
    specified by the testvars share and folder for the applicable smbuser



ftp.tcl

FTP IPv4 storage tests

Test Module Name Synopsis
Verify FTP server allows directory listing ftp.tcl ftp_2 Verify FTP server allows directory listing


    step 1. Resolve the FTP server name using DNS or NetBIOS
    step 2. Start a new FTP client on the LAN
    step 3. Verify that the FTP client is able to log in to the FTP server and
            perform a directory listing
    step 4. Verify that the FTP server responds to the directory listing

    NOTE: CDRouter's FTP client will perform a directory listing on the
    directory specified by the testvar path for the applicable ftpuser


    References:

    IETF RFC 959 "FILE TRANSFER PROTOCOL (FTP)"

    https://tools.ietf.org/html/rfc959

Test Module Name Synopsis
Verify FTP server allows name list command ftp.tcl ftp_3 Verify FTP server allows name list command


    step 1. Resolve the FTP server name using DNS or NetBIOS
    step 2. Start a new FTP client on the LAN
    step 3. Verify that the FTP client is able to log in to the FTP server and
            perform a name list command
    step 4. Verify that the FTP server responds to the name list

    NOTE: CDRouter's FTP client will perform a directory listing on the
    directory specified by the testvar path for the applicable ftpuser


    References:

    IETF RFC 959 "FILE TRANSFER PROTOCOL (FTP)"

    https://tools.ietf.org/html/rfc959


dhcp-docsis.tcl

DOCSIS CM DHCP client related tests

Test Module Name Synopsis
Verify CM DHCP client renews lease when current lease expires dhcp-docsis.tcl docsis_dhcp_1 Verify CM DHCP client renews lease when current lease expires


    step 1. Wait for DHCP lease to expire on CM
    step 2. Verify CM sends DHCPREQUEST for same IP address
    step 3. Reassign the same IP address


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol"

    https://tools.ietf.org/html/rfc2131

Test Module Name Synopsis
Verify CM DHCP client resends DHCPREQUEST packet if server does not respond dhcp-docsis.tcl docsis_dhcp_2 Verify CM DHCP client resends DHCPREQUEST packet if server does not respond


    step 1. Disable DOCSIS DHCP server
    step 2. Wait for DHCP lease to expire on CM
    step 3. Verify CM sends DHCPREQUEST for same IP address
    step 4. Do not respond to request
    step 5. Enable DOCSIS DHCP server
    step 6. Verify CM resends DHCPREQUEST for same IP address
    step 7. Respond to request and reassign the same IP address


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol"

    https://tools.ietf.org/html/rfc2131


usp_basic.tcl

Basic USP functionality tests

Test Module Name Synopsis
Verify that the Agent supports the Get message usp_basic.tcl usp_basic_1 Verify that the Agent supports the Get message


    Procedure:

    1. Send a Get message for Device.LocalAgent. to the Agent

    Test Metrics:

    1. Verify that the Agent sends a valid GetResp message to the Controller


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

Test Module Name Synopsis
Verify that the Agent supports the GetSupportedDM message usp_basic.tcl usp_basic_2 Verify that the Agent supports the GetSupportedDM message


    Procedure:

    1. Send a Get message for the Device.LocalAgent. to the Agent

    Test Metrics:

    1. Verify that the Agent sends a valid GetSupportedDMResp message to the
       Controller


    References:

    BBF TR-369 Version 1.1.2 "User Services Platform (USP)"

    https://usp.technology/

Contents

×

About CDRouter

QA Cafe CDRouter is a comprehensive and powerful test automation solution focused on feature, security, and performance testing for broadband and enterprise edge gateways, Wi-Fi and mesh systems, and other CPE.

Get in touch via our Contact page or by following us on your favorite service: