A multi-band WiFi connection fault grading recovery and semi-connection state elimination method

Abstract

This application relates to the field of wireless network connection failure recovery technology, specifically to a method for hierarchical recovery and half-connection state elimination of multi-band WiFi connection failures. It configures independent recovery parameters for different frequency bands; establishes a 7-state finite state machine model to drive the WiFi connection lifecycle with independent states; when the state transitions from the initial state to initiating a connection, if the connection command returns failure or times out, a guard condition decision tree is executed; if the associated state verifies that the current connection's SSID matches the target SSID, it enters post-connection verification, performs DHCP lease release and reacquires an IP address, and performs ping verification based on a success threshold to quantify connection quality and eliminate half-connection misjudgments; it records complete connection metric data to provide state trajectory auditing capabilities for fault diagnosis. The solution of this application can realize hierarchical recovery strategies, post-connection quality verification, frequency band differentiated parameter configuration, connection quality measurement, and state trajectory auditing.

Description

Technical Field

[0001] This application relates to the field of wireless network connection failure recovery technology, specifically to a method for graded recovery of multi-band WiFi connection failure and elimination of half-connection state. Background Technology

[0002] With the continuous evolution of WiFi technology, modern wireless routers and terminal devices widely support access capabilities across three frequency bands: 2.4GHz, 5GHz, and 6GHz. The 2.4GHz band offers wider coverage and stronger wall penetration, but its data transmission rate is relatively low and the band is congested. The 5GHz band has a smaller coverage area but a faster transmission rate. The 6GHz band (introduced with WiFi 6E) provides wider spectrum resources and higher transmission rates, meeting the needs of high-bandwidth applications such as 8K video and VR games.

[0003] Different frequency bands exhibit drastically different connection characteristics: the 2.4GHz band has a longer handshake time (WPA2-PSK requires both a 4-way handshake and a group key handshake), but its connection stability is relatively good; the 5GHz band has a faster handshake, but its channel switching latency is higher; the 6GHz band uses the WPA3-SAE (Simultaneous Authentication of Equals) authentication protocol, which is faster than WPA2-PSK's 4-way handshake, but the 6GHz band has a smaller coverage area, faster signal attenuation, and lower connection stability. Furthermore, the 6GHz band mandates the use of WPA3 or an enhanced open WLAN security protocol, further increasing the complexity of connection configuration.

[0004] In actual deployment and verification scenarios, multi-band WiFi devices need to establish reliable connections under different frequency bands, different encryption types (WPA2-PSK, WPA3-SAE, open network), and different key methods. Connection failures need to be automatically detected and graded for recovery, and connection quality needs to be quantitatively measured.

[0005] Currently, existing technologies for restoring WiFi connection failures mainly include the following categories: Simple retry loop method: This method adopts a linear loop structure of for i in range(N): try_connect(), executes the same connection command in each iteration, and waits for a fixed time interval before retrying after failure. This method is simple to implement, but has the following technical defects: (1) It cannot distinguish between software layer failure and hardware layer failure - the same retry strategy is used to deal with both connection command timeout or rejection (software layer) and inconsistent network card adapter status (hardware layer); (2) It lacks a post-connection verification stage, equating "WiFi is associated" with "network available", and cannot identify the half-connection state of "associated but DHCP (Dynamic Host Configuration Protocol) has not obtained an IP" or "IP has been obtained but the gateway is unreachable"; (3) It cannot apply differentiated timeout budgets and retry strategies to different frequency bands, and uses uniform parameters for all frequency bands; (4) It lacks state observability, and after the test fails, it only knows that "N attempts have failed", and it is impossible to trace which stage the failure occurred at.

[0006] Fixed timeout plus single verification method: This method executes a connection command once and waits for a fixed timeout period. After the timeout, it is judged as a failure. Its defects are: (1) Using the same timeout threshold for different frequency bands, resulting in the timeout being too short in the 2.4GHz slow handshake scenario and being mistakenly judged as a failure, and the timeout being too long in the 6GHz fast handshake scenario and wasting time; (2) There is no recovery mechanism. It terminates after a single failure and cannot automatically attempt software reconnection or hardware recovery; (3) There is no connection quality metric. It only records the binary success / failure result.

[0007] General WiFi connection state machine approach: Existing WiFi protocol stacks maintain finite state machines internally. For example, wpa_supplicant (the standard WiFi supplicant on the Linux platform) maintains a state machine (wpa_state: DISCONNECTED→SCANNING→ASSOCIATING→ASSOCIATED→4WAY_HANDSHAKE→GROUP_HANDSHAKE→COMPLETED), which tracks the 802.11 link layer protocol state (association, authentication, key handshake), but lacks post-connection quality verification capabilities (no ping verification, no DHCP refresh, no half-connection detection). NetworkManager adds an IP layer state on top of wpa_supplicant (NMConnectivityState: CONNECTED_LOCAL indicates that there is an IP address but the gateway is unreachable), but this state machine is only used for status reporting and does not include recovery path decision algorithms or hardware layer recovery capabilities—when CONNECTED_LOCAL is detected, it only reports the status rather than automatically taking recovery action; the Windows WLANAutoConfig service also maintains connection state tracking internally, but similarly lacks recovery policy decision functions. The common drawbacks of the existing state machines mentioned above are that they are all protocol layer state trackers rather than test orchestrators—they record "what state the WiFi is in" but do not make decisions on "what recovery strategy should be taken after the WiFi connection fails," nor do they record the complete audit trail of the recovery decision; existing state machines use uniform parameters for all frequency bands and cannot configure differentiated timeout and retry strategies for high-frequency bands such as 6GHz WPA3-SAE; they lack the ability to measure connection quality and diagnose faults, and cannot quantify connection timeout and ping success rate.

[0008] Based on the above analysis, existing technologies have the following core shortcomings in multi-band WiFi connection failure recovery: Lack of a tiered recovery strategy: Existing methods treat all connection failures the same, employing a single retry strategy (retransmitting the connection command). In real-world scenarios, WiFi connection failures can be categorized into two types: software-level failures (connection commands time out or are rejected, but the network adapter hardware is functioning normally; disconnecting and reconnecting resolves the issue) and hardware-level failures (inconsistent network adapter states, such as residual driver association states or DHCP lease caches; retransmitting the connection command fails to resolve the issue, requiring physical disabling and re-enabling of the network adapter to clear its hardware state). Existing methods cannot automatically identify the failure type and select the corresponding recovery path.

[0009] Lack of post-connection quality verification and half-connection detection: Existing methods equate "WiFi is associated" with "network available," lacking an independent verification phase after connection. In real-world scenarios, WiFi connections exist in four states: not associated (netsh shows disconnected), associated but no IP (DHCP not responding), associated with IP but gateway unreachable (ping failed), and fully available (ping gateway succeeded). Existing methods cannot distinguish between these four states, leading to the "associated but network unavailable" half-connection state being mistakenly judged as successful.

[0010] The lack of band-specific recovery parameters is a significant issue: different frequency bands have different connection characteristics, requiring different timeout budgets and recovery strategies. The 2.4GHz handshake sequence is longer, necessitating longer connection timeouts and more software retries; the 5GHz handshake is faster; and the 6GHz WPA3-SAE handshake is faster but less stable, requiring shorter timeouts and fewer software retries for faster upgrades to hardware recovery. Existing methods use a one-size-fits-all approach for all frequency bands, failing to adapt to band differences. Furthermore, the 6GHz band mandates WPA3-SAE encryption, but existing methods only perform value replacements during configuration propagation (e.g., changing encryption from WPA2-PSK to WPA3-SAE), retaining the key field and its original PSK password value. This leads to protocol layer authentication failure—because the WPA3-SAE SAE authentication protocol does not use pre-shared keys; the key is dynamically negotiated through the SAE protocol during connection establishment, rather than being pre-configured.

[0011] Lack of connection quality metrics: Existing methods only record binary success / failure results. Real-world testing requires quantifying connection quality, including: connection establishment time (number of seconds from initiating the connection to the first association), verification time (number of seconds from association to successful ping verification), ping success rate (the percentage of successful pings out of N attempts), software retries, and hardware resets. Existing methods cannot provide these metrics, making it impossible to automatically detect quality issues such as "successful connection but abnormally long latency" or "successful connection but unstable ping."

[0012] Lack of state trajectory auditing capabilities: Existing methods only know "failed after N attempts" after failure, but cannot trace which stage the failure occurred at (connection, association, DHCP, ping verification), nor can they obtain a complete record of the recovery decision process, resulting in low efficiency in fault diagnosis.

[0013] Lack of hardware-level recovery capabilities: When the network adapter experiences driver state inconsistencies (residual BSSID cache, invalid PMKSA (Pairwise Master Key Security Association) entries, or abnormal radio state), simple retry loops can only repeatedly send connection commands, while the NDIS (Network Driver Interface Specification) driver refuses to accept new connection commands when its internal state machine is inconsistent. Existing methods cannot clear the miniport driver stack state by physically disabling and re-enabling the network adapter, making such hardware-level failures unrecoverable.

[0014] In summary, existing technologies lack a comprehensive solution for multi-band WiFi connection failure recovery that can implement layered recovery strategies, post-connection quality verification, frequency band differentiated parameter configuration, connection quality measurement, and status trajectory auditing. Summary of the Invention

