FTTR equipment stability test method and device, medium and equipment

Abstract

The invention discloses an FTTR equipment stability test method and device, a medium and equipment. The method comprises the following steps: constructing a virtual terminal simulation test environment; simulating a test environment based on the constructed virtual terminal, and dynamically generating a virtual terminal with a unique MAC address; carrying out automatic IP address binding on the virtual terminal with the unique MAC address based on a DHCP protocol; hijacking the flow of the virtual terminal which completes automatic IP address binding by forging a protocol message so as to simulate a real data transmission scene; and in a process of simulating a real data transmission scene, executing a multi-dimensional network performance test so as to realize the stability test of the FTTR equipment. According to the invention, low-cost and high-efficiency FTTR equipment stability evaluation can be realized.

Description

Technical Field

[0001] This application belongs to the technical field of communication network testing, and particularly relates to a method, device, medium, and equipment for testing the stability of FTTR devices. Background Art

[0002] The stability testing of existing FTTR devices mainly relies on the access of physical terminals (such as PCs and mobile phones), and there are the following specific defects: 1. High hardware cost: A large number of terminal devices need to be purchased, occupying space and being complex to maintain. 2. Low degree of automation: Manual deployment of terminal devices is required, and the efficiency of monitoring the status is low and prone to errors. 3. Limited scenario coverage: It is difficult to simulate high-concurrency and extreme network conditions (such as sudden disconnection and ARP spoofing attacks). 4. Lack of flexibility: Traditional testing tools (such as Spirent TestCenter) are costly and have limited scenario simulation. Summary of the Invention

[0003] Aiming at the deficiencies in the prior art, the main purpose of this application is to provide a method, device, medium, and equipment for testing the stability of FTTR devices. This application aims to achieve low-cost and high-efficiency stability evaluation of FTTR devices.

[0004] To achieve the above objectives, this application provides the following technical solutions:

[0005] A method for testing the stability of an FTTR device, the method includes: constructing a virtual terminal simulation test environment; based on the constructed virtual terminal simulation test environment, dynamically generating virtual terminals with unique MAC addresses; automatically binding IP addresses to the virtual terminals with unique MAC addresses based on the DHCP protocol; hijacking the traffic of the virtual terminals with unique MAC addresses that have completed automatic IP address binding by forging protocol packets to simulate a real data transmission scenario; during the process of simulating the real data transmission scenario, performing multi-dimensional network performance testing to achieve the stability testing of the FTTR device.

[0006] Optionally, the constructing of the virtual terminal simulation test environment includes: connecting the test machine and the FTTR device to the same local area network to capture the network interaction data between all virtual terminals and the FTTR device; installing a virtualization test framework and dependent libraries, and loading a dynamic parameter configuration file.

[0007] Optionally, based on the constructed virtual terminal simulation test environment, dynamically generating virtual terminals with unique MAC addresses includes: dynamically generating unique MAC addresses through a random algorithm; binding the dynamically generated unique MAC addresses to the network interfaces of the virtual terminals to obtain virtual terminals with unique MAC addresses.

[0008] Optionally, the automatic IP address binding for the virtual terminal with a unique MAC address based on the DHCP protocol includes: sending a broadcast request to the FTTR device to simulate the simultaneous search for available DHCP servers by multiple terminals; listening to the available DHCP servers found and extracting the assigned IP addresses, and completing the IP address binding through interaction confirmation.

[0009] Optionally, hijacking the traffic of the virtual terminal that has completed automatic IP address binding by forging protocol packets to simulate a real data transmission scenario includes: forging the ARP entry of the target server to force the FTTR device to forward HTTP traffic to the virtual terminal to simulate file upload and download operations; constructing a TCP handshake packet to establish a connection based on the assigned IP address, sending an HTTP request, and recording the response time.

[0010] Optionally, during the process of simulating a real data transmission scenario, performing multi-dimensional network performance testing to achieve the stability testing of the FTTR device includes: sending network probing requests to each virtual terminal, measuring and recording the round-trip delay, analyzing the delay fluctuation and distribution to evaluate the network stability and response speed; setting different proportions of terminals to perform download, upload, and idle operations, and simulating network congestion or jitter conditions to achieve the stability testing of the FTTR device.

