CDRouter Demo Test Summaries (Full)

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	Name	Synopsis
`Router responds to ARP request on LAN interface`	`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	Name	Synopsis
`DHCP client renews lease when current lease expires`	`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	Name	Synopsis
`PPPoE client restarts PPPoE Discovery when PPP LCP Echo-Requests fail`	`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 up to 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	Name	Synopsis
`PPP CHAP authentication with various size key lengths`	`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	Name	Synopsis
`Verify DHCP server returns same IP address when client renews`	`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	Name	Synopsis
`Outbound TCP connections use NAPT`	`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	Name	Synopsis
`Verify WAN client learns new IP address when WAN server renumbers`	`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	Name	Synopsis
`Verify WAN PPPoE client learns new IP address when WAN server renumbers`	`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	Name	Synopsis
`Verify ICMP Echo Requests (ping) work through router`	`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	Name	Synopsis
`Inbound TCP connections to public side HTTP port are blocked`	`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	Name	Synopsis
`Verify IKE packets pass through router on UDP port 500`	`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	Name	Synopsis
`Verify IPv4 TTL is decremented for forwarded packets`	`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	Name	Synopsis
`Verify router sends RIPv1/v2 update on LAN side`	`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	Name	Synopsis
`Verify all DHCP clients are operational`	`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	Name	Synopsis
`Verify Inform contains required parameters`	`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	Name	Synopsis
`Verify GetParameterValues using empty string for top of hierarchy`	`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	Name	Synopsis
`Verify DUT forwards packets with multiple extension headers`	`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	Name	Synopsis
`Verify DUT responds to Router Solicitations on the LAN`	`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	Name	Synopsis
`Verify client requests the assignment of an IPv6 prefix`	`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	Name	Synopsis
`Verify client renews prefix when current binding expires`	`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	Name	Synopsis
`Verify server assigns same address after client restart`	`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	Name	Synopsis
`Verify IPv6 Router Advertisements include 6to4 prefix based on IPv4 WAN`	`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	Name	Synopsis
`Verify IPv6 Router Advertisements include 6rd prefix based on IPv4 WAN`	`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	Name	Synopsis
`Verify ICMPv6 Echo Requests work through DUT`	`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	Name	Synopsis
`Verify SNMP agent supports MIB walk`	`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	Name	Synopsis
`Verify SNMP agent supports GetRequest`	`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	Name	Synopsis
`Nmap IPv4 TCP Connect scan`	`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	Name	Synopsis
`Nmap IPv4 TCP Syn scan`	`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	Name	Synopsis
`Nmap IPv6 TCP Connect scan`	`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	Name	Synopsis
`Nmap IPv6 TCP Syn scan`	`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	Name	Synopsis
`Verify SMB server responds to a service lookup`	`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	Name	Synopsis
`Verify SMB server allows directory listing`	`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	Name	Synopsis
`Verify FTP server allows directory listing`	`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	Name	Synopsis
`Verify FTP server allows name list command`	`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	Name	Synopsis
`Verify CM DHCP client renews lease when current lease expires`	`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	Name	Synopsis
`Verify CM DHCP client resends DHCPREQUEST packet if server does not respond`	`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	Name	Synopsis
`Verify that the Agent supports the Get message`	`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	Name	Synopsis
`Verify that the Agent supports the GetSupportedDM message`	`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/