[0015] To provide a comprehensive solution for multi-band WiFi connection failure recovery that enables hierarchical recovery strategies, post-connection quality verification, frequency band differentiated parameter configuration, connection quality measurement, and status trajectory auditing, in a first aspect, embodiments of this application provide a method for hierarchical recovery and half-connection state elimination of multi-band WiFi connection failures, the method comprising: Configure independent recovery parameters for different WiFi frequency bands, so that different WiFi frequency bands have different timeout budgets, retry policies and encryption methods; A 7-state finite state machine model is established to drive the WiFi connection lifecycle with independent states. The states include the initial state / successful final state IDLE, WiFi connection initiation CONNECTING, WiFi association CONNECTED, connection verification VERIFYING, software layer retry RECONNECTING, hardware layer recovery ADAPTER_RESET, and final state FAILED. When the state transitions from the initial IDLE state to the initiation of WiFi connection CONNECTING state, if the connection command returns a failure or timeout, the guard condition decision tree is executed: if the software layer retry count is less than the maximum number of software retries, the software layer retry RECONNECTING state is entered; if the software layer retry count reaches the maximum number of software retries but the hardware layer reset count is less than the maximum number of hardware resets, the hardware layer recovery ADAPTER_RESET state is entered; if both the software layer retry count and the hardware layer reset count reach the maximum number of hardware resets, the final state FAILED state is entered. If the WiFi is already associated with the CONNECTED state, verify that the SSID of the current connection matches the target SSID, then perform a connection verification VERIFYING upon entry, execute a DHCP lease release and reacquire an IP address, and perform a ping verification based on a success threshold to quantify connection quality and eliminate false half-connection judgments. Record complete connection metric data to provide status trajectory auditing capabilities for fault diagnosis. The connection metric data includes entry / exit timestamps for each status, actual number of software layer retries, actual number of hardware layer resets, signal strength, number of DHCP refreshes, number of ping attempts, and number of successful pings.

[0016] In one possible implementation, the WiFi connection lifecycle includes the following steps: from the initial state IDLE to initiating WiFi connection CONNECTING, from initiating WiFi connection CONNECTING to WiFi already associated CONNECTED, from WiFi already associated CONNECTED to post-connection verification VERIFYING, and from post-connection verification VERIFYING to the successful final state IDLE; wherein, the final state FAILED is entered after all recovery paths corresponding to the guard condition decision tree are exhausted.

[0017] In one possible implementation, the step of entering the software-layer retry RECONNECTING when the software-layer retry count is less than the maximum number of software retries, and entering the hardware-layer recovery ADAPTER_RESET when the software-layer retry count reaches the maximum number of software retries but the hardware-layer reset count is less than the maximum number of hardware resets, includes: If the software layer retry count is less than the maximum number of software retries, enter the software layer retry RECONNECTING process, which involves disconnecting the current WiFi connection, waiting, and then re-initiating the WiFi connection CONNECTING process. If the software layer retry count exceeds the maximum number of software retry attempts, and the hardware layer reset count is less than the maximum number of hardware reset attempts, the hardware layer recovery ADAPTER_RESET will be initiated, which will physically disable the WiFi adapter, wait, physically enable the WiFi adapter, wait, and re-initiate the WiFi connection CONNECTING.

[0018] In one possible implementation, the method further includes: If the WiFi is associated with the CONNECTED state and the current SSID of the connection does not match the target SSID, jump to the guard condition decision tree; The process of releasing the DHCP lease and reacquiring an IP address, as well as ping verification based on a success threshold to quantify connection quality and eliminate false positives for half-open connections, includes: Get the gateway IP address corresponding to the current network adapter; Perform a two-step DHCP lease cycle to return the current IP lease and clear the old IP address on the adapter, and trigger a complete DHCP four-message exchange to obtain a new IP address from the current network segment; If the newly obtained IP address starts with 169.254, the DHCP acquisition is deemed to have failed and the process is transferred to the guard condition decision tree. Perform multiple pings and calculate the success rate. When the success rate is greater than the success threshold, enter the successful final state IDLE; otherwise, proceed to the guard condition decision tree.

[0019] In one possible implementation, the method includes: Single-band operation mode, dual-band operation mode and tri-band operation mode are constructed by mutual exclusion enumeration, so that invalid frequency band combinations cannot be represented at the type level. In multi-band operation mode, a frequency band identifier suffix is ​​appended to the SSID to generate an independent SSID for each frequency band, so that the WiFi can be matched and verified in the CONNECTED state. When the frequency band operation mode is three-band, a three-layer forced security upgrade is performed on the 6G frequency band. The three-layer forced security upgrade includes encrypting the 6G frequency band with WPA3, using the SAE key and removing the PSK key.

[0020] In one possible implementation, the method further includes: Based on the entry timestamps of "CONNECTING" (initiating WiFi connection) and "CONNECTED" (WiFi already associated) in the connection metric data, calculate the connection time from initiation to completion of association; Based on the entry and exit timestamps of the post-connection verification VERIFYING in the connection metric data, the time consumed in the verification phase is calculated. The ping success rate is calculated based on the number of ping attempts and the number of successful pings in the connection metric data. Based on the entry / exit timestamps of each state in the connection metric data, a complete state transition audit trail and fault diagnosis summary are formed. The summary includes the state path, the number of times the recovery strategy is used, the quality metric, and the final state.

[0021] In one possible implementation, the method further includes: By physically disabling the WiFi adapter, all pending I / O request packets in the miniport driver stack are cleared, forcing the miniport driver to reinitialize its internal state machine and invalidating the cached 802.11 associated state, which includes BSSID records and PMKSA cache entries. Physically enabling the WiFi adapter triggers a new initialization sequence for the miniport driver, starting from the 802.11 IDLE state, including scanning, authentication, association, and key handshake. The hardware-level recovery ADAPTER_RESET clears the BSSID cache, DHCP lease cache, and the internal state machine of the network adapter.

[0022] In one possible implementation, the connection timeout budget and maximum number of software retries in the recovery parameters decrease as the frequency band increases.

[0023] Secondly, embodiments of this application provide a multi-band WiFi connection fault graded recovery and half-connection state elimination device, the device comprising: The configuration module is used to configure independent recovery parameters for different WiFi frequency bands, so that different WiFi frequency bands have different timeout budgets, retry strategies and encryption methods; The state machine module is used to establish a 7-state finite state machine model to drive the WiFi connection lifecycle with independent states. The states include the initial state / successful final state IDLE, WiFi connection initiation CONNECTING, WiFi association CONNECTED, connection verification VERIFYING, software layer retry RECONNECTING, hardware layer recovery ADAPTER_RESET, and final state FAILED. The retry module is used to execute the guard condition decision tree when the state transitions from the initial state IDLE to the initiation of WiFi connection CONNECTING. If the connection command returns failure or timeout, the following steps are taken: If the software layer retry count is less than the maximum number of software retries, enter the software layer retry RECONNECTING phase; if the software layer retry count reaches the maximum number of software retries but the hardware layer reset count is less than the maximum number of hardware resets, enter the hardware layer recovery ADAPTER_RESET phase; if both the software layer retry count and the hardware layer reset count reach the maximum number of hardware resets, enter the final state FAILED. The verification module is used to verify that the SSID of the current connection matches the target SSID if the WiFi is already associated in the CONNECTED state, to verify the connection after entering the VERIFYING state, to perform DHCP lease release and reacquire IP address, and to perform ping verification based on success threshold to quantify connection quality and eliminate false half-connection judgments. The audit module is used to record complete connection metric data, providing status trajectory auditing capabilities for fault diagnosis. The connection metric data includes entry / exit timestamps for each state, actual number of software layer retries, actual number of hardware layer resets, signal strength, number of DHCP refreshes, number of ping attempts, and number of successful pings.

[0024] Thirdly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the above-described methods for graded recovery of multi-band WiFi connection faults and elimination of half-connection states.

[0025] This application provides a method for graded recovery and half-connection state elimination of multi-band WiFi connection failures. The method includes: configuring independent recovery parameters for different WiFi frequency bands, so that different WiFi frequency bands have differentiated timeout budgets, retry strategies, and encryption methods; establishing a 7-state finite state machine model to drive the WiFi connection lifecycle with independent states, including the initial state / successful final state IDLE, initiating WiFi connection CONNECTING, WiFi already associated CONNECTED, post-connection verification VERIFYING, software layer retry RECONNECTING, hardware layer recovery ADAPTER_RESET, and final state FAILED; when the state transitions from the initial state IDLE to initiating WiFi connection CONNECTING, if the connection command returns failure or timeout, the guard condition decision tree is executed: if the software layer retry count is less than the maximum number of software retries, the software layer retry REC is entered. In the ONNECTING state, if the software layer retry count reaches the maximum software retries but the hardware layer reset count is less than the maximum hardware reset count, it enters the hardware layer recovery ADAPTER_RESET state. If both the software layer retry count and the hardware layer reset count reach the maximum software retries and the maximum hardware reset count, it enters the final failure FAILED state. If the WiFi is already associated with the CONNECTED state, it verifies that the current connection's SSID matches the target SSID, enters the VERIFYING state for post-connection verification, performs DHCP lease release and reacquires an IP address, and performs ping verification based on a success threshold to quantify connection quality and eliminate half-connection false positives. Complete connection metric data is recorded to provide state trajectory auditing capabilities for fault diagnosis. The connection metric data includes the entry / exit timestamps for each state, the actual number of software layer retries, the actual number of hardware layer resets, signal strength, DHCP refresh counts, ping attempts, and ping successes. The solution in this application can realize a layered recovery strategy, post-connection quality verification, frequency band differentiated parameter configuration, connection quality measurement, and state trajectory auditing. Attached Figure Description

[0026] Figure 1 This is a schematic flowchart of a method for graded recovery of multi-band WiFi connection failure and elimination of half-connection state provided in an embodiment of this application; Figure 2 This is a schematic diagram of a multi-band WiFi connection fault graded recovery and half-connection state elimination device provided in an embodiment of this application. Detailed Implementation