[0011] This application also provides an FTTR device stability testing device, which includes: a construction unit for constructing a virtual terminal simulation test environment; a generation unit for dynamically generating virtual terminals with unique MAC addresses based on the constructed virtual terminal simulation test environment; a binding unit for automatically binding IP addresses to the virtual terminals with unique MAC addresses based on the DHCP protocol; a simulation unit for hijacking the traffic of the virtual terminals that have completed automatic IP address binding by forging protocol packets to simulate a real data transmission scenario; a testing unit for performing multi-dimensional network performance testing during the process of simulating a real data transmission scenario to achieve the stability testing of the FTTR device.

[0012] This application also provides an FTTR device stability testing system, and the testing system includes the testing device as described above.

[0013] This application also provides a storage medium, which includes instructions that, when running on a computer, cause the computer to execute the method described in any one of the preceding items.

[0014] This application also provides an electronic device, which includes: a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor executes the program to implement the method described in any one of the preceding items.

[0015] The present application can bring the following beneficial effects:

[0016] 1. By constructing a virtual terminal simulation test environment, the present application dynamically generates virtual terminals with unique MAC addresses and realizes automatic IP address binding in combination with the DHCP protocol, effectively simulating large-scale terminal access scenarios.

[0017] 2. The present application hijacks traffic using forged protocol packets to accurately reproduce complex network behaviors in real data transmission scenarios, and at the same time performs multi-dimensional network performance tests to comprehensively evaluate the stability, reliability, and anti-interference ability of the device under high load and complex conditions.

[0018] 3. The present application can significantly improve the test efficiency, support high-concurrency tests and real-time data analysis, and provide timely feedback for device optimization. At the same time, by reducing the dependence on physical terminals, the hardware cost, site occupancy, and maintenance cost are greatly reduced, realizing low-cost and high-efficiency stability evaluation of FTTR devices. Brief Description of the Drawings

[0019] Figure 1 is a schematic flowchart of a method for testing the stability of an FTTR device provided by an embodiment of the present application;

[0020] Figure 2 is a schematic structural diagram of a device for testing the stability of an FTTR device provided by another embodiment of the present application. Detailed Embodiments

[0021] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

[0022] It should be noted that all directional indications (such as up, down, left, right, front, back...) in the embodiments of the present application are only used to explain the relative positional relationship and movement conditions between components in a specific posture (as shown in the drawings). If the specific posture changes, the directional indications will also change accordingly.

[0023] In this application, unless otherwise clearly specified and defined, terms such as "connection" and "fixation" shall be understood in a broad sense. For example, "fixation" can be a fixed connection, a detachable connection, or integrated; it can be a mechanical connection or an electrical connection; it can be directly connected or indirectly connected through an intermediate medium, and it can be the communication inside two components or the interaction relationship between two components, unless otherwise clearly defined. For those of ordinary skill in the art, the specific meanings of the above terms in this application can be understood according to specific circumstances.

[0024] In addition, if there are descriptions involving "first", "second", etc. in the embodiments of this application, such descriptions of "first", "second", etc. are only for descriptive purposes and cannot be understood as indicating or implying their relative importance or implicitly indicating the quantity of the indicated technical features. Thus, the features defined with "first" and "second" can explicitly or implicitly include at least one such feature. In addition, the meaning of "and / or" appearing throughout the text includes three parallel scenarios. Taking "A and / or B" as an example, it includes scenario A, scenario B, or the scenario where both A and B are satisfied simultaneously. In addition, the technical solutions between various embodiments can be combined with each other, but it must be based on the ability of those of ordinary skill in the art to implement. When the combination of technical solutions is contradictory or cannot be implemented, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection required by this application.

[0025] Figure 1 is a schematic flow diagram of a method for testing the stability of an FTTR device provided by an exemplary embodiment of this application, as Figure 1 described, the testing method includes the following steps:

[0026] S100: Construct a virtual terminal simulation test environment;

