Tests channel zap time , channel surfing experience, join/leave functions and latency , join/jump channel functions and latency, join/next channel functions and latency, duplicate joins , duplicate leaves, emulates 100s/1000s of Channels and subscribers for TLS Authentication, DHCP address assignment and subscriber traffic validation .
| ID | Title | Function Name | Test Steps | Expected Result |
| Subs_1 | Verify subscriber joining and receiving traffic | test_subscriber_join_recv_channel | 1. Send a EAPOL start message for TLS authentication. 2. Send a DHCP discover packet from the client. 3. Verify joining to a particular group. | 1. TLS authentication should be successful. 2. IP address should be assigned to client. 3. Interface should receive traffic. |
| Subs_2 | Verify joining and jumping to the next channel for channel surfing | test_subscriber_join_jump_channel | 1. Send a EAPOL start message for TLS authentication. 2. Jump to the next ip. 3. Jump to the next channel and verify the traffic | 1. TLS authentication should be successful. 2. IP address should be assigned to client. 3. Interface should receive traffic. Also it should show the jump RX stats for subscriber. |
| Subs_3 | Test subscriber join next for channels | test_subscriber_join_next_channel | 1. Send a EAPOL start message for TLS authentication. 2. Join the next channel and verify the traffic. | 1.TLS authentication should be successful. 2. Interface should receive traffic |
| Subs_4 | Verify subscriber TLS authentication by sending invalid client certificate | test_subscriber_authentication_with_invalid_certificate_and_channel_surfing | 1. Send an invalid Client Hello TLS Certificate. 2. Send a DHCP discover packet from the subscriber. | 1. Authentication should not be successful. 2. Subscriber should not receive any ip from DHCP server. |
| Subs_5 | Verify subscriber TLS authentication by sending no client certificate | test_subscriber_authentication_with_no_certificate_and_channel_surfing | 1. Send an blank Client Hello TLS Certificate. 2. Send a DHCP discover packet from the subscriber. | 1.Authentication should not be successful. 2.Subscriber shouldn’t receive any ip from DHCP server. |
| Subs_6 | Verify subscriber TLS authentication by sending self signed certificate | test_subscriber_authentication_with_self_signed_certificate_and_channel_surfing | 1. Send a self sigend Client Hello TLS Certificate. 2. Send a DHCP discover packet from the subscriber. | 1.Authentication should not be successful. 2.Subscriber shouldn’t receive any ip from DHCP server. |
| Subs_7 | Verify subscribers TLS authenticatiby sending non ca certificate. | test_subscriber_authentication_with_non_ca_authorized_certificate_and_channel_surfing | 1. Send a non ca Hello TLS Certificate. 2. Send a DHCP discover packet from the subscriber. | 1.Authentication should not be successful. 2.Subscriber shouldn’t receive any ip from DHCP server. |
| Subs_8 | Verify subscriber with dhcp rediscover functionality | test_subscriber_authentication_with_dhcp_discover_and_channel_surfing | 1. Send a DHCP discover packet from the subscriber. 2. Send DHCP release and again send dhcp discover from the client. | 1. DHCP Ack should get received. 2. After releasing and then re-sending, dhcp ip address assignment should be successful. |
| Subs_9 | Verify the DHCP process when the subscriber becomes down and up. | test_subscriber_authentication_with_dhcp_client_reboot_scenario_and_channel_surfing | After DHCP address assignment to the client, make the subscriber down and then make it up. | Once its up, DHCP request message should be sent from the client to the server which is unicast. |
| Subs_10 | Verify the DHCP process when the DHCP server becomes down and up. | test_subscriber_authentication_with_dhcp_server_reboot_scenario_and_channel_surfing | 1. Send a DHCP discover packet . 2. Send a DHCP request packet from the client. 3. Make the DHCP server down. 4. Make the DHCP server up. | 1. DHCP offer packet generated. 2. DHCP Ack packet generated. 3. Client should have the same ip till the lease time expires. 4. DHCP Ack should be sent from the server. |
| Subs_11 | Verify dhcp subscriber rebind process | test_subscriber_authentication_with_dhcp_client_rebind_and_channel_surfing | After Rebind timer expires, a DHCP request message which is broadcast is being sent . | Since the server is up and reachable , it should respond back with DHCP Ack packet |
| Subs_12 | Verify DHCP subscriber starvation attack | test_subscriber_authentication_with_dhcp_starvation_scenario_and_channel_surfing | 1. Let the authentication be successful. 2. Send a lot of dummy DHCP requests, with random source Mac address (using Scapy) | After few second, there is no more IP addresses available in the pool, thus successfully performing denial of service attack to other subscriber |
| Subs_13 | Verify ip address assignment is successful when DHCP discover is sent twice. | test_subscriber_authentication_with_multiple_dhcp_discover_for_same_subscriber_and_channel_surfing | Let authentication be successful. Send DHCP discover message twice from the client. | DHCP server should give the same ip to the client using the DHCP Ack packet. |
| Subs_14 | Verify ip address assignment is successful when DHCP request is sent twice. | test_subscriber_authentication_with_multiple_dhcp_request_for_same_subscriber_and_channel_surfing | 1. Send a DHCP discover message from the client. 2. Send DHCP request message. 3. Again send DHCP request message. | 1. DHCP offer should be sent from the server. 2. DHCP Ack should get received. |
| Subs_15 | Verify subscriber ip address assignment is successful when desired ip is sent. | test_subscriber_authentication_with_dhcp_client_requested_ip_and_channel_surfing | 1.Let the authentication be successful. Send a DHCP discover packet with the desired ip which is in the server address pool. 2.Send DHCP discover message twice from the client. | DHCP ip address assignment should be successful. |
| Subs_16 | Verify ip address assignment when dhcp request and offer ip are different | test_subscriber_authentication_with_dhcp_non_offered_ip_and_channel_surfing | 1. Let the authentication be successful. 2. Send a DHCP discover message from the client. 3. Send DHCP request message with a different ip. | 2. DHCP offer should be sent from server. 3. DHCP NAK should be sent from the server. |
| Subs_17 | Verify subscriber ip address assignment when desired ip is sent which is out of the pool. | test_subscriber_authentication_with_dhcp_request_out_of_pool_ip_by_client_and_channel_surfing | 1. Let the authentication be successful. 2. Send a DHCP discover packet with the desired ip which is out of the server address pool | DHCP NAK message should be sent |
| Subs_18 | Verify subscriber ip address assignement with the lease time information specified. | test_subscriber_authentication_with_dhcp_specified_lease_time_functionality_and_channel_surfing | 1. Let the authentication be successful. 2. Send a DHCP discover packet with the least time mentioned. | DHCP ip address assignment should be successful with the mentioned lease time. |
| Subs_19 | Verify subscriber join and receive with multiple channels 100 | test_subscriber_join_recv_100channels | 1. Send a EAPOL start message for TLS authentication. 2. Send a DHCP discover packet from the client. 3. Verify joining to 100 channels | 1. TLS authentication should be successful. 2. IP address should be assigned to client. 3. All interfaces should receive traffic. |
| Subs_20 | Verify subscribers jumping to 100channels. | test_subscribers_join_jump_100channel | 1.Send a DHCP discover from 10 subscribers. 2. Jump to 5 channels and verify the traffic | 1.IP address should be assigend to all the subscribers. 2. All interfaces should receive traffic. |
| Subs_21 | Verify subscribers joining next to 100 channels. | test_subscribers_join_next_100channel | 1.Send a DHCP discover from 10 subscribers. 2. Join next to 5 channels and verify the traffic | 1.IP address should be assigend to all the subscribers. 2. All interfaces should receive traffic. |
| Subs_22 | Verify subscriber join and receive with multiple channels 400 | test_subscriber_join_recv_400channel | 1. Send a EAPOL start message for TLS authentication. 2. Send a DHCP discover packet from the client. 3. Verify joining to 400 channels | 1. TLS authentication should be successful. 2. IP address should be assigned to client. 3. All interfaces should receive traffic. |
| Subs_23 | Verify subscriber join and receive with multiple channels 800 | test_subscriber_join_recv_800channels | 1. Send a EAPOL start message for TLS authentication. 2. Send a DHCP discover packet from the client. 3. Verify joining to 800 channels | 1. TLS authentication should be successful. 2. IP address should be assigned to client. 3. All interfaces should receive traffic. |
| Subs_24 | Verify subscriber join and receive with 1500 multiple channels | test_subscriber_join_recv_1500channel | 1. Send a EAPOL start message for TLS authentication from a subscriber 2. Send a DHCP discover packet 3. Verify joining to 1500 channels. | 1. TLS authentication should be successful. 2. IP address should be assigned to all the clients. 3. All interfaces should receive traffic. |
| Subs_25 | Verify joining and jumping to 400 channels for channel surfing | test_subscriber_join_jump_400channel | 1. Send a EAPOL start message for TLS authentication. 2. Jump to the next 400 channels and verify the traffic | 1. TLS authentication should be successful. 2. All Interfaces should receive traffic. Also it should show the jump RX stats for subscriber. |
| Subs_26 | Verify joining and jumping to 800 channels for channel surfing | test_subscriber_join_jump_800channel | 1. Send a EAPOL start message for TLS authentication. 2. Jump to the next 800 channels and verify the traffic | 1. TLS authentication should be successful. 2. All Interfaces should receive traffic. Also it should show the jump RX stats for subscriber. |
| Subs_27 | Verify joining and jumping to 1200 channels for channel surfing | test_subscriber_join_jump_1200channel | 1. Send a EAPOL start message for TLS authentication. 2. Jump to the next 1200 channels and verify the traffic | 1. TLS authentication should be successful. 2. All Interfaces should receive traffic. Also it should show the jump RX stats for subscriber. |
| Subs_28 | Verify joining and jumping to 1500 channels for channel surfing | test_subscriber_join_jump_1500channel | 1. Send a EAPOL start message for TLS authentication. 2. Jump to the next 1500 channels and verify the traffic | 1. TLS authentication should be successful. 2. All Interfaces should receive traffic. Also it should show the jump RX stats for subscriber. |
| Subs_29 | Test subscriber join next for 400 channels | test_subscriber_join_next_400channel | 1. Send a EAPOL start message for TLS authentication from a subscriber 2. Join the next 400 channels and verify the traffic | 1. TLS authentication should be successful. 2. Interfaces should receive traffic. |
| Subs_30 | Test subscriber join next for 800 channels | test_subscriber_join_next_800channel | 1. Send a EAPOL start message for TLS authentication from a subscriber 2. Join the next 800 channels and verify the traffic | 1. TLS authentication should be successful. 2. Interfaces should receive traffic. |
| Subs_31 | Test subscriber join next for 1200 channels | test_subscriber_join_next_1200channel | 1. Send a EAPOL start message for TLS authentication from a subscriber 2. Join the next 1200 channels and verify the traffic | 1. TLS authentication should be successful. 2. Interfaces should receive traffic. |
| Subs_32 | Test subscriber join next for 1500 channels | test_subscriber_join_next_1500channel | 1. Send a EAPOL start message for TLS authentication from a subscriber 2. Join the next 1500 channels and verify the traffic | 1. TLS authentication should be successful. 2. Interfaces should receive traffic. |