[0027] Firstly, see [the following] Figure 1 This application provides a method for graded recovery of multi-band WiFi connection failures and elimination of half-connection states, the method comprising: S101 allows for the configuration of independent recovery parameters for different WiFi frequency bands.

[0028] This allows for different timeout budgets, retry strategies, and encryption methods for different WiFi frequency bands.

[0029] This application defines independent orchestration parameter configurations for each frequency band, rather than using a one-size-fits-all approach for all frequency bands. |Parameters|2.4GHz|5GHz|6GHz|Description|; |max_software_retries|3|3|2|Maximum number of retries for the software layer, less for faster upgrades to hardware recovery at 6GHz|; |max_adapter_resets|2|2|2|Maximum number of hardware layer resets|; |connect_timeout|60s|45s|30s|Connection command timed out, 2.4GHz handshake is slow and requires a longer timeout|; |verify_timeout|30s|20s|15s|Ping verification timeout, 6GHz verification is faster|; |adapter_reset_delay|5s|5s|5s|Wait time between disabling and enabling the network card|; |ping_count|3|3|3|ping verification count|; |ping_success_threshold|2|2|2|Ping success rate threshold (≥2 is considered a success, i.e., ping_success_ratio≥0.67)|; |cipher|AES|AES|SAE|Encryption method, 6GHz forced SAE|.

[0030] The differences in WiFi connection characteristics across different frequency bands mean that a one-size-fits-all approach is not applicable. 2.4GHz (bgnax): The handshake sequence is relatively long (WPA2-PSK 4-way handshake + group key handshake), with a connection timeout of 60 seconds. Stability is good; allow 3 software retries before considering hardware recovery. 5GHz (anacax): The handshake is faster, but channel switching latency is higher, with a connection timeout of 45 seconds. Stability is moderate; allow 3 software retries. 6GHz (anacax+SAE): WPA3-SAE's SAE (Simultaneous Authentication of Equals) handshake is faster than WPA2-PSK's 4-way handshake, with a connection timeout of 30 seconds. However, the 6GHz band has lower stability (smaller coverage area, faster signal attenuation). Unstable connections should not be repeatedly retried at the software level; instead, hardware recovery should be upgraded more quickly. Therefore, max_software_retries=2.

[0031] S102, establish a 7-state finite state machine model to drive the WiFi connection lifecycle with independent states.

[0032] The states include the initial state / successful final state IDLE, WiFi connection initiated CONNECTING, WiFi already associated CONNECTED, connection verification VERIFYING, software layer retry RECONNECTING, hardware layer recovery ADAPTER_RESET, and final state FAILED.

[0033] This application defines 7 formal states, which constitute a finite state machine for the WiFi connection lifecycle: |Status|Meaning|Innovation Point|; |IDLE|Initial state / Successful final state|Start and successful termination points of the state machine|; |CONNECTING|Initiate WiFi connection|Independent timeout budget (band specific), connection command executed only once|; |CONNECTED|WiFi is associated| does not mean "network available", it only means that netsh has confirmed the SSID association|; |VERIFYING|Post-connection verification|Core innovation: Independent state execution of DHCP refresh + ping verification to quantify connection quality|; |RECONNECTING| Software layer retry| Guard condition: software_retries < max_software_retries|; |ADAPTER_RESET|Hardware Layer Recovery|Core Innovation: Physically disable → enable network adapter, clear hardware state inconsistencies|; |FAILED|Final Failure|Termination state after all recovery paths have been exhausted|.

[0034] In one example, the WiFi connection lifecycle includes the following steps: from the initial state IDLE to initiating WiFi connection CONNECTING, from initiating WiFi connection CONNECTING to WiFi already associated CONNECTED, from WiFi already associated CONNECTED to post-connection verification VERIFYING, and from post-connection verification VERIFYING to the successful final state IDLE; wherein, the final state FAILED is entered after all recovery paths corresponding to the guard condition decision tree are exhausted.

[0035] The state machine is driven by a while loop, and in each iteration, the corresponding transition method is executed based on the current state: orchestrate(ssid,password,gateway): Reset metrics and counters _enter_state(IDLE) _enter_state(CONNECTING)# Enters the connection state for the first time. while state not in (IDLE, FAILED): if state == CONNECTING:→ _transition_CONNECTING(ssid, password) elif state == CONNECTED:→ _transition_CONNECTED(ssid) elif state == VERIFYING:→ _transition_VERIFYING(ssid, gateway) elif state == RECONNECTING:→ _transition_RECONNECTING(ssid,password) elif state == ADAPTER_RESET:→ _transition_ADAPTER_RESET() metrics.final_state = state _compute_derived_metrics() return state == IDLE# True = success, False = failure The loop termination condition is IDLE (success) or FAILED (all recovery paths exhausted), ensuring that the state machine does not loop indefinitely.

[0036] The CONNECTING state executes WiFi connection commands, with the following key characteristics: Instead of retrying in an inner loop, execute the join command only once (`max_retries=1`); Use a frequency band-specific `connect_timeout` as the timeout budget; Use the frequency band-specific `cipher` parameter (SAE for 6GHz, AES for other frequency bands); Connection successful → CONNECTED; Connection failed → `_decide_recovery_path()` selects the recovery path. Setting `skip_ping=True` disables ping verification during the connection phase (ping is performed in the VERIFYING standalone state).

[0037] The CONNECTED status verifies whether the currently connected SSID matches the target SSID: Call `check_wifi_connection_status()` to get the current connection information; Verify that `status.ssid == target ssid` (exact match, ignoring leading and trailing whitespace); SSID matching → Entering VERIFYING state; SSID mismatch → `_decide_recovery_path()` selects the recovery path.

[0038] This status prevents false positives such as "connected to a neighbor's WiFi instead of the target WiFi".

[0039] The recovery path decision algorithm `_decide_recovery_path()` is the core decision point of the layered recovery strategy. _decide_recovery_path(): if software_retry_count <max_software_retries: return RECONNECTING# Software-level recovery: Prioritize low-cost reconnection attempts elif adapter_reset_count <max_adapter_resets: return ADAPTER_RESET# Hardware layer recovery: Upgrade after software retries are exhausted else: return FAILED# All recovery paths exhausted: Terminate Decision priority: Software layer recovery (low cost) → Hardware layer recovery (high cost) → Termination. The key technical feature of this hierarchical decision-making is that each recovery level has independent operation objects and measurement records: software layer recovery only operates on WiFi connection commands (without touching the hardware state), while hardware layer recovery operates on the NDIS driver layer adapter physical state (clearing BSSID cache, PMKSA entries, and the driver's internal state machine). These are not repeated executions of the same operation but rather deterministic upgrade paths with different operation domains. The recovery path generated by guard conditions has complete state trajectory auditing capabilities, while stateless, intuitively driven sequential operations cannot provide this deterministic guarantee.

[0040] S103, when the state transitions from the initial state IDLE to initiate WiFi connection CONNECTING, if the connection command returns failure or timeout, execute the guard condition decision tree: if the software layer retry count is less than the maximum number of software retries, enter the software layer retry RECONNECTING; if the software layer retry count reaches the maximum number of software retries but the hardware layer reset count is less than the maximum number of hardware resets, enter the hardware layer recovery ADAPTER_RESET; if the software layer retry count reaches the maximum number of software retries and the hardware layer reset count reaches the maximum number of hardware resets, enter the final state FAILED.

[0041] If the software layer retry count is less than the maximum number of software retries, enter the software layer retry RECONNECTING process, which involves disconnecting the current WiFi connection, waiting, and then re-initiating the WiFi connection CONNECTING process. If the software layer retry count exceeds the maximum number of software retry attempts, and the hardware layer reset count is less than the maximum number of hardware reset attempts, the hardware layer recovery ADAPTER_RESET will be initiated, which will physically disable the WiFi adapter, wait, physically enable the WiFi adapter, wait, and re-initiate the WiFi connection CONNECTING.

[0042] In this application, RECONNECTING and ADAPTER_RESET represent a hierarchical recovery path rather than parallel retries. Traditional methods employ the same strategy (retrying the connection command) for all failures. This application divides the recovery path into two layers: Software layer recovery (RECONNECTING): execute `disconnect()` → wait → re-enter the CONNECTING state. This applies to the scenario where the network adapter hardware status is normal but the connection command is rejected; Hardware layer recovery (ADAPTER_RESET): execute `disable_adapter()` → wait → `enable_adapter()` → wait → re-enter the CONNECTING state. This applies to the scenario where the network adapter hardware status is abnormal (driver residual association, DHCP lease cache) and physical clearing is required.

[0043] The guard condition ensures that hardware recovery is only upgraded to after software retries are exhausted, instead of infinite retries at the software layer. This hierarchical decision generates a deterministic, auditable and reproducible recovery path—each recovery state has an independent operation object (RECONNECTING → WiFi connection command layer vs ADAPTER_RESET → NDIS driver layer hardware status), independent timing budget and independent measurement records. The guard condition ensures that the state trajectory accurately records when and why recovery is triggered, making the recovery decision process auditable and the results reproducible across test rounds, instead of relying on intuition-driven stateless sequence operations.

[0044] ADAPTER_RESET is not an "additional retry step" nested inside the RECONNECTING loop, but a formal state of the state machine, with independent state entry / exit records (`state_enter_times[ADAPTER_RESET]`, `state_exit_times[ADAPTER_RESET]`), independent counter (`adapter_reset_count`), independent guard condition (`adapter_reset_count<max_adapter_resets`), and independent timeout budget (`adapter_reset_delay`). This makes the hardware recovery path visible in the state trajectory instead of being hidden inside the loop.

