CDRouter Support

CDRouter Test Summaries (Full)

test-summary version 13.3

Test Case Descriptions

  • Modules: 61
  • Test Cases: 740

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


Test Module Name Synopsis
Router responds to ARP request on WAN interface basic.tcl cdrouter_basic_2 Router responds to ARP request on WAN interface


    step 1. Send an ARP request for router's WAN IP address
    step 2. Verify that a valid ARP reply is received
    step 3. Verify that the MAC address in the ARP reply matches expected MAC
            address of the DUT's WAN interface

    NOTE: This test is only run if the WAN interface mode supports ARP. This
    test is skipped for wanMode PPPoE.

    NOTE: To configure the expected MAC address of the DUT's WAN interface,
    configure the testvar "wanDutMac". If this testvar is not defined, Step 3
    will be skipped.


Test Module Name Synopsis
Verify LAN DHCP clients receive gateway/DNS configuration from WAN side basic.tcl cdrouter_basic_10 Verify LAN DHCP clients receive gateway/DNS configuration from WAN side


    step 1. Start new DHCP client on LAN interface
    step 2. Verify the received DHCP options match the WAN configuration
    step 3. Verify network mask matches configured network mask
    step 4. Verify gateway is router's LAN IP address
    step 5. Verify DNS server is one of the following values:

            a. WAN ISP DNS server, if the testvar DNStoDHCP is set to 'yes'
            b. A user defined DNS server if the testvar lanDnsServer is enabled
               and the testvar DNStoDHCP is set to 'no'
            c. The DUT's LAN IP if the testvar lanDnsServer is disabled and the
              testvar DNStoDHCP is set to 'no'

    step 6. If the WAN is running DHCP, verify domain is WAN ISP domain name


Test Module Name Synopsis
Outbound packets use specified/cloned source MAC address basic.tcl cdrouter_basic_20 Outbound packets use specified/cloned source MAC address


    step 1. Send an ICMP Echo Request from the LAN to the remote host IPv4
    step 2. Verify that an ICMP Echo Request is received on the WAN
    step 3. Verify that the source MAC address in the ICMP Echo Request received
            on the WAN matches the expected MAC address of DUT's WAN interface

    NOTE: To configure the expected MAC address of the DUT's WAN interface,
    configure the testvar "wanDutMac". If this testvar is not defined, this test
    case will be skipped.



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


Test Module Name Synopsis
DHCP client resends DHCPREQUEST packet if server does not respond dhcp-c.tcl cdrouter_dhcp_2 DHCP client resends DHCPREQUEST packet if server does not respond


    step 1. Wait for DHCP lease to expire
    step 2. Verify WAN client sends DHCPREQUEST for same IP address
    step 3. Do not respond to request
    step 4. Verify WAN client resends DHCPREQUEST for same IP address
    step 5. Respond to request


Test Module Name Synopsis
DHCP client drops back into DISCOVERY mode if original server stops responding dhcp-c.tcl cdrouter_dhcp_3 DHCP client drops back into DISCOVERY mode if original server stops responding


        step 1. Disable DHCP server
        step 2. Wait for DHCP lease to expire for WAN DHCP client
        step 3. Verify WAN client sends DHCPREQUEST for same IP address
        step 4. Do not respond to request
        step 5. Verify WAN client resends DHCPREQUEST for same IP address
        step 6. Verify WAN client eventually sends DHCPDISCOVER

    
Test Module Name Synopsis
DHCP client drops back into DISCOVERY mode if server sends a DHCPNAK dhcp-c.tcl cdrouter_dhcp_4 DHCP client drops back into DISCOVERY mode if server sends a DHCPNAK


        step 1. Configure DHCP server to respond to all DHCP requests with
        DHCPNAK
        step 2. Wait for DHCP lease to expire for WAN DHCP client
        step 3. Verify WAN client sends DHCPREQUEST for same IP address
        step 4. Send DHCPNAK to WAN client
        step 5. Verify WAN client restarts DHCP and eventually sends DHCPDISCOVER
        before any other DHCP message
        step 6. Restore DHCP server's original behavior


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 3.2: Client-server interaction - reusing a previously allocated network address

    If the client receives a DHCPNAK message, it cannot reuse its
    remembered network address.  It must instead request a new
    address by restarting the configuration process, this time
    using the (non-abbreviated) procedure described in section
    3.1.  This action also corresponds to the client moving to
    the INIT state in the DHCP state diagram.

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

Test Module Name Synopsis
DHCP client remains in DISCOVERY mode if server sends a DHCPNAK dhcp-c.tcl cdrouter_dhcp_5 DHCP client remains in DISCOVERY mode if server sends a DHCPNAK


        step  1. Configure DHCP server to respond to all DHCP requests with
        DHCPNAK
        step  2. Wait for DHCP lease to expire for WAN DHCP client
        step  3. Send DHCPNAK to WAN client
        step  4. Verify WAN client restarts DHCP and eventually sends DHCPDISCOVER
        step  5. Send DHCPOFFER to WAN client
        step  6. Verify WAN client sends a broadcast DHCPREQUEST
        step  7. Send DHCPNAK to WAN client
        step  8. Verify WAN client restarts DHCP and eventually sends DHCPDISCOVER
        before any other DHCP message
        step  9. Restore DHCP server's original behavior
        step 10. Verify WAN client is assigned an IP address


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 3.1: Client-server interaction - allocating a network address

    If the client receives a DHCPNAK message, the client restarts the
    configuration process.

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

Test Module Name Synopsis
DHCP client ignores site-specific DHCP options dhcp-c.tcl cdrouter_dhcp_10 DHCP client ignores site-specific DHCP options


        step 1. Disable DHCP server to force client back to DISCOVERY mode
        step 2. Wait for DHCP lease to expire for WAN DHCP client
        step 3. Verify WAN client sends DHCPREQUEST for same IP address
        step 4. Do not respond to request
        step 5. Verify WAN client resends DHCPREQUEST for same IP address
        step 6. Verify WAN client eventually sends DHCPDISCOVER
        step 7. Enable DHCP server with site specific options
        step 8. Verify DHCP client is able to obtain new IP address

    
Test Module Name Synopsis
Verify DHCP client handles server option with length 0 dhcp-c.tcl cdrouter_dhcp_11 Verify DHCP client handles server option with length 0


        step 1. Disable DHCP server to force client back to DISCOVERY mode
        step 2. Wait for WAN DHCP client lease to expire
        step 3. Verify WAN client sends DHCPREQUEST for same IP address
        step 4. Do not respond to request
        step 5. Verify WAN client resends DHCPREQUEST for same IP address
        step 6. Verify WAN client eventually sends DHCPDISCOVER
        step 7. Enable DHCP server
        step 8. Add site specific option with length 0
        step 9. Verify client is able to obtain new IP address

    
Test Module Name Synopsis
DHCP client ignores DHCP packets with corrupt UDP checksum dhcp-c.tcl cdrouter_dhcp_20 DHCP client ignores DHCP packets with corrupt UDP checksum


        step 1. Configure DHCP server to send DHCP packets with corrupt UDP checksum
        step 2. Wait for WAN client DHCP lease to expire
        step 3. Verify WAN client sends DHCPREQUEST
        step 4. Verify server responds with invalid UDP checksum
        step 5. Verify WAN client eventually sends DHCPDISCOVER
        step 6. Verify WAN client sends a second DHCPDISCOVER
        step 7. Configure DHCP server to send valid UDP checksums
        step 8. Verify WAN client can now obtain an IP address

    
Test Module Name Synopsis
DHCP client includes vendor defined options dhcp-c.tcl cdrouter_dhcp_30 DHCP client includes vendor defined options


        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
        step 4. Search DHCPREQUEST for expected options

        The testvars wanDhcpClientOptionCode and wanDhcpClientOptionData can
        be used to configure a list of DHCP options that the client should
        include in requests sent to the DHCP server.

    
Test Module Name Synopsis
Verify client supports DHCP Rapid Commit option dhcp-c.tcl cdrouter_dhcp_31 Verify client supports DHCP Rapid Commit option


        step 1. Disable DHCP server
        step 2. Wait for DHCP lease to expire for WAN DHCP client
        step 3. Verify WAN client sends DHCPREQUEST
        step 4. Do not respond to request
        step 5. Verify WAN client eventually sends DHCPDISCOVER
        step 6. Verify DHCPDISCOVER contains Rapid Commit option


    References:

    IETF RFC 4039 "Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4)" Section 3.1: Client/Server Operation

    https://tools.ietf.org/html/rfc4039#section-3.1

Test Module Name Synopsis
Verify client supports DHCP Forcerenew Nonce Authentication dhcp-c.tcl cdrouter_dhcp_32 Verify client supports DHCP Forcerenew Nonce Authentication


        step 1. Verify DHCP Forcerenew Authentication nonce for WAN client
        exists
        step 2. Send DHCPFORCERENEW using client nonce
        step 3. Verify WAN client sends DHCPREQUEST packet


    References:

    IETF RFC 3203 "DHCP reconfigure extension" Section 2.2: Force renew procedures

    https://tools.ietf.org/html/rfc3203#section-2.2

    IETF RFC 6704 "Forcerenew Nonce Authentication" Section 3.1.4: Client Considerations for Forcerenew Nonce Authentication

    https://tools.ietf.org/html/rfc6704#section-3.1.4

Test Module Name Synopsis
Verify client ignores DHCPFORCERENEW without Authentication option dhcp-c.tcl cdrouter_dhcp_33 Verify client ignores DHCPFORCERENEW without Authentication option


        step 1. Verify DHCP Forcerenew Authentication nonce for WAN client
        exists
        step 2. Send DHCPFORCERENEW using client nonce without
        Authentication option
        step 3. Verify WAN client does not send DHCPREQUEST packet


    References:

    IETF RFC 3203 "DHCP reconfigure extension" Section 6: Security Considerations

    https://tools.ietf.org/html/rfc3203#section-6

Test Module Name Synopsis
Verify client ignores DHCPFORCERENEW authenticated with incorrect nonce dhcp-c.tcl cdrouter_dhcp_34 Verify client ignores DHCPFORCERENEW authenticated with incorrect nonce


        step 1. Verify DHCP Forcerenew Authentication nonce for WAN client
        exists
        step 2. Send DHCPFORCERENEW using incorrect client nonce
        step 3. Verify WAN client does not send DHCPREQUEST packet

        Reference:

        IETF RFC 6704 Section 3.1.4 "Client Considerations for Forcerenew Nonce Authentication"
        IETF RFC 6704 Section 5 "Security Considerations"


    References:

    IETF RFC 6704 "Forcerenew Nonce Authentication" Section 3.1.4: Client Considerations for Forcerenew Nonce Authentication

    https://tools.ietf.org/html/rfc6704#section-3.1.4

    IETF RFC 6704 "Forcerenew Nonce Authentication" Section 5: Security Considerations

    https://tools.ietf.org/html/rfc6704#section-5

Test Module Name Synopsis
Verify client ignores DHCPFORCERENEW messages on port 67 dhcp-c.tcl cdrouter_dhcp_35 Verify client ignores DHCPFORCERENEW messages on port 67


    step 1. Verify DHCP Forcerenew Authentication nonce for WAN client
            exists
    step 2. Send DHCPFORCERENEW to the client on port 67
    step 3. Verify WAN client does not send DHCPREQUEST packet


    References:

    IETF RFC 6704 "Forcerenew Nonce Authentication" Section 3.1.4: Client Considerations for Forcerenew Nonce Authentication

    https://tools.ietf.org/html/rfc6704#section-3.1.4

    IETF RFC 6704 "Forcerenew Nonce Authentication" Section 5: Security Considerations

    https://tools.ietf.org/html/rfc6704#section-5

Test Module Name Synopsis
Verify client ignores DHCPOFFER messages on port 67 dhcp-c.tcl cdrouter_dhcp_36 Verify client ignores DHCPOFFER messages on port 67


    step 1. Wait for the DHCP lease to expire on the DUT
    step 2. Configure the DHCP server to send a DHCPNACK
    step 3. Wait for the DUT to send a DHCPDISCOVER
    step 4. Send a DHCPOFFER to port 67
    step 5. Verify the DUT doesn't respond with a DHCPREQUEST


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4: Constructing and sending DHCP messages

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

Test Module Name Synopsis
Verify client requests same parameters in all subsequent DHCP messages dhcp-c.tcl cdrouter_dhcp_40 Verify client requests same parameters in all subsequent DHCP messages


    step 1.  Disable DHCP server
    step 2.  Wait for DHCP lease to expire for WAN DHCP client
    step 3.  Verify WAN client eventually sends DHCPDISCOVER
    step 4.  Record the DHCP Parameter Request List option in DHCPDISCOVER
    step 5.  Enable DHCP server
    step 6.  Verify WAN client sends DHCPREQUEST
    step 7.  Record the DHCP Parameter Request List in DHCPREQUEST
    step 8.  Verify WAN client sends DHCPREQUEST to renew lease
    step 9.  Record the DHCP Parameter Request List in DHCPREQUEST sent during
             renewal
    step 10. Verify DHCP Parameter Request List option contents are consistent
             across DHCP messages (verify that the steps 4, 7, and 9)


    References:

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

    If the client included a list of requested parameters in a DHCPDISCOVER
    message, it MUST include that list in all subsequent messages.

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

Test Module Name Synopsis
Verify client uses same Client ID in all subsequent DHCP messages dhcp-c.tcl cdrouter_dhcp_41 Verify client uses same Client ID in all subsequent DHCP messages


    step 1. Disable DHCP server
    step 2. Wait for DHCP lease to expire for WAN DHCP client
    step 3. Verify WAN client eventually sends DHCPDISCOVER
    step 4. Record the DHCP ClientID
    step 5. Enable DHCP server
    step 6. Verify WAN client sends DHCPREQUEST
    step 7. Record the DHCP ClientID
    step 8. Verify WAN client sends DHCPREQUEST for renewal
    step 9. Record the DHCP ClientID
    step 10. Verify DHCP ClientID is consistent across DHCP messages


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 2: Protocol Summary

    If the client uses a 'client identifier' in one message, it MUST use that
    same identifier in all subsequent messages, to ensure that all servers
    correctly identify the client.

    If the client does not use the DHCP Client ID option 61, the client ID will
    be the src MAC address.

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

Test Module Name Synopsis
Verify client uses a randomized exponential backoff algorithm for DHCPDISCOVER retransmissions dhcp-c.tcl cdrouter_dhcp_50 Verify client uses a randomized exponential backoff algorithm for DHCPDISCOVER retransmissions


    step 1. Disable DHCP server
    step 2. Wait for DHCP lease to expire for WAN DHCP client
    step 3. Verify WAN client sends DHCPREQUEST
    step 4. Do not respond to request
    step 5. Verify WAN client eventually sends DHCPDISCOVER
    step 6. Do not respond to discover
    step 7. Verify WAN client continues to retransmit DHCPDISCOVER
            using a randomized exponential backoff algorithm


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4.1: Constructing and sending DHCP messages

    DHCP clients are responsible for all message retransmission.  The
    client MUST adopt a retransmission strategy that incorporates a
    randomized exponential backoff algorithm to determine the delay
    between retransmissions.  The delay between retransmissions SHOULD be
    chosen to allow sufficient time for replies from the server to be
    delivered based on the characteristics of the internetwork between
    the client and the server.  For example, in a 10Mb/sec Ethernet
    internetwork, the delay before the first retransmission SHOULD be 4
    seconds randomized by the value of a uniform random number chosen
    from the range -1 to +1.  Clients with clocks that provide resolution
    granularity of less than one second may choose a non-integer
    randomization value.  The delay before the next retransmission SHOULD
    be 8 seconds randomized by the value of a uniform number chosen from
    the range -1 to +1.  The retransmission delay SHOULD be doubled with
    subsequent retransmissions up to a maximum of 64 seconds.  The client
    MAY provide an indication of retransmission attempts to the user as
    an indication of the progress of the configuration process.

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

Test Module Name Synopsis
DHCP client obtains lease when server delays responses dhcp-c.tcl cdrouter_dhcp_60 DHCP client obtains lease when server delays responses


        step 1. Disable DHCP server
        step 2. Wait for DHCP lease to expire for WAN DHCP client
        step 3. Verify WAN client sends DHCPREQUEST for same IP address
        step 4. Do not respond to request
        step 5. Verify WAN client eventually sends DHCPDISCOVER
        step 6. Do not respond to request
        step 7. Configure DHCP server to delay all responses
        step 8. Verify WAN client sends a second DHCPDISCOVER
        step 9. Verify WAN client can now obtain an IP address

        NOTE: The testvar dhcpServerResponseDelay can be used to
        specify the delay used by CDRouter's DHCP server on the WAN
        for this testcase.

    
Test Module Name Synopsis
DHCP client is able to rebind to alternate DHCP server dhcp-c.tcl cdrouter_dhcp_70 DHCP client is able to rebind to alternate DHCP server


        step 1.  Disable the DHCP server
        step 2.  Wait for the DUT to send a DHCPREQUEST to renew its lease
        step 3.  Ignore the DUT's requests and allow it to enter the REBINDING state
        step 4.  Verify that the DUT is in the REBIND state by checking that it
                 is broadcasting DHCPREQUESTs
        step 5.  Reconfigure the DHCP server to a new IP address and enable it
        step 6.  Allow the DHCP server to respond with an DHCPACK to the client
        step 7.  Send an ARP request to the client
        step 8.  Verify it was able to renew its original address by responding
                 to the ARP request
        step 9.  If a LAN client is configured ping a remote host from a LAN client
        step 10. Verify that traffic is correctly transmitted and the DUT is using
                 the new gateway
        step 11. Wait for another address renew from the DUT
        step 12. Verify the DUT has learned the new DHCP server address
        step 13. Verify that at no point did the DUT fall back into the INIT
                 state and broadcast DISCOVERY messages

        NOTE: steps 9 and 10 are optional and only performed if there
              is a LAN client configured.

    
    References:

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

    DHCPREQUEST generated during REBINDING state:

    In this situation, the client is completely
    configured, and is trying to extend its lease. This message MUST
    be broadcast to the 0xffffffff IP broadcast address.  The DHCP
    server SHOULD check 'ciaddr' for correctness before replying to
    the DHCPREQUEST.

    The DHCPREQUEST from a REBINDING client is intended to accommodate
    sites that have multiple DHCP servers and a mechanism for
    maintaining consistency among leases managed by multiple servers.
    A DHCP server MAY extend a client's lease only if it has local
    administrative authority to do so.

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


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.


Test Module Name Synopsis
PPPoE client restarts PPPoE Discovery when PPP LCP terminates PPP link pppoe-c.tcl cdrouter_pppoe_client_10 PPPoE client restarts PPPoE Discovery when PPP LCP terminates PPP link


    step 1. Check the current PPPoE session is established
    step 2. Terminate the current PPP session using LCP Terminate
    step 3. Verify WAN PPPoE client sends PADI to restart PPPoE Discovery
    step 4. Verify PPPoE client brings new PPPoE session up

    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).


Test Module Name Synopsis
PPPoE PPP client replies to LCP Echo-Requests pppoe-c.tcl cdrouter_pppoe_client_50 PPPoE PPP client replies to LCP Echo-Requests


    step 1. Send 5 LCP Echo-Requests
    step 2. Verify LCP Echo-Replies are received
    step 3. Verify LCP Echo-Request data is echoed back in response


Test Module Name Synopsis
PPPoE PPP client maintains LCP Magic Number during session pppoe-c.tcl cdrouter_pppoe_client_60 PPPoE PPP client maintains LCP Magic Number during session


    step 1. Terminate the current PPP session using LCP Terminate
    step 2. Check for Magic Number in LCP Configure Request
    step 3. Wait for LCP Echo Request and verify Magic Number is the same
    step 4. Send LCP Echo Request
    step 5. Verify Magic Number in LCP Echo Response is the same

    NOTE: CDRouter does not fail this test if the PPPoE PPP client
    does not send an LCP Echo Request. Some clients do not
    use LCP Echo Requests automtically.


    References:

    IETF RFC 1548 "The Point-to-Point Protocol (PPP)" Section 5.8: Echo-Request and Echo-Reply

    https://tools.ietf.org/html/rfc1548#section-5.8

Test Module Name Synopsis
PPPoE/PPP restarts if PPP authentication fails pppoe-c.tcl cdrouter_pppoe_client_200 PPPoE/PPP restarts if PPP authentication fails


    step 1. Terminate the current PPP session using LCP Terminate
    step 2. Verify WAN PPPoE client sends PADI to restart PPPoE Discovery
    step 3. Verify PPPoE client brings new PPPoE session up
    step 4. Reject any PAP or CHAP authentication attempts
    step 5. Wait 60 seconds, continuing to reject PPP authentication
    step 6. Accept PPP authentication after 60 seconds
    step 7. Send pings from LAN side to WAN side to force link to reestablish
    step 8. Verify PPP link is reestablished in 300 seconds (pppRestartTimeout)

    NOTE: This test supports PAP, CHAP, and MSCHAP authentication.

    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).

Test Module Name Synopsis
PPPoE/PPP can recover if LCP renegotiation is attempted pppoe-c.tcl cdrouter_pppoe_client_210 PPPoE/PPP can recover if LCP renegotiation is attempted


    step 1. Send LCP Configure-Request to PPP peer
    step 2. Verify peer resends LCP configuration
    step 3. Verify the configuration is the same
    step 4. If the PPPoE link is terminated, issue ping to reestablish link
    step 5. Verify ping succeeds from LAN to WAN

    NOTE: Renegotiating LCP can cause some PPP implementations to terminate
    the PPP link or the PPPoE link. This test does not fail the DUT if this
    happens, but it does issue a warning if the PPPoE session is restarted.

    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).

Test Module Name Synopsis
PPPoE/PPP can recover if LCP Echo-Request contains bad length pppoe-c.tcl cdrouter_pppoe_client_230 PPPoE/PPP can recover if LCP Echo-Request contains bad length


    step 1. Send out LCP Echo-Request with length 4096, but no data
    step 2. Peer may respond or drop LCP Echo-Request
    step 3. Verify PPP is still functioning using ICMP Echo

    NOTE: This test checks that the device under test behaves gracefully
    when it receives PPP options with a bad length. Some devices may
    still respond to the LCP Echo-Request, but it is not considered a failure if
    the device does not respond.

Test Module Name Synopsis
PPPoE client recovers if PPPoE server drops PADR from PPPoE client pppoe-c.tcl cdrouter_pppoe_client_300 PPPoE client recovers if PPPoE server drops PADR from PPPoE client


    step 1. Terminate the current PPP session using LCP Terminate
    step 2. Verify WAN PPPoE client sends PADI to restart PPPoE Discovery
    step 3. Do not respond to the PADR packet from client
    step 4. Continue to ignore any PPPoE packets from the client until
            the client sends a new PADI packet
    step 5. Restore PPPoE server to normal operation
    step 6. Verify PPPoE client session recovers

    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)" Section 8: Other Considerations

    If the Host is waiting to receive a PADS packet, a similar timeout
    mechanism SHOULD be used, with the Host re-sending the PADR.  After
    a specified number of retries, the Host SHOULD then resend a PADI
    packet.

    https://tools.ietf.org/html/rfc2516#section-8

Test Module Name Synopsis
PPPoE client returns AC-Cookie in PADR when server sends AC-Cookie in PADO pppoe-c.tcl cdrouter_pppoe_client_310 PPPoE client returns AC-Cookie in PADR when server sends AC-Cookie in PADO


    step 1. Configure PPPoE server to use AC-Cookie Tag in PADO responses
    step 2. Terminate the current PPP session using LCP Terminate
    step 3. Verify WAN PPPoE client sends PADI to restart PPPoE Discovery
    step 4. Send AC-Cookie Tag in PADO
    step 5. Verify PADR from client contains AC-Cookie with the same cookie data


    References:

    IETF RFC 2516 "A Method for Transmitting PPP Over Ethernet (PPPoE)" Section A: AC-Cookie

    If a Host receives this TAG, it MUST return the TAG
    unmodified in the following PADR.

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

Test Module Name Synopsis
PPPoE client maintains Relay-Session-Id during PPPoE session establishment pppoe-c.tcl cdrouter_pppoe_client_320 PPPoE client maintains Relay-Session-Id during PPPoE session establishment


    step 1. Configure PPPoE server to use Relay-Session-Id in PADO responses
    step 2. Terminate the current PPP session using LCP Terminate
    step 3. Verify WAN PPPoE client sends PADI to restart PPPoE Discovery
    step 4. If the PADI already contains a Relay-Session-Id from an actual
            PPPoE Relay server, configure the PPPoE server to use the same
            tag value
    step 5. Send Relay-Session-Id Tag in PADO
    step 6. Verify PADR from client contains Relay-Session-Id tag with the same cookie data

    NOTE: Normally, CDRouter does not expect a PPPoE relay server to be present
    between the PPPoE client and CDRouter. However, this test does check for
    an existing Relay-Session-Id in the PADI and will use this tag value
    for the test instead of generating a unique value. This allows the test
    to work with an existing PPPoE relay server on the WAN.


    References:

    IETF RFC 2516 "A Method for Transmitting PPP Over Ethernet (PPPoE)" Section A: Relay-Session-Id

    If either the Host or Access Concentrator receives this TAG they
    MUST include it unmodified in any discovery packet they send as a response.

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

Test Module Name Synopsis
PPPoE client sends PADT packet after idle timeout elapses pppoe-c.tcl cdrouter_pppoe_client_330 PPPoE client sends PADT packet after idle timeout elapses


    step 1. Ping from LAN to WAN to refresh idle timeout
    step 2. Disable LAN client to prevent LAN to WAN traffic
    step 3. Verify PPPoE client sends PADT packet after a configured
            period of inactivity

    NOTE: The amount of time the test waits to for the PADT packet can
    be configured by adjusting the testvar pppoeIdleTimeout.  This
    variable contains the number of seconds to wait for PPPoE
    connections to timeout when idling. The default is 60 seconds.

    NOTE: This test is skipped if the testvar pppoeConnectOnDemand is
    set to no.

Test Module Name Synopsis
Verify PPPoE client sends correct PPP-Max-Payload tag in PADI packets pppoe-c.tcl cdrouter_pppoe_client_400 Verify PPPoE client sends correct PPP-Max-Payload tag in PADI packets


    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 the PADI contains a PPP-Max-Payload tag whose value
            matches that of the testvar pppoeMaxPayload.
    step 6. Verify PPPoE client brings new PPPoE session up


    References:

    IETF RFC 4638 "Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point Protocol over Ethernet (PPPoE)"

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


pptp-c.tcl

PPTP client tests for the WAN side of the router

Test Module Name Synopsis
PPTP client restarts PPTP connection when PPTP Echo Requests fail pptp-c.tcl cdrouter_pptp_5 PPTP client restarts PPTP connection when PPTP Echo Requests fail


    step 1. Turn off PPTP Echo Replies on PPTP server
    step 2. Verify WAN PPTP client closes PPTP TCP connection
            (wait upto 5 minutes for PPTP to failover)
    step 3. Continue to send data from LAN to WAN to initiate new connection
    step 4. Verify PPTP client establishes new PPTP control session
    step 5. Verify PPTP client establishes new PPTP outbound call session
    step 6. Verify LAN side can reach WAN using new PPTP call id

    NOTE: By default, CDRouter will still respond to ICMP Echo
    Requests during this test. This allows the test to verify failure
    occures 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:


    References:

    IETF RFC 2637 "Point-to-Point Tunneling Protocol (PPTP)" Section 3.1.4: Keep Alives and Timers

    https://tools.ietf.org/html/rfc2637#section-3.1.4

Test Module Name Synopsis
PPTP client restarts PPTP connection when PPP LCP terminates PPP link pptp-c.tcl cdrouter_pptp_10 PPTP client restarts PPTP connection when PPP LCP terminates PPP link


    step 1. Terminate the current PPP session using LCP Terminate
    step 2. Verify WAN PPTP client closes PPTP TCP session
    step 3. Continue to send data from LAN to WAN to initiate new connection
    step 4. Verify PPTP client establishes new PPTP control session
    step 5. Verify PPTP client establishes new PPTP outbound call session
    step 6. Verify LAN side can reach WAN using new PPTP call id


    References:

    IETF RFC 2637 "Point-to-Point Tunneling Protocol (PPTP)"

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

Test Module Name Synopsis
PPTP client restarts PPTP connection when TCP control session is closed pptp-c.tcl cdrouter_pptp_20 PPTP client restarts PPTP connection when TCP control session is closed


    step 1. Initiate TCP close on PPTP control session by sending TCP FIN
    step 2. Verify WAN PPTP client closes PPTP TCP connection
    step 3. Continue to send data from LAN to WAN to initiate new connection
    step 4. Verify PPTP client establishes new PPTP control session
    step 5. Verify PPTP client establishes new PPTP outbound call session
    step 6. Verify LAN side can reach WAN using new PPTP call id

    NOTE: The behavior of the router when the PPTP TCP control session is
    lost is not well defined by RFC 2637. On some implementations, this
    causes the PPTP client to restart its control session. In the worst
    case, the PPTP client should detect a dead connection through PPTP
    Echo Request failires. At this point, the PPTP control session should
    be restarted.


    References:

    IETF RFC 2637 "Point-to-Point Tunneling Protocol (PPTP)" Section 3.1.4: Keep Alives and Timers

    https://tools.ietf.org/html/rfc2637#section-3.1.4

Test Module Name Synopsis
PPTP client restarts PPTP connection when TCP control session is reset pptp-c.tcl cdrouter_pptp_25 PPTP client restarts PPTP connection when TCP control session is reset


    step 1. Send TCP RST for PPTP control session
    step 2. Continue to send data from LAN to WAN to initiate new connection
    step 3. Verify PPTP client establishes new PPTP control session
    step 4. Verify PPTP client establishes new PPTP outbound call session
    step 5. Verify LAN side can reach WAN using new PPTP call id

    NOTE: The behavior of the router when the PPTP TCP control session is
    lost is not well defined by RFC 2637. On some implementations, this
    causes the PPTP client to restart its control session. In the worst
    case, the PPTP client should detect a dead connection through PPTP
    Echo Request failires. At this point, the PPTP control session should
    be restarted.


    References:

    IETF RFC 2637 "Point-to-Point Tunneling Protocol (PPTP)" Section 3.1.4: Keep Alives and Timers

    https://tools.ietf.org/html/rfc2637#section-3.1.4

Test Module Name Synopsis
PPTP client initiates new call after a PPTP Call-Disconnect-Notify pptp-c.tcl cdrouter_pptp_30 PPTP client initiates new call after a PPTP Call-Disconnect-Notify


    step 1. Send PPTP Call-Disconnect-Notify for existing Call ID
    step 2. Continue to send data from LAN to WAN to initiate new call
    step 3. Verify PPTP client establishes new PPTP outbound call
    step 4. Verify LAN side can reach WAN using new PPTP call id

    NOTE: Some implementations may close the PPTP control session if
    the PPTP call is disconnected. This test does not consider this a
    failure as long as a valid PPTP outbound call is reestablished.


    References:

    IETF RFC 2637 "Point-to-Point Tunneling Protocol (PPTP)"

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

Test Module Name Synopsis
PPTP PPP client replies to LCP Echo Requests pptp-c.tcl cdrouter_pptp_50 PPTP PPP client replies to LCP Echo Requests


    step 1. Send 5 LCP Echo Requests
    step 2. Verify LCP Echo Replies are received
    step 3. Verify LCP Echo Request data is echoed back in response


Test Module Name Synopsis
PPTP PPP client maintains LCP Magic Number during session pptp-c.tcl cdrouter_pptp_60 PPTP PPP client maintains LCP Magic Number during session


    step 1. Terminate the current PPP session using LCP Terminate
    step 2. Check for Magic Number in LCP Configure Request
    step 3. Wait for LCP Echo Request and verify Magic Number is the same
    step 4. Send LCP Echo Request
    step 5. Verify Magic Number in LCP Echo Response is the same

    RFC 1548 The Point-to-Point Protocol
    5.8 Echo-Request and Echo-Reply

    NOTE: CDRouter does not fail this test if the PPTP PPP client
    does not send an LCP Echo Request. Some clients do not
    use LCP Echo Requests automtically.

Test Module Name Synopsis
PPTP/PPP restarts if PPP authentication fails pptp-c.tcl cdrouter_pptp_200 PPTP/PPP restarts if PPP authentication fails


    step 1. Terminate the current PPP session using LCP Terminate
    step 2. Verify PPTP client closes current PPTP control session
    step 3. Continue to send data from LAN to WAN
    step 4. Reject any PAP or CHAP authentication attempts
    step 5. Wait 60 seconds, continuing to reject PPP authentication
    step 6. Accept PPP authentication after 60 seconds
    step 7. Verify PPP link is reestablished in 120 seconds

    Note: This test supports PAP and CHAP authentication.

Test Module Name Synopsis
PPTP/PPP can recover if LCP renegotiation is attempted pptp-c.tcl cdrouter_pptp_210 PPTP/PPP can recover if LCP renegotiation is attempted


    step 1. Send out LCP Configure-Request to PPP peer
    step 2. Verify peer resends LCP configuration
    step 3. Verify the configuration is the same
    step 4. Verify ping succeeds from LAN to WAN

    NOTE: Renegotiating LCP has can cause some PPP implementations to terminate
    the PPP link or the PPTP link. This test does not fail the DUT if this
    happens, but it does issue a warning if the PPTP session is restarted.


Test Module Name Synopsis
PPTP/PPP can recover if LCP Echo Request contains bad length pptp-c.tcl cdrouter_pptp_230 PPTP/PPP can recover if LCP Echo Request contains bad length


    step 1. Send LCP Echo Request with length 4096, but no data
    step 2. Peer may respond or drop LCP Echo Request
    step 3. Verify PPP is still functioning using ICMP echo

    NOTE: This test checks that the device under test behaves gracefully
    when it receives PPP options with a bad length. Some devices may
    still respond to the LCP Echo Request, but its not considered a failure if
    the device does not respond.


l2tp-c.tcl

L2TP client tests for WAN side of the router

Test Module Name Synopsis
L2TP client restarts L2TP connection when L2TP Hello Requests are unanswered l2tp-c.tcl cdrouter_l2tp_5 L2TP client restarts L2TP connection when L2TP Hello Requests are unanswered


    step 1. Turn off L2TP Hello Replies on L2TP server
    step 2. Halt traffic on the L2TP tunnel
    step 3. Verify the L2TP client sends L2TP Hello Requests to the server
    step 4. Verify WAN L2TP client closes L2TP tunnel
    step 5. Continue to send data from LAN to WAN to initiate new connection
    step 6. Verify L2TP client establishes new L2TP session
    step 7. Verify LAN side can reach WAN using new L2TP session


    References:

    IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""

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

Test Module Name Synopsis
L2TP client restarts L2TP connection when PPP LCP terminates PPP link l2tp-c.tcl cdrouter_l2tp_10 L2TP client restarts L2TP connection when PPP LCP terminates PPP link


    step 1. Terminate the current PPP session using LCP Terminate
    step 2. Verify WAN L2TP client closes L2TP TCP session
    step 3. Continue to send data from LAN to WAN to initiate new connection
    step 4. Verify L2TP client establishes new L2TP session
    step 5. Verify LAN side can reach WAN using new L2TP call id


    References:

    IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""

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

Test Module Name Synopsis
L2TP client initiates new L2TP connection after closing tunnel with StopCCN l2tp-c.tcl cdrouter_l2tp_20 L2TP client initiates new L2TP connection after closing tunnel with StopCCN


    step 1.  Send the StopCCN command to close the active L2TP tunnel
    step 2.  Continue to send data from the LAN to WAN to initiate a new tunnel
    step 3.  Verify L2TP client establishes a new L2TP tunnel
    step 4.  Verify LAN side can reach WAN using new L2TP tunnel


    References:

    IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""

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

Test Module Name Synopsis
L2TP client initiates new L2TP tunnel after receiving CDN and StopCCN l2tp-c.tcl cdrouter_l2tp_30 L2TP client initiates new L2TP tunnel after receiving CDN and StopCCN


    step 1. Send Call-Disconnect-Notify for the L2TP session
    step 2. Send StopCCN for L2TP tunnel
    step 3. Continue to send data from LAN to WAN to initiate new tunnel
    step 4. Verify L2TP client establishes new L2TP tunnel
    step 5. Verify LAN side can reach WAN using new L2TP tunnel


    References:

    IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""

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

Test Module Name Synopsis
L2TP client sends HELLO after period of inactivity l2tp-c.tcl cdrouter_l2tp_40 L2TP client sends HELLO after period of inactivity


    step 1. Stop PPP from passing traffic to the WAN
    step 2. Continue to send data from LAN to WAN
    step 3. Verify L2TP sends HELLO message to L2TP server
    step 4. Respond to HELLO
    step 5. Reestablish PPP traffic from WAN
    step 6. Verify LAN-WAN communication resumes


    References:

    IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""

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

Test Module Name Synopsis
L2TP PPP client replies to LCP Echo Requests l2tp-c.tcl cdrouter_l2tp_50 L2TP PPP client replies to LCP Echo Requests


    step 1. Send 5 LCP Echo Requests
    step 2. Verify LCP Echo Replies are received
    step 3. Verify LCP Echo Request data is echoed back in reply


    References:

    IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""

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

Test Module Name Synopsis
L2TP PPP client maintains LCP Magic Number during session l2tp-c.tcl cdrouter_l2tp_60 L2TP PPP client maintains LCP Magic Number during session


    step 1. Terminate the current PPP session using LCP Terminate
    step 2. Check for Magic Number in LCP Configure Request
    step 3. Wait for LCP Echo Request and verify Magic Number is the same
    step 4. Send LCP Echo Request
    step 5. Verify Magic Number in LCP Echo Response is the same

    RFC 1548 The Point-to-Point Protocol
    5.8 Echo-Request and Echo-Reply

    NOTE: CDRouter does not fail this test if the L2TP PPP client
    does not send an LCP Echo Request. Some clients do not
    use LCP Echo Requests automatically.

    References:

    IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""

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

Test Module Name Synopsis
L2TP/PPP restarts if PPP authentication fails l2tp-c.tcl cdrouter_l2tp_200 L2TP/PPP restarts if PPP authentication fails


    step 1. Terminate the current PPP session using LCP Terminate
    step 2. Verify L2TP client closes current L2TP control session
    step 3. Continue to send data from LAN to WAN
    step 4. Reject any PAP or CHAP authentication attempts
    step 5. Wait 60 seconds, continuing to reject PPP authentication
    step 6. Accept PPP authentication after 60 seconds
    step 7. Verify PPP link is reestablished in 120 seconds

    Note: This test supports PAP and CHAP authentication.


    References:

    IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""

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

Test Module Name Synopsis
L2TP/PPP can recover if LCP renegotiation is attempted l2tp-c.tcl cdrouter_l2tp_210 L2TP/PPP can recover if LCP renegotiation is attempted


    step 1. Send LCP config request to PPP peer
    step 2. Verify peer resends LCP configuration
    step 3. Verify the configuration is the same
    step 4. Verify ping succeeds from LAN to WAN

    NOTE: Renegotiating LCP has can cause some PPP implementations to terminate
    the PPP link or the L2TP link. This test does not fail the DUT if this
    happens, but it does issue a warning if the L2TP session is restarted.


    References:

    IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""

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

Test Module Name Synopsis
L2TP/PPP can recover if LCP Echo Request contains bad length l2tp-c.tcl cdrouter_l2tp_230 L2TP/PPP can recover if LCP Echo Request contains bad length


    step 1. Send LCP Echo Request with length 4096, but no data
    step 2. Peer may respond or drop LCP Echo Request
    step 3. Verify PPP is still functioning using ICMP Echo Request

    NOTE: This test checks that the device under test behaves gracefully
    when it receives PPP options with a bad length. Some devices may
    still respond to the LCP Echo Request, but its not considered a failure if
    the device does not respond.


    References:

    IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""

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


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

Test Module Name Synopsis
Verify PPP client will reauthenticate using CHAP during active connection chap.tcl cdrouter_chap_20 Verify PPP client will reauthenticate using CHAP during active connection


    step 1. Send CHAP Challenge to PPP client
    step 2. Verify CHAP Response is received in 10 seconds
    step 3. Repeat for 30 CHAP Challenges will link remains active


    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

Test Module Name Synopsis
Verify DHCP server rejects DHCPREQUESTS with non-offered IP address dhcp-s.tcl cdrouter_dhcp_server_2 Verify DHCP server rejects DHCPREQUESTS with non-offered IP address


    step 1. Send DHCPRELEASE to release DHCP client address on LAN
    step 2. Configure DHCP client on LAN to include invalid 'Requested IP
            Address' option
    step 3. Restart DHCP client on LAN
    step 4. Wait for DHCPOFFER from DHCP server and send DHCPREQUEST with
            invalid 'Requested IP Address' option configured in step 2
    step 5. Verify DHCP server sends DHCPNAK
    step 6. Restore original behavior
    step 7. Restart DHCP client on LAN and verify that client receives a
            valid address


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 3.5: Client parameters in DHCP

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

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

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

Test Module Name Synopsis
Verify DHCP server address reservations dhcp-s.tcl cdrouter_dhcp_server_3 Verify DHCP server address reservations


    step 1. Build a list of DHCP address reservations
    step 2. Start new DHCP client on LAN interface using reserved client MAC
    step 3. Verify DHCP client obtains expected reserved IP address
    step 4. Repeat for each DHCP address reservation identified in step 1

    NOTE: Many DHCP server implementations allow addresses within the DHCP pool
    to be reserved for specific clients based on the client's MAC address. This
    test verifies that the DHCP server honors any configured client MAC to IP
    address reservations as defined by the testvars 'dhcpClientReservedIp'
    and 'dhcpClientReservedMac'.

    Example for two reserved addresses:

    testvar dhcpClientReservedIp1   192.168.1.10
    testvar dhcpClientReservedMac1  00:11:22:33:33:44

    testvar dhcpClientReservedIp2   192.168.1.15
    testvar dhcpClientReservedMac2  00:11:22:33:33:55


Test Module Name Synopsis
Verify DHCP server returns IP address within configured pool dhcp-s.tcl cdrouter_dhcp_server_4 Verify DHCP server returns IP address within configured pool


    step 1. Send DHCPRELEASE to release DHCP client address on LAN
    step 2. Restart DHCP client on LAN
    step 3. Verify DHCP client receives an address from within the configured
            DHCP pool

    Note: The DHCP pool is configured using the testvars dhcpClientStart and
    dhcpClientEnd. These testvars must match the DHCP pool settings on the
    DUT.


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol"

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

Test Module Name Synopsis
Verify DHCP server returns IP address with expected lease time dhcp-s.tcl cdrouter_dhcp_server_5 Verify DHCP server returns IP address with expected lease time


    step 1. Send DHCPRELEASE to release DHCP client address on LAN
    step 2. Restart DHCP client on LAN
    step 3. Verify DHCP client receives an address with the expected lease time

    Note: The expected DHCP lease time is configured using the testvar
    dhcpClientLeaseTime. This testvar should match the value configured on the
    DUT's DHCP server.


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol"

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

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


    step 1. Send DHCPDISCOVER to restart DHCP client on LAN
    step 2. Verify DHCP client receives the same IP address


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4.3.1: DHCPDISCOVER message

    When a server receives a DHCPDISCOVER message from a client, the
    server chooses a network address for the requesting client.  If no
    address is available, the server may choose to report the problem to
    the system administrator. If an address is available, the new address
    SHOULD be chosen as follows:

      * The client's current address as recorded in the client's current
        binding, ELSE

      * The client's previous address as recorded in the client's (now
        expired or released) binding, if that address is in the server's
        pool of available addresses and not already allocated, ELSE

      * The address requested in the 'Requested IP Address' option, if that
        address is valid and not already allocated, ELSE

      * A new address allocated from the server's pool of available
        addresses; the address is selected based on the subnet from which
        the message was received (if 'giaddr' is 0) or on the address of
        the relay agent that forwarded the message ('giaddr' when not 0).

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

Test Module Name Synopsis
Verify DHCP server returns same IP address when client releases then restarts dhcp-s.tcl cdrouter_dhcp_server_7 Verify DHCP server returns same IP address when client releases then restarts


    step 1. Send DHCPRELEASE to release DHCP client address on LAN
    step 2. Send DHCPDISCOVER to restart DHCP client on LAN
    step 3. Verify DHCP client receives the same IP address


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4.3.1: DHCPDISCOVER message

    When a server receives a DHCPDISCOVER message from a client, the
    server chooses a network address for the requesting client.  If no
    address is available, the server may choose to report the problem to
    the system administrator. If an address is available, the new address
    SHOULD be chosen as follows:

      * The client's current address as recorded in the client's current
        binding, ELSE

      * The client's previous address as recorded in the client's (now
        expired or released) binding, if that address is in the server's
        pool of available addresses and not already allocated, ELSE

      * The address requested in the 'Requested IP Address' option, if that
        address is valid and not already allocated, ELSE

      * A new address allocated from the server's pool of available
        addresses; the address is selected based on the subnet from which
        the message was received (if 'giaddr' is 0) or on the address of
        the relay agent that forwarded the message ('giaddr' when not 0).

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

Test Module Name Synopsis
Verify DHCP server returns same IP address when client restarts using Requested IP Address option dhcp-s.tcl cdrouter_dhcp_server_8 Verify DHCP server returns same IP address when client restarts using Requested IP Address option


    step 1. Configure DHCP client to use Requested IP Address option (DHCP
            option 50) with current IP address as value
    step 2. Send DHCPDISCOVER to restart DHCP client on LAN
    step 3. Verify DHCP client receives the same IP address


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4.3.1: DHCPDISCOVER message

    When a server receives a DHCPDISCOVER message from a client, the
    server chooses a network address for the requesting client.  If no
    address is available, the server may choose to report the problem to
    the system administrator. If an address is available, the new address
    SHOULD be chosen as follows:

      * The client's current address as recorded in the client's current
        binding, ELSE

      * The client's previous address as recorded in the client's (now
        expired or released) binding, if that address is in the server's
        pool of available addresses and not already allocated, ELSE

      * The address requested in the 'Requested IP Address' option, if that
        address is valid and not already allocated, ELSE

      * A new address allocated from the server's pool of available
        addresses; the address is selected based on the subnet from which
        the message was received (if 'giaddr' is 0) or on the address of
        the relay agent that forwarded the message ('giaddr' when not 0).

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

Test Module Name Synopsis
Verify DHCP server returns same IP address when client releases and restarts using Requested IP Address option dhcp-s.tcl cdrouter_dhcp_server_9 Verify DHCP server returns same IP address when client releases and restarts using Requested IP Address option


    step 1. Configure DHCP client to use Requested IP Address option (DHCP
            option 50) with current IP address as value
    step 2. Send DHCPRELEASE to release DHCP client address on LAN
    step 3. Send DHCPDISCOVER to restart DHCP client on LAN using Requested IP
            Address option in DHCPDISCOVER
    step 4. Verify DHCP client receives the same IP address


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4.3.1: DHCPDISCOVER message

    When a server receives a DHCPDISCOVER message from a client, the
    server chooses a network address for the requesting client.  If no
    address is available, the server may choose to report the problem to
    the system administrator. If an address is available, the new address
    SHOULD be chosen as follows:

      * The client's current address as recorded in the client's current
        binding, ELSE

      * The client's previous address as recorded in the client's (now
        expired or released) binding, if that address is in the server's
        pool of available addresses and not already allocated, ELSE

      * The address requested in the 'Requested IP Address' option, if that
        address is valid and not already allocated, ELSE

      * A new address allocated from the server's pool of available
        addresses; the address is selected based on the subnet from which
        the message was received (if 'giaddr' is 0) or on the address of
        the relay agent that forwarded the message ('giaddr' when not 0).

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

Test Module Name Synopsis
Verify DHCP server returns requested IP address when new client uses Requested IP Address option dhcp-s.tcl cdrouter_dhcp_server_10 Verify DHCP server returns requested IP address when new client uses Requested IP Address option


    step 1. Create a new host with a unique MAC address on the LAN
    step 2. Configure new host to use Requested IP Address option (DHCP option
            50) with a valid, unallocated address from within the configured LAN
            DHCP pool
    step 3. Start DHCP client on new host
    step 4. Verify DHCP client receives the address included in the Requested
            IP Address option


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4.3.1: DHCPDISCOVER message

    When a server receives a DHCPDISCOVER message from a client, the
    server chooses a network address for the requesting client.  If no
    address is available, the server may choose to report the problem to
    the system administrator. If an address is available, the new address
    SHOULD be chosen as follows:

      * The client's current address as recorded in the client's current
        binding, ELSE

      * The client's previous address as recorded in the client's (now
        expired or released) binding, if that address is in the server's
        pool of available addresses and not already allocated, ELSE

      * The address requested in the 'Requested IP Address' option, if that
        address is valid and not already allocated, ELSE

      * A new address allocated from the server's pool of available
        addresses; the address is selected based on the subnet from which
        the message was received (if 'giaddr' is 0) or on the address of
        the relay agent that forwarded the message ('giaddr' when not 0).

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

Test Module Name Synopsis
Verify DHCP server does not return an address when invalid Requested IP Address option is used dhcp-s.tcl cdrouter_dhcp_server_11 Verify DHCP server does not return an address when invalid Requested IP Address option is used


    step 1. Create a new host with a unique MAC address on the LAN
    step 2. Configure new host to use Requested IP Address option (DHCP option
            50) with the IP address of the existing LAN interface
    step 3. Start DHCP client on new host
    step 4. Verify DHCP client does not receive the address included in the
            Requested IP Address option since it has already been allocated


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4.3.1: DHCPDISCOVER message

    When a server receives a DHCPDISCOVER message from a client, the
    server chooses a network address for the requesting client.  If no
    address is available, the server may choose to report the problem to
    the system administrator. If an address is available, the new address
    SHOULD be chosen as follows:

      * The client's current address as recorded in the client's current
        binding, ELSE

      * The client's previous address as recorded in the client's (now
        expired or released) binding, if that address is in the server's
        pool of available addresses and not already allocated, ELSE

      * The address requested in the 'Requested IP Address' option, if that
        address is valid and not already allocated, ELSE

      * A new address allocated from the server's pool of available
        addresses; the address is selected based on the subnet from which
        the message was received (if 'giaddr' is 0) or on the address of
        the relay agent that forwarded the message ('giaddr' when not 0).

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

Test Module Name Synopsis
DHCP server includes vendor defined options dhcp-s.tcl cdrouter_dhcp_server_30 DHCP server includes vendor defined options


    step 1. Send DHCPRELEASE to release DHCP client address on LAN
    step 2. Send DHCPDISCOVER to restart DHCP client on LAN
    step 3. Verify DHCP client receives the expected options

    The testvars lanDhcpClientOptionCode and lanDhcpClientOptionData can
    be used to configure a list of DHCP options that the client should
    receive from the DHCP server.


Test Module Name Synopsis
Verify server supports DHCP Rapid Commit option dhcp-s.tcl cdrouter_dhcp_server_31 Verify server supports DHCP Rapid Commit option


    step 1. Send DHCPRELEASE to release DHCP client address on LAN
    step 2. Configure DHCP client on LAN to use the Rapid Commit option
    step 3. Restart DHCP client on LAN
    step 4. Wait for DHCPACK from DHCP server
    step 5. Verify DHCP server sends DHCPACK including Rapid Commit option
    step 6. Verify DHCP client receives a valid address
    step 7. Restore original behavior
    step 8. Restart DHCP client on LAN and verify that client receives a
            valid address


    References:

    IETF RFC 4039 "Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4)" Section 3.1: Client/Server Operation

    https://tools.ietf.org/html/rfc4039#section-3.1

Test Module Name Synopsis
Verify DHCP server ignores DHCPDISCOVER messages on port 68 dhcp-s.tcl cdrouter_dhcp_server_35 Verify DHCP server ignores DHCPDISCOVER messages on port 68


    step 1. Send DHCPRELEASE to release DHCP client address on LAN
    step 2. Send DHCPDISCOVER to LAN DHCP server using port 68
    step 3. Verify DHCP server ignores the DHCPDISCOVER.
    step 4. Restart DHCP client on LAN allowing the client to obtain an address


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4.1: Constructing and sending DHCP messages

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

Test Module Name Synopsis
Verify DHCP server accepts DHCP client packets with IPv4 length less than 576 dhcp-s.tcl cdrouter_dhcp_server_100 Verify DHCP server accepts DHCP client packets with IPv4 length less than 576


    step 1. Send DHCPRELEASE to release DHCP client address on LAN
    step 2. Configure DHCP client on LAN to not use minimum size DHCP packets
    step 3. Restart DHCP client on LAN
    step 4. Verify DHCP client receives a valid address
    step 5. Restore original behavior
    step 6. Restart DHCP client on LAN and verify that client receives a
            valid address

    NOTE: RFC 2131 allows clients to send DHCP packets that are not padded
    out to a minimum length. Older servers based on RFC 1541 may require
    a minimum IP length of 576 for DHCP packets. This test verifies that the
    DHCP server will interoperate with newer clients based on RFC 2131.


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 2: Protocol Summary

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

Test Module Name Synopsis
Verify DHCP server rejects DHCPREQUESTS with IP address of other clients dhcp-s.tcl cdrouter_dhcp_server_200 Verify DHCP server rejects DHCPREQUESTS with IP address of other clients


    step 1. Create a new DHCP client on LAN
    step 2. Verify new client obtains a valid IP address
    step 3. Attempt to renew the new client's lease using the IP address of
            another client in 'Client IP Address' option
    step 4. Verify DHCP server sends DHCPNAK
    step 5. Remove DHCP client created in step 1 from LAN


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 3.5: Client parameters in DHCP

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

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

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

Test Module Name Synopsis
Verify DHCP server ignores site-specific DHCP options dhcp-s.tcl cdrouter_dhcp_server_300 Verify DHCP server ignores site-specific DHCP options


    step 1. Send DHCPRELEASE to release DHCP client address on LAN
    step 2. Configure DHCP client on LAN to include site specific options
    step 3. Restart DHCP client on LAN
    step 4. Verify DHCP client receives a valid address
    step 5. Restore original behavior
    step 6. Restart DHCP client on LAN and verify that client receives a
            valid address


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 3.5: Client parameters in DHCP

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

Test Module Name Synopsis
Verify DHCP server handles client option with length 0 dhcp-s.tcl cdrouter_dhcp_server_301 Verify DHCP server handles client option with length 0


    step 1. Send DHCPRELEASE to release DHCP client address on LAN
    step 2. Configure DHCP client on LAN to include a 0 length option
    step 3. Restart DHCP client on LAN
    step 4. Verify DHCP client receives a valid address
    step 5. Restore original behavior
    step 6. Restart DHCP client on LAN and verify that client receives a
            valid address


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 3.5: Client parameters in DHCP

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

Test Module Name Synopsis
Verify DHCP server ignores DHCP packets with an invalid UDP checksum dhcp-s.tcl cdrouter_dhcp_server_401 Verify DHCP server ignores DHCP packets with an invalid UDP checksum


    step 1. Send DHCPRELEASE to release DHCP client address on LAN
    step 2. Configure DHCP client on LAN to send corrupted UDP checksums
    step 3. Restart DHCP client on LAN
    step 4. Verify DHCP client does not receive a valid address
    step 5. Restore original behavior
    step 6. Restart DHCP client on LAN and verify that client receives a
            valid address


Test Module Name Synopsis
Verify DHCP server allows multiple DHCP clients with same name (DHCP option 12) dhcp-s.tcl cdrouter_dhcp_server_501 Verify DHCP server allows multiple DHCP clients with same name (DHCP option 12)


    step 1. Create a new DHCP client on LAN
    step 2. Configure new client with the same hostname as the primary LAN client
    step 3. Verify new client obtains a valid IP address
    step 4. Remove DHCP client created in step 1 from LAN

    Note: This test checks that two DHCP clients configured with the same
    hostname can still receive a DHCP address. The hostname is set using
    DHCP Option 12.


Test Module Name Synopsis
Verify DHCP server uses IPv4 broadcast when DHCP client sets broadcast flag dhcp-s.tcl cdrouter_dhcp_server_520 Verify DHCP server uses IPv4 broadcast when DHCP client sets broadcast flag


    step 1. Send DHCPRELEASE to release DHCP client address on LAN
    step 2. Configure DHCP client on LAN to set the broadcast bit in
            its DHCPDISCOVER message
    step 3. Restart DHCP client on LAN
    step 4. Verify DHCP client receives a valid address
    step 5. Restore original behavior
    step 6. Restart DHCP client on LAN and verify that client receives a
            valid address


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 2: Protocol Summary

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

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 4.1: Constructing and sending DHCP messages

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

Test Module Name Synopsis
Verify DHCP server probes IPv4 client address before assigning dhcp-s.tcl cdrouter_dhcp_server_540 Verify DHCP server probes IPv4 client address before assigning


    step 1. Create a new DHCP client on LAN
    step 2. Watch all ARP and ICMP Echo requests from the router's LAN interface
    step 3. Verify DHCP client receives a valid address
    step 4. Verify router and/or DHCP server sends ARP or ICMP Echo request
            for DHCP client's address before assigning it
    step 5. Remove DHCP client created in step 1 from LAN

    NOTE: Each DHCP server may use a different technique to probe
    an IPv4 address before assigning it to a client. For example,
    send an ARP Request, ICMP ping, etc. This test verifies that
    the router attempts to resolve an ARP Request for the IPv4
    address or send an ICMP Echo Request before the address is
    assigned to a DHCP client.

    NOTE: In most cases the default router and DHCP server will be the same
    IPv4 address. However, this test allows them to be different.


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 3.1: Client-Server Interaction

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

Test Module Name Synopsis
Verify DHCP server returns correct WINS server(s) dhcp-s.tcl cdrouter_dhcp_server_600 Verify DHCP server returns correct WINS server(s)


    step 1. Send DHCPRELEASE to release DHCP client address on LAN
    step 2. Configure DHCP client on LAN to request WINS server option
    step 3. Restart DHCP client on LAN
    step 4. Verify DHCP client receives a valid address that includes the WINS
            server option
    step 5. Verify WINS server address(es) provided by the DHCP server match
            the expected value(s)
    step 6. Restore original behavior
    step 7. Restart DHCP client on LAN and verify that client receives a
            valid address


Test Module Name Synopsis
Verify DHCP server returns correct NTP server(s) dhcp-s.tcl cdrouter_dhcp_server_610 Verify DHCP server returns correct NTP server(s)


    step 1. Send DHCPRELEASE to release DHCP client address on LAN
    step 2. Configure DHCP client on LAN to request NTP server option
    step 3. Restart DHCP client on LAN
    step 4. Verify DHCP client receives a valid address that includes the NTP
            server option
    step 5. Verify NTP server address(es) provided by the DHCP server match
            the expected value(s)
    step 6. Restore original behavior
    step 7. Restart DHCP client on LAN and verify that client receives a
            valid address

    NOTE: CDRouter automatically announces ntpServer1 and ntpServer2
    via DHCP on the WAN. This test verifies that the NTP server(s)
    received via DHCP on the LAN match the ntpServer1 and ntpServer2
    addresses. If both ntpServer1 and ntpServer2 are configured, this
    test will verify that the LAN client received both addresses. If
    only one NTP server is configured, this test will verify that the
    LAN client received only the expected address. This test is only
    run if the testvar 'dhcpClientRequestNtp' is set to 'yes'.

Test Module Name Synopsis
Verify DHCP server returns correct client identifier option dhcp-s.tcl cdrouter_dhcp_server_620 Verify DHCP server returns correct client identifier option


    step 1. Send DHCPRELEASE to release DHCP client address on LAN
    step 2. Configure DHCP client on LAN to request the 'client identifier'
            option
    step 3. Restart DHCP client on LAN
    step 4. Verify DHCP client receives client identifier option in all
            DHCP response packets from the server
    step 5. Verify client identifier option contains client's MAC address
    step 6. Verify DHCP client receives IP address

    If the 'client identifier' option is present in a message received
    from a client, the server MUST return the 'client identifier' option,
    unaltered, in its response message.


    References:

    IETF RFC 6842 "Client Identifier Option in DHCP Server Replies" Section 3: Modification to RFC 2131

    https://tools.ietf.org/html/rfc6842#section-3

Test Module Name Synopsis
Verify DHCP server returns correct DNS server(s) dhcp-s.tcl cdrouter_dhcp_server_630 Verify DHCP server returns correct DNS server(s)


    step 1. Send DHCPRELEASE to release DHCP client address on LAN
    step 2. Configure DHCP client on LAN to request DNS server option
    step 3. Restart DHCP client on LAN
    step 4. Verify DHCP client receives a valid address that includes the DNS
            server option
    step 5. Verify DNS server address(es) provided by the DHCP server match
            the expected value(s)

    NOTE: CDRouter automatically announces wanDnsServer, wanBackupDnsServer, and
    optionally wanBackupDnsServer2 and wanBackupDnsServer3 via DHCP on the WAN.
    If the testvar “DNStoDHCP“ is set to “yes”, CDRouter will verify that its
    LAN DHCP client receives the same DNS servers that have either been learned
    dynamically by the DUT on the WAN or configured manually on the DUT. If the
    testvar “DNStoDHCP” is set to “no”, CDRouter will verify that its LAN DHCP
    client receives the DNS server specified by the testvar “lanDnsServer”
    instead.


Test Module Name Synopsis
Verify DHCP server responds to unicast and broadcast DHCPINFORM messages dhcp-s.tcl cdrouter_dhcp_server_700 Verify DHCP server responds to unicast and broadcast DHCPINFORM messages


    step 1. Send a unicast DHCPINFORM message to the DHCP server
            including DNS Servers (Option 6) and Domain Name (Option 15)
            in the parameter request list
    step 2. Verify DHCP server sends DHCPACK
    step 3. Verify the DHCPACK does not contain a lease time
    step 4. Verify the DHCPACK contains the correct DNS servers (Option 6)
    step 5. Verify the DHCPACK contains the correct domain name (Option 15)
            NOTE: Domain Name is only checked when the wanMode is DHCP
                  and if the testvar lanDomainName is not set to 'none'.
    step 6. Repeat test by sending broadcast DHCPINFOM message

    NOTE: If your DUT does not respond with the Domain Name DHCP option (15),
    then ensure that the testvar lanDomainName is set to the keyword 'none'.


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol" Section 3.4: Obtaining parameters with externally configured network address

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

Test Module Name Synopsis
Verify DHCP server handles clients using V-I Vendor-Specific Information option dhcp-s.tcl cdrouter_dhcp_server_710 Verify DHCP server handles clients using V-I Vendor-Specific Information option


    step 1. Send DHCPRELEASE to release DHCP client address on LAN
    step 2. Configure DHCP client on LAN to request V-I Vendor-Specific
            Information option
    step 3. Restart DHCP client on LAN
    step 4. Verify DHCP client receives a valid address
    step 5. Restore original behavior
    step 6. Restart DHCP client on LAN and verify that client receives a
            valid address

    NOTE: This test verifies that new LAN side CPE devices with TR-111 support
    can still operate behind an IGD device that may not support TR-069. The IGD
    device should ignore the unknown DHCP options if they are not supported.


    References:

    IETF RFC 3925 "Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)"

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

Test Module Name Synopsis
Verify DHCP server handles clients using V-I Vendor Class option dhcp-s.tcl cdrouter_dhcp_server_720 Verify DHCP server handles clients using V-I Vendor Class option


    step 1. Send DHCPRELEASE to release DHCP client address on LAN
    step 2. Configure DHCP client on LAN to request V-I Vendor Class option
    step 3. Restart DHCP client on LAN
    step 4. Verify DHCP client receives a valid address
    step 5. Restore original behavior
    step 6. Restart DHCP client on LAN and verify that client receives a
            valid address

    NOTE: This test verifies that new LAN side CPE devices using Vendor Class
    options to identify themselves can still operate behind an IGD device
    that may not recognize Vendor Class options.


    References:

    IETF RFC 3925 "Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)"

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

Test Module Name Synopsis
Verify DHCP server does not become exhausted after a large number of DHCP restarts dhcp-s.tcl cdrouter_dhcp_server_800 Verify DHCP server does not become exhausted after a large number of DHCP restarts


    step 1. Send DHCPDISCOVER to restart DHCP client on LAN
    step 2. Verify DHCP client receives an address from within the configured
            DHCP pool
    step 3. Repeat steps 1 and 2 N times, where N is equal to 2 times the DHCP
            pool size

    Note: The DHCP pool is configured using the testvars dhcpClientStart and
    dhcpClientEnd. These testvars must match the DHCP pool settings on the
    DUT.


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol"

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

Test Module Name Synopsis
Verify DHCP server does not become exhausted after a large number of DHCP release then restarts dhcp-s.tcl cdrouter_dhcp_server_801 Verify DHCP server does not become exhausted after a large number of DHCP release then restarts


    step 1. Send DHCPRELEASE to release DHCP client address on LAN
    step 2. Send DHCPDISCOVER to restart DHCP client on LAN
    step 3. Verify DHCP client receives an address from within the configured
            DHCP pool
    step 4. Repeat steps 1 through 3 N times, where N is equal to 2 times the
            DHCP pool size

    Note: The DHCP pool is configured using the testvars dhcpClientStart and
    dhcpClientEnd. These testvars must match the DHCP pool settings on the
    DUT.


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol"

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


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

Test Module Name Synopsis
Outbound UDP connections use NAPT nat.tcl cdrouter_nat_2 Outbound UDP connections use NAPT


    step 1. Initiate an outbound UDP connection (UDP Echo)
    step 2. Verify the udp is received on WAN side
    step 3. Verify the IPv4 source address on the WAN side is the router's address
    step 4. Send a return response back to LAN
    step 5. Verify return packet is received on the LAN


    References:

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

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

Test Module Name Synopsis
Maximum number of TCP connections with single LAN host nat.tcl cdrouter_nat_100 Maximum number of TCP connections with single LAN host


    step 1. Initiate an outbound TCP connection
    step 2. Verify the connection is established
    step 3. Send HTTP GET on TCP connection
    step 4. Verify the source address on the WAN side is the router's address
    step 5. Continue creating sessions up to the maximum number supported


    References:

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

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

Test Module Name Synopsis
NAPT with multiple LAN hosts using the same TCP source port nat.tcl cdrouter_nat_101 NAPT with multiple LAN hosts using the same TCP source port


    step 1. Configure additional LAN host
    step 2. Configure the new LAN host so that its TCP source ports will be the
            same as the original LAN host
    step 3. Initiate outbound TCP connections for both LAN hosts
    step 4. Verify the connections are established
    step 5. Continue to create up to 10 connections per host


    References:

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

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

Test Module Name Synopsis
NAPT with a TCP and UDP connection using the same source port nat.tcl cdrouter_nat_120 NAPT with a TCP and UDP connection using the same source port


    step 1. Initiate an outbound TCP connection to HTTP server
    step 2. Verify the connection is established
    step 3. Verify the IPv4 source address on the WAN side is the router's address
    step 4. Initiate an outbound UDP connection using same source port (UDP Echo)
    step 5. Verify the UDP packet is received on the WAN
    step 6. Send a return UDP packet back to the LAN host
    step 7. Verify return UDP packet is received on the LAN
    step 8. Close TCP connection from LAN side


    References:

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

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

Test Module Name Synopsis
Verify NAPT with outbound TCP connections using high and low source ports nat.tcl cdrouter_nat_130 Verify NAPT with outbound TCP connections using high and low source ports


    step 1. Set the next TCP source port to 65535
    step 2. Initiate an outbound TCP connection to HTTP server
    step 3. Verify the connection is established
    step 4. Verify the IPv4 source address on the WAN side is the router's address
    step 5. Send HTTP GET request to server
    step 6. Verify HTTP response is received
    step 7. Close TCP connection from LAN side
    step 8. Repeat using TCP source ports 65534, 0, 1, and 2


    References:

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

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

Test Module Name Synopsis
Verify TCP source port can be reused after a passive close behind NAPT nat.tcl cdrouter_nat_150 Verify TCP source port can be reused after a passive close behind NAPT


    step 1. Initiate an outbound TCP connection to TCP server
    step 2. Verify the connection is established and operational
    step 3. Initiate a TCP active close from the WAN side
    step 4. Initiate a TCP passive close from the LAN side
    step 5. Initiate a new outbound TCP connection using the same TCP source port
    step 6. Verify the connection is established and operational

    NOTES: The NAPT implementation should allow new TCP connections to reuse the
    same source port if the TCP connection on the LAN side is closed through
    a passive TCP close operation.

    The amount of time to wait before attempting to resue the Tcp port can
    be configured using testvar 'natTcpPortDelay'. It defaults to 1 second. Setting
    this value too high may defeat the test since the port mapping may be
    deleted before the port is reused.


    References:

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

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

Test Module Name Synopsis
Maximum number of UDP connections with single LAN host nat.tcl cdrouter_nat_200 Maximum number of UDP connections with single LAN host


    step 1. Initiate an outbound UDP connection
    step 2. Verify the the UDP packet is received on the WAN
    step 3. Verify the source address on the WAN side is the router's address
    step 4. Send return UDP packet back to the LAN
    step 5. Verify the return UDP packet is received on the LAN
    step 6. Continue creating sessions up to the maximum number supported
    step 7. Once all sessions are established, loop through each session
            again and forward a UDP packet from the WAN to the LAN using
            the port mappings that were established for each connection
    step 8. Verify that each UDP connection is still forwarding traffic
            from WAN to LAN.


    References:

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

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

Test Module Name Synopsis
NAPT with multiple LAN hosts using the same UDP source port nat.tcl cdrouter_nat_201 NAPT with multiple LAN hosts using the same UDP source port


    step 1. Configure additional LAN host
    step 2. Configure the new LAN host so that its UDP source ports will be the
            same as the original LAN host
    step 3. Initiate outbound UDP connections for both LAN hosts (UDP Echo)
    step 4. Verify the UDP Echo requests are answered
    step 5. Continue to create up to 10 UDP connections per host


    References:

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

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

Test Module Name Synopsis
Verify NAPT checks source IP address of inbound UDP packets nat.tcl cdrouter_nat_300 Verify NAPT checks source IP address of inbound UDP packets


    step 1. Forward a UDP packet from a LAN client to the WAN
    step 2. Forward a packet back from the WAN to the same LAN client
    step 3. Verify packet is received
    step 4. Forward a packet using a different source IP address to LAN
    step 5. Verify the packet is not forwarded onto the LAN or if
            the natType or dsliteFirewallMode is full-cone, verify
            the packet is forwarded to the LAN.

    NOTE: The exact behavior of this test depends on the type of NAT that
    is implemented by the device. The testvar natMode can be used to
    configure either full-cone, address-restricted, or port-restricted NAT.

    NOTE: When DS-Lite is enabled, NAT is not normally applied on the CPE.
    The CPE may still apply a firewall. The mode of the firewall can be
    configured using the dsliteFirewallMode testvar.


    References:

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

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

Test Module Name Synopsis
UDP headers with a checksum equal to 0 should not be modified nat.tcl cdrouter_nat_320 UDP headers with a checksum equal to 0 should not be modified


    step 1. Forward a UDP packet from a LAN client to the WAN with
            UDP checksum equal to 0
    step 2. Verify packet is received
    step 3. Verify received UDP checksum on WAN side is 0


    References:

    IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)" Section 4.1: IP, TCP, UDP and ICMP Header Manipulations

    https://tools.ietf.org/html/rfc3022#section-4.1

Test Module Name Synopsis
Outbound TCP connection using IPv4 options nat.tcl cdrouter_nat_330 Outbound TCP connection using IPv4 options


    step 1. Enable LAN client and remote host to include the router alert
            IP option in every IPv4 packet
    step 2. Initiate an outbound TCP connection to HTTP server
    step 3. Verify the connection is established
    step 4. Verify the IPv4 source address on the WAN side is the router's address
    step 5. Send HTTP GET request to server
    step 6. Verify HTTP response is received
    step 7. Close TCP connection from LAN side


    References:

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

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

Test Module Name Synopsis
Outbound UDP connection using IPv4 options nat.tcl cdrouter_nat_340 Outbound UDP connection using IPv4 options


    step 1. Enable LAN client and remote host to include the router alert
            IP option every IPv4 packet
    step 2. Initiate an outbound UDP connection (UDP Echo)
    step 3. Verify the UDP is received on WAN side
    step 4. Verify the IPv4 source address on the WAN side is the router's address
    step 5. Send a return response back to LAN
    step 6. Verify return packet is received on the LAN


    References:

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

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

Test Module Name Synopsis
Verify NAPT uses port parity preservation nat.tcl cdrouter_nat_350 Verify NAPT uses port parity preservation


    step 1. Send UDP packet from LAN to WAN
    step 2. Verify UDP packet is received on the WAN
    step 3. Verify source port on WAN matches the parity of original LAN port
    step 4. Repeat for incremental ports

    If port parity is not supported, this test can be skipped by configuring
    the testvar 'natPortParity' to 'no'. The default is yes.


    References:

    IETF RFC 4787 "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" Section 4.2.2: Port Parity

    https://tools.ietf.org/html/rfc4787#section-4.2.2

Test Module Name Synopsis
Verify ICMP Destination Unreachable message from WAN does not destroy NAT UDP mapping nat.tcl cdrouter_nat_360 Verify ICMP Destination Unreachable message from WAN does not destroy NAT UDP mapping


    step 1. Send UDP packet from LAN to WAN
    step 2. Verify UDP packet is received on the WAN and return an ICMP Destination Unreachable message
    step 3. Verify ICMP Destination Unreachable message is received on the LAN
    step 4. Send UDP response from WAN to LAN
    step 5. Verify UDP response is received on LAN since NAPT mapping is still working

    NOTE: Receipt of any sort of ICMP message must not destroy the NAT mapping.
    This is REQ-12 from RFC 4787.


    References:

    IETF RFC 4787 "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" Section 9: ICMP Destination Unreachable Behavior

    https://tools.ietf.org/html/rfc4787#section-9

Test Module Name Synopsis
Verify ICMP Destination Unreachable message from WAN does not destroy NAT TCP mapping nat.tcl cdrouter_nat_361 Verify ICMP Destination Unreachable message from WAN does not destroy NAT TCP mapping


    step 1. Establish TCP connection from LAN to WAN
    step 2. Send an ICMP Destination Unreachable message from the WAN for the connection
    step 3. Verify ICMP Destination Unreachable message is received on the LAN
    step 4. Send TCP data segment from WAN to LAN for the session
    step 5. Verify TCP data segment is received on LAN since NAPT mapping is still working


    References:

    IETF RFC 5382 "NAT Behavioral Requirements for TCP" Section 7.3: ICMP Responses to TCP Packets

    REQ-10:  Receipt of any sort of ICMP message MUST NOT terminate the
       NAT mapping or TCP connection for which the ICMP was generated.

    Justification:  This is necessary for reliably performing TCP
       simultaneous-open where a remote NAT may temporarily signal an
       ICMP error.

    https://tools.ietf.org/html/rfc5382#section-7.3

Test Module Name Synopsis
Verify basic MSS Clamping for TCP sessions nat.tcl cdrouter_nat_400 Verify basic MSS Clamping for TCP sessions


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

    NOTE: The expected MSS size for MSS clamping can be configured
    using the testvar 'mssClampingValue'. If the inbound direction is
    different than the outbound direction for MSS clamping, the inbound
    direction can be adjusted using the testvar mssClampingInValue.

    NOTE: The TCP port used for the MSS clamping test defaults to
    port 8096. This can be changed using the testvar mssClampingTestPort.


Test Module Name Synopsis
Verify MSS Clamping with TCP options from different clients nat.tcl cdrouter_nat_401 Verify MSS Clamping with TCP options from different clients


    step 1. Set the TCP options to resemble a Windows TCP client
    step 2. Initiate an outbound TCP connection to HTTP server
    step 3. Verify the received MSS on the LAN and WAN matches
            the expected MSS size
    step 4. Verify the IPv4 source address on the WAN side is the router's address
    step 5. Send HTTP GET request to server
    step 6. Verify HTTP response is received
    step 7. Close TCP connection from LAN side
    step 8. Repeat testing using TCP options for a Linux TCP client
    step 9. Repeat testing using TCP options for a Mac OS X TCP client

    NOTE: The expected MSS size for MSS clamping can be configured
    using the testvar 'mssClampingValue'. If the inbound direction is
    different than the outbound direction for MSS clamping, the inbound
    direction can be adjusted using the testvar mssClampingInValue.

    NOTE: The TCP port used for the MSS clamping test defaults to
    port 8096. This can be changed using the testvar mssClampingTestPort.


Test Module Name Synopsis
Verify MSS Clamping does not modify smaller MSS values nat.tcl cdrouter_nat_410 Verify MSS Clamping does not modify smaller MSS values


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

    NOTE: In order to pass this test, the router's expected MSS Clamping value
    must be greater than 512. When the router detects a MSS value smaller than its
    own MSS clamping value, it should leave the MSS unchanged. The expected MSS
    size for MSS clamping can be configured using the testvar 'mssClampingValue'.

    NOTE: The TCP port used for the MSS clamping test defaults to
    port 8096. This can be changed using the testvar mssClampingTestPort.


Test Module Name Synopsis
NAT uses single binding for TCP session with same source IP and source port nat.tcl cdrouter_nat_500 NAT uses single binding for TCP session with same source IP and source port


    step 1. Initiate an outbound TCP connection to server 1 on the WAN
    step 2. Initiate a second outbound TCP connection to server 2 on the WAN
    step 3. Verify outgoing source port on the WAN side is the same for both connections
    step 4. Close both connections

    RFC 3022 Section 3.1 states that NAT implementations may use the same
    binding for TCP or UDP sessions when the source IP and port are the same.
    This technique is used by peer-to-peer applications to establish a
    connection through NAT. This is also known as Cone NAT.

    NOTE: IETF draft-ford-midcom-p2p-03.txt
    Section 5.1. Deprecate the use of symmetric NATs

    This test is only run when the testvar 'natSupportsP2P' is set to yes.


    References:

    IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)" Section 3.1: Address binding

    https://tools.ietf.org/html/rfc3022#section-3.1

    IETF Internet-Draft draft-ford-midcom-p2p-03 "Peer-to-Peer(P2P) communication across Network Address Translators(NATs)" Section 5.1: Deprecate the use of symmetric NATs

    https://tools.ietf.org/html/draft-ford-midcom-p2p-03#section-5.1

Test Module Name Synopsis
NAT uses single binding for UDP session with same source IP and source port nat.tcl cdrouter_nat_501 NAT uses single binding for UDP session with same source IP and source port


    step 1. Initiate an outbound UDP connection to server 1 on the WAN
    step 2. Initiate a second outbound UDP connection to server 2 on the WAN
    step 3. Verify outgoing source port on the WAN side is the same for both connections

    RFC 3022 Section 3.1 states that NAT implementations may use the same
    binding for TCP or UDP sessions when the source IP and port are the same.
    This technique is used by peer-to-peer applications to establish a
    connection through NAT. This is also known as Cone NAT.

    NOTE: IETF draft-ford-midcom-p2p-03.txt
    Section 5.1. Deprecate the use of symmetric NATs

    This test is only run when the testvar 'natSupportsP2P' is set to yes.


    References:

    IETF RFC 3022 "Traditional IP Network Address Translator (Traditional NAT)" Section 3.1: Address binding

    https://tools.ietf.org/html/rfc3022#section-3.1

    IETF Internet-Draft draft-ford-midcom-p2p-03 "Peer-to-Peer(P2P) communication across Network Address Translators(NATs)" Section 5.1: Deprecate the use of symmetric NATs

    https://tools.ietf.org/html/draft-ford-midcom-p2p-03#section-5.1

Test Module Name Synopsis
NAT performs hairpin translation for LAN side TCP connections nat.tcl cdrouter_nat_510 NAT performs hairpin translation for LAN side TCP connections


    step 1. Initiate an outbound TCP connection to server 1 from LAN source port A
    step 2. Initiate a second outbound TCP connection to server 1 from LAN source port B
    step 3. Detect public IP and source port for both TCP connections
    step 4. Send TCP SYN from LAN source port A to public IP and source port for connection 2
    step 5. Send TCP SYN from LAN source port B to public IP and source port for connection 1

    step 6. Send TCP SYN from LAN source port A to public IP and source port for connection 2
            ** NOTE: This step is required for Restricted and Port Restricted
            Cone NATs. These types of NATs require an existing outgoing session
            before allowing incoming packets. The test will pass packets in both
            directions before trying to verify the hairpin behavior.

    step 7. Verify packet is received at LAN source port B
    step 8. Verify source IPv4 address and TCP port are translated to public IPv4 and port
            ** NOTE: The test only issues a warning if the TCP source port is not preserved.

    step 9. Send TCP SYN-ACK from LAN source port B to public IP and source port for connection 1
            ** NOTE: The source port is taken from the TCP SYN packet to work with implementations
            that do not preserve the TCP source port.

    step 10. Verify packet is received at LAN source port A
    step 11. Verify source IPv4 address and TCP port are translated to public IPv4 and port

    NOTES: This test scenario should work for all Cone NAT implementations - Full
    Cone NAT, Restricted Cone NAT, and Port Restricted Cone NAT. For a discussion
    of each type of Cone NAT, please see RFC 3489.

    This test is only run when the testvar 'natSupportsP2P' is set to yes.


    References:

    IETF RFC 5382 "NAT Behavioral Requirements for TCP" Section 7.2: Hairpinning behavior

    https://tools.ietf.org/html/rfc5382#section-7.2

Test Module Name Synopsis
NAT performs hairpin translation for LAN side UDP connections nat.tcl cdrouter_nat_511 NAT performs hairpin translation for LAN side UDP connections


    step 1. Initiate an outbound UDP connection to server 1 from LAN source port A
    step 2. Initiate a second outbound UDP connection to server 1 from LAN source port B
    step 3. Detect public IP and source port for both UDP connections
    step 4. Send UDP from LAN source port A to public IP and source port for connection 2
    step 5. Send UDP from LAN source port B to public IP and source port for connection 1

    step 6. Send UDP from LAN source port A to public IP and source port for connection 2
            ** NOTE: This step is required for Restricted and Port Restricted
            Cone NATs. These types of NATs require an existing outgoing session
            before allowing incoming packets. The test will pass packets in both
            directions before trying to verify the hairpin behavior.

    step 7. Verify packet is received at LAN source port B
    step 8. Verify source IPv4 address and UDP port are translated to public IPv4 and port
            ** NOTE: The test only issues a warning if the UDP source port is not preserved.

    step 9. Send UDP from LAN source port B to public IP and source port for connection 1
            ** NOTE: The source port is taken from the incoming UDP packet to work with
            implementations that do not preserve the UDP source port.

    step 10. Verify packet is received at LAN source port A
    step 11. Verify source IPv4 address and UDP port are translated to public IPv4 and port

    NOTES: This test scenario should work for all Cone NAT implementations - Full
    Cone NAT, Restricted Cone NAT, and Port Restricted Cone NAT. For a discussion
    of each type of Cone NAT, please see RFC 3489.

    This test is only run when the testvar 'natSupportsP2P' is set to yes.


    References:

    IETF RFC 4787 "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" Section 6: Hairpinning Behavior

    https://tools.ietf.org/html/rfc4787#section-6

Test Module Name Synopsis
Verify Port-Restricted, Address-Restricted, or Full-Cone NAPT for UDP connections nat.tcl cdrouter_nat_520 Verify Port-Restricted, Address-Restricted, or Full-Cone NAPT for UDP connections


    step 1. Forward a UDP packet from a LAN client to the WAN
    step 2. Verify packet is received
    step 3. Follow the steps below based on the value of the natMode testvar:

    For Full-Cone NAT
    step 4. Forward a packet using a different source port but same IP address from the WAN
    step 5. Verify the packet is forwarded to the LAN
    step 6. Forward a packet using a different IPv4 address and same source port
    step 7. Verify the packet is forwarded to the LAN
    step 8. Forward a packet using the same IPv4 address and same source port
    step 9. Verify the packet is forwarded to the LAN

    For Address-Restricted NAT
    step 4. Forward a packet using a different source port but same IP address from the WAN
    step 5. Verify the packet is forwarded to the LAN
    step 6. Forward a packet using a different IPv4 address and same source port
    step 7. Verify the packet is not forwarded to the LAN
    step 8. Forward a packet using the same IPv4 address and same source port
    step 9. Verify the packet is forwarded to the LAN

    For Port-Restricted NAT
    step 4. Forward a packet using a different source port but same IP address from the WAN
    step 5. Verify the packet is not forwarded to the LAN
    step 6. Forward a packet using a different IPv4 address and same source port
    step 7. Verify the packet is not forwarded to the LAN
    step 8. Forward a packet using the same IPv4 address and same source port
    step 9. Verify the packet is forwarded to the LAN

    NOTE: Most NAPT routers use either Port-Restricted NAT, Address-Restricted NAT,
    or Full-Cone NAT. By default, CDRouter assumes Port-Restricted NAT, but the type
    of NAPT in use can be configured using the testvar 'natMode'.


    References:

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

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

Test Module Name Synopsis
Verify TCP connections using TCP window scale option through NAT nat.tcl cdrouter_nat_530 Verify TCP connections using TCP window scale option through NAT


    step 1. Configure a LAN client to set the TCP window scale option using value '4'
            and a TCP window size of 65535
    step 2. Configure a WAN server to set the TCP window scale option using value '4'
            and a TCP window size of 65535
    step 3. Initiate a outbound TCP connection from the LAN client to the WAN client
    step 4. Verify both TCP connections received the same TCP window scale option
            with the same scaling factor '4'. The TCP window scale option should
            not be modified. Stop the test here if the window scale option is modified.
    step 5. Send a data block from the LAN to the WAN at the start of the data sequence
    step 6. Move the sequence ahead (65535 * 3) so that it would be outside of the
            current window if TCP window scaling is not being applied
    step 7. Send a new data block from the LAN to the WAN and verify the WAN server
            can echo back the data block.
    step 8. Repeat the Steps 5 and 6 until 5 data blocks have been sent
    step 9. Send a data block from the WAN to the LAN using current data sequence
    step 10. Move the sequence ahead (65535 * 3) so that it would be outside of the
             current window if TCP window scaling is not being applied
    step 11. Send a new data block from the WAN to the LAN and verify the LAN client
             can echo back the data block.
    step 12. Repeat the Steps 9 and 10 until 5 data blocks have been sent
    step 13. Close the TCP connection

    NOTE: If a firewall/NAT device is tracking the sequence number of TCP data, it
    needs to understand the TCP window scale option. This test is designed to find
    issues with devices that are not applying the TCP window scale factor to the
    the TCP window. If a device is not maintaining any TCP sequence number state,
    the TCP connection should not experience any problems.


    References:

    IETF RFC 1323 "TCP Extensions for High Performance"

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

Test Module Name Synopsis
Verify TCP Fast Open cookie request through NAT nat.tcl cdrouter_nat_600 Verify TCP Fast Open cookie request through NAT


    step 1. Configure a LAN client to enable TCP Fast Open support
    step 2. Configure WAN server to enable TCP Fast Open support
    step 3. Initiate an outbound TCP connection from the LAN client to
            the WAN server.  Client includes a TCP Fast Open cookie
            request option in its initial SYN packet.
    step 4. Verify LAN client received a TCP Fast Open cookie option
            in the SYN+ACK from the WAN server during the normal TCP
            three-way handshake.
    step 5. Verify TCP connection was established successfully.
    step 6. Close the TCP connection

    NOTE: TCP Fast Open does not currently have an officially assigned
    IANA TCP option value.  Therefore, this test uses the experimental
    TCP option value 0xfe and prepends the magic value 0xf989 to each
    cookie in order to distinguish TFO cookie request/TFO cookie
    options from other experimental TCP options.  The fact that these
    are not official IANA values should not be a factor in this
    NAT-style test since CDRouter is acting as both the client and
    server.


    References:

    IETF Internet-Draft draft-ietf-tcpm-fastopen "TCP Fast Open"

    https://tools.ietf.org/html/draft-ietf-tcpm-fastopen

Test Module Name Synopsis
Verify TCP connections using TCP Fast Open option through NAT nat.tcl cdrouter_nat_610 Verify TCP connections using TCP Fast Open option through NAT


    step 1. Configure a LAN client to enable TCP Fast Open support
    step 2. Configure WAN server to enable TCP Fast Open support
    step 3. Initiate an outbound TCP connection from the LAN client to
            the WAN server.  Client includes a TCP Fast Open cookie
            request option in its initial SYN packet.
    step 4. Verify LAN client received a TCP Fast Open cookie option
            in the SYN+ACK from the WAN server during the normal TCP
            three-way handshake.
    step 5. Verify TCP connection was established successfully.
    step 6. Close the TCP connection
    step 7. Initiate an outbound TCP connection from the LAN client to
            the WAN server, client includes data along with the TCP
            Fast Open cookie from step 4 in its SYN packet.
    step 8. WAN server sends its response data in an extra ACK between
            the server's SYN+ACK and the client's ACK during the
            normal TCP three-way handshake.
    step 9. Verify TCP connection was established successfully
    step 10. Verify LAN client received expected server data
    step 11. Verify WAN server received expected client data
    step 12. Close the TCP connection

    NOTE: TCP Fast Open does not currently have an officially assigned
    IANA TCP option value.  Therefore, this test uses the experimental
    TCP option value 0xfe and prepends the magic value 0xf989 to each
    cookie in order to distinguish TFO cookie request/TFO cookie
    options from other experimental TCP options.  The fact that these
    are not official IANA values should not be a factor in this
    NAT-style test since CDRouter is acting as both the client and
    server.


    References:

    IETF Internet-Draft draft-ietf-tcpm-fastopen "TCP Fast Open"

    https://tools.ietf.org/html/draft-ietf-tcpm-fastopen


nat-timeout.tcl

NAPT tests for session timers

Test Module Name Synopsis
Verify NAT TCP session timeout after FIN close nat-timeout.tcl cdrouter_nat_timeout_1 Verify NAT TCP session timeout after FIN close


    step 1. Initiate an outbound TCP connection to next TCP port
    step 2. Verify the connection is established
    step 3. Close the TCP connection using FIN from WAN
    step 4. Wait for natFinTimeout to expire
    step 5. Retransmit the last TCP segment from the WAN to LAN
    step 6. Verify TCP packet from the WAN is not forwarded to LAN
    step 7. Initiate a second outbound TCP connection to same TCP port
    step 8. Verify the connection is established
    step 9. Close the TCP connection using FIN from WAN
    step 10. Wait for natFinTimeout - 5 seconds
    step 11. Retransmit the last TCP segment from the WAN to LAN
    step 12. Verify TCP packet from the WAN is forwarded to LAN

    NOTE: This test verifies that the router maintains a NAT entry for a
    TCP connection that has been closed for 'natFinTimeout' seconds. The
    natFinTimeout setting is configured in the configuration file
    using the testvar natFinTimeout.

    NOTE: There are two mains types of implementations of the natFinTimeout
    timer. Some implementations delete the NAT entry after a FIN event
    occurs and the natFinTimeout occurs. Other implementations reset the
    timeout each time a packet is seen. This test case uses 2 TCP sessions
    to verify the behavior since sending TCP data to verify the timeout can
    cause some implementations to reset the timeout.

    NOTE: If the CPE is not designed to immediately delete expired NAT 
    mappings, the 'natLagTime' testvar should be set to force CDRouter to 
    wait a fixed number of seconds before verifying that the mapping has 
    been deleted.


    References:

    IETF RFC 2663 "NAT Terminology and Considerations" Section 2.6: End of session for TCP, UDP and others

    https://tools.ietf.org/html/rfc2663#section-2.6

Test Module Name Synopsis
Verify NAT TCP session timeout after RST close nat-timeout.tcl cdrouter_nat_timeout_2 Verify NAT TCP session timeout after RST close


    step 1. Initiate an outbound TCP connection to next TCP port
    step 2. Verify the connection is established
    step 3. Close the TCP connection using RST from LAN
    step 4. Wait for natRstTimeout to expire
    step 5. Retransmit the last TCP segment from the WAN to LAN
    step 6. Verify TCP packet from the WAN is not forwarded to LAN
    step 7. Initiate a second outbound TCP connection to same TCP port
    step 8. Verify the connection is established
    step 9. Close the TCP connection using RST from LAN
    step 10. Wait for natRstTimeout - 5 seconds
    step 11. Retransmit the last TCP segment from the WAN to LAN
    step 12. Verify TCP packet from the WAN is forwarded to LAN

    NOTE: This test verifies that the router maintains a NAT entry for a
    TCP connection that has been closed for 'natRstTimeout' seconds. The
    natRstTimeout setting is configured in the configuration file
    using the testvar natRstTimeout.

    NOTE: There are two mains types of implementations of the natRstTimeout
    timer. Some implementations delete the NAT entry after an RST event
    occurs and the natRstTimeout occurs. Other implementations reset the
    timeout each time a packet is seen. This test case uses 2 TCP sessions
    to verify the behavior since sending TCP data to verify the timeout can
    cause some implementations to reset the timeout.

    NOTE: If the CPE is not designed to immediately delete expired NAT 
    mappings, the 'natLagTime' testvar should be set to force CDRouter to 
    wait a fixed number of seconds before verifying that the mapping has 
    been deleted.


    References:

    IETF RFC 2663 "NAT Terminology and Considerations" Section 2.6: End of session for TCP, UDP and others

    https://tools.ietf.org/html/rfc2663#section-2.6

Test Module Name Synopsis
Verify NAT TCP session timeout for established session nat-timeout.tcl cdrouter_nat_timeout_10 Verify NAT TCP session timeout for established session


    step 1. Initiate an outbound TCP connection to next TCP port
    step 2. Verify the connection is established
    step 3. Wait for natTcpTimeout to expire
    step 4. Retransmit the last TCP segment from the WAN to LAN
    step 5. Verify TCP packet from the WAN is not forwarded to LAN
    step 6. Initiate a second outbound TCP connection to same TCP port
    step 7. Verify the connection is established
    step 8. Wait for natTcpTimeout - 5 seconds
    step 9. Retransmit the last TCP segment from the WAN to LAN
    step 10. Verify TCP packet from the WAN is forwarded to LAN

    NOTE: This test verifies that the router deletes the NAT entry
    for a TCP session that has been inactive for 'natTcpTimeout'
    seconds. The natTcpTimeout can be configured using the testvar
    natTcpTimeout.

    NOTE: The default natTcpTimeout on most NAT devices can be quite long.
    Some devices default to 24 hours (86400). This test can be quite
    time consuming with long timeout values.

    NOTE: If the CPE is not designed to immediately delete expired NAT 
    mappings, the 'natLagTime' testvar should be set to force CDRouter to 
    wait a fixed number of seconds before verifying that the mapping has 
    been deleted.


    References:

    IETF RFC 2663 "NAT Terminology and Considerations" Section 2.6: End of session for TCP, UDP and others

    https://tools.ietf.org/html/rfc2663#section-2.6

Test Module Name Synopsis
Verify NAT TCP SYN session timeout nat-timeout.tcl cdrouter_nat_timeout_11 Verify NAT TCP SYN session timeout


    step 1. Send outbound TCP SYN to next TCP port
    step 2. Wait for natSynTimeout to expire
    step 3. Send TCP SYN-ACK from WAN back to LAN host
    step 4. Verify TCP packet from the WAN is not forwarded to LAN
    step 5. Send a second outbound TCP SYN to same TCP port
    step 6. Wait for natSynTimeout - 5 seconds
    step 7. Send TCP SYN-ACK from WAN back to LAN host
    step 8. Verify TCP packet from the WAN is forwarded to LAN

    NOTE: This test verifies that the router maintains a NAT entry for a
    partially open TCP connection for 'natSynTimeout' seconds. The
    natSynTimeout setting is configured in the configuration file
    using the testvar natSynTimeout.

    NOTE: If the CPE is not designed to immediately delete expired NAT 
    mappings, the 'natLagTime' testvar should be set to force CDRouter to 
    wait a fixed number of seconds before verifying that the mapping has 
    been deleted.


    References:

    IETF RFC 2663 "NAT Terminology and Considerations" Section 2.6: End of session for TCP, UDP and others

    https://tools.ietf.org/html/rfc2663#section-2.6

Test Module Name Synopsis
Verify NAT UDP session timeout nat-timeout.tcl cdrouter_nat_timeout_20 Verify NAT UDP session timeout


    step 1. Initiate an outbound UDP Echo
    step 2. Verify the UDP packet is received on the WAN
    step 3. Wait for natUdpTimeout seconds
    step 4. Transmit the UDP response from the WAN to LAN
    step 5. Verify UDP packet from the WAN is not forwarded to LAN
    step 6. Initiate a second outbound UDP Echo
    step 7. Verify the packet is received on the WAN
    step 8. Wait for natUdpTimeout - 5 seconds
    step 9. Transmit the UDP response from the WAN to LAN
    step 10. Verify UDP packet from the WAN is forwarded to LAN

    NOTE: This test verifies that the router maintains a NAT entry for a
    UDP connections for 'natUdpTimeout' seconds. The natUdpTimeout
    setting is configured in the configuration file using the testvar
    natUdpTimeout.

    NOTE: If the CPE is not designed to immediately delete expired NAT 
    mappings, the 'natLagTime' testvar should be set to force CDRouter to 
    wait a fixed number of seconds before verifying that the mapping has 
    been deleted.


    References:

    IETF RFC 2663 "NAT Terminology and Considerations" Section 2.6: End of session for TCP, UDP and others

    https://tools.ietf.org/html/rfc2663#section-2.6

Test Module Name Synopsis
Verify NAT DNS session timeout nat-timeout.tcl cdrouter_nat_timeout_25 Verify NAT DNS session timeout


    step 1. Initiate an outbound DNS query
    step 2. Verify the DNS packet is received on the WAN
    step 3. Wait for natDnsTimeout seconds
    step 4. Transmit the DNS response from the WAN to LAN
    step 5. Verify DNS packet from the WAN is not forwarded to LAN
    step 6. Initiate a second outbound DNS query
    step 7. Verify the packet is received on the WAN
    step 8. Wait for natDnsTimeout - 5 seconds
    step 9. Transmit the DNS response from the WAN to LAN
    step 10. Verify DNS packet from the WAN is forwarded to LAN

    NOTE: This test verifies that the router maintains a NAT entry for
    a DNS connection for 'natDnsTimeout' seconds. The natDnsTimeout
    setting is configured in the configuration file using the testvar
    natDnsTimeout. If the implementation does not make any
    distintiction between DNS and generic UDP, this timeout should be
    set to the same value as the natUdpTimeout.

    NOTE: If the CPE is not designed to immediately delete expired NAT 
    mappings, the 'natLagTime' testvar should be set to force CDRouter to 
    wait a fixed number of seconds before verifying that the mapping has 
    been deleted.


    References:

    IETF RFC 2663 "NAT Terminology and Considerations" Section 2.6: End of session for TCP, UDP and others

    https://tools.ietf.org/html/rfc2663#section-2.6

Test Module Name Synopsis
Verify NAT ICMP session timeout nat-timeout.tcl cdrouter_nat_timeout_30 Verify NAT ICMP session timeout


    step 1. Initiate an outbound ICMP Echo Request
    step 2. Verify the packet is received on the WAN
    step 3. Wait for natIcmpTimeout seconds
    step 4. Transmit the Echo Reply from the WAN to LAN
    step 5. Verify ICMP packet from the WAN is not forwarded to LAN
    step 6. Initiate a second outbound ICMP Echo Request
    step 7. Verify the packet is received on the WAN
    step 8. Wait for natIcmpTimeout - 5 seconds
    step 9. Transmit the Echo Reply from the WAN to LAN
    step 10. Verify ICMP packet from the WAN is forwarded to LAN

    NOTE: This test verifies that the router maintains a NAT entry for a
    ICMP connections for 'natIcmpTimeout' seconds. The
    natIcmpTimeout setting is configured in the configuration file
    using the testvar natIcmpTimeout.

    NOTE: If the CPE is not designed to immediately delete expired NAT 
    mappings, the 'natLagTime' testvar should be set to force CDRouter to 
    wait a fixed number of seconds before verifying that the mapping has 
    been deleted.


    References:

    IETF RFC 2663 "NAT Terminology and Considerations" Section 2.6: End of session for TCP, UDP and others

    https://tools.ietf.org/html/rfc2663#section-2.6

Test Module Name Synopsis
Verify RTSP session timeout for established session nat-timeout.tcl cdrouter_nat_timeout_40 Verify RTSP session timeout for established session


    step 1. Initiate an outbound RTSP connection
    step 2. Verify the connection is established
    step 3. Wait for natRtspTimeout to expire
    step 4. Verify RTP and RTCP packets from the WAN are not forwarded to LAN
    step 5. Initiate a second outbound RTSP connection
    step 6. Verify the connection is established
    step 7. Wait for natRtspTimeout - 5 seconds
    step 8. Verify RTP and RTCP packets from the WAN are forwarded to LAN

    NOTE: This test verifies that the router deletes the RTSP entry
    for a RTSP session that has been inactive for 'natRtspTimeout'
    seconds. The natRtspTimeout can be configured using the testvar
    natRtspTimeout.

    NOTE: If the CPE is not designed to immediately delete expired NAT 
    mappings, the 'natLagTime' testvar should be set to force CDRouter to 
    wait a fixed number of seconds before verifying that the mapping has 
    been deleted.



nat-frag.tcl

NAPT tests for IPv4 fragmentation

Test Module Name Synopsis
Verify NAT with TCP IPv4 fragments nat-frag.tcl nat_frag_1 Verify NAT with TCP IPv4 fragments


    step 1. Initiate an outbound TCP connection
    step 2. Set outgoing MTU to 108 bytes to force fragmentation
    step 3. Send a fragmented TCP data segment
    step 4. Verify the TCP data is received on WAN side
    step 5. Send a return response back to LAN
    step 6. Verify return packet is received on the LAN
    step 7. Repeat for multiple packet sizes


    References:

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

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

    IETF Internet-Draft draft-ietf-intarea-frag-fragile-02 "Real Time Streaming Protocol (RTSP)" Section 4.2: Network Address Translation (NAT)

    IP fragmentation causes problems for Network Address Translation (NAT) devices. When a NAT
    device detects a new, outbound flow, it maps that flow's source port and IP address to another
    source port and IP address. Having created that mapping, the NAT device translates:

    * The Source IP Address and Source Port on each outbound packet.
    * The Destination IP Address and Destination Port on each inbound packet.

    A+P and Carrier Grade NAT (CGN) are two common NAT strategies. In both approaches the NAT
    device must virtually reassemble fragmented packets in order to translate and forward each
    fragment.

    Virtual reassembly in the network is problematic, because it is computationally expensive and
    because it is prone to attacks.

    https://tools.ietf.org/id/draft-ietf-intarea-frag-fragile-02.html#section-4.2

Test Module Name Synopsis
Verify NAT with TCP IPv4 out-of-order fragments nat-frag.tcl nat_frag_2 Verify NAT with TCP IPv4 out-of-order fragments


    step 1. Initiate an outbound TCP connection
    step 2. Set outgoing MTU to 108 bytes to force fragmentation
    step 3. Send a fragmented TCP data segment with fragments in reverse order
    step 4. Verify the TCP data is received on WAN side
    step 5. Send a return response back to LAN
    step 6. Verify return packet is received on the LAN
    step 7. Repeat for multiple packet sizes


    References:

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

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

    IETF Internet-Draft draft-ietf-intarea-frag-fragile-02 "Real Time Streaming Protocol (RTSP)" Section 4.2: Network Address Translation (NAT)

    IP fragmentation causes problems for Network Address Translation (NAT) devices. When a NAT
    device detects a new, outbound flow, it maps that flow's source port and IP address to another
    source port and IP address. Having created that mapping, the NAT device translates:

    * The Source IP Address and Source Port on each outbound packet.
    * The Destination IP Address and Destination Port on each inbound packet.

    A+P and Carrier Grade NAT (CGN) are two common NAT strategies. In both approaches the NAT
    device must virtually reassemble fragmented packets in order to translate and forward each
    fragment.

    Virtual reassembly in the network is problematic, because it is computationally expensive and
    because it is prone to attacks.

    https://tools.ietf.org/id/draft-ietf-intarea-frag-fragile-02.html#section-4.2

Test Module Name Synopsis
Verify NAT with UDP IPv4 fragments nat-frag.tcl nat_frag_11 Verify NAT with UDP IPv4 fragments


    step 1. Initiate an outbound UDP connection (UDP Echo) with large fragmented packet
    step 2. Verify the udp is received on WAN side
    step 3. Send a return response back to LAN
    step 4. Verify return packet is received on the LAN
    step 5. Repeat for multiple packet sizes


    References:

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

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

    IETF Internet-Draft draft-ietf-intarea-frag-fragile-02 "Real Time Streaming Protocol (RTSP)" Section 4.2: Network Address Translation (NAT)

    IP fragmentation causes problems for Network Address Translation (NAT) devices. When a NAT
    device detects a new, outbound flow, it maps that flow's source port and IP address to another
    source port and IP address. Having created that mapping, the NAT device translates:

    * The Source IP Address and Source Port on each outbound packet.
    * The Destination IP Address and Destination Port on each inbound packet.

    A+P and Carrier Grade NAT (CGN) are two common NAT strategies. In both approaches the NAT
    device must virtually reassemble fragmented packets in order to translate and forward each
    fragment.

    Virtual reassembly in the network is problematic, because it is computationally expensive and
    because it is prone to attacks.

    https://tools.ietf.org/id/draft-ietf-intarea-frag-fragile-02.html#section-4.2

Test Module Name Synopsis
Verify NAT with UDP IPv4 out-of-order fragments nat-frag.tcl nat_frag_12 Verify NAT with UDP IPv4 out-of-order fragments


    step 1. Initiate an outbound UDP connection (UDP Echo) with large fragmented packet
    step 2. Send fragments in reverse order
    step 3. Verify the udp is received on WAN side
    step 4. Send a return response back to LAN
    step 5. Verify return packet is received on the LAN
    step 6. Repeat for multiple packet sizes


    References:

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

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

    IETF Internet-Draft draft-ietf-intarea-frag-fragile-02 "Real Time Streaming Protocol (RTSP)" Section 4.2: Network Address Translation (NAT)

    IP fragmentation causes problems for Network Address Translation (NAT) devices. When a NAT
    device detects a new, outbound flow, it maps that flow's source port and IP address to another
    source port and IP address. Having created that mapping, the NAT device translates:

    * The Source IP Address and Source Port on each outbound packet.
    * The Destination IP Address and Destination Port on each inbound packet.

    A+P and Carrier Grade NAT (CGN) are two common NAT strategies. In both approaches the NAT
    device must virtually reassemble fragmented packets in order to translate and forward each
    fragment.

    Virtual reassembly in the network is problematic, because it is computationally expensive and
    because it is prone to attacks.

    https://tools.ietf.org/id/draft-ietf-intarea-frag-fragile-02.html#section-4.2

Test Module Name Synopsis
Verify NAT with ICMP IPv4 fragments nat-frag.tcl nat_frag_21 Verify NAT with ICMP IPv4 fragments


    step 1. Initiate an outbound ICMP request with large fragmented packet
    step 2. Verify the udp is received on WAN side
    step 3. Send a return response back to LAN
    step 4. Verify return packet is received on the LAN
    step 5. Repeat for multiple packet sizes


    References:

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

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

    IETF Internet-Draft draft-ietf-intarea-frag-fragile-02 "Real Time Streaming Protocol (RTSP)" Section 4.2: Network Address Translation (NAT)

    IP fragmentation causes problems for Network Address Translation (NAT) devices. When a NAT
    device detects a new, outbound flow, it maps that flow's source port and IP address to another
    source port and IP address. Having created that mapping, the NAT device translates:

    * The Source IP Address and Source Port on each outbound packet.
    * The Destination IP Address and Destination Port on each inbound packet.

    A+P and Carrier Grade NAT (CGN) are two common NAT strategies. In both approaches the NAT
    device must virtually reassemble fragmented packets in order to translate and forward each
    fragment.

    Virtual reassembly in the network is problematic, because it is computationally expensive and
    because it is prone to attacks.

    https://tools.ietf.org/id/draft-ietf-intarea-frag-fragile-02.html#section-4.2

Test Module Name Synopsis
Verify NAT with ICMP IPv4 out-of-order fragments nat-frag.tcl nat_frag_22 Verify NAT with ICMP IPv4 out-of-order fragments


    step 1. Initiate an outbound ICMP request with large fragmented packet
    step 2. Send fragments in reverse order
    step 3. Verify the ICMP is received on WAN side
    step 4. Send a return response back to LAN
    step 5. Verify return packet is received on the LAN
    step 6. Repeat for multiple packet sizes


    References:

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

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

    IETF Internet-Draft draft-ietf-intarea-frag-fragile-02 "Real Time Streaming Protocol (RTSP)" Section 4.2: Network Address Translation (NAT)

    IP fragmentation causes problems for Network Address Translation (NAT) devices. When a NAT
    device detects a new, outbound flow, it maps that flow's source port and IP address to another
    source port and IP address. Having created that mapping, the NAT device translates:

    * The Source IP Address and Source Port on each outbound packet.
    * The Destination IP Address and Destination Port on each inbound packet.

    A+P and Carrier Grade NAT (CGN) are two common NAT strategies. In both approaches the NAT
    device must virtually reassemble fragmented packets in order to translate and forward each
    fragment.

    Virtual reassembly in the network is problematic, because it is computationally expensive and
    because it is prone to attacks.

    https://tools.ietf.org/id/draft-ietf-intarea-frag-fragile-02.html#section-4.2


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

Test Module Name Synopsis
Verify existing TCP connections can be reestablished after WAN renumber renum-dhcp.tcl cdrouter_renumber_2 Verify existing TCP connections can be reestablished after WAN renumber


    step 1. Initiate TCP connection from LAN to WAN
    step 2. Change the wanIspAssignIp address to a new address
    step 3. Wait for DHCP lease to expire on WAN interface
    step 4. Verify WAN client sends DHCPREQUEST for same IP address
    step 5. Send DHCPNAK for that address
    step 6. Verify DHCP WAN client restarts DHCPDISCOVERY and learns new IP
    step 7. Verify new address responds to ping from LAN
    step 8. Verify the old address no longer responds to ping from LAN
    step 9. Initiate same TCP connection from LAN to WAN
    step 10. Verify TCP connection works
    step 11. Reset wanIspAssignIp to its original value and wait for a DHCP renew
    step 12. Verify the remoteHost responds to ping from the LAN


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol"

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

Test Module Name Synopsis
Verify LAN clients learn new DNS server during LAN side renew renum-dhcp.tcl cdrouter_renumber_3 Verify LAN clients learn new DNS server during LAN side renew


    step 1. Change the DNS server address
    step 2. Wait for WAN client to renew lease and learn new DNS Server
    step 3. Initiate LAN client renew
    step 4. Verify LAN client receives new DNS server address
    step 5. Reset the WAN client's DNS server address
    step 6. Verify the LAN client can ping a remote host


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol"

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

Test Module Name Synopsis
Verify LAN clients learn new longer domain name during LAN side renew renum-dhcp.tcl cdrouter_renumber_4 Verify LAN clients learn new longer domain name during LAN side renew


    step 1. Change the DNS domain name to a longer domain name
    step 2. Wait for WAN client to renew lease and learn new domain name
    step 3. Initiate LAN client renew
    step 4. Verify LAN client receives new domain name
    step 5. Reset the WAN client's DNS domain name
    step 6. Verify the LAN client can ping a remote host
    
    This test checks that the router correctly handles changes to the domain
    when it is modified. QACafe has seen cases where domain names passed on to
    DHCP clients were corrupted when changed after the WAN side renewed its DHCP
    lease.


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol"

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

Test Module Name Synopsis
Verify LAN clients learn new shorter domain name during LAN side renew renum-dhcp.tcl cdrouter_renumber_5 Verify LAN clients learn new shorter domain name during LAN side renew


    step 1. Change the DNS domain name to a shorter name
    step 2. Wait for WAN client to renew lease and learn new domain name
    step 3. Initiate LAN client renew
    step 4. Verify LAN client receives new domain name
    step 5. Reset the WAN client's DNS domain name
    step 6. Verify the LAN client can ping a remote host

    This test checks that the router correctly handles changes to the domain
    when it is modified. QACafe has seen cases where domain names passed on to
    DHCP clients were corrupted when changed after the WAN side renewed its DHCP
    lease.


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol"

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

Test Module Name Synopsis
Verify WAN side switches to new gateway after renumber renum-dhcp.tcl cdrouter_renumber_6 Verify WAN side switches to new gateway after renumber


    step 1. Change the default gateway that the DHCP server will assign
            to a new IPv4 address based on testvar wanIspNextIp
    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 DHCPACK that contains the new IP gateway
    step 5. Wait 5 seconds for CPE to update the default gateway
    step 6. Initiate TCP connection from LAN to WAN
    step 7. Verify TCP connection works using the new gateway
    step 8. Reset the WAN client's default gateway
    step 9. Verify the LAN client can ping a remote host

    NOTE: By default, this test case will wait 5 seconds after the DHCP client
    has updated before checking that the new gateway is working. This time
    interval can be adjusted using the testvar dhcpGatewayCache.


    References:

    IETF RFC 2131 "Dynamic Host Configuration Protocol"

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

Test Module Name Synopsis
Verify LAN clients learn additional DNS servers renum-dhcp.tcl cdrouter_renumber_50 Verify LAN clients learn additional DNS servers


    step 1. Add two more DNS servers to WAN side DHCP server
    step 2. Wait for WAN client to renew lease and learn new DNS servers
    step 3. Initiate LAN client renew
    step 4. Verify LAN client receives two new DNS servers

    NOTE: The router under test must support at least three DNS servers in order
    to pass this test. Some routers will only include one or two DNS servers in
    the DHCP DNS option offered to DHCP clients.


    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

Test Module Name Synopsis
Verify existing TCP connections can be reestablished after WAN renumber renum-pppoe.tcl cdrouter_renum_pppoe_2 Verify existing TCP connections can be reestablished after WAN renumber


    step 1. Initiate TCP connection from LAN to WAN
    step 2. Change the wanIspAssignIp address to a new address
    step 3. Terminate the current PPPoE session with the client
    step 4. Verify WAN attempts to establish new PPPoE session
    step 5. Initiate same TCP connection from LAN to WAN
    step 6. Verify TCP connection works
    step 7. Reset the WAN configuration to original IP address
    step 8. 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

Test Module Name Synopsis
Verify LAN clients learn new DNS server during LAN side renew renum-pppoe.tcl cdrouter_renum_pppoe_3 Verify LAN clients learn new DNS server during LAN side renew


    step 1. Change the DNS server address
    step 2. Terminate PPPoE session
    step 3. Verify PPPoE client starts new session
    step 4. Initiate LAN client renew
    step 5. Verify LAN client receives new DNS server address
    step 6. Reset the WAN configuration
    step 7. Verify the original PPPoE session has been reestablished


    References:

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

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

Test Module Name Synopsis
Verify WAN side switches to new gateway after renumber renum-pppoe.tcl cdrouter_renum_pppoe_6 Verify WAN side switches to new gateway after renumber


    step 1. Change the wanIspIp address to a new IP address
    step 2. Terminate PPPoE session on WAN interface
    step 3. Verify PPPoE client starts new session
    step 4. Initiate same TCP connection from LAN to WAN
    step 5. Verify TCP connection works
    step 6. Close TCP connection
    step 7. Change the wanIspIp to the original IP address
    step 8. Reset the WAN interface
    step 9. Verify the original PPPoE session has been reestablished


    References:

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

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

Test Module Name Synopsis
Verify LAN clients learn additional DNS server renum-pppoe.tcl cdrouter_renum_pppoe_50 Verify LAN clients learn additional DNS server


    step 1. Change secondary DNS servers on WAN side
    step 2. Terminate existing PPPoE session
    step 3. Verify PPPoE client starts new PPPoE session
    step 3. Initiate LAN client renew
    step 4. Verify LAN client receives new DNS server
    step 9. Reset the WAN configuration to original IP address
    step 10. Verify the original PPPoE session has been reestablished

    NOTE: The router under test must support at least two DNS servers in order
    to pass this test.


    References:

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

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


renum-pptp.tcl

WAN side renumbering tests with PPTP on the WAN

Test Module Name Synopsis
Verify WAN PPTP client learns new IP address when WAN server renumbers renum-pptp.tcl cdrouter_renum_pptp_1 Verify WAN PPTP client learns new IP address when WAN server renumbers


    step 1. Change the wanIspAssignIp address to a new address
    step 2. Terminate the current PPP session with the client
    step 3. Verify WAN attempts to establish new PPP session
    step 4. Verify LAN client can ping remote host using new address
    step 5. Resetting the WAN configuration to original IP address
    step 6. Verify the original PPPTP 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 2637 "Point-to-Point Tunneling Protocol (PPTP)"

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

Test Module Name Synopsis
Verify existing TCP connections can be reestablished after WAN renumber renum-pptp.tcl cdrouter_renum_pptp_2 Verify existing TCP connections can be reestablished after WAN renumber


    step 1. Initiate TCP connection from LAN to WAN
    step 2. Change the wanIspAssignIp address to a new address
    step 3. Terminate the current PPP session with the client
    step 4. Verify WAN attempts to establish new PPP session
    step 5. Initiate same TCP connection from LAN to WAN
    step 6. Verify TCP connection works
    step 7. Resetting the WAN configuration to original IP address
    step 8. Verify the original PPPTP 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 2637 "Point-to-Point Tunneling Protocol (PPTP)"

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

Test Module Name Synopsis
Verify LAN clients learn new DNS server during LAN side renew renum-pptp.tcl cdrouter_renum_pptp_3 Verify LAN clients learn new DNS server during LAN side renew


    step 1. Change the DNS server address
    step 2. Terminate PPP session
    step 3. Verify PPP client starts new session
    step 4. Initiate LAN client renew
    step 5. Verify LAN client receives new DNS server address
    step 6. Resetting the WAN configuration to original IP address
    step 7. Verify the original PPPTP session has been reestablished


    References:

    IETF RFC 2637 "Point-to-Point Tunneling Protocol (PPTP)"

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

Test Module Name Synopsis
Verify WAN side switches to new gateway after renumber renum-pptp.tcl cdrouter_renum_pptp_6 Verify WAN side switches to new gateway after renumber


    step 1. Initiate TCP connection from LAN to WAN
    step 2. Change the wanIspAssignIp address to a new address
    step 3. Terminate PPP session on WAN interface
    step 4. Verify PPP client starts new session
    step 5. Initiate same TCP connection from LAN to WAN
    step 6. Verify TCP connection works
    step 7. Resetting the WAN configuration to original IP address
    step 8. Verify the original PPPTP session has been reestablished


    References:

    IETF RFC 2637 "Point-to-Point Tunneling Protocol (PPTP)"

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

Test Module Name Synopsis
Verify LAN clients learn additional DNS server renum-pptp.tcl cdrouter_renum_pptp_50 Verify LAN clients learn additional DNS server


    step 1. Change secondary DNS servers on WAN side
    step 2. Terminate existing PPP session
    step 3. Verify PPP client starts new PPP session
    step 3. Initiate LAN client renew
    step 4. Verify LAN client receives new DNS server
    step 5. Resetting the WAN configuration
    step 6. Verify the original PPPTP session has been reestablished

    NOTE: The router under test must support at least two DNS servers in order
    to pass this test.

    References:

    IETF RFC 2637 "Point-to-Point Tunneling Protocol (PPTP)"

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


renum-l2tp.tcl

WAN side renumbering tests with L2TP on the WAN

Test Module Name Synopsis
Verify WAN L2TP client learns new IP address when WAN server renumbers renum-l2tp.tcl cdrouter_renum_l2tp_1 Verify WAN L2TP client learns new IP address when WAN server renumbers


    step 1. Change the WanIspAssignIp address to a new address
    step 2. Terminate the current PPP session with the client
    step 3. Verify WAN attempts to establish new PPP session
    step 4. Verify LAN client can ping remote host using new address
    step 5. Reset the WAN configuration back to original IP address
    step 6. Verify the original PPP 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 2661 "Layer Two Tunneling Protocol "L2TP""

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

Test Module Name Synopsis
Verify existing TCP connections can be reestablished after WAN renumber renum-l2tp.tcl cdrouter_renum_l2tp_2 Verify existing TCP connections can be reestablished after WAN renumber


    step 1. Initiate TCP connection from LAN to WAN
    step 2. Change the wanIspAssignIp address to a new address
    step 3. Terminate the current PPP session with the client
    step 4. Verify WAN attempts to establish new PPP session
    step 5. Initiate same TCP connection from LAN to WAN
    step 6. Verify TCP connection works
    step 7. Reset the WAN configuration back to original IP address
    step 8. Verify the original PPP 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 2661 "Layer Two Tunneling Protocol "L2TP""

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

Test Module Name Synopsis
Verify LAN clients learn new DNS server during LAN side renew renum-l2tp.tcl cdrouter_renum_l2tp_3 Verify LAN clients learn new DNS server during LAN side renew


    step 1. Change the DNS server address
    step 2. Terminate PPP session
    step 3. Verify PPP client starts new session
    step 4. Initiate LAN client renew
    step 5. Verify LAN client receives new DNS server address
    step 6. Reset the WAN configuration
    step 7. Verify the original PPP session has been reestablished


    References:

    IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""

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

Test Module Name Synopsis
Verify WAN side switches to new gateway after renumber renum-l2tp.tcl cdrouter_renum_l2tp_6 Verify WAN side switches to new gateway after renumber


    step 1. Initiate TCP connection from LAN to WAN
    step 2. Change the wanIspAssignIp address to a new address
    step 3. Terminate PPP session on WAN interface
    step 4. Verify PPP client starts new session
    step 5. Initiate same TCP connection from LAN to WAN
    step 6. Verify TCP connection works
    step 7. Reset the WAN configuration back to original IP address
    step 8. Verify the original PPP session has been reestablished


    References:

    IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""

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

Test Module Name Synopsis
Verify LAN clients learn additional DNS server renum-l2tp.tcl cdrouter_renum_l2tp_50 Verify LAN clients learn additional DNS server


    step 1. Change secondary DNS servers on WAN side
    step 2. Terminate existing PPP session
    step 3. Verify PPP client starts new PPP session
    step 3. Initiate LAN client renew
    step 4. Verify LAN client receives new DNS server
    step 5. Reset the WAN configuration back to original IP address
    step 6. Verify the original PPP session has been reestablished

    NOTE: The cable/dsl router must support at least 2 DNS servers inorder
    to pass this test.


    References:

    IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""

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


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


Test Module Name Synopsis
Verify ICMP Echo Requests from multiple LAN clients work through router icmp.tcl cdrouter_icmp_2 Verify ICMP Echo Requests from multiple LAN clients work through router


    step 1. Configure additional lan host
    step 2. Initiate an outbound ICMP Echo Request to a WAN destination from host 1
    step 3. Verify ICMP Echo Reply is received
    step 4. Initiate an outbound ICMP Echo Request to a WAN destination from host 2
    step 5. Verify ICMP Echo Reply is received


Test Module Name Synopsis
Verify ICMP Echo Requests to router's LAN side IP address from the LAN icmp.tcl cdrouter_icmp_5 Verify ICMP Echo Requests to router’s LAN side IP address from the LAN


    step 1. Initiate an outbound ICMP Echo Request to the router's LAN side IP address
    step 2. Verify ICMP Echo Reply is received


Test Module Name Synopsis
Verify ICMP Echo Requests to router's WAN side IP address from the LAN icmp.tcl cdrouter_icmp_6 Verify ICMP Echo Requests to router’s WAN side IP address from the LAN


    step 1. Initiate an outbound ICMP Echo Request to the router's WAN side IP address
    step 2. Verify ICMP Echo Reply is received


Test Module Name Synopsis
Verify ICMP Echo Requests to router's WAN side IP address from the WAN icmp.tcl cdrouter_icmp_7 Verify ICMP Echo Requests to router’s WAN side IP address from the WAN


    step 1. Initiate an outbound ICMP Echo Request to the router's WAN side IP
            address from the WAN
    step 2. Verify ICMP Echo Reply is received

    Note: the testvar wanPingRespond is used to determine if pinging the
    WAN-side of the DUT is expected to work or not.  It defaults to "no" which
    signifies that the device will not respond to pings on its WAN interface.


Test Module Name Synopsis
Verify ICMP Time Exceeded packet is sent when incoming UDP TTL is 1 icmp.tcl cdrouter_icmp_10 Verify ICMP Time Exceeded packet is sent when incoming UDP TTL is 1


    step 1. Set the IP TTL of outbound packets to 1
    step 2. Forward an UDP packet from a LAN client to the WAN
    step 3. Verify ICMP Time Exceeded packet is sent to initial LAN host
    step 4. Verify the ICMP Time Exceeded packet contains the IP header of the
            original packet


    References:

    IETF RFC 792 "INTERNET CONTROL MESSAGE PROTOCOL"

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

Test Module Name Synopsis
Verify NAT translates IP address in ICMP Time Exceeded packet icmp.tcl cdrouter_icmp_11 Verify NAT translates IP address in ICMP Time Exceeded packet


    step 1. Forward a UDP packet from a LAN client to the WAN
    step 2. Verify packet is received on WAN side
    step 3. Send ICMP Time Exceeded packet with original UDP packet as data
    step 4. Verify ICMP Time Exceeded packet is received by LAN host
    step 5. Verify that the contents of the original IP packet included
            in the ICMP Time Exceeded packet are properly translated by NAT
    step 6. The following fields are verified:

            IP length                    (length should not change)
            IP ID                        (unchanged)
            IP source address            (translated by NAT)
            IP destination address       (unchanged)
            IP checksum                  (recomputed by NAT)
            UDP source port              (translated by NAT)
            UDP destination port         (unchanged)

    NOTE: If an implementation changes the IPv4 ID field of an outgoing
    IPv4 packet, the returned IP header may contain a different ID field
    than the original packet. The IP header ID field verification can be
    skipped by configuring:


    References:

    IETF RFC 1631 "The IP Network Address Translator (NAT)" Section 3.3: Header Manipulations

    If an ICMP message is passed through NAT, it may require two address
    modifications and three checksum modifications. This is because most ICMP
    messages contain part of the original IP packet in the body.

    https://tools.ietf.org/html/rfc1631#section-3.3

Test Module Name Synopsis
Verify NAT translates IP address in ICMP Destination Unreachable with code port unreachable icmp.tcl cdrouter_icmp_12 Verify NAT translates IP address in ICMP Destination Unreachable with code port unreachable


    step 1. Forward a UDP packet from a LAN client to the WAN
    step 2. Verify packet is received on WAN side
    step 3. Send ICMP Destination Unreachable packet with original UDP packet as data
    step 4. Verify ICMP Destination Unreachable is received by LAN host
    step 5. Verify that the contents of the original IP packet included
            in the ICMP Destination Unreachable message are translated by NAT
    step 6. The following fields are verified:

            IP length                    (length should not change)
            IP ID                        (unchanged)
            IP source address            (translated by NAT)
            IP destination address       (unchanged)
            IP checksum                  (recomputed by NAT)
            UDP source port              (translated by NAT)
            UDP destination port         (unchanged)

    NOTE: If an implementation changes the IPv4 ID field of an outgoing
    IPv4 packet, the returned IP header may contain a different ID field
    than the original packet. The IP header ID field verification can be
    skipped by configuring:


    References:

    IETF RFC 1631 "The IP Network Address Translator (NAT)" Section 3.3: Header Manipulations

    If an ICMP message is passed through NAT, it may require two address
    modifications and three checksum modifications. This is because most ICMP
    messages contain part of the original IP packet in the body.

    https://tools.ietf.org/html/rfc1631#section-3.3

Test Module Name Synopsis
Verify NAT translates IP address in ICMP Destination Unreachable with code fragmentation needed icmp.tcl cdrouter_icmp_13 Verify NAT translates IP address in ICMP Destination Unreachable with code fragmentation needed


    step 1. Forward a UDP packet from a LAN client to the WAN with IPv4 DF=1
    step 2. Verify packet is received on WAN side
    step 3. Send ICMP Destination Unreachable with code 4 Fragmentation needed and
            DF set packet with original UDP packet as data
    step 4. Verify ICMP Destination Unreachable is received by LAN host
    step 5. Verify that the contents of the original IP packet included
            in the ICMP Destination Unreachable message are translated by NAT
    step 6. The following fields are verified:

            IP length                    (length should not change)
            IP ID                        (unchanged)
            IP source address            (translated by NAT)
            IP destination address       (unchanged)
            IP checksum                  (recomputed by NAT)
            UDP source port              (translated by NAT)
            UDP destination port         (unchanged)

    NOTE: If an implementation changes the IPv4 ID field of an outgoing
    IPv4 packet, the returned IP header may contain a different ID field
    than the original packet. The IP header ID field verification can be
    skipped by configuring:


    References:

    IETF RFC 1631 "The IP Network Address Translator (NAT)" Section 3.3: Header Manipulations

    If an ICMP message is passed through NAT, it may require two address
    modifications and three checksum modifications. This is because most ICMP
    messages contain part of the original IP packet in the body.

    https://tools.ietf.org/html/rfc1631#section-3.3

Test Module Name Synopsis
Verify NAT translates IP address in outbound ICMP Destination Unreachable with code port unreachable icmp.tcl cdrouter_icmp_14 Verify NAT translates IP address in outbound ICMP Destination Unreachable with code port unreachable


    step 1. Forward a UDP packet from LAN client to the WAN
    step 2. Verify packet is received on WAN side
    step 3. Forward a UDP packet from the WAN to the LAN client
    step 4. Send ICMP Destination Unreachable packet with original UDP packet as data
    step 5. Verify ICMP Destination Unreachable is received by WAN host
    step 6. Verify that the contents of the original IP packet included
            in the ICMP Destination Unreachable message are translated by NAT
    step 7. The following fields are verified:

            IP length                    (length should not change)
            IP ID                        (unchanged)
            IP source address            (unchanged)
            IP destination address       (translated by NAT)
            IP checksum                  (recomputed by NAT)
            UDP source port              (unchanged)
            UDP destination port         (translated by NAT)

    NOTE: If an implementation changes the IPv4 ID field of an outgoing
    IPv4 packet, the returned IP header may contain a different ID field
    than the original packet. The IP header ID field verification can be
    skipped by configuring:


    References:

    IETF RFC 1631 "The IP Network Address Translator (NAT)" Section 3.3: Header Manipulations

    If an ICMP message is passed through NAT, it may require two address
    modifications and three checksum modifications. This is because most ICMP
    messages contain part of the original IP packet in the body.

    https://tools.ietf.org/html/rfc1631#section-3.3

Test Module Name Synopsis
Verify router supports Path MTU Discovery over WAN interface icmp.tcl cdrouter_icmp_20 Verify router supports Path MTU Discovery over WAN interface


    step 1. Send 1500 byte UDP packet with IP Don't Fragment Flag = 1
    step 2. Check for an ICMP Destination Unreachable packet with code = 4
    step 3. Repeat process 2 more times until until an ICMP Destination
            Unreachable packet is received, or all 3 packets are sent
    step 4. If an ICMP Destination Unreachable packet was sent, verify that
            the code value is 4 and verify the MTU value in the ICMP header
    step 5. Reduce the UDP packet size by 1 byte and repeat the process
            until no ICMP Destination Unreachable packet is sent
    step 6. When a packet size is found that does not generate an
            ICMP Destination Unreachable message, verify packets can be
            forwarded using this packet size
    step 7. Verify the final MTU size is the same as the MTU size
            reported in the ICMP Destination Unreachable packet

    NOTE: This test starts with an initial MTU of 1500. If the WAN interface
    already supports this MTU (DHCP), then this test will pass without
    exercising the real part of Path MTU Discovery.

    NOTE: Some devices rate limit the number of ICMP packets that may be sent.
    This test will send 3 UDP packets over a 15 second window in order to
    generate an ICMP Destination Unreachable packet. If the router under test
    uses rate limiting on ICMP packets, it must allow at least one ICMP packet
    every 10 seconds.


    References:

    IETF RFC 1191 "Path MTU Discovery"

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

Test Module Name Synopsis
Verify ICMP Time Exceeded packet is sent when incoming TCP TTL is 1 icmp.tcl cdrouter_icmp_30 Verify ICMP Time Exceeded packet is sent when incoming TCP TTL is 1


    step 1. Set the IP TTL of outbound packets to 1
    step 2. Forward a TCP Syn packet from a LAN client to the WAN
    step 3. Verify ICMP Time Exceeded packet is sent to initial LAN host
    step 4. Verify the ICMP Time Exceeded packet contains the IP header of the
            original packet

    Additional Information on TCP Traceroute:

    https://www.freebsd.org/cgi/man.cgi?query=tcptraceroute


    References:

    IETF RFC 792 "INTERNET CONTROL MESSAGE PROTOCOL"

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


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


Test Module Name Synopsis
Inbound TCP connections to LAN hosts are blocked firewall.tcl cdrouter_firewall_2 Inbound TCP connections to LAN hosts are blocked


    step 1. Initiate a WAN TCP connection to a LAN client address
    step 2. Verify the connection is not established


Test Module Name Synopsis
DHCP server ignores DHCP client request from the WAN firewall.tcl cdrouter_firewall_10 DHCP server ignores DHCP client request from the WAN


    step 1. Start new DHCP client on WAN interface
    step 2. Verify new client does not obtain lease for IP address


Test Module Name Synopsis
DNS requests from the WAN are ignored by DNS proxy or relay firewall.tcl cdrouter_firewall_12 DNS requests from the WAN are ignored by DNS proxy or relay


    step 1. Initiate a DNS request from the LAN client to a known host
    step 2. Verify a valid DNS response is received
    step 3. Initiate a DNS request from remoteHost to the router's WAN IP
            for the same host name
    step 4. Verify that a DNS response is not received

    NOTE: This test case will be skipped if the router has a UDP
    virtual service configured on the DNS port 53.


Test Module Name Synopsis
Perform TCP port scan test on router's public WAN IP address firewall.tcl cdrouter_firewall_100 Perform TCP port scan test on router’s public WAN IP address


    step 1. Send ARP Replies for all LAN hosts and static LAN hosts
    step 2. Send TCP SYN packets from WAN to each port in the port scan range
    step 3. Verify packets are not forwarded to LAN
    step 4. Verify the router does not accept the TCP connection or
            send a RST for the TCP connection unless the port has
            been configured as an open or closed port
    step 5. Do not flag ports that have port forwarding configured

    NOTE: The speed of the scan can be adjusted using the 'portScanDelay'
    testvar. By default, it is set to 1. The value indicates the number of
    milliseconds to wait in between the sending of each packet:

    testvar portScanDelay 100

    NOTE: The list of closed and open ports can be configured using the
    'firewallTcpClosedPorts' and 'firewallTcpOpenPorts' testvars:

    testvar firewallTcpClosedPorts "2323"
    testvar firewallTcpOpenPorts "22 443"


Test Module Name Synopsis
Perform UDP port scan test on router's public WAN IP address firewall.tcl cdrouter_firewall_101 Perform UDP port scan test on router’s public WAN IP address


    step 1. Send ARP replys for all LAN hosts and static LAN hosts
    step 2. Send UDP packets from WAN to each port in the port scan range
    step 3. Verify packets are not forwarded to LAN
    step 4. Verify no ICMP Destination Unreachable messages or UDP Echo Replies
            are received unless UDP port is configured as an open or close port
    step 5. Do not flag ports that have port forwarding configured

    NOTE: A warning will still be issued if a packet is forwarded if
    it has been configured as a virtual service.

    NOTE: The speed of the scan can be adjusted using the 'portScanDelay'
    testvar. By default, it is set to 1. The value indicates the number of
    milliseconds to wait in between the sending of each packet:

    testvar portScanDelay 100

    NOTE: The list of closed and open ports can be configured using the
    'firewallUdpClosedPorts' and 'firewallUdpOpenPorts' testvars:

    testvar firewallUdpClosedPorts "2323"
    testvar firewallUdpOpenPorts "22 443"


Test Module Name Synopsis
Perform TCP fragmentation port scan test on router's public WAN IP address firewall.tcl cdrouter_firewall_110 Perform TCP fragmentation port scan test on router’s public WAN IP address


    step 1. Send ARP Replies for all LAN hosts and static LAN hosts
    step 2. Set the IPv4 fragmentation size to 28 bytes
    step 3. Send TCP SYN packets from WAN to each port in the port scan range
    step 4. Verify packets are not forwarded to LAN
    step 5. Verify the router does not accept the TCP connection or
            send a RST for the TCP connection unless the port has
            been configured as an open or closed port
    step 6. Do not flag ports that have port forwarding configured

    NOTE: A warning will still be issued if a packet is forwarded if
    it has been configured as a virtual service.

    NOTE: The speed of the scan can be adjusted using the 'portScanDelay'
    testvar. By default, it is set to 1. The value indicates the number of
    milliseconds to wait in between the sending of each packet:

    testvar portScanDelay 100

    NOTE: The list of closed and open ports can be configured using the
    'firewallTcpClosedPorts' and 'firewallTclOpenPorts' testvars:

    testvar firewallTcpClosedPorts "2323"
    testvar firewallTcpOpenPorts "22 443"


Test Module Name Synopsis
Verify firewall blocks/accepts piggyback TCP SYN connections from WAN firewall.tcl cdrouter_firewall_301 Verify firewall blocks/accepts piggyback TCP SYN connections from WAN


    step 1. Send a TCP SYN from LAN host to IP address on WAN
    step 2. Send a TCP SYN from the WAN host to the original LAN host
            using the same TCP source port
    step 3. If the router blocks simultaneous TCP SYNs through NAT
            (testvar 'natSimultaneousTcp' is set to no), verify the TCP
            SYN from the WAN is dropped

            OR

            If the router supports simultaneous TCP SYN through NAT
            (testvar 'natSimultaneousTcp' is set to yes), verify the TCP
            SYN from the WAN is forwarded to the LAN

    step 4. Repeat step 1 using new TCP port numbers
    step 5. Send a TCP SYN from the WAN host to the original LAN host
            using a new TCP source port
    step 6. Verify the TCP SYN from the WAN is dropped

    NOTE: This test verifies that the firewall only allows TCP packets
    for established TCP sessions. If simultaneous TCP open is supported through
    NAT, this test will verify that TCP SYN packets from the WAN are forwarded
    to the LAN. If simultaneous TCP open through NAT is not supported, the
    test will verify that no TCP SYN packets are allowed from the WAN to the
    LAN for sessions that have been initiated from the LAN.

    NOTE: This test also verifies that the NAT implementation is
    Port Restricted and that returning packets must have the same TCP
    source used to created the NAT binding.

    NOTE: Steps 4-6 of this test will be skipped if natMode is not
    "port-restricted".


Test Module Name Synopsis
Verify outbound packets are not forwarded if the source address is not a prefix of the interior network firewall.tcl cdrouter_firewall_508 Verify outbound packets are not forwarded if the source address is not a prefix of the interior network


    step 1. Create a new LAN client
    step 2. Assign an address outside of lanIp/lanMask
    step 3. Send traffic to the WAN from the martian source address
    step 4. Verify traffic is not forwarded
    step 5. Assign an address from the private-use address block outside lanIp/lanMask
    step 6. Send traffic to the WAN from the martian source address
    step 7. Verify traffic is not forwarded

    NOTE: This test ensures that the random martian address assigned
    to the LAN client in step 2 is outside of lanIp/lanMask, does not
    match any static routes configured with staticRouteLanNetwork and
    is not within any of the following reserved IP ranges: 0.0.0.0/8,
    127.0.0.0/8, 169.254.0.0/16, 192.88.99.0/24, 224.0.0.0/4,
    240.0.0.0/4, 255.255.255.255/32.


    References:

    IETF RFC 3704 "Ingress Filtering for Multihomed Networks"

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


firewall-out.tcl

Firewall tests for limiting outbound access to services

Test Module Name Synopsis
Verify CPE does not forward outbound TCP packets to ports that have been administratively blocked firewall-out.tcl cdrouter_firewall_outbound_1 Verify CPE does not forward outbound TCP packets to ports that have been administratively blocked


    step 1. Configure the DUT to block outbound access from the LAN to specific TCP ports
    step 2. Send a TCP SYN packet from the LAN to each blocked port
    step 3. Verify the DUT does not forward TCP packets to any of the blocked ports

    The firewallOutBlockedTcpPorts testvar is used to determine the list of TCP ports
    that the DUT has been configured to block access to.


Test Module Name Synopsis
Verify CPE does not forward outbound UDP packets to ports that have been administratively blocked firewall-out.tcl cdrouter_firewall_outbound_2 Verify CPE does not forward outbound UDP packets to ports that have been administratively blocked


    step 1. Configure the DUT to block outbound access from the LAN to specific UDP ports
    step 2. Send a UDP packet from the LAN to each blocked port
    step 3. Verify the DUT does not forward UDP packets to any of the blocked ports

    The firewallOutBlockedUdpPorts testvar is used to determine the list of UDP ports
    that the DUT has been configured to block access to.


Test Module Name Synopsis
Verify CPE does not forward outbound IP packets for protocols that have been administratively blocked firewall-out.tcl cdrouter_firewall_outbound_3 Verify CPE does not forward outbound IP packets for protocols that have been administratively blocked


    step 1. Configure the DUT to block outbound access from the LAN to specific IP Protocol types
    step 2. Send an IP packet from the LAN to the WAN for each blocked IP protocol
    step 3. Verify the DUT does not forward any of the blocked IP protocols

    The firewallOutBlockedIpProtos testvar is used to determine the list of IP Protocol types
    that the DUT has been configured to block access to.



apps.tcl

Application layer gateway (ALG) tests for FTP, DNS, TFTP, SMTP, POP3, MSN, RTSP and others

Test Module Name Synopsis
Verify router supports the active mode FTP PORT command apps.tcl cdrouter_app_2 Verify router supports the active mode FTP PORT command


    step 1. Initiate an outbound tcp connection to FTP server port
    step 2. Verify the connection is established
    step 3. Send the FTP port command using all upper case letters
    step 4. Verify router translates port command using router's address
    step 5. Initiate inbound TCP connection for FTP data connection
    step 6. Verify inbound TCP connection is established
    step 7. Close both connections


    References:

    IETF RFC 959 "FILE TRANSFER PROTOCOL (FTP)" Section 5.3: COMMANDS

    https://tools.ietf.org/html/rfc959#section-5.3

Test Module Name Synopsis
Multiple FTP connections using the same source port apps.tcl cdrouter_app_3 Multiple FTP connections using the same source port


    step 1. Set up second host using same source ports as original host
    step 2. Initiate an outbound TCP connection to FTP server port
    step 3. Verify the connection is established
    step 4. Build the FTP PORT command for the LAN client
    step 5. Start up second host on LAN
    step 6. Initate outbound connection from second LAN host to FTP server
            using same source port as FTP PORT command
    step 7. Send the FTP PORT command on first connection
    step 8. Verify router translates FTP PORT command using router's address
    step 9. Initiate inbound TCP connection for FTP data connection
    step 10. Verify inbound TCP connection is established
    step 11. Close both connections


    References:

    IETF RFC 959 "FILE TRANSFER PROTOCOL (FTP)" Section 5.3: COMMANDS

    https://tools.ietf.org/html/rfc959#section-5.3

Test Module Name Synopsis
Connections opened for FTP PORT command check for correct IPv4 address apps.tcl cdrouter_app_10 Connections opened for FTP PORT command check for correct IPv4 address


    step 1. Initiate an outbound FTP connection to FTP server port
    step 2. Verify the connection is established
    step 3. Send the FTP port command
    step 4. Verify router translates port command using router's address
    step 5. From new host, attempt inbound TCP connection for FTP data connection
    step 6. Verify inbound TCP connection is not established
    step 7. Close both connections


    References:

    IETF RFC 959 "FILE TRANSFER PROTOCOL (FTP)" Section 5.3: COMMANDS

    https://tools.ietf.org/html/rfc959#section-5.3

Test Module Name Synopsis
Verify FTP PORT command succeeds when TCP segment is retransmitted apps.tcl cdrouter_app_11 Verify FTP PORT command succeeds when TCP segment is retransmitted


    step 1. Initiate an outbound TCP connection to FTP server port
    step 2. Verify the connection is established
    step 3. Configure WAN side server to ignore TCP packets
    step 4. Send the FTP PORT command using all upper case letters
    step 5. Wait five seconds and retransmit last TCP segment
    step 6. Verify router translates port command using router's address
    step 5. Initiate inbound TCP connection for FTP data connection
    step 7. Verify inbound TCP connection is established
    step 8. Close both connections


    References:

    IETF RFC 959 "FILE TRANSFER PROTOCOL (FTP)" Section 5.3: COMMANDS

    https://tools.ietf.org/html/rfc959#section-5.3

Test Module Name Synopsis
Verify FTP PORT translation stays the same when TCP segment is retransmitted apps.tcl cdrouter_app_12 Verify FTP PORT translation stays the same when TCP segment is retransmitted


    step 1. Initiate an outbound TCP connection to FTP server port
    step 2. Verify the connection is established
    step 3. Configure WAN side server to ignore TCP packets
    step 4. Send the FTP port command
    step 5. Verify the FTP PORT command is translated
    step 6. Wait five seconds and retransmit last TCP segment
    step 7. Verify the FTP PORT command is translated to the same ports
    step 8. Initiate inbound TCP connection for FTP data connection
    step 9. Verify inbound TCP connection is established
    step 10. Close both connections


    References:

    IETF RFC 959 "FILE TRANSFER PROTOCOL (FTP)" Section 5.3: COMMANDS

    https://tools.ietf.org/html/rfc959#section-5.3

Test Module Name Synopsis
Verify router closes public ports opened with the FTP PORT command apps.tcl cdrouter_app_14 Verify router closes public ports opened with the FTP PORT command


    step 1. Initiate an outbound TCP connection to FTP server port
    step 2. Verify the connection is established
    step 3. Send the FTP PORT command using all upper case letters
    step 4. Verify router translates FTP PORT command using router's address
    step 5. Close the outbound TCP connection
    step 6. Wait ftpPortTimeout seconds for inbound port to be closed
    step 7. Initiate inbound TCP connection for FTP data connection
    step 8. Verify inbound TCP connection is blocked

    NOTE: The FTP PORT command will cause the router to open inbound ports for
    incoming FTP data connections. When the FTP control session is closed, the
    router should also close any inbound ports that have been opened.

    NOTE: The FTP PORT clean up interval can be configued using the
    ftpPortTimeout testvar.


    References:

    IETF RFC 959 "FILE TRANSFER PROTOCOL (FTP)" Section 5.3: COMMANDS

    https://tools.ietf.org/html/rfc959#section-5.3

Test Module Name Synopsis
Verify router supports the active mode FTP EPRT command apps.tcl cdrouter_app_15 Verify router supports the active mode FTP EPRT command


    step 1. Initiate an outbound TCP connection to FTP server port
    step 2. Verify the connection is established
    step 3. Send the FTP EPRT command using all upper case letters
    step 4. Verify router translates EPRT command using router's address
    step 5. Initiate inbound TCP connection for FTP data connection
    step 6. Verify inbound TCP connection is established
    step 7. Close both connections


    References:

    IETF RFC 2428 "FTP Extensions for IPv6 and NATs" Section 2: The EPRT Command

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

Test Module Name Synopsis
Verify translation of EPRT command accepts non default delimiters apps.tcl cdrouter_app_16 Verify translation of EPRT command accepts non default delimiters


    step 1. Initiate an outbound TCP connection to FTP server port
    step 2. Verify the connection is established
    step 3. Send the FTP EPRT command using delimiter character '~'
    step 4. Verify router translates EPRT command using router's address
    step 5. Initiate inbound TCP connection for FTP data connection
    step 6. Verify inbound TCP connection is established
    step 7. Close both connections

    NOTE: The FTP ALG on the device may change the delimiter back to the
    default delimiter character '|'.


    References:

    IETF RFC 2428 "FTP Extensions for IPv6 and NATs" Section 2: The EPRT Command

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

Test Module Name Synopsis
Verify router supports the passive mode FTP PASV command apps.tcl cdrouter_app_17 Verify router supports the passive mode FTP PASV command


    step 1. Initiate an outbound tcp connection to FTP server port
    step 2. Verify the connection is established
    step 3. Send the FTP PASV command using all upper case letters
    step 4. Verify PASV command is received on the WAN
    step 5. Send PASV response that includes server IP and port
    step 6. Verify the server IP and port is not translated on the LAN
    step 7. Initiate outbound TCP connection for FTP data connection
    step 8. Verify inbound TCP connection is established
    step 9. Close both connections


    References:

    IETF RFC 959 "FILE TRANSFER PROTOCOL (FTP)" Section 5.3: COMMANDS

    https://tools.ietf.org/html/rfc959#section-5.3

    IETF RFC 1123 "Requirements for Internet Hosts -- Application and Support" Section 4.1.2.6: PASV Command: RFC-959 Section 4.1.2

    A server-FTP MUST implement the PASV command.

    If multiple third-party transfers are to be executed during
    the same session, a new PASV command MUST be issued before
    each transfer command, to obtain a unique port pair.

    IMPLEMENTATION:
         The format of the 227 reply to a PASV command is not
         well standardized.  In particular, an FTP client cannot
         assume that the parentheses shown on page 40 of RFC 959
         will be present (and in fact, Figure 3 on page 43 omits
         them).  Therefore, a User-FTP program that interprets
         the PASV reply must scan the reply for the first digit
         of the host and port numbers.

         Note that the host number h1,h2,h3,h4 is the IP address
         of the server host that is sending the reply, and that
         p1,p2 is a non-default data transfer port that PASV has
         assigned.

    https://tools.ietf.org/html/rfc1123#section-4.1.2.6

Test Module Name Synopsis
Verify router supports the passive mode FTP EPSV command apps.tcl cdrouter_app_18 Verify router supports the passive mode FTP EPSV command


    step 1. Initiate an outbound tcp connection to FTP server port
    step 2. Verify the connection is established
    step 3. Send the FTP EPSV command using all upper case letters
    step 4. Verify EPSV command is received on the WAN
    step 5. Send EPSV response that includes server IP and port
    step 6. Verify the server IP and port is not translated on the LAN
    step 7. Initiate outbound TCP connection for FTP data connection
    step 8. Verify inbound TCP connection is established
    step 9. Close both connections


    References:

    IETF RFC 2428 "FTP Extensions for IPv6 and NATs"

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

Test Module Name Synopsis
Verify DNS queries to router are forwarded to real DNS server apps.tcl cdrouter_app_20 Verify DNS queries to router are forwarded to real DNS server


    step 1. Initiate a DNS query to the router's LAN ip address
    step 2. Verify the query is received by real DNS server on the WAN side
    step 3. The query may be received by the primary or backup DNS server
    step 4. Send a return response back to LAN
    step 5. Verify the response is received by the LAN client

    NOTE: The router must support some type of DNS relay or proxy to pass this
    test case.


Test Module Name Synopsis
Verify DNS queries sent to primary DNS server apps.tcl cdrouter_app_21 Verify DNS queries sent to primary DNS server


    step 1. Initiate a DNS query to the primary DNS server from the LAN
    step 2. Verify the query is received by real DNS server on the WAN side
    step 3. Depending on the implementation, the query may be received by
            the primary or backup DNS server
    step 4. Send a response to the LAN
    step 5. Verify the response is received by the LAN client


Test Module Name Synopsis
Verify DNS queries sent to backup DNS server apps.tcl cdrouter_app_22 Verify DNS queries sent to backup DNS server


    step 1. Initiate a DNS query to the backup DNS server from the LAN
    step 2. Verify the query is received by real DNS server on the WAN side
    step 3. Depending on the implementation, the query may be received by
            the primary or backup DNS server
    step 4. Send a response to the LAN
    step 5. Verify the response is received by the LAN client.


Test Module Name Synopsis
Verify DNS relay on router fails over to backup DNS server apps.tcl cdrouter_app_25 Verify DNS relay on router fails over to backup DNS server


    step 1. Configure the primary DNS server to ignore all DNS requests
    step 2. Initiate a DNS query to the router's LAN ip address
    step 3. Verify the query is received by the backup DNS server on the WAN side
    step 4. Send a response back to the LAN
    step 5. Verify the response is received by the LAN client

    NOTE: Some routers will alternate sending DNS queries between the configured
    or learned DNS servers. Other routers will send queries to all of the
    configured or learned DNS servers at the same time. This test will continue
    to send DNS queries for up to 120 seconds by default. This time interval may
    be changed by configuring the testvar dnsRelayFailover to the number of
    seconds to wait before failover should happen.


Test Module Name Synopsis
Verify DNS relay on router fails over to backup DNS server (using same ID for retransmissions) apps.tcl cdrouter_app_26 Verify DNS relay on router fails over to backup DNS server (using same ID for retransmissions)


    step 1. Configure the primary DNS server to ignore all DNS requests
    step 2. Initiate a DNS query to the router's LAN ip address
    step 3. Verify the query is received by the backup DNS server on the WAN side
    step 4. Send a response back to the LAN
    step 5. Verify the response is received by the LAN client

    NOTE: Some routers will alternate sending DNS queries between the configured
    or learned DNS servers. Other routers will send queries to all of the
    configured or learned DNS servers at the same time. This test will continue
    to send DNS queries for up to 120 seconds by default. This time interval may
    be changed by configuring the testvar dnsRelayFailover to the number of
    seconds to wait before failover should happen.

    NOTE: For this test, the LAN client will use the same DNS transaction ID for
    all DNS query retransmissions.


Test Module Name Synopsis
Verify DNS relay on router fails over to third DNS server apps.tcl cdrouter_app_27 Verify DNS relay on router fails over to third DNS server


    step 1. Configure the primary and secondary DNS servers to ignore all DNS requests
    step 2. Initiate a DNS query to the router's LAN ip address
    step 3. Verify the query is received by the third DNS server on the WAN side
    step 4. Send a response back to the LAN
    step 5. Verify the response is received by the LAN client

    NOTE: Some routers will alternate sending DNS queries between the configured
    or learned DNS servers. Other routers will send queries to all of the
    configured or learned DNS servers at the same time. This test will continue
    to send DNS queries for up to 120 seconds by default. This time interval may
    be changed by configuring the testvar dnsRelayFailover to the number of
    seconds to wait before failover should happen.


Test Module Name Synopsis
Verify DNS relay on router fails over to third DNS server (using same ID for retransmissions) apps.tcl cdrouter_app_28 Verify DNS relay on router fails over to third DNS server (using same ID for retransmissions)


    step 1. Configure the primary and secondary DNS server to ignore all DNS requests
    step 2. Initiate a DNS query to the router's LAN ip address
    step 3. Verify the query is received by the backup DNS server on the WAN side
    step 4. Send a response back to the LAN
    step 5. Verify the response is received by the LAN client

    NOTE: Some routers will alternate sending DNS queries between the configured
    or learned DNS servers. Other routers will send queries to all of the
    configured or learned DNS servers at the same time. This test will continue
    to send DNS queries for up to 120 seconds by default. This time interval may
    be changed by configuring the testvar dnsRelayFailover to the number of
    seconds to wait before failover should happen.

    NOTE: For this test, the LAN client will use the same DNS transaction ID for
    all DNS query retransmissions.


Test Module Name Synopsis
Verify DNS queries sent directly to a 3rd party DNS server apps.tcl cdrouter_app_30 Verify DNS queries sent directly to a 3rd party DNS server


    step 1. Create a new DNS server on the WAN with a unique IP address
    step 2. Initiate a DNS query to to the new DNS server
    step 3. Verify the query is received by the DNS server on the WAN side
    step 4. Send a response back to the LAN
    step 5. Verify the response is received by the LAN client

    NOTE: This test verifies that DNS clients and DNS tools running on a LAN
    client can initiate DNS queries to a third party DNS server that has not
    been configured on the router nor learned by the router.

    NOTE: If the testvar dnsCaptive is set to yes, the test will expect DNS
    queries to be sent to the original WAN side DNS servers and not the 3rd
    party DNS server.


Test Module Name Synopsis
Verify router supports wrapping of TCP sequence number for FTP transfers apps.tcl cdrouter_app_100 Verify router supports wrapping of TCP sequence number for FTP transfers


    step 1. Set the initial TCP sequence number to 0xfffffffc
    step 2. Initiate an outbound TCP connection to FTP server port
    step 3. Verify the connection is established
    step 4. Send the FTP PORT command using all upper case letters
    step 5. Verify router translates FTP PORT command using router's address
    step 6. Verify the sequence number has correctly wrapped
    step 7. Initiate inbound TCP connection for FTP data connection
    step 8. Verify inbound TCP connection is established
    step 9. Close both connections
    step 10. Repeat for initial TCP sequence numbers 0xfffffffc - 0x00000001


Test Module Name Synopsis
Verify HTTPS session through the router apps.tcl cdrouter_app_110 Verify HTTPS session through the router


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


Test Module Name Synopsis
Verify SMTP session through the router apps.tcl cdrouter_app_120 Verify SMTP session through the router


    step 1. Initiate an outbound TCP connection to SMTP server
    step 2. Send email message using SMTP server
    step 3. Verify SMTP server correctly receives email message
    step 4. Close SMTP session from LAN side


    References:

    IETF RFC 821 "SIMPLE MAIL TRANSFER PROTOCOL"

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

Test Module Name Synopsis
Verify POP3 session through the router apps.tcl cdrouter_app_122 Verify POP3 session through the router


    step 1. Initiate an outbound TCP connection to POP3 server
    step 2. Retreive email messages using POP3 protocol
    step 3. Verify POP3 server correctly returns email messages
    step 4. Close POP3 session from LAN side


    References:

    IETF RFC 1939 "Post Office Protocol - Version 3"

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

Test Module Name Synopsis
Verify TFTP session through the router apps.tcl cdrouter_app_124 Verify TFTP session through the router


    step 1. Startup a TFTP server on the WAN
    step 2. Initiate an outbound TFTP connection to TFTP server from LAN
    step 3. Send TFTP GET to receive file via TFTP
    step 4. Verify TFTP server correctly returns file via TFTP
    step 5. Close TFTP session from LAN side


    References:

    IETF RFC 1350 "THE TFTP PROTOCOL (REVISION 2)"

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

Test Module Name Synopsis
Verify NTP session through the router apps.tcl cdrouter_app_126 Verify NTP session through the router


    step 1. Initiate an outbound NTP connection to NTP server
    step 2. Verify NTP request is sent to the WAN
    step 3. Verify NTP response is sent to LAN client


Test Module Name Synopsis
Verify STUN session through the router apps.tcl cdrouter_app_130 Verify STUN session through the router


    step 1. Initiate an outbound STUN Binding Request to remoteHost
    step 2. Verify STUN Binding Response is received
    step 3. Verify the STUN MAPPED-ADDRESS matches the expected NAT Address


    References:

    IETF RFC 3489 "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)"

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

Test Module Name Synopsis
Verify authenticated STUN session through the router apps.tcl cdrouter_app_131 Verify authenticated STUN session through the router


    step 1. Configure STUN server and client to use authentication
    step 2. Initiate an outbound STUN Binding Request to remoteHost
    step 3. STUN server should sent back a 401 Binding Error Response
    step 4. STUN client retransmits Binding Request using message-integrity attribute
    step 5. Verify STUN Binding Response is received
    step 6. Verify the STUN MAPPED-ADDRESS matches the expected NAT Address


    References:

    IETF RFC 3489 "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)"

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

Test Module Name Synopsis
Verify IPv4 L2GRE session through the router apps.tcl cdrouter_app_140 Verify IPv4 L2GRE session through the router


    step 1. Enable L2GRE endpoint on the LAN client
    step 2. Create a new IPv4 address on the WAN for the other L2GRE endpoint
    step 3. Initiate an ICMP ping from LAN to WAN using L2GRE tunnel
    step 4. Verify the ICMP is successful


    References:

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

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

Test Module Name Synopsis
Verify router translates MSN File Transfer Invite messages apps.tcl cdrouter_app_302 Verify router translates MSN File Transfer Invite messages


    step 1. Open a TCP connection to the MSN Dispatch Server at port 1863
    step 2. After login, look for XFR command to MSN Notification Server
    step 3. Open a TCP connection to the MSN Notification Server
    step 4. Login and send XFR command for MSN Switchboard Server
    step 5. Look for XFR command to MSN Switchboard Server
    step 6. Open a TCP connection from LAN client to MSN Switchboard Server on WAN
    step 7. Send a MSN Invite message for a file transfer application
    step 8. Send a MSN Accept message with LAN side IP address and port
    step 9. Verify the MSN Accept message is received on the WAN side
    step 10. Verify the IP address has been NAT translated
    step 11. Verify an inbound TCP connection can be created to the LAN
             client using the NAT translated IP and port number


Test Module Name Synopsis
Verify router translates MSN Voice Invite messages apps.tcl cdrouter_app_305 Verify router translates MSN Voice Invite messages


    step 1. Open a TCP connection to the MSN Dispatch Server at port 1863
    step 2. After login, look for XFR command to MSN Notification Server
    step 3. Open a TCP connection to the MSN Notification Server
    step 4. Login and send XFR command for MSN Switchboard Server
    step 5. Look for XFR command to MSN Switchboard Server
    step 6. Open a TCP connection from LAN client to MSN Switchbaord Server on WAN
    step 7. Send a MSN Invite message for a voice application
    step 8. Send a MSN Accept message with LAN side IP address and port
    step 9. Verify the MSN accept message is received on the WAN side
    step 10. Verify the IP address has been NAT translated


Test Module Name Synopsis
Verify router does not modify MSN fields related to NAT detection apps.tcl cdrouter_app_310 Verify router does not modify MSN fields related to NAT detection


    step 1. Open a TCP connection to the MSN Dispatch Server at port 1863
    step 2. After login, look for XFR command to MSN Notification Server
    step 3. Open a TCP connection to the MSN Notification Server
    step 4. Login and send XFR command for MSN Switchboard Server
    step 5. Look for XFR command to MSN Switchboard Server
    step 6. Open a TCP connection from LAN client to MSN Switchbaord Server on WAN
    step 7. Send a MSN Invite message for a file transfer application
    step 8. Send a MSN Accept message with LAN side IP address and port
            Include IP-Address-Internal and PortX-Internal fields in MSN
            Invite message
    step 9. Verify the MSN Invite message is received on the WAN side
    step 10. Verify the IP address has been NAT translated
    step 11. Verify the IP-Address-Internal and PortX-Internal fields are not
             translated by the MSN ALG
    step 12. Verify an inbound TCP connection can be created to the LAN
             client using the NAT translated IP and port number


Test Module Name Synopsis
Verify basic RTSP session with UDP transport apps.tcl cdrouter_rtsp_1 Verify basic RTSP session with UDP transport


    step 1. Establish TCP session from LAN client to RTSP server at port 554
    step 2. Send a RTSP DESCRIBE for URL from client to server
    step 3. Verify server response to client is code 200
    step 4. Allocate 2 UDP ports on client for transport
    step 5. Send a RTSP SETUP for URL from client to server using Transport
    step 6. Verify RTSP server receives transport with port translations
    step 7. Verify server response to client is code 200
    step 8. Verify UDP forwarding from WAN to LAN for each AVP port in RTSP transport
    step 9. Send RTSP TEARDOWN and close TCP session from LAN client

    NOTE: The NAT ALG must handle translating the Transport field included in
    the RTSP SETUP from the client.


    References:

    IETF RFC 2326 "Real Time Streaming Protocol (RTSP)"

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

Test Module Name Synopsis
Verify basic RTSP session with UDP transport for multiple LAN hosts apps.tcl cdrouter_rtsp_2 Verify basic RTSP session with UDP transport for multiple LAN hosts


    step 1. Create a second DHCP host on the LAN
    step 2. Setup RTSP transport for each client using the same src ports
    step 3. For each client, verify UDP forwarding from WAN to LAN for each
            AVP port in RTSP transport
    step 4. For each client, send RTSP TEARDOWN and close TCP session from
            LAN client

    NOTE: The NAT ALG must handle translating the Transport field included in
    the RTSP SETUP from the client.


    References:

    IETF RFC 2326 "Real Time Streaming Protocol (RTSP)"

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

Test Module Name Synopsis
Verify RTSP transport is translated in both outbound and inbound directions apps.tcl cdrouter_rtsp_10 Verify RTSP transport is translated in both outbound and inbound directions


    step 1. Establish RTSP session to remoteHost on WAN
    step 2. Send a RTSP DESCRIBE, SETUP, and PLAY to establish the transport
    step 3. Verify the client port values are translated in the outbound direction
    step 4. Verify the client port values are translated in the inbound direction
    step 5. Verify UDP forwarding from WAN to LAN for each AVP port in RTSP transport
    step 6. Send RTSP TEARDOWN and close TCP session from LAN client


    References:

    IETF RFC 2326 "Real Time Streaming Protocol (RTSP)"

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

Test Module Name Synopsis
Verify RTSP port mapping is deleted after TEARDOWN and TCP close apps.tcl cdrouter_rtsp_20 Verify RTSP port mapping is deleted after TEARDOWN and TCP close


    step 1. Establish RTSP session to a remote host on the WAN
    step 2. Send a RTSP DESCRIBE, SETUP, and PLAY to establish the transport
    step 3. Verify UDP forwarding from WAN to LAN for each AVP port in RTSP transport
    step 4. Send TEARDOWN from client and close TCP connection
    step 5. Verify UDP forwarding fails from WAN to LAN for each AVP port in RTSP transport

    Note: The amount of time between the RTSP TEARDOWN and the verification of
    the port mappings can be adjusted using the testvar rtspTeardownDelay. This
    defaults to 5 seconds.


    References:

    IETF RFC 2326 "Real Time Streaming Protocol (RTSP)"

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

Test Module Name Synopsis
Verify RTSP port mapping is deleted after TEARDOWN and without TCP close apps.tcl cdrouter_rtsp_21 Verify RTSP port mapping is deleted after TEARDOWN and without TCP close


    step 1. Establish RTSP session to a remote host on the WAN
    step 2. Send a RTSP DESCRIBE, SETUP, and PLAY to establish the transport
    step 3. Verify UDP forwarding from WAN to LAN for each AVP port in RTSP transport
    step 4. Send TEARDOWN from client
    step 5. Do not close the TCP session from client to RTSP server
    step 6. Verify UDP forwarding fails from WAN to LAN for each AVP port in RTSP transport

    Note: RTSP clients are allowed to maintain persistent connections to the
    RTSP server. They are not required to close the TCP session when a RTSP
    session is ended.

    Note: The amount of time between the RTSP TEARDOWN and the verification of
    the port mappings can be adjusted using the testvar rtspTeardownDelay. This
    defaults to 5 seconds.


    References:

    IETF RFC 2326 "Real Time Streaming Protocol (RTSP)"

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

Test Module Name Synopsis
Verify RTSP port mappings still work when TCP connection is closed apps.tcl cdrouter_rtsp_22 Verify RTSP port mappings still work when TCP connection is closed


    step 1. Establish RTSP session to a remote host on the WAN
    step 2. Send a RTSP DESCRIBE, SETUP, and PLAY to establish the transport
    step 3. Verify UDP forwarding from WAN to LAN for each AVP port in RTSP transport
    step 4. Do not send TEARDOWN from client to end the RTSP session
    step 5. Close the TCP session from client to RTSP server
    step 6. Verify UDP forwarding succeeds from WAN to LAN for each AVP port in RTSP transport


    References:

    IETF RFC 2326 "Real Time Streaming Protocol (RTSP)"

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

Test Module Name Synopsis
Verify IPv4 destination in client transport SETUP is translated to public IP apps.tcl cdrouter_rtsp_30 Verify IPv4 destination in client transport SETUP is translated to public IP


    step 1. Establish TCP session from LAN client to RTSP server at port 554
    step 2. Send a RTSP DESCRIBE for URL from client to server
    step 3. Verify server response to client is code 200
    step 4. Allocate 2 UDP ports on client for transport
    step 5. Send a RTSP SETUP with transport that includes destination field
    step 6. Verify server receives transport with transport IP address in destination field
    step 7. Verify UDP forwarding from WAN to LAN for each AVP port in RTSP transport
    step 8. Send RTSP TEARDOWN and close TCP session from LAN client


    References:

    IETF RFC 2326 "Real Time Streaming Protocol (RTSP)"

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

Test Module Name Synopsis
Verify RTSP ALG supports persistent TCP connections apps.tcl cdrouter_rtsp_50 Verify RTSP ALG supports persistent TCP connections


    step 1. Establish RTSP session to remoteHost on WAN
    step 2. Send a RTSP DESCRIBE, SETUP, and PLAY to establish the transport
    step 3. Using the same TCP connection, setup a second RTSP session
    step 4. Verify UDP forwarding from WAN to LAN for first session
    step 5. Verify UDP forwarding from WAN to LAN for second session
    step 6. Send RTSP TEARDOWN for first session
    step 7. Send RTSP TEARDOWN for second session
    step 8. Close TCP session from LAN client


    References:

    IETF RFC 2326 "Real Time Streaming Protocol (RTSP)" Section 1.1: Purpose

    https://tools.ietf.org/html/rfc2326#section-1.1

    IETF Internet-Draft draft-ietf-mmusic-2326bis-05 "TCP Fast Open"

    https://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-05

Test Module Name Synopsis
Verify RTSP session with different IPv4 address for RTP media server apps.tcl cdrouter_rtsp_60 Verify RTSP session with different IPv4 address for RTP media server


    step 1. Create a new server on the WAN for the RTP media source
    step 2. Establish TCP session from LAN client to RTSP server at port 554
    step 3. Send a RTSP DESCRIBE for URL from client to server
    step 4. Verify server response to client is code 200
    step 5. Allocate 2 UDP ports on client for transport
    step 6. Send a RTSP SETUP for URL from client to server using Transport
    step 7. Verify RTSP server receives transport with port translations
    step 8. Verify server response to client is code 200 along with
            Transport: header that specifies a source IPv4 address
            that is different from the RTSP server
    step 9. Verify UDP forwarding from WAN to LAN for each AVP port in RTSP transport
            using the IPv4 source address of the RTP media
    step 10. Send RTSP TEARDOWN and close TCP session from LAN client

    NOTE: The NAT ALG must handle translating the Transport field included in
    the RTSP SETUP from the client.


    References:

    IETF RFC 2326 "Real Time Streaming Protocol (RTSP)"

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

Test Module Name Synopsis
Verify RTSP session timeout for established session apps.tcl cdrouter_rtsp_70 Verify RTSP session timeout for established session


    step 1. Initiate an outbound RTSP connection
    step 2. Verify the connection is established
    step 3. Verify RTP and RTCP packets from the WAN are forwarded to LAN
    step 4. Send RTSP PAUSE message from LAN to WAN
    step 5. Send keep-alive RTSP GET_PARAMETER messages from LAN to
            WAN every rtspGetParameterInterval seconds until natRtspTimeout
            seconds elapses
    step 6. Send RTSP PLAY message from LAN to WAN
    step 7. Verify RTP and RTCP packets from the WAN are forwarded to LAN
    step 8. Send RTSP TEARDOWN and close TCP session from LAN client


    References:

    IETF RFC 2326 "Real Time Streaming Protocol (RTSP)"

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

Test Module Name Synopsis
Verify a Multipath TCP connection can be opened apps.tcl cdrouter_mptcp_1 Verify a Multipath TCP connection can be opened


        step 1. Initiate MPTCP connection from LAN client to WAN server
        step 2. Verify MPTCP connection is established
        step 3. Verify MPTCP connection attributes on LAN client and
                WAN server match
        step 4. Close MPTCP connection


    References:

    IETF RFC 8684 "TCP Extensions for Multipath Operation with Multiple Addresses"

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

Test Module Name Synopsis
Verify a Multipath TCP connection with two subflows can be opened apps.tcl cdrouter_mptcp_2 Verify a Multipath TCP connection with two subflows can be opened


        step 1. Initiate MPTCP connection from LAN client to WAN server
        step 2. Verify MPTCP connection is established
        step 3. Verify MPTCP connection attributes on LAN client and
                WAN server match
        step 4. Transmit data on MPTCP connection from LAN client
        step 5. Verify data is received by WAN server
        step 6. Initiate new MPTCP subflow on MPTCP connection from
                step 1
        step 7. Verify new MPTCP subflow is established
        step 8. Verify MPTCP subflow attributes on LAN client and WAN
                server match
        step 9. Transmit data on MPTCP connection from LAN client
        step 10. Verify data is received by WAN server
        step 11. Close MPTCP connection


    References:

    IETF RFC 8684 "TCP Extensions for Multipath Operation with Multiple Addresses"

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


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


Test Module Name Synopsis
Verify tunnel mode IPSEC packets pass through router ipsecpt.tcl cdrouter_ipsecpt_2 Verify tunnel mode IPSEC packets pass through router


    step 1. Forward an IPSEC packet from LAN to WAN
            Note: Tunnel mode IPSEC packets are sent as IPv4 protocol 50
    step 2. Verify the packet is received on the WAN
    step 3. Send a tunnel mode IPSEC packet from the WAN side to LAN
    step 4. Verify the packet is received on the LAN

    Note: The testvar alwaysUseIke can be used to initiate an IKE connection
    prior to sending tunnel mode IPSEC packets.


Test Module Name Synopsis
Fragmented tunnel mode IPSEC packets are forwarded between LAN and WAN ipsecpt.tcl cdrouter_ipsecpt_3 Fragmented tunnel mode IPSEC packets are forwarded between LAN and WAN


    step 1. Forward a fragmented IPSEC packet from LAN to WAN
            Note: Tunnel mode IPSEC packets are sent as IPv4 protocol 50
    step 2. Verify all IPv4 fragments are received on the WAN
    step 3. Send an IPSEC packet from the WAN side to the router's public IPv4 address
    step 4. Verify all IPv4 fragments are received on the LAN

    NOTE: If the wanMode for this test is PPPoE, the MTU on both stacks is set
          to 1492. Otherwise, the MTU is set to 1500. The test tries to send
          1500 bytes of IPv4 data to resemble an IPSEC tunnel with a 1500 byte
          payload.

    Note: The testvar alwaysUseIke can be used to initiate an IKE connection
    prior to sending tunnel mode IPSEC packets.


Test Module Name Synopsis
Verify unknown IPv4 protocol types using the pass through mechanism ipsecpt.tcl cdrouter_ipsecpt_30 Verify unknown IPv4 protocol types using the pass through mechanism


    step 1. Forward an IPv4 packet with protocol 52
    step 2. Check for packet on WAN side of router
    step 3. Forward the IPv4 protocol packet back to router's public IPv4 address
    step 4. By default, the packet should not be received on the LAN
    step 5. If the testvar 'unknownPassthrough' is set to yes, the packet should
            be received on the LAN

    By default, this test verifies that unknown IPv4 protocol packets are
    forwarded by the router. However, if the router does not handle pass
    through packets for all IPv4 protocol types, the testvar
    'unknownPassthrough' should be set to 'no'. It defaults to 'yes'


Test Module Name Synopsis
Verify the maximum number of IPSEC pass through connections for a single LAN host ipsecpt.tcl cdrouter_ipsecpt_100 Verify the maximum number of IPSEC pass through connections for a single LAN host


    step 1. Forward a tunnel mode IPSEC packet from LAN to unique WAN IPv4 address
            Note: Tunnel mode IPSEC packets are sent as IPv4 protocol 50
    step 2. Verify the packet is received on the WAN
    step 3. Send a tunnel mode IPSEC packet from the WAN side to LAN
    step 4. Verify the packet is received on the LAN
    step 5. Repeat up to the ipsecMaxTunnels value

    Note: Each IPSEC tunnel uses a unique IPv4 destination address.

    Note: The testvar alwaysUseIke can be used to initiate an IKE connection
    prior to sending tunnel mode IPSEC packets.


Test Module Name Synopsis
Verify IPSEC pass through with multiple LAN clients using same VPN server ipsecpt.tcl cdrouter_ipsecpt_110 Verify IPSEC pass through with multiple LAN clients using same VPN server


    step 1. Start new DHCP client on the LAN interface
    step 2. Forward an IPSEC packet from host 1 to VPN server on WAN
    step 3. Forward an IPSEC packet from host 2 to VPN server on WAN
    step 4. Verify both packets are received by the VPN server
    step 5. Send a return IPSEC packet to each LAN host using unique SPI
    step 6. Verify each LAN host receives IPSEC packet with correct SPI

    Note: Each LAN client sends a IPSEC packet to the same VPN server
          using unique SPI values in the ESP header. IPSEC packets
          sent back from the WAN use the SPI value.

    Note: This test is only supported by routers using SPI tracking
          features to build NAPT mappings for return IPSEC/ESP traffic.
          There is no reliable technique for a router to know the return
          SPI value. However, some routers attempt to serialize the
          return connections and associate incoming SPIs with outgoing
          connections. While this does not work if packets are
          reordered or lost, some routers do use this technique to allow
          multiple LAN clients to use the same VPN server.

    Note: The testvar alwaysUseIke can be used to initiate an IKE connection
    prior to sending tunnel mode IPSEC packets.


Test Module Name Synopsis
Verify IKE with multiple LAN clients using same VPN server ipsecpt.tcl cdrouter_ipsecpt_120 Verify IKE with multiple LAN clients using same VPN server


    step 1. Start new DHCP client on the LAN interface
    step 2. Forward an IPSEC IKE packet from host1 to VPN server on WAN
    step 3. Forward an IPSEC IKE packet from host2 to VPN server on WAN
    step 4. Verify both packets are received by the VPN server
    step 5. Send return IKE/ISAKMP packets to LAN clients
    step 6. Verify each LAN client receives correct IKE packet

    Note: Each LAN client uses a unique ISAKMP cookie for the initiator and
    responder cookies. There are two common techniques used to multiplex
    multiple IKE connections all originating from port 500. Some routers will
    change the IKE source port to another UDP port. This solution does not work
    for all VPN servers which may not accept IKE traffic if the UDP source port
    is not 500. Other routers will track the initiator and responder cookies in
    the ISAKMP messages in order to demultiplex incoming IKE packets. This test
    will succeed if either technique is used.


Test Module Name Synopsis
IPSEC pass through without NAT-T based IPSEC client ipsecpt.tcl cdrouter_ipsecpt_200 IPSEC pass through without NAT-T based IPSEC client


    step 1. Create new IPSEC VPN server on the WAN
    step 2. Start the CDRouter IKE client on the LAN without using NAT-T
    step 3. Verify IPSEC pass through allows IKE session to establish
    step 4. Verify data traffic over the IPSEC tunnel


Test Module Name Synopsis
IPSEC pass through with NAT-T based IPSEC client ipsecpt.tcl cdrouter_ipsecpt_210 IPSEC pass through with NAT-T based IPSEC client


    step 1. Create new IPSEC VPN server on the WAN
    step 2. Start the CDRouter IKE client on the LAN using NAT-T
    step 3. Verify IPSEC pass through allows IKE session to establish
    step 4. Verify data traffic over the IPSEC tunnel



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

Test Module Name Synopsis
Verify packet is not forwarded when IPv4 TTL is 1 forward.tcl cdrouter_forward_2 Verify packet is not forwarded when IPv4 TTL is 1

    step 1. Set the IP TTL of outbound packets to 1
    step 2. Forward an IP packet from a LAN client to the WAN
    step 3. Verify the packet is not forwarded

Test Module Name Synopsis
Verify packet can be forwarded back through incoming LAN interface forward.tcl cdrouter_forward_3 Verify packet can be forwarded back through incoming LAN interface

    step 1. Forward an IP packet from a LAN client to another LAN client
    step 2. Forward packet using router's MAC address
    step 3. Verify packet is forwarded back out the LAN interface

    NOTE: The router may send an ICMP Redirect back to the originator.

Test Module Name Synopsis
Verify packet is not forwarded if IPv4 checksum is corrupt forward.tcl cdrouter_forward_4 Verify packet is not forwarded if IPv4 checksum is corrupt

    step 1. Configure the LAN host to send corrupt IPv4 checksums
    step 2. Forward an IP packet from a LAN client to the WAN
    step 3. Verify the packet is not forwarded
    step 4. If the packet is forwarded, see if the checksum is valid


    References:

    IETF RFC 1812 "Requirements for IP Version 4 Routers" Section 4.2.2.5: Header Checksum: RFC 791 Section 3.1

    As stated in Section [5.2.2], a router MUST verify the IP checksum of any
    packet that is received, and MUST discard messages containing invalid
    checksums. The router MUST NOT provide a means to disable this checksum
    verification.

    https://tools.ietf.org/html/rfc1812#section-4.2.2.5

Test Module Name Synopsis
Forward UDP packets with various packet lengths (LAN to WAN) forward.tcl cdrouter_forward_10 Forward UDP packets with various packet lengths (LAN to WAN)

    step 1. Initiate an outbound UDP connection with UDP data length of 4
    step 2. Verify packets are received on the WAN interface
    step 3. If wanMode is PPPoE,
               continue forwarding until UDP data length is 1464 (1492 max IP len)
            else if wanMode is PPTP or L2TP
               continue forwarding until UDP data length is 1432 (1460 max IP len)
            else for DHCP and static wanModes
               continue forwarding until UDP data length is 1472 (1500 max IP len)

    NOTE: Some routers will stop forwarding IP traffic while they renew their
    WAN side IP address. This can cause this test to fail.

    NOTE: Some routers allow static configuration of the MTU size. This may
    default to 1492 even for routers running DHCP on the WAN side.

    NOTE: This test will stop if the number of max failures is reached. This
    value may be configured using testvar forwardingMaxFailures. Setting this
    value to 0 will test each packet size regardles of the result.

    testvar forwardingMaxFailures 20

Test Module Name Synopsis
Forward UDP packets with various packet lengths (WAN to LAN) forward.tcl cdrouter_forward_11 Forward UDP packets with various packet lengths (WAN to LAN)

    step 1. Initiate an outbound UDP connection with UDP data length of 4
    step 2. Verify packet is received on the WAN interface
    step 3. Forward a return packet from the WAN to the LAN
    step 4. Verify packets are received on the LAN interface
    step 5. If wanMode is PPPoE,
               continue forwarding until UDP data length is 1464 (1492 max IP len)
            else if wanMode is PPTP
               continue forwarding until UDP data length is 1432 (1460 max IP len)
            else for DHCP and static wanModes
               continue forwarding until UDP data length is 1472 (1500 max IP len)

    NOTE: Some routers will stop forwarding IP traffic while they renew their
    WAN side IP address. This can cause this test to fail.

    NOTE: Some routers allow static configuration of the MTU size. This may
    default to 1492 even for routers running DHCP on the WAN side.

    NOTE: This test will stop if the number of max failures is reached. This
    value may be configured using testvar forwardingMaxFailures. Setting this
    value to 0 will test each packet size regardles of the result.

    testvar forwardingMaxFailures 20

Test Module Name Synopsis
No packets are forwarded if WAN lease expires forward.tcl cdrouter_forward_20 No packets are forwarded if WAN lease expires

    step 1. Disable the DHCP server and any ICMP or ARP responses
    step 2. Wait for the WAN lease to expire
    step 3. Forward packets from LAN client to WAN destination
    step 4. Verify the packets are not forwarded out the WAN interface
    step 5. Enable DHCP, ICMP, and ARP

    NOTE: ARP/ICMP responses are also disabled on the WAN interface for this
    test. Some routers use ARP or ICMP to verify that the WAN is still
    operational.


jumbo.tcl

Jumbo MTU forwarding tests with different packet sizes and directions

Test Module Name Synopsis
Verify IPv4 TTL is decremented for forwarded jumbo MTU packets jumbo.tcl cdrouter_jumbo_1 Verify IPv4 TTL is decremented for forwarded jumbo MTU packets

    step 1. Forward an IP packet from a LAN client to the WAN that utilizes the
            maximum supported jumbo mtu of both interfaces
    step 2. Verify the TTL of the packet is decremented by 1

    NOTE: The maximum jumbo packet size is configured using the testvar
    jumboMtu.

Test Module Name Synopsis
Verify jumbo MTU packet is not forwarded when IPv4 TTL is 1 jumbo.tcl cdrouter_jumbo_2 Verify jumbo MTU packet is not forwarded when IPv4 TTL is 1

    step 1. Set the IP TTL of outbound packets to 1
    step 2. Forward an IP packet from a LAN client to the WAN that utilizes the
            maximum supported jumbo mtu of both interfaces
    step 3. Verify the packet is not forwarded

    NOTE: The maximum jumbo packet size is configured using the testvar
    jumboMtu.

Test Module Name Synopsis
Verify jumbo MTU packet can be forwarded back through incoming LAN interface jumbo.tcl cdrouter_jumbo_3 Verify jumbo MTU packet can be forwarded back through incoming LAN interface

    step 1. Forward an IP packet from a LAN client to another LAN client that
            utilizes the maximum supported jumbo mtu of both interfaces
    step 2. Forward packet using router's MAC address
    step 3. Verify packet is forwarded back out the LAN interface

    NOTE: The router may send an ICMP Redirect back to the originator.

    NOTE: The maximum jumbo packet size is configured using the testvar
    jumboMtu.

Test Module Name Synopsis
Verify jumbo MTU packet is not forwarded if IPv4 checksum is corrupt jumbo.tcl cdrouter_jumbo_4 Verify jumbo MTU packet is not forwarded if IPv4 checksum is corrupt

    step 1. Configure the LAN host to send corrupt IPv4 checksums
    step 2. Forward an IP packet from a LAN client to the WAN that utilizes the
            maximum supported jumbo mtu of both interfaces
    step 3. Verify the packet is not forwarded
    step 4. If the packet is forwarded, see if the checksum is valid

    NOTE: The maximum jumbo packet size is configured using the testvar
    jumboMtu.


    References:

    IETF RFC 1812 "Requirements for IP Version 4 Routers" Section 4.2.2.5: Header Checksum: RFC 791 Section 3.1

    As stated in Section [5.2.2], a router MUST verify the IP checksum of any
    packet that is received, and MUST discard messages containing invalid
    checksums. The router MUST NOT provide a means to disable this checksum
    verification.

    https://tools.ietf.org/html/rfc1812#section-4.2.2.5

Test Module Name Synopsis
Forward jumbo MTU UDP packets with various packet lengths (LAN to WAN) jumbo.tcl cdrouter_jumbo_10 Forward jumbo MTU UDP packets with various packet lengths (LAN to WAN)

    step 1. Initiate an outbound UDP connection with UDP packet that utilizes
            the maximum supported standard mtu of both interfaces
    step 2. Verify packets are received on the WAN interface
    step 3. Continue forwarding until the UDP packet utilizes the maximum
            supported jumbo mtu of both interfaces

    NOTE: Some routers will stop forwarding IP traffic while they renew their
    WAN side IP address. This can cause this test to fail.

    NOTE: The maximum jumbo packet size is configured using the testvar
    jumboMtu.

    NOTE: This test will stop if the number of max failures is reached. This
    value may be configured using testvar forwardingMaxFailures. Setting this
    value to 0 will test each packet size regardles of the result.

    testvar forwardingMaxFailures 20

Test Module Name Synopsis
Forward jumbo MTU UDP packets with various packet lengths (WAN to LAN) jumbo.tcl cdrouter_jumbo_11 Forward jumbo MTU UDP packets with various packet lengths (WAN to LAN)

    step 1. Initiate an outbound UDP connection with UDP packet that utilizes
            the maximum supported standard mtu of both interfaces
    step 2. Verify packet is received on the WAN interface
    step 3. Forward a return packet from the WAN to the LAN that utilizes the
            maximum supported standard mtu of both interfaces
    step 4. Verify packets are received on the LAN interface
    step 5. Continue forwarding until the UDP packet utilizes the maximum
            supported jumbo mtu of both interfaces

    NOTE: Some routers will stop forwarding IP traffic while they renew
    their WAN side IP address. This can cause this test to fail.

    NOTE: The maximum jumbo packet size is configured using the testvar
    jumboMtu.

    NOTE: This test will stop if the number of max failures is reached. This
    value may be configured using testvar forwardingMaxFailures. Setting this
    value to 0 will test each packet size regardles of the result.

    testvar forwardingMaxFailures 20


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

Test Module Name Synopsis
Verify router learns new RIP routes from LAN side RIP router (v1 or v2) rip.tcl cdrouter_rip_2 Verify router learns new RIP routes from LAN side RIP router (v1 or v2)


    step 1. Start new DHCP client on LAN interface
    step 2. Announce new RIPv1/v2 route with metric 1 from new DHCP client
    step 3. Forward from original LAN client to IP address within the
            new RIPv1/v2 route range
    step 4. Verify the packet is forwarded to the new DHCP client


    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

Test Module Name Synopsis
Verify router responds to RIP requests on LAN interface rip.tcl cdrouter_rip_5 Verify router responds to RIP requests on LAN interface


    step 1. Send RIP Request from new UDP src port to RIP destination address
    step 2. Verify router returns a RIP response
    step 3. Verify the response is sent to the correct UDP port
    step 4. Verify the response is sent using unicast IP destination

    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

Test Module Name Synopsis
Verify router selects RIP route with lowest metric (v1 or v2) rip.tcl cdrouter_rip_10 Verify router selects RIP route with lowest metric (v1 or v2)


    step 1. Start 2 new DHCP clienst on LAN interface (R1 and R2)
    step 2. Announce new RIPv1/v2 route with metric 10 from R1
    step 3. Announce same RIPv1/v2 route with metric 9 from R2

    step 5. Forward from original LAN client to IP address within the
            new RIPv1/v2 route range
    step 6. Verify the packet is forwarded to R2


    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

Test Module Name Synopsis
Verify router ignores routes with a metric of 16 rip.tcl cdrouter_rip_12 Verify router ignores routes with a metric of 16


    step 1. Start new DHCP client on LAN interface
    step 2. Announce new RIPv1/v2 route with metric 16 from new DHCP client
    step 3. Forward from original LAN client to IP address within the
            new RIPv1/v2 route range
    step 4. Verify the packet is not forwarded to the new DHCP client
    step 5. Verify the packet is forwarded to WAN side


    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

Test Module Name Synopsis
Verify router uses split horizon or poison reverse for learned RIP routes rip.tcl cdrouter_rip_20 Verify router uses split horizon or poison reverse for learned RIP routes


    step 1. Start new DHCP client on LAN interface
    step 2. Announce new RIPv1/v2 route with metric 1 from new DHCP client
    step 3. Wait for new RIP update
    step 4. Verify route is not announced (split horizon) or announced as
            unreachable (poison reverse)


    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

Test Module Name Synopsis
Verify router announces default route on LAN side rip.tcl cdrouter_rip_30 Verify router announces default route on LAN side


    step 1. Listen for RIP updates for 1 minute
    step 2. Verify default route (0.0.0.0) is announced as reachable


    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

Test Module Name Synopsis
Verify the maximum number of RIP routes supported rip.tcl cdrouter_rip_100 Verify the maximum number of RIP routes supported


    step 1. Start a new DHCP client on LAN interface
    step 2. Announce new RIPv1/v2 routes with metric 1 from new DHCP client

            NOTE: The 'ripMaxRoutes' variable in your configuration file
            determines the number of RIPv1/v2 routes that are announced.

    step 3. Forward from original LAN client to IP address within the
            each new route range
    step 4. Verify packets are forwarded for each new route


    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

Test Module Name Synopsis
Verify router learns new RIP routes from WAN side RIP router (v1 or v2) rip.tcl cdrouter_rip_200 Verify router learns new RIP routes from WAN side RIP router (v1 or v2)


    step 1. Announce new RIPv1/v2 route with metric 1 from WAN side
    step 2. Wait for new RIP update on the LAN
    step 3. Verify new route is announced on the LAN
    step 4. Forward packet from LAN to new IP destination
    step 5. Verify packet is forwarded to WAN side

    NOTE: This test is only enabled when testvar ripAcceptWanUpdate
          is set to yes. The default is no.

          testvar ripAcceptWanUpdate yes

    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

Test Module Name Synopsis
Verify all DHCP clients with multiple TCP connections scaling.tcl cdrouter_scale_2 Verify all DHCP clients with multiple TCP connections


    step 1. Determine the size of the IPv4 LAN address pool
    step 2. Determine the maximum number of TCP connections to create for
            each DHCP client
    step 3. Create a DHCP client for each available IP address
    step 4. Verify each client obtains an IP address within the range
    step 5. Verify there are no address conflicts
    step 6. Verify each client can establish scaleTcpConnsPerHost outbound
            HTTP connections to port 80; each connection is to a unique IP
            address unless the free network range has been exceeded
    step 7. Verify each client can send/receive data over each connection
    step 8. Close each TCP connection
    step 9. 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: The maximum number of TCP connections per host is set in your
    configuration file using the testvar 'scaleTcpConnsPerHost'. If this entry
    is not included in your configuration file, it defaults to 5.

    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

Test Module Name Synopsis
Verify all DHCP clients with single UDP connection scaling.tcl cdrouter_scale_3 Verify all DHCP clients with single UDP connection


    step 1. Determine the size of the IPv4 LAN address pool
    step 2. Determine the maximum number of UDP connections to create for
            each DHCP client
    step 3. Create a DHCP client for each available IP address within the pool
    step 4. Verify each client obtains an IP address within the range
    step 5. Verify there are no address conflicts
    step 6. Verify each client can establish one outbound UDP connection
    step 7. Verify each client can send/receive data over each 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

Test Module Name Synopsis
Verify no duplicate IP addresses are assigned when DHCP address pool is exhausted scaling.tcl cdrouter_scale_10 Verify no duplicate IP addresses are assigned when DHCP address pool is exhausted


    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. Attempt to create one additional DHCP client
    step 6. Verify that the DHCP client in step 5 does not obtain an IP address
    step 7. Release all DHCP client leases

    NOTE: The DHCP address pool size is set in your configuration file using
    the 'dhcpClientStart' and 'dhcpClientEnd' testvars. 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

Test Module Name Synopsis
Verify all DHCP clients can create an IPSEC tunnel scaling.tcl cdrouter_scale_15 Verify all DHCP clients can create an IPSEC tunnel


    step 1. Determine the number of IPSEC tunnels to create based on the value
            of the ipsecMaxTunnels testvar
    step 2. Create one DHCP client per IPSEC tunnel
    step 3. Verify the client obtains an IP address within the range
    step 4. Verify there are no address conflicts
    step53. Verify each client can establish an outbound IPSEC tunnel to a
            unique IP destination address on the WAN side
    step 6. Verify IKE session is established
    step 7. Verify IPSEC/ESP packets pass through
    step 8. Release all new DHCP client leases

    NOTE: This test is only supported by routers using SPI tracking
    features to build NAPT mappings for return IPSEC/ESP traffic.
    There is no reliable technique for a router to know the return
    SPI value. However, some routers attempt to serialize the
    return connections and associate incoming SPIs with outgoing
    connections. While this does not work if packets are
    reordered or lost, some routers do use this technique to allow
    multiple LAN clients to use the same VPN server.

    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.

    NOTE: If the maximum number of IPSEC tunnels supported is less than
    the DHCP address pool size, not all DHCP clients will be used. The
    maximum number of IPSEC tunnels is configured using the
    'ipsecMaxTunnels' testvar.

    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

Test Module Name Synopsis
Verify all DHCP clients can create a PPTP tunnel scaling.tcl cdrouter_scale_20 Verify all DHCP clients can create a PPTP tunnel


    step 1. Determine the number of PPTP tunnels to create based on the value
            of the pptpMaxTunnels testvar
    step 2. Create one DHCP client per PPTP tunnel
    step 3. Verify the 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 PPTP tunnel
            to a unique IP destination address on the WAN side
    step 6. 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.

    NOTE: If the maximum number of PPTP tunnels supported is less than
    the DHCP address pool size, not all DHCP clients will be used. The
    maximum number of PPTP tunnels is configured using the
    pptpMaxTunnels variable.

    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

Test Module Name Synopsis
Verify all DHCP clients can create a L2TP/IPSEC tunnel scaling.tcl cdrouter_scale_30 Verify all DHCP clients can create a L2TP/IPSEC tunnel


    step 1. Determine the number of L2TP tunnels to create based on the value
            of the l2tpMaxTunnels testvar
    step 2. Create one DHCP client per L2TP tunnel
    step 3. Verify the 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 L2TP/IPSEC tunnel
            to a unique IP destination address on the WAN side
    step 6. 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.

    NOTE: If the maximum number of L2TP tunnels supported is less than
    the DHCP address pool size, not all DHCP clients will be used. The
    maximum number of L2TP tunnels is configured using the
    l2tpMaxTunnels variable.

    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

Test Module Name Synopsis
Verify all DHCP clients can create a L2TP/IPSEC tunnel with NAT-T scaling.tcl cdrouter_scale_40 Verify all DHCP clients can create a L2TP/IPSEC tunnel with NAT-T


    step 1. Determine the number of L2TP tunnels to create based on the value
            of the l2tpMaxTunnels testvar
    step 2. Create one DHCP client per L2TP tunnel
    step 3. Verify the 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 L2TP/IPSEC tunnel
            to a unique IP destination address on the WAN side using NAT-T
    step 6. 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.

    NOTE: If the maximum number of L2TP tunnels supported is less than
    the DHCP address pool size, not all DHCP clients will be used. The
    maximum number of L2TP tunnels is configured using the
    l2tpMaxTunnels variable.

    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


vservice.tcl

Port forwarding tests to verify configured virtual services on the router

Test Module Name Synopsis
Verify each configured TCP virtual service vservice.tcl cdrouter_vservice_10 Verify each configured TCP virtual service


    step 1. Read all the configured virtual services for TCP
    step 2. For each service, initiate a TCP connection from the WAN
            to the router's WAN side IP address and specified TCP port
    step 3. Verify the TCP session is established
    step 4. Verify the TCP session is forwarded to the correct LAN host
    step 5. Close the TCP session
    step 6. Repeat for each TCP service

    NOTE: Up to 4096 virtual services can be configured in your configuration
    file using the virtualTcpService* entries. For example,

    testvar virtualTcpServicePort1        23
    testvar virtualTcpServiceHost1        192.168.1.200
    testvar virtualTcpServiceName1        telnet
    testvar virtualTcpServiceLanPort1     23

    testvar virtualTcpServicePort2        25
    testvar virtualTcpServiceHost2        192.168.1.201
    testvar virtualTcpServiceName2        smtp
    testvar virtualTcpServiceLanPort2     25

    The IP address on the LAN side for each virtual serivce must be on the
    same network as the "lanIp" address. You may also configure a different
    LAN port using the *LanPort* entries. By default, the LAN port for the
    service is the same as the WAN and does not need to be configured.

    NOTE: The expected IP source address of packets forwarded using the
    virtual service can be configured using the testvar 'virtualWANTransType'.
    This value can be set to "none", "public" or "private". When set to "none"
    (default), no IP address translation should be done on the IP source
    address of a packet incoming from the WAN to a configured virtual service.
    When set to "public", the router should use the WAN side IP address as the
    source address for all packets originating on the WAN that are forwarded
    to a virtual services port. When set to "private", the router should use
    the LAN side IP address as the source address for all packets originating
    on the WAN that are forwarded to a virtual service port.

Test Module Name Synopsis
Verify each configured UDP virtual service vservice.tcl cdrouter_vservice_20 Verify each configured UDP virtual service


    step 1. Read all the configured virtual services for UDP
    step 2. For each service, send a UDP packet from the WAN
            to the router's WAN side IP address and specified UDP port
    step 3. Verify the UDP packet is forwarded to the correct LAN host
    step 4. Send a return UDP packet from the LAN host to the WAN originator
    step 5. Verify the UDP packet is forwarded back to the WAN
    step 6. Repeat for each UDP service

    NOTE: Up to 4096 virtual services can be configured in your configuration
    file using the virtualUdpService* entries. For example,

    testvar virtualUdpServicePort1        23
    testvar virtualUdpServiceHost1        192.168.1.200
    testvar virtualUdpServiceName1        telnet

    testvar virtualUdpServicePort2        25
    testvar virtualUdpServiceHost2        192.168.1.201
    testvar virtualUdpServiceName2        smtp

    The IP address on the LAN side for each virtual serivce must be on the
    same network as the "lanIp" address.

Test Module Name Synopsis
Verify TCP virtual services are reachable from the LAN side vservice.tcl cdrouter_vservice_30 Verify TCP virtual services are reachable from the LAN side


    step 1. Read all the configured virtual services for TCP
    step 2. For each service, initiate a TCP connection from the LAN
            to the router's WAN side IP address and specified TCP port
    step 3. Verify the TCP session is established
    step 4. Verify the TCP session is forwarded to the correct LAN host
    step 5. Close the TCP session
    step 6. Repeat for each TCP service

    NOTE: Up to 4096 virtual services can be configured in your configuration
    file using the virtualTcpService* entries. For example,

    testvar virtualTcpServicePort1        23
    testvar virtualTcpServiceHost1        192.168.1.200
    testvar virtualTcpServiceName1        telnet

    testvar virtualTcpServicePort2        25
    testvar virtualTcpServiceHost2        192.168.1.201
    testvar virtualTcpServiceName2        smtp

    The IP address on the LAN side for each virtual serivce must be on the
    same network as the "lanIp" address.

    NOTE: The expected IP source address of packets forwarded using the
    virtual service can be configured using the testvar 'virtualLANTransType'.
    This value can be set to "public" or "private". When set to "public",
    the router should use the WAN side IP address as the source address for
    all packets originating on the LAN that are forwarded to a virtual services
    port. When set to "private", the router should use the LAN side IP address
    as the source address for all packets originating on the LAN that are
    forwarded to a virtual service port.


Test Module Name Synopsis
Verify UDP virtual services are reachable from the LAN side vservice.tcl cdrouter_vservice_40 Verify UDP virtual services are reachable from the LAN side


    step 1. Read all the configured virtual services for UDP
    step 2. For each service, send a UDP packet from the LAN
            to the router's WAN side IP address and specified UDP port
    step 3. Verify the UDP packet is forwarded to the correct LAN host
    step 4. Send a return UDP packet from the LAN host to the LAN originator
    step 5. Verify the UDP packet is forwarded back to the LAN
    step 6. Repeat for each UDP service

    NOTE: Up to 4096 virtual services can be configured in your configuration
    file using the virtualUdpService* entries. For example,

    testvar virtualUdpServicePort1        23
    testvar virtualUdpServiceHost1        192.168.1.200
    testvar virtualUdpServiceName1        telnet

    testvar virtualUdpServicePort2        25
    testvar virtualUdpServiceHost2        192.168.1.201
    testvar virtualUdpServiceName2        smtp

    The IP address on the LAN side for each virtual serivce must be on the
    same network as the "lanIp" address.

    NOTE: The expected IP source address of packets forwarded using the
    virtual service can be configured using the testvar 'virtualLANTransType'.
    This value can be set to "public" or "private". When set to "public",
    the router should use the WAN side IP address as the source address for
    all packets originating on the LAN that are forwarded to a virtual services
    port. When set to "private", the router should use the LAN side IP address
    as the source address for all packets originating on the LAN that are
    forwarded to a virtual service port.



url-filter.tcl

URL filtering tests for LAN side HTTP clients

Test Module Name Synopsis
Verify HTTP GETs to filtered URLs are blocked url-filter.tcl cdrouter_urlfilter_10 Verify HTTP GETs to filtered URLs are blocked


    step 1. Set up new web server on WAN side using free network address
    step 2. Resolve domain address using DNS from LAN client
    step 3. Initiate TCP connection to web server from LAN client
    step 4. Verify TCP connection is opened
    step 5. Send HTTP GET from LAN client to new server for requested URL
    step 6. URL is considered blocked if one of the following occurs:
              a. The LAN client does not receive a page from the webserver
              b. The LAN client receives a page from the webserver, but
                 the HTTP status code is not 200 "OK"
              c. The LAN client receives a page from the webserver with
                 an HTTP status code of 200, but the returned page contains
                 text indicating that the page was administratively blocked,
                 as defined by the testvar 'urlFilterBlockedText'
    step 7. Repeat for each configured filtered URL
    step 8. Verify that each configured non-filtered URL returns a valid
            webpage

    NOTE: This test is only performed if the testvar 'urlFilterSupported'
    is set to "yes". The testvars 'filtered-urls' and 'non-filtered-urls'
    are used to specify which URLs are used during this test.

    NOTE: This test allows the CPE to block a URL by preventing establishment
    of the TCP connection in step 4, using a proxy to return a non-200 HTTP
    status code in step 6, or using a proxy to return a 200 HTTP status code
    in step 6 with alternate webpage text indicating that the page was
    admninistratively blocked. The testvar 'urlFilterBlockedText' should be
    configured with a portion of the expected text returned when a page is
    blocked by the CPE.

Test Module Name Synopsis
Verify HTTP GETs to filtered URLs are blocked without DNS lookups url-filter.tcl cdrouter_urlfilter_12 Verify HTTP GETs to filtered URLs are blocked without DNS lookups


    step 1. Set up new web server on WAN side using free network address
    step 2. Resolve only domain addresses for non-filtered URLs from LAN client
    step 3. Initiate TCP connection to web server from LAN client
    step 4. Verify TCP connection is opened
    step 5. Send HTTP GET from LAN client to new server for requested URL
    step 6. URL is considered blocked if one of the following occurs:
              a. The LAN client does not receive a page from the webserver
              b. The LAN client receives a page from the webserver, but
                 the HTTP status code is not 200 "OK"
              c. The LAN client receives a page from the webserver with
                 an HTTP status code of 200, but the returned page contains
                 text indicating that the page was administratively blocked,
                 as defined by the testvar 'urlFilterBlockedText'
    step 7. Repeat for each configured filtered URL
    step 8. Verify that each configured non-filtered URL returns a valid
            webpage

    NOTE: This test is only performed if the testvar 'urlFilterSupported'
    is set to "yes". The testvars 'filtered-urls' and 'non-filtered-urls'
    are used to specify which URLs are used during this test.

    NOTE: This test allows the CPE to block a URL by preventing establishment
    of the TCP connection in step 4, using a proxy to return a non-200 HTTP
    status code in step 6, or using a proxy to return a 200 HTTP status code
    in step 6 with alternate webpage text indicating that the page was
    admninistratively blocked. The testvar 'urlFilterBlockedText' should be
    configured with a portion of the expected text returned when a page is
    blocked by the CPE.

Test Module Name Synopsis
Verify HTTP HEADs to filtered URLs are blocked url-filter.tcl cdrouter_urlfilter_15 Verify HTTP HEADs to filtered URLs are blocked


    step 1. Set up new web server on WAN side using free network address
    step 2. Resolve domain address using DNS from LAN client
    step 3. Initiate TCP connection to web server from LAN client
    step 4. Verify TCP connection is opened
    step 5. Send HTTP HEAD from LAN client to new server for requested URL
    step 6. URL is considered blocked if one of the following occurs:
              a. The LAN client does not receive a page from the webserver
              b. The LAN client receives a page from the webserver, but
                 the HTTP status code is not 200 "OK"
              c. The LAN client receives a page from the webserver with
                 an HTTP status code of 200, but the returned page contains
                 text indicating that the page was administratively blocked,
                 as defined by the testvar 'urlFilterBlockedText'
    step 7. Repeat for each configured filtered URL
    step 8. Verify that each configured non-filtered URL returns a valid
            webpage

    NOTE: This test is only performed if the testvar 'urlFilterSupported'
    is set to "yes". The testvars 'filtered-urls' and 'non-filtered-urls'
    are used to specify which URLs are used during this test.

    NOTE: This test allows the CPE to block a URL by preventing establishment
    of the TCP connection in step 4, using a proxy to return a non-200 HTTP
    status code in step 6, or using a proxy to return a 200 HTTP status code
    in step 6 with alternate webpage text indicating that the page was
    admninistratively blocked. The testvar 'urlFilterBlockedText' should be
    configured with a portion of the expected text returned when a page is
    blocked by the CPE.

Test Module Name Synopsis
Verify HTTP POSTs to filtered URLs are blocked url-filter.tcl cdrouter_urlfilter_20 Verify HTTP POSTs to filtered URLs are blocked


    step 1. Set up new web server on WAN side using free network address
    step 2. Resolve domain address using DNS from LAN client
    step 3. Initiate TCP connection to web server from LAN client
    step 4. Verify TCP connection is opened
    step 5. Send HTTP POST from LAN client to new server for requested URL
    step 6. URL is considered blocked if one of the following occurs:
              a. The LAN client does not receive a page from the webserver
              b. The LAN client receives a page from the webserver, but
                 the HTTP status code is not 200 "OK"
              c. The LAN client receives a page from the webserver with
                 an HTTP status code of 200, but the returned page contains
                 text indicating that the page was administratively blocked,
                 as defined by the testvar 'urlFilterBlockedText'
    step 7. Repeat for each configured filtered URL
    step 8. Verify that each configured non-filtered URL returns a valid
            webpage

    NOTE: This test is only performed if the testvar 'urlFilterSupported'
    is set to "yes". The testvars 'filtered-urls' and 'non-filtered-urls'
    are used to specify which URLs are used during this test.

    NOTE: This test allows the CPE to block a URL by preventing establishment
    of the TCP connection in step 4, using a proxy to return a non-200 HTTP
    status code in step 6, or using a proxy to return a 200 HTTP status code
    in step 6 with alternate webpage text indicating that the page was
    admninistratively blocked. The testvar 'urlFilterBlockedText' should be
    configured with a portion of the expected text returned when a page is
    blocked by the CPE.

Test Module Name Synopsis
Verify URL filtering does not look at Cookie data url-filter.tcl cdrouter_urlfilter_30 Verify URL filtering does not look at Cookie data


    step 1. Set up new web server on WAN side using free network address
    step 2. Resolve domain address using DNS from LAN client
    step 3. Initiate TCP connection to web server from LAN client
    step 4. Verify TCP connection is opened
    step 5. Send HTTP GET from LAN client to new server for requested URL
    step 6. Use one of the filtered URLs as the cookie data
    step 7. Verify webserver does return a response
    step 8. Repeat for each configured allowed URL

    NOTE: This test is only performed if the testvar 'urlFilterSupported'
    is set to "yes". The testvars 'filtered-urls' and 'non-filtered-urls'
    are used to specify which URLs are used during this test.

Test Module Name Synopsis
Verify HTTPS GETs to filtered URLs are blocked url-filter.tcl cdrouter_urlfilter_40 Verify HTTPS GETs to filtered URLs are blocked


    step 1.  Set up new HTTPS server on WAN side using free network address
    step 2.  Resolve domain address using DNS from LAN client
    step 3.  Initiate TCP connection to web server from LAN client
    step 4.  If TCP connection is not established, skip to step 9
    step 5.  Verify TCP connection is opened
    step 6.  Establish SSL connection to server
    step 7.  Send HTTPS GET from LAN client to new server for requested URL
    step 8.  URL is considered blocked if one of the following occurs:
              a. The LAN client does not receive a page from the webserver
              b. The LAN client receives a page from the webserver, but
                 the HTTP status code is not 200 "OK"
              c. The LAN client receives a page from the webserver with
                 an HTTP status code of 200, but the returned page contains
                 text indicating that the page was administratively blocked,
                 as defined by the testvar 'urlFilterBlockedText'
    step 9.  Repeat for each configured filtered URL
    step 10. Verify that each configured non-filtered URL returns a valid
             webpage

    NOTE: This test is only performed if the testvar 'urlFilterSupported'
    is set to "yes". The testvars 'filtered-urls' and 'non-filtered-urls'
    are used to specify which URLs are used during this test.

    NOTE: This test allows the CPE to block a URL by preventing establishment
    of the TCP connection in step 4, using a proxy to return a non-200 HTTP
    status code in step 8, or using a proxy to return a 200 HTTP status code
    in step 8 with alternate webpage text indicating that the page was
    admninistratively blocked. The testvar 'urlFilterBlockedText' should be
    configured with a portion of the expected text returned when a page is
    blocked by the CPE.


triggerp.tcl

Tests to verify configured trigger ports on the router

Test Module Name Synopsis
Verify basic case for each configured trigger port application triggerp.tcl cdrouter_tport_10 Verify basic case for each configured trigger port application


    step 1. Read all the configured trigger ports
    step 2. For each port, verify that none of the public triggered ports
            are currently open on the WAN side.
    step 3. Initiate a TCP or UDP session from the LAN to the WAN side
            using the triggered port as the destination port.
    step 4. Verify the TCP or UDP session is created
    step 5. For each public port that should now be triggered, open
            a connection from the WAN to the LAN using the public
            port as the destination port and the router's nat IP address
            as the destination IP address
    step 5. Verify a connection can be estabished for each public port
    step 6. Close down each public port
    step 7. Close down the original LAN side connection used for the trigger
    step 8. Repeat for each configured port trigger

    NOTE: Up to 4096 trigger ports can be configured in your configuration
    file. For example,

    testvar triggerName1                  net2phone-1
    testvar triggerPort1                  6801
    testvar triggerType1                  udp
    testvar triggerPublic1                30000
    testvar triggerPublicType1            both

    testvar triggerName2                  app1
    testvar triggerPort2                  20000
    testvar triggerType2                  udp
    testvar triggerPublic2                20001-20010
    testvar triggerPublicType2            udp

    NOTE: Many routers will not time out the triggered port connection once
    it is open. This will cause this test to fail if it is executed more
    than once.

    The PublicType may be either "tcp", "udp", or "both". If "both" is used,
    the test case will verify both a TCP and UDP connection for each port
    in the Public range.

    A delay can be configured between each trigger port. This is sometimes
    required for port trigger implementations using Smart ALGs. To configure
    the delay, configure the testvar 'portTriggerDelay' with the number of
    milliseconds.

    A delay can also be configured before a trigger port is verified as being
    open with WAN to LAN traffic. This is sometimes required for
    implemenatations that have a delay associated with processing the outbound
    trigger packet. To configure the delay, configure the testvar
    'portTriggerOpenDelay' with the number of milliseconds.

    Examples:

    testvar portTriggerDelay 5000
    testvar portTriggerOpenDelay 1000


Test Module Name Synopsis
Verify multiple LAN hosts can use trigger ports after mappings are aged out triggerp.tcl cdrouter_tport_30 Verify multiple LAN hosts can use trigger ports after mappings are aged out


    step 1. Read all the configured trigger ports
    step 2. Create a second DHCP LAN client
    step 3. Initiate a TCP or UDP session from the LAN to the WAN side
            using the triggered port as the destination port
    step 4. Verify the TCP or UDP session is created
    step 5. For each public port that should now be triggered, open
            a connection from the WAN to the LAN using the public
            port as the destination port and the router's nat IP address
            as the destination IP address.
    step 6. Verify a connection can be estabished for each public port
    step 7. Close down each public port
    step 8. Close down the original LAN side connection used for the trigger
    step 9. Wait for port mappings to be aged out
    step 10. Repeat from step 2. using the second LAN client
    step 11. Repeat for each configured port trigger

    NOTE: The port mapping aging time for trigger ports is configured
    using the portTriggerTimeout variable in your config file. Your
    router must support the aging of trigger ports in order to run this
    test.

    NOTE: Up to 4096 trigger ports can be configured in your configuration
    file. For example,

    testvar triggerName1                  net2phone-1
    testvar triggerPort1                  6801
    testvar triggerType1                  udp
    testvar triggerPublic1                30000
    testvar triggerPublicType1            both

    NOTE: Many routers will not time out the triggered port connection once
    it is open. This will cause this test to fail if it is executed more
    than once.

    The PublicType may be either tcp, udp, or both. If "both" is used,
    the test case will verify both a TCP and UDP connection for each port
    in the Public range.

    A delay can be configured between each trigger port. This is sometimes
    required for port trigger implementations using Smart ALGs. To configure
    the delay, configure the testvar 'portTriggerDelay' with the number of
    milliseconds.

    A delay can also be configured before a trigger port is verified as being
    open with WAN to LAN traffic. This is sometimes required for
    implemenatations that have a delay associated with processing the outbound
    trigger packet. To configure the delay, configure the testvar
    'portTriggerOpenDelay' with the number of milliseconds.

    Examples:

    testvar portTriggerDelay 5000
    testvar portTriggerOpenDelay 1000



upnp.tcl

UPnP tests for routers that support IGDv1/IGDv2 devices

Test Module Name Synopsis
Verify UPnP router responds to SSDP Discovery Requests on LAN upnp.tcl cdrouter_ssdp_1 Verify UPnP router responds to SSDP Discovery Requests on LAN


    step 1. Build a SSDP M-SEARCH request for search target "ssdp:all"
    step 2. Send M-SEARCH request using unique UDP source port
    step 3. Wait up to 5 seconds for all responses sent to UDP source port
    step 4. For each response, verify the required headers are included


    References:

    UPnP Device Architecture 1.1 Section 1: Discovery

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf1

Test Module Name Synopsis
Verify UPnP router does not respond to SSDP Discovery Requests on WAN upnp.tcl cdrouter_ssdp_2 Verify UPnP router does not respond to SSDP Discovery Requests on WAN


    step 1. Build a SSDP M-SEARCH request for search target "ssdp:all"
    step 2. Send M-SEARCH request on WAN side of router
    step 3. Wait up to 5 seconds for all responses sent
    step 4. Verify no responses are received


    References:

    UPnP Device Architecture 1.1 Section 1: Discovery

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf1

Test Module Name Synopsis
Verify UPnP router supports discovery of required IGD devices and services upnp.tcl cdrouter_ssdp_3 Verify UPnP router supports discovery of required IGD devices and services


    step 1. Build a M-SEARCH request for search for each required device/service
    step 2. Send M-SEARCH request using unique UDP source port
    step 3. Wait up to 5 seconds for all responses sent to UDP source port
    step 4. For each response, verify the required headers are included

    Required device and service URNs:

      urn:schemas-upnp-org:device:InternetGatewayDevice:1
      urn:schemas-upnp-org:device:WANDevice:1
      urn:schemas-upnp-org:device:WANConnectionDevice:1
      urn:schemas-upnp-org:device:LANDevice:1

      urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1
      urn:schemas-upnp-org:service:WANPPPConnection:1 (PPP based WAN only)
      urn:schemas-upnp-org:service:WANIPConnection:1  (not required for PPP)

    NOTE: Support for UPnP LANDevice:1 template is now configurable. If
    the router under test does not support the LANDevice:1
    template, the 'upnpLANDevice' testvar should be configured to
    no. If LANDevice is supported, the testvar should be configured
    to yes.


    References:

    InternetGatewayDevice:1 Device Template Version 1.01

    http://upnp.org/specs/gw/UPnP-gw-InternetGatewayDevice-v1-Device.pdf

    WANIPConnection:1 Service Template Version 1.01

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf

    WANIPConnection:2 Service Template Version 1.01

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf

Test Module Name Synopsis
Verify UPnP router does not respond to SSDP Discovery Requests without MX header upnp.tcl cdrouter_ssdp_4 Verify UPnP router does not respond to SSDP Discovery Requests without MX header


    step 1. Build a SSDP M-SEARCH request for search target "ssdp:all"
            that does not include an MX header
    step 2. Send M-SEARCH request on LAN side of router
    step 3. Wait up to 5 seconds for all responses sent
    step 4. Verify no responses are received


    References:

    UPnP Device Architecture 1.1 Section 1.3.3: Search response

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf1.3.3

Test Module Name Synopsis
Verify UPnP router responds to unicast SSDP Discovery Requests on LAN upnp.tcl cdrouter_ssdp_5 Verify UPnP router responds to unicast SSDP Discovery Requests on LAN


    step 1. Build a SSDP M-SEARCH request for search target "ssdp:all"
    step 2. Send a unicast M-SEARCH request using unique UDP source port
    step 3. Wait up to 5 seconds for all responses sent to UDP source port
    step 4. For each response, verify the required headers are included


    References:

    UPnP Device Architecture 1.1 Section 1: Discovery

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf1

Test Module Name Synopsis
Verify required headers of M-SEARCH responses on LAN upnp.tcl cdrouter_ssdp_6 Verify required headers of M-SEARCH responses on LAN


    step 1. Build a SSDP M-SEARCH request for search target "ssdp:all"
    step 2. Send M-SEARCH request using unique UDP source port
    step 3. Wait up to 5 seconds for all responses sent to UDP source port
    step 4. For each response, verify the required headers are included


    References:

    UPnP Device Architecture 1.1 Section 1: Discovery

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf1

Test Module Name Synopsis
Verify XML description of IGD root device can be parsed upnp.tcl cdrouter_upnp_10 Verify XML description of IGD root device can be parsed


    step 1. Find the description URL for the root device using SSDP
    step 2. Send HTTP GET to load description URL
    step 3. Verify the response can be parsed using XML parser

    Required root device:

      urn:schemas-upnp-org:device:InternetGatewayDevice:1


    References:

    InternetGatewayDevice:1 Device Template Version 1.01

    http://upnp.org/specs/gw/UPnP-gw-InternetGatewayDevice-v1-Device.pdf

Test Module Name Synopsis
Verify XML descriptions cannot be loaded from the WAN side of router upnp.tcl cdrouter_upnp_12 Verify XML descriptions cannot be loaded from the WAN side of router


    step 1. Find the description URL for the root device using SSDP on LAN
    step 2. Send HTTP GET from the WAN side to load description URL
    step 3. Send HTTP GET using router's WAN side public IP and private IP
    step 4. Verify description cannot be loaded using HTTP


    References:

    UPnP Device Architecture 1.1 Section 1: Discovery

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf1

Test Module Name Synopsis
Verify XML description for WANIPConnection or WANPPPConnection service can be parsed upnp.tcl cdrouter_upnp_20 Verify XML description for WANIPConnection or WANPPPConnection service can be parsed


    step 1. Find the description URL for the WANIPConnection or
            WANPPPConnection service using SSDP
    step 2. Send HTTP GET to load description URL
    step 3. Verify the response can be parsed using XML parser

    Required service name:

    urn:schemas-upnp-org:service:WANIPConnection:1
    urn:schemas-upnp-org:service:WANPPPConnection:1

    NOTE: The testvar 'upnpWANPPPConnection' is used to configure the test case
    to use the WANPPPConnection service. Otherwise, CDRouter will test for the
    WANIPConnection service.


    References:

    InternetGatewayDevice:1 Device Template Version 1.01

    http://upnp.org/specs/gw/UPnP-gw-InternetGatewayDevice-v1-Device.pdf

Test Module Name Synopsis
Verify router responds to UPnP Query for ConnectionStatus upnp.tcl cdrouter_upnp_25 Verify router responds to UPnP Query for ConnectionStatus


    step 1. Find Control URL for WANIPConnection service
    step 2. Send UPnP Query for ConnectionStatus via SOAP POST
    step 3. Verify ConnectionStatus variable is returned in SOAP response

    NOTE: The QueryStateVariable action has been deprecated by the UPnP Forum.
    This test should be skipped if the device does not support the
    QueryStateVariable action.


    References:

    UPnP Device Architecture 1.0 Section 3.3.1: Control: Query: Invoke

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.0-20080424.pdf3.3.1

Test Module Name Synopsis
Verify UPnP GetExternalIPAddress Action returns WAN IP address upnp.tcl cdrouter_upnp_30 Verify UPnP GetExternalIPAddress Action returns WAN IP address


    step 1. Find Control URL for WANIPConnection or WANPPPConnection service
    step 2. Send UPnP Action for GetExternalIPAddress
    step 3. Verify Action succeeds with HTTP return code 200
    step 4. Verify IP address returned in the NewExternalIPAddress
            attribute is the correct WAN IP address


    References:

    WANIPConnection:1 Service Template Version 1.01 Section 2.4.18: GetExternalIPAddress

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.18

Test Module Name Synopsis
Verify UPnP GetStatusInfo Action returns correct ConnectionStatus information upnp.tcl cdrouter_upnp_31 Verify UPnP GetStatusInfo Action returns correct ConnectionStatus information


    step 1. Find Control URL for WANIPConnection or WANPPPConnection service
    step 2. Send UPnP Action for GetStatusInfo
    step 3. Verify Action succeeds with HTTP return code 200
    step 4. Verify returned ConnectionStatus is in the 'Connected' state


    References:

    WANIPConnection:1 Service Template Version 1.01 Section 2.4.9: GetStatusInfo

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.9

Test Module Name Synopsis
Verify UPnP GetStatusInfo Action returns increasing Uptime value upnp.tcl cdrouter_upnp_32 Verify UPnP GetStatusInfo Action returns increasing Uptime value


    step 1. Find Control URL for WANIPConnection or WANPPPConnection service
    step 2. Send UPnP Action for GetStatusInfo
    step 3. Verify Action succeeds with HTTP return code 200
    step 4. Save the current Uptime
    step 5. Wait 10 seconds
    step 6. Send UPnP Action for GetStatusInfo
    step 7. Verify Action succeeds with HTTP return code 200
    step 8. Verify Uptime has increased by at least 10 seconds


    References:

    WANIPConnection:1 Service Template Version 1.01 Section 2.4.9: GetStatusInfo

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.9

Test Module Name Synopsis
Add/delete dynamic UPnP TCP port mapping for wildcard IP source address upnp.tcl cdrouter_upnp_35 Add/delete dynamic UPnP TCP port mapping for wildcard IP source address


    step 1. Find Control URL for WANIPConnection or WANPPPConnection service
    step 2. Send UPnP Action for AddPortMapping with wildcard
            for NewRemoteHost ("") and NewLeaseDuration of 0
    step 3. Verify Action returns HTTP 200 status code
    step 4. Initiate inbound TCP connection to new port mapping
    step 5. Verify TCP connection is established
    step 6. Initiate second inbound TCP connection from different IP
            source address on the WAN side
    step 7. Verify 2nd TCP connection is established
    step 8. Close both TCP connections
    step 9. Delete port mapping using DeletePortMapping Action
    step 10. Wait 5 seconds for port mapping to be deleted
    step 11. Initiate inbound TCP connection for port mapping from WAN side
    step 12. Verify inbound TCP connection is blocked


    References:

    WANIPConnection:1 Service Template Version 1.01 Section 2.4.16: AddPortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.16

    WANIPConnection:1 Service Template Version 1.01 Section 2.4.17: DeletePortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.17

Test Module Name Synopsis
Add/delete dynamic UPnP TCP port mapping for specific IP source address upnp.tcl cdrouter_upnp_36 Add/delete dynamic UPnP TCP port mapping for specific IP source address


    step 1. Find Control URL for WANIPConnection or WANPPPConnection service
    step 2. Send UPnP Action for AddPortMapping with specific IP address (A)
            for NewRemoteHost ("") and NewLeaseDuration of 0
    step 3. Verify Action returns HTTP 200 status code
    step 4. Initiate inbound TCP connection from specific IP address (A)
            to new port mapping
    step 5. Verify TCP connection is established
    step 6. Initiate second inbound TCP connection from different IP
            source address (B) on the WAN side
    step 7. Verify 2nd TCP connection is blocked
    step 8. Close both TCP connections
    step 9. Delete port mapping using DeletePortMapping Action
    step 10. Wait 5 seconds for port mapping to be deleted
    step 11. Initiate inbound TCP connection for port mapping from WAN side
             from specific ip address (A)
    step 12. Verify inbound TCP connection is blocked


    References:

    WANIPConnection:1 Service Template Version 1.01 Section 2.4.16: AddPortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.16

    WANIPConnection:1 Service Template Version 1.01 Section 2.4.17: DeletePortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.17

Test Module Name Synopsis
Add/delete dynamic UPnP UDP port mapping for wildcard IP source address upnp.tcl cdrouter_upnp_40 Add/delete dynamic UPnP UDP port mapping for wildcard IP source address


    step 1. Find Control URL for WANIPConnection or WANPPPConnection service
    step 2. Send UPnP Action for AddPortMapping with wildcard
            for NewRemoteHost (""), NewProtocol UDP and NewLeaseDuration of 0
    step 3. Verify Action returns HTTP 200 status code
    step 4. Initiate inbound UDP connection to new port mapping
    step 5. Verify UDP connection is established
    step 6. Initiate second inbound UDP connection from different IP
            source address on the WAN side
    step 7. Verify 2nd UDP connection is established
    step 8. Delete port mapping using DeletePortMapping Action
    step 9. Wait 5 seconds for port mapping to be deleted
    step 10. Initiate inbound UDP connection for port mapping from WAN side
    step 11. Verify inbound UDP connection is blocked


    References:

    WANIPConnection:1 Service Template Version 1.01 Section 2.4.16: AddPortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.16

    WANIPConnection:1 Service Template Version 1.01 Section 2.4.17: DeletePortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.17

Test Module Name Synopsis
Add/delete dynamic UPnP UDP port mapping for specific IP source address upnp.tcl cdrouter_upnp_41 Add/delete dynamic UPnP UDP port mapping for specific IP source address


    step 1. Find Control URL for WANIPConnection or WANPPPConnection service
    step 2. Send UPnP Action for AddPortMapping with specific IP address (A)
            for NewRemoteHost (""), NewProtocol UDP and NewLeaseDuration of 0
    step 3. Verify Action returns HTTP 200 status code
    step 4. Initiate inbound UDP connection from specific IP address (A)
            to new port mapping
    step 5. Verify UDP connection is established
    step 6. Initiate second inbound UDP connection from different IP
            source address (B) on the WAN side
    step 7. Verify 2nd UDP connection is blocked
    step 8. Delete port mapping using DeletePortMapping Action
    step 9. Wait 5 seconds for port mapping to be deleted
    step 10. Initiate inbound UDP connection for port mapping from WAN side
             from specific ip address (A)
    step 11. Verify inbound UDP connection is blocked


    References:

    WANIPConnection:1 Service Template Version 1.01 Section 2.4.16: AddPortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.16

    WANIPConnection:1 Service Template Version 1.01 Section 2.4.17: DeletePortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.17

Test Module Name Synopsis
Verify UPnP Router rejects new port mappings that conflict upnp.tcl cdrouter_upnp_45 Verify UPnP Router rejects new port mappings that conflict


    step 1. Start second client on LAN interface
    step 2. Find Control URL for WANIPConnection or WANPPPConnection service
    step 3. Send UPnP Action for AddPortMapping from the first DHCP client
    step 4. Verify Action returns HTTP 200 status code
    step 5. Send 2nd UPnP Action for AddPortMapping from the second client
            using the same external port number and protocol
    step 6. Verify AddPortMapping Action fails
    step 7. Delete port mapping using DeletePortMapping Action


    References:

    WANIPConnection:1 Service Template Version 1.01 Section 2.4.16: AddPortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.16

Test Module Name Synopsis
Verify dynamic UPnP port mapping is deleted when lease expires upnp.tcl cdrouter_upnp_50 Verify dynamic UPnP port mapping is deleted when lease expires


    step 1. Find Control URL for WANIPConnection or WANPPPConnection service
    step 2. Send UPnP Action for AddPortMapping with lease of 30 seconds
    step 3. Verify Action returns HTTP 200 status code
    step 4. Initiate inbound TCP connection to new port mapping
    step 5. Verify TCP connection is established
    step 6. Close TCP connection
    step 7. Wait 45 seconds for lease to be deleted
    step 8. Initiate inbound TCP connection to new port mapping
    step 9. Verify TCP connection is blocked


    References:

    WANIPConnection:1 Service Template Version 1.01 Section 2.4.16: AddPortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.16

    WANIPConnection:1 Service Template Version 1.01 Section 2.4.17: DeletePortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.17

Test Module Name Synopsis
Maximum number of UPnP TCP dynamic port mappings upnp.tcl cdrouter_upnp_100 Maximum number of UPnP TCP dynamic port mappings


    step 1. Determine the maximum number of UPnP TCP port mappings

    NOTE: This is configured in your configuration file using  the
    the testvar 'upnpMaxTcpMappings'.

    step 2. Create a unique port mapping using the AddPortMapping Action
            up to the maximum number supported
    step 3. For each mapping, establish an inbound TCP connection
    step 4. Verify each TCP connection can be established
    step 5. Delete each port mapping using the DeletePortMapping Action


    References:

    WANIPConnection:1 Service Template Version 1.01 Section 2.4.16: AddPortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.16

    WANIPConnection:1 Service Template Version 1.01 Section 2.4.17: DeletePortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v1-Service.pdf2.4.17

Test Module Name Synopsis
Verify UPnP clients can subscribe/unsubcribe to events for WANIPConnection or WANPPPConnection upnp.tcl cdrouter_upnp_200 Verify UPnP clients can subscribe/unsubcribe to events for WANIPConnection or WANPPPConnection


    step 1. Find Control URL for WANIPConnection or WANPPPConnection service
    step 2. Send SUBSCRIBE for eventSubURL
    step 3. Verify SUBSCRIBE returns HTTP 200 OK response
    step 4. Wait for initial NOTIFY event
    step 5. Send UNSUBSCRIBE for eventSubURL
    step 6. Verify UNSUBSCRIBE returns HTTP 200 OK response


    References:

    UPnP Device Architecture 1.1 Section 4.0: Eventing

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0

Test Module Name Synopsis
Verify UPnP clients can subscribe to events with infinite subscription time upnp.tcl cdrouter_upnp_201 Verify UPnP clients can subscribe to events with infinite subscription time


    step 1. Find Control URL for WANIPConnection or WANPPPConnection service
    step 2. Send SUBSCRIBE for eventSubURL using Timeout of infinite
    step 3. Verify SUBSCRIBE returns HTTP 200 OK response
    step 4. Wait for initial NOTIFY event
    step 5. Send UNSUBSCRIBE for eventSubURL
    step 6. Verify UNSUBSCRIBE returns HTTP 200 OK response


    References:

    UPnP Device Architecture 1.1 Section 4.0: Eventing

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0

Test Module Name Synopsis
Verify UPnP clients can renew NOTIFY events for WANIPConnection or WANPPPConnection upnp.tcl cdrouter_upnp_202 Verify UPnP clients can renew NOTIFY events for WANIPConnection or WANPPPConnection


    step 1. Find Control URL for WANIPConnection or WANPPPConnection service
    step 2. Send SUBSCRIBE for eventSubURL
    step 3. Verify SUBSCRIBE returns HTTP 200 OK response
    step 4. Wait for initial NOTIFY event
    step 5. Send SUBSCRIBE renewal for NOTIFY events
    step 6. Verify SUBSCRIBE renewal returns HTTP 200 OK response
    step 7. Send UNSUBSCRIBE for eventSubURL
    step 8. Verify UNSUBSCRIBE returns HTTP 200 OK response


    References:

    UPnP Device Architecture 1.1 Section 4.0: Eventing

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0

Test Module Name Synopsis
Verify router sends UPnP NOTIFY events for ConnectionStatus upnp.tcl cdrouter_upnp_203 Verify router sends UPnP NOTIFY events for ConnectionStatus


    step 1. Find Control URL for WANIPConnection or WANPPPConnection service
    step 2. Send SUBSCRIBE for eventSubURL
    step 3. Verify SUBSCRIBE returns HTTP 200 OK response
    step 4. Wait for initial NOTIFY event
    step 5. Verify ConnectionStatus is 'Connected'
    step 6. Bring down WAN link
    step 7. Wait for NOTIFY event with new ConnectionStatus
    step 8. Verify ConnectionStatus is not 'Connected'
    step 9. Bring up WAN link
    step 10. Wait for NOTIFY event with new ConnectionStatus
    step 11. Verify ConnectionStatus is 'Connected'
    step 12. Send UNSUBSCRIBE for eventSubURL
    step 13. Verify UNSUBSCRIBE returns HTTP 200 OK response

    NOTE: This test is not supported when the wanMode is static.


    References:

    UPnP Device Architecture 1.1 Section 4.0: Eventing

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0

Test Module Name Synopsis
Verify router sends UPnP NOTIFY events with updated ExternalIPAddress upnp.tcl cdrouter_upnp_204 Verify router sends UPnP NOTIFY events with updated ExternalIPAddress


    step 1. Find Control URL for WANIPConnection or WANPPPConnection service
    step 2. Send SUBSCRIBE for eventSubURL
    step 3. Verify SUBSCRIBE returns HTTP 200 OK response
    step 4. Wait for initial NOTIFY event
    step 5. Verify ExternalIPAddress matches current assigned WAN IP
    step 6. Bring down WAN link
    step 7. Bring up WAN link with new external IP address
    step 8. Wait for NOTIFY event with new ExternalIPAddress
    step 9. Verify ExternalIPAddress is new IP address
    step 10. Bring down WAN link
    step 11. Bring up WAN link with new original IP address
    step 12. Wait for NOTIFY event with new ExternalIPAddress
    step 13. Verify ExternalIPAddress is original IP address
    step 14. Send UNSUBSCRIBE for eventSubURL
    step 15. Verify UNSUBSCRIBE returns HTTP 200 OK response


    References:

    UPnP Device Architecture 1.1 Section 4.0: Eventing

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0

Test Module Name Synopsis
Verify router stops sending NOTIFY events when subscription expires upnp.tcl cdrouter_upnp_210 Verify router stops sending NOTIFY events when subscription expires


    step 1. Find Control URL for WANIPConnection or WANPPPConnection service
    step 2. Send SUBSCRIBE for eventSubURL using minimum subscriber timeout
    step 3. Verify SUBSCRIBE returns HTTP 200 OK response
    step 4. Wait for initial NOTIFY event
    step 5. Verify ConnectionStatus is 'Connected'
    step 6. Wait minimum subscriber timeout seconds for subscription to expire
    step 7. Bring down WAN link
    step 8. Wait for NOTIFY event
    step 9. Verify NOTIFY event is not received
    step 10. Bring up WAN link
    step 11. Wait for NOTIFY event
    step 12. Verify NOTIFY event is not received
    step 13. Do not UNSUBSCRIBE since subscription should be expired


    References:

    UPnP Device Architecture 1.1 Section 4.0: Eventing

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0

Test Module Name Synopsis
Verify the maximum number of UPnP event subscriptions that can be created upnp.tcl cdrouter_upnp_220 Verify the maximum number of UPnP event subscriptions that can be created


    step 1. Find Control URL for WANIPConnection or WANPPPConnection service
    step 2. For each event client, send SUBSCRIBE for eventSubURL
    step 3. Verify SUBSCRIBE returns HTTP 200 OK response
    step 4. For each event client, wait for initial NOTIFY event
    step 5. Verify ConnectionStatus is 'Connected'
    step 6. Bring down WAN link
    step 7. For each event client, wait for NOTIFY event with new ConnectionStatus
    step 8. For each event client, verify ConnectionStatus is not 'Connected'
    step 9. Bring up WAN link
    step 10. For each event client, wait for NOTIFY event with new ConnectionStatus
    step 11. For each event client, verify ConnectionStatus is 'Connected'
    step 12. For each event client, send UNSUBSCRIBE for eventSubURL
    step 13. For each event client, verify UNSUBSCRIBE returns HTTP 200 OK response

    NOTE: The number of UPnP subscribers can be configured using the testvar
    upnpMaxSubClients. If not configured, the default is 10 subscribers.


    References:

    UPnP Device Architecture 1.1 Section 4.0: Eventing

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0

Test Module Name Synopsis
Check for UPnP format string vulnerability used by BCMPUPnP_Hunter malware upnp.tcl cdrouter_upnp_400 Check for UPnP format string vulnerability used by BCMPUPnP_Hunter malware


    step 1. Find Control URL for WANIPConnection or WANPPPConnection service
    step 2. Send UPnP Action for SetConnectionType with string format
    step 3. Verify Action does not return HTTP 200 status code
    step 4. Send UPnP Action for GetConnectionTypeInfo to trigger exploit


    References:

    Broadcom UPnP Remote Preauth Code Execution Vulnerability

    https://www.defensecode.com/public/DefenseCode_Broadcom_Security_Advisory.pdf/

    From Zero to ZeroDay Journey: Router Hacking (WRT54GL Linksys Case)

    https://defensecode.com/whitepapers/From_Zero_To_ZeroDay_Network_Devices_Exploitation.txt

Test Module Name Synopsis
Verify UPnP router supports discovery of required devices and services (IGD2) upnp.tcl cdrouter_ssdp_igd2_3 Verify UPnP router supports discovery of required devices and services (IGD2)


    step 1. Build a M-SEARCH request for search for each required device/service
    step 2. Send M-SEARCH request using unique UDP source port
    step 3. Wait up to 5 seconds for all responses sent to UDP source port
    step 4. For each response, verify the required headers are included

    Required device and service URNs:

      urn:schemas-upnp-org:device:InternetGatewayDevice:2
      urn:schemas-upnp-org:device:WANDevice:2
      urn:schemas-upnp-org:device:WANConnectionDevice:2
      urn:schemas-upnp-org:device:LANDevice:1

      urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1
      urn:schemas-upnp-org:service:WANPPPConnection:1 (PPP based WAN only)
      urn:schemas-upnp-org:service:WANIPConnection:2  (not required for PPP)

    NOTE: Support for UPnP LANDevice:1 template is now configurable. If the
    router under test does not support the LANDevice:1 template, the
    'upnpLANDevice' testvar should be configured to no. If LANDevice is
    supported, the testvar should be configured to yes.


    References:

    InternetGatewayDevice:2 Device Template Version 1.01

    http://upnp.org/specs/gw/UPnP-gw-InternetGatewayDevice-v2-Device.pdf

Test Module Name Synopsis
Verify XML description of IGD root device can be parsed (IGD2) upnp.tcl cdrouter_upnp_igd2_10 Verify XML description of IGD root device can be parsed (IGD2)


    step 1. Find the description URL for the root device using SSDP
    step 2. Send HTTP GET to load description URL
    step 3. Verify the response can be parsed using XML parser

    Required root device:

      urn:schemas-upnp-org:device:InternetGatewayDevice:2


    References:

    InternetGatewayDevice:2 Device Template Version 1.01

    http://upnp.org/specs/gw/UPnP-gw-InternetGatewayDevice-v2-Device.pdf

Test Module Name Synopsis
Verify XML descriptions cannot be loaded from the WAN side of router (IGD2) upnp.tcl cdrouter_upnp_igd2_12 Verify XML descriptions cannot be loaded from the WAN side of router (IGD2)


    step 1. Find the description URL for the root device using SSDP on LAN
    step 2. Send HTTP GET from the WAN side to load description URL
    step 3. Send HTTP GET using router's WAN side public IP and private IP
    step 4. Verify description cannot be loaded using HTTP


    References:

    InternetGatewayDevice:2 Device Template Version 1.01

    http://upnp.org/specs/gw/UPnP-gw-InternetGatewayDevice-v2-Device.pdf

Test Module Name Synopsis
Verify XML description for WANIPConnection or WANPPPConnection service can be parsed (IGD2) upnp.tcl cdrouter_upnp_igd2_20 Verify XML description for WANIPConnection or WANPPPConnection service can be parsed (IGD2)


    step 1. Find the description URL for the WANIPConnection:2 or
            WANPPPConnection:1 service using SSDP
    step 2. Send HTTP GET to load description URL
    step 3. Verify the response can be parsed using XML parser

    Required service name:

    urn:schemas-upnp-org:service:WANIPConnection:2
    urn:schemas-upnp-org:service:WANPPPConnection:1

    NOTE: The testvar 'upnpWANPPPConnection' is used to configure the
    test case to use the WANPPPConnection service. Otherwise, the
    router uses the WANIPConnection service.


    References:

    WANIPConnection:2 Service Template Version 2.00

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf

    WANIPConnection:2 Service Template Version 1.01

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf

Test Module Name Synopsis
Verify router responds to UPnP Query for ConnectionStatus (IGD2) upnp.tcl cdrouter_upnp_igd2_25 Verify router responds to UPnP Query for ConnectionStatus (IGD2)


    step 1. Find Control URL for WANIPConnection:2 service
    step 2. Send UPnP Query for ConnectionStatus via SOAP POST
    step 3. Verify ConnectionStatus variable is returned in SOAP response

    NOTE: The QueryStateVariable action has been deprecated by the UPnP Forum.
    This test should be skipped if the device does not support the
    QueryStateVariable action.


    References:

    UPnP Device Architecture 1.0 Section 3.3.1: Control: Query: Invoke

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.0-20080424.pdf3.3.1

Test Module Name Synopsis
Verify UPnP GetExternalIPAddress Action returns WAN IP address (IGD2) upnp.tcl cdrouter_upnp_igd2_30 Verify UPnP GetExternalIPAddress Action returns WAN IP address (IGD2)


    step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
    step 2. Send UPnP Action for GetExternalIPAddress
    step 3. Verify Action succeeds with HTTP return code 200
    step 4. Verify IP address returned in the NewExternalIPAddress
            attribute is the correct WAN IP address


    References:

    WANIPConnection:2 Service Template Version 2.00 Section 2.5.20: GetExternalIPAddress

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.20

Test Module Name Synopsis
Verify UPnP GetStatusInfo Action returns correct ConnectionStatus information (IGD2) upnp.tcl cdrouter_upnp_igd2_31 Verify UPnP GetStatusInfo Action returns correct ConnectionStatus information (IGD2)


    step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
    step 2. Send UPnP Action for GetStatusInfo
    step 3. Verify Action succeeds with HTTP return code 200
    step 4. Verify returned ConnectionStatus is in the 'Connected' state


    References:

    WANIPConnection:2 Service Template Version 2.00 Section 2.5.9: GetStatusInfo

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.9

Test Module Name Synopsis
Verify UPnP GetStatusInfo Action returns increasing Uptime value (IGD2) upnp.tcl cdrouter_upnp_igd2_32 Verify UPnP GetStatusInfo Action returns increasing Uptime value (IGD2)


    step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
    step 2. Send UPnP Action for GetStatusInfo
    step 3. Verify Action succeeds with HTTP return code 200
    step 4. Save the current Uptime
    step 5. Wait 10 seconds
    step 6. Send UPnP Action for GetStatusInfo
    step 7. Verify Action succeeds with HTTP return code 200
    step 8. Verify Uptime has increased by at least 10 seconds


    References:

    WANIPConnection:2 Service Template Version 2.00 Section 2.5.9: GetStatusInfo

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.9

Test Module Name Synopsis
Add/delete dynamic UPnP TCP port mapping for wildcard IP source address (IGD2) upnp.tcl cdrouter_upnp_igd2_35 Add/delete dynamic UPnP TCP port mapping for wildcard IP source address (IGD2)


    step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
    step 2. Send UPnP Action for AddPortMapping with wildcard
            for NewRemoteHost ("") and NewLeaseDuration of 0
    step 3. Verify Action returns HTTP 200 status code
    step 4. Initiate inbound TCP connection to new port mapping
    step 5. Verify TCP connection is established
    step 6. Initiate second inbound TCP connection from different IP
            source address on the WAN side
    step 7. Verify 2nd TCP connection is established
    step 8. Close both TCP connections
    step 9. Delete port mapping using DeletePortMapping Action
    step 10. Wait 5 seconds for port mapping to be deleted
    step 11. Initiate inbound TCP connection for port mapping from WAN side
    step 12. Verify inbound TCP connection is blocked


    References:

    WANIPConnection:2 Service Template Version 2.00 Section 2.5.16: AddPortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.16

    WANIPConnection:2 Service Template Version 2.00 Section 2.5.18: DeletePortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.18

Test Module Name Synopsis
Add/delete dynamic UPnP TCP port mapping for specific IP source address (IGD2) upnp.tcl cdrouter_upnp_igd2_36 Add/delete dynamic UPnP TCP port mapping for specific IP source address (IGD2)


    step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
    step 2. Send UPnP Action for AddPortMapping with specific IP address (A)
            for NewRemoteHost ("") and NewLeaseDuration of 0
    step 3. Verify Action returns HTTP 200 status code
    step 4. Initiate inbound TCP connection from specific IP address (A)
            to new port mapping
    step 5. Verify TCP connection is established
    step 6. Initiate second inbound TCP connection from different IP
            source address (B) on the WAN side
    step 7. Verify 2nd TCP connection is blocked
    step 8. Close both TCP connections
    step 9. Delete port mapping using DeletePortMapping Action
    step 10. Wait 5 seconds for port mapping to be deleted
    step 11. Initiate inbound TCP connection for port mapping from WAN side
             from specific ip address (A)
    step 12. Verify inbound TCP connection is blocked


    References:

    WANIPConnection:2 Service Template Version 2.00 Section 2.5.16: AddPortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.16

    WANIPConnection:2 Service Template Version 2.00 Section 2.5.18: DeletePortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.18

Test Module Name Synopsis
Add/delete dynamic UPnP UDP port mapping for wildcard IP source address (IGD2) upnp.tcl cdrouter_upnp_igd2_40 Add/delete dynamic UPnP UDP port mapping for wildcard IP source address (IGD2)


    step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
    step 2. Send UPnP Action for AddPortMapping with wildcard
            for NewRemoteHost (""), NewProtocol UDP and NewLeaseDuration of 0
    step 3. Verify Action returns HTTP 200 status code
    step 4. Initiate inbound UDP connection to new port mapping
    step 5. Verify UDP connection is established
    step 6. Initiate second inbound UDP connection from different IP
            source address on the WAN side
    step 7. Verify 2nd UDP connection is established
    step 8. Delete port mapping using DeletePortMapping Action
    step 9. Wait 5 seconds for port mapping to be deleted
    step 10. Initiate inbound UDP connection for port mapping from WAN side
    step 11. Verify inbound UDP connection is blocked


    References:

    WANIPConnection:2 Service Template Version 2.00 Section 2.5.16: AddPortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.16

    WANIPConnection:2 Service Template Version 2.00 Section 2.5.18: DeletePortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.18

Test Module Name Synopsis
Add/delete dynamic UPnP UDP port mapping for specific IP source address (IGD2) upnp.tcl cdrouter_upnp_igd2_41 Add/delete dynamic UPnP UDP port mapping for specific IP source address (IGD2)


    step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
    step 2. Send UPnP Action for AddPortMapping with specific IP address (A)
            for NewRemoteHost (""), NewProtocol UDP and NewLeaseDuration of 0
    step 3. Verify Action returns HTTP 200 status code
    step 4. Initiate inbound UDP connection from specific IP address (A)
            to new port mapping
    step 5. Verify UDP connection is established
    step 6. Initiate second inbound UDP connection from different IP
            source address (B) on the WAN side
    step 7. Verify 2nd UDP connection is blocked
    step 8. Delete port mapping using DeletePortMapping Action
    step 9. Wait 5 seconds for port mapping to be deleted
    step 10. Initiate inbound UDP connection for port mapping from WAN side
             from specific ip address (A)
    step 11. Verify inbound UDP connection is blocked


    References:

    WANIPConnection:2 Service Template Version 2.00 Section 2.5.16: AddPortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.16

    WANIPConnection:2 Service Template Version 2.00 Section 2.5.18: DeletePortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.18

Test Module Name Synopsis
Verify UPnP Router rejects new port mappings that conflict (IGD2) upnp.tcl cdrouter_upnp_igd2_45 Verify UPnP Router rejects new port mappings that conflict (IGD2)


    step 1. Start second client on LAN interface
    step 2. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
    step 3. Send UPnP Action for AddPortMapping from the first DHCP client
    step 4. Verify Action returns HTTP 200 status code
    step 5. Send 2nd UPnP Action for AddPortMapping from the second client
            using the same external port number and protocol
    step 6. Verify AddPortMapping Action fails
    step 7. Delete port mapping using DeletePortMapping Action


    References:

    WANIPConnection:2 Service Template Version 2.00 Section 2.5.16: AddPortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.16

Test Module Name Synopsis
Verify dynamic UPnP port mapping is deleted when lease expires (IGD2) upnp.tcl cdrouter_upnp_igd2_50 Verify dynamic UPnP port mapping is deleted when lease expires (IGD2)


    step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
    step 2. Send UPnP Action for AddPortMapping with lease of 30 seconds
    step 3. Verify Action returns HTTP 200 status code
    step 4. Initiate inbound TCP connection to new port mapping
    step 5. Verify TCP connection is established
    step 6. Close TCP connection
    step 7. Wait 45 seconds for lease to be deleted
    step 8. Initiate inbound TCP connection to new port mapping
    step 9. Verify TCP connection is blocked


    References:

    WANIPConnection:2 Service Template Version 2.00 Section 2.5.16: AddPortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.16

Test Module Name Synopsis
Maximum number of UPnP TCP dynamic port mappings (IGD2) upnp.tcl cdrouter_upnp_igd2_100 Maximum number of UPnP TCP dynamic port mappings (IGD2)


    step 1. Determine the maximum number of UPnP TCP port mappings

    NOTE: This is configured in your configuration file using  the
    the testvar 'upnpMaxTcpMappings'.

    step 2. Create a unique port mapping using the AddPortMapping Action
            up to the maximum number supported
    step 3. For each mapping, establish an inbound TCP connection
    step 4. Verify each TCP connection can be established
    step 5. Delete each port mapping using the DeletePortMapping Action


    References:

    WANIPConnection:2 Service Template Version 2.00 Section 2.5.16: AddPortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.16

    WANIPConnection:2 Service Template Version 2.00 Section 2.5.18: DeletePortMapping

    http://upnp.org/specs/gw/UPnP-gw-WANIPConnection-v2-Service.pdf2.5.18

Test Module Name Synopsis
Verify UPnP clients can subscribe/unsubcribe to events for WANIPConnection or WANPPPConnection (IGD2) upnp.tcl cdrouter_upnp_igd2_200 Verify UPnP clients can subscribe/unsubcribe to events for WANIPConnection or WANPPPConnection (IGD2)


    step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
    step 2. Send SUBSCRIBE for eventSubURL
    step 3. Verify SUBSCRIBE returns HTTP 200 OK response
    step 4. Wait for initial NOTIFY event
    step 5. Send UNSUBSCRIBE for eventSubURL
    step 6. Verify UNSUBSCRIBE returns HTTP 200 OK response


    References:

    UPnP Device Architecture 1.1 Section 4.0: Eventing

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0

Test Module Name Synopsis
Verify UPnP clients can subscribe to events with infinite subscription time (IGD2) upnp.tcl cdrouter_upnp_igd2_201 Verify UPnP clients can subscribe to events with infinite subscription time (IGD2)


    step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
    step 2. Send SUBSCRIBE for eventSubURL using Timeout of infinite
    step 3. Verify SUBSCRIBE returns HTTP 200 OK response
    step 4. Wait for initial NOTIFY event
    step 5. Send UNSUBSCRIBE for eventSubURL
    step 6. Verify UNSUBSCRIBE returns HTTP 200 OK response


    References:

    UPnP Device Architecture 1.1 Section 4.0: Eventing

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0

Test Module Name Synopsis
Verify UPnP clients can renew NOTIFY events for WANIPConnection or WANPPPConnection (IGD2) upnp.tcl cdrouter_upnp_igd2_202 Verify UPnP clients can renew NOTIFY events for WANIPConnection or WANPPPConnection (IGD2)


    step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
    step 2. Send SUBSCRIBE for eventSubURL
    step 3. Verify SUBSCRIBE returns HTTP 200 OK response
    step 4. Wait for initial NOTIFY event
    step 5. Send SUBSCRIBE renewal for NOTIFY events
    step 6. Verify SUBSCRIBE renewal returns HTTP 200 OK response
    step 7. Send UNSUBSCRIBE for eventSubURL
    step 8. Verify UNSUBSCRIBE returns HTTP 200 OK response


    References:

    UPnP Device Architecture 1.1 Section 4.0: Eventing

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0

Test Module Name Synopsis
Verify router sends UPnP NOTIFY events for ConnectionStatus (IGD2) upnp.tcl cdrouter_upnp_igd2_203 Verify router sends UPnP NOTIFY events for ConnectionStatus (IGD2)


    step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
    step 2. Send SUBSCRIBE for eventSubURL
    step 3. Verify SUBSCRIBE returns HTTP 200 OK response
    step 4. Wait for initial NOTIFY event
    step 5. Verify ConnectionStatus is 'Connected'
    step 6. Bring down WAN link
    step 7. Wait for NOTIFY event with new ConnectionStatus
    step 8. Verify ConnectionStatus is not 'Connected'
    step 9. Bring up WAN link
    step 10. Wait for NOTIFY event with new ConnectionStatus
    step 11. Verify ConnectionStatus is 'Connected'
    step 12. Send UNSUBSCRIBE for eventSubURL
    step 13. Verify UNSUBSCRIBE returns HTTP 200 OK response

    NOTE: This test is not supported when the wanMode is static.


    References:

    UPnP Device Architecture 1.1 Section 4.0: Eventing

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0

Test Module Name Synopsis
Verify router sends UPnP NOTIFY events with updated ExternalIPAddress (IGD2) upnp.tcl cdrouter_upnp_igd2_204 Verify router sends UPnP NOTIFY events with updated ExternalIPAddress (IGD2)


    step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
    step 2. Send SUBSCRIBE for eventSubURL
    step 3. Verify SUBSCRIBE returns HTTP 200 OK response
    step 4. Wait for initial NOTIFY event
    step 5. Verify ExternalIPAddress matches current assigned WAN IP
    step 6. Bring down WAN link
    step 7. Bring up WAN link with new external IP address
    step 8. Wait for NOTIFY event with new ExternalIPAddress
    step 9. Verify ExternalIPAddress is new IP address
    step 10. Bring down WAN link
    step 11. Bring up WAN link with new original IP address
    step 12. Wait for NOTIFY event with new ExternalIPAddress
    step 13. Verify ExternalIPAddress is original IP address
    step 14. Send UNSUBSCRIBE for eventSubURL
    step 15. Verify UNSUBSCRIBE returns HTTP 200 OK response


    References:

    UPnP Device Architecture 1.1 Section 4.0: Eventing

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0

Test Module Name Synopsis
Verify router stops sending NOTIFY events when subscription expires (IGD2) upnp.tcl cdrouter_upnp_igd2_210 Verify router stops sending NOTIFY events when subscription expires (IGD2)


    step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
    step 2. Send SUBSCRIBE for eventSubURL using minimum subscriber timeout
    step 3. Verify SUBSCRIBE returns HTTP 200 OK response
    step 4. Wait for initial NOTIFY event
    step 5. Verify ConnectionStatus is 'Connected'
    step 6. Wait minimum subscriber timeout seconds for subscription to expire
    step 7. Bring down WAN link
    step 8. Wait for NOTIFY event
    step 9. Verify NOTIFY event is not received
    step 10. Bring up WAN link
    step 11. Wait for NOTIFY event
    step 12. Verify NOTIFY event is not received
    step 13. Do not UNSUBSCRIBE since subscription should be expired


    References:

    UPnP Device Architecture 1.1 Section 4.0: Eventing

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0

Test Module Name Synopsis
Verify the maximum number of UPnP event subscriptions that can be created (IGD2) upnp.tcl cdrouter_upnp_igd2_220 Verify the maximum number of UPnP event subscriptions that can be created (IGD2)


    step 1. Find Control URL for WANIPConnection:2 or WANPPPConnection:1 service
    step 2. For each event client, send SUBSCRIBE for eventSubURL
    step 3. Verify SUBSCRIBE returns HTTP 200 OK response
    step 4. For each event client, wait for initial NOTIFY event
    step 5. Verify ConnectionStatus is 'Connected'
    step 6. Bring down WAN link
    step 7. For each event client, wait for NOTIFY event with new ConnectionStatus
    step 8. For each event client, verify ConnectionStatus is not 'Connected'
    step 9. Bring up WAN link
    step 10. For each event client, wait for NOTIFY event with new ConnectionStatus
    step 11. For each event client, verify ConnectionStatus is 'Connected'
    step 12. For each event client, send UNSUBSCRIBE for eventSubURL
    step 13. For each event client, verify UNSUBSCRIBE returns HTTP 200 OK response

    NOTE: The number of UPnP subscribers can be configured using the testvar
    upnpMaxSubClients. If not configured, the default is 10 subscribers.


    References:

    UPnP Device Architecture 1.1 Section 4.0: Eventing

    http://www.upnp.org/specs/arch/UPnP-arch-DeviceArchitecture-v1.1.pdf4.0

Test Module Name Synopsis
Check for UPnP format string vulnerability used by BCMPUPnP_Hunter malware upnp.tcl cdrouter_upnp_igd2_400 Check for UPnP format string vulnerability used by BCMPUPnP_Hunter malware


    step 1. Find Control URL for WANIPConnection or WANPPPConnection service
    step 2. Send UPnP Action for SetConnectionType with string format
    step 3. Verify Action does not return HTTP 200 status code
    step 4. Send UPnP Action for GetConnectionTypeInfo to trigger exploit


    References:

    Broadcom UPnP Remote Preauth Code Execution Vulnerability

    https://www.defensecode.com/public/DefenseCode_Broadcom_Security_Advisory.pdf/

    From Zero to ZeroDay Journey: Router Hacking (WRT54GL Linksys Case)

    https://defensecode.com/whitepapers/From_Zero_To_ZeroDay_Network_Devices_Exploitation.txt


pptp-pt.tcl

PPTP based VPN pass through from the LAN to the WAN

Test Module Name Synopsis
PPTP control session can be established at port 1723 pptp-pt.tcl cdrouter_pptppt_1 PPTP control session can be established at port 1723


    step 1. Create PPTP sever on WAN side of the router
    step 2. Initiate TCP session from LAN to port 1723 on PPTP server
    step 3. Verify TCP session can be established
    step 4. Initiate PPTP control session
    step 5. Initiate new outbound PPTP call from LAN side
    step 6. Verify PPTP call is established
    step 7. Close TCP session from LAN side


    References:

    IETF RFC 2637 "Point-to-Point Tunneling Protocol (PPTP)"

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

Test Module Name Synopsis
Tunneled PPTP data packets pass through router (PPP over GRE) pptp-pt.tcl cdrouter_pptppt_2 Tunneled PPTP data packets pass through router (PPP over GRE)


    step 1. Initiate outbound PPTP call using unique PPTP tunnel endpoint
    step 2. Verify PPTP control session is established and call is accepted
    step 3. Initiate an ICMP Echo Request on the LAN host through a PPTP tunnel
    step 4. Send the ICMP packet as a tunneled PPP over GRE packet
    step 5. Verify the tunneled PPP over GRE packet is received on the WAN host
    step 6. Respond to the ICMP Echo Request on the WAN side
    step 7. Send the ICMP Echo Reply as a tunneled PPP over GRE packet


    References:

    IETF RFC 2637 "Point-to-Point Tunneling Protocol (PPTP)"

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

Test Module Name Synopsis
Verify the max number of PPTP pass through connections for a single LAN host pptp-pt.tcl cdrouter_pptppt_100 Verify the max number of PPTP pass through connections for a single LAN host


    step 1. Initiate outbound PPTP call using unique PPTP tunnel endpoint
    step 2. Verify PPTP control session is established and call is accepted
    step 3. Forward an ICMP Echo Request from LAN to unique WAN IP address using
            a unique PPTP tunnel endpoint IP address
    step 4. Verify the packet is received on the WAN
    step 5. Send an ICMP Echo Reply to LAN using PPTP tunnel
    step 6. Verify the ICMP Echo Reply is received on the LAN
    step 7. Repeat up to the pptpMaxTunnels value

    Note: Each PPTP tunnel uses a unique IP address as its PPTP tunnel
    endpoint. The ICMP Echo Request is also sent to a unique IP destination
    address that is routed over the PPTP tunnel on the LAN.

    References:

    IETF RFC 2637 "Point-to-Point Tunneling Protocol (PPTP)"

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


l2tp-pt.tcl

L2TP based VPN pass through from the LAN to the WAN

Test Module Name Synopsis
Verify L2TP session passes through router l2tp-pt.tcl cdrouter_l2tppt_1 Verify L2TP session passes through router


    step 1. Initiate outbound L2TP tunnel to L2TP server
    step 2. Verify L2TP session is established
    step 3. Initiate PPP session over L2TP tunnel
    step 4. Verify ICMP echo across tunnel

    NOTE: This test case uses L2TP directly over UDP without IPSEC. L2TP clients
    from Microsoft normally run L2TP over IPSEC. L2TP over IPSEC pass through
    is covered by test case cdrouter_l2tppt_2.


    References:

    IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""

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

Test Module Name Synopsis
Verify L2TP over IPSEC session passes through router l2tp-pt.tcl cdrouter_l2tppt_2 Verify L2TP over IPSEC session passes through router


    step 1. Initiate IKE transport mode tunnel to L2TP server
    step 2. Initiate outbound L2TP call to L2TP server
    step 3. Verify L2TP tunnel is established
    step 4. Initiate PPP session over L2TP tunnel
    step 5. Verify ICMP echo across tunnel


    References:

    IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""

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

Test Module Name Synopsis
Verify L2TP over IPSEC with NAT-T passes through router l2tp-pt.tcl cdrouter_l2tppt_10 Verify L2TP over IPSEC with NAT-T passes through router


    step 1. Initiate IKE transport mode tunnel with NAT-T to L2TP server
    step 2. Initiate outbound L2TP call to L2TP server
    step 3. Verify L2TP tunnel is established
    step 4. Initiate PPP session over L2TP tunnel
    step 5. Verify ICMP echo across tunnel


    References:

    IETF RFC 2661 "Layer Two Tunneling Protocol "L2TP""

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


eapol.tcl

Basic EAPOL tests for all types of EAP

Test Module Name Synopsis
Authenticator sends EAPOL packets to correct MAC address eapol.tcl cdrouter_eapol_1 Authenticator sends EAPOL packets to correct MAC address


    step 1. Unauthorize the supplicant interface
    step 2. Start authentication on the supplicant interface
    step 3. Wait for EAPOL packet from authenticator (up to txWhen seconds)
    step 4. For wireless supplicants, verify that the destination MAC address
            of the packet received in step 3 is the supplicant's unicast MAC
            address; for wired supplicants, verify that the destination MAC
            address is the supplicant's unicast MAC address or the PAE group
            address 01:80:C2:00:00:03

    NOTE: The authenticator should be in the CONNECTING state after the
    EAPOL-Logoff/EAPOL-Start packets are sent by the supplicant.


    References:

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 7.8: EAPOL Addressing

    https://standards.ieee.org/standard/802_1X-2001.html

Test Module Name Synopsis
Basic case of authenticator initiated authentication eapol.tcl cdrouter_eapol_2 Basic case of authenticator initiated authentication


    step 1. Send EAPOL-Logoff to place controlled port in unauthorized state
    step 2. Initiate ping on LAN port to remote WAN host
    step 3. Continue ping attempts for 120 seconds
    step 4. Verify authentication occurs for the configured type
    step 5. Verify ping is received by remote host on the WAN


    References:

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.4.2.1: Authenticator Initiation

    https://standards.ieee.org/standard/802_1X-2001.html

Test Module Name Synopsis
Basic case of supplicant initiated authentication eapol.tcl cdrouter_eapol_3 Basic case of supplicant initiated authentication


    step 1. Unauthorize supplicant interface
    step 2. Start authentication on supplicant interface
    step 3. Verify authentication occurs for the configured type
    step 4. Verify ping to remote host on the WAN


    References:

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.4.2.2: Supplicant Initiation

    https://standards.ieee.org/standard/802_1X-2001.html

Test Module Name Synopsis
Authenticator sends EAP Failure after supplicant sends EAPOL-Logoff eapol.tcl cdrouter_eapol_6 Authenticator sends EAP Failure after supplicant sends EAPOL-Logoff


    step 1. Send EAPOL-Logoff to place controlled port in unauthorized state
    step 2. Wait up to 15 seconds for EAP Failure packet from Authenticator


    References:

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.4.4: Disconnected

    https://standards.ieee.org/standard/802_1X-2001.html

Test Module Name Synopsis
Authenticator sends EAP Failure if identity is unknown eapol.tcl cdrouter_eapol_8 Authenticator sends EAP Failure if identity is unknown


    step 1. Configure the supplicant to use unknown identity
    step 2. Start authentication on supplicant interface
    step 3. Wait for EAP Identity Request
    step 4. Respond with unknown identity
    step 5. Verify an EAP Failure is received

    NOTE: This test uses the Identity 'badUserName' which must not be a valid
    user name on your back-end authentication server.


    References:

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.8.6: FAIL

    https://standards.ieee.org/standard/802_1X-2001.html

Test Module Name Synopsis
Authenticator sends EAP Failure if authentication challenge fails eapol.tcl cdrouter_eapol_9 Authenticator sends EAP Failure if authentication challenge fails


    step 1. Configure the supplicant to use known identity
    step 2. Start authentication on supplicant interface
    step 3. Wait for EAP Identity Request
    step 4. Respond with known identity
    step 5. Wait for EAP authentication challenge (MD5, TLS, PEAP, SIM, etc)
    step 6. Respond with authentication data that fails challenge
    step 7. Verify an EAP Failure is received


    References:

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.8.6: FAIL

    https://standards.ieee.org/standard/802_1X-2001.html

Test Module Name Synopsis
Authenticator retransmits EAP Identity Request if no response is received eapol.tcl cdrouter_eapol_20 Authenticator retransmits EAP Identity Request if no response is received


    step 1. Unauthorize supplicant interface
    step 2. Start authentication on supplicant interface
    step 3. Wait txWhen seconds for EAP Identity Request
    step 4. Do not respond
    step 5. Wait txWhen seconds for EAP Identity Request
    step 6. Repeat up to reAuthMax attempts


    References:

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.4.5: Connecting

    https://standards.ieee.org/standard/802_1X-2001.html

Test Module Name Synopsis
Authenticator uses same EAP identifier for each retransmitted identity request eapol.tcl cdrouter_eapol_21 Authenticator uses same EAP identifier for each retransmitted identity request


    step 1. Unauthorize supplicant interface
    step 2. Start authentication on supplicant interface
    step 3. Wait txWhen seconds for EAP Identity Request
    step 4. Do not respond
    step 5. Wait txWhen seconds for EAP Identity Request
    step 6. Verify the EAP identifier does not change
    step 7. Repeat up to reAuthMax attempts

    NOTE: After the authenticator enters the Disconnected state, it should
    transition back to the Connecting state. Once in the Connecting state, the
    authenticator should reuse the current ID each time the EAP Idenitity
    request is retransmitted.

    NOTE: The test checks that identifier does not change. It is possible that
    some EAP Identity packets are not received during the disassociate and
    reconnect process.


    References:

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.4.4: Disconnected

    https://standards.ieee.org/standard/802_1X-2001.html

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.4.5: Connecting

    https://standards.ieee.org/standard/802_1X-2001.html

Test Module Name Synopsis
Authenticator ignores EAP Identity Responses with unknown id field eapol.tcl cdrouter_eapol_23 Authenticator ignores EAP Identity Responses with unknown id field


    step 1. Unauthorize supplicant interface
    step 2. Start authentication on supplicant interface
    step 3. Wait txWhen seconds for EAP RetryIdentity Request
    step 4. Respond with EAP Identity Response with mismatched Id field
    step 5. Verify Authenticator resends EAP Identity Request
    step 6. Verify the EAP identifier does not change
    step 7. Repeat up to reAuthMax attempts


    References:

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.4.5: Connecting

    https://standards.ieee.org/standard/802_1X-2001.html

Test Module Name Synopsis
Authenticator enters the held state after authentication is rejected eapol.tcl cdrouter_eapol_24 Authenticator enters the held state after authentication is rejected


    step 1. Configure the supplicant with bad authentication data (password/cert)
    step 2. Send EAPOL-Start
    step 3. Wait for EAP Identity Request
    step 4. Respond with identity
    step 5. Wait for authentication challenge
    step 6. Send bad authentication data (bad md5, invalid cert, etc)
    step 5. Verify an EAP Failure is received
    step 6. Authenticator should move to the HELD state
    step 7. Continue to send EAPOL-Start packets
    step 8. Verify no EAP Identity Request is received under the quietWhile
            timer expires


    References:

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.4.6: Authenticating

    https://standards.ieee.org/standard/802_1X-2001.html

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.4.9: Held

    https://standards.ieee.org/standard/802_1X-2001.html

Test Module Name Synopsis
No packets are forwarded/processed when port is in unauthorized state eapol.tcl cdrouter_eapol_100 No packets are forwarded/processed when port is in unauthorized state


    step 1. Unauthorize supplicant interface
    step 2. Send ARP request for router's LAN IP address
    step 3. Verify no response is received
    step 4. Send ping to remoteHost on WAN using PAE group MAC address
    step 5. Verify ping is not forwarded to WAN
    step 6. Send ping to remoteHost on LAN using broadcast MAC address
    step 7. Verify ping is not forwarded to WAN
    step 8. Bring authenticator to the CONNECTING state
    step 9. Repeat forwarding tests and verify no packets are forwarded
    step 10. Bring authenticator to the AUTHENTICATING state
    step 11. Repeat forwarding tests and verify no packets are forwarded


    References:

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.1: Purpose

    https://standards.ieee.org/standard/802_1X-2001.html

Test Module Name Synopsis
Inbound traffic is blocked when port is in unauthorized state eapol.tcl cdrouter_eapol_105 Inbound traffic is blocked when port is in unauthorized state


    step 1. Bring port to authenticated state
    step 2. Initiate traffic to remote host on WAN
    step 3. Verify packet is received on the WAN
    step 4. Initiate traffic from WAN host back to LAN host
    step 5. Verify packet is received on the LAN
    step 6. Unauthorize controlled port
    step 7. Do not respond to any EAP request
    step 8. Initiate traffic from WAN host back to LAN host
    step 9. Verify traffic is not forwarded to LAN


    References:

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.1: Purpose

    https://standards.ieee.org/standard/802_1X-2001.html

Test Module Name Synopsis
Packets are forwarded during reauthentication if port is in authenticated state eapol.tcl cdrouter_eapol_110 Packets are forwarded during reauthentication if port is in authenticated state


    step 1. Send EAPOL-Logoff to place controlled port in unauthorized state
    step 2. Bring port to authenticated state
    step 3. Send EAPOL-Start to initiate reauthentication process
    step 4. Send ARP request for router's LAN IP address
    step 5. Verify ARP response is received
    step 6. Send ping to remoteHost on WAN
    step 7. Verify ping response is received on LAN


    References:

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.4.5: Connecting

    https://standards.ieee.org/standard/802_1X-2001.html

Test Module Name Synopsis
Port is placed in unauthenticated state if reauthentication fails (bad identity) eapol.tcl cdrouter_eapol_112 Port is placed in unauthenticated state if reauthentication fails (bad identity)


    step 1. Unauthorize supplicant interface
    step 2. Start authentication with valid identity
    step 3. Verify authentication succeeds
    step 4. Restart authentication using an unknown identity
    step 5. Verify authentication fails
    step 6. Send ARP request for router's LAN IP address
    step 7. Verify no response is received
    step 8. Send UDP packet to remoteHost on WAN
    step 9. Verify UDP packet is not forwarded to LAN


    References:

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.4.6: Authenticating

    https://standards.ieee.org/standard/802_1X-2001.html

Test Module Name Synopsis
Port is placed in unauthorized state if reauthentication fails (bad auth) eapol.tcl cdrouter_eapol_113 Port is placed in unauthorized state if reauthentication fails (bad auth)


    step 1. Unauthorize supplicant interface
    step 2. Start authentication with valid identity
    step 3. Verify authentication succeeds
    step 4. Restart authentication using an bad authentication data (md5/tls)
    step 5. Verify authentication fails
    step 6. Send UDP packet to remoteHost on WAN
    step 7. Verify UDP packet is not forwarded to LAN


    References:

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.4.6: Authenticating

    https://standards.ieee.org/standard/802_1X-2001.html

Test Module Name Synopsis
Port becomes unauthorized if no response to EAP Identity request is received eapol.tcl cdrouter_eapol_115 Port becomes unauthorized if no response to EAP Identity request is received


    step 1. Unauthorize supplicant interface
    step 2. Start authentication on supplicant interface
    step 3. Verify authentication succeeds
    step 4. Restart authentication on supplicant interface
    step 5. Do not respond to any EAP packets
    step 6. Wait for all EAP Identity Requests to timeout
    step 7. Verify port is not in unauthorized state


    References:

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.4.5: Connecting

    https://standards.ieee.org/standard/802_1X-2001.html

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.8.7: Timeout

    https://standards.ieee.org/standard/802_1X-2001.html

Test Module Name Synopsis
EAP Success packets from supplicant do not authorize port eapol.tcl cdrouter_eapol_117 EAP Success packets from supplicant do not authorize port


    step 1. Unauthorize supplicant interface
    step 2. Start authentication on supplicant interface
    step 3. Respond to identity request
    step 4. Wait for EAP Request to begin authenticating process
    step 5. Send EAP Success using ID from EAP Request
    step 6. Send ARP request to LAN interface of router
    step 7. Verify no ARP response is received
    step 8. Send ping to remoteHost on WAN
    step 9. Verify ping is not forwarded to WAN

    NOTE: The Authenticator should not authorize the port when an EAP-Success
    packet is received from the supplicant. This packet is normally relayed to
    the Back-end to process. Some implementations will reject the relayed
    EAP-Success as an invalid packet and send an EAP-Failure.


    References:

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.4.7: Relaying EAP Frames

    https://standards.ieee.org/standard/802_1X-2001.html

Test Module Name Synopsis
Authenticator initiates reauthentication with supplicant every reAuthPeriod eapol.tcl cdrouter_eapol_130 Authenticator initiates reauthentication with supplicant every reAuthPeriod


    step 1. Unauthorize supplicant interface
    step 2. Initiate EAP authentication
    step 3. Verify authentication succeeds
    step 4. Wait up to reAuthPeriod seconds for authenticator to reauthenticate
    step 5. Verify reauthentication occurs within reAuthPeriod

    NOTE: The EAP reAuthPeriod interval is configured using the
    'eapReAuthPeriod' testvar. The default interval is 3600 seconds. If the
    'eapReAuthPeriod' testvar is set to 0, this test will be skipped.


    References:

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.7: Reauthentication Timer state machine

    https://standards.ieee.org/standard/802_1X-2001.html

Test Module Name Synopsis
Port is placed in unauthorized state if 802.11 layer is reinitialized eapol.tcl cdrouter_eapol_140 Port is placed in unauthorized state if 802.11 layer is reinitialized


    step 1. Unauthorize supplicant interface
    step 2. Start authentication with valid identity
    step 3. Verify authentication succeeds
    step 4. Reassociate to AP with out performing authentication.
            (This will cause the 802.11 layer to reset)
    step 5. Do not respond to any EAP requests
    step 6. Send ping to remote host on WAN
    step 7. Verify the ping fails
    step 8. Start authentication on supplicant interface
    step 9. Verify authentication succeeds
    step 10. Send ping to remote host on WAN
    step 11. Verify the ping succeeds


    References:

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.4.2: Authentication initiation

    https://standards.ieee.org/standard/802_1X-2001.html

Test Module Name Synopsis
Verify supplicant can login using all configured Identities eapol.tcl cdrouter_eapol_300 Verify supplicant can login using all configured Identities


    step 1. Unauthorize supplicant interface
    step 2. For each configured EAP Identity
    step 3. Configure the supplicant to use the next Identity
    step 4. Start authentication on supplicant interface
    step 5. Verify successful authentication occurs


    References:

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.4: Protocol Operation

    https://standards.ieee.org/standard/802_1X-2001.html

Test Module Name Synopsis
Authenticator handles EAP Start flood DoS attack eapol.tcl cdrouter_eapol_500 Authenticator handles EAP Start flood DoS attack


    step 1. Flood 100 EAPOL-Start packets
    step 2. Send ping to host on the WAN to verify port is operational
    step 3. Verify ping is received


    References:

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control"

    https://standards.ieee.org/standard/802_1X-2001.html

Test Module Name Synopsis
Authenticator handles EAP Logoff flood DoS attack eapol.tcl cdrouter_eapol_501 Authenticator handles EAP Logoff flood DoS attack


    step 1. Flood 100 EAPOL-Logoff packets
    step 2. Send ping to host on the WAN to verify port is operational
    step 3. Verify ping is received


    References:

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control"

    https://standards.ieee.org/standard/802_1X-2001.html

Test Module Name Synopsis
Authenticator handles EAP-of-Death DoS attack eapol.tcl cdrouter_eapol_502 Authenticator handles EAP-of-Death DoS attack


    step 1. Start authentication on supplicant interface
    step 2. Wait for EAP Request Identity packet
    step 3. Respond with EAP Identity Reply with length field = 0xffff
    step 4. Repeat step 2 and 3
    step 5. Start authentication on supplicant interface with normal behavior
    step 6. Verify normal authentication occurs
    step 7. Verify LAN port can ping remote host on WAN

    NOTE: The length field for an EAP packet is 2 bytes. This allows
    a maximum EAP packet size of 0xffff. However, EAPOL can only carry
    EAP packets with a length less than the Ethernet MTU. This test
    verifies that the authenticator handles these invalid packets
    gracefully.


    References:

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control"

    https://standards.ieee.org/standard/802_1X-2001.html

    IETF RFC 2284 "PPP Extensible Authentication Protocol (EAP)"

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

Test Module Name Synopsis
Back-end flood DoS attack eapol.tcl cdrouter_eapol_503 Back-end flood DoS attack


    step 1. Unauthorize supplicant interface
    step 2. Start authentication on supplicant interface
    step 3. Respond to identity request
    step 4. Wait for EAP Request to begin authenticating process
    step 5. Flood back-end with 100 EAP Responses with invalid authentication data
    step 6. Start authentication on supplicant interface with normal behavior
    step 7. Verify normal authentication occurs
    step 8. Verify LAN port can ping remote host on WAN

    NOTE: This test trys to exploit the EAP relay beahvior of the authenticator.
    Once the EAP session reaches the authentication stage, the supplicant will
    flood the back-end with EAP Response which should be handled gracefully by
    the Authenticator and back-end.


    References:

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control"

    https://standards.ieee.org/standard/802_1X-2001.html


eap-md5.tcl

EAPOL tests specific to EAP-MD5

Test Module Name Synopsis
Authenticator sends EAP Failure if MD5 Challenge Response is invalid eap-md5.tcl cdrouter_eapmd5_10 Authenticator sends EAP Failure if MD5 Challenge Response is invalid


    step 1. Send EAPOL-Start
    step 2. Wait for EAP Identity Request
    step 3. Respond with known identity
    step 4. Wait for EAP authentication MD5 Challenge Request
    step 5. Respond with valid authentication value, but include different
            EAP Identity after the MD5 Challenge Response
    step 6. Verify an EAP Failure is received


    References:

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.8.6: FAIL

    https://standards.ieee.org/standard/802_1X-2001.html

Test Module Name Synopsis
Authenticator sends EAP Failure if no response to EAP MD5 Challenge Request is received eap-md5.tcl cdrouter_eapmd5_20 Authenticator sends EAP Failure if no response to EAP MD5 Challenge Request is received


    step 1. Send EAPOL-Logoff to place controlled port in unauthorized state
    step 2. Bring authenticator to the AUTHENTICATING state
    step 3. Wait txWhen seconds for EAP MD5 Challenge Request
    step 4. Do not respond
    step 5. Verify authenticator sends an EAP Failure


    References:

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.8.7: Timeout

    https://standards.ieee.org/standard/802_1X-2001.html

Test Module Name Synopsis
Authenticator ignores EAP MD5 Responses with unknown id field eap-md5.tcl cdrouter_eapmd5_23 Authenticator ignores EAP MD5 Responses with unknown id field


    step 1. Send EAPOL-Logoff to place controlled port in unauthorized state
    step 2. Bring authenticator to the AUTHENTICATING state
    step 3. Wait txWhen seconds for EAP MD5 Challenge Request
    step 4. Respond with EAP MD5 Challenge Response with mismatched Id field
    step 5. Verify Authenticator does not send EAP Success

    NOTE: This test verifies that the Backend Authentication State machine
    checks the EAP Challenge Response identifier to verify that it matches the
    request identifier. Some implementations will silently ignore a mismatch and
    eventually trigger a TIMEOUT. Other implementations will generate an EAP
    Failure message. This test only verifies that the Backend does not generate
    an EAP Success.


    References:

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.8.3: REQUEST

    https://standards.ieee.org/standard/802_1X-2001.html

Test Module Name Synopsis
Authenticator handles EAP MD5 Challenge Request DoS attack eap-md5.tcl cdrouter_eapmd5_500 Authenticator handles EAP MD5 Challenge Request DoS attack


    step 1. Send EAPOL-Start
    step 2. Wait for EAP Identity request
    step 3. Respond with known identity
    step 4. Wait for EAP authentication MD5 Challenge Request
    step 5. Respond with bad authentication length
    step 6. Repeat for 200 MD5 Challenge Requests

    Reference: IEEE Std 802.1X-2001

    NOTE: In this DoS attach, the MD5 Challenge Response is returned with a
    value length of 255. However, only 16 bytes of the actual MD5 value are
    included. The Backend Authentication server must handle the parsing failure
    of the packet.


    References:

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control"

    https://standards.ieee.org/standard/802_1X-2001.html


eap-tls.tcl

EAPOL tests specific to EAP-TLS

Test Module Name Synopsis
Authenticator sends EAP Failure when TLS client fails to authenticate server eap-tls.tcl cdrouter_eaptls_10 Authenticator sends EAP Failure when TLS client fails to authenticate server


    step 1. Start authentication on supplicant interface
    step 2. Wait for EAP Identity Request
    step 3. Respond with known identity
    step 4. Wait for EAP-TLS Start
    step 5. Complete TLS session using invalid root CA certificate
    step 6. Verify an EAP Failure is received


    References:

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.8.6: FAIL

    https://standards.ieee.org/standard/802_1X-2001.html

    IETF RFC 2716 "PPP EAP TLS Authentication Protocol" Section 3.1: Overview of the EAP-TLS conversation

    https://tools.ietf.org/html/rfc2716#section-3.1

Test Module Name Synopsis
Authenticator sends EAP Failure when TLS server fails to authenticate client eap-tls.tcl cdrouter_eaptls_12 Authenticator sends EAP Failure when TLS server fails to authenticate client


    step 1. Start authentication on supplicant interface
    step 2. Wait for EAP Identity Request
    step 3. Respond with known identity
    step 4. Wait for EAP-TLS Start
    step 5. Complete TLS session using invalid client certificate
    step 6. Verify an EAP Failure is received


    References:

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.8.6: FAIL

    https://standards.ieee.org/standard/802_1X-2001.html

    IETF RFC 2716 "PPP EAP TLS Authentication Protocol" Section 3.1: Overview of the EAP-TLS conversation

    https://tools.ietf.org/html/rfc2716#section-3.1

Test Module Name Synopsis
Port becomes unauthorized if no response to EAP-TLS Start request is received eap-tls.tcl cdrouter_eaptls_20 Port becomes unauthorized if no response to EAP-TLS Start request is received


    step 1. Unauthorize supplicant interface
    step 2. Bring authenticator to the AUTHENTICATING state
    step 3. Wait txWhen seconds for EAP-TLS Start request
    step 4. Do not respond
    step 5. Wait for EAP-TLS Start to be retransmitted up to
            eapReAuthMax times
    step 6. Verify port is not in unauthorized state


    References:

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.8.7: Timeout

    https://standards.ieee.org/standard/802_1X-2001.html

Test Module Name Synopsis
Authenticator ignores EAP-TLS Response with unknown id field eap-tls.tcl cdrouter_eaptls_23 Authenticator ignores EAP-TLS Response with unknown id field


    step 1. Unauthorize supplicant interface
    step 2. Bring authenticator to the AUTHENTICATING state
    step 3. Wait txWhen seconds for EAP-TLS Request
    step 4. Respond with EAP-TLS Response with mismatched Id field
    step 5. Verify Authenticator does not send EAP Success

    NOTE: This test verifies that the Backend Authentication State machine
    checks the EAP Response identifier to verify that it matches the request
    identifier. Some implementations will silently ignore a mismatch and
    eventually trigger a TIMEOUT. Other implementations will generate an EAP
    Failure message. This test only verifies that the Backend does not generate
    an EAP Success.


    References:

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.8.3: REQUEST

    https://standards.ieee.org/standard/802_1X-2001.html

Test Module Name Synopsis
Backend sends TLS Alert if supplicant fails server TLS authentication eap-tls.tcl cdrouter_eaptls_40 Backend sends TLS Alert if supplicant fails server TLS authentication


    step 1. Unauthorize supplicant interface
    step 2. Start authentication on supplicant interface
    step 3. Send invalid user certification during TLS exchange
    step 4. Verify TLS server returns TLS Alert
    step 5. Verify Backend returns an EAP-Failure
    step 6. Send ping to remote host on WAN
    step 7. Verify ping is not forwarded to WAN


    References:

    IETF RFC 2716 "PPP EAP TLS Authentication Protocol" Section 3.1: Overview of the EAP-TLS conversation

    https://tools.ietf.org/html/rfc2716#section-3.1

Test Module Name Synopsis
Port becomes unauthorized if TLS session times out eap-tls.tcl cdrouter_eaptls_115 Port becomes unauthorized if TLS session times out


    step 1. Unauthorize supplicant interface
    step 2. Start authentication on supplicant interface
    step 3. Verify authentication succeeds
    step 4. Restart authentication
    step 5. Do not respond to TLS after receiving server certificate
    step 6. Wait for all EAP TLS Requests to timeout
    step 7. Verify port is not in unauthorized state


    References:

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.4.5: Connecting

    https://standards.ieee.org/standard/802_1X-2001.html

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.8.7: Timeout

    https://standards.ieee.org/standard/802_1X-2001.html

Test Module Name Synopsis
EAP-TLS authenticator/backend ignores duplicate EAP-TLS packets eap-tls.tcl cdrouter_eaptls_300 EAP-TLS authenticator/backend ignores duplicate EAP-TLS packets


    step 1. Configure supplicant to send duplicate EAP packets
    step 2. Unauthorize supplicant interface
    step 3. Start authentication on supplicant interface
    step 4. Verify EAP-TLS authentication succeeds


    References:

    IETF RFC 2716 "PPP EAP TLS Authentication Protocol" Section 3.2: Retry behavior

    https://tools.ietf.org/html/rfc2716#section-3.2

Test Module Name Synopsis
EAP-TLS authentication using small EAP Fragment sizes eap-tls.tcl cdrouter_eaptls_400 EAP-TLS authentication using small EAP Fragment sizes


    step 1. Unauthorize supplicant interface
    step 2. Start authentication on supplicant interface
    step 3. Set the EAP Fragment size to 10
    step 4. Verify EAP-TLS Authentication succeeds
    step 5. Repeat for EAP Fragment sizes 9,8,7,6

    NOTE: Some Backend servers and internal authentication implementations will
    timeout with small EAP Fragment sizes such as 1. With this size, the
    authentication server is not able to read an entire EAP-TLS message before
    the txWhen timer fires on the server. The server then restarts the TLS
    session with a EAP Request/TLS-Start. This test starts with an EAP Fragment
    size of 10 and attempts to lower the fragment size to 6 bytes.


    References:

    IETF RFC 2716 "PPP EAP TLS Authentication Protocol" Section 3.3: Fragmentation

    https://tools.ietf.org/html/rfc2716#section-3.3

Test Module Name Synopsis
EAP-TLS backend accepts EAP packets without EAP-TLS Message Length field eap-tls.tcl cdrouter_eaptls_410 EAP-TLS backend accepts EAP packets without EAP-TLS Message Length field


    step 1. Unauthorize supplicant interface
    step 2. Start authentication on supplicant interface
    step 3. Configure supplicant to not send EAP-TLS message length for
            EAP-TLS packets smaller than the EAP-TLS fragmentation setting
    step 4. Wait for EAP-TLS Start
    step 5. Send initial EAP-TLS packets without including message length
    step 6. Verify EAP-TLS authentication succeeds

    NOTE: For EAP-TLS packets that are less than the EAP fragment size, the
    EAP-TLS Message Length field is optional.


    References:

    IETF RFC 2716 "PPP EAP TLS Authentication Protocol" Section 3.3: Fragmentation

    https://tools.ietf.org/html/rfc2716#section-3.3

Test Module Name Synopsis
Authenticator handles EAP-TLS bad length DoS attack eap-tls.tcl cdrouter_eaptls_500 Authenticator handles EAP-TLS bad length DoS attack


    step 1. Unauthorize supplicant interface
    step 2. Start authentication on supplicant interface
    step 3. Wait for EAP Identity request
    step 4. Respond with known identity
    step 5. Wait for EAP-TLS Start Request
    step 6. Respond with bad TLS message (Flags 0xc0 with no length or data)
    step 7. Repeat for 10 EAP-TLS Start Requests


    References:

    IETF RFC 2716 "PPP EAP TLS Authentication Protocol" Section 3.3: Fragmentation

    https://tools.ietf.org/html/rfc2716#section-3.3

    IETF RFC 2716 "PPP EAP TLS Authentication Protocol" Section 4.3: EAP-TLS Response Packet

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


eap-radius.tcl

RADIUS client tests for EAP based authentication (802.1X)

Test Module Name Synopsis
Verify authenticator sends EAP-Success after receiving Access-Accept eap-radius.tcl eapradius_1 Verify authenticator sends EAP-Success after receiving Access-Accept


    step 1. Unauthorize supplicant interface
    step 2. Start authentication on supplicant interface
    step 3. Wait for RADIUS packet sent to authentication server
    step 4. Respond with Access-Accept message that includes an EAP-Success
            packet as the EAP Message
    step 5. Verify supplicant receives EAP-Success packet

    Note: This test does use any specific type of EAP authentication. The RADIUS
    server immediately returns an EAP-Success packet to the authenticator without
    going through the request for a specific EAP type.


    References:

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.8.4: Response

    https://standards.ieee.org/standard/802_1X-2001.html

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.8.5: Success

    https://standards.ieee.org/standard/802_1X-2001.html

Test Module Name Synopsis
Verify authenticator sends EAP-Failure after Access-Reject eap-radius.tcl eapradius_2 Verify authenticator sends EAP-Failure after Access-Reject


    step 1. Unauthorize supplicant interface
    step 2. Start authentication on supplicant interface
    step 3. Wait for RADIUS packet sent to authentication server
    step 4. Respond with Access-Reject message that includes an EAP-Failure
            packet as the EAP Message
    step 5. Wait 60 seconds for supplicant to receive EAP Failure

    Note: This test does use any specific type of EAP authentication. The RADIUS
    server immediately returns an EAP-Failure packet to the authenticator without
    going through the request for a specific EAP type.


    References:

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.8.4: Response

    https://standards.ieee.org/standard/802_1X-2001.html

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.8.6: Fail

    https://standards.ieee.org/standard/802_1X-2001.html

Test Module Name Synopsis
Validate common RADIUS attributes sent from authenticator eap-radius.tcl eapradius_5 Validate common RADIUS attributes sent from authenticator


    step 1. Start authentication on supplicant interface
    step 2. Wait for RADIUS packet sent to authentication server
    step 3. Verify the Calling-Station-Id attribute is correct
    step 4. Verify the Called-Station-Id attribute is present (WARNING only)
    step 5. Verify the Message-Authenticator attribute is present
    step 6. Verify the NAS-Identifier is present (WARNING only)
    step 7. Verify the NAS-Port-Type is present (WARNING only)


    References:

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section D.3: RADIUS authentication

    https://standards.ieee.org/standard/802_1X-2001.html

Test Module Name Synopsis
Verify authentication fails if RADIUS secret is invalid eap-radius.tcl eapradius_6 Verify authentication fails if RADIUS secret is invalid


    step 1. Start authentication on supplicant interface
    step 2. Configure RADIUS server to send packets with invalid RADIUS secret.
            The Message-Authenticator attribute will still be calculated using
            the original shared secret.
    step 3. Verify authentication does not succeed


    References:

    IETF RFC 2138 "Remote Authentication Dial In User Service (RADIUS)" Section 2: Operation

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

Test Module Name Synopsis
Verify authentication fails if Message-Authenticator attribute is invalid eap-radius.tcl eapradius_7 Verify authentication fails if Message-Authenticator attribute is invalid


    step 1. Start authentication on supplicant interface
    step 2. Configure RADIUS server to send packets with invalid
            Message-Authenticator attribute. The RADIUS authenticator
            will still be calculated using the original shared secret.
    step 3. Verify authentication does not succeed


    References:

    IETF RFC 2138 "Remote Authentication Dial In User Service (RADIUS)" Section 2: Operation

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

Test Module Name Synopsis
Verify ID and authenticator are unique for each new Access-Request eap-radius.tcl eapradius_8 Verify ID and authenticator are unique for each new Access-Request


    step 1. Start authentication on supplicant interface
    step 2. Save RADIUS request ID and request authenticator from each RADIUS
            Access-Request packet
    step 3. Verify authentication succeeds
    step 4. Verify the ID in each RADIUS Request is unique
    step 5. Verify the Request authenticator in also unique


    References:

    IETF RFC 2138 "Remote Authentication Dial In User Service (RADIUS)" Section 4.1: Access-Request

    https://tools.ietf.org/html/rfc2138#section-4.1

Test Module Name Synopsis
Verify authenticator sends EAP-Failure when no response from RADIUS in unauthenticated state eap-radius.tcl eapradius_9 Verify authenticator sends EAP-Failure when no response from RADIUS in unauthenticated state


    step 1. Unauthorize supplicant interface
    step 2. Start authentication on supplicant interface
    step 3. Wait for RADIUS packet sent to authentication server
    step 4. Do not response
    step 5. Verify EAP-Failure is sent to supplicant


    References:

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section 8.5.8.4: Response

    https://standards.ieee.org/standard/802_1X-2001.html

Test Module Name Synopsis
Verify authenticator can reassemble EAP packets from many RADIUS eapMessage attributes eap-radius.tcl eapradius_10 Verify authenticator can reassemble EAP packets from many RADIUS eapMessage attributes


    step 1. Start authentication on supplicant interface
    step 2. Configure Authentication server to send 10 bytes of a
            EAP message in each RADIUS eapMessage attribute resulting
            in many EAP Message attributes in each RADIUS packet
    step 3. Verify authentication succeeds


    References:

    IETF RFC 2869 "RADIUS Extensions" Section 5.13: EAP-Message

    https://tools.ietf.org/html/rfc2869#section-5.13

Test Module Name Synopsis
Verify authenticator ignores RADIUS messages with invalid attribute list eap-radius.tcl eapradius_12 Verify authenticator ignores RADIUS messages with invalid attribute list


    step 1. Unauthorize supplicant interface
    step 2. Start authentication on supplicant interface
    step 3. Wait for RADIUS packet sent to authentication server
    step 4. Respond with invalid attribute list containing bad eapMessage and
            additional attribute with no length or data
    step 5. Restart authentication on supplicant
    step 6. Verify authentication succeeds

    NOTE: This test verifies that the authenticator can recover after
    it receives a RADIUS packet with a bad attribute list. Some devices
    have experience a fault when they attempt to parse the bad
    RADIUS attribute list.


    References:

    IETF RFC 2869 "RADIUS Extensions" Section 5.13: EAP-Message

    https://tools.ietf.org/html/rfc2869#section-5.13

Test Module Name Synopsis
Verify authenticator ignores RADIUS messages without a Message-Authenticator attribute eap-radius.tcl eapradius_14 Verify authenticator ignores RADIUS messages without a Message-Authenticator attribute


    step 1. Start authentication on supplicant interface
    step 2. Configure Authentication server so that the
            Message-Authenticator attribute will not be sent in any
            RADIUS replies
    step 3. Verify authentication fails

    NOTE: RFC 2869 recommends that the RADIUS client SHOULD silently
    drop packets from the RADIUS server containing EAP-Message attribute
    if the Message-Authenticator attribute is not included.


    References:

    IETF RFC 2869 "RADIUS Extensions" Section 5.13: EAP-Message

    https://tools.ietf.org/html/rfc2869#section-5.13

Test Module Name Synopsis
Verify authenticator sends canned EAP-Failure message when Access-Reject is received eap-radius.tcl eapradius_20 Verify authenticator sends canned EAP-Failure message when Access-Reject is received


    step 1. Unauthorize supplicant interface
    step 2. Start authentication on supplicant interface
    step 3. Wait for RADIUS packet sent to authentication server
    step 4. Respond with Access-Reject message that includes an EAP-Success
            packet as the EAP Message
    step 5. Verify supplicant receives EAP Failure


    References:

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section D.4: Security considerations

    https://standards.ieee.org/standard/802_1X-2001.html

Test Module Name Synopsis
Verify authenticator sends canned EAP-Success message when Access-Accept is received eap-radius.tcl eapradius_21 Verify authenticator sends canned EAP-Success message when Access-Accept is received


    step 1. Unauthorize supplicant interface
    step 2. Start authentication on supplicant interface
    step 3. Wait for RADIUS packet sent to authentication server
    step 4. Respond with Access-Accept message that includes an EAP-Failure
            packet as the EAP Message
    step 5. Verify supplicant receives EAP-Success


    References:

    IEEE 802.1X-2001 "IEEE Standard for Port Based Network Access Control" Section D.4: Security considerations

    https://standards.ieee.org/standard/802_1X-2001.html


pppoe-pt.tcl

PPPoE pass through from PPPoE client on LAN to WAN side PPPoE server

Test Module Name Synopsis
Verify basic case of PPPoE pass through with LAN PPPoE client pppoe-pt.tcl cdrouter_pppoept_1 Verify basic case of PPPoE pass through with LAN PPPoE client


    step 1. Start a new PPPoE server on the WAN
    step 2. Initiate a PPPoE client session from a host on the LAN
    step 3. Verify the PPPoE client can establish a PPPoE session
    step 4. Verify the PPPoE client can bring up the PPP link
    step 5. Close the PPP and PPPoE session

    NOTE: In order to pass this test, the device must support PPPoE
    pass through for PPPoE clients on the LAN.


    References:

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

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

Test Module Name Synopsis
Verify PPPoE packets to unknown MAC address do not use PPPoE pass through pppoe-pt.tcl cdrouter_pppoept_2 Verify PPPoE packets to unknown MAC address do not use PPPoE pass through


    step 1. Start a new PPPoE server on the WAN
    step 2. Initiate a PPPoE client session from a host on the LAN
    step 3. Verify the PPPoE client can establish a PPPoE session
    step 4. Verify the PPPoE client can bring up the PPP link
    step 5. Send PPPoE packet from WAN to LAN using an unknown MAC address
    step 6. Verify the PPPoE packet is not forwarded onto the LAN
    step 7. Close the PPP and PPPoE session for the existing PPPoE session

    NOTE: In order to pass this test, the device must support PPPoE
    pass through for PPPoE clients on the LAN.


    References:

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

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

Test Module Name Synopsis
Verify basic case of PPPoE pass through with LAN PPPoE client using random session ID's pppoe-pt.tcl cdrouter_pppoept_3 Verify basic case of PPPoE pass through with LAN PPPoE client using random session ID’s


    step 1. Start a new PPPoE server on the WAN configured to use random session ID's
    step 2. Initiate a PPPoE client session from a host on the LAN
    step 3. Verify the PPPoE client can establish a PPPoE session
    step 4. Verify the PPPoE client can bring up the PPP link
    step 5. Close the PPP and PPPoE session

    NOTE: In order to pass this test, the device must support PPPoE
    pass through for PPPoE clients on the LAN.


    References:

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

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


ipsec-esp.tcl

IPSEC ESP tests for IPSEC based VPNs

Test Module Name Synopsis
Verify the ESP header sequence number increases with each new IPv4 IPSEC ESP packet ipsec-esp.tcl cdrouter_esp_1 Verify the ESP header sequence number increases with each new IPv4 IPSEC ESP packet


    step 1. Initiate 100 outbound ICMP Echo Requests to the remote VPN host
    step 2. Outbound traffic should be sent through IPSEC tunnel
    step 3. Verify the sequence number in the IPSEC ESP header increments by 1


    References:

    IETF RFC 2406 "IP Encapsulating Security Payload (ESP)" Section 2.2: Sequence Number

    https://tools.ietf.org/html/rfc2406#section-2.2

Test Module Name Synopsis
Verify manual IPSEC keys continue to work after ESP sequence number wraps ipsec-esp.tcl cdrouter_esp_3 Verify manual IPSEC keys continue to work after ESP sequence number wraps


    step 1. Set the current sequence number for the outbound SA to 0xfffffffe
    step 2. Initiate 10 outbound ICMP Echo Requests to the remote VPN host
    step 3. Outbound traffic should be sent through IPSEC tunnel
    step 4. Verify all packets are received as IPSEC ESP sequence number wraps


    References:

    IETF RFC 2406 "IP Encapsulating Security Payload (ESP)" Section 5: Conformance Requirements

    https://tools.ietf.org/html/rfc2406#section-5

Test Module Name Synopsis
Verify no anti-relay techniques are used with manual IPSEC keys ipsec-esp.tcl cdrouter_esp_5 Verify no anti-relay techniques are used with manual IPSEC keys


    step 1. Initiate 10 outbound ICMP Echo Requests to the remote host
    step 2. Before each packet is sent, reset the ESP sequence number
            to 11221122 so that all outbound packets have the same
            sequence number.
    step 3. Outbound traffic should be sent through IPSEC tunnel
    step 4. Verify all packets are sent and received with no errors


    References:

    IETF RFC 2406 "IP Encapsulating Security Payload (ESP)" Section 5: Conformance Requirements

    https://tools.ietf.org/html/rfc2406#section-5

Test Module Name Synopsis
Verify inner IPv4 TTL is decremented for IPSEC tunneled packet ipsec-esp.tcl cdrouter_esp_8 Verify inner IPv4 TTL is decremented for IPSEC tunneled packet


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


    References:

    IETF RFC 2401 "Security Architecture for the Internet Protocol" Section 5.1.2: Header Construction for Tunnel Mode

    https://tools.ietf.org/html/rfc2401#section-5.1.2

Test Module Name Synopsis
Verify packets with wrong ESP authentication are dropped ipsec-esp.tcl cdrouter_esp_10 Verify packets with wrong ESP authentication are dropped


    step 1. Initiate an outbound ICMP Echo Request to a WAN destination
    step 2. Verify ICMP Echo Reply is received
    step 3. Configure outbound SA with invalid authentication key
    step 4. Repeat outbound ICMP Echo Request
    step 5. Verify return ICMP Echo Reply is dropped
    step 6. Reconfigure original ESP authentication key
    step 7. Verify outbound ICMP Echo Request now succeeds

    NOTE: This test is only run when the configured IPSEC tunnel has
    authentication enabled.


    References:

    IETF RFC 2406 "IP Encapsulating Security Payload (ESP)" Section 3.4.5: Packet Decryption

    https://tools.ietf.org/html/rfc2406#section-3.4.5

Test Module Name Synopsis
Verify Incoming IP fragments for ESP tunnel are reassembled ipsec-esp.tcl cdrouter_esp_20 Verify Incoming IP fragments for ESP tunnel are reassembled


    step 1. Set the MTU on the IPSEC tunnel endpoint to 108
    step 2. Send a 1000 byte UDP packet from the LAN to the WAN
    step 3. Send a return 1000 byte UDP packet from the WAN to the LAN
            over the IPSEC tunnel. The IPSEC packet will be fragmented
            based on the MTU size.
    step 4. Verify router reassembled all IP fragments and forwards UDP
            packet to the LAN host
    step 5. Add 8 to the MTU size and repeat the test until the MTU is 996


    References:

    IETF RFC 791 "INTERNET PROTOCOL" Section 3.2: Fragmentation and Reassembly

    https://tools.ietf.org/html/rfc791#section-3.2

    IETF RFC 2401 "Security Architecture for the Internet Protocol" Section 5.2: Processing Inbound IP Traffic

    https://tools.ietf.org/html/rfc2401#section-5.2

    IETF RFC 2406 "IP Encapsulating Security Payload (ESP)" Section 3.1: ESP Header Location

    https://tools.ietf.org/html/rfc2406#section-3.1

Test Module Name Synopsis
Verify out-of-order IP fragments for ESP tunnel are reassembled ipsec-esp.tcl cdrouter_esp_21 Verify out-of-order IP fragments for ESP tunnel are reassembled


    step 1. Set the MTU on the IPSEC tunnel endpoint to 108
    step 2. Send a 1000 byte UDP packet from the LAN to the WAN
    step 3. Send a return 1000 byte UDP packet from the WAN to the LAN
            over the IPSEC tunnel using out of order IP fragments
    step 4. Verify router reassembled all out-of-order IP fragments
            and forwards UDP packet to the LAN host


    References:

    IETF RFC 791 "INTERNET PROTOCOL" Section 3.2: Fragmentation and Reassembly

    https://tools.ietf.org/html/rfc791#section-3.2

    IETF RFC 2406 "IP Encapsulating Security Payload (ESP)" Section 3.1: ESP Header Location

    https://tools.ietf.org/html/rfc2406#section-3.1

Test Module Name Synopsis
Verify router fragments large IP packets before sending over IPSEC tunnel ipsec-esp.tcl cdrouter_esp_22 Verify router fragments large IP packets before sending over IPSEC tunnel


    step 1. Forward UDP packet from LAN host to WAN using 1500 byte packet
    step 2. Verify packet is forwarded over IPSEC tunnel
    step 3. In order to forward the packet over the tunnel, the router must
            fragment the packet.
    step 4. Send a return UDP packet with the same packet size from the WAN
            to the LAN.
    step 5. Reduce the packet size by 1 byte and repeat until the packet size
            is >= 1408.

    NOTE: The router may fragment the inner IP packet before ESP encapsulation
    and send 2 or more ESP packets or the router may fragment the outer ESP
    packet and send IP fragments. The first approach is more NAT friendly since
    IP fragments are not used and this allows other NAT routers in the path
    to use SPI tracking for IPSEC pass through connections. This test case
    supports both implementations.


    References:

    IETF RFC 2406 "IP Encapsulating Security Payload (ESP)" Section 3.3.5: Fragmentation

    https://tools.ietf.org/html/rfc2406#section-3.3.5

Test Module Name Synopsis
Verify router supports PMTU discovery for packets sent over IPSEC tunnel ipsec-esp.tcl cdrouter_esp_100 Verify router supports PMTU discovery for packets sent over IPSEC tunnel


    step 1. Send 1500 byte UDP packet with IP Don't Fragment Flag = 1 to the
            remoteVpn host over the IPSEC tunnel
    step 2. Check for an ICMP Destination Unreachable packet with code = 4
    step 3. Repeat process two more times until until an ICMP Destination
            Unreachable is received, or all 3 packets are sent
    step 4. If an ICMP Destination Unreachable was sent, verify the
            the code value is 4 and verify MTU value in the ICMP header
    step 5. Reduce the UDP packet size by 1 byte and repeat the process
            until no ICMP Destination Unreachable is sent
    step 6. When a packet size is found that does not generate an
            ICMP Destination Unreachable, verify packets can be forwarded over
            IPSEC tunnel using this packet size
    step 7. Verify the final MTU size is the same as the MTU size
            reported in the ICMP Destination Unreachable packet

    NOTE: Some devices rate limit the number of ICMP packets that may be sent.
    This test will sent 3 UDP packets over a 15 second window in order to
    generate an ICMP unreachable packet. If your device uses rate limiting on
    ICMP packets, it must allow at least 1 ICMP packet every 10 seconds.


    References:

    IETF RFC 2401 "Security Architecture for the Internet Protocol" Section 6.1: PMTU/DF Processing

    https://tools.ietf.org/html/rfc2401#section-6.1

    IETF RFC 1191 "Path MTU Discovery"

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

Test Module Name Synopsis
Verify DF bit from original packet is copied to encapsulation header ipsec-esp.tcl cdrouter_esp_101 Verify DF bit from original packet is copied to encapsulation header


    step 1. Send ICMP Echo packet to the remoteVpn with the DF flag set to 1
    step 2. Wait for ESP packet on the WAN for this IPSEC tunnel
    step 3. Verify the DF flag in the ESP header is 1

    NOTE: In order to pass this test, the router may need to configure the
    treatment of the DF bit. The router should be configured to copy the value
    of the DF bit from the inner IP packet. This allows the PMTU behavior to
    work for packets that have been tunneled.


    References:

    IETF RFC 2401 "Security Architecture for the Internet Protocol" Section 6.1: PMTU/DF Processing

    https://tools.ietf.org/html/rfc2401#section-6.1

Test Module Name Synopsis
Verify return traffic that does not use IPSEC/ESP is dropped ipsec-esp.tcl cdrouter_esp_200 Verify return traffic that does not use IPSEC/ESP is dropped


    step 1. Forward UDP packet from LAN to remote VPN host
    step 2. Verify packet is forwarded over IPSEC tunnel to remote VPN host
    step 3. Send a return UDP packet from the remote VPN host without
            encapsulating the packet with an ESP header
    step 4. Verify the packet is not forwarded back to the LAN


    References:

    IETF RFC 2401 "Security Architecture for the Internet Protocol" Section 4.4.1: The Security Policy Database (SPD)

    https://tools.ietf.org/html/rfc2401#section-4.4.1

Test Module Name Synopsis
Verify all configured IPv4 IPSEC tunnels are operational ipsec-esp.tcl cdrouter_esp_400 Verify all configured IPv4 IPSEC tunnels are operational


    step 1. Configure SAs for all IPSEC tunnels defined in the configuration file
    step 2. For each tunnel, verify a TCP connection can be established
            from the LAN host to a remote host over the IPSEC tunnel
    step 3. Close all TCP connections


dmz.tcl

Test cases for DMZ configurations

Test Module Name Synopsis
Inbound TCP connections to public side HTTP port are forwarded to DMZ host dmz.tcl cdrouter_dmz_1 Inbound TCP connections to public side HTTP port are forwarded to DMZ host


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


Test Module Name Synopsis
Inbound TCP packets are sent to DMZ host for all ports dmz.tcl cdrouter_dmz_100 Inbound TCP packets are sent to DMZ host for all ports


    step 1. Ping the router's LAN IP address from the DMZ host
    step 2. Send TCP SYN packets from WAN to each port in the port scan range
    step 3. Verify packets are forwarded to DMZ host
    step 4. Do not test ports that have port forwarding configured

    NOTE: The port scan range can be configured using the 'portScanStart' and
    'portScanStop' testvars. You can also specify any exceptions to the port
    range using the testvar 'lanDmzTcpPortExceptions'.

    Example:

    testvar portScanStart 0
    testvar portScanStop  65535


Test Module Name Synopsis
Inbound UDP packets are sent to DMZ host for all ports dmz.tcl cdrouter_dmz_101 Inbound UDP packets are sent to DMZ host for all ports


    step 1. Ping the router's LAN IP address from the DMZ host
    step 2. Send UDP packets from WAN to each port in the port scan range
    step 3. Verify packets are forwarded to DMZ host
    step 4. Do not test ports that have port forwarding configured

    NOTE: The port scan range can be configured using the 'portScanStart' and
    'portScanStop' testvars. You can also specify any exceptions to the port
    range using the testvar 'lanDmzUdpPortExceptions'.

    Example:

    testvar portScanStart 0
    testvar portScanStop  65535


Test Module Name Synopsis
ICMP Echo packets are forwarded to DMZ host dmz.tcl cdrouter_dmz_110 ICMP Echo packets are forwarded to DMZ host


    step 1. Initiate an inbound ICMP Echo Request from the WAN to router's public IP
    step 2. Verify ICMP Echo Request is received by DMZ host

    NOTE: Some routers do not support sending unassociated ICMP packets to
    the DMZ host. Instead, they may locally process the ICMP packet or drop the
    packet. If the router does not support this functionality, the
    'lanDmzSupportsIcmp' testvar should be set to no.

    Example:

    testvar lanDmzSupportsIcmp no


Test Module Name Synopsis
Non ICMP, TCP, UDP, or SCTP protocol types are forwarded to DMZ host dmz.tcl cdrouter_dmz_200 Non ICMP, TCP, UDP, or SCTP protocol types are forwarded to DMZ host


    step 1. Send packet with IP protocol type 0 from  WAN to router's public IP
    step 2. Verify IP packet is forwarded to DMZ host
    step 3. Repeat for IP protocol types up to 255, skipping protocol types 1
            (ICMP), 6 (TCP), 17 (UDP), and 132 (SCTP) which are all transport
            protocols
    step 4. Verify each protocol type is forwarded to the DMZ host

    NOTE: The DMZ may not forward certain protocols that may be terminated
    locally on the router. For example, it may not be possible to have IGMP
    packets pass through the DMZ. You may configure a list of specific IP
    protocol types that should be skipped for this test using the testvar
    'lanDmzIpProtoExceptions'. This list should contain a comma separated
    list of ports.

    For example:

    testvar lanDmzIpProtoExceptions "2,47"



mcast.tcl

IGMPv2/v3 and multicast data tests for IGMP proxy or pass through

Test Module Name Synopsis
IGMP packets from LAN are forwarded/proxied to WAN interface mcast.tcl cdrouter_mcast_1 IGMP packets from LAN are forwarded/proxied to WAN interface


    step 1. Send an IGMPv2/3 Query on the WAN to allow device to detect IGMP version
    step 2. Send an IGMPv2/3 Membership Report packet on the LAN interface
    step 3. Verify an IGMPv2/3 Membership Report packet is received on the WAN interface
    step 4. For IGMPv3, verify group record is CHANGE_TO_EXCLUDE_MODE for the group
            with an empty source list.
    step 5. Repeat test using an IGMPv2 Leave packet or IGMPv3 Memebership Report
            to leave the multicast group
    step 6. For IGMPv3, verify group record is CHANGE_TO_INCLUDE_MODE for the group
            with an empty source list.

    NOTE: This test will work with either a multicast pass through implementation
    or a multicast proxy implementation.

    NOTE: Some routers may send an IGMP query on the LAN interface after the
    IGMP Leave from the LAN client. The IGMP Leave may not be sent on the
    WAN interface until the LAN side has made multiple queries.

    The amount of time this test case should wait before expecting the
    IGMP Leave on the WAN interface may be configured by setting the
    testvar 'multicastCacheTimeout'.


    References:

    IETF RFC 2236 "Internet Group Management Protocol, Version 2"

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

    IETF RFC 3376 "Internet Group Management Protocol, Version 3"

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

Test Module Name Synopsis
Verify IPv4 TTL is decremented for multicast packets mcast.tcl cdrouter_mcast_2 Verify IPv4 TTL is decremented for multicast packets


    step 1. Send an IGMPv2/3 Query on the WAN to allow device to detect IGMP version
    step 2. Join a multicast group on the LAN interface
    step 3. Send a UDP packet to the multicast group from the WAN
    step 4. Verify the multicast packet is received on the LAN
    step 5. Verify the TTL is decremented by the expected IP hop count

    NOTE: This test will work with either a multicast pass through implementation
    or a multicast proxy implementation.

    NOTE: The number of expected IP hops can be configured using the testvar
    'IPv4HopCount'. The default is 1 IP hop. If the device is using bridge
    mode, the expected IPv4HopCount is 0.

    NOTE: The testvar multicastJoinDelay can be used to control how long
    the test waits to verify the multicast traffic after receiving the
    IGMP report. The default value is 2 seconds.


    References:

    IETF RFC 2236 "Internet Group Management Protocol, Version 2"

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

    IETF RFC 3376 "Internet Group Management Protocol, Version 3"

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

Test Module Name Synopsis
Forward Multicast UDP packets with various packet lengths (LAN to WAN) mcast.tcl cdrouter_mcast_11 Forward Multicast UDP packets with various packet lengths (LAN to WAN)


    step 1. Send an IGMPv2/3 Query on the WAN to allow device to detect IGMP version
    step 2. Join a multicast group on the WAN interface
    step 3. Forward a multicast UDP packet from the LAN with UDP length 4
    step 4. Verify the packet is received on the WAN interface
    step 5. Repeat for all packet sizes up to the max MTU

    NOTE: This test will work with either a multicast pass through implementation
    or a multicast proxy implementation.

    NOTE: The testvar multicastJoinDelay can be used to control how long
    the test waits to verify the multicast traffic after receiving the
    IGMP report. The default value is 2 seconds.

    NOTE: If the device does not support forwarding multiast traffic
    through NAT to the WAN, this test case may be skipped by setting
    the testvar supportsMulticastOut to no.


    References:

    IETF RFC 2236 "Internet Group Management Protocol, Version 2"

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

    IETF RFC 3376 "Internet Group Management Protocol, Version 3"

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

Test Module Name Synopsis
Forward Multicast UDP packets with various packet lengths (WAN to LAN) mcast.tcl cdrouter_mcast_12 Forward Multicast UDP packets with various packet lengths (WAN to LAN)


    step 1. Send an IGMPv2/3 Query on the WAN to allow device to detect IGMP version
    step 2. Join a multicast group on the LAN interface
    step 3. Forward a multicast UDP packet from the WAN with UDP length 4
    step 4. Verify the packet is received on the LAN interface
    step 5. Repeat for all packet sizes up to the max MTU

    NOTE: This test will work with either a multicast pass through implementation
    or a multicast proxy implementation.

    NOTE: The testvar multicastJoinDelay can be used to control how long
    the test waits to verify the multicast traffic after receiving the
    IGMP report. The default value is 2 seconds.


    References:

    IETF RFC 2236 "Internet Group Management Protocol, Version 2"

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

    IETF RFC 3376 "Internet Group Management Protocol, Version 3"

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

Test Module Name Synopsis
Verify IGMP router periodically sends general IGMP Query on LAN interface mcast.tcl cdrouter_mcast_20 Verify IGMP router periodically sends general IGMP Query on LAN interface


    step 1. Send an IGMPv2/3 Query on the WAN to allow device to detect IGMP version
    step 2. Wait up to igmpQueryInterval seconds for a general IGMP Query on the LAN
    step 3. Repeat for 2 queries

    NOTE: This test will work with a multicast proxy implementation only.


    References:

    IETF RFC 2236 "Internet Group Management Protocol, Version 2"

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

    IETF RFC 3376 "Internet Group Management Protocol, Version 3"

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

Test Module Name Synopsis
Multicast streams are not forwarded if no group members exist mcast.tcl cdrouter_mcast_50 Multicast streams are not forwarded if no group members exist


    step 1. Send an IGMPv2/3 Query on the WAN to allow device to detect IGMP version
    step 2. Allocate a multicast group that has no members on the LAN
    step 3. Forward UDP multicast packet from WAN to LAN using group
    step 4. Verify the packet is not received on the LAN

    NOTE: This test will work with a multicast proxy implementation only.


    References:

    IETF RFC 2236 "Internet Group Management Protocol, Version 2"

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

    IETF RFC 3376 "Internet Group Management Protocol, Version 3"

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

Test Module Name Synopsis
Multicast streams are not forwarded after last member leaves group mcast.tcl cdrouter_mcast_51 Multicast streams are not forwarded after last member leaves group


    step 1. Send an IGMPv2/3 Query on the WAN to allow device to detect IGMP version
    step 2. Join a multicast group on the LAN interface
    step 3. Send a UDP packet to the multicast group from the WAN
    step 4. Verify the multicast packet is received on the LAN
    step 5. Send a IGMP Leave packet on the LAN interface for group
    step 6. Wait for the multicast cache to expire
    step 7. Forward UDP multicast packet from WAN to LAN using group
    step 8. Verify the packet is not received on the LAN

    NOTE: This test will work with a multicast proxy implementation only.


    References:

    IETF RFC 2236 "Internet Group Management Protocol, Version 2"

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

    IETF RFC 3376 "Internet Group Management Protocol, Version 3"

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

Test Module Name Synopsis
Multicast streams are not forwarded after last member ages out mcast.tcl cdrouter_mcast_52 Multicast streams are not forwarded after last member ages out


    step 1. Send an IGMPv2/3 Query on the WAN to allow device to detect IGMP version
    step 2. Join a multicast group on the LAN interface
    step 3. Send a UDP packet to the multicast group from the WAN
    step 4. Verify the multicast packet is received on the LAN
    step 5. Wait for the multicast group to expire
    step 6. Forward UDP multicast packet from WAN to LAN using group
    step 7. Verify the packet is not received on the LAN

    NOTE: This test will work with a multicast proxy implementation only.

    NOTE: The amount of time it takes the multicast group to expire is
    based on the igmpQueryInterval, igmpRobustnessVariable, and
    igmpQueryResponseInterval. These can all be configured using the
    following testvars:

      testvar igmpQueryInterval 125
      testvar igmpRobustnessVariable 2
      testvar igmpQueryResponseInterval 10


    References:

    IETF RFC 2236 "Internet Group Management Protocol, Version 2"

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

    IETF RFC 3376 "Internet Group Management Protocol, Version 3"

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

Test Module Name Synopsis
IGMP proxy interface answers IGMP general query requests mcast.tcl cdrouter_mcast_53 IGMP proxy interface answers IGMP general query requests


    step 1. Send an IGMPv2/3 Query on the WAN to allow device to detect IGMP version
    step 2. Join a multicast group on the LAN interface
    step 3. Wait up to 20 seconds for IGMP membership report on the WAN
    step 4. Issue an IGMP Membership query to 224.0.0.1 on WAN for group address 0.0.0.0
    step 5. Verify router's WAN side responds with IGMP membership report for
            the multicast group

    NOTE: This test will work with a multicast proxy implementation only.


    References:

    IETF RFC 2236 "Internet Group Management Protocol, Version 2"

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

    IETF RFC 3376 "Internet Group Management Protocol, Version 3"

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

Test Module Name Synopsis
IGMP proxy interface answers IGMP specific query requests mcast.tcl cdrouter_mcast_54 IGMP proxy interface answers IGMP specific query requests


    step 1. Send an IGMPv2/3 Query on the WAN to allow device to detect IGMP version
    step 2. Join a multicast group on the LAN interface
    step 3. Wait up to 20 seconds for IGMP membership report on the WAN
    step 4. Issue an IGMP Membership query to 224.0.0.1 on WAN for specific group address
    step 5. Verify router's WAN side responds with IGMP membership report for
            the multicast group

    NOTE: This test will work with a multicast proxy implementation only.


    References:

    IETF RFC 2236 "Internet Group Management Protocol, Version 2"

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

    IETF RFC 3376 "Internet Group Management Protocol, Version 3"

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

Test Module Name Synopsis
Verify IGMP router sends IGMP Group Specific Query after last member leaves group mcast.tcl cdrouter_mcast_60 Verify IGMP router sends IGMP Group Specific Query after last member leaves group


    step 1. Send an IGMPv2/3 Query on the WAN to allow device to detect IGMP version
    step 2. Send an IGMPv2/3 Membership Report packet on the LAN interface
    step 3. Send an IGMPv2 Leave or IGMPv3 Memebership packet on the LAN interface
            to leave the multicast group
    step 4. Verify an IGMPv2/3 Query packet is sent on the LAN interface
            to the specific multicast group. If igmpFastLeave is set
            to yes, verify that no IGMP Query is sent.

    NOTE: This test will work with a multicast proxy implementation only.

    NOTE: If the device supports IGMP Fast Leave, the testvar igmpFastLeave
    should be set to yes. In this case, the test case will verify that
    no group specific IGMP query is sent after the IGMP Leave.

    References:

    IETF RFC 2236 "Internet Group Management Protocol, Version 2"

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

    IETF RFC 3376 "Internet Group Management Protocol, Version 3"

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

Test Module Name Synopsis
Verify IGMP router sends IGMP Leave after last group member ages out mcast.tcl cdrouter_mcast_70 Verify IGMP router sends IGMP Leave after last group member ages out


    step 1. Send an IGMPv2/3 Query on the WAN to allow device to detect IGMP version
    step 2. Send an IGMPv2/3 Membership Report packet on the LAN interface
    step 3. Verify an IGMPv2/3 Membership Report packet is received on the WAN interface
    step 4. For IGMPv3, verify group record is CHANGE_TO_EXCLUDE_MODE for the group
            with an empty source list.
    step 5. Let group member on the LAN age out. No responses will sent to IGMP
            queries and no IGMP Leave will be sent.
    step 6. Verify IGMP leave or IGMPv3 membership report is received for the group
            on the WAN interface
    step 7. For IGMPv3, verify group record is CHANGE_TO_INCLUDE_MODE for the group
            with an empty source list.

    NOTE: This test will work with either a multicast pass through implementation
    or a multicast proxy implementation.

    NOTE: The amount of time it takes the multicast group to expire is
    based on the igmpQueryInterval, igmpRobustnessVariable, and
    igmpQueryResponseInterval. These can all be configured using the
    following testvars:

      testvar igmpQueryInterval 125
      testvar igmpRobustnessVariable 2
      testvar igmpQueryResponseInterval 10

    References:

    IETF RFC 2236 "Internet Group Management Protocol, Version 2"

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

    IETF RFC 3376 "Internet Group Management Protocol, Version 3"

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

Test Module Name Synopsis
Verify IGMP router accepts reports with unspecified source address mcast.tcl cdrouter_mcast_80 Verify IGMP router accepts reports with unspecified source address


    step 1. Send an IGMPv2/3 Query on the WAN to allow device to detect IGMP version
    step 2. Send an IGMPv2/3 Membership Report packet on the LAN interface using
            the unspecified src address 0.0.0.0.
    step 3. Verify an IGMPv2/3 Membership Report packet is received on the WAN interface
    step 4. For IGMPv3, verify group record is CHANGE_TO_EXCLUDE_MODE for the group
            with an empty source list.
    step 5. Repeat test using an IGMPv2 Leave packet or IGMPv3 Memebership Report
            to leave the multicast group
    step 6. For IGMPv3, verify group record is CHANGE_TO_INCLUDE_MODE for the group
            with an empty source list.

    NOTE: This test will work with either a multicast pass through implementation
    or a multicast proxy implementation.

    NOTE: Some routers may send an IGMP query on the LAN interface after the
    IGMP Leave from the LAN client. The IGMP Leave may not be sent on the
    WAN interface until the LAN side has made multiple queries.

    The amount of time this test case should wait before expecting the
    IGMP Leave on the WAN interface may be configured by setting the
    testvar 'multicastCacheTimeout'.


    References:

    IETF RFC 2236 "Internet Group Management Protocol, Version 2"

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

    IETF RFC 3376 "Internet Group Management Protocol, Version 3"

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

    IETF RFC 4541 "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches"

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

Test Module Name Synopsis
Verify IGMP snooping switch scenario with unspecified source address mcast.tcl cdrouter_mcast_81 Verify IGMP snooping switch scenario with unspecified source address


    step 1. Send an IGMPv2/3 Query on the WAN to allow device to detect IGMP version
    step 2. Join a multicast group on the LAN interface using src address 0.0.0.0
    step 3. Send a UDP packet to the multicast group from the WAN
    step 4. Verify the multicast packet is received on the LAN
    step 5. Verify the TTL is decremented by the expected IP hop count

    NOTE: This test will work with either a multicast pass through implementation
    or a multicast proxy implementation.

    NOTE: The number of expected IP hops can be configured using the testvar
    'IPv4HopCount'. The default is 1 IP hop.

    NOTE: The testvar multicastJoinDelay can be used to control how long
    the test waits to verify the multicast traffic after receiving the
    IGMP report. The default value is 2 seconds.


    References:

    IETF RFC 2236 "Internet Group Management Protocol, Version 2"

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

    IETF RFC 3376 "Internet Group Management Protocol, Version 3"

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

    IETF RFC 4541 "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches"

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

Test Module Name Synopsis
Verify IGMP proxy interface answers general IGMP query requests with unspecified source address mcast.tcl cdrouter_mcast_82 Verify IGMP proxy interface answers general IGMP query requests with unspecified source address


    step 1. Send an IGMPv2/3 Query on the WAN to allow device to detect IGMP version
    step 2. Join a multicast group on the LAN interface
    step 3. Wait up to 20 seconds for IGMP membership report on the WAN
    step 4. Issue an IGMP Membership query to 224.0.0.1 on WAN for group address 0.0.0.0
            using src address 0.0.0.0
    step 5. Verify router's WAN side responds with IGMP membership report for
            the multicast group

    NOTE: This test will work with a multicast proxy implementation only.

    An IGMP snooping switch may send an IGMP query with a 0.0.0.0 IP Source Address.
    IGMP does not specifically prevent IGMP queries using an unspecified
    src address while RFC 3590 does not allow this for MLD.


    References:

    IETF RFC 2236 "Internet Group Management Protocol, Version 2"

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

    IETF RFC 3376 "Internet Group Management Protocol, Version 3"

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

    IETF RFC 4541 "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches"

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

Test Module Name Synopsis
Verify IGMP proxy interface answers specific IGMP query requests with unspecified source address mcast.tcl cdrouter_mcast_83 Verify IGMP proxy interface answers specific IGMP query requests with unspecified source address


    step 1. Send an IGMPv2/3 Query on the WAN to allow device to detect IGMP version
    step 2. Join a multicast group on the LAN interface
    step 3. Wait up to 20 seconds for IGMP membership report on the WAN
    step 4. Issue an IGMP Membership query to 224.0.0.1 on WAN for specific group address
            using src address 0.0.0.0
    step 5. Verify router's WAN side responds with IGMP membership report for
            the multicast group

    NOTE: This test will work with a multicast proxy implementation only.

    An IGMP snooping switch may send an IGMP query with a 0.0.0.0 IP Source Address.
    IGMP does not specifically prevent IGMP queries using an unspecified
    src address while RFC 3590 does not allow this for MLD.


    References:

    IETF RFC 2236 "Internet Group Management Protocol, Version 2"

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

    IETF RFC 3376 "Internet Group Management Protocol, Version 3"

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

    IETF RFC 4541 "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches"

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

Test Module Name Synopsis
Verify the maximum number of multicast groups received on the LAN mcast.tcl cdrouter_mcast_100 Verify the maximum number of multicast groups received on the LAN


    step 1. Send an IGMPv2/3 Query on the WAN to allow device to detect IGMP version
    step 2. Join igmpMaxGroups multicast groups on the LAN interface
    step 3. Forward a multicast UDP packet from the WAN to each group
    step 4. Verify each group is received on the LAN interface
    step 5. Send a IGMP Leave for each multicast group

    NOTE: This test will work with either a multicast pass through implementation
    or a multicast proxy implementation.

    NOTE: You can slow down the rate at which CDRouter will join each group
    by configuring the testvar multicastScaleDelay. It defaults to 1
    millisecond.


    References:

    IETF RFC 2236 "Internet Group Management Protocol, Version 2"

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

    IETF RFC 3376 "Internet Group Management Protocol, Version 3"

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

Test Module Name Synopsis
Verify IPTV channel change test scenario 1 (no overlap) mcast.tcl cdrouter_mcast_110 Verify IPTV channel change test scenario 1 (no overlap)


    step 1. Send an IGMPv2/3 Query on the WAN to allow device to detect IGMP version
    step 2. Check the testvar iptvChannelRange to determine the number of channels
    step 3. For each channel, join the multicast group on the LAN
    step 4. Verify the IGMPv2 or IGMPv3 report is received in the WAN
    step 5. Start sending multicast data on the WAN for the new group
    step 6. Verify the LAN side starts to receive the multicast data
    step 7. Wait for a small delay determined by testvar iptvChannelChangeDelay
    step 8. Leave the multicast group on the LAN using IGMPv2/3
    step 9. Switch to the next channel or exit if too many failures have
            occurred

    NOTE: There are a few test variables that can control the number of channels
    and speed of this test.

    The testvar iptvChannelChangeDelay specifies a delay in milliseconds to wait
    between each channel change.

    The testvar iptvChannelRange specifies the total number of channel changes to
    attempt.

    The testvar iptvMaxFailures is used to stop the test after a specific number
    of failures. When testing a large number of channels, it can be useful
    to stop the test early if many channels start failing.


    References:

    IETF RFC 2236 "Internet Group Management Protocol, Version 2"

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

    IETF RFC 3376 "Internet Group Management Protocol, Version 3"

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

Test Module Name Synopsis
Verify IPTV channel change test scenario 2 (overlap) mcast.tcl cdrouter_mcast_120 Verify IPTV channel change test scenario 2 (overlap)


    step 1. Send an IGMPv2/3 Query on the WAN to allow device to detect IGMP version
    step 2. Check the testvar iptvChannelRange to determine the number of channels
    step 3. For each channel, join the multicast group on the LAN
    step 4. Verify the IGMPv2 or IGMPv3 report is received in the WAN
    step 5. Leave any previous multicast group for the last channel
    step 6. Start sending multicast data on the WAN for the new group
    step 7. Verify the LAN side starts to receive the multicast data
    step 8. Wait for a small delay determined by testvar iptvChannelChangeDelay
    step 9. Switch to the next channel or exit if too many failures have
            occurred

    NOTE: There are a few test variables that can control the number of channels
    and speed of this test.

    The testvar iptvChannelChangeDelay specifies a delay in milliseconds to wait
    between each channel change.

    The testvar iptvChannelRange specifies the total number of channel changes to
    attempt.

    The testvar iptvMaxFailures is used to stop the test after a specific number
    of failures. When testing a large number of channels, it can be useful
    to stop the test early if many channels start failing.


    References:

    IETF RFC 2236 "Internet Group Management Protocol, Version 2"

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

    IETF RFC 3376 "Internet Group Management Protocol, Version 3"

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

Test Module Name Synopsis
Verify IGMPv3 membership with source specific ALLOW_NEW_SOURCES/BLOCK_OLD_SOURCES mcast.tcl cdrouter_mcast_200 Verify IGMPv3 membership with source specific ALLOW_NEW_SOURCES/BLOCK_OLD_SOURCES


    step 1. Send an IGMPv3 Query on the WAN to allow device to detect IGMP version
    step 2. Send an IGMPv3 Membership Report packet on the LAN interface
            with ALLOW_NEW_SOURCES record containing specific source
    step 3. Verify an IGMPv3 Membership Report packet is received on the WAN interface
    step 4. Verify group record is ALLOW_NEW_SOURCES for the group
            with a matching source list.
    step 5. Verify multicast forwarding from WAN to LAN for new group using
            the specific source address.
    step 6. Continue test using an IGMPv3 BLOCK_OLD_SOURCES to leave the multicast group
    step 7. Verify group record is BLOCK_OLD_SOURCES for the group
            with a matching source list.


    References:

    IETF RFC 2236 "Internet Group Management Protocol, Version 2"

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

    IETF RFC 3376 "Internet Group Management Protocol, Version 3"

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

Test Module Name Synopsis
Verify IGMPv3 router blocks incoming multicast sources that do not match the source list mcast.tcl cdrouter_mcast_210 Verify IGMPv3 router blocks incoming multicast sources that do not match the source list


    step 1. Send an IGMPv3 Query on the WAN to allow device to detect IGMP version
    step 2. Send an IGMPv3 Membership Report packet on the LAN interface
            with ALLOW_NEW_SOURCES record containing specific source
    step 3. Verify an IGMPv3 Membership Report packet is received on the WAN interface
    step 4. Verify group record is ALLOW_NEW_SOURCES for the group
            with a matching source list.
    step 5. Verify multicast forwarding fails from WAN to LAN for new group using
            the different source address.
    step 6. Continue test using an IGMPv3 BLOCK_OLD_SOURCES to leave the multicast group
    step 7. Verify group record is BLOCK_OLD_SOURCES for the group
            with a matching source list.


    References:

    IETF RFC 2236 "Internet Group Management Protocol, Version 2"

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

    IETF RFC 3376 "Internet Group Management Protocol, Version 3"

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

Test Module Name Synopsis
Verify IGMPv3 router blocks incoming sources on a per group basis mcast.tcl cdrouter_mcast_220 Verify IGMPv3 router blocks incoming sources on a per group basis


    step 1. Send an IGMPv3 Query on the WAN to allow device to detect IGMP version
    step 2. Send an IGMPv3 Membership Report packet on the LAN interface
            with ALLOW_NEW_SOURCES record containing specific source
    step 3. Verify an IGMPv3 Membership Report packet is received on the WAN interface
    step 4. Verify group record is ALLOW_NEW_SOURCES for the group
            with a matching source list.
    step 5. Verify multicast forwarding from WAN to LAN for new group using
            the specific source address.
    step 6. Verify multicast forwarding fails from WAN to LAN for a different group
            using the same specific source address.
    step 7. Continue test using an IGMPv3 BLOCK_OLD_SOURCES to leave the multicast group
    step 8. Verify group record is BLOCK_OLD_SOURCES for the group
            with a matching source list.


    References:

    IETF RFC 2236 "Internet Group Management Protocol, Version 2"

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

    IETF RFC 3376 "Internet Group Management Protocol, Version 3"

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

Test Module Name Synopsis
Verify IGMPv3 source specific group with multiple sources mcast.tcl cdrouter_mcast_230 Verify IGMPv3 source specific group with multiple sources


    step 1. Send an IGMPv3 Query on the WAN to allow device to detect IGMP version
    step 2. Create a new server on the WAN for a multicast source
    step 3. Send an IGMPv3 Membership Report packet on the LAN interface
            with ALLOW_NEW_SOURCES record containing multiple specific sources
    step 4. Verify an IGMPv3 Membership Report packet is received on the WAN interface
    step 5. Verify group record is ALLOW_NEW_SOURCES for the group
            with a matching source list.
    step 6. Verify multicast forwarding from WAN to LAN for new group using
            the specific source address from source address 1.
    step 7. Verify multicast forwarding from WAN to LAN for new group using
            the specific source address from source address 2.
    step 8. Continue test using an IGMPv3 BLOCK_OLD_SOURCES to leave the multicast group
    step 9. Verify group record is BLOCK_OLD_SOURCES for the group
            with a matching source list.


    References:

    IETF RFC 2236 "Internet Group Management Protocol, Version 2"

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

    IETF RFC 3376 "Internet Group Management Protocol, Version 3"

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

Test Module Name Synopsis
Verify IGMPv3 general query requests with source specific memberships mcast.tcl cdrouter_mcast_240 Verify IGMPv3 general query requests with source specific memberships


    step 1. Send an IGMPv3 Query on the WAN to allow device to detect IGMP version
    step 2. Join a multicast group on the LAN interface
    step 3. Wait up to 20 seconds for IGMP membership report on the WAN
    step 4. Issue an IGMP Membership query to 224.0.0.1 on WAN for group 0.0.0.0
    step 5. Verify router's WAN side responds with IGMP membership report for
            the multicast group


    References:

    IETF RFC 2236 "Internet Group Management Protocol, Version 2"

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

    IETF RFC 3376 "Internet Group Management Protocol, Version 3"

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

Test Module Name Synopsis
Verify IGMPv3 specific query requests with source specific memberships mcast.tcl cdrouter_mcast_250 Verify IGMPv3 specific query requests with source specific memberships


    step 1. Send an IGMPv3 Query on the WAN to allow device to detect IGMP version
    step 2. Join a multicast group on the LAN interface
    step 3. Wait up to 20 seconds for IGMP membership report on the WAN
    step 4. Issue an IGMP Membership query on WAN for specific group address
    step 5. Verify router's WAN side responds with IGMP membership report for
            the multicast group


    References:

    IETF RFC 2236 "Internet Group Management Protocol, Version 2"

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

    IETF RFC 3376 "Internet Group Management Protocol, Version 3"

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

Test Module Name Synopsis
Verify IGMPv3 group and source specific query requests mcast.tcl cdrouter_mcast_260 Verify IGMPv3 group and source specific query requests


    step 1. Send an IGMPv3 Query on the WAN to allow device to detect IGMP version
    step 1. Join a multicast group on the LAN interface
    step 2. Wait up to 20 seconds for IGMP membership report on the WAN
    step 3. Issue an IGMP Membership query on WAN for specific group address
    step 4. Verify router's WAN side responds with IGMP membership report for
            the multicast group


    References:

    IETF RFC 2236 "Internet Group Management Protocol, Version 2"

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

    IETF RFC 3376 "Internet Group Management Protocol, Version 3"

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

Test Module Name Synopsis
Verify IGMPv3 maximum number of multicast groups with multiple group records mcast.tcl cdrouter_mcast_300 Verify IGMPv3 maximum number of multicast groups with multiple group records


    step 1. Send an IGMPv3 Query on the WAN to allow device to detect IGMP version
    step 2. Join igmpMaxGroups multicast groups on the LAN interface using
            multiple group records in a single IGMPv3 membership report
    step 3. Forward a multicast UDP packet from the WAN to each group
    step 4. Verify each group is received on the LAN interface
    step 5. Send a IGMP Leave for each multicast group


    References:

    IETF RFC 2236 "Internet Group Management Protocol, Version 2"

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

    IETF RFC 3376 "Internet Group Management Protocol, Version 3"

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

Test Module Name Synopsis
Verify IGMPv3 source specific IPTV channel change test scenario mcast.tcl cdrouter_mcast_310 Verify IGMPv3 source specific IPTV channel change test scenario


    step 1. Send an IGMPv3 Query on the WAN to allow device to detect IGMP version
    step 2. Check the testvar iptvChannelRange to determine the number of channels
    step 3. For each channel, join the multicast group on the LAN
    step 4. Verify the IGMPv3 report is received in the WAN
    step 5. Start sending multicast data on the WAN for the new group
    step 6. Verify the LAN side starts to receive the multicast data
    step 7. Wait for a small delay determined by testvar iptvChannelChangeDelay
    step 8. Send new IGMPv3 report to leave current channel and join next channel
            or exit if too many failures have occurred

    NOTE: There are a few test variables that can control the number of channels
    and speed of this test.

    The testvar iptvChannelChangeDelay specifies a delay in milliseconds to wait
    between each channel change.

    The testvar iptvChannelRange specifies the total number of channel changes to
    attempt.

    The testvar iptvMaxFailures is used to stop the test after a specific number
    of failures. When testing a large number of channels, it can be useful
    to stop the test earily is many channels start failing.


    References:

    IETF RFC 2236 "Internet Group Management Protocol, Version 2"

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

    IETF RFC 3376 "Internet Group Management Protocol, Version 3"

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


dyndns.tcl

Tests for routers with built in DynDNS clients

Test Module Name Synopsis
DynDNS client sends an update request when the WAN IP address changes dyndns.tcl cdrouter_dyndns_1 DynDNS client sends an update request when the WAN IP address changes


    Step 1: Terminate the WAN connection
    Step 2: Reestablish the WAN connection with a different IP address
    Step 3: Verify that the DynDNS client updated with the new IP address
    Step 4: Terminate the WAN connection again
    Step 5: Reestablish the WAN connection with the original IP address
    Step 6: Verify that the DynDNS client updated again following the WAN address change


    References:

    Dynamic DNS Update API "Dyn.com Remote Access Update API -- Perform Update"

    https://help.dyn.com/remote-access-api/perform-update/

Test Module Name Synopsis
DynDNS client does not update if the WAN reestablishes with the same IP address dyndns.tcl cdrouter_dyndns_2 DynDNS client does not update if the WAN reestablishes with the same IP address


    Step 1: Terminate the WAN connection
    Step 2: Wait for the device to reestablish the WAN connection with the same IP address
    Step 3: Observe DynDNS activity for a period of time
    Step 4: Verify that no DynDNS updates were performed.


    References:

    Dynamic DNS Update API "Dyn.com Remote Access Update API -- Policies"

    https://help.dyn.com/remote-access-api/policies/

Test Module Name Synopsis
DynDNS client sends correct parameters in update request dyndns.tcl cdrouter_dyndns_10 DynDNS client sends correct parameters in update request


    Step 1: Terminate the WAN connection
    Step 2: Reestablish the WAN connection with a different IP address
    Step 3: Verify that the DynDNS client updates with the new WAN IP address
    Step 4: Compare the update parameters with their expected values specified in the config file

    NOTE: The config file allows you to specify expected values for each of the DynDNS update parameters.
    If the client being tested relies on the default value being used, leave the coresponding testvar
    commented out.


    References:

    Dynamic DNS Update API "Dyn.com Remote Access Update API -- Perform Update"

    https://help.dyn.com/remote-access-api/perform-update/

Test Module Name Synopsis
DynDNS client uses DNS to resolve the address of members.dyndns.org dyndns.tcl cdrouter_dyndns_20 DynDNS client uses DNS to resolve the address of members.dyndns.org


    Step 1: Disable the existing DynDNS server so it doesn't respond to any update requests
    Step 2: Create a new DynDNS server on the WAN side on a free IP address
    Step 3: Update the DNS entry of members.dyndns.org to resolve to the new DynDNS server
    Step 4: Terminate the WAN connection
    Step 5: Reestablish the WAN connection with a new IP address
    Step 6: Verify the DynDNS client updates with the new DynDNS server
    Step 7: Reset the WAN connection back to the original IP address; reset the original
            DNS information for members.dyndns.org and reenable the original DynDNS server


    References:

    Dynamic DNS Update API "Dyn.com Remote Access Update API -- Policies"

    https://help.dyn.com/remote-access-api/policies/

Test Module Name Synopsis
DynDNS client doesn't rely on DNS to determine if an update is necessary dyndns.tcl cdrouter_dyndns_50 DynDNS client doesn’t rely on DNS to determine if an update is necessary


    Step 1: Count the number of times the DynDNS client hostname has been queried in DNS
    Step 2: Force a DynDNS update by changing the IP address on the WAN and reestablish a connection
    Step 3: Observe DynDNS client activity for a period of time
    Step 4: Count again the number of times the DynDNS client hostname has been queried in DNS
    Step 5: Compare the count in Step 1 with the count in Step 2
    Step 6: Reset the WAN connection to use the orignial IP address

    NOTE: This test verifies that the DynDNS client is not using a DNS lookup to determine if an update
          needs to be performed.


    References:

    Dynamic DNS Update API "Dyn.com Remote Access Update API -- Guidelines"

    Clients should not perform DNS queries to determine whether
    it is necessary to update. The danger is that the ISP’s DNS
    server will be caching the old IP for a few minutes, leading
    the client to conclude the update failed and causing a loop.

    https://help.dyn.com/remote-access-api/guidelines/

Test Module Name Synopsis
DynDNS client reacts appropriately to error conditions dyndns.tcl cdrouter_dyndns_101 DynDNS client reacts appropriately to error conditions


    Step 1: Terminate the WAN connection
    Step 2: Set the DynDNS server to return the specified error code
    Step 3: Force a DynDNS update by changing the IP address on the WAN and reestablish a connection
    Step 4: Observe DynDNS activity for a period of time
    Step 5: Verify the DynDNS client stops updating after receiving the error message

    NOTE: Following this test, the DynDNS client should not perform any updates until there has
    been user confirmation that the problem is fixed. This will break any subsequent tests and
    therefore must be run in isolation from other DynDNS tests.

    Example:

    testvar testDynDnsErrorCode   yes
    testvar dynDnsServerReturn    <error code>


    References:

    Dynamic DNS Update API "Dyn.com Remote Access Update API -- Policies"

    https://help.dyn.com/remote-access-api/policies/

    Dynamic DNS Update API "Dyn.com Remote Access Update API -- Return Codes"

    https://help.dyn.com/remote-access-api/return-codes/


sip-alg.tcl

SIP testing for SIP ALG or proxy

Test Module Name Synopsis
Verify NAT translation of SIP headers during REGISTER sip-alg.tcl cdrouter_sip_1 Verify NAT translation of SIP headers during REGISTER


    step 1. Send a REGISTER from LAN client to SIP proxy on WAN
    step 2. Verify the private IPv4 address in the Contact header
            is translated to the WAN side IPv4 address
    step 3. Verify the private IPv4 address in the Via header
            is translated to the WAN side IPv4 address; in the
            case of a proxy, verify a new Via header is added
            with the SIP ALGs public IPv4 address.


    References:

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation"

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00

Test Module Name Synopsis
Verify NAT translation of short format SIP headers during REGISTER sip-alg.tcl cdrouter_sip_2 Verify NAT translation of short format SIP headers during REGISTER


    step 1. Configure the SIP client and server to use short
            header formats
    step 2. Send a REGISTER from LAN client to SIP proxy on WAN
    step 3. Verify the private IPv4 address in the Contact header
            is translated to the WAN side IPv4 address
    step 4. Verify the private IPv4 address in the Via header
            is translated to the WAN side IPv4 address; in the
            case of a proxy, verify a new Via header is added
            with the SIP ALGs public IPv4 address.


    References:

    IETF RFC 3261 "SIP: Session Initiation Protocol" Section 20: Header Fields

    https://tools.ietf.org/html/rfc3261#section-20

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify NAT translation of SIP headers during outbound call sip-alg.tcl cdrouter_sip_10 Verify NAT translation of SIP headers during outbound call


    step 1. Register SIP client with SIP proxy on WAN
    step 2. Initiate an outbound call to remote SIP destination
    step 3. Verify the Contact and Via headers are updated
            for the INVITE and BYE methods.


    References:

    IETF RFC 3261 "SIP: Session Initiation Protocol" Section 20: Header Fields

    https://tools.ietf.org/html/rfc3261#section-20

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify NAT translation of short format SIP headers during outbound call sip-alg.tcl cdrouter_sip_11 Verify NAT translation of short format SIP headers during outbound call


    step 1. Configure SIP client and server to use short format
            for all SIP headers
    step 2. Register SIP client with SIP proxy on WAN
    step 3. Initiate an outbound call to remote SIP destination
    step 4. Verify the Contact and Via headers are updated
            for the INVITE and BYE methods.


    References:

    IETF RFC 3261 "SIP: Session Initiation Protocol" Section 20: Header Fields

    https://tools.ietf.org/html/rfc3261#section-20

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify NAT translation of SIP headers during inbound call sip-alg.tcl cdrouter_sip_20 Verify NAT translation of SIP headers during inbound call


    step 1. Register SIP client with SIP proxy on WAN
    step 2. Initiate an inbound call to LAN side SIP destination
    step 3. Verify the Contact and Via headers are updated
            for the Resposes to INVITE and BYE methods


    References:

    IETF RFC 3261 "SIP: Session Initiation Protocol" Section 20: Header Fields

    https://tools.ietf.org/html/rfc3261#section-20

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify NAT translation of short format SIP headers during inbound call sip-alg.tcl cdrouter_sip_21 Verify NAT translation of short format SIP headers during inbound call


    step 1. Configure SIP client and server to use short format
            for all SIP headers
    step 2. Register SIP client with SIP proxy on WAN
    step 3. Initiate an inbound call to LAN side SIP destination
    step 4. Verify the Contact and Via headers are updated
            for the Resposes to INVITE and BYE methods


    References:

    IETF RFC 3261 "SIP: Session Initiation Protocol" Section 20: Header Fields

    https://tools.ietf.org/html/rfc3261#section-20

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify NAT translation of SDP headers during outbound call sip-alg.tcl cdrouter_sip_30 Verify NAT translation of SDP headers during outbound call


    step 1. Register SIP client with SIP proxy on WAN
    step 2. Initiate an outbound call to remote SIP destination
    step 3. Verify the SDP Media and Connection fields are updated
            with the public side IP address and port mapping
    step 4. Initiate RTP stream in both directions
    step 5. Verify RTP packets are flowing in both directions
    step 6. End SIP call by sending 'BYE' from the LAN
    step 7. Unregister SIP client


    References:

    IETF RFC 3261 "SIP: Session Initiation Protocol" Section 20: Header Fields

    https://tools.ietf.org/html/rfc3261#section-20

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify NAT translation of SDP headers during inbound call sip-alg.tcl cdrouter_sip_31 Verify NAT translation of SDP headers during inbound call


    step 1. Register SIP client with SIP proxy on WAN
    step 2. Initiate an inbound call to remote SIP destination
    step 3. For INVITE response from SIP client, verify the
            SDP Media and Connection fields are updated
            with the public side IP address and port mapping
    step 4. Initiate RTP stream in both directions
    step 5. Verify RTP packets are flowing in both directions
    step 6. End SIP call by sending 'BYE' from the LAN
    step 7. Unregister SIP client


    References:

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify SIP call with client using source port not equal to 5060 sip-alg.tcl cdrouter_sip_40 Verify SIP call with client using source port not equal to 5060


    step 1. Configure SIP client to use a source port other than
            5060 for SIP signaling
    step 2. Register SIP client with SIP proxy on WAN
    step 3. Initiate an outbound call to remote SIP destination
    step 4. Initiate RTP stream in both directions
    step 5. Verify RTP packets are flowing in both directions
    step 6. End SIP call by sending 'BYE' from the LAN
    step 7. Unregister SIP client


    References:

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify outbound SIP call with client 'Contact' header using different port sip-alg.tcl cdrouter_sip_41 Verify outbound SIP call with client ‘Contact’ header using different port


    step 1. Configure SIP client to use a source port in the Contact
            header that is not the same as the SIP packet source port
    step 2. Register SIP client with SIP proxy on WAN
    step 3. Initiate an outbound call to remote SIP destination
    step 4. Initiate RTP stream in both directions
    step 5. Verify RTP packets are flowing in both directions
    step 6. End SIP call by sending 'BYE' from the LAN
    step 7. Unregister SIP client


    References:

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify inbound SIP call with client 'Contact' header using different port sip-alg.tcl cdrouter_sip_42 Verify inbound SIP call with client ‘Contact’ header using different port


    step 1. Configure SIP client to use a source port in the Contact
            header that is not the same as the SIP packet source port
    step 2. Register SIP client with SIP proxy on WAN
    step 3. Initiate an inbound call to remote SIP destination
    step 4. Initiate RTP stream in both directions
    step 5. Verify RTP packets are flowing in both directions
    step 6. End SIP call by sending 'BYE' from the LAN
    step 7. Unregister SIP client


    References:

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify outbound SIP calls allow incoming RTP stream when caller uses mute sip-alg.tcl cdrouter_sip_43 Verify outbound SIP calls allow incoming RTP stream when caller uses mute


    step 1. Register SIP client with SIP proxy on WAN
    step 2. Initiate an outbound call to remote SIP destination
    step 3. Configure SIP client in "mute" mode so that no outbound
            RTP traffic will be sent
    step 4. When call is answered, send RTP stream from WAN side
            SIP endpoint to the LAN side SIP client
    step 5. Verify the SIP client on the LAN receives RTP stream

    NOTE: This test verifies that the SIP ALG creates a NAT port mapping
    for incoming RTP packets. If the SIP ALG relies on outgoing RTP packets
    to set up the NAT port mapping for RTP, this test will fail. Some SIP
    clients will not send any RTP packets when mute is enabled.


    References:

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation"

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00

Test Module Name Synopsis
Verify Via header port is used for response instead of UDP source port sip-alg.tcl cdrouter_sip_45 Verify Via header port is used for response instead of UDP source port


    step 1. Configure SIP client to use port 5060 in Via header
            but send packets from a different UDP source port
    step 2. Register SIP client with SIP proxy on WAN
    step 3. Initiate an outbound call to remote SIP destination
    step 4. Initiate RTP stream in both directions
    step 5. Verify RTP packets are flowing in both directions
    step 6. End SIP call by sending 'BYE' from the LAN
    step 7. Unregister SIP client

    NOTE: Some poorly implemented SIP clients use a Via header that does not
    match the actual source packet of SIP request packets. The SIP ALG should
    use the Via header information to formulate the SIP response and not the
    source port of the UDP packet.


    References:

    IETF RFC 3261 "SIP: Session Initiation Protocol" Section 8.1.17: Via

    https://tools.ietf.org/html/rfc3261#section-8.1.17

Test Module Name Synopsis
Verify NAT translation of SDP remains the same on retransmission of INVITE sip-alg.tcl cdrouter_sip_50 Verify NAT translation of SDP remains the same on retransmission of INVITE


    step 1. Register SIP client with SIP proxy on WAN
    step 2. Configure SIP proxy not to respond to INVITES
    step 3. Send INVITE with SDP descriptor from LAN to WAN SIP client
    step 4. Verify SDP port and IPv4 address is translated to public IP
    step 5. Resend INVITE with same Call ID and SDP information
    step 6. Verify SDP translation remains the same


    References:

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation"

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00

Test Module Name Synopsis
Verify RTP port mapping is deleted when SIP client ends call (BYE) sip-alg.tcl cdrouter_sip_60 Verify RTP port mapping is deleted when SIP client ends call (BYE)


    step 1. Register SIP client with SIP proxy on WAN
    step 2. Initiate an outbound call to remote SIP destination
    step 3. Initiate RTP stream in both directions
    step 4. Verify RTP packets are flowing in both directions
    step 5. End SIP call by sending 'BYE' from the LAN
    step 6. After call ends, wait sipCallTeardownDelay seconds
    step 7. Send inbound RTP packets from WAN to LAN
            using the same port numbers for the RTP connection
    step 8. Verify the port mapping is now closed and the
            RTP packets are not forwarded onto the LAN
    step 9. Unregister SIP client

    NOTE: The amount of time to wait after the call ends can be configured using
    the testvar 'sipCallTeardownDelay'. Some ALGs explicitly delete a RTP port
    mapping when the BYE exchange occurs. Others wait until no media packets
    have been received.


    References:

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify RTP port mapping is deleted when SIP proxy ends call (BYE) sip-alg.tcl cdrouter_sip_61 Verify RTP port mapping is deleted when SIP proxy ends call (BYE)


    step 1. Register SIP client with SIP proxy on WAN
    step 2. Initiate an outbound call to remote SIP destination
    step 3. Initiate RTP stream in both directions
    step 4. Verify RTP packets are flowing in both directions
    step 5. End SIP call by sending 'BYE' from the WAN SIP Proxy
    step 6. After call ends, send inbound RTP packets from WAN to LAN
            using the same port numbers for the RTP connection
    step 7. Verify the port mapping is now closed and the
            RTP packets are not forwarded onto the LAN
    step 8. Unregister SIP client

    NOTE: The amount of time to wait after the call ends can be configured using
    the testvar 'sipCallTeardownDelay'. Some ALGs explicitly delete a RTP port
    mapping when the BYE exchange occurs. Others wait until no media packets
    have been received.


    References:

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify RTP port mapping is deleted when SIP client cancels call (CANCEL) sip-alg.tcl cdrouter_sip_62 Verify RTP port mapping is deleted when SIP client cancels call (CANCEL)


    step 1. Register SIP client with SIP proxy on WAN
    step 2. Initiate an outbound call to remote SIP destination
    step 3. Configure the SIP proxy not to respond
    step 4. End SIP call by sending 'CANCEL' from the LAN
    step 5. After call ends, send inbound RTP packets from WAN to LAN
            using the same port numbers for the RTP connection
    step 6. Verify the port mapping is now closed and the
            RTP packets are not forwarded onto the LAN
    step 7. Unregister SIP client

    NOTE: The amount of time to wait after the call ends can be configured using
    the testvar 'sipCallTeardownDelay'. Some ALGs explicitly delete a RTP port
    mapping when the BYE exchange occurs. Others wait until no media packets
    have been received.


    References:

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify RTP port mapping is deleted or not established if call setup fails sip-alg.tcl cdrouter_sip_63 Verify RTP port mapping is deleted or not established if call setup fails


    step 1. Register SIP client with SIP proxy on WAN
    step 2. Initiate an outbound call to remote SIP destination
    step 3. Configure the SIP proxy to return 400 error
    step 4. Verify the port mapping in INVITE is closed and the
            RTP packets are not forwarded onto the LAN
    step 5. Unregister SIP client

    NOTE: The amount of time to wait after the call ends can be configured using
    the testvar 'sipCallTeardownDelay'. Some ALGs explicitly delete a RTP port
    mapping when the BYE exchange occurs. Others wait until no media packets
    have been received.


    References:

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify SIP ALG with various SIP URI formats sip-alg.tcl cdrouter_sip_70 Verify SIP ALG with various SIP URI formats


    step 1. For each URI, register SIP client with SIP proxy on WAN
    step 2. Initiate an outbound call to remote SIP destination
    step 3. Verify outbound call succeeds and RTP traffic is flowing
    step 4. End outbound SIP call from client side
    step 5. Attempt inbound call to URI address
    step 6. Verify inbound call succeeds and RTP traffic is flowing
    step 7. End inbound SIP call from client side
    step 8. Unregister SIP client


Test Module Name Synopsis
Verify outbound calls with multiple SIP clients using the same SIP and SDP ports sip-alg.tcl cdrouter_sip_71 Verify outbound calls with multiple SIP clients using the same SIP and SDP ports


    step 1. Configure an additional DHCP client on the LAN
    step 2. Register 2 SIP clients with SIP proxy on WAN using
            the same source port (5060) on the LAN side
    step 3. Initiate an outbound call to remote SIP destination
            from both SIP clients
    step 4. For each call, initiate RTP streams in both directions
    step 5. For each call, Verify RTP packets are flowing in both directions
    step 6. End SIP call by sending 'BYE' from the LAN
    step 7. Unregister both SIP clients


    References:

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify inbound calls with multiple SIP clients using the same SIP and SDP ports sip-alg.tcl cdrouter_sip_72 Verify inbound calls with multiple SIP clients using the same SIP and SDP ports


    step 1. Configure an additional DHCP client on the LAN
    step 2. Register 2 SIP clients with SIP proxy on WAN using
            the same source port (5060) on the LAN side
    step 3. Initiate an inbound call to remote SIP destination
            from both SIP clients
    step 4. For each call, initiate RTP streams in both directions
    step 5. For each call, Verify RTP packets are flowing in both directions
    step 6. End SIP call by sending 'BYE' from the LAN
    step 7. Unregister both SIP clients


    References:

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify outbound calls with multiple SIP clients using corner case port 65535 for SDP sip-alg.tcl cdrouter_sip_73 Verify outbound calls with multiple SIP clients using corner case port 65535 for SDP


    step 1. Configure an additional DHCP client on the LAN
    step 2. Register 2 SIP clients with SIP proxy on WAN using
            the same source port (5060) on the LAN side
    step 3. Initiate an outbound call to remote SIP destination
            from both SIP clients with both clients using SDP
            port 65534-65535
    step 4. For each call, initiate RTP streams in both directions
    step 5. For each call, Verify RTP packets are flowing in both directions
    step 6. End SIP call by sending 'BYE' from the LAN
    step 7. Unregister both SIP clients

    NOTE: This test verifies that the SIP-ALG is able to support the maximum
    port number that is allowed.


    References:

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify outbound SIP calls when server uses early media SDP setup sip-alg.tcl cdrouter_sip_80 Verify outbound SIP calls when server uses early media SDP setup


    step 1. Register SIP client with SIP proxy on WAN
    step 2. Initiate an outbound call to remote SIP destination
    step 3. Configure SIP server to return 183 Session Progress that
            includes SDP media setup
    step 4. Server side will start sending RTP stream
    step 5. Verify the SIP client on the LAN receives RTP stream

    NOTE: This test verifies that the SIP ALG creates a NAT port mapping
    for incoming RTP packets when 183 Session Progress with SDP is used by
    the SIP server. If the SIP ALG relies on outgoing RTP packets to set
    up the NAT port mapping for RTP, this test will fail.


    References:

    IETF RFC 3261 "SIP: Session Initiation Protocol" Section 21.1.5: 183 Session Progress

    https://tools.ietf.org/html/rfc3261#section-21.1.5

Test Module Name Synopsis
Verify maximum number of simultaneous outbound SIP calls sip-alg.tcl cdrouter_sip_100 Verify maximum number of simultaneous outbound SIP calls


    step 1. Register SIP client with SIP proxy on WAN
    step 2. Initiate an outbound call to unique remote SIP destination
    step 3. Continue to initiate calls up to sipMaxOutboundCalls
    step 4. For each call, verify RTP traffic is flowing in both directions
    step 5. End each call by sending 'BYE' from the LAN
    step 6. Unregister SIP client

    NOTES:

    The number of outbound SIP calls attempted is controlled by the testvar
    'sipMaxOutboundCalls'. It defaults to 10.

    For this testing scenario, the pace of the RTP stream is slowed down to
    allow fewer RTP packets per stream. The actual RTP send interval can be
    configured using the testvar 'rtpSendInterval'. This is the interval between
    each RTP packet in milliseconds. The default value is 5000 milliseconds.

    An additional pacing time can be configured between each SIP call using the
    testvar 'sipCallPacing'. This value is in milliseconds.

    Once all outbound SIP calls have been attempted, the test will let the calls
    run for 30 seconds by default. This duration can be changed using the
    testvar 'sipScaleRunTime'. The duration must be long enough to allow each
    RTP stream to send and receive at least 2 packets. This value is in seconds.


    References:

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify maximum number of simultaneous inbound SIP calls sip-alg.tcl cdrouter_sip_101 Verify maximum number of simultaneous inbound SIP calls


    step 1. Register SIP client with SIP proxy on WAN
    step 2. Initiate an inbound call from unique remote SIP destination
    step 3. Continue to initiate calls up to sipMaxInboundCalls
    step 4. For each call, verify RTP traffic is flowing in both directions
    step 5. End each call by sending 'BYE' from the WAN
    step 6. Unregister SIP client

    NOTES:

    The number of inbound SIP calls attempted is controlled by the testvar
    'sipMaxInboundCalls'. It defaults to 10.

    For this testing scenario, the pace of the RTP stream is slowed down to
    allow fewer RTP packets per stream. The actual RTP send interval can be
    configured using the testvar 'rtpSendInterval'. This is the interval between
    each RTP packet in milliseconds. The default value is 5000 milliseconds.

    An additional pacing time can be configured between each SIP call using the
    testvar 'sipCallPacing'. This value is in milliseconds.

    Once all inbound SIP calls have been attempted, the test will let the calls
    run for 30 seconds by default. The call duration can be changed using the
    testvar 'sipScaleRunTime'. The duration must be long enough to allow each
    RTP stream to send and receive at least 2 packets. This value is in seconds.


    References:

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify outbound SIP calls with multiple DHCP LAN clients sip-alg.tcl cdrouter_sip_200 Verify outbound SIP calls with multiple DHCP LAN clients


    step 1. Create a DHCP client for each SIP call
    step 2. Register each SIP client with SIP proxy on WAN
    step 3. Initiate an outbound call to remote SIP destination
    step 4. Continue to initiate calls up to sipMaxOutboundCalls
    step 5. For each call, verify RTP traffic is flowing in both directions
    step 6. End each call by sending 'BYE' from the LAN
    step 7. Unregister SIP client
    step 8. Release all new DHCP client leases

    NOTES:

    The number of outbound SIP calls attempted is controlled by the testvar
    'sipMaxOutboundCalls'. It defaults to 10.

    By default, the SIP server and client use port 5060. The SIP server port may
    be configured using the testvar sipScaleServerPort. The sipScaleClientPort
    testvar may be used to configure a specific SIP client source port for the
    clients. The value of unique may also be specified to dynamically allocate
    the SIP client port.

    Example:

    testvar sipScaleServerPort 10001
    testvar sipScaleClientPort unique

    For this testing scenario, the pace of the RTP stream is slowed down to
    allow fewer RTP packets per stream. The actual RTP send interval can be
    configured using the testvar 'rtpSendInterval'. This is the interval between
    each RTP packet in milliseconds. The default value is 5000 milliseconds. If
    this is increased to a larger value, changing the value of 'sipScaleRunTime'
    should also be increased. This controls the duration must be long enough to
    allow each RTP stream to send and receive at least 2 packets. This value is
    in seconds.


    References:

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify outbound SIP calls with multiple DHCP LAN clients without registering a port sip-alg.tcl cdrouter_sip_201 Verify outbound SIP calls with multiple DHCP LAN clients without registering a port


    step 1. Create a DHCP client for each SIP call
    step 2. Register each SIP client with SIP proxy on WAN without specifying any port numbers
    step 3. Initiate an outbound call to remote SIP destination
    step 4. Continue to initiate calls up to sipMaxOutboundCalls
    step 5. For each call, verify RTP traffic is flowing in both directions
    step 6. End each call by sending 'BYE' from the LAN
    step 7. Unregister SIP client
    step 8. Release all new DHCP client leases

    NOTES:

    The number of outbound SIP calls attempted is controlled by the testvar
    'sipMaxOutboundCalls'. It defaults to 10.

    This test will start the SIP server and SIP clients on the default port of
    5060.

    For this testing scenario, the pace of the RTP stream is slowed down to
    allow fewer RTP packets per stream. The actual RTP send interval can be
    configured using the testvar 'rtpSendInterval'. This is the interval between
    each RTP packet in milliseconds. The default value is 5000 milliseconds. If
    this is increased to a larger value, changing the value of 'sipScaleRunTime'
    should also be increased. This controls the duration must be long enough to
    allow each RTP stream to send and receive at least 2 packets. This value is
    in seconds.


    References:

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1


sip-alg-tcp.tcl

SIP over TCP testing for SIP ALG or proxy

Test Module Name Synopsis
Verify NAT translation of SIP headers during REGISTER (TCP) sip-alg-tcp.tcl cdrouter_sip_tcp_1 Verify NAT translation of SIP headers during REGISTER (TCP)


    step 1. Send a REGISTER from LAN client to SIP proxy on WAN
    step 2. Verify the private IPv4 address in the Contact header
            is translated to the WAN side IPv4 address
    step 3. Verify the private IPv4 address in the Via header
            is translated to the WAN side IPv4 address; in the
            case of a proxy, verify a new Via header is added
            with the SIP ALGs public IPv4 address.


    References:

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation"

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00

Test Module Name Synopsis
Verify NAT translation of short format SIP headers during REGISTER (TCP) sip-alg-tcp.tcl cdrouter_sip_tcp_2 Verify NAT translation of short format SIP headers during REGISTER (TCP)


    step 1. Configure the SIP client and server to use short
            header formats
    step 2. Send a REGISTER from LAN client to SIP proxy on WAN
    step 3. Verify the private IPv4 address in the Contact header
            is translated to the WAN side IPv4 address
    step 4. Verify the private IPv4 address in the Via header
            is translated to the WAN side IPv4 address; in the
            case of a proxy, verify a new Via header is added
            with the SIP ALGs public IPv4 address.


    References:

    IETF RFC 3261 "SIP: Session Initiation Protocol" Section 20: Header Fields

    https://tools.ietf.org/html/rfc3261#section-20

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify NAT translation of SIP headers during outbound call (TCP) sip-alg-tcp.tcl cdrouter_sip_tcp_10 Verify NAT translation of SIP headers during outbound call (TCP)


    step 1. Register SIP client with SIP proxy on WAN
    step 2. Initiate an outbound call to remote SIP destination
    step 3. Verify the Contact and Via headers are updated
            for the INVITE and BYE methods.


    References:

    IETF RFC 3261 "SIP: Session Initiation Protocol" Section 20: Header Fields

    https://tools.ietf.org/html/rfc3261#section-20

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify NAT translation of short format SIP headers during outbound call (TCP) sip-alg-tcp.tcl cdrouter_sip_tcp_11 Verify NAT translation of short format SIP headers during outbound call (TCP)


    step 1. Configure SIP client and server to use short format
            for all SIP headers
    step 2. Register SIP client with SIP proxy on WAN
    step 3. Initiate an outbound call to remote SIP destination
    step 4. Verify the Contact and Via headers are updated
            for the INVITE and BYE methods.


    References:

    IETF RFC 3261 "SIP: Session Initiation Protocol" Section 20: Header Fields

    https://tools.ietf.org/html/rfc3261#section-20

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify NAT translation of SIP headers during inbound call (TCP) sip-alg-tcp.tcl cdrouter_sip_tcp_20 Verify NAT translation of SIP headers during inbound call (TCP)


    step 1. Register SIP client with SIP proxy on WAN
    step 2. Initiate an inbound call to LAN side SIP destination
    step 3. Verify the Contact and Via headers are updated
            for the Resposes to INVITE and BYE methods


    References:

    IETF RFC 3261 "SIP: Session Initiation Protocol" Section 20: Header Fields

    https://tools.ietf.org/html/rfc3261#section-20

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify NAT translation of short format SIP headers during inbound call (TCP) sip-alg-tcp.tcl cdrouter_sip_tcp_21 Verify NAT translation of short format SIP headers during inbound call (TCP)


    step 1. Configure SIP client and server to use short format
            for all SIP headers
    step 2. Register SIP client with SIP proxy on WAN
    step 3. Initiate an inbound call to LAN side SIP destination
    step 4. Verify the Contact and Via headers are updated
            for the Resposes to INVITE and BYE methods


    References:

    IETF RFC 3261 "SIP: Session Initiation Protocol" Section 20: Header Fields

    https://tools.ietf.org/html/rfc3261#section-20

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify NAT translation of SDP headers during outbound call (TCP) sip-alg-tcp.tcl cdrouter_sip_tcp_30 Verify NAT translation of SDP headers during outbound call (TCP)


    step 1. Register SIP client with SIP proxy on WAN
    step 2. Initiate an outbound call to remote SIP destination
    step 3. Verify the SDP Media and Connection fields are updated
            with the public side IP address and port mapping
    step 4. Initiate RTP stream in both directions
    step 5. Verify RTP packets are flowing in both directions
    step 6. End SIP call by sending 'BYE' from the LAN
    step 7. Unregister SIP client


    References:

    IETF RFC 3261 "SIP: Session Initiation Protocol" Section 20: Header Fields

    https://tools.ietf.org/html/rfc3261#section-20

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify NAT translation of SDP headers during inbound call (TCP) sip-alg-tcp.tcl cdrouter_sip_tcp_31 Verify NAT translation of SDP headers during inbound call (TCP)


    step 1. Register SIP client with SIP proxy on WAN
    step 2. Initiate an inbound call to remote SIP destination
    step 3. For INVITE response from SIP client, verify the
            SDP Media and Connection fields are updated
            with the public side IP address and port mapping
    step 4. Initiate RTP stream in both directions
    step 5. Verify RTP packets are flowing in both directions
    step 6. End SIP call by sending 'BYE' from the LAN
    step 7. Unregister SIP client


    References:

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify SIP call with client using source port not equal to 5060 (TCP) sip-alg-tcp.tcl cdrouter_sip_tcp_40 Verify SIP call with client using source port not equal to 5060 (TCP)


    step 1. Configure SIP client to use a source port other than
            5060 for SIP signaling
    step 2. Register SIP client with SIP proxy on WAN
    step 3. Initiate an outbound call to remote SIP destination
    step 4. Initiate RTP stream in both directions
    step 5. Verify RTP packets are flowing in both directions
    step 6. End SIP call by sending 'BYE' from the LAN
    step 7. Unregister SIP client


    References:

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify outbound SIP call with client 'Contact' header using different port (TCP) sip-alg-tcp.tcl cdrouter_sip_tcp_41 Verify outbound SIP call with client ‘Contact’ header using different port (TCP)


    step 1. Configure SIP client to use a source port in the Contact
            header that is not the same as the source port as the
            SIP packet source port
    step 2. Register SIP client with SIP proxy on WAN
    step 3. Initiate an outbound call to remote SIP destination
    step 4. Initiate RTP stream in both directions
    step 5. Verify RTP packets are flowing in both directions
    step 6. End SIP call by sending 'BYE' from the LAN
    step 7. Unregister SIP client


    References:

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify inbound SIP call with client 'Contact' header using different port (TCP) sip-alg-tcp.tcl cdrouter_sip_tcp_42 Verify inbound SIP call with client ‘Contact’ header using different port (TCP)


    step 1. Configure SIP client to use a source port in the Contact
            header that is not the same as the SIP packet source port
    step 2. Register SIP client with SIP proxy on WAN
    step 3. Initiate an inbound call to remote SIP destination
    step 4. Initiate RTP stream in both directions
    step 5. Verify RTP packets are flowing in both directions
    step 6. End SIP call by sending 'BYE' from the LAN
    step 7. Unregister SIP client


    References:

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify outbound SIP calls allow incoming RTP stream when caller uses mute (TCP) sip-alg-tcp.tcl cdrouter_sip_tcp_43 Verify outbound SIP calls allow incoming RTP stream when caller uses mute (TCP)


    step 1. Register SIP client with SIP proxy on WAN
    step 2. Initiate an outbound call to remote SIP destination
    step 3. Configure SIP client in "mute" mode so that no outbound
            RTP traffic will be sent
    step 4. When call is answered, send RTP stream from WAN side
            SIP endpoint to the LAN side SIP client
    step 5. Verify the SIP client on the LAN receives RTP stream

    NOTE: This test verifies that the SIP ALG creates a NAT port mapping for
    incoming RTP packets. If the SIP ALG relies on outgoing RTP packets to set
    up the NAT port mapping for RTP, this test will fail. Some SIP clients will
    not send any RTP packets when mute is enabled.


    References:

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation"

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00

Test Module Name Synopsis
Verify Via header port is used for response instead of TCP source port (TCP) sip-alg-tcp.tcl cdrouter_sip_tcp_45 Verify Via header port is used for response instead of TCP source port (TCP)


    step 1. Configure SIP client to use port 5060 in Via header
            but send packets from a different TCP source port
    step 2. Register SIP client with SIP proxy on WAN
    step 3. Initiate an outbound call to remote SIP destination
    step 4. Initiate RTP stream in both directions
    step 5. Verify RTP packets are flowing in both directions
    step 6. End SIP call by sending 'BYE' from the LAN
    step 7. Unregister SIP client

    NOTE: Some poorly implemented SIP clients use a Via header that does not
    match the actual source packet of SIP request packets. The SIP ALG should
    use the Via header information to formulate the SIP response and not the
    source port of the TCP packet.


    References:

    IETF RFC 3261 "SIP: Session Initiation Protocol" Section 8.1.1.7: Via

    https://tools.ietf.org/html/rfc3261#section-8.1.1.7

Test Module Name Synopsis
Verify NAT translation of SDP remains the same on retransmission of INVITE (TCP) sip-alg-tcp.tcl cdrouter_sip_tcp_50 Verify NAT translation of SDP remains the same on retransmission of INVITE (TCP)


    step 1. Register SIP client with SIP proxy on WAN
    step 2. Configure SIP proxy not to respond to INVITES
    step 3. Send INVITE with SDP descriptor from LAN to WAN SIP client
    step 4. Verify SDP port and IPv4 address is translated to public IP
    step 5. Resend INVITE with same Call ID and SDP information
    step 6. Verify SDP translation remains the same


    References:

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation"

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00

Test Module Name Synopsis
Verify RTP port mapping is deleted when SIP client ends call (BYE) (TCP) sip-alg-tcp.tcl cdrouter_sip_tcp_60 Verify RTP port mapping is deleted when SIP client ends call (BYE) (TCP)


    step 1. Register SIP client with SIP proxy on WAN
    step 2. Initiate an outbound call to remote SIP destination
    step 3. Initiate RTP stream in both directions
    step 4. Verify RTP packets are flowing in both directions
    step 5. End SIP call by sending 'BYE' from the LAN
    step 6. After call ends, wait sipCallTeardownDelay seconds
    step 7. Send inbound RTP packets from WAN to LAN
            using the same port numbers for the RTP connection
    step 8. Verify the port mapping is now closed and the
            RTP packets are not forwarded onto the LAN
    step 9. Unregister SIP client

    NOTE: The amount of time to wait after the call ends can be configured using
    the testvar 'sipCallTeardownDelay'. Some ALGs explicitly delete a RTP port
    mapping when the BYE exchange occurs. Others wait until no media packets
    have been received.


    References:

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify RTP port mapping is deleted when SIP proxy ends call (BYE) (TCP) sip-alg-tcp.tcl cdrouter_sip_tcp_61 Verify RTP port mapping is deleted when SIP proxy ends call (BYE) (TCP)


    step 1. Register SIP client with SIP proxy on WAN
    step 2. Initiate an outbound call to remote SIP destination
    step 3. Initiate RTP stream in both directions
    step 4. Verify RTP packets are flowing in both directions
    step 5. End SIP call by sending 'BYE' from the WAN SIP Proxy
    step 6. After call ends, send inbound RTP packets from WAN to LAN
            using the same port numbers for the RTP connection
    step 7. Verify the port mapping is now closed and the
            RTP packets are not forwarded onto the LAN
    step 8. Unregister SIP client

    NOTE: The amount of time to wait after the call ends can be configured using
    the testvar 'sipCallTeardownDelay'. Some ALGs explicitly delete a RTP port
    mapping when the BYE exchange occurs. Others wait until no media packets
    have been received.


    References:

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify RTP port mapping is deleted when SIP client cancels call (CANCEL) (TCP) sip-alg-tcp.tcl cdrouter_sip_tcp_62 Verify RTP port mapping is deleted when SIP client cancels call (CANCEL) (TCP)


    step 1. Register SIP client with SIP proxy on WAN
    step 2. Initiate an outbound call to remote SIP destination
    step 3. Configure the SIP proxy not to respond
    step 4. End SIP call by sending 'CANCEL' from the LAN
    step 5. After call ends, send inbound RTP packets from WAN to LAN
            using the same port numbers for the RTP connection
    step 6. Verify the port mapping is now closed and the
            RTP packets are not forwarded onto the LAN
    step 7. Unregister SIP client

    NOTE: The amount of time to wait after the call ends can be configured using
    the testvar 'sipCallTeardownDelay'. Some ALGs explicitly delete a RTP port
    mapping when the BYE exchange occurs. Others wait until no media packets
    have been received.


    References:

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify RTP port mapping is deleted or not established if call setup fails (TCP) sip-alg-tcp.tcl cdrouter_sip_tcp_63 Verify RTP port mapping is deleted or not established if call setup fails (TCP)


    step 1. Register SIP client with SIP proxy on WAN
    step 2. Initiate an outbound call to remote SIP destination
    step 3. Configure the SIP proxy to return 400 error
    step 4. Verify the port mapping in INVITE is closed and the
            RTP packets are not forwarded onto the LAN
    step 5. Unregister SIP client

    NOTE: The amount of time to wait after the call ends can be configured using
    the testvar 'sipCallTeardownDelay'. Some ALGs explicitly delete a RTP port
    mapping when the BYE exchange occurs. Others wait until no media packets
    have been received.


    References:

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify SIP ALG with various SIP URI formats (TCP) sip-alg-tcp.tcl cdrouter_sip_tcp_70 Verify SIP ALG with various SIP URI formats (TCP)


    step 1. For each URI, register SIP client with SIP proxy on WAN
    step 2. Initiate an outbound call to remote SIP destination
    step 3. Verify outbound call succeeds and RTP traffic is flowing
    step 4. End outbound SIP call from client side
    step 5. Attempt inbound call to URI address
    step 6. Verify inbound call succeeds and RTP traffic is flowing
    step 7. End inbound SIP call from client side
    step 8. Unregister SIP client


Test Module Name Synopsis
Verify outbound calls with multiple SIP clients using the same SIP and SDP ports (TCP) sip-alg-tcp.tcl cdrouter_sip_tcp_71 Verify outbound calls with multiple SIP clients using the same SIP and SDP ports (TCP)


    step 1. Configure an additional DHCP client on the LAN
    step 2. Register 2 SIP clients with SIP proxy on WAN using
            the same source port on the LAN side
    step 3. Initiate an outbound call to remote SIP destination
            from both SIP clients
    step 4. For each call, initiate RTP streams in both directions
    step 5. For each call, Verify RTP packets are flowing in both directions
    step 6. End SIP call by sending 'BYE' from the LAN
    step 7. Unregister both SIP clients


    References:

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify inbound calls with multiple SIP clients using the same SIP and SDP ports (TCP) sip-alg-tcp.tcl cdrouter_sip_tcp_72 Verify inbound calls with multiple SIP clients using the same SIP and SDP ports (TCP)


    step 1. Configure an additional DHCP client on the LAN
    step 2. Register 2 SIP clients with SIP proxy on WAN using
            the same source port (5060) on the LAN side
    step 3. Initiate an inbound call to remote SIP destination
            from both SIP clients
    step 4. For each call, initiate RTP streams in both directions
    step 5. For each call, Verify RTP packets are flowing in both directions
    step 6. End SIP call by sending 'BYE' from the LAN
    step 7. Unregister both SIP clients


    References:

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify outbound calls with multiple SIP clients using corner case port 65535 for SDP (TCP) sip-alg-tcp.tcl cdrouter_sip_tcp_73 Verify outbound calls with multiple SIP clients using corner case port 65535 for SDP (TCP)


    step 1. Configure an additional DHCP client on the LAN
    step 2. Register 2 SIP clients with SIP proxy on WAN using
            the same source port on the LAN side
    step 3. Initiate an outbound call to remote SIP destination
            from both SIP clients with both clients using SDP
            port 65534-65535
    step 4. For each call, initiate RTP streams in both directions
    step 5. For each call, Verify RTP packets are flowing in both directions
    step 6. End SIP call by sending 'BYE' from the LAN
    step 7. Unregister both SIP clients

    NOTE: This test verifies that the SIP-ALG is able to support the maximum
    port number that is allowed.


    References:

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify outbound SIP calls when server uses early media SDP setup (TCP) sip-alg-tcp.tcl cdrouter_sip_tcp_80 Verify outbound SIP calls when server uses early media SDP setup (TCP)


    step 1. Register SIP client with SIP proxy on WAN
    step 2. Initiate an outbound call to remote SIP destination
    step 3. Configure SIP server to return 183 Session Progress that
            includes SDP media setup
    step 4. Server side will start sending RTP stream
    step 5. Verify the SIP client on the LAN receives RTP stream

    NOTE: This test verifies that the SIP ALG creates a NAT port mapping for
    incoming RTP packets when 183 Session Progress with SDP is used by the SIP
    server. If the SIP ALG relies on outgoing RTP packets to set up the NAT port
    mapping for RTP, this test will fail.


    References:

    IETF RFC 3261 "SIP: Session Initiation Protocol" Section 21.1.5: 183 Session Progress

    https://tools.ietf.org/html/rfc3261#section-21.1.5

Test Module Name Synopsis
Verify maximum number of simultaneous outbound SIP calls (TCP) sip-alg-tcp.tcl cdrouter_sip_tcp_100 Verify maximum number of simultaneous outbound SIP calls (TCP)


    step 1. Register SIP client with SIP proxy on WAN
    step 2. Initiate an outbound call to unique remote SIP destination
    step 3. Continue to initiate calls up to sipMaxOutboundCalls
    step 4. For each call, verify RTP traffic is flowing in both directions
    step 5. End each call by sending 'BYE' from the LAN
    step 6. Unregister SIP client

    NOTES:

    The number of outbound SIP calls attempted is controlled by the testvar
    'sipMaxOutboundCalls'. It defaults to 10.

    For this testing scenario, the pace of the RTP stream is slowed down to
    allow fewer RTP packets per stream. The actual RTP send interval can be
    configured using the testvar 'rtpSendInterval'. This is the interval between
    each RTP packet in milliseconds. The default value is 5000 milliseconds.

    An additional pacing time can be configured between each SIP call using the
    testvar 'sipCallPacing'. This value is in milliseconds.

    Once all outbound SIP calls have been attempted, the test will let the calls
    run for 30 seconds by default. This duration can be changed using the
    testvar 'sipScaleRunTime'. The duration must be long enough to allow each
    RTP stream to send and receive at least 2 packets. This value is in seconds.


    References:

    IETF RFC 3261 "SIP: Session Initiation Protocol" Section 21.1.5: 183 Session Progress

    https://tools.ietf.org/html/rfc3261#section-21.1.5

Test Module Name Synopsis
Verify maximum number of simultaneous inbound SIP calls (TCP) sip-alg-tcp.tcl cdrouter_sip_tcp_101 Verify maximum number of simultaneous inbound SIP calls (TCP)


    step 1. Register SIP client with SIP proxy on WAN
    step 2. Initiate an inbound call from unique remote SIP destination
    step 3. Continue to initiate calls up to sipMaxInboundCalls
    step 4. For each call, verify RTP traffic is flowing in both directions
    step 5. End each call by sending 'BYE' from the WAN
    step 6. Unregister SIP client

    NOTES:

    The number of inbound SIP calls attempted is controlled by the testvar
    'sipMaxInboundCalls'. It defaults to 10.

    For this testing scenario, the pace of the RTP stream can be slowed down to
    allow fewer RTP packets per stream. The actual RTP send interval can be
    configured using the testvar 'rtpSendInterval'. This is the interval between
    each RTP packet in milliseconds. The default value is 5000 milliseconds.

    An additional pacing time can be configured between each SIP call using the
    testvar 'sipCallPacing'. This value is in milliseconds.

    Once all inbound SIP calls have been attempted, the test will let the calls
    run for 30 seconds by default. This duration can be changed using the
    testvar 'sipScaleRunTime'. The duration must be long enought to allow each
    RTP stream to send and receive at least 2 packets. This value is in seconds.


    References:

    IETF RFC 3261 "SIP: Session Initiation Protocol" Section 21.1.5: 183 Session Progress

    https://tools.ietf.org/html/rfc3261#section-21.1.5

Test Module Name Synopsis
Verify outbound SIP calls with multiple DHCP LAN clients (TCP) sip-alg-tcp.tcl cdrouter_sip_tcp_200 Verify outbound SIP calls with multiple DHCP LAN clients (TCP)


    step 1. Create a DHCP client for each SIP call
    step 2. Register each SIP client with SIP proxy on WAN
    step 3. Initiate an outbound call to remote SIP destination
    step 4. Continue to initiate calls up to sipMaxOutboundCalls
    step 5. For each call, verify RTP traffic is flowing in both directions
    step 6. End each call by sending 'BYE' from the LAN
    step 7. Unregister SIP client
    step 8. Release all new DHCP client leases

    NOTES:

    The number of outbound SIP calls attempted is controlled by the testvar
    'sipMaxOutboundCalls'. It defaults to 10.

    By default, the SIP server and client use port 5060. The SIP server port may
    be configured using the testvar sipScaleServerPort. The sipScaleClientPort
    testvar may be used to configure a specific SIP client source port for the
    clients. The value of unique may also be specified to dynamically allocate
    the SIP client port.

    Example:

    testvar sipScaleServerPort 10001
    testvar sipScaleClientPort unique

    For this testing scenario, the pace of the RTP stream is slowed down to
    allow fewer RTP packets per stream. The actual RTP send interval can be
    configured using the testvar 'rtpSendInterval'. This is the interval between
    each RTP packet in milliseconds. The default value is 5000 milliseconds. The
    call duration can be changed using the testvar 'sipScaleRunTime'. The
    duration must be long enough to allow each RTP stream to send and receive at
    least 2 packets. This value is in seconds.


    References:

    IETF Internet-Draft draft-biggs-sip-nat-00 "A SIP Application Level Gateway for Network Address Translation" Section 3.1: Outgoing SIP Message Mangling

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00#section-3.1

Test Module Name Synopsis
Verify outbound SIP calls with multiple DHCP LAN clients (TCP) without registering a port sip-alg-tcp.tcl cdrouter_sip_tcp_201 Verify outbound SIP calls with multiple DHCP LAN clients (TCP) without registering a port


    step 1. Create a DHCP client for each SIP call
    step 2. Register each SIP client with SIP proxy on WAN without specifying any port numbers
    step 3. Initiate an outbound call to remote SIP destination
    step 4. Continue to initiate calls up to sipMaxOutboundCalls
    step 5. For each call, verify RTP traffic is flowing in both directions
    step 6. End each call by sending 'BYE' from the LAN
    step 7. Unregister SIP client
    step 8. Release all new DHCP client leases

    Reference:
    A SIP Application Level Gateway for Network Address Translation
    IETF Draft draft-biggs-sip-nat-00.txt
    Section 3.1 Outgoing SIP Message Mangling

    NOTES:

    The number of outbound SIP calls attempted is controlled by the
    testvar 'sipMaxOutboundCalls'. It defaults to 10.

    This test will start the SIP server and SIP clients on the default
    port of 5060.

    For this testing scenario, the pace of the RTP stream is slowed down
    to allow fewer RTP packets per stream. The actual RTP send interval
    can be configured using the testvar 'rtpSendInterval'. This is the
    interval between each RTP packet in milliseconds. The default value is
    5000 milliseconds. The call duration can be changed using the testvar
    'sipScaleRunTime'. The duration must be long enough to allow each
    RTP stream to send and receive at least 2 packets. This value is in seconds.



dns.tcl

DNS proxy and DNS failover related tests

Test Module Name Synopsis
Verify DNS proxy does not cache DNS entry when DNS TTL is 0 dns.tcl dns_10 Verify DNS proxy does not cache DNS entry when DNS TTL is 0


    step 1. Initiate a DNS lookup for a new unique hostname from the LAN
            client to the configured DNS server
    step 2. Return DNS response with TTL set to 0 from WAN DNS server
    step 3. Change the IP address on the DNS server for the new hostname
    step 4. Initiate a new DNS lookup for the same hostname
    step 5. Verify a new DNS request is sent to the primary or backup
            DNS servers

    NOTE: Zero values are interpreted to mean that the RR can only be
    used for the transaction in progress, and should not be cached.


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 3.2.1: Format

    https://tools.ietf.org/html/rfc1035#section-3.2.1

Test Module Name Synopsis
Verify DNS proxy returns TTL of 0 when returned DNS TTL is 0 dns.tcl dns_11 Verify DNS proxy returns TTL of 0 when returned DNS TTL is 0


    step 1. Initiate a DNS lookup for a new unique hostname from the LAN
            client to the configured DNS server
    step 2. Return DNS response with TTL set to 0 from WAN DNS server
    step 3. Verify the returned TTL from the DNS proxy is 0

    NOTE: Zero values are interpreted to mean that the RR can only be
    used for the transaction in progress, and should not be cached.


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 3.2.1: Format

    https://tools.ietf.org/html/rfc1035#section-3.2.1

Test Module Name Synopsis
Verify AAAA IPv6 DNS queries to router are forwarded to real DNS server dns.tcl dns_40 Verify AAAA IPv6 DNS queries to router are forwarded to real DNS server


    step 1. Initiate an AAAA IPv6 DNS query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS
            server
    step 4. Send a return response back to LAN
    step 5. Verify the response is received by LAN client

    NOTE: The router must support some type of DNS relay or proxy to
    pass this test case. The DNS relay or proxy must understand IPv6 DNS
    type AAAA lookups.


    References:

    IETF RFC 4074 "Common Misbehavior Against DNS Queries for IPv6 Addresses"

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

Test Module Name Synopsis
Verify AAAA IPv6 DNS queries can return no address for IPv6 to IPv4 failover dns.tcl dns_41 Verify AAAA IPv6 DNS queries can return no address for IPv6 to IPv4 failover


    step 1. Initiate an AAAA IPv6 DNS query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS
            server
    step 4. Send an empty return response back to LAN
    step 5. Verify the response is received by LAN client

    NOTE: The router must support some type of DNS relay or proxy to
    pass this test case. The DNS relay or proxy must understand IPv6
    DNS type AAAA lookups.


    References:

    IETF RFC 4074 "Common Misbehavior Against DNS Queries for IPv6 Addresses"

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

Test Module Name Synopsis
Verify DNS failover when non-zero error codes are received in non-authoritative DNS response dns.tcl dns_45 Verify DNS failover when non-zero error codes are received in non-authoritative DNS response


    step 1. Verify DNS error codes from 1 - 15.
    step 2. For each error code, send 3 DNS queries for a unique
            hostname to the DUT's LAN IP address.
    step 3. Verify a valid DNS response was received for all 3 DNS
            queries.
    step 4. Verify that all 3 DNS queries were received on the same
            WAN DNS server address, known as the current primary DNS
            server address.
    step 5. Configure DNS queries sent to the current primary DNS
            server address to return the error code, and all other DNS
            server addresses to return the normal response.
    step 6. All error responses from the current primary DNS server
            address will have the authoritative bit not set.
    step 7. Send 3 DNS queries for another unique hostname to the
            DUT's LAN IP address.
    step 8. Verify a valid DNS response is received if the error code
            is expected to trigger DNS failover.
    step 9. Verify that a DNS query was received on the current
            primary DNS server address.

    NOTE: Most DNS clients that support multiple DNS servers (primary and
    backup) use some type of failover for certain DNS error codes. The behavior
    for each error code is implementation dependent. The list of error codes
    that will cause DNS failover can be configured using the testvar
    'dnsFailoverNonAuth'. If no DNS error codes will cause failover, the testvar
    should be configured with the keyword 'none'.

    Example:

    testvar dnsFailoverNonAuth "2 4 5"

    Example with no failover support:

    testvar dnsFailoverNonAuth none

    NOTE: Unix OSes based on bind will normally failover if DNS error
    codes 2, 4, or 5 are received. Windows based OSes will normally
    failover on all DNS error codes except 3 (No Such Name).

    NOTE: In most configurations the DUT will learn the IPv4 and/or IPv6
    addresses of several DNS servers on the WAN. While CDRouter will Initiate
    all DNS queries on the LAN over IPv4 in this test, the DUT may use any of
    the DNS servers in its list (IPv4 of IPv6) for final resolution.


Test Module Name Synopsis
Verify DNS failover when non-zero error codes are received in authoritative DNS response dns.tcl dns_46 Verify DNS failover when non-zero error codes are received in authoritative DNS response


    step 1. Verify DNS error codes from 1 - 15.
    step 2. For each error code, send 3 DNS queries for a unique
            hostname to the DUT's LAN IP address.
    step 3. Verify a valid DNS response was received for all 3 DNS
            queries.
    step 4. Verify that all 3 DNS queries were received on the same
            WAN DNS server address, known as the current primary DNS
            server address.
    step 5. Configure DNS queries sent to the current primary DNS
            server address to return the error code, and all other DNS
            server addresses to return the normal response.
    step 6. All error responses from the current primary DNS server
            address will have the authoritative bit set.
    step 7. Send 3 DNS queries for another unique hostname to the
            DUT's LAN IP address.
    step 8. Verify a valid DNS response is received if the error code
            is expected to trigger DNS failover.
    step 9. Verify that a DNS query was received on the current
            primary DNS server address.

    NOTE: Most DNS clients that support multiple DNS servers (primary and
    backup) use some type of failover for certain DNS error codes. The behavior
    for each error code is implementation dependent. The list of error codes
    that will cause DNS failover can be configured using the testvar
    'dnsFailoverAuth'. If no DNS error codes will cause failover, the testvar
    should be configured with the keyword 'none'.

    Example:

    testvar dnsFailoverAuth "2 4 5"

    Example with no failover support:

    testvar dnsFailoverAuth none

    NOTE: Unix OSes based on bind will normally failover if DNS error
    codes 2, 4, or 5 are received. Windows based OSes will normally
    failover on all DNS error codes except 3 (No Such Name).

    NOTE: In most configurations the DUT will learn the IPv4 and/or IPv6
    addresses of several DNS servers on the WAN. While CDRouter will Initiate
    all DNS queries on the LAN over IPv4 in this test, the DUT may use any of
    the DNS servers in its list (IPv4 of IPv6) for final resolution.


Test Module Name Synopsis
Verify Reverse PTR DNS queries to router are forwarded to real DNS server dns.tcl dns_50 Verify Reverse PTR DNS queries to router are forwarded to real DNS server


    step 1. Initiate a reverse DNS query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS
            server
    step 4. Send a return response back to LAN
    step 5. Verify the response is received by LAN client

    NOTE: The router must support some type of DNS relay or proxy to
    pass this test case.


Test Module Name Synopsis
Verify Reverse AAAA IPv6 DNS queries to router are forwarded to real DNS server dns.tcl dns_51 Verify Reverse AAAA IPv6 DNS queries to router are forwarded to real DNS server


    step 1. Initiate a reverse AAAA IPv6 DNS query from the LAN client
            to the configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS
            server
    step 4. Send a return response back to LAN
    step 5. Verify the response is received by LAN client

    NOTE: The router must support some type of DNS relay or proxy to
    pass this test case.


Test Module Name Synopsis
Verify DNS proxy fails over when new primary DNS server is learned dns.tcl dns_60 Verify DNS proxy fails over when new primary DNS server is learned


    step 1. Create a new primary and backup DNS server
    step 2. Terminate the WAN link and bring back up
    step 3. Issue DNS query from the LAN client to the DUT's LAN IP
            address
    step 4. Verify LAN client receives response from new DNS servers
    step 5. If DNS query fails, make additional attempts to allow
            possible failover
    step 6. Terminate the WAN link and bring back up with original DNS
            servers

    NOTE: This test is only run when the WAN mode is dynamic.

    NOTE: The amount of time to wait before checking that DNS has
    been updated after the WAN link is restored can be configured
    using the testvar 'dnsFailoverDelay'. The default is 10 seconds.

    NOTE: In IPv4 and IPv6 dual stack scenarios, the DUT may switch
    over to IPv6 DNS server addresses which have not changed. These
    servers are also unresponsive during the test and the DUT should
    fail over to the new IPv4 DNS servers. The number of DNS queries
    attempted may be configured using the testvar 'dnsFailoverAttempts'.

Test Module Name Synopsis
Verify DNS lookups with multiple IPv4 responses dns.tcl dns_70 Verify DNS lookups with multiple IPv4 responses


    step 1. Initiate a DNS lookup for a new unique hostname from the LAN
            client to the configured DNS server
    step 2. Return DNS response with multiple IPv4 answers from WAN DNS
            server
    step 3. Verify LAN client learns all IPv4 answers from DNS lookup


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"

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

Test Module Name Synopsis
Verify DNS proxy recovers after DNS server outage dns.tcl dns_100 Verify DNS proxy recovers after DNS server outage


    step 1. Verify initial DNS lookup is working
    step 2. Disable all DNS servers
    step 3. Initiate 3 DNS lookups for new domains which should fail
            from the LAN client to the DUT's LAN IP address
    step 4. Enable all DNS servers
    step 5. Verify DNS lookups start working again

    NOTE: Zero values are interpreted to mean that the RR can only be
    used for the transaction in progress, and should not be cached.


Test Module Name Synopsis
Verify DNS queries including the EDNS0 option dns.tcl dns_110 Verify DNS queries including the EDNS0 option


    step 1. Initiate a DNS lookup containing EDNS0 option for a new
            unique hostname from the LAN client to the configured DNS
            server
    step 2. Return DNS response with TTL set to 0 from WAN DNS server
    step 3. Change the IP address on the DNS server for the new hostname
    step 4. Initiate a new DNS lookup containing EDNS0 option for the
            same hostname
    step 5. Verify a new DNS request is sent to the primary or backup
            DNS servers; inclusion of EDNS0 option should not affect
            ability to successfully resolve hostnames

    NOTE: Zero values are interpreted to mean that the RR can only be
    used for the transaction in progress, and should not be cached.


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 3.2.1: Format

    https://tools.ietf.org/html/rfc1035#section-3.2.1

Test Module Name Synopsis
Verify large DNS responses using EDNS0 option dns.tcl dns_120 Verify large DNS responses using EDNS0 option


    step 1. Configure a DNS entry with 200 IPv4 matching records that
            requires a UDP response slightly less than 4096
    step 2. Initiate a DNS lookup for a new unique hostname from the LAN
            client to the configured DNS server using EDNS0 option
            announcing a UDP buffer size of 4096
    step 3. Return DNS response with multiple IPv4 answers from WAN DNS
            server
    step 4. Verify LAN client learns all IPv4 answers from DNS lookup


    References:

    IETF RFC 6891 "Extension Mechanisms for DNS (EDNS0)"

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

Test Module Name Synopsis
Verify maximum UDP payload value in EDNS0 option dns.tcl dns_121 Verify maximum UDP payload value in EDNS0 option


    step 1. Initiate a DNS lookup for a unique hostname from the LAN
            client to the configured DNS server using EDNS0 option
            announcing a UDP buffer size of 4096
    step 2. Verify DNS response contains EDNS0 option
    step 3. Configure a DNS entry with enough matching IPv4 records that
            requires a UDP response slightly less than the EDNS0 UDP
            buffer size seen in step 2
    step 4. Initiate a DNS lookup for the same hostname from LAN client
            using EDNS0 option announcing a UDP buffer size of 4096
    step 5. Return DNS response with multiple IPv4 answers from WAN DNS
            server
    step 6. Verify LAN client learns all IPv4 answers from DNS lookup


    References:

    IETF RFC 6891 "Extension Mechanisms for DNS (EDNS0)"

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

Test Module Name Synopsis
Verify DNS queries for TXT records dns.tcl dns_130 Verify DNS queries for TXT records


    step 1. Initiate a DNS TXT query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS server
    step 4. Send a return TXT response back to LAN
    step 5. Verify the response is received by LAN client


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"

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

Test Module Name Synopsis
Verify DNS queries for CNAME records dns.tcl dns_132 Verify DNS queries for CNAME records


    step 1. Initiate a DNS CNAME query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS server
    step 4. Send a return CNAME response back to LAN
    step 5. Verify the response is received by LAN client


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"

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

Test Module Name Synopsis
Verify DNS queries for responses returning both CNAME and A records dns.tcl dns_133 Verify DNS queries for responses returning both CNAME and A records


    step 1. Initiate a DNS query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS server
    step 4. Send both a CNAME and A records response back to LAN
    step 5. Verify the response is received by LAN client with both CNAME
            and A records


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"

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

Test Module Name Synopsis
Verify DNS queries for responses returning both CNAME and AAAA records dns.tcl dns_134 Verify DNS queries for responses returning both CNAME and AAAA records


    step 1. Initiate a DNS query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS server
    step 4. Send both a CNAME and AAAA records response back to LAN
    step 5. Verify the response is received by LAN client with both CNAME
            and AAAA records


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"

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

Test Module Name Synopsis
Verify DNS queries for SPF records dns.tcl dns_140 Verify DNS queries for SPF records


    step 1. Initiate a DNS SPF query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS
            server
    step 4. Send a return SPF response back to LAN
    step 5. Verify the response is received by LAN client


    References:

    IETF RFC 4408 "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1"

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

Test Module Name Synopsis
Verify DNS queries for SRV records dns.tcl dns_141 Verify DNS queries for SRV records


    step 1. Initiate a DNS SRV query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS
            server
    step 4. Send a return SRV response back to LAN
    step 5. Verify the response is received by LAN client
    step 6. Verify the response priority, weight, port and target fields


    References:

    IETF RFC 2782 "A DNS RR for specifying the location of services (DNS SRV)"

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

Test Module Name Synopsis
Verify DNS proxy behavior for DNS server status requests dns.tcl dns_150 Verify DNS proxy behavior for DNS server status requests


    step 1. Send a DNS server status request from the LAN client to the
            configured DNS server
    step 2. Verify that the DNS proxy either forwards the server status request
            to the real DNS server or drops it based on the proxy's expected
            behavior

    NOTE: Scanning tools including Nmap utilize DNS server status requests when
    probing a host. Some DNS proxy implementations will drop DNS server status
    requests for security reasons. The testvar dnsForwardServerStatus should be
    set to a value of **no** if this is the expected behavior of the DUT's DNS
    proxy. For DNS proxy implementations that forward server status request
    messages upstream, the testvar dnsForwardServerStatus should be set to a
    value of **yes**.


    References:

    IETF RFC 5625 "DNS Proxy Implementation Guidelines" Section 3: Transparency Principle

    https://tools.ietf.org/html/rfc5625#section-3

    The DNS Status OPCODE Section 6: Security Considerations

    http://www.eric-a-hall.com/specs/draft-hall-status-opcode-00-1.txt6

Test Module Name Synopsis
Verify DNS proxy does not mangle DNSSEC queries dns.tcl dns_200 Verify DNS proxy does not mangle DNSSEC queries


    step 1. Initiate a DNSKEY query from the LAN client to the
            configured DNS server
    step 2. The query may be received by the primary or backup DNS
            server
    step 3. Send a DNSKEY response back to LAN
    step 4. Verify the response is received by LAN client and all fields
            are correct
    step 5. Repeat steps 1-5 for RRSIG, DS, and NSEC queries

    NOTE: The router must support some type of DNS relay or proxy to
    pass this test case.


    References:

    IETF RFC 4034 "Resource Records for the DNS Security Extensions"

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

Test Module Name Synopsis
Verify DNS proxy does not mangle large DNSSEC responses dns.tcl dns_201 Verify DNS proxy does not mangle large DNSSEC responses


    step 1. Initiate a DNSKEY query from the LAN client to the
            configured DNS server
    step 2. The query may be received by the primary or backup DNS
            server
    step 3. Send a large RRSIG response (greater than 1220 bytes) back
            to LAN
    step 4. Verify full response is received by LAN client and all
            fields are correct

    NOTE: The router must support some type of DNS relay or proxy to
    pass this test case.


    References:

    IETF RFC 4035 "Protocol Modifications for the DNS Security Extensions" Section 4.1: EDNS Support

    https://tools.ietf.org/html/rfc4035#section-4.1

Test Module Name Synopsis
Verify DHCP server automatically registers DHCP client's hostname in DNS dns.tcl dns_210 Verify DHCP server automatically registers DHCP client’s hostname in DNS


    step 1. Perform a DNS lookup on the DHCP client's hostname on LAN
    step 2. Verify DNS record exists and contains correct address

    The DHCP Host Name option can be used to communicate an RFC 1035
    compatible domain name to the DHCP server. This test case verifies
    devices that will automatically populate the local DNS server with
    this hostname entry.


    References:

    IETF RFC 2132 "DHCP Options and BOOTP Vendor Extensions" Section 3.14: Host Name Option

    https://tools.ietf.org/html/rfc2132#section-3.14

Test Module Name Synopsis
Verify DHCP server updates DHCP client's hostname when it changes dns.tcl dns_220 Verify DHCP server updates DHCP client’s hostname when it changes


    step 1. Restart DHCP client on LAN with new hostname value
    step 2. Verify DHCP client obtains IPv4 address
    step 3. Perform a DNS lookup on the new DHCP client's hostname on LAN
    step 4. Verify DNS record exists and contains correct address
    step 5. Restore DHCP clients original hostname

    The DHCP Host Name option can be used to communicate an RFC 1035
    compatible domain name to the DHCP server. This test case verifies
    devices that will automatically populate the local DNS server with
    this hostname entry.


    References:

    IETF RFC 2132 "DHCP Options and BOOTP Vendor Extensions" Section 3.14: Host Name Option

    https://tools.ietf.org/html/rfc2132#section-3.14

Test Module Name Synopsis
Verify DHCP server supports FQDN hostname values dns.tcl dns_230 Verify DHCP server supports FQDN hostname values


    step 1. Restart DHCP client on LAN with new FQDN hostname value
    step 2. Verify DHCP client obtains IPv4 address
    step 3. Perform a DNS lookup on the new DHCP client's hostname on LAN
    step 4. Verify DNS record exists and contains correct address
    step 5. Restore DHCP clients original hostname

    The DHCP Host Name option may contain a fully qualified name.


    References:

    IETF RFC 2132 "DHCP Options and BOOTP Vendor Extensions" Section 3.14: Host Name Option

    https://tools.ietf.org/html/rfc2132#section-3.14

Test Module Name Synopsis
Verify DNS proxy removes old DHCP hostname values when hostname changes dns.tcl dns_240 Verify DNS proxy removes old DHCP hostname values when hostname changes


    step 1. Restart DHCP client on LAN with new hostname value
    step 2. Verify DHCP client obtains IPv4 address
    step 3. Perform a DNS lookup on the new DHCP client's hostname on LAN
    step 4. Verify DNS record exists and contains correct address
    step 5. Restart DHCP client with original hostname
    step 6. Verify DHCP client obtains IPv4 address
    step 7. Perform a DNS lookup on the old DHCP client's hostname on LAN
    step 8. Verify the old hostname is no longer in DNS


    References:

    IETF RFC 2132 "DHCP Options and BOOTP Vendor Extensions" Section 3.14: Host Name Option

    https://tools.ietf.org/html/rfc2132#section-3.14

Test Module Name Synopsis
Verify DHCP server handles DHCP hostname option with maximum size DNS subdomain length dns.tcl dns_250 Verify DHCP server handles DHCP hostname option with maximum size DNS subdomain length


    step 1. Restart DHCP client on LAN with new hostname value with total length of 63
    step 2. Verify DHCP client obtains IPv4 address
    step 3. Perform a DNS lookup on the new DHCP client's hostname on LAN
    step 4. Verify DNS record exists and contains correct address
    step 5. Restore DHCP clients original hostname


    References:

    IETF RFC 2132 "DHCP Options and BOOTP Vendor Extensions" Section 3.14: Host Name Option

    https://tools.ietf.org/html/rfc2132#section-3.14

Test Module Name Synopsis
Verify DNS proxy honors TTL values when caching responses dns.tcl dns_300 Verify DNS proxy honors TTL values when caching responses


    step 1. Initiate a DNS lookup for a hostname from the LAN client to
            the DUT's LAN IP address
    step 2. Verify DUT's DNS proxy forwards the query to the WAN DNS
            server
    step 3. Change the address on the WAN DNS server for the new
            hostname
    step 4. Wait half the TTL value of the response
    step 5. Perform a DNS lookup on the same hostname from the LAN
    step 6. If supportsDnsCaching is yes, verify DUT's DNS proxy returns
            cached response from step 2 and does not forward the query
            to the WAN DNS server.  If supportsDnsCaching is no, verify
            DUT's DNS proxy forwards the query to the WAN DNS server
    step 7. Wait long enough for the TTL value of the response from
            step 2 to have elapsed
    step 8. Perform a DNS lookup on the same hostname from the LAN
    step 9. Verify DUT's DNS proxy forwards the query to the WAN DNS
            server


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 4.1.3: Resource Record Format

    https://tools.ietf.org/html/rfc1035#section-4.1.3

Test Module Name Synopsis
Verify maximum number of cached DNS responses dns.tcl dns_301 Verify maximum number of cached DNS responses


    step 1. Initiate a DNS lookup for a new unique hostname from the LAN
            client to the DUT's LAN IP address
    step 2. Verify that the DUT's DNS proxy forwards the query to the
            WAN DNS server
    step 3. Send a valid response to the DUT on the WAN and verify that
            DUT's DNS proxy forwards this response to the LAN client
    step 4. Repeat steps 1 through 3 dnsCacheSize times
    step 5. Repeat steps 1 through 4 but look up the hostnames in
            reverse order
    step 6. Verify that each hostname lookup is cached by the DUT's
            DNS proxy

    NOTE: The testvar dnsCacheSize should be configured to match the
    minimum size of the DUT's DNS cache.


Test Module Name Synopsis
Verify parallel DNS queries dns.tcl dns_400 Verify parallel DNS queries


    step 1. Initiate a DNS A record lookup for a new unique hostname
            from the LAN client to the configured DNS server
    step 2. Initiate a DNS AAAA record lookup from the LAN client for
            the same hostname used in step 1 to the configured DNS
            server on the same socket as used in step 1
    step 3. Verify that DNS responses are received for both DNS
            queries


Test Module Name Synopsis
Verify DNS does not deploy NXDOMAIN hijacking for type A records dns.tcl dns_410 Verify DNS does not deploy NXDOMAIN hijacking for type A records


    step 1. Initiate a DNS lookup for a new unique type A DNS record from
            the LAN client to the configured DNS server
    step 2. Return DNS response with NXDOMAIN (No such domain reply code)
    step 3. Verify the NXDOMAIN response is returned to the LAN client


    References:

    DNS NXDOMAIN Hijacking

    http://en.wikipedia.org/wiki/DNS_hijacking

Test Module Name Synopsis
Verify DNS does not deploy NXDOMAIN hijacking for type AAAA records dns.tcl dns_411 Verify DNS does not deploy NXDOMAIN hijacking for type AAAA records


    step 1. Initiate a DNS lookup for a new unique type AAAA DNS record from
            the LAN client to the configured DNS server
    step 2. Return DNS response with NXDOMAIN (No such domain reply code)
    step 3. Verify the NXDOMAIN response is returned to the LAN client


    References:

    DNS NXDOMAIN Hijacking

    http://en.wikipedia.org/wiki/DNS_hijacking

Test Module Name Synopsis
Verify DNS proxy handles use of bit 0x20 in DNS labels dns.tcl dns_420 Verify DNS proxy handles use of bit 0x20 in DNS labels


    step 1. Add a new DNS hostname to the DNS servers on the WAN
    step 2. Create a new bit 0x20 version of the DNS hostname
    step 3. Initiate a DNS lookup from the LAN client using the bit 0x20 DNS label
    step 4. Verify the LAN client receives a valid DNS response
    step 5. Repeat this process for 100 variations of the bit 0x20 DNS label


    References:

    IETF Internet-Draft draft-vixie-dnsext-dns0x20-00 "Use of Bit 0x20 in DNS Labels to Improve Transaction Identity"

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00

Test Module Name Synopsis
Verify DNS proxy enforces DNS strict privacy usage profile dns.tcl dns_500 Verify DNS proxy enforces DNS strict privacy usage profile


    step 1. Add a new DNS hostname to the DNS servers on the WAN
    step 2. Initiate a DNS lookup for the new unique hostname from the LAN
            client to the DUT's DNS proxy
    step 3. Verify the LAN client receives a valid DNS response
    step 4. Verify a new DNS request is sent to the primary or backup
            DNS servers using a secure transport


    References:

    IETF RFC 8310 "Usage Profiles for DNS over (D)TLS" Section 5: Usage Profiles

    https://tools.ietf.org/html/rfc8310#section-5


dns-tcp.tcl

DNS over TCP proxy and DNS failover related tests

Test Module Name Synopsis
Verify DNS proxy does not cache DNS entry when DNS TTL is 0 dns-tcp.tcl dns_tcp_10 Verify DNS proxy does not cache DNS entry when DNS TTL is 0


    step 1. Initiate a DNS lookup for a new unique hostname from the LAN
            client to the configured DNS server
    step 2. Return DNS response with TTL set to 0 from WAN DNS server
    step 3. Change the IP address on the DNS server for the new hostname
    step 4. Initiate a new DNS lookup for the same hostname
    step 5. Verify a new DNS request is sent to the primary or backup
            DNS servers

    NOTE: Zero values are interpreted to mean that the RR can only be
    used for the transaction in progress, and should not be cached.


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 3.2.1: Format

    https://tools.ietf.org/html/rfc1035#section-3.2.1

Test Module Name Synopsis
Verify DNS proxy returns TTL of 0 when returned DNS TTL is 0 dns-tcp.tcl dns_tcp_11 Verify DNS proxy returns TTL of 0 when returned DNS TTL is 0


    step 1. Initiate a DNS lookup for a new unique hostname from the LAN
            client to the configured DNS server
    step 2. Return DNS response with TTL set to 0 from WAN DNS server
    step 3. Verify the returned TTL from the DNS proxy is 0

    NOTE: Zero values are interpreted to mean that the RR can only be
    used for the transaction in progress, and should not be cached.


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 3.2.1: Format

    https://tools.ietf.org/html/rfc1035#section-3.2.1

Test Module Name Synopsis
Verify AAAA IPv6 DNS queries to router are forwarded to real DNS server dns-tcp.tcl dns_tcp_40 Verify AAAA IPv6 DNS queries to router are forwarded to real DNS server


    step 1. Initiate an AAAA IPv6 DNS query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS
            server
    step 4. Send a return response back to LAN
    step 5. Verify the response is received by LAN client

    NOTE: The router must support some type of DNS relay or proxy to
    pass this test case. The DNS relay or proxy must understand IPv6 DNS
    type AAAA lookups.


    References:

    IETF RFC 4074 "Common Misbehavior Against DNS Queries for IPv6 Addresses"

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

Test Module Name Synopsis
Verify AAAA IPv6 DNS queries can return no address for IPv6 to IPv4 failover dns-tcp.tcl dns_tcp_41 Verify AAAA IPv6 DNS queries can return no address for IPv6 to IPv4 failover


    step 1. Initiate an AAAA IPv6 DNS query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS
            server
    step 4. Send an empty return response back to LAN
    step 5. Verify the response is received by LAN client

    NOTE: The router must support some type of DNS relay or proxy to
    pass this test case. The DNS relay or proxy must understand IPv6
    DNS type AAAA lookups.


    References:

    IETF RFC 4074 "Common Misbehavior Against DNS Queries for IPv6 Addresses"

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

Test Module Name Synopsis
Verify DNS failover when non-zero error codes are received in non-authoritative DNS response dns-tcp.tcl dns_tcp_45 Verify DNS failover when non-zero error codes are received in non-authoritative DNS response


    step 1. Verify DNS error codes from 1 - 15.
    step 2. For each error code, send 3 DNS queries for a unique
            hostname to the DUT's LAN IP address.
    step 3. Verify a valid DNS response was received for all 3 DNS
            queries.
    step 4. Verify that all 3 DNS queries were received on the same
            WAN DNS server address, known as the current primary DNS
            server address.
    step 5. Configure DNS queries sent to the current primary DNS
            server address to return the error code, and all other DNS
            server addresses to return the normal response.
    step 6. All error responses from the current primary DNS server
            address will have the authoritative bit not set.
    step 7. Send 3 DNS queries for another unique hostname to the
            DUT's LAN IP address.
    step 8. Verify a valid DNS response is received if the error code
            is expected to trigger DNS failover.
    step 9. Verify that a DNS query was received on the current
            primary DNS server address.

    NOTE: Most DNS clients that support multiple DNS servers (primary and
    backup) use some type of failover for certain DNS error codes. The behavior
    for each error code is implementation dependent. The list of error codes
    that will cause DNS failover can be configured using the testvar
    'dnsFailoverAuth'. If no DNS error codes will cause failover, the testvar
    should be configured with the keyword 'none'.

    Example:

    testvar dnsFailoverNonAuth "2 4 5"

    Example with no failover support:

    testvar dnsFailoverNonAuth none

    NOTE: Unix OSes based on bind will normally failover if DNS error
    codes 2, 4, or 5 are received. Windows based OSes will normally
    failover on all DNS error codes except 3 (No Such Name).

    NOTE: In most configurations the DUT will learn the IPv4 and/or IPv6
    addresses of several DNS servers on the WAN. While CDRouter will Initiate
    all DNS queries on the LAN over IPv4 in this test, the DUT may use any of
    the DNS servers in its list (IPv4 of IPv6) for final resolution.


Test Module Name Synopsis
Verify DNS failover when non-zero error codes are received in authoritative DNS response dns-tcp.tcl dns_tcp_46 Verify DNS failover when non-zero error codes are received in authoritative DNS response


    step 1. Verify DNS error codes from 1 - 15.
    step 2. For each error code, send 3 DNS queries for a unique
            hostname to the DUT's LAN IP address.
    step 3. Verify a valid DNS response was received for all 3 DNS
            queries.
    step 4. Verify that all 3 DNS queries were received on the same
            WAN DNS server address, known as the current primary DNS
            server address.
    step 5. Configure DNS queries sent to the current primary DNS
            server address to return the error code, and all other DNS
            server addresses to return the normal response.
    step 6. All error responses from the current primary DNS server
            address will have the authoritative bit set.
    step 7. Send 3 DNS queries for another unique hostname to the
            DUT's LAN IP address.
    step 8. Verify a valid DNS response is received if the error code
            is expected to trigger DNS failover.
    step 9. Verify that a DNS query was received on the current
            primary DNS server address.

    NOTE: Most DNS clients that support multiple DNS servers (primary and
    backup) use some type of failover for certain DNS error codes. The behavior
    for each error code is implementation dependent. The list of error codes
    that will cause DNS failover can be configured using the testvar
    'dnsFailoverAuth'. If no DNS error codes will cause failover, the testvar
    should be configured with the keyword 'none'.

    Example:

    testvar dnsFailoverAuth "2 4 5"

    Example with no failover support:

    testvar dnsFailoverAuth none

    NOTE: Unix OSes based on bind will normally failover if DNS error
    codes 2, 4, or 5 are received. Windows based OSes will normally
    failover on all DNS error codes except 3 (No Such Name).

    NOTE: In most configurations the DUT will learn the IPv4 and/or IPv6
    addresses of several DNS servers on the WAN. While CDRouter will Initiate
    all DNS queries on the LAN over IPv4 in this test, the DUT may use any of
    the DNS servers in its list (IPv4 of IPv6) for final resolution.


Test Module Name Synopsis
Verify Reverse PTR DNS queries to router are forwarded to real DNS server dns-tcp.tcl dns_tcp_50 Verify Reverse PTR DNS queries to router are forwarded to real DNS server


    step 1. Initiate a reverse DNS query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS
            server
    step 4. Send a return response back to LAN
    step 5. Verify the response is received by LAN client

    NOTE: The router must support some type of DNS relay or proxy to
    pass this test case.


Test Module Name Synopsis
Verify Reverse AAAA IPv6 DNS queries to router are forwarded to real DNS server dns-tcp.tcl dns_tcp_51 Verify Reverse AAAA IPv6 DNS queries to router are forwarded to real DNS server


    step 1. Initiate a reverse AAAA IPv6 DNS query from the LAN client
            to the configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS
            server
    step 4. Send a return response back to LAN
    step 5. Verify the response is received by LAN client

    NOTE: The router must support some type of DNS relay or proxy to
    pass this test case.


Test Module Name Synopsis
Verify DNS proxy fails over when new primary DNS server is learned dns-tcp.tcl dns_tcp_60 Verify DNS proxy fails over when new primary DNS server is learned


    step 1. Create a new primary and backup DNS server
    step 2. Terminate the WAN link and bring back up
    step 3. Issue DNS query from the LAN client to the DUT's LAN IP
            address
    step 4. Verify LAN client receives response from new DNS servers
    step 5. If DNS query fails, make additional attempts to allow
            possible failover
    step 6. Terminate the WAN link and bring back up with original DNS
            servers

    NOTE: This test is only run when the WAN mode is dynamic.

    NOTE: The amount of time to wait before checking that DNS has
    been updated after the WAN link is restored can be configured
    using the testvar 'dnsFailoverDelay'. The default is 10 seconds.

    NOTE: In IPv4 and IPv6 dual stack scenarios, the DUT may switch
    over to IPv6 DNS server addresses which have not changed. These
    servers are also unresponsive during the test and the DUT should
    fail over to the new IPv4 DNS servers. The number of DNS queries
    attempted may be configured using the testvar 'dnsFailoverAttempts'.

Test Module Name Synopsis
Verify DNS lookups with multiple IPv4 responses dns-tcp.tcl dns_tcp_70 Verify DNS lookups with multiple IPv4 responses


    step 1. Initiate a DNS lookup for a new unique hostname from the LAN
            client to the configured DNS server
    step 2. Return DNS response with multiple IPv4 answers from WAN DNS
            server
    step 3. Verify LAN client learns all IPv4 answers from DNS lookup


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"

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

Test Module Name Synopsis
Verify DNS proxy recovers after DNS server outage dns-tcp.tcl dns_tcp_100 Verify DNS proxy recovers after DNS server outage


    step 1. Verify initial DNS lookup is working
    step 2. Disable all DNS servers
    step 3. Initiate 3 DNS lookups for new domains which should fail
            from the LAN client to the DUT's LAN IP address
    step 4. Enable all DNS servers
    step 5. Verify DNS lookups start working again

    NOTE: Zero values are interpreted to mean that the RR can only be
    used for the transaction in progress, and should not be cached.


Test Module Name Synopsis
Verify DNS queries including the EDNS0 option dns-tcp.tcl dns_tcp_110 Verify DNS queries including the EDNS0 option


    step 1. Initiate a DNS lookup containing EDNS0 option for a new
            unique hostname from the LAN client to the configured DNS
            server
    step 2. Return DNS response with TTL set to 0 from WAN DNS server
    step 3. Change the IP address on the DNS server for the new hostname
    step 4. Initiate a new DNS lookup containing EDNS0 option for the
            same hostname
    step 5. Verify a new DNS request is sent to the primary or backup
            DNS servers; inclusion of EDNS0 option should not affect
            ability to successfully resolve hostnames

    NOTE: Zero values are interpreted to mean that the RR can only be
    used for the transaction in progress, and should not be cached.


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 3.2.1: Format

    https://tools.ietf.org/html/rfc1035#section-3.2.1

Test Module Name Synopsis
Verify large DNS responses using EDNS0 option dns-tcp.tcl dns_tcp_120 Verify large DNS responses using EDNS0 option


    step 1. Configure a DNS entry with 200 IPv4 matching records that
            requires a UDP response slightly less than 4096
    step 2. Initiate a DNS lookup for a new unique hostname from the LAN
            client to the configured DNS server using EDNS0 option
            announcing a UDP buffer size of 4096
    step 3. Return DNS response with multiple IPv4 answers from WAN DNS
            server
    step 4. Verify LAN client learns all IPv4 answers from DNS lookup


    References:

    IETF RFC 6891 "Extension Mechanisms for DNS (EDNS0)"

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

Test Module Name Synopsis
Verify maximum UDP payload value in EDNS0 option dns-tcp.tcl dns_tcp_121 Verify maximum UDP payload value in EDNS0 option


    step 1. Initiate a DNS lookup for a unique hostname from the LAN
            client to the configured DNS server using EDNS0 option
            announcing a UDP buffer size of 4096
    step 2. Verify DNS response contains EDNS0 option
    step 3. Configure a DNS entry with enough matching IPv4 records that
            requires a UDP response slightly less than the EDNS0 UDP
            buffer size seen in step 2
    step 4. Initiate a DNS lookup for the same hostname from LAN client
            using EDNS0 option announcing a UDP buffer size of 4096
    step 5. Return DNS response with multiple IPv4 answers from WAN DNS
            server
    step 6. Verify LAN client learns all IPv4 answers from DNS lookup


    References:

    IETF RFC 6891 "Extension Mechanisms for DNS (EDNS0)"

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

Test Module Name Synopsis
Verify DNS queries for TXT records dns-tcp.tcl dns_tcp_130 Verify DNS queries for TXT records


    step 1. Initiate a DNS TXT query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS server
    step 4. Send a return TXT response back to LAN
    step 5. Verify the response is received by LAN client


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"

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

Test Module Name Synopsis
Verify DNS queries for CNAME records dns-tcp.tcl dns_tcp_132 Verify DNS queries for CNAME records


    step 1. Initiate a DNS CNAME query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS server
    step 4. Send a return CNAME response back to LAN
    step 5. Verify the response is received by LAN client

    Reference: RFC 1035 Domain names - implementation and specification


Test Module Name Synopsis
Verify DNS queries for responses returning both CNAME and A records dns-tcp.tcl dns_tcp_133 Verify DNS queries for responses returning both CNAME and A records


    step 1. Initiate a DNS query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS server
    step 4. Send both a CNAME and A records response back to LAN
    step 5. Verify the response is received by LAN client with both CNAME
            and A records


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"

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

Test Module Name Synopsis
Verify DNS queries for responses returning both CNAME and AAAA records dns-tcp.tcl dns_tcp_134 Verify DNS queries for responses returning both CNAME and AAAA records


    step 1. Initiate a DNS query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS server
    step 4. Send both a CNAME and AAAA records response back to LAN
    step 5. Verify the response is received by LAN client with both CNAME
            and AAAA records


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"

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

Test Module Name Synopsis
Verify DNS queries for SPF records dns-tcp.tcl dns_tcp_140 Verify DNS queries for SPF records


    step 1. Initiate a DNS SPF query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS
            server
    step 4. Send a return SPF response back to LAN
    step 5. Verify the response is received by LAN client


    References:

    IETF RFC 4408 "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1"

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

Test Module Name Synopsis
Verify DNS queries for SRV records dns-tcp.tcl dns_tcp_141 Verify DNS queries for SRV records


    step 1. Initiate a DNS SRV query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS
            server
    step 4. Send a return SRV response back to LAN
    step 5. Verify the response is received by LAN client
    step 6. Verify the response priority, weight, port and target fields


    References:

    IETF RFC 2782 "A DNS RR for specifying the location of services (DNS SRV)"

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

Test Module Name Synopsis
Verify DNS proxy behavior for DNS server status requests dns-tcp.tcl dns_tcp_150 Verify DNS proxy behavior for DNS server status requests


    step 1. Send a DNS server status request from the LAN client to the
            configured DNS server
    step 2. Verify that the DNS proxy either forwards the server status request
            to the real DNS server or drops it based on the proxy's expected
            behavior

    NOTE: Scanning tools including Nmap utilize DNS server status requests when
    probing a host. Some DNS proxy implementations will drop DNS server status
    requests for security reasons. The testvar dnsForwardServerStatus should be
    set to a value of **no** if this is the expected behavior of the DUT's DNS
    proxy. For DNS proxy implementations that forward server status request
    messages upstream, the testvar dnsForwardServerStatus should be set to av
    alue of **yes**.


    References:

    IETF RFC 5625 "DNS Proxy Implementation Guidelines" Section 3: Transparency Principle

    https://tools.ietf.org/html/rfc5625#section-3

    The DNS Status OPCODE Section 6: Security Considerations

    http://www.eric-a-hall.com/specs/draft-hall-status-opcode-00-1.txt6

Test Module Name Synopsis
Verify DNS proxy does not mangle DNSSEC queries dns-tcp.tcl dns_tcp_200 Verify DNS proxy does not mangle DNSSEC queries


    step 1. Initiate a DNSKEY query from the LAN client to the
            configured DNS server
    step 2. The query may be received by the primary or backup DNS
            server
    step 3. Send a DNSKEY response back to LAN
    step 4. Verify the response is received by LAN client and all fields
            are correct
    step 5. Repeat steps 1-5 for RRSIG, DS, and NSEC queries

    NOTE: The router must support some type of DNS relay or proxy to
    pass this test case.


    References:

    IETF RFC 4034 "Resource Records for the DNS Security Extensions"

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

Test Module Name Synopsis
Verify DNS proxy does not mangle large DNSSEC responses dns-tcp.tcl dns_tcp_201 Verify DNS proxy does not mangle large DNSSEC responses


    step 1. Initiate a DNSKEY query from the LAN client to the
            configured DNS server
    step 2. The query may be received by the primary or backup DNS
            server
    step 3. Send a large RRSIG response (greater than 1220 bytes) back
            to LAN
    step 4. Verify full response is received by LAN client and all
            fields are correct

    NOTE: The router must support some type of DNS relay or proxy to
    pass this test case.


    References:

    IETF RFC 4035 "Protocol Modifications for the DNS Security Extensions" Section 4.1: EDNS Support

    https://tools.ietf.org/html/rfc4035#section-4.1

Test Module Name Synopsis
Verify DHCP server automatically registers DHCP client's hostname in DNS dns-tcp.tcl dns_tcp_210 Verify DHCP server automatically registers DHCP client’s hostname in DNS


    step 1. Perform a DNS lookup on the DHCP client's hostname on LAN
    step 2. Verify DNS record exists and contains correct address

    The DHCP Host Name option can be used to communicate an RFC 1035
    compatible domain name to the DHCP server. This test case verifies
    devices that will automatically populate the local DNS server with
    this hostname entry.


    References:

    IETF RFC 2132 "DHCP Options and BOOTP Vendor Extensions" Section 3.14: Host Name Option

    https://tools.ietf.org/html/rfc2132#section-3.14

Test Module Name Synopsis
Verify DHCP server updates DHCP client's hostname when it changes dns-tcp.tcl dns_tcp_220 Verify DHCP server updates DHCP client’s hostname when it changes


    step 1. Restart DHCP client on LAN with new hostname value
    step 2. Verify DHCP client obtains IPv4 address
    step 3. Perform a DNS lookup on the new DHCP client's hostname on LAN
    step 4. Verify DNS record exists and contains correct address
    step 5. Restore DHCP clients original hostname

    The DHCP Host Name option can be used to communicate an RFC 1035
    compatible domain name to the DHCP server. This test case verifies
    devices that will automatically populate the local DNS server with
    this hostname entry.


    References:

    IETF RFC 2132 "DHCP Options and BOOTP Vendor Extensions" Section 3.14: Host Name Option

    https://tools.ietf.org/html/rfc2132#section-3.14

Test Module Name Synopsis
Verify DHCP server supports FQDN hostname values dns-tcp.tcl dns_tcp_230 Verify DHCP server supports FQDN hostname values


    step 1. Restart DHCP client on LAN with new FQDN hostname value
    step 2. Verify DHCP client obtains IPv4 address
    step 3. Perform a DNS lookup on the new DHCP client's hostname on LAN
    step 4. Verify DNS record exists and contains correct address
    step 5. Restore DHCP clients original hostname

    The DHCP Host Name option may contain a fully qualified name.


    References:

    IETF RFC 2132 "DHCP Options and BOOTP Vendor Extensions" Section 3.14: Host Name Option

    https://tools.ietf.org/html/rfc2132#section-3.14

Test Module Name Synopsis
Verify DNS proxy removes old DHCP hostname values when hostname changes dns-tcp.tcl dns_tcp_240 Verify DNS proxy removes old DHCP hostname values when hostname changes


    step 1. Restart DHCP client on LAN with new hostname value
    step 2. Verify DHCP client obtains IPv4 address
    step 3. Perform a DNS lookup on the new DHCP client's hostname on LAN
    step 4. Verify DNS record exists and contains correct address
    step 5. Restart DHCP client with original hostname
    step 6. Verify DHCP client obtains IPv4 address
    step 7. Perform a DNS lookup on the old DHCP client's hostname on LAN
    step 8. Verify the old hostname is no longer in DNS


    References:

    IETF RFC 2132 "DHCP Options and BOOTP Vendor Extensions" Section 3.14: Host Name Option

    https://tools.ietf.org/html/rfc2132#section-3.14

Test Module Name Synopsis
Verify DHCP server handles DHCP hostname option with maximum size DNS subdomain length dns-tcp.tcl dns_tcp_250 Verify DHCP server handles DHCP hostname option with maximum size DNS subdomain length


    step 1. Restart DHCP client on LAN with new hostname value with total length of 63
    step 2. Verify DHCP client obtains IPv4 address
    step 3. Perform a DNS lookup on the new DHCP client's hostname on LAN
    step 4. Verify DNS record exists and contains correct address
    step 5. Restore DHCP clients original hostname


    References:

    IETF RFC 2132 "DHCP Options and BOOTP Vendor Extensions" Section 3.14: Host Name Option

    https://tools.ietf.org/html/rfc2132#section-3.14

Test Module Name Synopsis
Verify DNS proxy honors TTL values when caching responses dns-tcp.tcl dns_tcp_300 Verify DNS proxy honors TTL values when caching responses


    step 1. Initiate a DNS lookup for a hostname from the LAN client to
            the DUT's LAN IP address
    step 2. Verify DUT's DNS proxy forwards the query to the WAN DNS
            server
    step 3. Change the address on the WAN DNS server for the new
            hostname
    step 4. Wait half the TTL value of the response
    step 5. Perform a DNS lookup on the same hostname from the LAN
    step 6. If supportsDnsCaching is yes, verify DUT's DNS proxy returns
            cached response from step 2 and does not forward the query
            to the WAN DNS server.  If supportsDnsCaching is no, verify
            DUT's DNS proxy forwards the query to the WAN DNS server
    step 7. Wait long enough for the TTL value of the response from
            step 2 to have elapsed
    step 8. Perform a DNS lookup on the same hostname from the LAN
    step 9. Verify DUT's DNS proxy forwards the query to the WAN DNS
            server


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 4.1.3: Resource Record Format

    https://tools.ietf.org/html/rfc1035#section-4.1.3

Test Module Name Synopsis
Verify maximum number of cached DNS responses dns-tcp.tcl dns_tcp_301 Verify maximum number of cached DNS responses


    step 1. Initiate a DNS lookup for a new unique hostname from the LAN
            client to the DUT's LAN IP address
    step 2. Verify that the DUT's DNS proxy forwards the query to the
            WAN DNS server
    step 3. Send a valid response to the DUT on the WAN and verify that
            DUT's DNS proxy forwards this response to the LAN client
    step 4. Repeat steps 1 through 3 (dnsCacheSize + 10) times
    step 5. Repeat steps 1 through 4 but look up the hostnames in
            reverse order
    step 6. Verify that the last 10 hostname lookups are not cached by
            the DUT's DNS proxy

    NOTE: The testvar dnsCacheSize should be configured to match the
    size of the DUT's DNS cache.


Test Module Name Synopsis
Verify parallel DNS queries dns-tcp.tcl dns_tcp_400 Verify parallel DNS queries


    step 1. Initiate a DNS A record lookup for a new unique hostname
            from the LAN client to the configured DNS server.
    step 2. Initiate a DNS AAAA record lookup from the LAN client for
            the same hostname used in step 1 to the configured DNS
            server on the same socket as used in step 1.
    step 3. Verify that DNS responses are received for both DNS
            queries.


Test Module Name Synopsis
Verify DNS does not deploy NXDOMAIN hijacking for type A records dns-tcp.tcl dns_tcp_410 Verify DNS does not deploy NXDOMAIN hijacking for type A records


    step 1. Initiate a DNS lookup for a new unique type A DNS record from
            the LAN client to the configured DNS server
    step 2. Return DNS response with NXDOMAIN (No such domain reply code)
    step 3. Verify the NXDOMAIN response is returned to the LAN client


    References:

    DNS NXDOMAIN Hijacking

    http://en.wikipedia.org/wiki/DNS_hijacking

Test Module Name Synopsis
Verify DNS does not deploy NXDOMAIN hijacking for type AAAA records dns-tcp.tcl dns_tcp_411 Verify DNS does not deploy NXDOMAIN hijacking for type AAAA records


    step 1. Initiate a DNS lookup for a new unique type AAAA DNS record from
            the LAN client to the configured DNS server
    step 2. Return DNS response with NXDOMAIN (No such domain reply code)
    step 3. Verify the NXDOMAIN response is returned to the LAN client


    References:

    DNS NXDOMAIN Hijacking

    http://en.wikipedia.org/wiki/DNS_hijacking

Test Module Name Synopsis
Verify DNS proxy handles use of bit 0x20 in DNS labels dns-tcp.tcl dns_tcp_420 Verify DNS proxy handles use of bit 0x20 in DNS labels


    step 1. Add a new DNS hostname to the DNS servers on the WAN
    step 2. Create a new bit 0x20 version of the DNS hostname    
    step 3. Initiate a DNS lookup from the LAN client using the bit 0x20 DNS label
    step 4. Verify the LAN client receives a valid DNS response
    step 5. Repeat this process for 100 variations of the bit 0x20 DNS label


    References:

    IETF Internet-Draft draft-vixie-dnsext-dns0x20-00 "Use of Bit 0x20 in DNS Labels to Improve Transaction Identity"

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00

Test Module Name Synopsis
Verify DNS proxy enforces DNS strict privacy usage profile dns-tcp.tcl dns_tcp_500 Verify DNS proxy enforces DNS strict privacy usage profile


    step 1. Add a new DNS hostname to the DNS servers on the WAN
    step 2. Initiate a DNS lookup for the new unique hostname from the LAN
            client to the DUT's DNS proxy
    step 3. Verify the LAN client receives a valid DNS response
    step 4. Verify a new DNS request is sent to the primary or backup
            DNS servers using DNS over TLS


    References:

    IETF RFC 8310 "Usage Profiles for DNS over (D)TLS" Section 5: Usage Profiles

    https://tools.ietf.org/html/rfc8310#section-5


dns-tls.tcl

DNS over TLS proxy and DNS failover related tests

Test Module Name Synopsis
Verify DNS proxy does not cache DNS entry when DNS TTL is 0 dns-tls.tcl dns_tls_10 Verify DNS proxy does not cache DNS entry when DNS TTL is 0


    step 1. Initiate a DNS lookup for a new unique hostname from the LAN
            client to the configured DNS server
    step 2. Return DNS response with TTL set to 0 from WAN DNS server
    step 3. Change the IP address on the DNS server for the new hostname
    step 4. Initiate a new DNS lookup for the same hostname
    step 5. Verify a new DNS request is sent to the primary or backup
            DNS servers

    NOTE: Zero values are interpreted to mean that the RR can only be
    used for the transaction in progress, and should not be cached.


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 3.2.1: Format

    https://tools.ietf.org/html/rfc1035#section-3.2.1

Test Module Name Synopsis
Verify DNS proxy returns TTL of 0 when returned DNS TTL is 0 dns-tls.tcl dns_tls_11 Verify DNS proxy returns TTL of 0 when returned DNS TTL is 0


    step 1. Initiate a DNS lookup for a new unique hostname from the LAN
            client to the configured DNS server
    step 2. Return DNS response with TTL set to 0 from WAN DNS server
    step 3. Verify the returned TTL from the DNS proxy is 0

    NOTE: Zero values are interpreted to mean that the RR can only be
    used for the transaction in progress, and should not be cached.


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 3.2.1: Format

    https://tools.ietf.org/html/rfc1035#section-3.2.1

Test Module Name Synopsis
Verify AAAA IPv6 DNS queries to router are forwarded to real DNS server dns-tls.tcl dns_tls_40 Verify AAAA IPv6 DNS queries to router are forwarded to real DNS server


    step 1. Initiate an AAAA IPv6 DNS query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS
            server
    step 4. Send a return response back to LAN
    step 5. Verify the response is received by LAN client

    NOTE: The router must support some type of DNS relay or proxy to
    pass this test case. The DNS relay or proxy must understand IPv6 DNS
    type AAAA lookups.


    References:

    IETF RFC 4074 "Common Misbehavior Against DNS Queries for IPv6 Addresses"

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

Test Module Name Synopsis
Verify AAAA IPv6 DNS queries can return no address for IPv6 to IPv4 failover dns-tls.tcl dns_tls_41 Verify AAAA IPv6 DNS queries can return no address for IPv6 to IPv4 failover


    step 1. Initiate an AAAA IPv6 DNS query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS
            server
    step 4. Send an empty return response back to LAN
    step 5. Verify the response is received by LAN client

    NOTE: The router must support some type of DNS relay or proxy to
    pass this test case. The DNS relay or proxy must understand IPv6
    DNS type AAAA lookups.


    References:

    IETF RFC 4074 "Common Misbehavior Against DNS Queries for IPv6 Addresses"

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

Test Module Name Synopsis
Verify DNS failover when non-zero error codes are received in non-authoritative DNS response dns-tls.tcl dns_tls_45 Verify DNS failover when non-zero error codes are received in non-authoritative DNS response


    step 1. Verify DNS error codes from 1 - 15.
    step 2. For each error code, send 3 DNS queries for a unique
            hostname to the DUT's LAN IP address.
    step 3. Verify a valid DNS response was received for all 3 DNS
            queries.
    step 4. Verify that all 3 DNS queries were received on the same
            WAN DNS server address, known as the current primary DNS
            server address.
    step 5. Configure DNS queries sent to the current primary DNS
            server address to return the error code, and all other DNS
            server addresses to return the normal response.
    step 6. All error responses from the current primary DNS server
            address will have the authoritative bit not set.
    step 7. Send 3 DNS queries for another unique hostname to the
            DUT's LAN IP address.
    step 8. Verify a valid DNS response is received if the error code
            is expected to trigger DNS failover.
    step 9. Verify that a DNS query was received on the current
            primary DNS server address.

    NOTE: Most DNS clients that support multiple DNS servers (primary and
    backup) use some type of failover for certain DNS error codes. The behavior
    for each error code is implementation dependent. The list of error codes
    that will cause DNS failover can be configured using the testvar
    'dnsFailoverAuth'. If no DNS error codes will cause failover, the testvar
    should be configured with the keyword 'none'.

    Example:

    testvar dnsFailoverNonAuth "2 4 5"

    Example with no failover support:

    testvar dnsFailoverNonAuth none

    NOTE: Unix OSes based on bind will normally failover if DNS error
    codes 2, 4, or 5 are received. Windows based OSes will normally
    failover on all DNS error codes except 3 (No Such Name).

    NOTE: In most configurations the DUT will learn the IPv4 and/or IPv6
    addresses of several DNS servers on the WAN. While CDRouter will Initiate
    all DNS queries on the LAN over IPv4 in this test, the DUT may use any of
    the DNS servers in its list (IPv4 of IPv6) for final resolution.


Test Module Name Synopsis
Verify DNS failover when non-zero error codes are received in authoritative DNS response dns-tls.tcl dns_tls_46 Verify DNS failover when non-zero error codes are received in authoritative DNS response


    step 1. Verify DNS error codes from 1 - 15.
    step 2. For each error code, send 3 DNS queries for a unique
            hostname to the DUT's LAN IP address.
    step 3. Verify a valid DNS response was received for all 3 DNS
            queries.
    step 4. Verify that all 3 DNS queries were received on the same
            WAN DNS server address, known as the current primary DNS
            server address.
    step 5. Configure DNS queries sent to the current primary DNS
            server address to return the error code, and all other DNS
            server addresses to return the normal response.
    step 6. All error responses from the current primary DNS server
            address will have the authoritative bit set.
    step 7. Send 3 DNS queries for another unique hostname to the
            DUT's LAN IP address.
    step 8. Verify a valid DNS response is received if the error code
            is expected to trigger DNS failover.
    step 9. Verify that a DNS query was received on the current
            primary DNS server address.

    NOTE: Most DNS clients that support multiple DNS servers (primary and
    backup) use some type of failover for certain DNS error codes. The behavior
    for each error code is implementation dependent. The list of error codes
    that will cause DNS failover can be configured using the testvar
    'dnsFailoverAuth'. If no DNS error codes will cause failover, the testvar
    should be configured with the keyword 'none'.

    Example:

    testvar dnsFailoverAuth "2 4 5"

    Example with no failover support:

    testvar dnsFailoverAuth none

    NOTE: Unix OSes based on bind will normally failover if DNS error
    codes 2, 4, or 5 are received. Windows based OSes will normally
    failover on all DNS error codes except 3 (No Such Name).

    NOTE: In most configurations the DUT will learn the IPv4 and/or IPv6
    addresses of several DNS servers on the WAN. While CDRouter will Initiate
    all DNS queries on the LAN over IPv4 in this test, the DUT may use any of
    the DNS servers in its list (IPv4 of IPv6) for final resolution.


Test Module Name Synopsis
Verify Reverse PTR DNS queries to router are forwarded to real DNS server dns-tls.tcl dns_tls_50 Verify Reverse PTR DNS queries to router are forwarded to real DNS server


    step 1. Initiate a reverse DNS query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS
            server
    step 4. Send a return response back to LAN
    step 5. Verify the response is received by LAN client

    NOTE: The router must support some type of DNS relay or proxy to
    pass this test case.


Test Module Name Synopsis
Verify Reverse AAAA IPv6 DNS queries to router are forwarded to real DNS server dns-tls.tcl dns_tls_51 Verify Reverse AAAA IPv6 DNS queries to router are forwarded to real DNS server


    step 1. Initiate a reverse AAAA IPv6 DNS query from the LAN client
            to the configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS
            server
    step 4. Send a return response back to LAN
    step 5. Verify the response is received by LAN client

    NOTE: The router must support some type of DNS relay or proxy to
    pass this test case.


Test Module Name Synopsis
Verify DNS proxy fails over when new primary DNS server is learned dns-tls.tcl dns_tls_60 Verify DNS proxy fails over when new primary DNS server is learned


    step 1. Create a new primary and backup DNS server
    step 2. Terminate the WAN link and bring back up
    step 3. Issue DNS query from the LAN client to the DUT's LAN IP
            address
    step 4. Verify LAN client receives response from new DNS servers
    step 5. If DNS query fails, make additional attempts to allow
            possible failover
    step 6. Terminate the WAN link and bring back up with original DNS
            servers

    NOTE: This test is only run when the WAN mode is dynamic.

    NOTE: The amount of time to wait before checking that DNS has
    been updated after the WAN link is restored can be configured
    using the testvar 'dnsFailoverDelay'. The default is 10 seconds.

    NOTE: In IPv4 and IPv6 dual stack scenarios, the DUT may switch
    over to IPv6 DNS server addresses which have not changed. These
    servers are also unresponsive during the test and the DUT should
    fail over to the new IPv4 DNS servers. The number of DNS queries
    attempted may be configured using the testvar 'dnsFailoverAttempts'.

Test Module Name Synopsis
Verify DNS lookups with multiple IPv4 responses dns-tls.tcl dns_tls_70 Verify DNS lookups with multiple IPv4 responses


    step 1. Initiate a DNS lookup for a new unique hostname from the LAN
            client to the configured DNS server
    step 2. Return DNS response with multiple IPv4 answers from WAN DNS
            server
    step 3. Verify LAN client learns all IPv4 answers from DNS lookup


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"

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

Test Module Name Synopsis
Verify DNS proxy recovers after DNS server outage dns-tls.tcl dns_tls_100 Verify DNS proxy recovers after DNS server outage


    step 1. Verify initial DNS lookup is working
    step 2. Disable all DNS servers
    step 3. Initiate 3 DNS lookups for new domains which should fail
            from the LAN client to the DUT's LAN IP address
    step 4. Enable all DNS servers
    step 5. Verify DNS lookups start working again

    NOTE: Zero values are interpreted to mean that the RR can only be
    used for the transaction in progress, and should not be cached.


Test Module Name Synopsis
Verify DNS queries including the EDNS0 option dns-tls.tcl dns_tls_110 Verify DNS queries including the EDNS0 option


    step 1. Initiate a DNS lookup containing EDNS0 option for a new
            unique hostname from the LAN client to the configured DNS
            server
    step 2. Return DNS response with TTL set to 0 from WAN DNS server
    step 3. Change the IP address on the DNS server for the new hostname
    step 4. Initiate a new DNS lookup containing EDNS0 option for the
            same hostname
    step 5. Verify a new DNS request is sent to the primary or backup
            DNS servers; inclusion of EDNS0 option should not affect
            ability to successfully resolve hostnames

    NOTE: Zero values are interpreted to mean that the RR can only be
    used for the transaction in progress, and should not be cached.


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 3.2.1: Format

    https://tools.ietf.org/html/rfc1035#section-3.2.1

Test Module Name Synopsis
Verify large DNS responses using EDNS0 option dns-tls.tcl dns_tls_120 Verify large DNS responses using EDNS0 option


    step 1. Configure a DNS entry with 200 IPv4 matching records that
            requires a UDP response slightly less than 4096
    step 2. Initiate a DNS lookup for a new unique hostname from the LAN
            client to the configured DNS server using EDNS0 option
            announcing a UDP buffer size of 4096
    step 3. Return DNS response with multiple IPv4 answers from WAN DNS
            server
    step 4. Verify LAN client learns all IPv4 answers from DNS lookup


    References:

    IETF RFC 6891 "Extension Mechanisms for DNS (EDNS0)"

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

Test Module Name Synopsis
Verify maximum UDP payload value in EDNS0 option dns-tls.tcl dns_tls_121 Verify maximum UDP payload value in EDNS0 option


    step 1. Initiate a DNS lookup for a unique hostname from the LAN
            client to the configured DNS server using EDNS0 option
            announcing a UDP buffer size of 4096
    step 2. Verify DNS response contains EDNS0 option
    step 3. Configure a DNS entry with enough matching IPv4 records that
            requires a UDP response slightly less than the EDNS0 UDP
            buffer size seen in step 2
    step 4. Initiate a DNS lookup for the same hostname from LAN client
            using EDNS0 option announcing a UDP buffer size of 4096
    step 5. Return DNS response with multiple IPv4 answers from WAN DNS
            server
    step 6. Verify LAN client learns all IPv4 answers from DNS lookup


    References:

    IETF RFC 6891 "Extension Mechanisms for DNS (EDNS0)"

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

Test Module Name Synopsis
Verify DNS queries for TXT records dns-tls.tcl dns_tls_130 Verify DNS queries for TXT records


    step 1. Initiate a DNS TXT query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS server
    step 4. Send a return TXT response back to LAN
    step 5. Verify the response is received by LAN client


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"

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

Test Module Name Synopsis
Verify DNS queries for CNAME records dns-tls.tcl dns_tls_132 Verify DNS queries for CNAME records


    step 1. Initiate a DNS CNAME query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS server
    step 4. Send a return CNAME response back to LAN
    step 5. Verify the response is received by LAN client


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"

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

Test Module Name Synopsis
Verify DNS queries for responses returning both CNAME and A records dns-tls.tcl dns_tls_133 Verify DNS queries for responses returning both CNAME and A records


    step 1. Initiate a DNS query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS server
    step 4. Send both a CNAME and A records response back to LAN
    step 5. Verify the response is received by LAN client with both CNAME
            and A records


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"

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

Test Module Name Synopsis
Verify DNS queries for responses returning both CNAME and AAAA records dns-tls.tcl dns_tls_134 Verify DNS queries for responses returning both CNAME and AAAA records


    step 1. Initiate a DNS query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS server
    step 4. Send both a CNAME and AAAA records response back to LAN
    step 5. Verify the response is received by LAN client with both CNAME
            and AAAA records


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION"

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

Test Module Name Synopsis
Verify DNS queries for SPF records dns-tls.tcl dns_tls_140 Verify DNS queries for SPF records


    step 1. Initiate a DNS SPF query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS
            server
    step 4. Send a return SPF response back to LAN
    step 5. Verify the response is received by LAN client


    References:

    IETF RFC 4408 "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1"

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

Test Module Name Synopsis
Verify DNS queries for SRV records dns-tls.tcl dns_tls_141 Verify DNS queries for SRV records


    step 1. Initiate a DNS SRV query from the LAN client to the
            configured DNS server
    step 2. Verify the query is received by real DNS server on the WAN
            side
    step 3. The query may be received by the primary or backup DNS
            server
    step 4. Send a return SRV response back to LAN
    step 5. Verify the response is received by LAN client
    step 6. Verify the response priority, weight, port and target fields


    References:

    IETF RFC 2782 "A DNS RR for specifying the location of services (DNS SRV)"

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

Test Module Name Synopsis
Verify DNS proxy behavior for DNS server status requests dns-tls.tcl dns_tls_150 Verify DNS proxy behavior for DNS server status requests


    step 1. Send a DNS server status request from the LAN client to the
            configured DNS server
    step 2. Verify that the DNS proxy either forwards the server status request
            to the real DNS server or drops it based on the proxy's expected
            behavior

    NOTE: Scanning tools including Nmap utilize DNS server status requests when
    probing a host. Some DNS proxy implementations will drop DNS server status
    requests for security reasons. The testvar dnsForwardServerStatus should be
    set to a value of **no** if this is the expected behavior of the DUT's DNS
    proxy. For DNS proxy implementations that forward server status request
    messages upstream, the testvar dnsForwardServerStatus should be set to av
    alue of **yes**.


    References:

    IETF RFC 5625 "DNS Proxy Implementation Guidelines" Section 3: Transparency Principle

    https://tools.ietf.org/html/rfc5625#section-3

    The DNS Status OPCODE Section 6: Security Considerations

    http://www.eric-a-hall.com/specs/draft-hall-status-opcode-00-1.txt6

Test Module Name Synopsis
Verify DNS proxy does not mangle DNSSEC queries dns-tls.tcl dns_tls_200 Verify DNS proxy does not mangle DNSSEC queries


    step 1. Initiate a DNSKEY query from the LAN client to the
            configured DNS server
    step 2. The query may be received by the primary or backup DNS
            server
    step 3. Send a DNSKEY response back to LAN
    step 4. Verify the response is received by LAN client and all fields
            are correct
    step 5. Repeat steps 1-5 for RRSIG, DS, and NSEC queries

    NOTE: The router must support some type of DNS relay or proxy to
    pass this test case.


    References:

    IETF RFC 4034 "Resource Records for the DNS Security Extensions"

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

Test Module Name Synopsis
Verify DNS proxy does not mangle large DNSSEC responses dns-tls.tcl dns_tls_201 Verify DNS proxy does not mangle large DNSSEC responses


    step 1. Initiate a DNSKEY query from the LAN client to the
            configured DNS server
    step 2. The query may be received by the primary or backup DNS
            server
    step 3. Send a large RRSIG response (greater than 1220 bytes) back
            to LAN
    step 4. Verify full response is received by LAN client and all
            fields are correct

    NOTE: The router must support some type of DNS relay or proxy to
    pass this test case.


    References:

    IETF RFC 4035 "Protocol Modifications for the DNS Security Extensions" Section 4.1: EDNS Support

    https://tools.ietf.org/html/rfc4035#section-4.1

Test Module Name Synopsis
Verify DHCP server automatically registers DHCP client's hostname in DNS dns-tls.tcl dns_tls_210 Verify DHCP server automatically registers DHCP client’s hostname in DNS


    step 1. Perform a DNS lookup on the DHCP client's hostname on LAN
    step 2. Verify DNS record exists and contains correct address

    The DHCP Host Name option can be used to communicate an RFC 1035
    compatible domain name to the DHCP server. This test case verifies
    devices that will automatically populate the local DNS server with
    this hostname entry.


    References:

    IETF RFC 2132 "DHCP Options and BOOTP Vendor Extensions" Section 3.14: Host Name Option

    https://tools.ietf.org/html/rfc2132#section-3.14

Test Module Name Synopsis
Verify DHCP server updates DHCP client's hostname when it changes dns-tls.tcl dns_tls_220 Verify DHCP server updates DHCP client’s hostname when it changes


    step 1. Restart DHCP client on LAN with new hostname value
    step 2. Verify DHCP client obtains IPv4 address
    step 3. Perform a DNS lookup on the new DHCP client's hostname on LAN
    step 4. Verify DNS record exists and contains correct address
    step 5. Restore DHCP clients original hostname

    The DHCP Host Name option can be used to communicate an RFC 1035
    compatible domain name to the DHCP server. This test case verifies
    devices that will automatically populate the local DNS server with
    this hostname entry.


    References:

    IETF RFC 2132 "DHCP Options and BOOTP Vendor Extensions" Section 3.14: Host Name Option

    https://tools.ietf.org/html/rfc2132#section-3.14

Test Module Name Synopsis
Verify DHCP server supports FQDN hostname values dns-tls.tcl dns_tls_230 Verify DHCP server supports FQDN hostname values


    step 1. Restart DHCP client on LAN with new FQDN hostname value
    step 2. Verify DHCP client obtains IPv4 address
    step 3. Perform a DNS lookup on the new DHCP client's hostname on LAN
    step 4. Verify DNS record exists and contains correct address
    step 5. Restore DHCP clients original hostname

    The DHCP Host Name option may contain a fully qualified name.


    References:

    IETF RFC 2132 "DHCP Options and BOOTP Vendor Extensions" Section 3.14: Host Name Option

    https://tools.ietf.org/html/rfc2132#section-3.14

Test Module Name Synopsis
Verify DNS proxy removes old DHCP hostname values when hostname changes dns-tls.tcl dns_tls_240 Verify DNS proxy removes old DHCP hostname values when hostname changes


    step 1. Restart DHCP client on LAN with new hostname value
    step 2. Verify DHCP client obtains IPv4 address
    step 3. Perform a DNS lookup on the new DHCP client's hostname on LAN
    step 4. Verify DNS record exists and contains correct address
    step 5. Restart DHCP client with original hostname
    step 6. Verify DHCP client obtains IPv4 address
    step 7. Perform a DNS lookup on the old DHCP client's hostname on LAN
    step 8. Verify the old hostname is no longer in DNS


    References:

    IETF RFC 2132 "DHCP Options and BOOTP Vendor Extensions" Section 3.14: Host Name Option

    https://tools.ietf.org/html/rfc2132#section-3.14

Test Module Name Synopsis
Verify DHCP server handles DHCP hostname option with maximum size DNS subdomain length dns-tls.tcl dns_tls_250 Verify DHCP server handles DHCP hostname option with maximum size DNS subdomain length


    step 1. Restart DHCP client on LAN with new hostname value with total length of 63
    step 2. Verify DHCP client obtains IPv4 address
    step 3. Perform a DNS lookup on the new DHCP client's hostname on LAN
    step 4. Verify DNS record exists and contains correct address
    step 5. Restore DHCP clients original hostname


    References:

    IETF RFC 2132 "DHCP Options and BOOTP Vendor Extensions" Section 3.14: Host Name Option

    https://tools.ietf.org/html/rfc2132#section-3.14

Test Module Name Synopsis
Verify DNS proxy honors TTL values when caching responses dns-tls.tcl dns_tls_300 Verify DNS proxy honors TTL values when caching responses


    step 1. Initiate a DNS lookup for a hostname from the LAN client to
            the DUT's LAN IP address
    step 2. Verify DUT's DNS proxy forwards the query to the WAN DNS
            server
    step 3. Change the address on the WAN DNS server for the new
            hostname
    step 4. Wait half the TTL value of the response
    step 5. Perform a DNS lookup on the same hostname from the LAN
    step 6. If supportsDnsCaching is yes, verify DUT's DNS proxy returns
            cached response from step 2 and does not forward the query
            to the WAN DNS server.  If supportsDnsCaching is no, verify
            DUT's DNS proxy forwards the query to the WAN DNS server
    step 7. Wait long enough for the TTL value of the response from
            step 2 to have elapsed
    step 8. Perform a DNS lookup on the same hostname from the LAN
    step 9. Verify DUT's DNS proxy forwards the query to the WAN DNS
            server


    References:

    IETF RFC 1035 "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION" Section 4.1.3: Resource Record Format

    https://tools.ietf.org/html/rfc1035#section-4.1.3

Test Module Name Synopsis
Verify maximum number of cached DNS responses dns-tls.tcl dns_tls_301 Verify maximum number of cached DNS responses


    step 1. Initiate a DNS lookup for a new unique hostname from the LAN
            client to the DUT's LAN IP address
    step 2. Verify that the DUT's DNS proxy forwards the query to the
            WAN DNS server
    step 3. Send a valid response to the DUT on the WAN and verify that
            DUT's DNS proxy forwards this response to the LAN client
    step 4. Repeat steps 1 through 3 (dnsCacheSize + 10) times
    step 5. Repeat steps 1 through 4 but look up the hostnames in
            reverse order
    step 6. Verify that the last 10 hostname lookups are not cached by
            the DUT's DNS proxy

    NOTE: The testvar dnsCacheSize should be configured to match the
    size of the DUT's DNS cache.


Test Module Name Synopsis
Verify parallel DNS queries dns-tls.tcl dns_tls_400 Verify parallel DNS queries


    step 1. Initiate a DNS A record lookup for a new unique hostname
            from the LAN client to the configured DNS server.
    step 2. Initiate a DNS AAAA record lookup from the LAN client for
            the same hostname used in step 1 to the configured DNS
            server on the same socket as used in step 1.
    step 3. Verify that DNS responses are received for both DNS
            queries.


Test Module Name Synopsis
Verify DNS does not deploy NXDOMAIN hijacking for type A records dns-tls.tcl dns_tls_410 Verify DNS does not deploy NXDOMAIN hijacking for type A records


    step 1. Initiate a DNS lookup for a new unique type A DNS record from
            the LAN client to the configured DNS server
    step 2. Return DNS response with NXDOMAIN (No such domain reply code)
    step 3. Verify the NXDOMAIN response is returned to the LAN client

    NXDOMAIN hijacking is used to modify negative DNS responses. It
    is generally considered poor form and may break DNS services that
    depend on receiving NXDOMAIN responses.


    References:

    DNS NXDOMAIN Hijacking

    http://en.wikipedia.org/wiki/DNS_hijacking

Test Module Name Synopsis
Verify DNS does not deploy NXDOMAIN hijacking for type AAAA records dns-tls.tcl dns_tls_411 Verify DNS does not deploy NXDOMAIN hijacking for type AAAA records


    step 1. Initiate a DNS lookup for a new unique type AAAA DNS record from
            the LAN client to the configured DNS server
    step 2. Return DNS response with NXDOMAIN (No such domain reply code)
    step 3. Verify the NXDOMAIN response is returned to the LAN client

    NXDOMAIN hijacking is used to modify negative DNS responses. It
    is generally considered poor form and may break DNS services that
    depend on receiving NXDOMAIN responses.


    References:

    DNS NXDOMAIN Hijacking

    http://en.wikipedia.org/wiki/DNS_hijacking

Test Module Name Synopsis
Verify DNS proxy handles use of bit 0x20 in DNS labels dns-tls.tcl dns_tls_420 Verify DNS proxy handles use of bit 0x20 in DNS labels


    step 1. Add a new DNS hostname to the DNS servers on the WAN
    step 2. Create a new bit 0x20 version of the DNS hostname
    step 3. Initiate a DNS lookup from the LAN client using the bit 0x20 DNS label
    step 4. Verify the LAN client receives a valid DNS response
    step 5. Repeat this process for 100 variations of the bit 0x20 DNS label


    References:

    IETF Internet-Draft draft-vixie-dnsext-dns0x20-00 "Use of Bit 0x20 in DNS Labels to Improve Transaction Identity"

    https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00

Test Module Name Synopsis
Verify DNS proxy enforces DNS strict privacy usage profile dns-tls.tcl dns_tls_500 Verify DNS proxy enforces DNS strict privacy usage profile


    step 1. Add a new DNS hostname to the DNS servers on the WAN
    step 2. Initiate a DNS lookup for the new unique hostname from the LAN
            client to the DUT's DNS proxy
    step 3. Verify the LAN client receives a valid DNS response
    step 4. Verify a new DNS request is sent to the primary or backup
            DNS servers using DNS over TLS


    References:

    IETF RFC 8310 "Usage Profiles for DNS over (D)TLS" Section 5: Usage Profiles

    https://tools.ietf.org/html/rfc8310#section-5


mdns.tcl

mDNS related test cases

Test Module Name Synopsis
Verify DUT responds to mDNS query of its hostname mdns.tcl mdns_10 Verify DUT responds to mDNS query of its hostname


    step 1. Initiate a one-shot mDNS query from the LAN for the A
            record of the DUT's LAN hostname in the top-level domain
            'local'.
    step 2. Verify the mDNS query succeeds and the response contains
            the DUT's LAN address.

    NOTE: The DUT's expected LAN hostname is taken from the testvar
          lanHostname.


    References:

    IETF RFC 6762 "Multicast DNS"

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

Test Module Name Synopsis
Verify DUT responds to mDNS reverse query of its LAN IP mdns.tcl mdns_11 Verify DUT responds to mDNS reverse query of its LAN IP


    step 1. Initiate a on-shot mDNS query from the LAN for the reverse
            mapping of the DUT's LAN address.
    step 2. Verify the mDNS query succeeds and the response contains
            the DUT's LAN hostname in the top-level domain 'local'.

    NOTE: The DUT's expected LAN hostname is taken from the testvar
          lanHostname.


    References:

    IETF RFC 6762 "Multicast DNS"

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

Test Module Name Synopsis
Verify DUT returns DNS-Service Discovery records for its web server mdns.tcl mdns_12 Verify DUT returns DNS-Service Discovery records for its web server


    step 1. Initiate a one-shot mDNS query from the LAN for the DUT's
            _services._dns-sd._udp.local PTR record.
    step 2. Verify that the mDNS query succeeds and the response
            contains the _http._tcp.local domain.
    step 3. Initiate a one-shot mDNS query from the LAN for the DUT's
            _http._tcp.local PTR record.
    step 4. Verify that mDNS query succeeds.
    step 5. Initiate a one-shot mDNS query from the LAN for the
            SRV record of the resource returned in step 4.
    step 6. Verify that the mDNS query succeeds and the response
            contains the DUT's management port and the domain
            LANHOSTNAME.local.
    step 7. Initiate a one-shot mDNS query from the LAN for the A
            record of LANHOSTNAME.local.
    step 8. Verify that the mDNS query succeeds and the response
            contains the DUT's LAN address.
    step 9. Initiate an HTTP GET of the URL http://LANHOSTNAME:80 from
            the LAN.
    step 10. Verify that the HTTP GET succeeds.

    NOTE: The value of LANHOSTNAME is taken from the value of the
          lanHostname testvar.

    NOTE: The value of the DUT's management port is taken from the
          default insecure management port defined as the first port
          in the value of testvar dutMgmtPort.  Please read the
          documentation for dutMgmtPort for more information about the
          default insecure management port concept and its usage.


    References:

    IETF RFC 6762 "Multicast DNS"

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

    IETF RFC 6763 "DNS-Based Service Discovery"

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

Test Module Name Synopsis
Verify DUT does not forward LAN mDNS query onto the WAN mdns.tcl mdns_13 Verify DUT does not forward LAN mDNS query onto the WAN


    step 1. Initiate a one-shot mDNS query from the LAN destined for
            IPv4 multicast local network control block address
            224.0.0.251.
    step 2. Verify that the mDNS query is not forwarded on the WAN.


    References:

    IETF RFC 6762 "Multicast DNS"

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

    IETF RFC 5771 "IANA Guidelines for IPv4 Multicast Address Assignments" Section 4: Local Network Control Block (224.0.0/24)

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


dns-rfc5625.tcl

IETF RFC 5625 DNS Proxy Implementation Guidelines

Test Module Name Synopsis
A DNS proxy must forward unknown DNS flags and data dns-rfc5625.tcl dns_rfc5625_10 A DNS proxy must forward unknown DNS flags and data


    step 1. Initiate a new DNS lookup for a new unique hostname from LAN client
    step 2. Return DNS response with Z flag set to 1
    step 3. Verify the DNS packet is received by the LAN client


    References:

    IETF RFC 5625 "DNS Proxy Implementation Guidelines" Section 4.1: Unexpected Flags and Data

    https://tools.ietf.org/html/rfc5625#section-4.1

Test Module Name Synopsis
A DNS proxy must forward DNS packets regardless of compressed labels dns-rfc5625.tcl dns_rfc5625_11 A DNS proxy must forward DNS packets regardless of compressed labels


    step 1. Forward a DNS query to the DUT's DNS forwarder that will generate
            a DNS reply with multiple answers using compression labels
    step 2. Verify that the DNS reply uses compression labels.


    References:

    IETF RFC 5625 "DNS Proxy Implementation Guidelines" Section 4.2: Label Compression

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

Test Module Name Synopsis
A DNS proxy must forward DNS packets regardless of qtype and qclass fields dns-rfc5625.tcl dns_rfc5625_12 A DNS proxy must forward DNS packets regardless of qtype and qclass fields


    step 1. Initiate a DNS lookup using an UNKNOWN class type
    step 2. Return DNS response with an UNKNOWN class type from WAN DNS Server
    step 3. Verify the DNS packet is received by the LAN client


    References:

    IETF RFC 5625 "DNS Proxy Implementation Guidelines" Section 4.3: Unknown Resource Record Types

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

Test Module Name Synopsis
A DNS proxy must always preserve the TC bit dns-rfc5625.tcl dns_rfc5625_13 A DNS proxy must always preserve the TC bit

    step 1. Send a DNS request via the DNS proxy that will solicit
            a response that artificially has the TC bit set.
    step 2. Verify that the DNS packet is received by the LAN client
            and that the proxy has not reset the TC bit

    NOTE: Section 4.4 of RFC 5625 covers several scenarios in which the DNS
    proxy can incorrectly strip the TC (TrunCated) bit. The proxy may truncate
    the response, or may not, but regardless it must not interfere with a TC bit
    that has already been set to 1.


    References:

    IETF RFC 5625 "DNS Proxy Implementation Guidelines" Section 4.4: Packet Size Limits

    https://tools.ietf.org/html/rfc5625#section-4.4

Test Module Name Synopsis
A DNS proxy must be able to forward DNS over TCP dns-rfc5625.tcl dns_rfc5625_14 A DNS proxy must be able to forward DNS over TCP


    step 1. Force the LAN client to send a DNS request over TCP to the DUT DNS proxy.
    step 2. Verify that the upstream DNS reply is returned by the DNS proxy to the lan client.


    References:

    IETF RFC 5625 "DNS Proxy Implementation Guidelines" Section 4.4.1: TCP Transport

    https://tools.ietf.org/html/rfc5625#section-4.4.1

Test Module Name Synopsis
A DNS proxy should not convert a TCP lookup into a UDP lookup dns-rfc5625.tcl dns_rfc5625_15 A DNS proxy should not convert a TCP lookup into a UDP lookup


    step 1. Send a TCP DNS request via the DUT DNS proxy.
    step 2. Verify the DUT did not convert the original TCP DNS query to UDP


    References:

    IETF RFC 5625 "DNS Proxy Implementation Guidelines" Section 4.4.1: TCP Transport

    https://tools.ietf.org/html/rfc5625#section-4.4.1

Test Module Name Synopsis
A DNS proxy should be able to forward EDNS0 UDP packets at least 4096 bytes in size dns-rfc5625.tcl dns_rfc5625_17 A DNS proxy should be able to forward EDNS0 UDP packets at least 4096 bytes in size


    step 1. Configure a DNS entry with 200 IPv4 matching records that
            requires a UDP response slightly less than 4096
    step 2. Initiate a DNS lookup for a new unique hostname from LAN client
            using EDNS0 option announcing a UDP buffer size of 4096
    step 3. Return DNS response with multiple IPv4 answers from WAN DNS server
    step 4. Verify LAN client learns all IPv4 answers from DNS lookup


    References:

    IETF RFC 2671 "Extension Mechanisms for DNS (EDNS0)"

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

    IETF RFC 5625 "DNS Proxy Implementation Guidelines" Section 4.4.3: IP Fragmentation

    https://tools.ietf.org/html/rfc5625#section-4.4.3

Test Module Name Synopsis
A LAN Client should be able to send a DNS query directly to upstream server dns-rfc5625.tcl dns_rfc5625_19 A LAN Client should be able to send a DNS query directly to upstream server


    step 1. Send a DNS query of any variety directly from the LAN client to the remote
            DNS server
    step 2. Verify the Query ID is the same as the one sent by the LAN client


    References:

    IETF RFC 5625 "DNS Proxy Implementation Guidelines" Section 5.1: Domain Name Server (DHCP Option 6)

    https://tools.ietf.org/html/rfc5625#section-5.1

Test Module Name Synopsis
A DNS query ID from a DNS proxy should not increase monotonically dns-rfc5625.tcl dns_rfc5625_22 A DNS query ID from a DNS proxy should not increase monotonically


    step 1. Send two DNS queries upstream from the LAN client to the DNS proxy
    step 2. Inspect the Query IDs created by the DNS Proxy.  Verify they are non-sequential


    References:

    IETF RFC 5625 "DNS Proxy Implementation Guidelines" Section 6.1: Forgery Resilience

    https://tools.ietf.org/html/rfc5625#section-6.1

Test Module Name Synopsis
A DNS proxy should not accept connections on the WAN port dns-rfc5625.tcl dns_rfc5625_23 A DNS proxy should not accept connections on the WAN port


    step 1. Send a DNS query from a WAN client to the WAN interface of the DUT
    step 2. Verify that a response is not received


    References:

    IETF RFC 5625 "DNS Proxy Implementation Guidelines" Section 6.2: Interface Binding

    https://tools.ietf.org/html/rfc5625#section-6.2


static.tcl

IP static route related tests

Test Module Name Synopsis
Verify all LAN static routes with LAN side traffic only static.tcl static_1 Verify all LAN static routes with LAN side traffic only


    step 1. Find all configured static routes with next hops on the LAN
            interface
    step 2. Create new gateways for each next hop on the LAN
    step 3. Send ICMP Echo Request to a host within the static route from the
            LAN host
    step 4. Verify that the host in the static route reponds with ICMP Echo
            Reply


Test Module Name Synopsis
Verify all LAN static routes with LAN to WAN traffic static.tcl static_2 Verify all LAN static routes with LAN to WAN traffic


    step 1. Find all configured static routes with next hops on the LAN
            interface
    step 2. Create new gateways for each nexthop on the LAN
    step 3. Send ICMP Echo Request from host in static route network to the WAN
            side remoteHost
    step 4. Verify that the remoteHost on the WAN receives the ICMP Echo Request
    step 5. Verify the WAN host ICMP Echo Reply is received by the host in
            static route network


Test Module Name Synopsis
Verify all WAN static routes static.tcl static_10 Verify all WAN static routes


    step 1. Find all configured static routes with next hops on the WAN
            interface
    step 2. Create new gateways for each next hop on the WAN if not the wanIspIp
    step 3. Send ICMP Echo Request to a host within the static route from the
            LAN host
    step 4. Verify that the host in the static route receives the ICMP Echo
            Request


Test Module Name Synopsis
Verify all WAN static routes after WAN ISP address change static.tcl static_20 Verify all WAN static routes after WAN ISP address change


    step 1. Find all configured static routes with next hops on the WAN
            interface
    step 2. Create new gateways for each next hop on the WAN if not the wanIspIp
    step 3. Send an ICMP Echo Request to a host within the static route from the
            LAN host
    step 4. Verify that the host in the static route reponds with ICMP Echo
            Reply
    step 5. Change CDRouter's WAN ISP address and update the DUT to use it as the
            default router.
    step 6. Send an ICMP Echo Request to a host within the static route from the
            LAN host

    NOTE: This test is intended to test static routes that are configured on the CPE
    device by specifying a next hop address of "WAN" instead of a specific IP address.
    Most CPEs allow this type of static route configuration since the actual next hop will
    not be known during configuration when running a dynamic WAN protocol such as PPPoE,
    PPTP, L2TP, or DHCP.

    NOTE: This test is only run when the WAN protocol is dynamic.



dos.tcl

Common denial of service attacks against routers

Test Module Name Synopsis
Send 'ping of death' ICMP request to LAN side of the router dos.tcl cdrouter_dos_1 Send ‘ping of death’ ICMP request to LAN side of the router


    step 1. Initiate 'ping of death' packets to the router from the LAN side
    step 2. After recovery time, verify connectivity from LAN to WAN is still working
            by running test case cdrouter_nat_1 and cdrouter_nat_2

    NOTE: The amount of recovery time after the ping attack can be configured
    using the testvar 'dosRecoveryTime'. The default recovery time is 5 seconds.

    Example:

    testvar dosRecoveryTime 5

Test Module Name Synopsis
Send 'ping of death' ICMP request to WAN side of the router dos.tcl cdrouter_dos_2 Send ‘ping of death’ ICMP request to WAN side of the router


    step 1. Initiate 'ping of death' packets to the router from the WAN side
    step 2. After recovery time, verify connectivity from LAN to WAN is still working
            by running test case cdrouter_nat_1 and cdrouter_nat_2

    NOTE: The amount of recovery time after the ping attack can be configured
    using the testvar 'dosRecoveryTime'. The default recovery time is 5 seconds.

    Example:

    testvar dosRecoveryTime 5

Test Module Name Synopsis
Launch LAND attack against router's management port on the LAN dos.tcl cdrouter_dos_10 Launch LAND attack against router’s management port on the LAN


    step 1. Initiate LAND attack by sending TCP SYN packets to the CPE device
            management port using the device's IP as the source and destination
            address and using the device's MAC address as source and destination MAC.
    step 2. After recovery time, verify connectivity from LAN to WAN is still working
            by running test case cdrouter_nat_1 and cdrouter_nat_2.

    NOTE: The amount of recovery time after the LAND attack can be configured
    using the testvar 'dosRecoveryTime'. The default recovery time is 5 seconds.
    The devices management port and number of attack attempts can also be configured.

    Example:

    testvar dosRecoveryTime   5
    testvar dosAttackAttempts 100
    testvar dutMgmtPort       80

    NOTE: The value of the router's management port is taken from the
          default insecure management port defined as the first port
          in the value of testvar dutMgmtPort.  Please read the
          documentation for dutMgmtPort for more information about the
          default insecure management port concept and its usage.


Test Module Name Synopsis
Verify that the DUT is not a Smurf reflector (ICMP attack) dos.tcl cdrouter_dos_20 Verify that the DUT is not a Smurf reflector (ICMP attack)


    step 1. Send broadcast ICMP Echo Requests (pings) to the router's LAN port
    step 2. Verify that that the router's LAN interface does not respond to the broadcast pings
    step 3. Send broadcast ICMP Echo Requests (pings) to the router's WAN port
    step 4. Verify that that the router's WAN interface does not respond to the broadcast pings
    step 5. Simulate a Smurf attack on the LAN by sending spoofed broadcast ICMP Echo Request
            packets using the remoteHostIp as the source address
    step 6. Verify that the router does not forward the Smurf packets from LAN to WAN
    step 7. After recovery time, verify connectivity from LAN to WAN is still working
            by running test case cdrouter_nat_1 and cdrouter_nat_2

    NOTE: A Smurf attack involves sending a large number of ICMP Echo Requests to
    broadcast addresses from a spoofed source address. The spoofed source address
    is the address of the intended attack target. This attack can cause the target
    to be flooded with ICMP Echo replies creating a denial of service situation.
    Smurf attacks can be suppressed by configuring devices not to respond to broadcast
    pings, and configuring routers on a network not to forward packets to broadcast
    addresses.


Test Module Name Synopsis
Verify that the DUT is not a Fraggle reflector (UDP attack) dos.tcl cdrouter_dos_21 Verify that the DUT is not a Fraggle reflector (UDP attack)


    step 1. Send UDP Echo Requests to the broadcast address of the router's LAN port
    step 2. Verify that that the router's LAN IP Address does not respond to the broadcast Echo Request
    step 3. Send UDP Echo Requests to the broadcast address of the router's WAN port
    step 4. Verify that that the router's WAN IP Address does not respond to the broadcast Echo Request
    step 4. Repeat steps 1 thorugh 4 for the Daytime, QOTD, and Chargen protocols.
    step 5. After recovery time, verify connectivity from LAN to WAN is still working
            by running test case cdrouter_nat_1 and cdrouter_nat_2

    NOTE: A Fraggle attack involves sending a large number of UDP Echo Requests to
    broadcast addresses from a spoofed source address. The spoofed source address
    is the address of the intended attack target. This attack can cause the target
    to be flooded with UDP Echo replies creating a denial of service situation.
    Smurf attacks can be suppressed by configuring devices not to respond to broadcast
    pings, and configuring routers on a network not to forward packets to broadcast
    addresses.

Test Module Name Synopsis
SYN floods an open port on the DUT from spoofed LAN clients dos.tcl cdrouter_dos_30 SYN floods an open port on the DUT from spoofed LAN clients


    Step 1.  Send ARP information onto the LAN in anticipation of the DUT
             needing the L2 address of a spoofed lan client
    Step 2.  Open a TCP connection from the same spoofed lan client with
             a random source port by sending a SYN packet
    Step 3.  Ignore any SYN-ACK packets from the DUT
    Step 4.  Repeat until a configured number of iterations have completed
    Step 5.  After waiting for the DUT to recover, verify Internet connectivity
             is still working for the real lanClient

    NOTE: The amount of recovery time after the LAND attack can be configured
    using the testvar 'dosRecoveryTime'. The default recovery time is 5 seconds.
    The number of attack attempts can also be configured, which defaults to 100.
    To configure the port being attacked, set the testvar 'dosSynAttackPort'.

    Example:

    testvar dosRecoveryTime   5
    testvar dosSynAttackAttempts 100
    testvar dosSynAttackPort 80

Test Module Name Synopsis
SYN floods an open port on the WAN from spoofed Internet addresses dos.tcl cdrouter_dos_31 SYN floods an open port on the WAN from spoofed Internet addresses


    Step 1.  Open a TCP connection from a spoofed Internet address with
             a random source port by sending a SYN packet
    Step 2.  Ignore any SYN-ACK packets from the DUT
    Step 3.  Repeat until a configured number of iterations have completed
    Step 4.  After waiting for the DUT to recover, verify Internet connectivity
             is still working for the lanClient

    NOTE: The amount of recovery time after the LAND attack can be configured
    using the testvar 'dosRecoveryTime'. The default recovery time is 5 seconds.
    The number of attack attempts can also be configured, which defaults to 100.
    To configure the port being attacked, set the testvar 'dosSynAttackPort'.

    Example:

    testvar dosRecoveryTime   5
    testvar dosSynAttackAttempts 100
    testvar dosSynAttackPort 80

Test Module Name Synopsis
ARP floods the DUT's LAN interface dos.tcl cdrouter_dos_32 ARP floods the DUT’s LAN interface


    step 1. Send a gratuitous ARP Request from a spoofed IP and spoofed MAC address
    step 2. Reply to the gratuitous ARP Request with a gratuitous ARP Reply to the brodcast address
    step 3. Send an additional ARP Reply directly to the DUT
    step 4. Repeat steps 1 through 3 until a programed number of iterations have completed
    step 5. Wait for the DUT to recover, and then verify connectivity to the Internet is preserved

    NOTE: The amount of recovery time after the ARP Flood attack can be configured
    using the testvar 'dosRecoveryTime'. The default recovery time is 5 seconds.
    The number of attack attempts can also be configured, which defaults to 100.

    Example:

    testvar dosRecoveryTime   5
    testvar dosAttackAttempts 100

Test Module Name Synopsis
Christmas Tree floods the service ports on the WAN from spoofed Internet addresses dos.tcl cdrouter_dos_33 Christmas Tree floods the service ports on the WAN from spoofed Internet addresses


    Step 1.  Send an invalid TCP packet from a spoofed Internet address with
             a random source port by sending a Christmas packet (XMas Attack)
             to a random service port on the WAN IP Address of the DUT
    Step 2.  Ignore any packets from the DUT
    Step 3.  Repeat until a configured number of iterations have completed
    Step 4.  After waiting for the DUT to recover, verify Internet connectivity
             is still working for the lanClient

    NOTE: The amount of recovery time after the Christmas Tree Attack can be configured
    using the testvar 'dosRecoveryTime'. The default recovery time is 5 seconds.
    The number of attack attempts can also be configured, which defaults to 100.

    Example:

    testvar dosRecoveryTime   5
    testvar dosSynAttackAttempts 100

Test Module Name Synopsis
Floods the WAN interface with anomalous TCP packets dos.tcl cdrouter_dos_34 Floods the WAN interface with anomalous TCP packets


    Step 1.  Send an invalid TCP packet from a spoofed Internet address with
             a random source port to a random service port on the DUT's WAN IP Address
    Step 2.  Ignore any packets from the DUT
    Step 3.  Repeat until a configured number of iterations have completed
    Step 4.  After waiting for the DUT to recover, verify Internet connectivity
             is still working for the lanClient

    NOTE: The amount of recovery time after the Anomalous TCP Attack can be configured
    using the testvar 'dosRecoveryTime'. The default recovery time is 5 seconds.
    The number of attack attempts can also be configured, which defaults to 100.

    Example:

    testvar dosRecoveryTime   5
    testvar dosAttackAttempts 100


xbox.tcl

Xbox LIVE compatibilty tests to simulate Xbox LIVE console tests

Test Module Name Synopsis
IP Address Test: Verify DHCP IPv4 address or static IPv4 address xbox.tcl xbox_1 IP Address Test: Verify DHCP IPv4 address or static IPv4 address


    step 1. Restart the DHCP client if running DHCP on the LAN
    step 2. Verify DHCP client receives the same IP address and lease time
    step 3. Verify DHCP lease time is greater or equal to 5 minutes
    step 4. Verify LAN client can ARP for default gateway address


Test Module Name Synopsis
DNS Test: Verify DNS lookups from LAN client xbox.tcl xbox_2 DNS Test: Verify DNS lookups from LAN client


    step 1. Configure the primary and secondary DNS servers with the domain XEAS.XBOXLIVE.COM
    step 2. Initiate a DNS lookup on the LAN client with the learned or configured DNS server
    step 3. Verify the LAN client can resolve XEAS.XBOXLIVE.COM using DNS
    step 4. Repeat steps 1 through 3 using the domain XETGS.XBOXLIVE.COM
    step 5. Repeat steps 1 through 3 using the domain XEXDS.XBOXLIVE.COM
    step 6. Repeat steps 1 through 3 using the domain notice.xbox.com


Test Module Name Synopsis
MTU Test: Verify IPv4 MTU of 1364 for Xbox LIVE xbox.tcl xbox_3 MTU Test: Verify IPv4 MTU of 1364 for Xbox LIVE


    step 1. Send a UDP packet from LAN to WAN using IP MTU size of 1364 and
            source port 1258
    step 2. UDP server on WAN should echo packet back to LAN client
    step 3. Verify UDP echo succeeds with MTU of 1364
    step 4. Fragmentation of UDP will cause the UDP echo to fail
    step 5. Repeat steps 1 through 4 for UDP source port 1259

    The max IP MTU size used by CDRouter can be configured using the testvar
    'xboxMtu'. By default CDRouter uses a max IP MTU size of 1364.

    The destination port used by CDRouter can be configured using the testvar
    'xboxPort'. By default CDRouter uses a destination port of 3074.


Test Module Name Synopsis
ICMP Test: Verify ICMP Destination Unreachable message from WAN does not destroy NAT mapping xbox.tcl xbox_4 ICMP Test: Verify ICMP Destination Unreachable message from WAN does not destroy NAT mapping


    step 1. Send UDP packet with IP MTU size of 228 from LAN to WAN using
            source port 1259
    step 2. Verify UDP packet is received on the WAN and return an ICMP Destination Unreachable message
    step 3. Verify ICMP Destination Unreachable message is received on the LAN
    step 4. Send UDP response from WAN to LAN
    step 5. Verify UDP response is received on LAN since NAPT mapping is still working

    Refrence:
    Xbox Compatibility Testing http://www.qacafe.com/notes/show/8


Test Module Name Synopsis
NAT Test: Verify Xbox NAT classification of Open, Moderate, or Strict xbox.tcl xbox_5 NAT Test: Verify Xbox NAT classification of Open, Moderate, or Strict


    PART A: Verify if UPnP is enabled:

    step 1. Send UPnP M-SEARCH for WANIPConnection and WANPPPConnection services
    step 2. If found, initiate a UPnP GetStatusInfo Action on either service
    step 3. Consider UPnP enabled if Action succeeds

    PART B: Verify the shape of NAT to either symmetric or cone:

    step 1. Initiate UDP packet from LAN to WAN server
    step 2. Initiate UDP packet using same src port to different WAN server
    step 3. If WAN side src port changes, the device is using symmetric NAT

    PART C: Verify the type of NAT filtering:

    step 1. Initiate UDP packet from LAN to WAN server
    step 2. Forward return packet from WAN using different WAN src address
    step 3. If packet is forwarded to the LAN, full-cone NAT is in use
    step 4. Forward packet from original WAN server using differnt src address
    step 5. If packet is forwarded to the LAN, address-restricted NAT is in use
    step 6. Otherwise, NAT implementation is considered to be port-restricted

    PART D: Rate the type of NAT:

    Step 1. If UPnP is enabled, the NAT type is open
    Step 2. If device is using full-clone NAT, the NAT type is open
    Step 3. If device is using address-restricted or port-restricted NAT, the NAT type is moderate
    Step 4. If device is using symmetric NAT, the NAT type is strict
    Step 5. Test passes if NAT type matches minimal NAT type or is more open.

    NOTE: You can configure the minimal NAT type using the testvar xboxNatMinType. The
    default minimum NAT type is open. The xboxNatMinType values are
    open, moderate, and strict.

       testvar xboxNatMinType open

    Refrence:
    Xbox Compatibility Testing http://www.qacafe.com/notes/show/8


Test Module Name Synopsis
UPnP Test: Verify UDP wildcard port mapping can be created xbox.tcl xbox_6 UPnP Test: Verify UDP wildcard port mapping can be created


    step 1.  Find Control URL for WANIPConnection or WANPPPConnection service
    step 2.  Send UPnP Action for AddPortMapping with wildcard for
             NewRemoteHost (""), NewExternalPort 3074, NewProtocol UDP,
             NewInternalPort 3074, and NewLeaseDuration of 0
    step 3.  Verify Action returns HTTP 200 status code
    step 4.  Initiate inbound UDP connection using new port mapping
    step 5.  Verify UDP connection is established
    step 6.  Initiate outbound UDP connection using new port mapping
    step 7.  Verify UDP connection is established
    step 8.  Delete port mapping using DeletePortMapping Action
    step 9.  Wait 5 seconds for port mapping to be deleted
    step 10. Initiate inbound UDP connection for port mapping from WAN side
    step 11. Verify inbound UDP connection is blocked

    The source and destination port used by CDRouter for the port mapping can be
    configured using the testvar 'xboxPort'. By default CDRouter uses a source
    and destination port of 3074.

    The testvar 'upnpWANPPPConnection' is used to configure the test case
    to use the WANPPPConnection service. By default CDrouter uses the
    WANIPConnection service.



sctp.tcl

SCTP related test cases

Test Module Name Synopsis
Verify SCTP association initiation and termination sctp.tcl sctp_1 Verify SCTP association initiation and termination


    step 1. Initiate SCTP association from LAN client to WAN server
    step 2. Verify association initiation is successful
    step 3. Terminate SCTP association from LAN side
    step 4. Verify association is terminated successful


    References:

    IETF RFC 4960 "Stream Control Transmission Protocol"

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

Test Module Name Synopsis
Verify SCTP association with bidirectional data transfer sctp.tcl sctp_2 Verify SCTP association with bidirectional data transfer


    step 1. Initiate an outbound SCTP association from LAN client to WAN
            server
    step 2. Verify association initiation is successful
    step 3. Transmit SCTP data from LAN client to WAN server
    step 4. Verify WAN server receives SCTP data
    step 5. Transmit SCTP data from WAN server to LAN client
    step 6. Verify LAN client receives SCTP data
    step 7. Terminate SCTP association from LAN side
    step 8. Verify association is terminated successful


    References:

    IETF RFC 4960 "Stream Control Transmission Protocol"

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

Test Module Name Synopsis
Verify two simulataneous SCTP associations to same WAN server sctp.tcl sctp_3 Verify two simulataneous SCTP associations to same WAN server


    step 1. Initiate an outbound SCTP association from LAN client to WAN
            server
    step 2. Initiate an outbound SCTP association from second LAN client
            to the same WAN server
    step 3. Verify association initiation from step 1 is successful
    step 4. Verify association initiation from step 2 is successful
    step 5. Terminate SCTP association from first LAN client
    step 6. Terminate SCTP association from second LAN client
    step 7. Verify first LAN client's association is terminated successfully
    step 8. Verify second LAN client's association is terminated successfully


    References:

    IETF RFC 4960 "Stream Control Transmission Protocol"

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

Test Module Name Synopsis
Verify two simulataneous SCTP associations with same source port to same WAN server sctp.tcl sctp_4 Verify two simulataneous SCTP associations with same source port to same WAN server


    step 1. Initiate an outbound SCTP association from LAN client to WAN
            server
    step 2. Initiate an outbound SCTP association from second LAN
            client using same source port as the first LAN client to the
            same WAN server
    step 3. Verify association initiation from step 1 is successful
    step 4. Verify association initiation from step 2 is successful
    step 5. Terminate SCTP association from first LAN client
    step 6. Terminate SCTP association from second LAN client
    step 7. Verify first LAN client's association is terminated successfully
    step 8. Verify second LAN client's association is terminated successfully


    References:

    IETF RFC 4960 "Stream Control Transmission Protocol"

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


lldp.tcl

LLDP tests

Test Module Name Synopsis
Verify LLDP message transmission interval lldp.tcl lldp_1 Verify LLDP message transmission interval


    step 1. Wait up to lldpMsgTxInterval seconds for DUT to transmit
            an LLDP packet on LAN side
    step 2. Verify the DUT transmits the packet after
            lldpMsgTxInterval seconds
    step 3. Repeat steps 1 through 2 three times

    Note: The test is skipped unless supportsLLDP is yes.  Also, this
    test will only listen for LLDP packets from the MAC address
    lldpLanMac.


Test Module Name Synopsis
Verify LLDP new neighbor detection lldp.tcl lldp_2 Verify LLDP new neighbor detection


    step 1. Start new DHCP client on LAN interface
    step 2. Transmit an LLDP packet from new DHCP client
    step 3. Verify the DUT detects a new LLDP neighbor and quickly
            transmits lldpTxFastInit LLDP packets on the LAN side

    Note: The test is skipped unless supportsLLDP is yes.  Also, this
    test will only listen for LLDP packets from the MAC address
    lldpLanMac.


Test Module Name Synopsis
Verify Chassis TLV in DUT's LLDP message lldp.tcl lldp_3 Verify Chassis TLV in DUT’s LLDP message


    step 1. Wait up to lldpMsgTxInterval seconds for DUT to transmit
            an LLDP packet on LAN side
    step 2. Verify MAC address in MAC address Chassis TLV matches
            source MAC of the DUT's LAN interface

    Note: The test is skipped unless supportsLLDP is yes.  Also, this
    test will only listen for LLDP packets from the MAC address
    lldpLanMac.  If the MAC address in the DUT's Chassis TLV is not
    the same as lldpLanMac, configure the testvar lldpLanChassisMac.


Test Module Name Synopsis
Verify System Name TLV in DUT's LLDP message lldp.tcl lldp_4 Verify System Name TLV in DUT’s LLDP message


    step 1. Wait up to lldpMsgTxInterval seconds for DUT to transmit
            an LLDP packet on LAN side
    step 2. Verify value of System Name TLV matches DUT's expected LAN
            hostname.

    Note: The DUT's expected LAN hostname is configured using the
    testvar lanHostname.

    Note: The test is skipped unless supportsLLDP is yes.  Also, this
    test will only listen for LLDP packets from the MAC address
    lldpLanMac.



rfc5508.tcl

IETF RFC 5508 NAT behavioral requirements for ICMP

Test Module Name Synopsis
Section 3.1: ICMP Query Mapping, REQ-1 rfc5508.tcl rfc5508_req_1 Section 3.1: ICMP Query Mapping, REQ-1


    step 1. Send ICMP Echo Request from LAN client to WAN host A with
            ICMP ID X
    step 2. Verify ICMP Echo Request reaches WAN host A with
            translated ICMP ID X'
    step 3. Send a second ICMP Echo Request from LAN client to WAN
            host A with ID X
    step 4. Verify ICMP Echo Request reaches WAN host A, verify ICMP
            ID X' is unchanged
    step 5. Send ICMP Echo Request from LAN client to WAN host B with
            ICMP ID X
    step 6. Verify ICMP Echo Request reaches WAN host B, verify ICMP
            ID X' is unchanged


    References:

    IETF RFC 5508 "NAT Behavioral Requirements for TCP" Section 3.1: ICMP Query Mapping

    REQ-1: Unless explicitly overridden by local policy, a NAT device
    MUST permit ICMP Queries and their associated responses, when
    the Query is initiated from a private host to the external
    hosts.

    a. NAT mapping of ICMP Query Identifiers SHOULD be external-
       host independent.

    https://tools.ietf.org/html/rfc5508#section-3.1

Test Module Name Synopsis
Section 3.2: ICMP Query Session Timeouts, REQ-2 rfc5508.tcl rfc5508_req_2 Section 3.2: ICMP Query Session Timeouts, REQ-2


    step 1. Configure WAN host A to not respond to ICMP Echo Requests
    step 2. Send ICMP Echo Request from LAN client to WAN host A
    step 3. Wait slightly less than 60 seconds
    step 4. Send ICMP Echo Reply back from WAN host A to LAN client
    step 5. Verify LAN client receives ICMP Echo Reply from WAN host A


    References:

    IETF RFC 5508 "NAT Behavioral Requirements for TCP" Section 3.2: ICMP Query Session Timeouts

    Setting the ICMP NAT session timeout to a very large duration
    (say, 240 seconds) could potentially tie up precious NAT resources
    such as Query mappings and NAT Sessions for the whole duration.
    On the other hand, setting the timeout very low can result in
    premature freeing of NAT resources and applications failing to
    complete gracefully.  The ICMP Query session timeout needs to be a
    balance between the two extremes.  A 60-second timeout is a
    balance between the two extremes.  An ICMP Query session timer
    MUST NOT expire in less than 60 seconds.  It is RECOMMENDED that
    the ICMP Query session timer be made configurable.

    REQ-2: An ICMP Query session timer MUST NOT expire in less than 60
    seconds.

    a. It is RECOMMENDED that the ICMP Query session timer be made
       configurable.

    https://tools.ietf.org/html/rfc5508#section-3.2

Test Module Name Synopsis
Section 4.1: ICMP Error Payload Validation, REQ-3 rfc5508.tcl rfc5508_req_3 Section 4.1: ICMP Error Payload Validation, REQ-3


    step 1. Send ICMP Echo Request from LAN client to WAN host
    step 2. Send ICMP Port Unreachable with bad checksum from WAN host to LAN client
    step 3. Verify ICMP Port Unreachable is not forwarded to LAN client


    References:

    IETF RFC 5508 "NAT Behavioral Requirements for TCP" Section 4.1: ICMP Error Payload Validation

    REQ-3: When an ICMP Error packet is received, if the ICMP checksum
    fails to validate, the NAT SHOULD silently drop the ICMP Error
    packet.

    https://tools.ietf.org/html/rfc5508#section-4.1

Test Module Name Synopsis
Section 4.1: ICMP Error Payload Validation, REQ-3, Part A rfc5508.tcl rfc5508_req_3a Section 4.1: ICMP Error Payload Validation, REQ-3, Part A


    step 1. Send ICMP Echo Request from LAN client to WAN host
    step 2. Send ICMP Port Unreachable whose inner IPv4 header
            contains a bad checksum from WAN host to LAN client
    step 3. Verify ICMP Port Unreachable is not forwarded to LAN client


    References:

    IETF RFC 5508 "NAT Behavioral Requirements for TCP" Section 4.1: ICMP Error Payload Validation

    REQ-3: When an ICMP Error packet is received, if the ICMP checksum
    fails to validate, the NAT SHOULD silently drop the ICMP Error
    packet.  If the ICMP checksum is valid, do the following:

    a. If the IP checksum of the embedded packet fails to
    validate, the NAT SHOULD silently drop the Error packet

    https://tools.ietf.org/html/rfc5508#section-4.1

Test Module Name Synopsis
Section 4.1: ICMP Error Packet Received from the External Realm, REQ-4 rfc5508.tcl rfc5508_req_4 Section 4.1: ICMP Error Packet Received from the External Realm, REQ-4


    step 1. Send stray ICMP Port Unreachable from WAN host to LAN client
    step 2. Verify stray ICMP Port Unreachable is not forwarded to LAN client
    step 3. Run test cdrouter_icmp_12
    step 4. Run test cdrouter_icmp_13


    References:

    IETF RFC 5508 "NAT Behavioral Requirements for TCP" Section 4.2.1: ICMP Error Packet Received from the External Realm

    REQ-4: If a NAT device receives an ICMP Error packet from an external
    realm, and the NAT device does not have an active mapping for
    the embedded payload, the NAT SHOULD silently drop the ICMP
    Error packet.  If the NAT has active mapping for the embedded
    payload, then the NAT MUST do the following prior to
    forwarding the packet, unless explicitly overridden by local
    policy:

    a. Revert the IP and transport headers of the embedded IP
    packet to their original form, using the matching mapping;
    and

    b. Leave the ICMP Error type and code unchanged; and

    c. Modify the destination IP address of the outer IP header to
    be same as the source IP address of the embedded packet
    after translation.

    https://tools.ietf.org/html/rfc5508#section-4.2.1

Test Module Name Synopsis
Section 4.2.2: ICMP Error Packet Received from the Private Realm, REQ-5 rfc5508.tcl rfc5508_req_5 Section 4.2.2: ICMP Error Packet Received from the Private Realm, REQ-5


    step 1. Send stray ICMP Port Unreachable from LAN client to WAN host
    step 2. Verify stray ICMP Port Unreachable is not forwarded to WAN host
    step 3. Run test cdrouter_icmp_14


    References:

    IETF RFC 5508 "NAT Behavioral Requirements for TCP" Section 4.2.2: ICMP Error Packet Received from the Private Realm

    REQ-5: If a NAT device receives an ICMP Error packet from the private
    realm, and the NAT does not have an active mapping for the
    embedded payload, the NAT SHOULD silently drop the ICMP Error
    packet.  If the NAT has an active mapping for the embedded
    payload, then the NAT MUST do the following prior to
    forwarding the packet, unless explicitly overridden by local
    policy.

    a. Revert the IP and transport headers of the embedded IP
    packet to their original form, using the matching mapping;
    and

    b. Leave the ICMP Error type and code unchanged; and

    c. If the NAT enforces Basic NAT function [NAT-TRAD], and the
    NAT has active mapping for the IP address that sent the
    ICMP Error, translate the source IP address of the ICMP
    Error packet with the public IP address in the mapping.  In
    all other cases, translate the source IP address of the
    ICMP Error packet with its own public IP address.

    https://tools.ietf.org/html/rfc5508#section-4.2.2

Test Module Name Synopsis
Section 4.3: NAT Sessions Pertaining to ICMP Error Payload, REQ-6 rfc5508.tcl rfc5508_req_6 Section 4.3: NAT Sessions Pertaining to ICMP Error Payload, REQ-6


    step 1. Run test cdrouter_nat_360
    step 2. Run test cdrouter_nat_361


    References:

    IETF RFC 5508 "NAT Behavioral Requirements for TCP" Section 4.3: NAT Sessions Pertaining to ICMP Error Payload

    While processing an ICMP Error packet pertaining to an ICMP Query or
    Query response message, a NAT device MUST NOT refresh or delete the
    NAT Session that pertains to the embedded payload within the ICMP
    Error packet.  This is in spite of the fact that the NAT device uses
    the NAT Session to translate the embedded payload.  This ensures that
    the NAT Session will not be modified if someone is able to spoof ICMP
    Error messages for the session.  [ICMP-ATK] lists a number of
    potential ICMP attacks that may be attempted by malicious users on
    the network.  This requirement is necessary for current applications
    to work correctly.

    REQ-6: While processing an ICMP Error packet pertaining to an ICMP
    Query or Query response message, a NAT device MUST NOT refresh
    or delete the NAT Session that pertains to the embedded
    payload within the ICMP Error packet.

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

Test Module Name Synopsis
Section 5: Hairpinning Support for ICMP Packets, REQ-7 rfc5508.tcl rfc5508_req_7 Section 5: Hairpinning Support for ICMP Packets, REQ-7


    step 1. Initiate an outbound UDP connection to server 1 from LAN source port A
    step 2. Initiate a second outbound UDP connection to server 1 from LAN source port B
    step 3. Detect public IP and source port for both UDP connections
    step 4. Send UDP from LAN source port A to public IP and source port for connection 2
    step 5. Send UDP from LAN source port B to public IP and source port for connection 1

    step 6. Send UDP from LAN source port A to public IP and source port for connection 2
            ** NOTE: This step is required for Restricted and Port Restricted
            Cone NATs. These types of NATs require an existing outgoing session
            before allowing incoming packets. The test will pass packets in both
            directions before trying to verify the hairpin behavior.

    step 7. Verify packet is received at LAN source port B
    step 8. Verify source IPv4 address and UDP port are translated to public IPv4 and port
            ** NOTE: The test only issues a warning if the UDP source port is not preserved.

    step 9. Send UDP from LAN source port B to public IP and source port for connection 1
            ** NOTE: The source port is taken from the incoming UDP packet to work with
            implementations that do not preserve the UDP source port.

    step 10. Verify packet is received at LAN source port A
    step 11. Verify source IPv4 address and UDP port are translated to public IPv4 and port
    step 12. Send an ICMP Destination Unreachable message with an
             embedded IP packet matching the hairpin NAT binding from
             LAN.
    step 13. Verify that the ICMP Destination Unreachable message is
             forwarded and that the destination IP address of the
             outer IP header matches the source IP address of the
             embedded IP packet.

    NOTES: This test scenario should work for all Cone NAT implementations - Full
    Cone NAT, Restricted Cone NAT, and Port Restricted Cone NAT. For a discussion
    of each type of Cone NAT, please see RFC 3489.

    This test is only run when the testvar 'natSupportsP2P' is set to yes.


    References:

    IETF RFC 4787 "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" Section 6: Hairpinning Behavior

    https://tools.ietf.org/html/rfc4787#section-6

    IETF RFC 5508 "NAT Behavioral Requirements for TCP" Section 5: Hairpinning Support for ICMP Packets

    REQ-7: NAT devices enforcing Basic NAT [NAT-TRAD] MUST support the
    traversal of hairpinned ICMP Query sessions.  All NAT devices
    (i.e., Basic NAT as well as NAPT devices) MUST support the
    traversal of hairpinned ICMP Error messages:

    a. When forwarding a hairpinned ICMP Error message, the NAT
    device MUST translate the destination IP address of the
    outer IP header to be same as the source IP address of the
    embedded IP packet after the translation.

    https://tools.ietf.org/html/rfc5508#section-5


rfc4787.tcl

RFC 4787 NAT behavioral requirements for unicast UDP

Test Module Name Synopsis
Section 4.1: Address and Port Mapping, REQ-1 Mapping Behavior rfc4787.tcl rfc4787_req_1 Section 4.1: Address and Port Mapping, REQ-1 Mapping Behavior


    step 1. Transmit a UDP packet from LAN client with source port X
            to WAN server A.
    step 2. Transmit a UDP packet from LAN client with source port X
            to WAN server B.
    step 3. Verify WAN server B received the LAN client UDP packet
            from the same source IP and source port as WAN server A.


    References:

    IETF RFC 4787 "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" Section 4.1: Address and Port Mapping

    REQ-1:  A NAT MUST have an "Endpoint-Independent Mapping" behavior.

    https://tools.ietf.org/html/rfc4787#section-4.1

Test Module Name Synopsis
Section 4.1: Address and Port Mapping, REQ-2 Address Pooling Behavior rfc4787.tcl rfc4787_req_2 Section 4.1: Address and Port Mapping, REQ-2 Address Pooling Behavior


    step 1. Transmit a UDP packet from LAN client with source port A
            to WAN server.
    step 2. Transmit a second UDP packet from LAN client with source
            port B to WAN server.
    step 3. Verify the WAN server received the UDP packet from step 2
            from the same source IP as the UDP packet from step 1.


    References:

    IETF RFC 4787 "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" Section 4.1: Address and Port Mapping

    REQ-2:  It is RECOMMENDED that a NAT have an "IP address pooling"
       behavior of "Paired".  Note that this requirement is not
       applicable to NATs that do not support IP address pooling.

    https://tools.ietf.org/html/rfc4787#section-4.1

Test Module Name Synopsis
Section 4.2.1: Port Assignment Behavior, REQ-3 rfc4787.tcl rfc4787_req_3 Section 4.2.1: Port Assignment Behavior, REQ-3


    step 1. Transmit a UDP packet from LAN client A with source port X
            to WAN server on port X.
    step 2. Transmit a UDP packet from LAN client B with source port X
            to WAN server on port X.
    step 3. Verify the WAN server received the UDP packet from step 2
            from a different source port than the UDP packet from step 1.


    References:

    IETF RFC 4787 "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" Section 4.2.1: Port Assignment Behavior

    REQ-3:  A NAT MUST NOT have a "Port assignment" behavior of "Port
       overloading".

    https://tools.ietf.org/html/rfc4787#section-4.2.1

Test Module Name Synopsis
Section 4.2.2: Port Parity, REQ-4 rfc4787.tcl rfc4787_req_4 Section 4.2.2: Port Parity, REQ-4


    step 1. Transmit a UDP packet from the LAN Client with a even
            source port number to the WAN Server.
    step 2. Verify the UDP packet received by the WAN Server has
            an even source port.
    step 3. Transmit a UDP packet from the LAN Client with an odd
            source port number to the WAN Server.
    step 4. Verify the UDP packet received by the WAN Server has
            an odd source port.
    step 5. Repeat steps 1 through 4 several times.


    NOTE: If port parity is not supported, this test can be skipped by
    configuring the testvar 'natPortParity' to 'no'.


    References:

    IETF RFC 4787 "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" Section 4.2.2: Port Parity

    REQ-4:  It is RECOMMENDED that a NAT have a "Port parity
       preservation" behavior of "Yes".

    https://tools.ietf.org/html/rfc4787#section-4.2.2

Test Module Name Synopsis
Section 4.3: Mapping Refresh, REQ-5 Expiration Window rfc4787.tcl rfc4787_req_5 Section 4.3: Mapping Refresh, REQ-5 Expiration Window


    step 1. Initiate LAN client UDP ping to WAN server
    step 2. Verify LAN client receives response
    step 3. Wait 115 seconds
    step 4. Initiate WAN client UDP ping on same connection as step 1
            from WAN side
    step 5. Verify WAN client receives a response


    References:

    IETF RFC 4787 "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" Section 4.3: Mapping Refresh

    REQ-5:  A NAT UDP mapping timer MUST NOT expire in less than two
       minutes, unless REQ-5a applies.

      (a) For specific destination ports in the well-known port range
          (ports 0-1023), a NAT MAY have shorter UDP mapping timers that
          are specific to the IANA-registered application running over
          that specific destination port.

      (b) The value of the NAT UDP mapping timer MAY be configurable.

      (c) A default value of five minutes or more for the NAT UDP mapping
          timer is RECOMMENDED.

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

Test Module Name Synopsis
Section 4.3: Mapping Refresh, REQ-6 Refresh Behavior rfc4787.tcl rfc4787_req_6 Section 4.3: Mapping Refresh, REQ-6 Refresh Behavior


    step 1. Transmit a UDP packet from LAN client to WAN server.
    step 2. Wait natUdpTimeout - 10 seconds.
    step 3. Transmit a UDP packet from LAN client to WAN server on the
            same UDP connection as step 1 so that the NAT mapping is refreshed.
    step 4. Wait 10 seconds.
    step 5. Transmit a UDP packet from WAN server to LAN client on
            same UDP connection.
    step 6. Verify LAN client receives UDP packet from step 5.
    step 7. Transmit a UDP packet from LAN client to WAN server.
    step 8. Wait natUdpTimeout - 10 seconds.
    step 9. Transmit a UDP packet from WAN server to LAN client on the
            same UDP connection as step 7 so that the NAT mapping is refreshed.
    step 10. Wait 10 seconds.
    step 11. Transmit a UDP packet from WAN server to LAN client on
             same UDP connection as step 1.
    step 12. Verify LAN client receives UDP packet from step 11.

    NOTE: Steps 7 - 12 will be skipped if testvar natRefreshBehavior is
    not 'both'.


    References:

    IETF RFC 4787 "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" Section 4.3: Mapping Refresh

    REQ-6:  The NAT mapping Refresh Direction MUST have a "NAT Outbound
       refresh behavior" of "True".

      (a) The NAT mapping Refresh Direction MAY have a "NAT Inbound
          refresh behavior" of "True".

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

Test Module Name Synopsis
Section 5: Filtering Behavior, REQ-8 rfc4787.tcl rfc4787_req_8 Section 5: Filtering Behavior, REQ-8


    step 1. Forward a UDP packet from a LAN client to the WAN
    step 2. Forward a packet back from the WAN to the same LAN client
    step 3. Verify packet is received

    For Full-Cone NAT
    step 4. Forward a packet using a different source port but same IP address from the WAN
    step 5. Verify the packet is forwarded to the LAN
    step 6. Forward a packet using a different IPv4 address and same source port
    step 7. Verify the packet is forwarded to the LAN
    step 8. Forward a packet using the same IPv4 address and same source port
    step 9. Verify the packet is forwarded to the LAN

    For Address-Restricted NAT
    step 4. Forward a packet using a different IPv4 address and same source port
    step 5. Verify the packet is not forwarded to the LAN
    step 6. Forward a packet using a different source port but same IP address from the WAN
    step 7. Verify the packet is forwarded to the LAN
    step 8. Forward a packet using the same IPv4 address and same source port
    step 9. Verify the packet is forwarded to the LAN

    For Port-Restricted NAT
    step 4. Forward a packet using a different source port but same IP address from the WAN
    step 5. Verify the packet is not forwarded to the LAN
    step 6. Forward a packet using the same source port and IP address from the WAN
    step 7. Verify the packet is forwarded to the LAN 


    References:

    IETF RFC 4787 "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" Section 5: Filtering Behavior

    REQ-8:  If application transparency is most important, it is
       RECOMMENDED that a NAT have an "Endpoint-Independent Filtering"
       behavior.  If a more stringent filtering behavior is most
       important, it is RECOMMENDED that a NAT have an "Address-Dependent
       Filtering" behavior.

      (a) The filtering behavior MAY be an option configurable by the
          administrator of the NAT.

    https://tools.ietf.org/html/rfc4787#section-5

Test Module Name Synopsis
Section 6: Hairpinning Behavior, REQ-9 rfc4787.tcl rfc4787_req_9 Section 6: Hairpinning Behavior, REQ-9


    step 1. Initiate an outbound UDP connection to server 1 from LAN source port A
    step 2. Initiate a second outbound UDP connection to server 1 from LAN source port B
    step 3. Detect public IP and source port for both UDP connections
    step 4. Send UDP from LAN source port A to public IP and source port for connection 2
    step 5. Send UDP from LAN source port B to public IP and source port for connection 1
    step 6. Send UDP from LAN source port A to public IP and source port for connection 2
            ** NOTE: This step is required for Restricted and Port Restricted
            Cone NATs. These types of NATs require an existing outgoing session
            before allowing incoming packets. The test will pass packets in both
            directions before trying to verify the hairpin behavior.
    step 7. Verify packet is received at LAN source port B
    step 8. Verify source IPv4 address and UDP port are translated to public IPv4 and port
            ** NOTE: The test only issues a warning if the UDP source port is not preserved.
    step 9. Send UDP from LAN source port B to public IP and source port for connection 1
            ** NOTE: The source port is taken from the incoming UDP packet to work with
            implementations that do not preserve the UDP source port.

    step 10. Verify packet is received at LAN source port A
    step 11. Verify source IPv4 address and UDP port are translated to public IPv4 and port


    References:

    IETF RFC 4787 "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" Section 6: Hairpinning Behavior

    REQ-9:  A NAT MUST support "Hairpinning".

      (a) A NAT Hairpinning behavior MUST be "External source IP address
          and port".

    https://tools.ietf.org/html/rfc4787#section-6

Test Module Name Synopsis
Section 8: Deterministic Properties, REQ-11 rfc4787.tcl rfc4787_req_11 Section 8: Deterministic Properties, REQ-11


    step 1. Create two additional LAN clients for a total of three
    step 2. Create a second WAN server
    step 3. Create UDP Servers on both WAN Servers
    step 4. For each LAN client, connect to the WAN Server on port X, X+1,
            and WAN Server 2 port X, using the same source port on each LAN client
    step 5. Determine the NAT translation model by inspecting the NAT IP Address and Port used
            for each connection.
    step 6. Determine whether the NAT translation model was persistent across all three LAN clients
    step 7. Shut down the UDP WAN Servers.  Install UDP Servers on each LAN client,
            listening to the port the LAN client originally sent a packet from.
    step 8. Attempt to connect to each NAT mapping per LAN client from each of the
            original WAN Server destination ports.
    step 9. Determine whether the NAT filtering model was persistent across all three LAN clients


    References:

    IETF RFC 4787 "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" Section 8: Deterministic Properties

    REQ-11:  A NAT MUST have deterministic behavior, i.e., it MUST NOT
       change the NAT translation (Section 4) or the Filtering
       (Section 5) Behavior at any point in time, or under any particular
       conditions.

    https://tools.ietf.org/html/rfc4787#section-8

Test Module Name Synopsis
Section 9: ICMP Destination Unreachable Behavior, REQ-12 rfc4787.tcl rfc4787_req_12 Section 9: ICMP Destination Unreachable Behavior, REQ-12


    step 1. Send UDP packet from LAN to WAN
    step 2. Verify UDP packet is received on the WAN and return an ICMP Destination Unreachable message
    step 3. Verify ICMP Destination Unreachable message is received on the LAN
    step 4. Send UDP response from WAN to LAN
    step 5. Verify UDP response is received on LAN since NAPT mapping is still working


    References:

    IETF RFC 4787 "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" Section 9: ICMP Destination Unreachable Behavior

    REQ-12:  Receipt of any sort of ICMP message MUST NOT terminate the
       NAT mapping.

      (a) The NAT's default configuration SHOULD NOT filter ICMP messages
          based on their source IP address.

      (b) It is RECOMMENDED that a NAT support ICMP Destination
          Unreachable messages.

    https://tools.ietf.org/html/rfc4787#section-9

Test Module Name Synopsis
Section 10: Fragmentation of Outgoing Packets, REQ-13 rfc4787.tcl rfc4787_req_13 Section 10: Fragmentation of Outgoing Packets, REQ-13


    step 1. Create a packet larger than the WAN connection MTU, to force fragmentation
    step 2. Set the DF field of the packet to 1
    step 3. Send the packet from the LAN client to the WAN server
    step 4. Verify an ICMP Type 3, Code 4 message is received by the LAN client
    step 5. Recreate the packet from step 1
    step 6. Set the DF field of the packet to 0
    step 7. Send the packet from the LAN client to the WAN server
    step 8. Verify the fragmented packet is received on the WAN server

    NOTE: This behavior is appliciable under only the original framing of
    Section 10, 'When the MTU of the adjacent link is too small'.  This behavior
    is not expected when the packet would not require fragmentation.

    NOTE: This test will be skipped if the testvar 'wanMode' is not a WAN
    topology with an MTU smaller than the LAN MTU (Typically 1500).


    References:

    IETF RFC 4787 "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" Section 10: Fragmentation of Outgoing Packets

    REQ-13:  If the packet received on an internal IP address has DF=1,
       he NAT MUST send back an ICMP message "Fragmentation needed and
       DF set" to the host, as described in [RFC0792].

      (a) If the packet has DF=0, the NAT MUST fragment the packet and
          SHOULD send the fragments in order.

    https://tools.ietf.org/html/rfc4787#section-10

Test Module Name Synopsis
Section 11: Receiving Fragmented Packets, REQ-14 rfc4787.tcl rfc4787_req_14 Section 11: Receiving Fragmented Packets, REQ-14


    step 1. Send a set of UDP Echo fragment packets from the LAN client
            to the WAN server in reverse order
    step 2. Verify the WAN server replies to the LAN client


    References:

    IETF RFC 4787 "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" Section 11: Receiving Fragmented Packets

    REQ-14:  A NAT MUST support receiving in-order and out-of-order
       fragments, so it MUST have "Received Fragment Out of Order"
       behavior.

      (a) A NAT's out-of-order fragment processing mechanism MUST be
          designed so that fragmentation-based DoS attacks do not
          compromise the NAT's ability to process in-order and
          unfragmented IP packets.

    https://tools.ietf.org/html/rfc4787#section-11


http.tcl

HTTP related test cases

Test Module Name Synopsis
Verify HTTP/1.0 GET connections http.tcl cdrouter_http_100 Verify HTTP/1.0 GET connections


    step 1. Send an HTTP/1.0 GET request to server
    step 2. Verify HTTP response is received


    References:

    IETF RFC 1945 "Hypertext Transfer Protocol -- HTTP/1.0"

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

Test Module Name Synopsis
Verify HTTP/1.0 POST connections http.tcl cdrouter_http_101 Verify HTTP/1.0 POST connections


    step 1. Send an HTTP/1.0 POST request to server
    step 2. Verify HTTP response is received


    References:

    IETF RFC 1945 "Hypertext Transfer Protocol -- HTTP/1.0"

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

Test Module Name Synopsis
Verify HTTP/1.0 HEAD connections http.tcl cdrouter_http_102 Verify HTTP/1.0 HEAD connections


    step 1. Send an HTTP/1.0 HEAD request to server
    step 2. Verify HTTP response is received


    References:

    IETF RFC 1945 "Hypertext Transfer Protocol -- HTTP/1.0"

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

Test Module Name Synopsis
Verify HTTP/1.0 GET connections with large number of headers http.tcl cdrouter_http_103 Verify HTTP/1.0 GET connections with large number of headers

    
    step 1. Send a HTTP/1.0 GET request to the server with the maximum allowed headers
    step 2. Verify the HTTP response is received

    NOTE: The testvar httpMaxHeaderCount can be used to configure the number of
    headers that are applied during this test.


    References:

    IETF RFC 1945 "Hypertext Transfer Protocol -- HTTP/1.0"

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

Test Module Name Synopsis
Verify HTTP/1.1 GET connections http.tcl cdrouter_http_200 Verify HTTP/1.1 GET connections


    step 1. Send an HTTP/1.1 GET request to server
    step 2. Verify HTTP response is received


    References:

    IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"

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

Test Module Name Synopsis
Verify HTTP/1.1 POST connections http.tcl cdrouter_http_201 Verify HTTP/1.1 POST connections


    step 1. Send an HTTP/1.1 POST request to server
    step 2. Verify HTTP response is received


    References:

    IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"

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

Test Module Name Synopsis
Verify HTTP/1.1 HEAD connections http.tcl cdrouter_http_202 Verify HTTP/1.1 HEAD connections


    step 1. Send an HTTP/1.1 HEAD request to server
    step 2. Verify HTTP response is received


    References:

    IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"

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

Test Module Name Synopsis
Verify HTTP/1.1 PUT connections http.tcl cdrouter_http_203 Verify HTTP/1.1 PUT connections


    step 1. Send an HTTP/1.1 PUT request to server
    step 2. Verify HTTP response is received


    References:

    IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"

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

Test Module Name Synopsis
Verify HTTP/1.1 OPTIONS connections http.tcl cdrouter_http_204 Verify HTTP/1.1 OPTIONS connections


    step 1. Send an HTTP/1.1 OPTIONS request to server
    step 2. Verify HTTP response is received


    References:

    IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"

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

Test Module Name Synopsis
Verify HTTP/1.1 DELETE connections http.tcl cdrouter_http_205 Verify HTTP/1.1 DELETE connections


    step 1. Send an HTTP/1.1 DELETE request to server
    step 2. Verify HTTP response is received


    References:

    IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"

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

Test Module Name Synopsis
Verify HTTP/1.1 GET connections with large number of headers http.tcl cdrouter_http_206 Verify HTTP/1.1 GET connections with large number of headers


    step 1. Send an HTTP/1.1 GET request to the server with the maximum allowed headers
    step 2. Verify HTTP response is received

    NOTE: The testvar httpMaxHeaderCount can be used to configure the number of
    headers that are applied during this test.


    References:

    IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"

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

Test Module Name Synopsis
Verify HTTP/1.1 GET connections with chunked encoding http.tcl cdrouter_http_250 Verify HTTP/1.1 GET connections with chunked encoding


    step 1. Send an HTTP/1.1 GET request to server
    step 2. Verify HTTP response with chunked encoding is received


    References:

    IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"

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

Test Module Name Synopsis
Verify HTTP/1.1 proxy idle timeout http.tcl cdrouter_http_260 Verify HTTP/1.1 proxy idle timeout


    step 1. Configure HTTP server to delay sending responses by the
            time period specified by httpProxyIdleTimeout.
    step 2. Send an HTTP/1.1 GET request to server
    step 3. Verify HTTP response is received


    References:

    IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"

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

    IETF RFC 6202 "Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP" Section 5.5: Timeouts

    https://tools.ietf.org/html/rfc6202#section-5.5

Test Module Name Synopsis
Verify HTTP/1.1 pipelining http.tcl cdrouter_http_270 Verify HTTP/1.1 pipelining


    step 1. Send three pipelined HTTP/1.1 GET requests to server
    step 2. Verify three HTTP responses are received


    References:

    IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1" Section 8.1.2.2: Pipelining

    https://tools.ietf.org/html/rfc2616#section-8.1.2.2

Test Module Name Synopsis
Verify HTTP/1.1 streaming using chunked encoding http.tcl cdrouter_http_280 Verify HTTP/1.1 streaming using chunked encoding


    step 1. Send an HTTP/1.1 GET request.
    step 2. Verify headers of 200 OK response message are received.
    step 3. Verify first chunk of 200 OK response body is received.
    step 4. Pause for five seconds.
    step 5. Repeat steps 3-4 for the second and third chunks of the
            200 OK response body.
    step 6. Verify a full HTTP response message was received.


    References:

    IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"

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

    IETF RFC 6202 "Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP" Section 3.2: HTTP Streaming Issues

    https://tools.ietf.org/html/rfc6202#section-3.2

Test Module Name Synopsis
Verify HTTP/1.1 WebSocket Ping message http.tcl cdrouter_http_300 Verify HTTP/1.1 WebSocket Ping message


    step 1. Send an HTTP/1.1 GET request for creation of a WebSocket
    step 2. Verify WebSocket is created on the server
    step 3. Send a WebSocket Ping opcode (0x9)
    step 4. Verify server side returns WebSocket Pong opcode (0xA)
    step 5. Close the WebSocket server


    References:

    IETF RFC 6455 "The WebSocket Protocol"

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

Test Module Name Synopsis
Verify HTTP/1.1 WebSocket Text message http.tcl cdrouter_http_301 Verify HTTP/1.1 WebSocket Text message


    step 1. Send an HTTP/1.1 GET request for creation of a WebSocket
    step 2. Verify WebSocket is created on the server
    step 3. Send a WebSocket data message with text 
    step 4. Verify server side echos back the same text data
    step 5. Close the WebSocket server


    References:

    IETF RFC 6455 "The WebSocket Protocol"

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


https.tcl

HTTPS related test cases

Test Module Name Synopsis
Verify HTTPS/1.0 GET connections https.tcl cdrouter_https_100 Verify HTTPS/1.0 GET connections


    step 1. Send an HTTPS/1.0 GET request to server
    step 2. Verify HTTPS response is received


    References:

    IETF RFC 2818 "HTTP Over TLS"

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

    IETF RFC 1945 "Hypertext Transfer Protocol -- HTTP/1.0"

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

Test Module Name Synopsis
Verify HTTPS/1.0 POST connections https.tcl cdrouter_https_101 Verify HTTPS/1.0 POST connections


    step 1. Send an HTTPS/1.0 POST request to server
    step 2. Verify HTTPS response is received


    References:

    IETF RFC 2818 "HTTP Over TLS"

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

    IETF RFC 1945 "Hypertext Transfer Protocol -- HTTP/1.0"

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

Test Module Name Synopsis
Verify HTTPS/1.0 HEAD connections https.tcl cdrouter_https_102 Verify HTTPS/1.0 HEAD connections


    step 1. Send an HTTPS/1.0 HEAD request to server
    step 2. Verify HTTPS response is received


    References:

    IETF RFC 2818 "HTTP Over TLS"

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

    IETF RFC 1945 "Hypertext Transfer Protocol -- HTTP/1.0"

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

Test Module Name Synopsis
Verify HTTPS/1.0 GET connections with large number of headers https.tcl cdrouter_https_103 Verify HTTPS/1.0 GET connections with large number of headers

    
    step 1. Send a HTTPS/1.0 GET request to the server with the maximum allowed headers
    step 2. Verify the HTTPS response is received

    NOTE: The testvar httpMaxHeaderCount can be used to configure the number of
    headers that are applied during this test.


    References:

    IETF RFC 2818 "HTTP Over TLS"

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

    IETF RFC 1945 "Hypertext Transfer Protocol -- HTTP/1.0"

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

Test Module Name Synopsis
Verify HTTPS/1.1 GET connections https.tcl cdrouter_https_200 Verify HTTPS/1.1 GET connections


    step 1. Send an HTTPS/1.1 GET request to server
    step 2. Verify HTTPS response is received


    References:

    IETF RFC 2818 "HTTP Over TLS"

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

    IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"

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

Test Module Name Synopsis
Verify HTTPS/1.1 POST connections https.tcl cdrouter_https_201 Verify HTTPS/1.1 POST connections


    step 1. Send an HTTPS/1.1 POST request to server
    step 2. Verify HTTPS response is received


    References:

    IETF RFC 2818 "HTTP Over TLS"

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

    IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"

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

Test Module Name Synopsis
Verify HTTPS/1.1 HEAD connections https.tcl cdrouter_https_202 Verify HTTPS/1.1 HEAD connections


    step 1. Send an HTTPS/1.1 HEAD request to server
    step 2. Verify HTTPS response is received


    References:

    IETF RFC 2818 "HTTP Over TLS"

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

    IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"

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

Test Module Name Synopsis
Verify HTTPS/1.1 PUT connections https.tcl cdrouter_https_203 Verify HTTPS/1.1 PUT connections


    step 1. Send an HTTPS/1.1 PUT request to server
    step 2. Verify HTTPS response is received


    References:

    IETF RFC 2818 "HTTP Over TLS"

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

    IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"

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

Test Module Name Synopsis
Verify HTTPS/1.1 OPTIONS connections https.tcl cdrouter_https_204 Verify HTTPS/1.1 OPTIONS connections


    step 1. Send an HTTPS/1.1 OPTIONS request to server
    step 2. Verify HTTPS response is received


    References:

    IETF RFC 2818 "HTTP Over TLS"

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

    IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"

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

Test Module Name Synopsis
Verify HTTPS/1.1 DELETE connections https.tcl cdrouter_https_205 Verify HTTPS/1.1 DELETE connections


    step 1. Send an HTTPS/1.1 DELETE request to server
    step 2. Verify HTTPS response is received


    References:

    IETF RFC 2818 "HTTP Over TLS"

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

    IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"

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

Test Module Name Synopsis
Verify HTTPS/1.1 GET connections with large number of headers https.tcl cdrouter_https_206 Verify HTTPS/1.1 GET connections with large number of headers


    step 1. Send an HTTPS/1.1 GET request to the server with the maximum allowed headers
    step 2. Verify HTTPS response is received

    NOTE: The testvar httpMaxHeaderCount can be used to configure the number of
    headers that are applied during this test.


    References:

    IETF RFC 2818 "HTTP Over TLS"

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

    IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"

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

Test Module Name Synopsis
Verify HTTPS/1.1 GET connections with chunked encoding https.tcl cdrouter_https_250 Verify HTTPS/1.1 GET connections with chunked encoding


    step 1. Send an HTTPS/1.1 GET request to server
    step 2. Verify HTTPS response with chunked encoding is received


    References:

    IETF RFC 2818 "HTTP Over TLS"

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

    IETF RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"

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

Test Module Name Synopsis
Verify HTTPS/1.1 WebSocket Ping message https.tcl cdrouter_https_300 Verify HTTPS/1.1 WebSocket Ping message


    step 1. Send an HTTPS/1.1 GET request for creation of a WebSocket
    step 2. Verify WebSocket is created on the server
    step 3. Send a WebSocket Ping opcode (0x9)
    step 4. Verify server side returns WebSocket Pong opcode (0xA)
    step 5. Close the WebSocket server


    References:

    IETF RFC 2818 "HTTP Over TLS"

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

    IETF RFC 6455 "The WebSocket Protocol"

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

Test Module Name Synopsis
Verify HTTPS/1.1 WebSocket Text message https.tcl cdrouter_https_301 Verify HTTPS/1.1 WebSocket Text message


    step 1. Send an HTTPS/1.1 GET request for creation of a WebSocket
    step 2. Verify WebSocket is created on the server
    step 3. Send a WebSocket data message with text 
    step 4. Verify server side echos back the same text data
    step 5. Close the WebSocket server


    References:

    IETF RFC 2818 "HTTP Over TLS"

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

    IETF RFC 6455 "The WebSocket Protocol"

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


http2.tcl

HTTP/2 related test cases

Test Module Name Synopsis
Verify HTTP/2 GET connections http2.tcl cdrouter_http2_100 Verify HTTP/2 GET connections


    step 1. Send an HTTP/2 GET request to server
    step 2. Verify HTTP response is received


    References:

    IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"

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

Test Module Name Synopsis
Verify HTTP/2 POST connections http2.tcl cdrouter_http2_101 Verify HTTP/2 POST connections


    step 1. Send an HTTP/2 POST request to server
    step 2. Verify HTTP response is received


    References:

    IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"

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

Test Module Name Synopsis
Verify HTTP/2 HEAD connections http2.tcl cdrouter_http2_102 Verify HTTP/2 HEAD connections


    step 1. Send an HTTP/2 HEAD request to server
    step 2. Verify HTTP response is received


    References:

    IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"

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

Test Module Name Synopsis
Verify HTTP/2 PUT connections http2.tcl cdrouter_http2_103 Verify HTTP/2 PUT connections


    step 1. Send an HTTP/2 PUT request to server
    step 2. Verify HTTP response is received


    References:

    IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"

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

Test Module Name Synopsis
Verify HTTP/2 OPTIONS connections http2.tcl cdrouter_http2_104 Verify HTTP/2 OPTIONS connections


    step 1. Send an HTTP/2 OPTIONS request to server
    step 2. Verify HTTP response is received


    References:

    IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"

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

Test Module Name Synopsis
Verify HTTP/2 DELETE connections http2.tcl cdrouter_http2_105 Verify HTTP/2 DELETE connections


    step 1. Send an HTTP/2 DELETE request to server
    step 2. Verify HTTP response is received


    References:

    IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"

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

Test Module Name Synopsis
Verify HTTP/2 GET connections with large number of headers http2.tcl cdrouter_http2_106 Verify HTTP/2 GET connections with large number of headers

    
    step 1. Send an HTTP/2 GET request to the server with the maximum allowed headers
    step 2. Verify HTTP response is received

    NOTE: The testvar httpMaxHeaderCount can be used to configure the number of
    headers that are applied during this test.


    References:

    IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"

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


http2-tls.tcl

HTTP/2 over TLS related test cases

Test Module Name Synopsis
Verify HTTP/2 GET connections over TLS http2-tls.tcl cdrouter_http2_tls_100 Verify HTTP/2 GET connections over TLS


    step 1. Send an HTTP/2 GET request to server over TLS
    step 2. Verify HTTP response is received


    References:

    IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"

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

Test Module Name Synopsis
Verify HTTP/2 POST connections over TLS http2-tls.tcl cdrouter_http2_tls_101 Verify HTTP/2 POST connections over TLS


    step 1. Send an HTTP/2 POST request to server over TLS
    step 2. Verify HTTP response is received


    References:

    IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"

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

Test Module Name Synopsis
Verify HTTP/2 HEAD connections over TLS http2-tls.tcl cdrouter_http2_tls_102 Verify HTTP/2 HEAD connections over TLS


    step 1. Send an HTTP/2 HEAD request to server over TLS
    step 2. Verify HTTP response is received


    References:

    IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"

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

Test Module Name Synopsis
Verify HTTP/2 PUT connections over TLS http2-tls.tcl cdrouter_http2_tls_103 Verify HTTP/2 PUT connections over TLS


    step 1. Send an HTTP/2 PUT request to server over TLS
    step 2. Verify HTTP response is received


    References:

    IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"

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

Test Module Name Synopsis
Verify HTTP/2 OPTIONS connections over TLS http2-tls.tcl cdrouter_http2_tls_104 Verify HTTP/2 OPTIONS connections over TLS


    step 1. Send an HTTP/2 OPTIONS request to server over TLS
    step 2. Verify HTTP response is received


    References:

    IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"

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

Test Module Name Synopsis
Verify HTTP/2 DELETE connections over TLS http2-tls.tcl cdrouter_http2_tls_105 Verify HTTP/2 DELETE connections over TLS


    step 1. Send an HTTP/2 DELETE request to server over TLS
    step 2. Verify HTTP response is received


    References:

    IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"

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

Test Module Name Synopsis
Verify HTTP/2 GET connections over TLS with large number of headers http2-tls.tcl cdrouter_http2_tls_106 Verify HTTP/2 GET connections over TLS with large number of headers

    
    step 1. Send an HTTP/2 GET request to the server over TLS with the maximum allowed headers
    step 2. Verify HTTP response is received

    NOTE: The testvar httpMaxHeaderCount can be used to configure the number of
    headers that are applied during this test.


    References:

    IETF RFC 7540 "Hypertext Transfer Protocol Version 2 (HTTP/2)"

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


heartbleed.tcl

Heartbleed vulnerability tests for CVE-2014-0160

Test Module Name Synopsis
Verify DUT's LAN HTTPS server is protected against heartbleed exploit heartbleed.tcl cdrouter_heartbleed_100 Verify DUT’s LAN HTTPS server is protected against heartbleed exploit


    step 1. Open an SSL session on the DUT's LAN HTTPS server.
    step 2. Transmit an SSL Heartbeat message whose length field is
            larger than its payload.
    step 3. Verify the DUT's LAN HTTPS server does not respond to SSL
            Heartbeat message.

    NOTE: The port of the DUT's LAN HTTPS server is taken from the
          default secure management port defined as the first port in
          the value of testvar dutSecureMgmtPort.  Please read the
          documentation for dutSecureMgmtPort for more information
          about the default secure management port concept and its
          usage.


    References:

    NIST CVE-2014-0160 (Heartbleed) Detail

    https://nvd.nist.gov/vuln/detail/CVE-2014-0160

Test Module Name Synopsis
Verify DUT's WAN HTTPS server is protected against heartbleed exploit heartbleed.tcl cdrouter_heartbleed_200 Verify DUT’s WAN HTTPS server is protected against heartbleed exploit


    step 1. Open an SSL session on the DUT's WAN HTTPS server.
    step 2. Transmit an SSL Heartbeat message whose length field is
            larger than its payload.
    step 3. Verify the DUT's WAN HTTPS server does not respond to SSL
            Heartbeat message.

    NOTE: The port of the DUT's WAN HTTPS server is taken from the
          default secure management port defined as the first port in
          the value of testvar dutSecureMgmtPort.  Please read the
          documentation for dutSecureMgmtPort for more information
          about the default secure management port concept and its
          usage.


    References:

    NIST CVE-2014-0160 (Heartbleed) Detail

    https://nvd.nist.gov/vuln/detail/CVE-2014-0160

Test Module Name Synopsis
Verify DUT's TR-069 client is protected against heartbleed exploit heartbleed.tcl cdrouter_heartbleed_300 Verify DUT’s TR-069 client is protected against heartbleed exploit


    step 1. Configure the DUT to use an alternate ACS.
    step 2. Initiate a new CWMP connection using Connection Request URL.
    step 3. Wait for new Inform from CPE.
    step 4. Transmit an SSL Heartbeat message whose length field is
            larger than its payload.
    step 5. Verify the DUT's WAN HTTPS server does not respond to SSL
            Heartbeat message.


    References:

    NIST CVE-2014-0160 (Heartbleed) Detail

    https://nvd.nist.gov/vuln/detail/CVE-2014-0160


ssl.tcl

SSL related test cases

Test Module Name Synopsis
Verify DUT's LAN HTTPS server refuses connections with deprecated SSL protocols ssl.tcl cdrouter_ssl_100 Verify DUT’s LAN HTTPS server refuses connections with deprecated SSL protocols


    step 1. Open a SSL session on the DUT's LAN HTTPS server on the
            port specified by testvar dutSecureMgmtPort using a
            deprecated version of SSL
    step 2. Verify the SSL connection is not established
    step 3. Repeat for all deprecated versions of SSL
    step 4. Open a SSL sesssion using a non-deprecated version of SSL

    NOTE: The list of deprecated SSL protocols is configured using the
          testvar sslDeprecatedProtocols.

    NOTE: The value of the DUT's LAN HTTPS port is taken from the
          default secure management port defined as the first port in
          the value of testvar dutSecureMgmtPort.  Please read the
          documentation for dutSecureMgmtPort for more information
          about the default secure management port concept and its
          usage.


Test Module Name Synopsis
Verify DUT's LAN HTTPS server refuses connections with deprecated SSL ciphers ssl.tcl cdrouter_ssl_200 Verify DUT’s LAN HTTPS server refuses connections with deprecated SSL ciphers


    step 1. Open a SSL session on the DUT's LAN HTTPS server on the
            port specified by testvar dutSecureMgmtPort using a
            deprecated SSL cipher
    step 2. Verify the SSL connection is not established
    step 3. Repeat for all deprecated SSL ciphers
    step 4. Open a SSL sesssion using a non-deprecated SSL cipher

    NOTE: The list of deprecated SSL ciphers is configured using the
          testvar sslDeprecatedCiphers.

    NOTE: The value of the DUT's LAN HTTPS port is taken from
          the default secure management port defined as the first port
          in the value of testvar dutSecureMgmtPort.  Please read the
          documentation for dutSecureMgmtPort for more information
          about the default secure management port concept and its
          usage.



gre.tcl

IPv4 over GRE related test cases

Test Module Name Synopsis
Verify traffic sent to remote GRE host from LAN is forwarded over IPv4 GRE tunnel gre.tcl gre_1 Verify traffic sent to remote GRE host from LAN is forwarded over IPv4 GRE tunnel


    step 1. Initiate outbound ICMPv4 Echo Requests from a host on the LAN to a
            host within the remote GRE network on the WAN
    step 2. Verify ICMPv4 Echo Replies are received


    References:

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

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

Test Module Name Synopsis
Verify traffic sent to LAN from remote GRE host is forwarded over IPv4 GRE tunnel gre.tcl gre_2 Verify traffic sent to LAN from remote GRE host is forwarded over IPv4 GRE tunnel


    step 1. Initiate inbound ICMPv4 Echo Requests from a host within the remote
            GRE network to a host on the LAN
    step 2. Verify ICMPv4 Echo Replies are received


    References:

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

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

Test Module Name Synopsis
Verify DUT's LAN IPv4 address is reachable over GRE tunnel gre.tcl gre_3 Verify DUT’s LAN IPv4 address is reachable over GRE tunnel


    step 1. Initiate inbound ICMPv4 Echo Requests from a host within the remote
            GRE network to the DUT's LAN IPv4 address
    step 2. Verify ICMPv4 Echo Reply is received


    References:

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

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

Test Module Name Synopsis
Verify GRE header fields for IPv4 packet gre.tcl gre_4 Verify GRE header fields for IPv4 packet


    step 1. Send an IPv4 UDP packet from a host on the LAN to a host within the
            remote GRE network on the WAN
    step 2. Verify that the IPv4 over GRE packet is received on the WAN
    step 3. Verify the following GRE header fields within the received packet:

            Checksum Present (bit 0):      May be 0 or 1
            Reserved0 (bits 1-12):         Must be set to 0
            Version Number (bits 13-15):   Must be set to 0


    References:

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

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

Test Module Name Synopsis
Verify DUT forwards GRE packets with valid GRE checksums gre.tcl gre_5 Verify DUT forwards GRE packets with valid GRE checksums


    step 1. Enable GRE checksums for remote GRE network
    step 2. Initiate outbound ICMPv4 Echo Requests from a host on the LAN to a
            host within the remote GRE network on the WAN
    step 3. Send ICMPv4 Echo Replies with valid GRE checksums
    step 4. Verify ICMPv4 Echo Replies are received


    References:

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

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

Test Module Name Synopsis
Verify DUT drops GRE packets with bad GRE checksums gre.tcl gre_6 Verify DUT drops GRE packets with bad GRE checksums


    step 1. Enable GRE checksums for remote GRE network
    step 2. Initiate outbound ICMPv4 Echo Requests from a host on the LAN to a
            host within the remote GRE network on the WAN
    step 3. Send ICMPv4 Echo Replies with bad GRE checksums
    step 4. Verify ICMPv4 Echo Replies are received


    References:

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

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

Test Module Name Synopsis
Verify DUT fragments large outbound packets sent over GRE tunnel gre.tcl gre_30 Verify DUT fragments large outbound packets sent over GRE tunnel


    step 1. Send an IPv4 UDP packet from the LAN to a remote GRE host on the WAN
            using a size that requires IPv4 fragmentation
    step 2. Verify that the packet and any fragments are received on the WAN
    step 3. Reassemble the packet and verify the original contents
    step 4. Repeat steps 1 through 3 with IPv4 packets that range in size from
            1490 bytes to 1500 bytes (these packets have a UDP payload size of
            1462 to 1472 bytes)


    References:

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

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

Test Module Name Synopsis
Verify DUT sends ICMPv4 Destination Unreachables if a GRE packet needs fragmentation and DF=1 gre.tcl gre_31 Verify DUT sends ICMPv4 Destination Unreachables if a GRE packet needs fragmentation and DF=1


    step 1. Send an IPv4 UDP packet from the LAN to a remote GRE host on the WAN
            using a size that requires IPv4 fragmentation with DF=1
    step 2. Verify that the DUT sends an ICMPv4 Destination Unreachable
    step 3. Verify that the ICMP code is 4 'fragmentation needed and DF set'


    References:

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

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

    IETF RFC 1191 "Path MTU Discovery" Section 2: Protocol overview

    In this memo, we describe a technique for using the Don't Fragment
    (DF) bit in the IP header to dynamically discover the PMTU of a path.
    The basic idea is that a source host initially assumes that the PMTU
    of a path is the (known) MTU of its first hop, and sends all
    datagrams on that path with the DF bit set.  If any of the datagrams
    are too large to be forwarded without fragmentation by some router
    along the path, that router will discard them and return ICMP
    Destination Unreachable messages with a code meaning "fragmentation
    needed and DF set" [7].  Upon receipt of such a message (henceforth
    called a "Datagram Too Big" message), the source host reduces its
    assumed PMTU for the path.

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

Test Module Name Synopsis
Verify DUT reassembles and forwards fragmented IPv4 UDP packets from the LAN over GRE tunnel gre.tcl gre_32 Verify DUT reassembles and forwards fragmented IPv4 UDP packets from the LAN over GRE tunnel


    step 1. Send an IPv4 UDP packet from the LAN to a remote GRE host on the WAN
            using a size that does not require fragmentation; send the packet as
            two IPv4 fragments
    step 2. Verify that the packet is reassembled and forwarded over the GRE
            tunnel by the DUT and received by the GRE host on the WAN


    References:

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

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

Test Module Name Synopsis
Verify DUT reassembles and forwards fragmented IPv4 UDP packets from the WAN over GRE tunnel gre.tcl gre_34 Verify DUT reassembles and forwards fragmented IPv4 UDP packets from the WAN over GRE tunnel


    step 1. Send an IPv4 UDP packet from the LAN to a remote GRE host on the WAN
            to establish an outbound connection
    step 2. Verify that the packet is received on the WAN
    step 3. Send an IPv4 UDP packet with a total UDP length of 1470 bytes from
            a remote GRE host on the WAN to a host on the LAN; send the packet
            as two IPv4 fragments
    step 4. Verify that the packet is reassembled and forwarded over the GRE
            tunnel by the DUT and received by the LAN host
    step 5. Repeat steps 2 through 4 for packets with total UDP lengths from
            1470 to 1480


    References:

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

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

Test Module Name Synopsis
Verify DUT reassembles and forwards fragmented IPv4 UDP packets from the WAN over GRE tunnel that also require fragmentation on the LAN gre.tcl gre_35 Verify DUT reassembles and forwards fragmented IPv4 UDP packets from the WAN over GRE tunnel that also require fragmentation on the LAN


    step 1. Send an IPv4 UDP packet from the LAN to a remote GRE host on the WAN
            to establish an outbound connection
    step 2. Verify that the packet is received on the WAN
    step 3. Send an IPv4 UDP packet with a total UDP length of 7997 bytes from
            a remote GRE host on the WAN to a host on the LAN; send the packet
            as two IPv4 fragments
    step 4. Verify that the packet is reassembled and forwarded over the GRE
            tunnel by the DUT and received by the LAN host
    step 5. Repeat steps 2 through 4 for packets with total UDP lengths from
            7997 to 8000


    References:

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

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

Test Module Name Synopsis
Verify DUT properly reassembles and forwards out of order IPv4 fragments gre.tcl gre_36 Verify DUT properly reassembles and forwards out of order IPv4 fragments


    step 1. Send an IPv4 UDP Echo packet from the LAN to a remote GRE host on
            the WAN
    step 2. Send an IPv4 UDP Echo response packet from the remote GRE host on
            the WAN to the LAN host; fragment the packet and send the fragments
            in reverse order
    step 3. Verify that the packet is reassembled and forwarded over the GRE
            tunnel by the DUT and received by the LAN host


    References:

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

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

Test Module Name Synopsis
Verify DUT sets the DF flag in the GRE delivery header gre.tcl gre_50 Verify DUT sets the DF flag in the GRE delivery header


    step 1. Send an IPv4 UDP packet to a remote GRE host on the WAN with the DF
            flag set to 0
    step 2. Verify packet is received by remote GRE host on the WAN
    step 3. Verify the DF flag in the GRE header based on the testvar greDFflag:

            When payload DF=0:

                "inherit" - the DF flag should be 0
                "off"     - the DF flag should be 0
                "on"      - the DF flag should be 1

            When payload DF=1

                "inherit" - the DF flag should be 1
                "off"     - the DF flag should be 0
                "on"      - the DF flag should be 1

    step 4. Repeat steps 1 through 3 for DF flag set to 1

    Referneces:

    RFC 2784

    RFC 7588 A Widely Deployed Solution to the Generic
               Routing Encapsulation (GRE) Fragmentation Problem

    3.3.2.1.  Tunneling GRE over IPv4

    By default, the GRE ingress node does not fragment delivery packets.
    However, the GRE ingress node includes a configuration option that
    allows delivery packet fragmentation.

    By default, the GRE ingress node sets the DF bit in the delivery
    header to 1 (Don't Fragment).  However, the GRE ingress node also
    supports a configuration option that invokes the following behavior:

    o  When the GRE payload is IPv6, the DF bit on the delivery header is
      set to 0 (Fragments Allowed).

    o  When the GRE payload is IPv4, the DF bit is copied from the
       payload header to the delivery header.

    When the DF bit on an IPv4 delivery header is set to 0, the GRE
    delivery packet can be fragmented by any router between the GRE
    ingress and egress nodes.


    References:

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

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

Test Module Name Synopsis
Verify DUT drops invalid GRE packets gre.tcl gre_60 Verify DUT drops invalid GRE packets


    step 1. Initiate an outbound ICMPv4 Echo Request from a host on the LAN to a
            host within the remote GRE network on the WAN
    step 2. Send an invalid ICMPv4 Echo Reply packet with a shortened GRE header
    step 3. Verify that the ICMPv4 Echo Reply packet is not forwarded to the LAN
    step 4. Repeat


    References:

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

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

Test Module Name Synopsis
Verify DUT supports PMTU discovery for packets sent over GRE tunnel gre.tcl gre_80 Verify DUT supports PMTU discovery for packets sent over GRE tunnel


    step 1. Send 1500 byte UDP packet with IP Don't Fragment Flag = 1 to the
            remoteVpn host over the GRE tunnel
    step 2. Check for an ICMP Destination Unreachable packet with code = 4
    step 3. Repeat process two more times until an ICMP Destination
            Unreachable is received, or all 3 packets are sent
    step 4. If an ICMP Destination Unreachable was sent, verify the
            the code value is 4 and verify MTU value in the ICMP header
    step 5. Reduce the UDP packet size by 1 byte and repeat the process
            until no ICMP Destination Unreachable is sent
    step 6. When a packet size is found that does not generate an
            ICMP Destination Unreachable, verify packets can be forwarded over
            GRE tunnel using this packet size
    step 7. Verify the final MTU size is the same as the MTU size
            reported in the ICMP Destination Unreachable packet

    NOTE: Some devices rate limit the number of ICMP packets that may be sent.
    This test will sent 3 UDP packets over a 15 second window in order to
    generate an ICMP unreachable packet. If your device uses rate limiting on
    ICMP packets, it must allow at least 1 ICMP packet every 10 seconds.


    References:

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

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

    IETF RFC 1191 "Path MTU Discovery"

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

Test Module Name Synopsis
Verify that all configured IPv4 over GRE tunnels are capable of forwarding traffic gre.tcl gre_100 Verify that all configured IPv4 over GRE tunnels are capable of forwarding traffic


    step 1. Initiate outbound ICMPv4 Echo Requests from a host on the LAN to a
            host within the remote GRE network on the WAN
    step 2. Verify ICMPv4 Echo Replies are received
    step 3. Repeat steps 1 and 2 for all configured GRE tunnels


    References:

    IETF RFC 2784 "Generic Routing Encapsulation (GRE)"

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


wifi.tcl

WiFi client association and verification tests

Test Module Name Synopsis
Graceful wireless LAN client restart wifi.tcl wifi_1 Graceful wireless LAN client restart


    step 1. Release LAN client's IPv4 address via DHCP
    step 2. If IPv6 is enabled and DHCPv6 was used on the LAN, also release LAN
            client's IPv6 address
    step 2. Force LAN client to disassociate from DUT's AP
    step 3. Force LAN client to associate to DUT's AP using initial association
            parameters
    step 4. Restart DHCP (and DHCPv6, if enabled) on LAN client to obtain IPv4
            and IPv6 addresses
    step 5. Send 10 IPv4 (and IPv6, if enabled) pings from the LAN client to a
            remote host on WAN to verify connectivity

    NOTE: This test simulates a graceful restart by a wireless LAN client where
    the DHCP address is released before the wireless disassociation occurs.


Test Module Name Synopsis
Restart wireless LAN client without releasing address wifi.tcl wifi_2 Restart wireless LAN client without releasing address


    step 1. Force LAN client to disassociate from DUT's AP
    step 2. Force LAN client to associate to DUT's AP using initial association
            parameters
    step 3. Restart DHCP (and DHCPv6, if enabled) on LAN client to obtain IPv4
            and IPv6 addresses
    step 4. Send 10 IPv4 (and IPv6, if enabled) pings from the LAN client to a
            remote host on WAN to verify connectivity

    NOTE: This test simulates a sudden restart by a wireless LAN client where
    the DHCP address is not released before the wireless disassociation occurs.


Test Module Name Synopsis
Restart wireless LAN client without releasing or obtaining a new address wifi.tcl wifi_3 Restart wireless LAN client without releasing or obtaining a new address


    step 1. Force LAN client to disassociate from DUT's AP
    step 2. Force LAN client to associate to DUT's AP using initial association
            parameters
    step 3. Send 10 IPv4 (and IPv6, if enabled) pings from the LAN client to a
            remote host on WAN to verify connectivity

    NOTE: This test simulates a sudden restart by a wireless LAN client where
    the DHCP address is not released before the wireless disassociation occurs
    and DHCP is not restarted when re-associated.


Test Module Name Synopsis
Verify connectivity using all wifi modes advertised by the DUT wifi.tcl wifi_10 Verify connectivity using all wifi modes advertised by the DUT


    step 1. Release LAN client's IPv4 address via DHCP if enabled
    step 2. If IPv6 is enabled and DHCPv6 was used on the LAN, also release LAN
            client's IPv6 address
    step 3. Force LAN client to disassociate from DUT's AP
    step 4. Force LAN client to associate to DUT's AP using an 802.11 phy mode,
            WPA mode, WPA key management mode, WPA pairwise cipher, and WPA
            group cipher advertised by the DUT in its wifi beacons on the LAN
    step 5. Restart DHCP and/or DHCPv6, if enabled, on LAN client to obtain IPv4
            and IPv6 addresses
    step 6. Send 10 IPv4 (and IPv6, if enabled) pings from the LAN client to a
            remote host on WAN to verify connectivity
    step 7. Repeat steps 1 through 6 for all combinations of 802.11 phy mode,
            WPA mode, WPA key management mode, WPA pairwise cipher, and WPA
            group cipher supported by the DUT
    step 8. Repeat steps 1 through 6 to re-associate LAN client with original
            wireless configuration

    This test cycles through all advertised, supported modes and verifies that
    a client can associate to the DUT and forward traffic.

    If the DUT is configured for WEP or no security, this test will cycle
    through all supported 802.11 phy modes using the existing security settings.

    NOTE: 802.11b and 802.11g association modes are virtually the same. If the
    DUT advertises support for 802.11b, CDRouter will associate as an 802.11b/g
    compatible client.


Test Module Name Synopsis
Verify DUT prevents use of TKIP cipher when using HT/VHT/HE wifi.tcl wifi_11 Verify DUT prevents use of TKIP cipher when using HT/VHT/HE


    step 1. Release LAN client's IPv4 address via DHCP if enabled
    step 2. If IPv6 is enabled and DHCPv6 was used on the LAN, also release LAN
            client's IPv6 address
    step 3. Force LAN client to disassociate from DUT's AP
    step 4. Force LAN client to associate to DUT's AP using a HT, VHT, or HE phy
            and a pairwise cipher of TKIP
    step 5. Ensure that the DUT either did not allow the LAN client to associate
            or the DUT's AP forced the LAN client to associate using an 802.11a phy
    step 6. Restart DHCP and/or DHCPv6, if enabled, on LAN client to obtain IPv4
            and IPv6 addresses
    step 7. Send 10 IPv4 (and IPv6, if enabled) pings from the LAN client to a
            remote host on WAN to verify connectivity
    step 8. Repeat steps 1 through 7 for all combinations of HT/VHT/HE phy mode,
            WPA mode, WPA key management mode, supported by the DUT
    step 9. Re-associate LAN client with original wireless configuration

    This test cycles through all advertised, supported modes and verifies that
    a client cannot associate to the AP using TKIP and 802.11ax/ac/n.

    If the DUT is configured for WEP or no security, this test cannot be run
    and will abort before the test begins.


Test Module Name Synopsis
Verify DUT's wifi beacons contain expected mode information wifi.tcl wifi_20 Verify DUT’s wifi beacons contain expected mode information


    step 1. Display saved wifi beacon from DUT
    step 2. Verify beacon contains expected phy mode(s)
    step 3. Verify beacon contains expected privacy bit value
    step 4. If WPA IE is present, validate the key management mode(s) that are
            advertised
    step 5. If WPA IE is present, validate the pairwise cipher modes(s) that are
            advertised
    step 6. If WPA IE is present, validate the group cipher modes(s) that are
            advertised
    step 7. Repeat steps 4 through 6 for RSN IE, if present

    NOTE: For step 2, the testvar wifiBeaconPhy can be used to specify a list of
    the phy modes that the DUT is expected to advertise in its beacons.

    NOTE: For step 3, if the lanSecurity testvar is set to a value of "NONE",
    the privacy bit should be set to 0 in all beacons from the DUT. For all
    other security modes where encryption is used it should be set to a value of
    1.

    NOTE: For steps 4 through 7, the testvar wifiBeaconWpaMode can be used to
    specify whether or not the DUT is expected to advertise support for WPA in
    its beacons. If WPA support is expected and the DUT is advertising support
    for it, the testvars wifiBeaconWpaKeyMgmt, wifiBeaconWpaCipher, and
    wifiBeaconWpaGroupCipher can be used to specify the expected ke management,
    pairwise cipher, and group cipher mode(s), respectivley, that the DUT is
    expected to support. These modes are validated in steps 2 through 4 of the
    test.


Test Module Name Synopsis
WiFi association stress test wifi.tcl wifi_30 WiFi association stress test


    step 1. Force LAN client to disassociate from DUT's AP
    step 2. Force LAN client to associate to DUT's AP using initial association
            parameters
    step 3. Repeat steps 1 and 2 100 times
    step 4. Send 10 IPv4 (and IPv6, if enabled) pings from the LAN client to a
            remote host on WAN to verify connectivity

    NOTE: This test verifies that the DUT is able to support a large number of
    wifi reassociation cycles (100) in rapid succession and can be problematic
    for some devices if repeated or run multiple times. Some devices may prevent
    associations from CDRouter's LAN client during or following this test,
    resulting in test failures due to a lack of connectivity with the DUT. This
    behavior is implementation specific and may be a feature or a bug within the
    DUT itself.


Test Module Name Synopsis
WiFi SSID scan test wifi.tcl wifi_40 WiFi SSID scan test


    step 1. Scan for all wireless networks matching the configured SSID
    step 2. Ensure the configured SSID is found
    step 3. Output all the matching wireless networks


Test Module Name Synopsis
WiFi Band Steering test wifi.tcl wifi_50 WiFi Band Steering test


    step 1. Disassociate the WLAN client from the access point
    step 2. Perform a wireless scan for the configured lanSSID
    step 3. Wait 2 seconds and repeat step 2
    step 4. If networks with the configured SSID are found on bands outside
            the lan80211BandSteering testvar after step 2, ensure the WLAN client
            cannot associate with those networks
    step 5. Ensure the WLAN client can associate with the networks found
            on the band specified by the lan80211BandSteering testvar
    step 6. Repeat step 1 through 5 with any additional WLAN clients



arp.tcl

ARP functional test cases

Test Module Name Synopsis
Verify DUT responds to broadcast ARP request on LAN interface arp.tcl arp_1 Verify DUT responds to broadcast ARP request on LAN interface


    step 1. Send a broadcast ARP request on the LAN for the DUT's LAN IP
    step 2. Verify that the DUT sends a valid ARP reply

    NOTE: A broadcast ARP request is sent to the layer 2 broadcast address of
    ff:ff:ff:ff:ff:ff. The ARP packet sent in this test contains the following
    fields and values:

    * Sender MAC address: <CDRouter's LAN MAC address>
    * Sender IP address:  <CDRouter's LAN IP address>
    * Target MAC address: 00:00:00:00:00:00
    * Target IP address:  <DUT's LAN IP address>


Test Module Name Synopsis
Verify DUT responds to unicast ARP request on LAN interface arp.tcl arp_2 Verify DUT responds to unicast ARP request on LAN interface


    step 1. Obtain the DUT's MAC address via ARP
    step 2. Send a unicast ARP request to the DUT's MAC address obtained in
            step 1 on the LAN for the DUT's LAN IP
    step 3. Verify that the DUT sends a valid ARP reply

    NOTE: A unicast ARP request is sent directly to the layer 2 unicast address
    of the target node, which in this case is the DUT. The ARP packet sent in
    this test contains the following fields and values:

    * Sender MAC address: <CDRouter's LAN MAC address>
    * Sender IP address:  <CDRouter's LAN IP address>
    * Target MAC address: 00:00:00:00:00:00
    * Target IP address:  <DUT's LAN IP address>


Test Module Name Synopsis
Verify DUT responds to ARP Probes on the LAN interface arp.tcl arp_3 Verify DUT responds to ARP Probes on the LAN interface


    step 1. Send an ARP Probe on the LAN for the DUT's LAN IP
    step 2. Verify that the DUT sends a valid ARP reply
    step 3. Send pings to a remote host on the WAN to verify connectivity from
            LAN to WAN

    NOTE: An 'ARP Probe' is a request sent to the layer 2 broadcast address of
    ff:ff:ff:ff:ff:ff using a 'Sender IP address' field of 0.0.0.0. The 'Target
    MAC address' field of an ARP Probe should also be set to all zeros. The ARP
    Probe sent in this test contains the following fields and values:

    * Sender MAC address: <CDRouter's LAN MAC address>
    * Sender IP address:  0.0.0.0
    * Target MAC address: 00:00:00:00:00:00
    * Target IP address:  <DUT's LAN IP address>


    References:

    IETF RFC 5227 "IPv4 Address Conflict Detection" Section 2.1: Probing an Address

    https://tools.ietf.org/html/rfc5227#section-2.1

Test Module Name Synopsis
Verify DUT updates ARP cache when ARP request is received arp.tcl arp_10 Verify DUT updates ARP cache when ARP request is received


    step 1.  Obtain the DUT's MAC address via ARP
    step 2.  Create a new host on the LAN (host2)
    step 3.  Enable DHCP on host2 and verify that an address is received
    step 4.  Send a gratuitous ARP for host2
    step 5.  Send three pings to the DUT from the host2
    step 6.  Verify that the DUT sends at least one ping response and that the
             DUT does not send an ARP request for host2's IP address
    step 7.  Release host2's IP address
    step 8.  Create a new host on the LAN (host3) with a unique MAC and staticly
             assign the same IP address obtained earlier by host2
    step 9.  Send ARP request for DUT's IP from host3
    step 10. Send three pings to the DUT from host3
    step 11. Verify that the DUT sends at least one ping response

    NOTE: This test verifies that the DUT updates its ARP cache when it receives
    an ARP request from a new client that is using an address that should
    have an existing entry in the cache.

    NOTE: The ARP request in step 9 is sent to the layer 2 broadcast address of
    ff:ff:ff:ff:ff:ff and contains the following fields and values:

    * Sender MAC address: <host 3's MAC address>
    * Sender IP address:  <host 3's IP address>
    * Target MAC address: 00:00:00:00:00:00
    * Target IP address:  <DUT's LAN IP address>


    References:

    IETF RFC 826 "An Ethernet Address Resolution Protocol": Packet Reception

    If the pair <protocol type, sender protocol address> is
        already in my translation table, update the sender
        hardware address field of the entry with the new
        information in the packet and set Merge_flag to true.

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

Test Module Name Synopsis
Verify DUT updates ARP cache when ARP reply is received arp.tcl arp_11 Verify DUT updates ARP cache when ARP reply is received


    step 1.  Obtain the DUT's MAC address via ARP
    step 2.  Create a new host on the LAN (host2)
    step 3.  Enable DHCP on host2 and verify that an address is received
    step 4.  Send a gratuitous ARP for host2
    step 5.  Send three pings to the DUT from host2
    step 6.  Verify that the DUT sends at least one ping response and that the
             DUT does not send an ARP request for host2's IP address
    step 7.  Release host2's IP address
    step 8.  Create a new host on the LAN (host3) with a unique MAC and staticly
             assign the same IP address obtained earlier by host2
    step 9.  Send 3 unsolicited ARP replies to the DUT from host3
    step 10. Send three pings to the DUT from host3
    step 11. Verify that the DUT sends at least one ping response

    NOTE: This test verifies that the DUT updates its ARP cache when it receives
    an unsolicited ARP reply from a new client that is using an address that
    should have an existing entry in the cache.

    NOTE: The ARP requests in step 9 are sent to the DUT's layer 2 hardware
    address and contains the following fields and values:

    * Sender MAC address: <host 3's MAC address>
    * Sender IP address:  <host 3's IP address>
    * Target MAC address: <DUT's MAC address>
    * Target IP address:  <DUT's LAN IP address>


    References:

    IETF RFC 826 "An Ethernet Address Resolution Protocol"

    If the pair <protocol type, sender protocol address> is
        already in my translation table, update the sender
        hardware address field of the entry with the new
        information in the packet and set Merge_flag to true.

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

Test Module Name Synopsis
Verify DUT updates ARP cache when a gratuitous ARP request is received arp.tcl arp_12 Verify DUT updates ARP cache when a gratuitous ARP request is received


    step 1.  Obtain the DUT's MAC address via ARP
    step 2.  Create a new host on the LAN (host2)
    step 3.  Enable DHCP on host2 and verify that an address is received
    step 4.  Send a gratuitous ARP for host2
    step 5.  Send three pings to the DUT from host2
    step 6.  Verify that the DUT sends at least one ping response and that the
             DUT does not send an ARP request for host2's IP address
    step 7.  Release host2's IP address
    step 8.  Create a new host on the LAN (host3) with a unique MAC and staticly
             assign the same IP address obtained earlier by host2
    step 9.  Send 3 gratuitous ARP requests from host3
    step 10. Send three pings to the DUT from host3
    step 11. Verify that the DUT sends at least one ping response

    NOTE: This test verifies that the DUT updates its ARP cache when it receives
    a gratuitous ARP request from a new client that is using an address that
    should have an existing entry in the cache. RFC 3927 and 5227 define this
    type of gratuitous ARP request as an "ARP Announcement".

    NOTE: The behavior of this test is controlled by the testvar
    arpSupportGratuitous. If this testvar is set to no, the test will accept
    certain failure conditions.

    NOTE: The ARP requests in step 9 are sent to the layer 2 broadcast address
    of ff:ff:ff:ff:ff:ff and contain the following fields and values:

    * Sender MAC address: <host 3's MAC address>
    * Sender IP address:  <host 3's IP address>
    * Target MAC address: 00:00:00:00:00:00
    * Target IP address:  <host 3's IP address>


    References:

    IETF RFC 826 "An Ethernet Address Resolution Protocol"

    If the pair <protocol type, sender protocol address> is
        already in my translation table, update the sender
        hardware address field of the entry with the new
        information in the packet and set Merge_flag to true.

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

    IETF RFC 2002 "IP Mobility Support" Section 4.6: ARP, Proxy ARP, and Gratuitous ARP

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

    IETF RFC 3927 "Dynamic Configuration of IPv4 Link-Local Addresses" Section 1.2: Terminology

    https://tools.ietf.org/html/rfc3927#section-1.2

    IETF RFC 5227 "IPv4 Address Conflict Detection" Section 1.1: Conventions and Terminology Used in This Document

    https://tools.ietf.org/html/rfc5227#section-1.1

Test Module Name Synopsis
Verify DUT updates ARP cache when a gratuitous ARP reply is received arp.tcl arp_13 Verify DUT updates ARP cache when a gratuitous ARP reply is received


    step 1.  Obtain the DUT's MAC address via ARP
    step 2.  Create a new host on the LAN (host2)
    step 3.  Enable DHCP on host2 and verify that an address is received
    step 4.  Send a gratuitous ARP for host2
    step 5.  Send three pings to the DUT from host2
    step 6.  Verify that the DUT sends at least one ping response and that the
             DUT does not send an ARP request for host2's IP address
    step 7.  Release host2's IP address
    step 8.  Create a new host on the LAN (host3) with a unique MAC and staticly
             assign the same IP address obtained earlier by host2
    step 9.  Send 3 gratuitous ARP reply packets from host3
    step 10. Send three pings to the DUT from host3
    step 11. Verify that the DUT sends at least one ping response

    NOTE: This test verifies that the DUT updates its ARP cache when it receives
    a gratuitous ARP reply from a new client that is using an address that
    should have an existing entry in the cache.

    NOTE: The behavior of this test is controlled by the testvar
    arpSupportGratuitous. If this testvar is set to no, the test will accept
    certain failure conditions.

    NOTE: The ARP requests in step 9 are sent to the layer 2 broadcast address
    of ff:ff:ff:ff:ff:ff and contain the following fields and values:

    * Sender MAC address: <host 3's MAC address>
    * Sender IP address:  <host 3's IP address>
    * Target MAC address: <host 3's MAC address>
    * Target IP address:  <host 3's IP address>


    References:

    IETF RFC 826 "An Ethernet Address Resolution Protocol"

    If the pair <protocol type, sender protocol address> is
        already in my translation table, update the sender
        hardware address field of the entry with the new
        information in the packet and set Merge_flag to true.

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

    IETF RFC 2002 "IP Mobility Support" Section 4.6: ARP, Proxy ARP, and Gratuitous ARP

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

    IETF RFC 3927 "Dynamic Configuration of IPv4 Link-Local Addresses" Section 1.2: Terminology

    https://tools.ietf.org/html/rfc3927#section-1.2

    IETF RFC 5227 "IPv4 Address Conflict Detection" Section 1.1: Conventions and Terminology Used in This Document

    https://tools.ietf.org/html/rfc5227#section-1.1

Test Module Name Synopsis
Verify DUT does not respond to bad ARP Requests arp.tcl arp_20 Verify DUT does not respond to bad ARP Requests


    step 1. Send a broadcast ARP request on the LAN for the loopback address
            127.0.0.1
    step 2. Verify that the DUT does not respond
    step 3. Repeat steps 1 and 2 for the addresses 255.255.255.255, 0.0.0.0, and
            224.0.0.1


Test Module Name Synopsis
Verify DUT does not leak WAN side addresses on LAN via ARP arp.tcl arp_30 Verify DUT does not leak WAN side addresses on LAN via ARP


    step 1. Look through the ARP history of all LAN stacks that have been
            created to this point
    step 2. Verify that the DUT has not sent an ARP request for its WAN gateway
            on LAN

    NOTE: the DUT should only send ARP requests for its default gateway on the
    WAN. Sending these requests out on the LAN leaks the default gateway address
    making it possible for malicious clients to spoof the default gateway and
    influence the DUT's routing table. This can lead to a DoS situation for
    other LAN clients.

    There are several existing CVEs that mention this type of issue:

    CVE-1999-0763 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-0763
    CVE-1999-0667 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-0667

    NOTE: This is a new type of CDRouter test that analyzes data generated from
    previous tests. In this case the data being analyzed is the ARP history of
    all LAN clients that have been created up to the point where this test was
    executed during a particular test run. To ensure that the largest possible
    data set is analyzed, this test should be executed at the end of a test run
    or at multiple points during a test run.


Test Module Name Synopsis
Verify DUT does not leak LAN side addresses on WAN via ARP arp.tcl arp_31 Verify DUT does not leak LAN side addresses on WAN via ARP


    step 1. Look through the ARP history of all WAN stacks that have been
            created to this point
    step 2. Verify DUT has not sent ARP request for LAN side hosts

    Reference:

    The DUT should only send ARP requests for LAN clients on the LAN. Sending
    these requests out on the WAN leaks LAN side addresses and could make the
    DUT vulnerable to spoofing LAN side hosts from the WAN.

    There are several existing CVEs that mention this type of issue:

    CVE-1999-0763 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-0763
    CVE-1999-0667 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-1999-0667

    NOTE: This is a new type of CDRouter test that analyzes data generated from
    previous tests. In this case the data being analyzed is the ARP history of
    all LAN clients that have been created up to the point where this test was
    executed during a particular test run. To ensure that the largest possible
    data set is analyzed, this test should be executed at the end of a test run
    or at multiple points during a test run.


Test Module Name Synopsis
Verify DUT ARP mode behavior - open, restricted, strict arp.tcl arp_40 Verify DUT ARP mode behavior - open, restricted, strict


    step 1. Send ARP request for DUT's WAN IP address on the LAN
    step 2. Verify the DUT's expected ARP behavior regarding the request sent
            in step 1 according to the value of the arpMode testvar
    step 3. Send ARP request for DUT's LAN IP address on the LAN using a client
            with an address that is not within the LAN subnet
    step 4. Verify the DUT's expected ARP behavior regarding the request sent
            in step 3 according to the value of the arpMode testvar

    NOTE: The arpMode testvar specifies the expected ARP behavior of the DUT,
    which can be set to one of three values:

    * open:       The DUT will reply for any local target IP address, configured
                  on any interface.
    * restricted: The DUT will reply only if the target IP address is a local
                  address configured on the incoming interface.
    * strict:     The DUT will reply only if the target IP address is a local
                  address configured on the incoming interface and if the
                  sender's IP address is within the same subnet.

    The recommended ARP behavior is restricted or strict.

    NOTE: For more information please see the Linux kernel documentation for the
    arp_ignore flag:

    https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt


Test Module Name Synopsis
Verify DUT ignores spoofed ARP reply for WAN gateway arp.tcl arp_50 Verify DUT ignores spoofed ARP reply for WAN gateway


    step 1. Obtain the DUT's MAC address via ARP
    step 2. Create a new host on the LAN (host2)
    step 3. Enable DHCP on host2 and verify that an address is received
    step 4. Send 3 spoofed ARP replies from host2 to the DUT for the DUT's WAN
            default gateway
    step 5. Verify the DUT ignored the ARP replies sent in step 4 by testing LAN
            to WAN connectivity using pings
    step 6. Verify that the pings sent in step 5 are successful
    step 7. Restore the DUT's WAN gateway ARP entry by sending an ARP request
            for the DUT's IP on the WAN
    step 8. Verify LAN to WAN connectivity through the DUT using pings


    References:

    IETF RFC 5227 "IPv4 Address Conflict Detection" Section 2.1: Probing an Address

    https://tools.ietf.org/html/rfc5227#section-2.1

Test Module Name Synopsis
Verify DUT handles a large number of ARP requests with unique MAC addresses arp.tcl arp_60 Verify DUT handles a large number of ARP requests with unique MAC addresses


    step 1. Send a unicast ARP request on the LAN for the DUT's LAN IP
    step 2. Repeat for 500 unique source MAC addresses (only 20 unique source
            MAC for wireless interfaces)
    step 3. Send a broadcast ARP request on the LAN for the DUT's LAN IP
    step 4. Verify an ARP reply is received


Test Module Name Synopsis
Verify DUT handles a large number of ARP replies with unique MAC addresses arp.tcl arp_61 Verify DUT handles a large number of ARP replies with unique MAC addresses


    step 1. Send a unicast ARP reply to the DUT on the LAN
    step 2. Repeat for 500 unique source MAC addresses (only 20 unique source
            MAC for wireless)
    step 3. Send a broadcast ARP request on the LAN for the DUT's LAN IP
    step 4. Verify an ARP reply is received


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: