A method, device, medium and equipment for testing stability of FTTR equipment

Abstract

This application discloses a method, apparatus, medium, and device for testing the stability of FTTR equipment. The method includes: constructing a virtual terminal simulation test environment; dynamically generating a virtual terminal with a unique MAC address based on the constructed virtual terminal simulation test environment; automatically binding the virtual terminal with the unique MAC address to an IP address based on the DHCP protocol; hijacking the traffic of the virtual terminal that has completed the automatic IP address binding by forging protocol messages to simulate a real data transmission scenario; and performing multi-dimensional network performance testing during the simulation of the real data transmission scenario to implement FTTR equipment stability testing. This application can achieve low-cost and high-efficiency FTTR equipment stability assessment.

Description

Technical Field

[0001] The present application belongs to the field of communication network testing technology, and specifically relates to a method, device, medium and equipment for testing the stability of FTTR equipment. Background Art

[0002] Stability testing of existing FTTR equipment primarily relies on access through physical terminals (such as PCs and mobile phones), which suffers from the following drawbacks: 1. High hardware costs: A large number of terminal devices must be purchased, occupying space and making maintenance complex. 2. Low automation: Terminal devices must be deployed manually, resulting in inefficient monitoring and prone to errors. 3. Limited scenario coverage: It is difficult to simulate high-concurrency and extreme network conditions (such as sudden disconnections and ARP spoofing attacks). 4. Lack of flexibility: Traditional testing tools (such as Spirent TestCenter) are expensive and have limited scenario simulation capabilities. Summary of the Invention

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

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

[0005] A method for testing the stability of FTTR equipment comprises: constructing a virtual terminal simulation test environment; dynamically generating a virtual terminal with a unique MAC address based on the constructed virtual terminal simulation test environment; automatically binding an IP address to the virtual terminal with the unique MAC address based on the DHCP protocol; hijacking the traffic of the virtual terminal that has completed the automatic IP address binding by forging protocol messages to simulate a real data transmission scenario; and performing a multi-dimensional network performance test during the simulation of the real data transmission scenario to implement the FTTR equipment stability test.

[0006] Optionally, the setting up of a virtual terminal simulation test environment includes: connecting the test machine and the FTTR device to the same local area network to capture 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, a virtual terminal with a unique MAC address is dynamically generated, including: dynamically generating a unique MAC address through a random algorithm; binding the dynamically generated unique MAC address to the network interface of the virtual terminal to obtain a virtual terminal with a unique MAC address.

[0008] Optionally, the automatic IP address binding of a virtual terminal with a unique MAC address based on the DHCP protocol includes: sending a broadcast request to the FTTR device, simulating multiple terminals while searching for available DHCP servers; monitoring the searched available DHCP servers and extracting the allocated IP addresses, and completing the IP address binding through interactive confirmation.

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

[0010] Optionally, in the process of simulating a real data transmission scenario, a multi-dimensional network performance test is performed to realize the FTTR equipment stability test, including: sending a network probe request to each virtual terminal, measuring and recording the round-trip delay, analyzing the delay fluctuation and distribution to evaluate the stability and response speed of the network; setting different proportions of terminals to perform download, upload and idle operations, and simulating network congestion or jitter conditions to realize the FTTR equipment stability test.

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

[0012] The present application also provides a FTTR equipment stability testing system, which includes the testing device as described above.

[0013] The present application also provides a storage medium comprising instructions, which, when executed on a computer, enables the computer to execute the method as described in any of the preceding items.

[0014] The present application also provides an electronic device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the method described in any of the preceding items when executing the program.

[0015] This application can bring the following beneficial effects:

[0016] 1. This application constructs a virtual terminal simulation test environment, dynamically generates a virtual terminal with a unique MAC address, and combines the DHCP protocol to realize automatic IP address binding, effectively simulating a large-scale terminal access scenario.

[0017] 2. This application uses forged protocol messages to hijack traffic, accurately reproduces the complex network behavior in real data transmission scenarios, and simultaneously performs multi-dimensional network performance tests to comprehensively evaluate the stability, reliability, and anti-interference capabilities of the equipment under high load and complex conditions.

[0018] 3. This application significantly improves test efficiency, supports high-concurrency testing and real-time data analysis, and provides timely feedback for equipment optimization. At the same time, by reducing reliance on physical terminals, it significantly reduces hardware costs, site occupation, and maintenance costs, enabling low-cost, high-efficiency FTTR equipment stability assessment. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 This is a flow chart of a method for testing the stability of an FTTR device provided in one embodiment of the present application;

[0020] Figure 2 This is a structural diagram of an FTTR equipment stability testing device provided in another embodiment of the present application. DETAILED DESCRIPTION

[0021] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

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

[0023] In this application, unless otherwise specified or limited, the terms "connection" and "fixation" should be understood in a broad sense. For example, "fixation" can mean fixed connection, detachable connection, or integration; mechanical connection or electrical connection; direct connection or indirect connection through an intermediate medium; internal communication between two elements or interaction between two elements, unless otherwise specified. For those skilled 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 the present application, the descriptions of "first", "second", etc. are only for descriptive purposes and cannot be understood as indicating or suggesting their relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined as "first" and "second" may explicitly or implicitly include at least one of such features. In addition, the meaning of "and / or" appearing throughout the text includes three parallel schemes. Taking "A and / or B" as an example, it includes scheme A, or scheme B, or a scheme in which A and B are satisfied at the same time. In addition, the technical solutions between the various embodiments can be combined with each other, but it must be based on the ability of ordinary technicians in this field to implement it. When the combination of technical solutions is mutually contradictory or cannot be implemented, it should be deemed 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 FIG. 1 is a flow chart of a method for testing the stability of an FTTR device provided by an exemplary embodiment of the present application. Figure 1 Said testing method comprises the following steps:

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

[0027] S200: dynamically generating a virtual terminal with a unique MAC address based on the constructed virtual terminal simulation test environment;

[0028] S300: Automatically bind an IP address to a virtual terminal with a unique MAC address based on the DHCP protocol;

[0029] S400: hijacks the traffic of a virtual terminal that has completed automatic IP address binding by forging protocol messages to simulate a real data transmission scenario;

[0030] S500: Perform multi-dimensional network performance tests while simulating real data transmission scenarios to achieve FTTR equipment stability testing.

[0031] This embodiment achieves high-fidelity simulation of large-scale terminal access scenarios by constructing a virtual terminal simulation test environment and combining it with a virtual terminal that dynamically generates a unique MAC address. Automated IP allocation based on the DHCP protocol ensures the compatibility of the virtual terminal with the real network environment. By forging protocol messages to hijack traffic, complex network behaviors in real data transmission (such as abnormal traffic, attack simulation, etc.) can be accurately simulated while maintaining full controllability of the test process. Ultimately, in a controlled simulation environment, through continuous monitoring of multi-dimensional network performance indicators (such as latency, packet loss rate, throughput, etc.), the stability, reliability, and anti-interference capability of FTTR equipment in high-load and complex scenarios can be comprehensively evaluated, providing a reproducible and quantifiable test basis for equipment optimization, thereby significantly improving the efficiency and reliability of FTTR equipment research and development and deployment.

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

[0033] S101: Set up 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 in Linux) to capture all network interaction data between the virtual terminal and the FTTR device (for example, including 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 the virtual terminal 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 and timeout period);

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

[0037] #Install Python virtual environment

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

[0039] python-mvenvvenv#Create a virtual environment

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

[0041] #Install Scapy and other dependent libraries

[0042] pip install scapy==2.4.5psutil requests

[0043] Furthermore, this application uses the following pseudo code to exemplify how to load a dynamic parameter configuration file:

[0044] 1. Configuration file format

[0045]

[0046] 2. Load the configuration file

[0047]

[0048]

[0049] In summary, connecting the test machine and FTTR equipment to the same LAN is the physical foundation for establishing a virtual terminal test environment. This allows the test machine to capture all network interaction data between the virtual terminal and the FTTR equipment in real time, while ensuring that the virtual terminal and the FTTR equipment are within the same network domain, enabling direct communication. This network environment not only provides data visibility for subsequent testing but also, through the isolation characteristics of the LAN, prevents external network interference and ensures controllable test scenarios.