[0045] In one example, the method further comprises: clearing all pending I / O request packets in the miniport driver stack by physically disabling the WiFi network adapter, forcing the miniport driver to reinitialize its internal state machine, and invalidating the cached 802.11 association state, wherein the 802.11 association state includes BSSID records and PMKSA cache entries; triggering, by physically enabling the WiFi network adapter, the miniport driver to start a brand-new initialization sequence from the 802.11 IDLE state, including scanning, authentication, association, and key handshake; The hardware-level recovery ADAPTER_RESET clears the BSSID cache, DHCP lease cache, and the internal state machine of the network adapter.

[0046] Reconnecting state performs software-level recovery: `software_retry_count += 1`, `total_software_retries += 1`; Execute `disconnect_from_wifi()` to disconnect the current WiFi connection; Wait 3 seconds (the network adapter needs time to clear its association status after disconnection); It directly enters the CONNECTING state (not restarting the orchestrate, but the next iteration of the state machine loop).

[0047] RECONNECTING→CONNECTING is an internal loop within the state machine, not a function recursion. The main loop of the state machine automatically executes the CONNECTING logic in the next iteration, without requiring manual triggering.

[0048] ADAPTER_RESET state performs hardware-level recovery: `adapter_reset_count += 1`, `total_adapter_resets += 1`; Execute `disable_adapter()` to physically disable the WiFi adapter; Wait for `adapter_reset_delay` seconds (default 5 seconds); Execute `enable_adapter()` to physically enable the WiFi adapter; Waiting for `adapter_reset_delay` seconds (the network card needs time to initialize after being enabled); Disabling / enabling failed → directly enters FAILED state (hardware reset failure means network adapter cannot be recovered); Success → Enter CONNECTING state.

[0049] ADAPTER_RESET is not "try connecting again," but rather a physical operation that modifies the hardware state of the WiFi adapter. This operation clears: Residual WiFi association state (BSSID cache of old SSID) in the driver. DHCP lease cache (old gateway IP); The network card adapter's internal state machine (radio on / off states are inconsistent).

[0050] Clearing the connection and restarting from the IDLE state is equivalent to "restarting the network adapter" rather than "resending the connection command".

[0051] Physically disabling / enabling the WiFi adapter involves interaction with the operating system's NDIS layer, rather than a simple toggle switch. `disable_adapter`: This command changes the adapter's running state from Up to Down via an NDIS request, clears all pending I / O request packets (IRPs) in the miniport driver stack, forces the miniport driver to reinitialize its internal state machine, and invalidates cached 802.11 association states (BSSID records, PMKSA cache entries). This operation does not send IEEE 802.11 Deauthentication management frames—unlike `netsh wlan disconnect` (which sends a Deauth frame to notify the AP to clear client association records). `Disable-NetAdapter` directly takes the adapter offline at the NDIS driver layer. The AP retains client association records while the client driver state is forcibly reset, creating an asymmetric state. When `Enable-NetAdapter` brings the adapter back online, the adapter starts a new scan and association sequence from the 802.11 IDLE state, rather than attempting to restore the previous association state. This asymmetric state handling is a unique technical effect of `ADAPTER_RESET` and cannot be achieved by sending a `disconnect` command (which notifies the AP to synchronously clear the state).

[0052] enable_adapter: Restores the adapter's running state to Up via an NDIS request, triggering the miniport driver to start a completely new initialization sequence from the 802.11 IDLE state: first perform a scan (Probe Request / Response), then perform authentication (Authentication Request / Response), then perform association (Association Request / Response), and finally complete the key handshake (4-Way Handshake or SAE Handshake), instead of restoring from the cached association state.

[0053] adapter_reset_delay wait time: The wait between two NDIS operations ensures that the driver stack completes the disassembly sequence before reinitialization begins, preventing the miniport driver from being forcibly initialized before disassembly is complete, which could lead to inconsistent internal states.

[0054] S104. If the WiFi is already associated with the CONNECTED status, verify that the SSID of the current connection matches the target SSID. After entering, perform VERIFYING connection verification, release the DHCP lease and reacquire the IP address, and perform ping verification based on the success threshold to quantify the connection quality and eliminate false half-connection judgments.

[0055] Verifying is an independent state, not a post-check of CONNECTED. In traditional methods, "verifying connection availability" is a continuation of the CONNECTED state (if connected, then ping). This application elevates verification to the independent state VERIFYING, with independent state entry / exit time records, enabling the calculation of `time_to_verify`; independent metric collection (`ping_attempts`, `ping_successes`, `ping_success_ratio`); and independent recovery path decision (verification failure → `decide_recovery_path`). This ensures that a half-connected state that is "connected but verification failed" can be correctly detected and handled, rather than being misjudged as a successful connection.

[0056] If the WiFi is associated with the CONNECTED state and the current SSID of the connection does not match the target SSID, jump to the guard condition decision tree; The process of releasing the DHCP lease and reacquiring an IP address, as well as ping verification based on a success threshold to quantify connection quality and eliminate false positives for half-open connections, includes: Get the gateway IP address corresponding to the current network adapter; Perform a two-step DHCP lease cycle to return the current IP lease and clear the old IP address on the adapter, and trigger a complete DHCP four-message exchange to obtain a new IP address from the current network segment; If the newly obtained IP address starts with 169.254, the DHCP acquisition is deemed to have failed and the process is transferred to the guard condition decision tree. Perform multiple pings and calculate the success rate. When the success rate is greater than the success threshold, enter the successful final state IDLE; otherwise, proceed to the guard condition decision tree.

[0057] Connection verification is performed after the VERIFYING state is executed, including: Step 1: Obtain the gateway IP If the gateway parameter is specified, the specified value will be used; Otherwise, call `get_default_gateway()` to automatically obtain the default gateway IP of the current network adapter; Failed to retrieve path → `_decide_recovery_path()`.

[0058] Step 2: DHCP Refresh Calling `release_renew_ip()` executes a two-step DHCP lease cycle: Step 2a: DHCPRELEASE: Send a DHCPRELEASE message to the DHCP server to return the current IP lease and clear the old IP address on the adapter, preventing the half-open connection state of "already associated but holding an old session IP". Step 2b: DHCPDISCOVER→DHCPOFFER→DHCPREQUEST→DHCPACK: Triggers a complete DHCP four-message exchange to obtain a new IP address from the current network segment.

[0059] Record `dhcp_refresh_count += 1`; Resolves the issue of "Associated but IP has an old lease or 0.0.0.0"; APIPA check: If the DHCP server does not respond to the DHCPDISCOVER message, the adapter may automatically assign an APIPA (Automatic Private IP Addressing) address (in the 169.254.0.0 / 16 range). The VERIFYING state explicitly checks and rejects APIPA addresses as an indication of DHCP failure: if the obtained IP address begins with 169.254, the DHCP acquisition is considered a failure and the process is transferred to _decide_recovery_path(), rather than treating the APIPA address as a valid network address. This check prevents a half-open connection state—where the connection is associated but holds an APIPA IP and the gateway is unreachable—from being mistakenly considered successful.

[0060] Step 3: Ping verification Perform N pings (`ping_count` times, default 3 times); Each ping timeout lasts 5 seconds; Record `ping_attempts` and `ping_successes`; Calculate `ping_success_ratio = ping_successes / ping_attempts`; If `success_count ≥ ping_success_threshold` (default ≥ 2) → succeed, enter IDLE; Otherwise → `_decide_recovery_path()`.

[0061] Step 4: Skip_ping shortcut path If `skip_ping=True` is set in OrchestrationConfig, skip ping verification and return IDLE directly. `time_to_verify = 0.0`; Suitable for scenarios where only connection establishment needs to be verified, and network availability does not need to be verified.

[0062] A simple "ping after connection" check can detect half-connection states, but it cannot handle the entire lifecycle of a half-connection—detection and recovery must be integrated, not separated: If a ping fails due to an old DHCP lease (the adapter holds the IP address from the previous session), a simple ping check will only report "ping gateway failed," offering no recovery path. This application's VERIFYING performs a two-step lease cycle: DHCPRELEASE → DHCPDISCOVER → DHCPREQUEST → DHCPACK, proactively clearing old leases and acquiring new IPs, rather than simply detecting failures.

[0063] If ping partially fails (1 successful out of 3 attempts, 2 timeouts), a simple ping check will report a binary failure. VERIFYING's ping_success_threshold mechanism allows partial connectivity to pass (2 / 3 = 0.67 ≥ threshold), while triggering a recovery path upgrade when connectivity is truly poor (0 / 3 or 1 / 3)—precisely distinguishing between "infrequent packet loss is tolerable" and "persistent unreachability requiring recovery".

[0064] If both a legacy DHCP lease and an unreachable gateway exist simultaneously, there's no simple upgrade path—the problem is detected but cannot be resolved. This application routes VERIFYING failures to _decide_recovery_path(), upgrading from software retries to hardware resets—forming a closed loop between detection and recovery, rather than isolated steps.

[0065] S105 records complete connectivity metrics data, providing status trajectory auditing capabilities for fault diagnosis.

[0066] The connection metrics data include entry / exit timestamps for each state, actual number of software layer retries, actual number of hardware layer resets, signal strength, number of DHCP refreshes, number of ping attempts, and number of successful pings.

[0067] This application provides a method for graded recovery and half-connection state elimination of multi-band WiFi connection failures. The method includes: configuring independent recovery parameters for different WiFi frequency bands, so that different WiFi frequency bands have differentiated timeout budgets, retry strategies, and encryption methods; establishing a 7-state finite state machine model to drive the WiFi connection lifecycle with independent states, including the initial state / successful final state IDLE, initiating WiFi connection CONNECTING, WiFi already associated CONNECTED, post-connection verification VERIFYING, software layer retry RECONNECTING, hardware layer recovery ADAPTER_RESET, and final state FAILED; when the state transitions from the initial state IDLE to initiating WiFi connection CONNECTING, if the connection command returns failure or timeout, the guard condition decision tree is executed: if the software layer retry count is less than the maximum number of software retries, the software layer retry REC is entered. In the ONNECTING state, if the software layer retry count reaches the maximum software retries but the hardware layer reset count is less than the maximum hardware reset count, it enters the hardware layer recovery ADAPTER_RESET state. If both the software layer retry count and the hardware layer reset count reach the maximum software retries and the maximum hardware reset count, it enters the final failure FAILED state. If the WiFi is already associated with the CONNECTED state, it verifies that the current connection's SSID matches the target SSID, enters the VERIFYING state for post-connection verification, performs DHCP lease release and reacquires an IP address, and performs ping verification based on a success threshold to quantify connection quality and eliminate half-connection false positives. Complete connection metric data is recorded to provide state trajectory auditing capabilities for fault diagnosis. The connection metric data includes the entry / exit timestamps for each state, the actual number of software layer retries, the actual number of hardware layer resets, signal strength, DHCP refresh counts, ping attempts, and ping successes. The solution in this application can realize a layered recovery strategy, post-connection quality verification, frequency band differentiated parameter configuration, connection quality measurement, and state trajectory auditing.

[0068] In one example, the method further includes: Based on the entry timestamps of "CONNECTING" (initiating WiFi connection) and "CONNECTED" (WiFi already associated) in the connection metric data, calculate the connection time from initiation to completion of association; Based on the entry and exit timestamps of the post-connection verification VERIFYING in the connection metric data, the time consumed in the verification phase is calculated. The ping success rate is calculated based on the number of ping attempts and the number of successful pings in the connection metric data. Based on the entry / exit timestamps of each state in the connection metric data, a complete state transition audit trail and fault diagnosis summary are formed. The summary includes the state path, the number of times the recovery strategy is used, the quality metric, and the final state.

[0069] This application defines the ConnectionMetrics data structure to record complete state machine metric data: ConnectionMetrics: state_enter_times: Dict[ConnectionState, float] # Entry timestamp for each state state_exit_times: Dict[ConnectionState, float] # Exit timestamp for each state total_software_retries: int # Total number of software retries total_adapter_resets: int # Total number of hardware layer resets signal_strength_dbm: Optional[int] # Signal strength (dBm) dhcp_refresh_count: int#number of DHCP refreshes ping_attempts: int # number of ping attempts ping_successes: int # Number of successful ping attempts ping_success_ratio: Optional[float] # Ping success rate (success / attempt) final_state: ConnectionState # Final state time_to_connect: Optional[float] #IDLE→CONNECTED time (seconds) time_to_verify: Optional[float] #CONNECTED→VERIFYING Time (seconds) state_trace: List[Tuple[ConnectionState, float]] # Complete state transition trace Calculate derived metrics from the original state timestamp: `time_to_connect=`state_enter_times[CONNECTED]-state_enter_times[CONNECTING]`` represents the time elapsed from initiating a connection to the first association; `time_to_verify=`state_exit_times[VERIFYING]-state_enter_times[VERIFYING]`` represents the time spent in the verification phase; ping_success_ratio: `ping_successes / ping_attempts`, represents the success rate of ping authentication.

[0070] The difference between this application and the simple retry loop "try N times, success = True" is that this application supports connection quality measurement and fault diagnosis, rather than just binary success / failure judgment. This allows quality problems such as "connection successful but abnormal time consumption" or "connection successful but unstable ping" to be detected automatically.

[0071] Each state transition is recorded in the `state_trace` list, forming a complete state transition audit trail: Example trajectory (successfully retried by the software): IDLE(0.00)→CONNECTING(0.00)→RECONNECTING(15.30)→CONNECTING(18.30)→CONNECTED(23.50)→VERIFYING(23.55)→IDLE(28.80); Example trajectory (successfully restored after hardware recovery): IDLE(0.00)→CONNECTING(0.00)→RECONNECTING(15.30)→CONNECTING(18.30)→RECONNECTING(33.50)→CONNECTI NG(36.50)→ADAPTER_RESET(51.80)→CONNECTING(61.80)→CONNECTED(72.00)→VERIFYING(72.05)→IDLE(77.30); Example trajectory (ultimately failed): IDLE(0.00)→CONNECTING(0.00)→RECONNECTING(15.30)→CONNECTING(18.30)→RECONNECTING(33.50)→CONNECTING(3 6.50)→ADAPTER_RESET(51.80)→CONNECTING(61.80)→ADAPTER_RESET(76.00)→CONNECTING(86.00)→FAILED(106.00).

[0072] The number of times RECONNECTING and ADAPTER_RESET appear in the trajectory matches the counter, allowing auditing of the complete decision-making process for the recovery path.

[0073] State path: IDLE → CONNECTING → RECONNECTING → CONNECTING → ADAPTER_RESET → FAILED Software retry: 3, Network card reset: 2; Connection time: N / A, Authentication time: N / A; Ping: 0 / 0 (Success rate: N / A); Final state: FAILED.

[0074] The summary includes the state path, the number of times the recovery strategy was used, quality metrics, and the final state, allowing you to understand the cause of failure without having to look at the logs.

[0075] In one example, the method includes: Single-band operation mode, dual-band operation mode and tri-band operation mode are constructed by mutual exclusion enumeration, so that invalid frequency band combinations cannot be represented at the type level. In multi-band operation mode, a frequency band identifier suffix is ​​appended to the SSID to generate an independent SSID for each frequency band, so that the WiFi can be matched and verified in the CONNECTED state. When the frequency band operation mode is three-band, a three-layer forced security upgrade is performed on the 6G frequency band. The three-layer forced security upgrade includes encrypting the 6G frequency band with WPA3, using the SAE key and removing the PSK key.

[0076] This application introduces a configuration layer between the generation layer and the orchestration layer to handle the construction, propagation, and security upgrades of frequency band configurations. This layer includes three key technical features: The BandMode XOR mutex enumeration models the WiFi band operation mode as a BandMode enumeration, which contains three mutex enumeration values: |Enumerated Value|Meaning|Corresponding Frequency Band|; |SINGLE_BAND|Single band|Only 2.4GHz|; |DOUBLE_EN|Dual-band|2.4GHz+5GHz|; |TRIPLE_BAND|Tri-band|2.4GHz+5GHz+6GHz|.

[0077] DOUBLE_EN (dual-band enabled) and TRIPLE_BAND (triple-band enabled) are mutually exclusive operation modes. Enumeration modeling makes invalid combinations (DOUBLE_EN=True and TRIPLE_BAND=True simultaneously effective) unrepresentable at the type level, and non-runtime Boolean checks can be bypassed. This ensures that the state machine's ADAPTER_RESET recovery path will not trigger meaningless hardware reset loops due to illegal configuration combinations—if the configuration itself is illegal at the type level, then connection failures based on that configuration are not considered faults requiring recovery, but rather inputs that need to be rejected.

[0078] Enumeration modeling eliminates the possibility of illegal states at the language type system level. Any code that attempts to construct an illegal combination is rejected by the type checker at compile time, rather than being found to be wrong at runtime.

[0079] In multi-band operation mode, the SSID uses a band suffix propagation strategy instead of simple copying: |Frequency Band|SSID Generation Rules|Example|; |2.4GHz| Keep the base SSID unchanged |"Router_ABC"|; |5GHz|Additional band identifier suffix|"Router_ABC_5G|; |6GHz|Additional band identifier suffix|"Router_ABC_6G|; The SSIDs for 5G and 6G bands are not simply copies of the 2.4G band SSIDs, but are generated by appending a band identifier suffix. This makes each band's SSID uniquely identifiable, preventing devices from confusing signals from different BSSs under the same ESS; the SSID naming maintains a logical association (shared base name + band suffix), facilitating correlation analysis in test reports; the CONNECTED state SSID matching verification of the state machine can distinguish between SSIDs with the same name on different bands, preventing false positives such as "connected to a neighboring 5GHz AP instead of the target 6GHz AP".

[0080] When the frequency band operation mode is TRIPLE_BAND, the 6G frequency band performs a three-layer mandatory security upgrade: |Upgrade Layer|Upgrade Operation|Instructions|; |Layer 1: Encryption Type|encryption→WPA3-SAE|6GHz Forced WPA3 Encryption|; |Layer 2: Keying Method|cipher→SAE|6GHz uses SAE instead of AES|; |Layer 3: PSK Key Removal|key → "" (empty string)|WPA3-SAE uses SAE authentication instead of PSK password|.

[0081] Layer 3 PSK key removal is a semantic transformation rather than a simple value replacement. Traditional configuration propagation only replaces field values ​​(e.g., changing encryption from WPA2-PSK to WPA3-SAE), but retains the key field and its original value (PSK password string). This application, during WPA3-SAE upgrades, not only changes the encryption and key method values ​​but also deletes the key field (setting it to an empty string) because WPA3-SAE's SAE (Simultaneous Authentication of Equals) authentication protocol does not use pre-shared keys—keys are dynamically negotiated via the SAE protocol during connection establishment, rather than being pre-configured.

[0082] This semantic change directly affects the CONNECTING state: In the 6GHz band, the CONNECTING state uses the SAE key method to initiate the connection command and passes an empty string key parameter instead of the PSK password in the AES key method. If only the value is replaced without removing the key field, the CONNECTING state will pass the PSK password to the SAE authentication process, causing protocol layer authentication to fail.