[0027] S200: Based on the constructed virtual terminal simulation test environment, dynamically generate virtual terminals with unique MAC addresses;

[0028] S300: Automatically bind IP addresses to the virtual terminals with unique MAC addresses based on the DHCP protocol;

[0029] S400: Hijack the traffic of the virtual terminals that have completed automatic IP address binding by forging protocol packets to simulate a real data transmission scenario;

[0030] S500: During the process of simulating a real data transmission scenario, perform multi-dimensional network performance tests to achieve the stability test of the FTTR device.

[0031] In this embodiment, a virtual terminal simulation test environment is constructed, combined with virtual terminals that dynamically generate unique MAC addresses, to achieve a highly realistic simulation of large-scale terminal access scenarios; the automated IP allocation based on the DHCP protocol ensures the compatibility of virtual terminals with the real network environment; by forging protocol packets to hijack traffic, complex network behaviors in real data transmission (such as abnormal traffic, attack simulation, etc.) can be accurately simulated, while maintaining complete controllability over the test process; finally, in a controlled simulation environment, through continuous monitoring of multi-dimensional network performance metrics (such as latency, packet loss rate, throughput, etc.), the stability, reliability, and anti-interference ability of the FTTR device in high-load and complex scenarios can be comprehensively evaluated, providing a reproducible and quantifiable test basis for device optimization, thereby significantly improving the efficiency and reliability of FTTR device research and development and deployment.

[0032] In another exemplary embodiment, in step S100, the building of the virtual terminal simulation test environment includes the following steps:

[0033] S101: Set the network interface: Connect the test machine and the FTTR device to the same local area network, and set the network interface to promiscuous mode (for example, execute ip link set eth0 promisc on under Linux) to capture all network interaction data between virtual terminals and the FTTR device (such as DHCP requests, HTTP traffic, etc.);

[0034] In this step, the promiscuous mode is a special mode of the network interface. In this mode, the network card can capture all interaction data between virtual terminals and the FTTR device, including DHCP requests, HTTP traffic, etc., providing raw data for subsequent analysis of latency, throughput, and stability.

[0035] S102: Install the virtualization test framework and dependent libraries, and load the dynamic parameter configuration file (such as the number of virtual terminals, timeout time);

[0036] In this step, the virtualization test framework is used to simulate multi-user terminals, network devices, and traffic behaviors in a real network environment, supporting automated testing and complex scenario reproduction, such as Scapy, Python multi-threading / coroutines, Docker, etc. In this application, taking Scapy + Python multi-threading as an example, the following describes how to install the virtualization test framework:

[0037] # Install the Python virtual environment

[0038] sudo apt-get install python3-venv # Linux

[0039] python -m venv venv # Create a virtual environment

[0040] source venv / bin / activate # Activate the environment

[0041] # Install Scapy and other dependent libraries

[0042] pip install scapy==2.4.5 psutil requests

[0043] Furthermore, the present application exemplarily illustrates how to load a dynamic parameter configuration file through the following pseudocode:

[0044] 1. Configuration file format

[0045]

[0046] 2. Load the configuration file

[0047]

[0048]

[0049] In summary, connecting the test machine and the FTTR device to the same local area network is the physical basis for building a virtual terminal test environment. Through this operation, the test machine can capture all network interaction data between the virtual terminal and the FTTR device in real time, while ensuring that the virtual terminal and the FTTR device are in the same network domain to achieve direct communication. The construction of this network environment not only provides data visibility for subsequent tests, but also avoids external network interference through the isolation characteristics of the local area network, ensuring the controllability of the test scenario.

[0050] On this basis, installing the virtualization test framework and dependent libraries and loading the dynamic parameter configuration file become the core of the second stage of building the test environment. Through the dynamic parameter configuration file, the virtualization framework can quickly generate a large number of virtual terminals with unique MAC addresses and simulate the network behaviors of real terminals (such as DHCP requests, HTTP traffic, abnormal packets, etc.). At the same time, the network parameters defined in the configuration file (such as IP allocation policy, traffic pattern, load level) need to be fully compatible with the configuration of the local area network in step one (such as DHCP server settings, FTTR device parameters) to ensure that the virtual terminal can seamlessly access the network and interact with the FTTR device.