[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 phase 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 behavior of real terminals (such as DHCP requests, HTTP traffic, abnormal messages, etc.). At the same time, the network parameters defined in the configuration file (such as IP allocation strategy, traffic pattern, load level) must be fully compatible with the LAN configuration in step one (such as DHCP server settings and FTTR equipment parameters) to ensure that the virtual terminals can seamlessly access the network and interact with the FTTR equipment.

[0051] In another exemplary embodiment, in step S200, dynamically generating a virtual terminal with a unique MAC address based on the constructed 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 duplication or conflict;

[0053] In this step, generating a unique MAC address by 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: Gets the nanosecond-precision value of the current time (for example, 16304500000000000000) to ensure that seeds generated at different times are unique.

[0057] Random salt: Generates a 16-bit random number (such as 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: Build a hash chain;

[0060] Subsequent seeds are iteratively generated using a hash function (such as SHA-256). The specific iteration rules are as follows:

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

[0062] Among them, Counter is an incremental counter (initial value is 0) to ensure that the seed generated each time is different.

[0063] In the above iterative process, the hash function input at each step is the concatenation of the previous seed (Seed_n) and the counter (Counter), and the output result is the next seed (Seed_{n+1}). The following example uses the generation and iteration of the initial seed Seed_0 as an example to illustrate:

[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. Iteration n:

[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 builds a hash chain and, by leveraging the irreversibility and avalanche effect of one-way hash functions, iterates the initial seed (generated by a high-precision timestamp and a random salt) and the incrementing counter step by step, ensuring that each generated seed is unique and unpredictable. This mechanism not only ensures the efficient generation and global uniqueness of large-scale MAC addresses in a distributed environment, but also prevents the reuse of historical seeds through the irreversible nature of the hash chain. Combined with dynamic perturbations of timestamps and counter incrementing strategies, it effectively reduces the probability of address conflicts, while supporting high-concurrency generation scenarios and providing a safe, reliable, and scalable randomization foundation for automated testing.

[0077] Step 3: Divide the MAC address into the following three segments (as shown in Table 1), each of which 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. This involves combining the OUI segment, dynamic segment, and random segment into a complete MAC address. The following example shows the complete MAC address:

[0081]

[0082]

[0083] The following pseudo code is used to illustrate the above steps:

[0084]

[0085] In summary, the above algorithm efficiently generates a globally unique MAC address through high-precision timestamps, hash chain iterations, and hierarchical randomization technology; nanosecond timestamps are used to ensure that addresses generated at different times are not repeated, and a one-way hash chain is used to avoid seed duplication and prediction. The segmentation strategy is combined to achieve efficient and reliable unique address allocation, wherein the OUI segment (the first 3 bytes) uses a fixed virtual manufacturer identifier or dynamically extracts the first 24 bits of the seed to ensure that the device identifier is controllable and avoid conflicts with real devices; the dynamic segment (the middle 2 bytes) XORs the middle part of the seed with the lower 16 bits of the timestamp to break the deterministic mode of the hash chain and enhance the temporal and spatial randomness of address generation; the random segment (the last byte) achieves fine-grained randomization by perturbing the end of the seed with the modulo operation of the counter. This application, through the synergistic effect of the three segments, while ensuring global uniqueness, has both anti-collision, high concurrent 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 to obtain a virtual terminal with a unique MAC address.

[0087] In this step, the present application uses the network namespace isolation of the Linux kernel to create an independent network environment for each virtual terminal, and combines virtual Ethernet pairs and MACVLAN to achieve direct binding of dynamic MAC addresses. Specifically, the following steps are included:

[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: Create a virtual network device, 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 vethpair, veth${i} is the host side, 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. This can be achieved by executing the following code:

[0095] sudo ip netns exec Terminal_NS_${i}ip link set veth_peer${i}nameeth0address${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 using the ip netns add command provides a completely isolated network environment for virtual terminals. Each namespace has its own independent network protocol stack, including routing tables, firewall rules, and interface configurations, effectively preventing network interference between different virtual terminals. This isolation allows multiple virtual terminals to simulate independent network device behavior even when running on the same host. Creating a veth pair virtual device simulates a real network cable connection. One end (such as veth0) remains in the host namespace, while the other end (such as veth_peer0) is moved to the virtual terminal's namespace. This design allows the host and virtual terminal to communicate through this virtual interface pair as if they were directly connected by a physical network cable. Dynamic MAC address injection is performed within the virtual terminal's namespace. The ipnetns exec command is used to execute configuration commands within the namespace, binding the dynamically generated unique MAC address to the virtual interface (such as eth0). This dynamic binding mechanism not only ensures MAC address uniqueness but also provides significant flexibility, allowing MAC addresses to be changed or reassigned as needed without restarting the virtual terminal or host system. The above steps combine the isolation of network namespaces, the virtual network connectivity of veth pairs, and the flexibility of dynamic MAC addresses to achieve an efficient, scalable, and easy-to-manage dynamic MAC address binding solution.

[0098] In another exemplary embodiment, in step S300, automatically binding an IP address to a virtual terminal having 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 multiple terminals while searching for available DHCP servers. Specifically, the following steps are included:

[0100] Step 1: Use the Scapy library to dynamically generate DHCP Discover messages. Each message carries the unique MAC address of the virtual terminal (generated in step S201). The DHCP Discover message includes the following fields:

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

[0102] xid (transaction ID): generated 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 achieved by the following code:

[0105]

[0106]

[0107] Step 2: Use a coroutine pool or a multi-thread pool to concurrently send the generated DHCP Discover messages. The initial sending rate is N requests per second (N is set according to the performance of the FTTR equipment). At the same time, the server response rate is monitored in real time. If the response rate falls below a threshold (such as 80%), the dynamic rate adjustment mechanism is triggered, and a step-by-step attenuation method (such as a 20% reduction for the first time and a 10% reduction thereafter) is used to smoothly reduce the sending rate, thereby avoiding server overload and maintaining test continuity.

[0108] For example, step 2 can be implemented by the following code:

[0109]

[0110]

[0111]

[0112] In the captured Offer message, necessary information is parsed, such as server_id (IP address of the DHCP server) and yiaddr (IP address provided to the client). This information will be used to construct the Request message later. For example, the Offer message can be parsed by executing the following code:

[0113]

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

[0115]

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

[0117]

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

[0119] S401: Forging the ARP table 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 an ARP (Address Resolution Protocol) entry, the FTTR equipment mistakenly believes the virtual terminal is the actual target server, redirecting HTTP traffic originally destined for the server to the virtual terminal. This process can be used to simulate real file upload and download scenarios and evaluate the network equipment's ability to respond to abnormal situations.

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

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

[0123] Next, use a tool like Scapy to construct an ARP reply containing the target server's real IP address and the virtual terminal's MAC address as the source MAC address. These ARP replies are then sent to all devices in the LAN (including FTTR equipment), informing them that the target server's MAC address is actually the virtual terminal's MAC address.

[0124] Finally, check the ARP table on the FTTR device or other LAN device to confirm whether the original entry about the target server has been successfully overwritten.

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

[0126]

[0127] S402: Based on the allocated IP address, a TCP handshake message is constructed to establish a connection, an HTTP request is sent, and the response time is recorded.

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

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

[0130] First, based on the IP address and port number of the virtual terminal, a TCP SYN message is constructed to initiate a connection request to the target server.

[0131] Next, set Scapy to listen mode and wait for the SYN-ACK response from the server. Once received, the first step of the TCP three-way handshake is complete.

[0132] Secondly, after receiving SYN-ACK, a TCP ACK message is sent to complete the three-way handshake and establish a complete TCP connection.

[0133] Finally, on top of the established TCP connection, an HTTP GET / POST request is constructed and sent, and the time interval from sending the HTTP request to receiving the complete HTTP response is recorded to evaluate network latency and service response speed.

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

[0135]

[0136]

[0137]

[0138] In another exemplary embodiment, in step S500, performing a multi-dimensional network performance test in a simulation of a real data transmission scenario to implement a FTTR equipment stability test includes 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, and evaluate the network stability and response speed;

[0140] In this step, first, you need to select a detection protocol. For example, you can use ICMP Echo (Ping) or TCP SYN as a detection method. Among them, ICMP Echo is suitable for most network environments, while TCP SYN is more suitable for the case where the firewall filters ICMP.

[0141] Secondly, according to the selected detection protocol type, use Scapy to construct the corresponding detection message. For ICMPEcho, you can directly construct ICMP Echo Request; for TCP SYN, you need to construct a TCP message with the SYN flag. The specific example is as follows:

[0142]

[0143]

[0144] For all virtual terminal IP addresses, call the measure_rtt function in a loop to collect all RTT values. The specific example is as follows:

[0145] virtual_ips = ["192.168.1.10","192.168.1.11"] # Sample 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 indicators such as average RTT and standard deviation, draw a latency distribution graph, and identify outliers. The specific example is as follows:

[0149] import statistics#Import statistical calculation module to calculate mean and standard deviation

[0150] #Filter invalid data: retain non-None values (that is, RTT values successfully obtained)

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

[0152] #Note: None value usually indicates request timeout or measurement failure and needs to be excluded from calculation

[0153] #Calculate the average value (mean) of effective RTT

[0154] avg_rtt=statistics.mean(valid_rtts)

[0155] #Use statistics.mean() to calculate the arithmetic mean, the formula is: sum(valid_rtts) / len(valid_rtts)

[0156] #Calculate the standard deviation of effective RTT (sample standard deviation)

[0157] std_dev_rtt=statistics.stdev(valid_rtts)

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

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

[0160] # Output results

[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: Setting different ratios of terminals to perform download, upload, and idle operations, and simulating network congestion or jitter conditions to implement FTTR equipment stability testing.

[0164] In this step, first, you need to set different proportions of virtual terminals to perform downloading, uploading, or remaining idle according to the test requirements. For example, you can set 70% of the terminals to perform file downloading, 20% to perform file uploading, and the remaining 10% to remain idle.

[0165] Secondly, randomly assigning actions to each virtual terminal according to the above ratio 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 equipment, including throughput, connection success rate, error rate, etc., and analyze the data to determine the performance of the FTTR equipment under different load conditions, thereby realizing the stability test of the FTTR equipment.

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

[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, the present application also provides an FTTR equipment stability testing device, characterized in that, as shown in the figure, the device includes: a construction unit 100, used to construct a virtual terminal simulation test environment; a generation unit 200, used to dynamically generate a virtual terminal with a unique MAC address based on the constructed virtual terminal simulation test environment; a binding unit 300, used to automatically bind the IP address of the virtual terminal with a unique MAC address based on the DHCP protocol; a simulation unit 400, used to hijack the traffic of the virtual terminal that has completed the automatic IP address binding by forging protocol messages to simulate a real data transmission scenario; a testing unit 500, used to perform multi-dimensional network performance testing in the process of simulating the real data transmission scenario to achieve FTTR equipment stability testing.

[0175] In another exemplary embodiment, the present application further provides a FTTR equipment stability testing system, which includes the testing device as described above.

[0176] In another exemplary embodiment, the present application further provides a storage medium comprising instructions, which, when executed on a computer, enables the computer to execute any of the methods described above.

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

[0178] The above are only preferred embodiments of the present application and do not limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present 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 virtual terminals that have completed automatic IP address binding is hijacked to simulate real data transmission scenarios; The method of hijacking the traffic of the virtual terminal that has completed the automatic IP address binding by forging protocol messages to simulate a real data transmission scenario includes: Forge the target server's ARP table entry, forcing 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; In the process of simulating real data transmission scenarios, multi-dimensional network performance tests are performed to achieve FTTR equipment stability testing.

2. The method according to claim 1, characterized in that The construction of the virtual terminal simulation test environment includes: Connect the test machine and FTTR equipment to the same local area network 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 devices, simulating multiple terminals while searching for available DHCP servers; The server monitors the available DHCP servers found and extracts the allocated IP address, completing the IP address binding through interactive confirmation.

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

6. 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, configured to dynamically generate a virtual terminal having 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 with a unique MAC address based on the 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 a real data transmission scenario; the forging protocol messages to hijack the traffic of the virtual terminal that has completed the automatic IP address binding to simulate a real data transmission scenario includes: Forge the target server's ARP table entry, forcing 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; 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 testing.

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

8. 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 5.

9. 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 5 is implemented.

Images