[0083] Traditional methods employ the same strategy (retrying the connection command) for all failures, making it impossible to distinguish between software-level and hardware-level failures. This application automatically selects a recovery path based on guard conditions. Software layer failure (connection command timed out / rejected) → RECONNECTING (low-cost reconnection); Hardware layer failure (interconnect adapter state inconsistency) → ADAPTER_RESET (high-cost but more thorough hardware reset).

[0084] In actual testing, hardware-level recovery resolved the following scenarios that traditional methods could not recover from: residual old SSID association states in the driver, causing new connection commands to fail; DHCP lease caching, resulting in "associated but IP with old lease"; inconsistent radio on / off states of the network card adapter, causing connection commands to be rejected by the driver.

[0085] Traditional methods equate "associated" with "network available." This application performs DHCP refresh + ping verification through an independent VERIFYING state, accurately distinguishing between: not associated (netsh disconnected), associated but no IP (DHCP not responding), associated with IP but gateway unreachable (ping failed), and fully available (ping successful). This ensures that the half-connection state of "associated but network unavailable" is correctly detected as a failure, rather than being mistakenly judged as success.

[0086] Traditional methods only record binary results of "success / failure". This application supports connection quality measurement and fault diagnosis: connection time does not exceed 30 seconds (`time_to_connect<= 30.0`), and ping success rate is not less than 67% (`ping_success_ratio>=0.67`). This allows quality issues such as "successful connection but abnormal time" or "successful connection but unstable ping" to be automatically detected and reported.

[0087] A one-size-fits-all approach to parameters is not applicable to different frequency bands. This application configures independent timeout budgets (2.4GHz=60s, 5GHz=45s, 6GHz=30s), retry policies (2.4GHz / 5GHz=3 software retries, 6GHz=2 retries) and key methods (6GHz=SAE, others=AES) for each frequency band. This allows unstable 6GHz connections to be upgraded to hardware recovery more quickly, rather than wasting time on repeated retries at the software layer.

[0088] Traditional methods only show "failed after N attempts" after a failure. This application records the complete state transition path: the state sequence (e.g., "IDLE→CONNECTING→RECONNECTING→ADAPTER_RESET→FAILED"), the timestamp of each transition, the number of software retries and hardware resets, ping verification results, and success rate. This allows for immediate identification of the failure stage (connection / verification / recovery) after a test fails, without needing to review detailed logs.

[0089] A comprehensive comparison of this application with existing simple retry loop methods in multi-band WiFi connection failure recovery: (1) Elimination of Half-Connection Misjudgment: The simple retry loop equates "WiFi is associated" with "network available", and cannot identify the half-connection state of "associated but DHCP has not obtained an IP" or "IP has been obtained but the gateway is unreachable", leading to such misjudgment. This application performs DHCP two-step lease cycle + ping threshold verification + APIPA detection through independent VERIFYING state, accurately distinguishing the four connection states at the protocol layer and eliminating half-connection misjudgment.

[0090] (2) Hardware layer recovery capability: The simple retry loop uses the same strategy (retransmitting the connection command) for all failures. When the network card adapter has an inconsistent NDIS driver state (residual BSSID cache, invalid PMKSA entry, abnormal radio state), retransmitting the connection command cannot recover—the driver refuses to accept new connection commands when the internal state machine is inconsistent. This application performs a physical disable → enable operation of the NDIS layer through the ADAPTER_RESET state, clears the 802.11 associated state cache of the miniport driver stack, and re-initializes the adapter from the IDLE state, thus solving the hardware layer failure that cannot be recovered by software layer retries.

[0091] (3) Frequency Band Differentiation Recovery Efficiency: Simple retry loops use a uniform timeout and number of retries for all frequency bands, resulting in 6GHz unstable connections wasting time by repeatedly retries at the software layer. This application uses frequency band differentiation OrchestrationConfig (6GHz max_software_retries=2, faster upgrade to ADAPTER_RESET) to enable 6GHz unstable connections to enter hardware recovery faster after software retries are exhausted, reducing the total recovery time. The finite state machine model in this application has a deterministic maximum execution time (a computable upper bound). Regardless of the failure mode, the state machine will inevitably terminate (IDLE or FAILED) within the computable maximum time budget, whereas simple retry loops may run indefinitely or have unpredictable timeout behavior, ensuring that the test will not run indefinitely.

[0092] (4) Test failure traceability: After a simple retry loop fails, all that is known is "all failed after N attempts". This application records the complete state transition path, timestamp, number of times the recovery strategy was used, and ping verification results, so that after a test fails, the stage at which the failure occurred (connection / verification / recovery) can be located immediately without having to look at detailed logs.

[0093] (5) Connection quality quantification: Simple retry loop only records binary success / failure. This application supports connection quality measurement and fault diagnosis of connection time (time_to_connect) and ping success rate (ping_success_ratio), which can detect quality degradation problems such as "connection successful but time is abnormal" or "connection successful but ping is unstable".

[0094] To verify the technical effectiveness of this application, under the same test environment (router model UR35, firmware version 35.3.0.13, test PC Windows 10, Intel WiFi adapter), multi-band WiFi connection tests were performed using both the simple retry loop method and the method of this application. The comparison results are as follows: |Test Scenario|Metrics|Simple Retry Loop|This Application Method|Improvement|; |2.4GHz WPA2-PSK Normal Connection|Connection Success Rate|78% (39 / 50)|96% (48 / 50)|+18%|; |2.4GHz WPA2-PSK driver residual association|Recovery success rate|0% (0 / 20)|85% (17 / 20)|+85%|; |5GHz WPA2-PSK Normal Connection|Connection Success Rate|82% (41 / 50)|94% (47 / 50)|+12%|; |6GHz WPA3-SAE Normal Connection|Connection Success Rate|65% (33 / 50)|88% (44 / 50)|+23%|; |6GHz WPA3-SAE Unstable Signal|Average Recovery Time|N / A (No Recovery)|18.5s|With Recovery Capability|; | Semi-connection false positive rate | False positives indicating associated but unusable connections | 12% (6 / 50) | 0% (0 / 50) | Completely eliminated |; |Connection quality quantification|Ping success rate record|None|Yes (0.67-1.0)|New capability|; | Fault traceability | Failure cause location | Know all failures | Status trajectory location | New capabilities |

[0095] (1) The hardware layer recovery of ADAPTER_RESET solves the driver remnant related scenario - simple retry has a 0% recovery rate in this scenario, while this application has an 85% recovery rate. This is because simple retry only resends the connection command, and the NDIS driver refuses to accept new connection commands when the internal state is inconsistent; ADAPTER_RESET clears the miniport driver state by physically disabling → enabling, so that the adapter is completely initialized from 802.11 IDLE.

[0096] (2) Complete elimination of half-connection false positives - simple retry will misjudge the connection as successful even if it has been associated but failed to obtain an IP address via DHCP (12% false positive rate). This application passed the DHCP refresh in VERIFYING state + APIPA detection + ping threshold verification, and 0 half-connection false positives in 50 tests.

[0097] (3) 6GHz Unstable Connection Recovery Efficiency - Simple Retry: Using the same retry parameters for all frequency bands, the 6GHz unstable connection wastes time by repeatedly retrying at the software layer. This application uses a frequency band differentiation parameter of max_software_retries=2 to enable the 6GHz to upgrade to ADAPTER_RESET faster, with an average recovery time of 18.5 seconds.

[0098] Example 1: Successful connection scenario of 2.4GHz WPA2-PSK AES.

[0099] Taking a WiFi connection using WPA2-PSK encryption with AES key in the 2.4GHz band as an example, the complete execution flow of the state machine is explained.

[0100] Arrangement configuration: OrchestrationConfig: band="2.4G",connect_timeout=60,verify_timeout=30 max_software_retries=3,max_adapter_resets=2 cipher="AES",ping_count=3,ping_success_threshold=2 State machine execution trajectory: Step 1:_enter_state(IDLE,timestamp=0.00) Step 2:_enter_state(CONNECTING,timestamp=0.00) wlan_ops.connect(ssid="Router_ABC",password="12345678", timeout=60,cipher="AES") → Returns True (Connection successful) Step 3:_exit_state(CONNECTING,timestamp=22.50) _enter_state(CONNECTED,timestamp=22.50) check_wifi_connection_status() → ssid="Router_ABC" (matches) Step 4:_exit_state(CONNECTED,timestamp=22.55) _enter_state(VERIFYING,timestamp=22.55) get_default_gateway()→"192.168.1.1" release_renew_ip() → Obtain IP address via DHCP ping #1:192.168.1.1 → Success

[0101] Ping #2:192.168.1.1 → Success

[0102] Ping #3:192.168.1.1 → Success

[0103] ping_success_ratio=3 / 3=1.0≥0.67

[0104] Step 5:_exit_state(VERIFYING,timestamp=28.80) State == IDLE → Loop terminates ConnectionMetrics: time_to_connect=22.50s(IDLE→CONNECTED) time_to_verify=6.25s(CONNECTED→VERIFYING) ping_success_ratio=1.0 total_software_retries=0 total_adapter_resets=0 final_state=IDLE Connection quality measurement and fault diagnosis: time_to_connect=22.50s≤30.0s

[0105] ping_success_ratio=1.0≥0.67

[0106] →Test passed Example 2: 6GHz WPA3-SAE connection failure → software retry → hardware recovery → success scenario Taking a 6GHz band WPA3-SAE encrypted WiFi connection as an example, this illustrates the complete execution process of upgrading to hardware recovery after the software layer retries are exhausted.