[0051] In another exemplary embodiment, in step S200, generating virtual terminals with unique MAC addresses based on the built virtual terminal simulation test environment includes the following steps:

[0052] S201: Dynamically generate a unique MAC address through a random algorithm to ensure that each address has no duplicate conflicts;

[0053] In this step, generating a unique MAC address through a random algorithm includes the following steps:

[0054] Step 1: Initialize the seed;

[0055] Generate an initial seed Seed_0, which consists of the following parts:

[0056] Timestamp: Obtain the nanosecond-precision value of the current time (e.g., 1630450000000000000) to ensure the uniqueness of the seeds generated at different times.

[0057] Random salt: Generate a 16-bit random number (e.g., 0xA3F1) to enhance the unpredictability of the seed.

[0058] Seed generation formula: Seed_0 = Hash(timestamp || random salt), where Hash() represents the hash function and || represents concatenation.

[0059] Step 2: Construct a hash chain;

[0060] Generate subsequent seeds iteratively through a hash function (such as SHA-256). The specific iteration rules are as follows:

[0061] Seed_{n + 1} = Hash(Seed_n || Counter)

[0062] where Counter is an incrementing counter (with an initial value of 0) to ensure that each generated seed is different.

[0063] In the above iteration process, the input of the hash function at each step is the concatenated value of the previous seed (Seed_n) and the counter (Counter), and the output result is the next seed (Seed_{n + 1}). The following is an exemplary illustration using the generation and iteration of the initial seed Seed_0:

[0064] 1. Initial seed generation:

[0065] Seed_0 = Hash(timestamp || random salt)

[0066] Input: Timestamp (16 bytes) + random salt (2 bytes).

[0067] Output: Seed_0 (hash result, such as a 32-byte SHA-256 digest).

[0068] 2. First iteration:

[0069] Seed_1 = Hash(Seed_0 || Counter = 0)

[0070] Input: Seed_0 + Counter = 0.

[0071] Output: Seed_1 (new seed).

[0072] 3. The nth iteration:

[0073] Seed_{n} = Hash(Seed_{n - 1} || Counter = k)

[0074] Input: Previous seed Seed_{n - 1} + current counter value k.

[0075] Output: Seed_{n} (new seed).

[0076] This application constructs a hash chain. By leveraging the irreversibility and avalanche effect of the one-way hash function, the initial seed (generated from a high-precision timestamp and a random salt) and an incrementing counter are iterated step by step to ensure that each generated seed is unique and unpredictable. This mechanism not only guarantees the efficient generation and global uniqueness of a large number of MAC addresses in a distributed environment but also prevents the reuse of historical seeds through the non-backtraceable feature of the hash chain. Combining the dynamic perturbation of the timestamp and the counter increment strategy effectively reduces the probability of address conflicts and supports high-concurrency generation scenarios, providing a safe, reliable, and scalable randomization basis for automated testing.

[0077] Step 3: Divide the MAC address into the following three segments (as shown in Table 1), and each segment is dynamically derived based on the current seed (Seed_n) to ensure global uniqueness:

[0078] Table 1

[0079]

[0080] Step 4: Assemble the MAC address, that is, combine the OUI segment, the dynamic segment, and the random segment into a complete MAC address. The specific example is as follows:

[0081]

[0082]

[0083] Hereinafter, this application exemplarily illustrates the above steps through the following pseudo-code:

[0084]

[0085] In summary, the above algorithm efficiently generates a globally unique MAC address through high-precision timestamps, hash chain iteration, and hierarchical randomization techniques. It uses nanosecond-level timestamps to ensure that the addresses generated at different times are not repeated, and a one-way hash chain to avoid seed repetition and prediction. Combining a segmentation strategy, it achieves efficient and reliable unique address allocation. Among them, the OUI segment (the first 3 bytes) uses a fixed virtual factory identifier or dynamically extracts the first 24 bits of the seed to ensure controllable device identification and avoid conflicts with real devices. The dynamic segment (the middle 2 bytes) performs an exclusive OR operation on the middle part of the seed and the lower 16 bits of the timestamp to break the deterministic pattern of the hash chain and enhance the spatio-temporal randomness of address generation. The random segment (the last byte) is perturbed through a modulo operation of the end of the seed and the counter to achieve fine-grained randomization. Through the collaborative effect of the three segments, this application not only ensures global uniqueness but also has anti-collision, high-concurrency generation, and scenario adaptation capabilities, providing a verifiable address allocation basis for virtual terminal testing.

[0086] S202: Bind the dynamically generated unique MAC address to the network interface of the virtual terminal, and a virtual terminal with a unique MAC address can be obtained.

[0087] In this step, this application creates an independent network environment for each virtual terminal through the network namespace isolation of the Linux kernel, and combines virtual Ethernet pairs and MACVLANs to achieve direct binding of dynamic MAC addresses. The specific steps are as follows:

[0088] Step 1: Create a network namespace, which can be achieved by executing the following code:

[0089] # Create a namespace

[0090] sudo ip netns add Terminal_NS_1 # Terminal_NS_${i} is the namespace name

[0091] Step 2: Build virtual network devices, which can be achieved by executing the following code:

[0092] sudo ip link add veth${i} type veth peer name veth_peer${i} # Create a veth pair, veth${i} is the host side, and veth_peer${i} is the container side

[0093] sudo ip link set veth_peer${i} netns Terminal_NS_${i} # Move the container-side interface to the namespace

[0094] Step 3: Dynamically inject the MAC address into the interface within the namespace, which can be achieved by executing the following code:

[0095] sudo ip netns exec Terminal_NS_${i}ip link set veth_peer${i}name eth0 address ${MAC} # Rename the interface and set the MAC address

[0096] sudo ip netns exec Terminal_NS_${i}ip link set eth0 up # Enable the interface

[0097] In summary, the network namespace created by the ip netns add command provides a completely isolated network environment for virtual terminals. Each namespace has an independent network protocol stack, including a routing table, firewall rules, and interface configuration, effectively avoiding network interference between different virtual terminals. This isolation allows multiple virtual terminals to be run on the same host, simulating the behavior of independent network devices. Constructing a veth pair virtual device simulates a real network cable connection. One end (e.g., veth0) remains in the host namespace, and the other end (e.g., veth_peer0) is moved to the namespace of the virtual terminal. This design enables communication between the host and the virtual terminal through this pair of virtual interfaces, as if they were directly connected by a physical network cable. The process of dynamically injecting the MAC address is completed in the namespace of the virtual terminal. By using the ip netns exec command to execute configuration commands within the namespace, the dynamically generated unique MAC address is bound to the virtual interface (e.g., eth0). This dynamic binding mechanism not only ensures the uniqueness of the MAC address but also provides great flexibility, allowing the MAC address to be changed or reallocated at any time according to requirements, without restarting the virtual terminal or the host system. The above steps achieve an efficient, scalable, and easy-to-manage dynamic MAC address binding solution by combining the isolation of network namespaces, the virtual network connection ability of veth pairs, and the flexibility of dynamic MAC addresses.

[0098] In another exemplary embodiment, in step S300, the automatic IP address binding of the virtual terminal with a unique MAC address based on the DHCP protocol includes the following steps:

[0099] S301: Send a broadcast request to the FTTR device to simulate the simultaneous search for available DHCP servers by multiple terminals, specifically including the following steps:

[0100] Step 1: Dynamically generate DHCP Discover messages using the Scapy library. Each message carries the unique MAC address of the virtual terminal (generated in step S201). Among them, the DHCP Discover message includes the following fields:

[0101] chaddr field: Fill in the MAC address of the virtual terminal (formatted as a byte sequence).

[0102] xid (transaction ID): Generate based on the virtual terminal index and nanosecond timestamp to ensure uniqueness.

[0103] Broadcast flag: Set to 1 to force the message to be sent in broadcast form.

[0104] The above steps can be implemented through the following code:

[0105]

[0106]

