SNTP - Simple Network Time Protocol ======================================= .. panels:: :container: container pb-4 :column: col-lg-12 p-2 :card: shadow .. panels:: :container: container pb-4 :column: col-lg-12 p-2 :card: shadow **What is SNTP?** SNTP (Simple Network Time Protocol) is a protocol used to synchronize the clocks of computers and devices over a network. It is a simplified version of NTP (Network Time Protocol) that offers less precision, making it suitable for less demanding time synchronization needs. .. panels:: :container: container pb-4 :column: col-lg-12 p-2 :card: shadow **Why is SNTP useful?** * Provides a simple and lightweight way to synchronize system clocks. * Ensures consistent timekeeping across devices in a network. * More efficient and less complex than NTP, ideal for systems where high precision isn't critical. * Widely supported by various devices and operating systems. .. panels:: :container: container pb-4 :column: col-lg-12 p-2 :card: shadow **How it works?** * A client sends a request to an SNTP server, typically over UDP. * The server responds with the current time. * The client adjusts its system clock based on the response. * The protocol does not perform complex time correction algorithms, making it less accurate than NTP, but sufficient for most applications. .. panels:: :container: container pb-4 :column: col-lg-12 p-2 :card: shadow **Where is SNTP used?** * SNTP is commonly used in environments where precise time synchronization is not a priority. * It is typically used in consumer devices, home routers, printers, and embedded systems. * Often found in systems with limited processing power or where NTP’s high precision isn’t necessary. .. panels:: :container: container pb-4 :column: col-lg-12 p-2 :card: shadow **Which OSI layer does this protocol belong to?** * SNTP operates at the Application Layer (Layer 7) of the OSI model. * It uses lower layers (Transport Layer and Network Layer) for communication, typically relying on UDP at the Transport Layer. .. panels:: :container: container pb-4 :column: col-lg-12 p-2 :card: shadow **Is SNTP Windows specific?** * No, SNTP is not Windows-specific. * It is supported by a wide range of operating systems including Linux, macOS, and many embedded devices. .. panels:: :container: container pb-4 :column: col-lg-12 p-2 :card: shadow **Is SNTP Linux specific?** * No, SNTP is not Linux-specific. * It is supported by various operating systems and is commonly used in a wide range of devices across different platforms. .. panels:: :container: container pb-4 :column: col-lg-12 p-2 :card: shadow **Which Transport Protocol is used by SNTP?** * SNTP typically uses UDP (User Datagram Protocol) at the Transport Layer. * UDP is used because it provides low-latency communication, which is suitable for time synchronization. .. panels:: :container: container pb-4 :column: col-lg-12 p-2 :card: shadow **Which Port is used by SNTP?** * SNTP operates on UDP port 123. * This is the same port used by NTP, as SNTP is essentially a simplified version of it. .. panels:: :container: container pb-4 :column: col-lg-12 p-2 :card: shadow **Is SNTP using Client-server model?** * Yes, SNTP follows the client-server model. * The client sends a request to the SNTP server, and the server responds with the current time. .. panels:: :container: container pb-4 :column: col-lg-12 p-2 :card: shadow Topics in this section, * :ref:`Learnings in this section ` * :ref:`Terminology ` * :ref:`Version Info ` * :ref:`SNTP Version&RFC Details ` * :ref:`SNTP Basic Setup on Ubuntu using IPv4 ` * :ref:`SNTP Basic Setup on Ubuntu using IPv6 ` * :ref:`SNTP Protocol Packet Details ` * :ref:`SNTP Usecases ` * :ref:`SNTP Basic Features ` * :ref:`SNTP Feature : Simplicity ` * :ref:`SNTP Feature : Time Synchronization ` * :ref:`SNTP Feature : UDP-Based Communication ` * :ref:`SNTP Feature : Low Overhead ` * :ref:`SNTP Feature : Compatibility with NTP servers ` * :ref:`SNTP Feature : Support for IPv4 and IPv6 ` * :ref:`SNTP Feature : One-Way Communication ` * :ref:`SNTP Feature : Periodic Updates ` * :ref:`Reference links ` .. _SNTP_step1: .. tab-set:: .. tab-item:: Learnings in this section * In this section, you are going to learn .. _SNTP_step2: .. tab-set:: .. tab-item:: Terminology * Terminology .. _SNTP_step3: .. tab-set:: .. tab-item:: Version Info * Version Info .. _SNTP_step5: .. tab-set:: .. tab-item:: SNTP Version&RFC Details .. csv-table:: :file: ./SNTP/sntp_rfc_details.csv :widths: 10,10,10,30 :header-rows: 1 .. _SNTP_step18: .. tab-set:: .. tab-item:: SNTP Basic Setup on Ubuntu using IPv4 **SNTP C Code (Client-Server Model over UDP)** * This C program demonstrates how to build a simple SNTP (Simple Network Time Protocol) server and client using UDP sockets. * The **SNTP server** (mode 4) listens on a UDP port and responds with a basic NTP packet containing the transmit timestamp. * The **SNTP client** (mode 3) sends a request to the server and reads the transmit timestamp to print the server time. * This setup is useful for testing SNTP communication, simulating time servers, or learning basic NTP packet structure. * Replace the server IP address (`127.0.0.1`) in the client code with your actual SNTP server address before running. * Step-1: Download C source code for SNTP server and client. :download:`Download SNTP Server Code ` :download:`Download SNTP Client Code ` * Step-2: Convert C code to executable files. .. code-block:: shell test:~$gcc sntp_server.c -o sntp_server test:~$gcc sntp_client.c -o sntp_client * Step-3: Run SNTP server and client. .. code-block:: shell # Start SNTP server (may require sudo if using port 123) test:~$sudo ./sntp_server SNTP server listening on port 123... # Run SNTP client test:~$ ./sntp_client Server time: Wed Jul 31 13:44:28 2025 * Step-4: Wireshark Capture :download:`Download Wireshark capture ` **SNTP Client Code with Error Handling (Invalid Server IP Demonstration)** * This C program demonstrates how an SNTP client handles network errors when provided with an invalid or unreachable NTP server IP address. * The client constructs a basic NTP request packet (mode 3), sends it to the specified IP, and waits for a response. * If the IP address is invalid, or no response is received within 3 seconds, the program prints a relevant error message. * This is useful for testing SNTP client robustness, network failure scenarios, or for educational purposes. * Step-1: Download C source code for SNTP invalid server IP test. :download:`Download SNTP Client (Invalid IP Test) ` * Step-2: Convert C code to executable file. .. code-block:: shell test:~$ gcc sntp_invalid_ip_client.c -o sntp_invalid_ip_client * Step-3: Run SNTP client with an invalid or unreachable IP. .. code-block:: shell test:~$ ./sntp_invalid_ip_client 192.0.2.1 Packet sent to 192.0.2.1. Waiting for response... Receive failed: Resource temporarily unavailable .. note:: - `192.0.2.1` is a reserved non-routable IP (TEST-NET-1) and is commonly used for documentation. - The client sets a 3-second receive timeout to avoid indefinite blocking. * Step-4: Wireshark Capture :download:`Download Wireshark capture ` **SNTP Wrong Mode Packet Injection (Mode 7 - Reserved/Private Use)** * This C program demonstrates how to manually construct and send an SNTP/NTP packet with an invalid mode field: * Mode 7 (Reserved / Private) is not used in standard client-server communication and is typically rejected or ignored by NTP servers. * The client sets LI = 0, VN = 4, Mode = 7 and sends it to a specified NTP server over UDP. * This test is useful for: * Evaluating how NTP servers handle non-standard or malformed mode values. * Auditing firewalls and NTP-aware intrusion detection systems. * Learning how NTP mode bits work at the packet level. * Step-1: Download the C source code for wrong mode packet generation. :download:`Download SNTP Wrong Mode Code ` * Step-2: Convert the C code to an executable file. .. code-block:: shell test:~$ gcc sntp_wrong_mode.c -o sntp_wrong_mode * Step-3: Run the wrong-mode SNTP client with the target NTP server IP. .. code-block:: shell test:~$ ./sntp_wrong_mode 216.239.35.0 Wrong-mode NTP packet (mode 7) sent to 216.239.35.0 .. note:: - Replace `216.239.35.0` with your actual test NTP server IP. - Most compliant servers will ignore or drop mode 7 packets without replying. * Step-4: Wireshark Capture :download:`Download Wireshark capture (mode 7 test) ` **SNTP Delayed Response Simulation (Send and Receive Timestamped NTP Packets)** * This C program demonstrates how to send a fully formed SNTP (Simple Network Time Protocol) request to a server and then receive and interpret the response, including transmit timestamps. * The client sends a well-formed NTPv4 packet using Mode 3 (Client) and a valid transmit timestamp. * The program sets a 2-second socket timeout to simulate how SNTP clients handle slow or unresponsive servers. * The received NTP packet is decoded and the transmit timestamp is converted to a human-readable date/time. * This is useful for: * Understanding client-side time parsing in SNTP. * Testing server responsiveness and round-trip behavior. * Simulating timeout or delay handling in a lightweight SNTP implementation. * Step-1: Download the C source code for SNTP delayed response client. :download:`Download SNTP Delayed Response Code ` * Step-2: Compile the C code into an executable. .. code-block:: shell test:~$ gcc sntp_delayed_response.c -o sntp_delayed_response * Step-3: Run the SNTP client and observe server response or timeout. .. code-block:: shell test:~$ ./sntp_delayed_response 129.6.15.28 NTP request sent to 129.6.15.28. Waiting for response... Response received in 365.73 ms Server time: 2025-07-31 12:34:46 .. note:: - Replace `129.6.15.28` with the IP of a valid public or local NTP server. - If no response is received within 2 seconds, a timeout error will be shown. * Step-4: Wireshark Capture :download:`Download Wireshark capture (delayed SNTP test) ` **SNTP C Client Querying Multiple NTP Servers** * This C program implements a basic SNTP client that sends an NTP request (Mode 3) to a given NTP server. * It constructs a 48-byte SNTP packet, sends it via UDP, waits for the response, extracts the transmit timestamp, and converts it to human-readable local time. * This can be used to verify synchronization accuracy across multiple public NTP servers. * Step-1: Download C source code for SNTP client. :download:`Download SNTP client code ` * Step-2: Compile the source code into an executable. .. code-block:: shell test:~$ gcc sntp_client_1.c -o sntp_client_1 * Step-3: Run the SNTP client with different public NTP server IPs. .. code-block:: shell test:~$ ./sntp_client_1 129.6.15.28 #time.google.com Server Time: Thu Jul 31 12:45:28 2025 test:~$ ./sntp_client_1 216.239.35.12 #pool.ntp.org Server Time: Thu Jul 31 12:45:30 2025 test:~$ ./sntp_client_1 40.119.6.228 #time.windows.com Server Time: Thu Jul 31 12:45:32 2025 * Step-4: Analyze server time differences or round-trip delays using Wireshark. :download:`Download Wireshark capture ` **SNTP Version Mismatch Test (Version 1 Packet to NTPv4 Server)** * This C program sends an SNTP packet using **NTP Version 1**, which is outdated and not typically supported by modern NTP servers (which use v3 or v4). * It is useful for testing how NTP servers handle requests with unsupported or mismatched protocol versions. * This helps in evaluating server behavior and backward compatibility with legacy clients. * Step-1: Download C source code for SNTP version mismatch test. :download:`Download C source code ` * Step-2: Compile the source code into an executable. .. code-block:: shell test:~$ gcc sntp_version_mismatch.c -o sntp_version_mismatch * Step-3: Send version 1 SNTP request to an NTPv4 server. .. code-block:: shell test:~$ ./sntp_version_mismatch 216.239.35.0 NTP packet with version 1 sent to 216.239.35.0 * Step-4: Observe behavior: * No response or timeout indicates the server rejects outdated versions. * Use Wireshark or tcpdump to analyze network-level handling. * Step-5: Capture the packet exchange using Wireshark. :download:`Download Wireshark capture ` **SNTP Malformed Packet Test** * This C program sends a **malformed NTP packet** (only 20 bytes, whereas a valid NTP/SNTP packet must be 48 bytes) to an NTP server. * The purpose of this test is to observe how the NTP server handles improperly sized or corrupted packets. * This can be used for robustness testing, fuzzing, or input validation verification. * Step-1: Download the C source code for malformed packet generation. :download:`Download malformed packet code ` * Step-2: Compile the source code. .. code-block:: shell test:~$ gcc sntp_malformed.c -o sntp_malformed * Step-3: Run the executable against an NTP server. .. code-block:: shell test:~$ ./sntp_malformed 216.239.35.0 Malformed packet (20 bytes) sent to 216.239.35.0 * Step-4: Observe behavior: * The server may silently drop the packet. * Use Wireshark or tcpdump to confirm packet dispatch and any server response. * Step-5: Capture and analyze using Wireshark. :download:`Download Wireshark capture ` **SNTP Rapid-Fire Request Test** * This C program sends **10 consecutive SNTP requests** in rapid succession (100ms apart) to a specified NTP server. * It is used to simulate a burst of time requests to observe: * Server rate-limiting behavior. * Whether the server drops packets under load. * How responses are handled when queried at high frequency. * This is helpful for testing firewall rules, DoS handling, or client behavior in time-critical environments. * Step-1: Download the C source code for rapid-fire SNTP requests. :download:`Download C source code ` * Step-2: Compile the source code. .. code-block:: shell test:~$ gcc sntp_rapid_fire.c -o sntp_rapid_fire * Step-3: Run the test against a reachable NTP server. .. code-block:: shell test:~$ ./sntp_rapid_fire 216.239.35.0 Request 1 sent Request 2 sent Request 3 sent Request 4 sent Request 5 sent Request 6 sent Request 7 sent Request 8 sent Request 9 sent Request 10 sent * Step-4: Observe server behavior: * Use Wireshark or tcpdump to verify if all packets were sent and whether responses were returned. * Useful for assessing tolerance to polling frequency. * Step-5: Capture the test using Wireshark. :download:`Download Wireshark capture ` **One-time Sync with ntpdate (SNTP Server Response Verification)** * To ensure that the SNTP server responds correctly to time synchronization requests from an NTP client, and client can successfully update its system time using the received data. * Step-1: Install and Configure NTP Server (on Machine A). .. code-block:: shell test1:~$ sudo apt update test1:~$ sudo apt install ntp # Edit the NTP configuration test1:~$ sudo nano /etc/ntp.conf # Add the following lines or update accordingly restrict 192.168.56.0 mask 255.255.255.0 nomodify notrap server 127.127.1.0 fudge 127.127.1.0 stratum 10 broadcast 192.168.56.255 # Comment out online pool servers if offline # pool 0.ubuntu.pool.ntp.org iburst # pool 1.ubuntu.pool.ntp.org iburst # Restart the NTP service test1:~$ sudo systemctl restart ntp test1:~$ sudo systemctl status ntp * Step-2: Verify NTP Listening on Port 123 (UDP) .. code-block:: shell test1:~$ ss -ulpn | grep :123 * Step-3: Allow NTP Traffic via UFW (if enabled) .. code-block:: shell test1:~$ sudo ufw status test1:~$ sudo ufw allow 123/udp * Step-4: Install Client Tools on Machine B .. code-block:: shell test2:~$ sudo apt update test2:~$ sudo apt install ntpdate sntp * Step-5: One-Time Time Sync Using ntpdate .. code-block:: shell test2:~$ sudo ntpdate -q 192.168.56.10 # Example Output: # server 192.168.56.10, stratum 10, offset -0.000123, delay 0.02567 * Expected Result: * The client should receive a valid time response from the server. * Output should indicate stratum and offset. * No errors like "no server suitable for synchronization found" should occur. * Step-6: Wireshark Capture :download:`Download wireshark capture ` **One-time Sync with sntp (SNTP Server Response Verification)** * To verify that the NTP server (Machine A) responds correctly to SNTP (Simple NTP) queries and that a client (Machine B) can synchronize its time using the `sntp` utility. * Step-1: Ensure SNTP is Installed on the Client (Machine B) .. code-block:: shell test2:~$ sudo apt update test2:~$ sudo apt install sntp * Step-2: Query the NTP Server Using SNTP .. code-block:: shell test2:~$ sntp 192.168.56.10 # Example Output: # 2025-08-04 13:15:07.123456 (+0000) +0.001234 +/- 0.005678 secs * Interpretation: * The client successfully queried the NTP server. * The output includes: - The current timestamp - Time offset (e.g., +0.001234) - Estimated error bounds (+/-) * Note: `sntp` by default **does not** set the system time; it only queries. * Step-4: Ensure Server is Listening (Run on Server - Machine A) .. code-block:: shell test1:~$ ss -ulpn | grep :123 * Expected Result: * The SNTP client should successfully contact the server and display the timestamp, offset, and delay. * No error messages such as “no server suitable for synchronization found”. * Step-5: Wireshark Capture :download:`Download wireshark capture ` **Time Sync Validation via ntpdate** * To verify the system time on the client machine before and after synchronization using `ntpdate`, and confirm time alignment with the NTP server. * Requirements: * Machine B (Client – test2) must have `ntpdate` installed. * Machine A (Server – test1) must be running and accessible on `192.168.56.10`. * `sudo` privileges available on the client. * Step-1: Check Current Time on Client (Before Sync) .. code-block:: shell test2:~$ date # Example Output: # Mon Aug 4 13:24:10 UTC 2025 * Note the time. You may observe it differs from the actual/current time if the system is out of sync. * Step-2: Synchronize Time with NTP Server .. code-block:: shell test2:~$ sudo ntpdate 192.168.56.10 # Example Output: # 4 Aug 13:25:10 ntpdate[1234]: adjust time server 192.168.56.10 offset -0.345678 sec * This indicates that the system clock was adjusted by the reported offset. * Step-3: Check Time Again on Client (After Sync) .. code-block:: shell test2:~$ date # Example Output: # Mon Aug 4 13:25:10 UTC 2025 * Compare this with the time noted in Step 1. It should now reflect the correct time based on the server's clock. * Step-4 (Optional): Check NTP Sync Status via timedatectl .. code-block:: shell test2:~$ timedatectl status * Example output might include: - `NTP enabled: no` (if only manual sync is used) - `System clock synchronized: yes` - Accurate `Local time` and `Universal time` * Step-5: Wireshark Capture :download:`Download wireshark capture ` **Time Sync with Deliberately Skewed System Clock** * To verify that `ntpdate` can successfully correct the system clock on the client when the clock is significantly incorrect. * Requirements: * Machine B (Client – test2) must have `ntpdate` installed. * Machine A (Server – test1) must be running NTP and accessible at `192.168.56.10`. * `sudo` access is required on the client machine. * Step-1: Manually Skew the System Clock on Client .. code-block:: shell test2:~$ sudo date -s "2020-01-01 12:00:00" test2:~$ date # Example Output: # Wed Jan 1 12:00:00 UTC 2020 * This sets the system clock far in the past. * Step-2: Synchronize Time with NTP Server .. code-block:: shell test2:~$ sudo ntpdate 192.168.56.10 # Example Output: # 4 Aug 13:32:15 ntpdate[5678]: adjust time server 192.168.56.10 offset +176490745.123456 sec * A large offset indicates a significant correction has been made. * Step-3: Confirm System Time is Corrected .. code-block:: shell test2:~$ date # Example Output: # Mon Aug 4 13:32:16 UTC 2025 * The time should now match the correct date/time from the NTP server. * Expected Result: * The system clock is reset from the incorrect manual value to the correct time. * No synchronization errors should appear in the output. * Step-4: Wireshark Capture :download:`Download wireshark capture ` **Verbose SNTP Query for Debugging** * To view detailed NTP response fields using `sntp` in debug mode. This is useful for troubleshooting and analyzing time synchronization behavior at the protocol level. * Requirements: * Machine B (Client – test2) must have `sntp` installed. * Machine A (Server – test1) must be running and accessible at `192.168.56.10`. * Step-1: Run SNTP in Debug Mode from Client .. code-block:: shell test2:~$ sntp -d 192.168.56.10 # Example Output: # sntp 4.2.8p15@1.3728-o (1) # 2025-08-04 13:40:00.123456 (+0000) +0.000123 +/- 0.001234 secs # server 192.168.56.10, port 123 # stratum 10, precision -23, leap 00, trust 000 # refid [127.127.1.0], delay 0.02567, dispersion 0.00345 # transmitted 2025-08-04 13:40:00.123456 # received 2025-08-04 13:40:00.125678 * Expected Output Details: * Server IP and port used * Stratum level of the server * Offset and estimated delay * Leap indicator * Reference ID * Dispersion and precision * Timestamps for transmit/receive events * This mode is especially useful for debugging synchronization issues, analyzing NTP behavior, or validating server response fields manually. * Step-2: Wireshark Capture :download:`Download wireshark capture ` **DNS Resolution Failure Handling** * To verify how `sntp` behaves when provided with an invalid or non-existent hostname, and confirm that proper DNS resolution errors are shown. * Requirements: * Machine B (Client – test2) must have `sntp` installed. * No specific NTP server is required, since the test targets DNS failure handling. * Step-1: Attempt to Query an Invalid Hostname .. code-block:: shell test2:~$ sntp thisdoesnotexist.local # Expected Output: # sntp: Name or service not known * Expected Result: * The command should fail with a clear DNS resolution error. * No query attempt is made to any server. * Helpful for testing fallback or error handling mechanisms in time sync scripts. * This test confirms graceful failure and diagnostic output in cases of unreachable or misconfigured DNS names. * Step-2: Wireshark Capture (Optional — likely empty of NTP packets) :download:`Download wireshark capture ` **Sync with Multiple NTP Servers (Fallback Behavior)** * To verify that `sntp` correctly handles multiple server inputs by skipping unreachable ones and falling back to the next available server. * Requirements: * Machine B (Client – test2) must have `sntp` installed. * Machine A (Server – test1) must be running NTP at `192.168.56.10`. * At least one unreachable IP (e.g., `192.168.99.99`) is included in the test. * Step-1: Run SNTP with Multiple Servers (First Invalid, Second Valid) .. code-block:: shell test2:~$ sudo sntp -s 192.168.99.99 192.168.56.10 # Example Output: # sntp: no response received from 192.168.99.99 # (then silently succeeds using 192.168.56.10) * Step-2: Check Time After Sync .. code-block:: shell test2:~$ date # Output should show correct current time synced from the valid server. * Expected Result: * `sntp` should attempt to contact `192.168.99.99` first. * Upon failure, it should continue to `192.168.56.10` and perform time sync. * No critical failure occurs; only a warning for the first server. * This test validates fallback behavior and fault tolerance when using multiple servers in SNTP. * Step-3: Wireshark Capture :download:`Download wireshark capture ` .. _SNTP_step19: .. tab-set:: .. tab-item:: SNTP Basic Setup on Ubuntu using IPv6 * Setup .. _SNTP_step6: .. tab-set:: .. tab-item:: SNTP Protocol Packet Details **Symmetric Active Packet** .. csv-table:: :file: ./SNTP/sntp_packet1_details.csv :widths: 10,20,30,10 :header-rows: 1 **Symmetric Passive Packet** .. csv-table:: :file: ./SNTP/sntp_packet2_details.csv :widths: 10,20,30,10 :header-rows: 1 **Client Packet** .. csv-table:: :file: ./SNTP/sntp_packet3_details.csv :widths: 10,20,30,10 :header-rows: 1 **Server Packet** .. csv-table:: :file: ./SNTP/sntp_packet4_details.csv :widths: 10,20,30,10 :header-rows: 1 **Broadcast Packet** .. csv-table:: :file: ./SNTP/sntp_packet5_details.csv :widths: 10,20,30,10 :header-rows: 1 **SNTP Control Message Packet** .. csv-table:: :file: ./SNTP/sntp_packet6_details.csv :widths: 10,20,30,10 :header-rows: 1 .. _SNTP_step7: .. tab-set:: .. tab-item:: SNTP Usecases .. csv-table:: :file: ./SNTP/sntp_usecases.csv :widths: 10,20,30 :header-rows: 1 .. _SNTP_step8: .. tab-set:: .. tab-item:: SNTP Basic Features .. csv-table:: :file: ./SNTP/sntp_features.csv :widths: 10,10,30 :header-rows: 1 .. _SNTP_step9: .. tab-set:: .. tab-item:: SNTP Feature : Simplicity **Simplicity - Testcases** .. csv-table:: :file: ./SNTP/sntp_feature1_test_cases.csv :widths: 10,10,30,20 :header-rows: 1 .. _SNTP_step10: .. tab-set:: .. tab-item:: SNTP Feature : Time Synchronization **Time Synchronization - Testcases** .. csv-table:: :file: ./SNTP/sntp_feature2_test_cases.csv :widths: 10,10,30,20 :header-rows: 1 .. _SNTP_step11: .. tab-set:: .. tab-item:: SNTP Feature : UDP-Based Communication **UDP-Based Communication - Testcases** .. csv-table:: :file: ./SNTP/sntp_feature3_test_cases.csv :widths: 10,10,30,20 :header-rows: 1 .. _SNTP_step12: .. tab-set:: .. tab-item:: SNTP Feature : Low Overhead **Low Overhead - Testcases** .. csv-table:: :file: ./SNTP/sntp_feature4_test_cases.csv :widths: 10,10,30,20 :header-rows: 1 .. _SNTP_step13: .. tab-set:: .. tab-item:: SNTP Feature : Compatibility with NTP servers **Compatibility with NTP servers - Testcases** .. csv-table:: :file: ./SNTP/sntp_feature5_test_cases.csv :widths: 10,10,30,20 :header-rows: 1 .. _SNTP_step14: .. tab-set:: .. tab-item:: SNTP Feature : Support for IPv4 and IPv6 **Support for IPv4 and IPv6 - Testcases** .. csv-table:: :file: ./SNTP/sntp_feature6_test_cases.csv :widths: 10,10,30,20 :header-rows: 1 .. _SNTP_step15: .. tab-set:: .. tab-item:: SNTP Feature : One-Way Communication **One-Way Communication - Testcases** .. csv-table:: :file: ./SNTP/sntp_feature7_test_cases.csv :widths: 10,10,30,20 :header-rows: 1 .. _SNTP_step16: .. tab-set:: .. tab-item:: SNTP Feature : Periodic Updates **Periodic Updates - Testcases** .. csv-table:: :file: ./SNTP/sntp_feature8_test_cases.csv :widths: 10,10,30,20 :header-rows: 1 .. _SNTP_step17: .. tab-set:: .. tab-item:: Reference links * Reference links