[0107] Arrangement configuration: OrchestrationConfig: band="6G", connect_timeout=30, verify_timeout=15 max_software_retries=2, max_adapter_resets=2 cipher="SAE", ping_count=3, ping_success_threshold=2 State machine execution trajectory: Step 1: _enter_state(IDLE, timestamp=0.00) Step 2: _enter_state(CONNECTING, timestamp=0.00) wlan_ops.connect(ssid="Router_ABC_6G",password="", timeout=30,cipher="SAE") → Returns False (Weak 6GHz signal, first connection failed) Step 3: _decide_recovery_path(): software_retry_count=0 <max_software_retries=2→ RECONNECTING _enter_state(RECONNECTING, timestamp=30.00) disconnect_from_wifi() → Wait 3 seconds Step 4: _enter_state(CONNECTING, timestamp=33.00) # Second attempt wlan_ops.connect(ssid="Router_ABC_6G", ...) → False (still failed) Step 5: _decide_recovery_path(): software_retry_count=1<2 → RECONNECTING _enter_state(RECONNECTING, timestamp=63.00) disconnect_from_wifi() → Wait 3 seconds Step 6: _enter_state(CONNECTING, timestamp=66.00) # Third attempt wlan_ops.connect(ssid="Router_ABC_6G", ...)→False (Software retry exhausted) Step 7: _decide_recovery_path(): software_retry_count=2 ≥ max_software_retries=2 → Check hardware recovery adapter_reset_count=0 <max_adapter_resets=2→ADAPTER_RESET _enter_state(ADAPTER_RESET, timestamp=96.00) disable_adapter("wifi1") → Wait 5 seconds enable_adapter("wifi1") → Wait 5 seconds Hardware reset successful Step 8: _enter_state(CONNECTING, timestamp=106.00) # Reconnect after hardware recovery wlan_ops.connect(ssid="Router_ABC_6G", ...) → True (Connection succeeds after network card status is cleared) Step 9: _enter_state(CONNECTED, timestamp=128.50) SSID matching confirmed Step 10: _enter_state(VERIFYING, timestamp=128.55) DHCP refresh + ping verification ping_success_ratio = 0.67 ≥ 0.67

[0108] Step 11: state == IDLE → Loop terminates ConnectionMetrics: time_to_connect = 128.50s (first CONNECTING → first CONNECTED) time_to_verify = 5.25s ping_success_ratio = 0.67 total_software_retries = 2 total_adapter_resets = 1 final_state = IDLE Connection quality measurement and fault diagnosis: time_to_connect = 128.50s>30.0s

[0109] → AssertionError("Connection time too long: 128.5s>30s") → Test failed (connection successful but quality not up to standard) Example 3: Invalid configuration combination (2.4GHz + WPA3-SAE) should result in connection failure. Arrangement configuration: OrchestrationConfig: band="2.4G", connect_timeout=60, cipher="SAE" max_software_retries=3, max_adapter_resets=2 State machine execution trajectory: Step 1: _enter_state(IDLE) Step 2: _enter_state(CONNECTING) wlan_ops.connect(ssid="Router_ABC", password="", cipher="SAE") → Returns False (SAE certification is not supported at 2.4GHz) Step 3: _decide_recovery_path() → RECONNECTING (Software retry) Step 4: _enter_state(CONNECTING) → False Step 5: _decide_recovery_path() → RECONNECTING Step 6: _enter_state(CONNECTING) → False Step 7: _decide_recovery_path() → RECONNECTING Step 8: _enter_state(CONNECTING) → False Step 9: _decide_recovery_path(): software_retry_count=3 ≥ max=3 adapter_reset_count=0<2 → ADAPTER_RESET Step 10: disable_adapter → enable_adapter Step 11: _enter_state(CONNECTING) → False (SAE is still not supported after hardware reset) Step 12: _decide_recovery_path(): software_retry_count=3 ≥ max=3 adapter_reset_count=1<2 → ADAPTER_RESET Step 13: disable_adapter → enable_adapter Step 14: _enter_state(CONNECTING) → False Step 15: _decide_recovery_path(): software_retry_count=3 ≥ max=3 adapter_reset_count=2 ≥ max=2 → FAILED ConnectionMetrics: final_state = FAILED total_software_retries = 3 total_adapter_resets = 2 orchestrator.orchestrate() returns False → as expected. → Test passed (invalid configuration should not connect successfully) The state machine orchestration and hierarchical recovery strategy of this application is not limited to Windows PowerShell NDIS operations, but also applies to Linux systems. In a Linux environment, the ADAPTER_RESET state can manipulate the physical state of the network adapter via `ip link set dev wlan0down / up`, and DHCP release-reacquisition can be performed via `dhclient -r / dhclient`. The state machine layer and orchestration layer do not require modification; only the implementations of `wlan_ops` and `network_utils` need to be replaced. For example, for testing Linux embedded devices, `WindowsOperations` is replaced with `LinuxOperations`, `Disable-NetAdapter` is replaced with `ip link set down`, and `Enable-NetAdapter` is replaced with `ip link set up`.

[0110] The ping verification in the VERIFYING state can be replaced with other connection quality metrics: ARP resolution verification (arping command verifies Layer 2 reachability), DNS resolution verification (nslookup verifies domain name resolution capability), and HTTP connectivity verification (curl verifies web service reachability). The ping_success_threshold mechanism also applies—if the number of successful verifications out of N attempts reaches a threshold, the connection passes. This extension allows the state machine to quantify connection quality across different dimensions.

[0111] The `OrchestrationConfig.get_default_configs()` function can be extended to support new frequency bands (such as the future 7GHz band). Simply add independent orchestration parameters for the new frequency band (connect_timeout, max_software_retries, cipher, etc.) to the configuration dictionary, and add the corresponding valid / invalid combinations of the frequency band to the YAML parameter matrix. The generator will then automatically generate differentiated test classes for the new frequency band without modifying the core logic of the state machine.

[0112] The 7-state machine and hierarchical recovery strategy of this invention can be generalized to other scenarios requiring a "connection → verification → recovery" lifecycle: VPN connection orchestration (CONNECTING = establishing a VPN tunnel, VERIFYING = pinging a remote gateway, ADAPTER_RESET = restarting the VPN service process), cellular network connection orchestration (CONNECTING = dialing, VERIFYING = pinging the carrier gateway, ADAPTER_RESET = resetting the modem), and MQTT connection orchestration (CONNECTING = establishing a TCP connection + MQTT handshake, VERIFYING = publish-subscribe verification, ADAPTER_RESET = resetting the TCP socket). The guard condition logic and metric recording mechanism of the recovery path decision algorithm can be directly reused.

[0113] The current ADAPTER_RESET generates an asymmetric client-AP state by not sending an 802.11 Deauth frame, and then re-establishes the connection from IDLE. The reverse implementation involves first sending a Deauth frame via netsh wlan disconnect (notifying the AP to clear the state), then performing the ADAPTER_RESET NDIS operation (clearing the client-driver state), so that both sides start from zero. This is suitable for "completely clean reconnection" scenarios.

[0114] Secondly, see Figure 2 This application provides a multi-band WiFi connection fault graded recovery and half-connection state elimination device, the device comprising: Configuration module 101 is used to configure independent recovery parameters for different WiFi frequency bands, so that different WiFi frequency bands have different timeout budgets, retry strategies and encryption methods; State machine module 102 is used to establish a 7-state finite state machine model to drive the WiFi connection lifecycle with independent states. The states include initial state / successful final state IDLE, WiFi connection initiation CONNECTING, WiFi associated CONNECTED, connection verification VERIFYING, software layer retry RECONNECTING, hardware layer recovery ADAPTER_RESET, and final state FAILED. The retry module 103 is used to execute the guard condition decision tree when the state transitions from the initial state IDLE to the initiation of WiFi connection CONNECTING, if the connection command returns failure or timeout: if the software layer retry count is less than the maximum number of software retries, enter the software layer retry RECONNECTING; if the software layer retry count reaches the maximum number of software retries but the hardware layer reset count is less than the maximum number of hardware resets, enter the hardware layer recovery ADAPTER_RESET; if the software layer retry count reaches the maximum number of software retries and the hardware layer reset count reaches the maximum number of hardware resets, enter the final state FAILED. The verification module 104 is used to verify that the SSID of the current connection matches the target SSID if the WiFi is already associated in the CONNECTED state, to verify the connection after entering the VERIFYING state, to perform DHCP lease release and reacquire IP address, and to perform ping verification based on the success threshold to quantify the connection quality and eliminate false half-connection judgments. The audit module 105 is used to record complete connection metric data, providing status trajectory auditing capabilities for fault diagnosis. The connection metric data includes the entry / exit timestamps of each state, the actual number of software layer retries, the actual number of hardware layer resets, signal strength, the number of DHCP refreshes, the number of ping attempts, and the number of successful pings.

[0115] In one possible implementation, the apparatus further includes a verification branch module for: If the WiFi is associated with the CONNECTED state and the current SSID of the connection does not match the target SSID, jump to the guard condition decision tree; The verification module is specifically used for: Get the gateway IP address corresponding to the current network adapter; Perform a two-step DHCP lease cycle to return the current IP lease and clear the old IP address on the adapter, and trigger a complete DHCP four-message exchange to obtain a new IP address from the current network segment; If the newly obtained IP address starts with 169.254, the DHCP acquisition is deemed to have failed and the process is transferred to the guard condition decision tree. Perform multiple pings and calculate the success rate. When the success rate is greater than the success threshold, enter the successful final state IDLE; otherwise, proceed to the guard condition decision tree.