[0107] Step 2: Use a coroutine pool or a multithreaded pool to send the generated DHCP Discover messages concurrently. Among them, the initial sending rate is N requests per second (N is set according to the performance of the FTTR device). At the same time, monitor the server response rate in real time. If the response rate is lower than the threshold (such as 80%), trigger the dynamic rate adjustment mechanism, and use a stepped attenuation method (such as reducing by 20% for the first time and decreasing by 10% subsequently) to smoothly reduce the sending rate, while avoiding server overload and maintaining the continuity of the test.

[0108] Exemplarily, step 2 can be implemented through the following code:

[0109]

[0110]

[0111]

[0112] In the captured Offer message, parse out the necessary information, such as server_id (the IP address of the DHCP server) and yiaddr (the IP address provided to the client). This information will be used to construct the subsequent Request message. Exemplarily, the parsing of the Offer message can be implemented by executing the following code:

[0113]

[0114] Step 2: Based on the server_id (DHCP server identifier) and yiaddr in the DHCP Offer message, construct a Request message to confirm the IP address with the server. Specifically, the Request message can be constructed using the following code:

[0115]

[0116] Next, send the constructed Request message and wait for the server's final confirmation (ACK message) to complete the entire IP address binding process. Exemplarily, the Request message can be sent by executing the following code:

[0117]

[0118] In another exemplary embodiment, in step S400, hijacking the traffic of the virtual terminal that has completed automated IP address binding by forging protocol messages to simulate a real data transmission scenario includes the following steps:

[0119] S401: Forge the ARP entry of the target server to force the FTTR device to forward HTTP traffic to the virtual terminal to simulate file upload and download operations;

[0120] In this step, by forging the ARP (Address Resolution Protocol) entry, the FTTR device is made to think that the virtual terminal is the real target server, so that the HTTP traffic originally sent to the server is redirected to the virtual terminal. This process can be used to simulate real file upload and download scenarios and evaluate the response ability of network devices to abnormal situations.

[0121] The implementation details of the above process can be described as:

[0122] First, before performing ARP spoofing, it is necessary to determine the real IP address of the target server and its corresponding MAC address.

[0123] Secondly, use tools such as Scapy to construct ARP reply packets. The ARP reply packets contain: the real IP address of the target server and the MAC address of the virtual terminal as the source MAC address. Send these ARP reply packets to all devices within the local area network (including the FTTR device) to inform them that the MAC address of the target server is actually the MAC address of the virtual terminal.

[0124] Finally, by checking the ARP table on the FTTR device or other local area network devices, confirm whether the original entry about the target server has been successfully overwritten.

[0125] The above implementation process can be achieved through the code shown below:

[0126]

[0127] S402: Based on the assigned IP address, construct a TCP handshake packet to establish a connection, send an HTTP request, and record the response time.

[0128] In this step, use the IP address assigned to the virtual terminal to construct a TCP three-way handshake sequence, establish a TCP connection with the target server, and on this basis, send an HTTP request. By recording the time from sending the request to receiving the response, the network latency and server processing speed are evaluated.

[0129] The implementation details of the above process can be specifically described as follows:

[0130] First, according to the IP address and port number of the virtual terminal, construct a TCP SYN packet and initiate a connection request to the target server.

[0131] Second, set the Scapy listening mode and wait for the SYN-ACK response returned by the server. Once received, it indicates that the first step of the TCP three-way handshake has been completed.

[0132] Third, after receiving the SYN-ACK, send a TCP ACK packet to complete the three-way handshake and establish a complete TCP connection.

[0133] Finally, on the established TCP connection, construct and send an HTTP GET / POST request, and record the time interval from sending the HTTP request to receiving the complete HTTP response, so as to evaluate the network latency and service response speed.

[0134] The above implementation process can be achieved through the code shown below:

[0135]

[0136]

[0137]

[0138] In another exemplary embodiment, in step S500, during the process of simulating a real data transmission scenario, perform multi-dimensional network performance testing to achieve the stability testing of the FTTR device, including the following steps:

[0139] S501: Send a network probe request to each virtual terminal, measure and record the round-trip delay, analyze the delay fluctuation and distribution, so as to evaluate the network stability and response speed;

[0140] In this step, first, a probing protocol needs to be selected. For example, ICMP Echo (Ping) or TCP SYN can be used as the probing means. Among them, ICMP Echo is applicable to most network environments, while TCP SYN is more suitable when the firewall filters ICMP.

[0141] Secondly, according to the selected probing protocol type, use Scapy to construct the corresponding probing packets. For ICMP Echo, an ICMP Echo Request can be directly constructed; for TCP SYN, a TCP packet with the SYN flag needs to be constructed. The specific examples are as follows:

[0142]

[0143]

[0144] For all virtual terminal IP addresses, loop through and call the measure_rtt function to collect all RTT values. The specific examples are as follows:

[0145] virtual_ips = ["192.168.1.10", "192.168.1.11"] # Example virtual terminal IP list

[0146] rtts = [measure_rtt(ip) for ip in virtual_ips]

[0147] print(f"RTTs: {rtts}")

[0148] Use statistical methods to calculate metrics such as the average RTT and standard deviation, draw a delay distribution graph, and identify outliers. The specific examples are as follows:

[0149] import statistics # Import the statistical calculation module for calculating the mean and standard deviation

[0150] # Filter invalid data: Keep non-None values (i.e., successfully obtained RTT values)

[0151] valid_rtts = [rtt for rtt in rtts if rtt is not None]

[0152] # Note: None values usually indicate request timeouts or measurement failures and need to be excluded from the calculation

[0153] # Calculate the average (mean) of the valid RTTs

[0154] avg_rtt = statistics.mean(valid_rtts)

[0155] # Calculate the arithmetic mean using statistics.mean(), formula: sum(valid_rtts) / len(valid_rtts)

[0156] # Calculate the standard deviation of valid RTTs (sample standard deviation)

[0157] std_dev_rtt = statistics.stdev(valid_rtts)

[0158] # Use statistics.stdev() to calculate the sample standard deviation, applicable to sample data drawn from the population

[0159] # Formula: sqrt(sum((x - mean)^2) / (n - 1)), where n is the sample size

[0160] # Output result

[0161] print(f"Average RTT: {avg_rtt}, Standard Deviation: {std_dev_rtt}")

[0162] # RTT (Round - Trip Time) represents the round - trip time of a network request and is an important indicator of network performance

[0163] S502: Set different proportions of terminals to perform download, upload, and idle operations, and simulate network congestion or jitter conditions to achieve the stability test of the FTTR device.

[0164] In this step, first, different proportions of virtual terminals need to be set according to the test requirements to perform download, upload, or remain idle respectively. For example, 70% of the terminals can be set to perform file downloads, 20% to perform file uploads, and the remaining 10% to remain idle.

[0165] Secondly, randomly assign behaviors to each virtual terminal according to the above - mentioned proportions, which can be achieved through the following code:

[0166]

[0167]

[0168]

[0169] During the test, it is necessary to continuously monitor various performance indicators of the FTTR device, including throughput, connection success rate, error rate, etc., and determine the performance of the FTTR device under different load conditions by analyzing the data, so as to realize the stability test of the FTTR device.

[0170] Next, this application compares this solution with the existing stability test solution, and the specific comparison results are shown in Table 2 as follows:

[0171] Table 2

[0172]

[0173] As can be seen from Table 2, the test method described in this application is superior to the existing test method in all indicators.

[0174] In another exemplary embodiment, this application also provides a stability test device for an FTTR device, which is characterized in that, as shown in the figure, the device includes: a construction unit 100 for constructing a virtual terminal simulation test environment; a generation unit 200 for dynamically generating virtual terminals with unique MAC addresses based on the constructed virtual terminal simulation test environment; a binding unit 300 for automatically binding IP addresses to virtual terminals with unique MAC addresses based on the DHCP protocol; a simulation unit 400 for hijacking the traffic of virtual terminals that have completed automatic IP address binding by forging protocol messages to simulate real data transmission scenarios; a test unit 500 for performing multi-dimensional network performance tests during the process of simulating real data transmission scenarios to realize the stability test of the FTTR device.

[0175] In another exemplary embodiment, this application also provides a stability test system for an FTTR device, and the test system includes the test device described above.