[0116] In one possible implementation, the device further includes a second configuration module for: Single-band operation mode, dual-band operation mode and tri-band operation mode are constructed by mutual exclusion enumeration, so that invalid frequency band combinations cannot be represented at the type level. In multi-band operation mode, a frequency band identifier suffix is ​​appended to the SSID to generate an independent SSID for each frequency band, so that the WiFi can be matched and verified in the CONNECTED state. When the frequency band operation mode is three-band, a three-layer forced security upgrade is performed on the 6G frequency band. The three-layer forced security upgrade includes encrypting the 6G frequency band with WPA3, using the SAE key and removing the PSK key.

[0117] In one possible implementation, the apparatus further includes a derived metric module for: Based on the entry timestamps of "CONNECTING" (initiating WiFi connection) and "CONNECTED" (WiFi already associated) in the connection metric data, calculate the connection time from initiation to completion of association; Based on the entry and exit timestamps of the post-connection verification VERIFYING in the connection metric data, the time consumed in the verification phase is calculated. The ping success rate is calculated based on the number of ping attempts and the number of successful pings in the connection metric data. Based on the entry / exit timestamps of each state in the connection metric data, a complete state transition audit trail and fault diagnosis summary are formed. The summary includes the state path, the number of times the recovery strategy is used, the quality metric, and the final state.

[0118] In one possible implementation, the retry module further includes a physical recovery unit for: By physically disabling the WiFi adapter, all pending I / O request packets in the miniport driver stack are cleared, forcing the miniport driver to reinitialize its internal state machine and invalidating the cached 802.11 associated state, which includes BSSID records and PMKSA cache entries. Physically enabling the WiFi adapter triggers a new initialization sequence for the miniport driver, starting from the 802.11 IDLE state, including scanning, authentication, association, and key handshake. The hardware-level recovery ADAPTER_RESET clears the BSSID cache, DHCP lease cache, and the internal state machine of the network adapter.

[0119] Thirdly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the above-described methods for graded recovery of multi-band WiFi connection faults and elimination of half-connection states.

[0120] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)).

[0121] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0122] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device embodiments are described simply because they are similar to the method embodiments; relevant parts can be referred to the descriptions of the method embodiments.

[0123] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes to the above embodiments within the scope of the present invention without departing from the principles and spirit of the present invention.

Claims

1. A method for graded recovery of multi-band WiFi connection failures and elimination of half-connection states, characterized in that, The method includes: Configure independent recovery parameters for different WiFi frequency bands, so that different WiFi frequency bands have different timeout budgets, retry policies and encryption methods; A 7-state finite state machine model is established to drive the WiFi connection lifecycle with independent states. The states include the initial state / successful final state IDLE, WiFi connection initiation CONNECTING, WiFi association CONNECTED, connection verification VERIFYING, software layer retry RECONNECTING, hardware layer recovery ADAPTER_RESET, and final state FAILED. When the state transitions from the initial IDLE state to the initiation of WiFi connection CONNECTING state, if the connection command returns a failure or timeout, the guard condition decision tree is executed: if the software layer retry count is less than the maximum number of software retries, the software layer retry RECONNECTING state is entered; if the software layer retry count reaches the maximum number of software retries but the hardware layer reset count is less than the maximum number of hardware resets, the hardware layer recovery ADAPTER_RESET state is entered; if both the software layer retry count and the hardware layer reset count reach the maximum number of hardware resets, the final state FAILED state is entered. If the WiFi is already associated with the CONNECTED state, verify that the SSID of the current connection matches the target SSID, then perform a connection verification VERIFYING upon entry, execute a DHCP lease release and reacquire an IP address, and perform a ping verification based on a success threshold to quantify connection quality and eliminate false half-connection judgments. Record complete connection metric data to provide status trajectory auditing capabilities for fault diagnosis. The connection metric data includes entry / exit timestamps for each status, actual number of software layer retries, actual number of hardware layer resets, signal strength, number of DHCP refreshes, number of ping attempts, and number of successful pings.

2. The method according to claim 1, characterized in that, The WiFi connection lifecycle includes the following stages: from the initial state IDLE to initiating WiFi connection CONNECTING, from initiating WiFi connection CONNECTING to WiFi already associated CONNECTED, from WiFi already associated CONNECTED to subsequent connection verification VERIFYING, and from subsequent connection verification VERIFYING to the successful final state IDLE; wherein, after all recovery paths corresponding to the guard condition decision tree are exhausted, the final state FAILED is entered.

3. The method according to claim 1, characterized in that, The step of entering the software-layer retry RECONNECTING when the software-layer retry count is less than the maximum number of software retries, and entering the hardware-layer recovery ADAPTER_RESET when the software-layer retry count reaches the maximum number of software retries but the hardware-layer reset count is less than the maximum number of hardware resets, includes: If the software layer retry count is less than the maximum number of software retries, enter the software layer retry RECONNECTING process, which involves disconnecting the current WiFi connection, waiting, and then re-initiating the WiFi connection CONNECTING process. If the software layer retry count exceeds the maximum number of software retry attempts, and the hardware layer reset count is less than the maximum number of hardware reset attempts, the hardware layer recovery ADAPTER_RESET will be initiated, which will physically disable the WiFi adapter, wait, physically enable the WiFi adapter, wait, and re-initiate the WiFi connection CONNECTING.

4. The method according to claim 1, characterized in that, The method further includes: If the WiFi is associated with the CONNECTED state and the current SSID of the connection does not match the target SSID, jump to the guard condition decision tree; The process of releasing the DHCP lease and reacquiring an IP address, as well as ping verification based on a success threshold to quantify connection quality and eliminate false positives for half-open connections, includes: Get the gateway IP address corresponding to the current network adapter; Perform a two-step DHCP lease cycle to return the current IP lease and clear the old IP address on the adapter, and trigger a complete DHCP four-message exchange to obtain a new IP address from the current network segment; If the newly obtained IP address starts with 169.254, the DHCP acquisition is deemed to have failed and the process is transferred to the guard condition decision tree. Perform multiple pings and calculate the success rate. When the success rate is greater than the success threshold, enter the successful final state IDLE; otherwise, proceed to the guard condition decision tree.

5. The method according to claim 1, characterized in that, The method includes: Single-band operation mode, dual-band operation mode and tri-band operation mode are constructed by mutual exclusion enumeration, so that invalid frequency band combinations cannot be represented at the type level. In multi-band operation mode, a frequency band identifier suffix is ​​appended to the SSID to generate an independent SSID for each frequency band, so that the WiFi can be matched and verified in the CONNECTED state. When the frequency band operation mode is three-band, a three-layer forced security upgrade is performed on the 6G frequency band. The three-layer forced security upgrade includes encrypting the 6G frequency band with WPA3, using the SAE key and removing the PSK key.

6. The method according to claim 1, characterized in that, The method further includes: Based on the entry timestamps of "CONNECTING" (initiating WiFi connection) and "CONNECTED" (WiFi already associated) in the connection metric data, calculate the connection time from initiation to completion of association; Based on the entry and exit timestamps of the post-connection verification VERIFYING in the connection metric data, the time consumed in the verification phase is calculated. The ping success rate is calculated based on the number of ping attempts and the number of successful pings in the connection metric data. Based on the entry / exit timestamps of each state in the connection metric data, a complete state transition audit trail and fault diagnosis summary are formed. The summary includes the state path, the number of times the recovery strategy is used, the quality metric, and the final state.

7. The method according to claim 3, characterized in that, The method further includes: By physically disabling the WiFi adapter, all pending I / O request packets in the miniport driver stack are cleared, forcing the miniport driver to reinitialize its internal state machine and invalidating the cached 802.11 associated state, which includes BSSID records and PMKSA cache entries. Physically enabling the WiFi adapter triggers a new initialization sequence in the miniport driver, starting from the 802.11 IDLE state, including scanning, authentication, association, and key handshake. The hardware-level recovery ADAPTER_RESET clears the BSSID cache, DHCP lease cache, and the internal state machine of the network adapter.

8. The method according to claim 1, characterized in that, The connection timeout budget and maximum number of software retries in the recovery parameters decrease as the frequency band increases.

9. A multi-band WiFi connection fault graded recovery and half-connection state elimination device, characterized in that, The device includes: The configuration module is used to configure independent recovery parameters for different WiFi frequency bands, so that different WiFi frequency bands have different timeout budgets, retry policies and encryption methods; The state machine module is used to establish a 7-state finite state machine model to drive the WiFi connection lifecycle with independent states. The states include the initial state / successful final state IDLE, WiFi connection initiation CONNECTING, WiFi association CONNECTED, connection verification VERIFYING, software layer retry RECONNECTING, hardware layer recovery ADAPTER_RESET, and final state FAILED. The retry module is used to execute the guard condition decision tree when the state transitions from the initial state IDLE to the initiation of WiFi connection CONNECTING. If the connection command returns failure or timeout, the following steps are taken: If the software layer retry count is less than the maximum number of software retries, enter the software layer retry RECONNECTING phase; if the software layer retry count reaches the maximum number of software retries but the hardware layer reset count is less than the maximum number of hardware resets, enter the hardware layer recovery ADAPTER_RESET phase; if both the software layer retry count and the hardware layer reset count reach the maximum number of hardware resets, enter the final state FAILED. The verification module is used to verify that the SSID of the current connection matches the target SSID if the WiFi is already associated in the CONNECTED state, to verify the connection after entering the VERIFYING state, to perform DHCP lease release and reacquire IP address, and to perform ping verification based on success threshold to quantify connection quality and eliminate false half-connection judgments. The audit module is used to record complete connection metric data, providing status trajectory auditing capabilities for fault diagnosis. The connection metric data includes entry / exit timestamps for each state, actual number of software layer retries, actual number of hardware layer resets, signal strength, number of DHCP refreshes, number of ping attempts, and number of successful pings.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method described in any one of claims 1-8.

Images