[0176] In another exemplary embodiment, this application also provides a storage medium, which includes instructions that, when running on a computer, cause the computer to execute the method described in any of the previous items.

[0177] In another exemplary embodiment, this application also provides an electronic device, which includes: a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor implements the method described in any of the previous items when executing the program.

[0178] The above are only the preferred embodiments of this application, and do not limit the patent scope of this application accordingly. Any equivalent structure or equivalent process transformation made by using the content of the specification and drawings of this application, or directly or indirectly applied in other related technical fields, shall be equally included in the patent protection scope of this application.

Claims

1. A method for testing the stability of FTTR equipment, characterized in that: The method comprises: Build a virtual terminal simulation test environment; Based on the constructed virtual terminal simulation test environment, a virtual terminal with a unique MAC address is dynamically generated; Automatically bind IP addresses to virtual terminals with unique MAC addresses based on the DHCP protocol; By forging protocol messages, the traffic of the virtual terminal that has completed the automatic IP address binding is hijacked to simulate the real data transmission scenario; In the process of simulating real data transmission scenarios, multi-dimensional network performance tests are performed to achieve FTTR equipment stability tests.

2. The method according to claim 1, characterized in that: The virtual terminal simulation test environment is constructed, including: Connect the test machine and FTTR equipment to the same LAN to capture the network interaction data between all virtual terminals and FTTR equipment; Install the virtualization test framework and dependent libraries, and load the dynamic parameter configuration file.

3. The method according to claim 1, characterized in that: Based on the constructed virtual terminal simulation test environment, a virtual terminal with a unique MAC address is dynamically generated, including: Dynamically generate a unique MAC address through a random algorithm; The dynamically generated unique MAC address is bound to the network interface of the virtual terminal to obtain a virtual terminal with a unique MAC address.

4. The method according to claim 1, characterized in that: The method of automatically binding an IP address to a virtual terminal having a unique MAC address based on the DHCP protocol includes: Send broadcast requests to FTTR equipment, simulating multiple terminals while searching for available DHCP servers; The searched available DHCP servers are monitored and the allocated IP addresses are extracted, and the IP address binding is completed through interactive confirmation.

5. The method according to claim 1, characterized in that: The method of hijacking the traffic of the virtual terminal that has completed the automatic IP address binding by forging protocol messages to simulate the real data transmission scenario includes: Forge the ARP table entry of the target server and force the FTTR device to forward HTTP traffic to the virtual terminal to simulate file upload and download operations; Based on the assigned IP address, a TCP handshake message is constructed to establish a connection, an HTTP request is sent, and the response time is recorded.

6. The method according to claim 1, characterized in that: In the process of simulating real data transmission scenarios, multi-dimensional network performance tests are performed to implement FTTR equipment stability tests, including: Send network probe requests to each virtual terminal, measure and record round-trip delay, analyze delay fluctuation and distribution to evaluate network stability and response speed; Set different proportions of terminals to perform download, upload and idle operations, and simulate network congestion or jitter conditions to achieve FTTR equipment stability testing.

7. A FTTR equipment stability testing device, characterized in that: The device comprises: A construction unit, used for constructing a virtual terminal simulation test environment; A generating unit, used for dynamically generating a virtual terminal with a unique MAC address based on the constructed virtual terminal simulation test environment; A binding unit, used for automatically binding an IP address to a virtual terminal having a unique MAC address based on a DHCP protocol; The simulation unit is used to hijack the traffic of the virtual terminal that has completed the automatic IP address binding by forging protocol messages to simulate the real data transmission scenario; The test unit is used to perform multi-dimensional network performance tests in the process of simulating real data transmission scenarios to achieve FTTR equipment stability tests.

8. A FTTR equipment stability test system, characterized in that: The testing system comprises the testing device according to claim 7.

9. A storage medium, characterized in that: The method comprises instructions, which, when executed on a computer, enable the computer to execute the method according to any one of claims 1 to 6.

10. An electronic device, characterized in that: The electronic device comprises: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the program, the method according to any one of claims 1 to 6 is implemented.

Images