Method for automatically skipping in network distribution of AP (Access Point)

Abstract

The invention discloses a method for automatically skipping in AP network distribution, which is applied to intelligent equipment and comprises the following steps of: enabling the intelligent equipment to enter an AP mode and starting DNS (Domain Name Server) service for intercepting a network request so as to receive an HTTP (Hyper Text Transport Protocol) authentication request of a mobile terminal connected to the AP mode; for an HTTP authentication request initiated by a mobile terminal, the following operations are executed: 1) under the condition that the mobile terminal concurrently sends a plurality of HTTP authentication requests, identifying and locking the HTTP authentication request received for the first time for processing; 2) responding to the HTTP authentication request received for the first time, and sending an HTTP redirection instruction to the mobile terminal, the HTTP redirection instruction being used for guiding a browser of the mobile terminal to automatically access a built-in distribution network page of the intelligent device; after an access request of the mobile terminal to the distribution network page is received, the intelligent device sends data of the distribution network page to the mobile terminal and stops DNS service so as to switch to a normal Web service mode, and it is ensured that subsequent data interaction is not intercepted again.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) technology, and in particular to a method for automatic switching during AP network configuration. Background Technology

[0002] In today's era of rapid development in the Internet of Things (IoT) and smart home devices, Wi-Fi network configuration, as the primary link between devices and users, has become a key factor influencing user experience. Wi-Fi technology, due to its wide coverage, high transmission speed, and low cost, is widely used in smart home devices such as smart speakers, cameras, and routers, as well as in industrial IoT and mobile devices. Based on current technological status, the number of Wi-Fi connected devices worldwide has exceeded ten billion, and is projected to grow further by 2026. However, the initial Wi-Fi configuration process for devices is often complex, involving manual configuration of network parameters by the user. This not only increases the operational threshold but can also lead to configuration failures, affecting device adoption rates.

[0003] Existing Wi-Fi configuration technologies mainly include various modes, such as web-based configuration, WeChat AirKiss configuration, Bluetooth configuration, sound wave configuration, and hardware interface settings. Among these, web-based configuration is widely used due to its advantages such as not requiring a dedicated app, good cross-platform compatibility, and relatively simple operation. According to market research data, web-based configuration dominates in smart devices, especially in scenarios where no additional software support is needed. However, traditional web-based configuration processes still have significant drawbacks, mainly in terms of cumbersome user operations and insufficient system compatibility.

[0004] Traditional web-based configuration processes typically require users to: Search for and connect to the access point (AP) created by your device in your phone's Wi-Fi settings; Manually open the browser; Enter the IP address specified by the device; Select your home Wi-Fi network on the webpage and enter the password to complete the configuration.

[0005] While this method is simple, it's prone to errors or being forgotten when entering IP addresses for non-technical users, such as the elderly or first-time IoT device users, leading to a high failure rate in network configuration. Combined with the current technological landscape, the diversity of mobile operating systems (such as iOS and Android) and version updates (such as the enhanced security mechanisms of Android 12+) further amplify these problems. Users expect a more seamless network configuration experience, and existing solutions fail to adequately adapt to these changes.

[0006] To improve user experience, some existing technologies attempt to utilize the network connectivity check mechanism of mobile operating systems, namely the Captive Portal mechanism. When a phone connects to a Wi-Fi network that cannot access the internet, the operating system automatically sends an HTTP request to a preset URL (such as http: / / captive.apple.com / ). The device can intercept this request and return to the configuration page, causing the page to pop up automatically. Theoretically, this mechanism can reduce manual operation, but in practical applications, it suffers from stability and compatibility issues. The main drawbacks include: 1) Cumbersome and error-prone user operation: Existing web-based network configuration solutions require users to manually enter IP addresses or handle compatibility issues, which is particularly prominent in today's diverse mobile phone ecosystem. For example, some low-end phones or certain operating system versions may not support automatic detection mechanisms, forcing users to rely on manual input, increasing the cognitive burden. The reason for this deficiency is that existing solutions lack user-friendly design and fail to fully utilize the operating system's built-in network detection functions, instead relying on static IP address configuration. This design stems from the early development stage of Wi-Fi network configuration technology, when mobile phone systems had low standardization, and developers focused more on simple implementation than user experience optimization.

[0007] 2) Instability and poor compatibility of automatic pop-up mechanism: Although the forced portal mechanism can achieve automatic redirection, the existing implementation scheme is often crude, resulting in interruption or failure of the network configuration process. Specifically, it manifests as: (1) DNS hijacking service is continuously running, causing internal HTTP requests (such as obtaining the Wi-Fi list) to be misjudged as new authentication requests after the network configuration page is loaded, resulting in loop redirection or data interaction failure; (2) Differences in mobile phone system behavior, such as some Android devices sending multiple authentication requests concurrently, causing the device side to be unable to effectively manage the session, resulting in repeated pop-up browser windows or redirection failure. There are two main reasons for the defects: First, there is a lack of fine-grained management of session state, and the device side has not implemented dynamic switching of communication mode, which stems from the developers' neglect of the behavior of the mobile phone operating system; Second, there is insufficient handling of concurrent requests, and the device side has not adopted a unique mechanism, resulting in resource competition, because the existing schemes are mostly based on the general forced portal framework and have not been optimized for the specific scenarios of IoT devices. In combination with the current technological status, the security enhancement of mobile phone operating systems (such as iOS 15+ and Android 13), such as stricter network permission control, has further aggravated these problems and increased compatibility challenges.

[0008] In summary, while existing Wi-Fi network configuration technologies have made progress, they still fail to address core pain points: operational complexity and insufficient system compatibility. These shortcomings not only reduce the success rate of network configuration but also limit the widespread adoption of IoT devices. Developing an automatic redirection method based on HTTP redirection and session management mechanisms to achieve a more stable and user-friendly network configuration process has become a crucial technical problem urgently needing to be solved in this field. Summary of the Invention

[0009] The purpose of this invention is to design an automatic switching method during AP network configuration, which solves the technical defects of existing technologies such as operational complexity and insufficient system compatibility, which lead to a reduced network configuration success rate and also limit the popularization of IoT devices.

[0010] This invention provides a method for automatic switching during AP network configuration, applicable to smart devices, comprising: The smart device is put into AP mode and DNS service for intercepting network requests is enabled to receive HTTP authentication requests from mobile terminals connected to AP mode. For the HTTP authentication request initiated by the mobile terminal, perform the following operations: 1) In the case of multiple concurrent HTTP authentication requests from the mobile terminal, identify and lock the first received HTTP authentication request for processing; 2) In response to the first received HTTP authentication request, send an HTTP redirection instruction to the mobile terminal, the HTTP redirection instruction being used to instruct the browser of the mobile terminal to automatically access the network configuration page built into the smart device; Upon receiving the mobile terminal's access request to the network configuration page, the smart device sends the data of the network configuration page to the mobile terminal and stops the DNS service to switch to the normal web service mode, ensuring that subsequent data interactions are not intercepted again.

[0011] In the above solution, users only need to select and connect to the device hotspot from the Wi-Fi list; the subsequent browser opening and page access processes are completed automatically. This eliminates the memory burden and operational obstacles for non-technical users, making the network configuration process as intuitive and simple as connecting to public Wi-Fi, significantly lowering the barrier to entry for the product. Through socket uniqueness processing, it effectively solves compatibility issues caused by differences in the behavior of different mobile phone systems, such as duplicate pop-ups and redirection failures due to concurrent authentication requests, making automatic redirection more stable on various mainstream mobile terminals. Through dynamic shutdown of the DNS service, it fundamentally solves the common problem of page malfunctions or process interruptions after redirection in existing automatic pop-up solutions, ensuring a smooth process from redirection to configuration submission. This application does not simply utilize a forced portal mechanism, but rather forms a robust end-to-end solution from triggering and redirection to configuration completion through the organic combination of HTTP redirection response, dynamic shutdown of the DNS service, and authentication socket uniqueness processing. This not only achieves automation but also ensures the stability and compatibility of the process.

[0012] Preferably, enabling the DNS service for intercepting network requests includes: When the smart device enters AP mode, the DNS service is immediately activated to intercept network requests from the mobile terminal, and the DNS service is ensured to be active before intercepting HTTP authentication requests in order to improve the efficiency of network request capture. Once the DNS service is enabled, it hijacks the mobile terminal's preset URL requests, ensuring that all HTTP authentication requests are processed internally by the smart device.

[0013] Preferably, receiving the HTTP authentication request from the mobile terminal already connected to the AP mode includes: The HTTP request data sent by the mobile terminal is parsed, and when a preset authentication feature character is detected in the request data, the HTTP request is confirmed to be an authentication request. The preset authentication feature characters include at least one of “GET / ” and “HTTP / 1.”.

[0014] Preferably, the process of identifying and locking the first received HTTP authentication request includes: Record the identifier of the first established authentication socket connection; When a subsequent authentication socket connection created by the mobile terminal is detected, the subsequent authentication socket connection is actively closed, and only the initially established authentication socket connection is kept for the network configuration process.

[0015] Preferably, the HTTP redirection instruction is an HTTP 302 status code response, and the header of the HTTP 302 status code response includes a Location field, the value of which is the access address of the network configuration page built into the smart device.

[0016] Preferably, the method further includes: Extract the HTTP protocol version information from the HTTP authentication request; Based on the HTTP protocol version information, an HTTP redirection instruction compatible with the mobile terminal is generated.

[0017] Preferably, sending the data of the network configuration page to the mobile terminal includes: All data content of the network configuration page is encapsulated in a single HTTP response message and sent at once to avoid loading failures caused by data packet transmission.

[0018] Preferably, in the normal Web service mode, the method further includes: In response to the WiFi list acquisition request initiated by the mobile terminal through the network configuration page, the system scans for nearby WiFi hotspots, encapsulates the scan results, and sends them to the mobile terminal. The system receives connection parameters for the target WiFi network submitted by the mobile terminal through the network configuration page. These connection parameters include the WiFi name and password.

[0019] Preferably, the method further includes: After receiving the connection parameters, a network configuration result page is sent to the mobile terminal; Control the smart device to exit AP mode and attempt to connect to the target WiFi network using the connection parameters.

[0020] Preferably, the method further includes: Maintain a session state identifier throughout the entire power distribution process; the session state identifier is used to distinguish between the authentication phase and the power distribution interaction phase. During the authentication phase, the DNS service remains enabled; during the network configuration interaction phase, the DNS service remains disabled. When the network distribution process is abnormally interrupted, the service mode is restored according to the session status identifier.

[0021] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention discloses a method for automatic redirection during AP network configuration. Users do not need to manually enter IP addresses or URLs; they only need to connect to the device's AP hotspot to be automatically redirected to the network configuration page, greatly simplifying the operation process. By identifying and locking the first received HTTP authentication request, duplicate redirections or failures caused by concurrent requests can be avoided, improving the stability of the network configuration process. By stopping the DNS service, HTTP requests within the network configuration page can be prevented from being intercepted again, thus ensuring the smooth progress of the network configuration process and enhancing compatibility with different mobile terminals and operating systems. The automatic redirection function reduces the cognitive burden and operational difficulty for users, providing a smoother and more convenient network configuration experience. By making complex technical operations transparent to ordinary users, the barrier to using devices for network connectivity can be lowered, promoting the popularization of smart devices. Attached Figure Description

[0022] Figure 1 This is a schematic flowchart of a method for automatic switching during AP network configuration provided in an embodiment of the present invention; Figure 2 This is a flowchart illustrating an implementation method for automatic switching during AP network configuration provided in an embodiment of the present invention. Detailed Implementation

[0023] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0024] like Figure 1 As shown, this application provides a method for automatic switching during AP network configuration, applied to smart devices, including: The smart device is put into AP mode and DNS service for intercepting network requests is enabled to receive HTTP authentication requests from mobile terminals connected to AP mode. For the HTTP authentication request initiated by the mobile terminal, perform the following operations: 1) In the case of multiple concurrent HTTP authentication requests from the mobile terminal, identify and lock the first received HTTP authentication request for processing; 2) In response to the first received HTTP authentication request, send an HTTP redirection instruction to the mobile terminal, the HTTP redirection instruction being used to instruct the browser of the mobile terminal to automatically access the network configuration page built into the smart device; Upon receiving the mobile terminal's access request to the network configuration page, the smart device sends the data of the network configuration page to the mobile terminal and stops the DNS service to switch to the normal web service mode, ensuring that subsequent data interactions are not intercepted again.

[0025] like Figure 2 As shown in one embodiment of this application, a method for automatic switching during AP network configuration is described. This method is applied to a smart device, such as a smart socket, smart camera, or environmental monitor. The smart device integrates a Wi-Fi module, a microcontroller (MCU), and flash memory for storing network configuration page data. The specific implementation steps are as follows: Step S101: The smart device enters AP mode and enables DNS hijacking service.

[0026] When a smart device is powered on for the first time or when the user triggers the network configuration mode via a physical button, such as pressing and holding the reset button for 5 seconds, the smart device enters AP mode. In this mode, the device creates an open Wi-Fi hotspot, whose SSID can be set to "SmartDevice-XXXX", where XXXX is the last four digits of the device's MAC address.

[0027] Upon enabling AP mode, the device's internal operating system immediately activates a lightweight DNS service. This DNS service is configured as a DNS hijacking server, and its core function is to resolve all received domain name resolution requests, regardless of the requested domain name (e.g., captive.apple.com or connectivitycheck.gstatic.com), to the smart device's own IP address. This address is typically the gateway address in AP mode, such as 192.168.4.1. Ensuring that the DNS service remains active until HTTP authentication requests are intercepted is a prerequisite for efficiently capturing network requests and triggering automatic redirects.

[0028] Step S102: Receive and identify the HTTP authentication request from the mobile terminal.

[0029] In the mobile device's Wi-Fi settings list, the user selects and connects to a Wi-Fi hotspot named "SmartDevice-XXXX". After a successful connection, the mobile device's operating system performs a network connectivity check, automatically sending an HTTP request to a preset URL to determine if the Wi-Fi can access the internet normally.

[0030] The smart device's DNS service intercepts the domain name resolution process of this request and returns its own IP address, 192.168.4.1. Subsequently, the mobile terminal sends an HTTP request to port 80 of 192.168.4.1. The web service inside the device receives this HTTP request data packet.

[0031] To accurately identify whether the request is an authentication request initiated by the operating system, the device parses the received HTTP request data. It searches for preset authentication characteristic characters, which are typical markers of authentication requests. In this embodiment, the preset authentication characteristic characters include a combination of "GET / " and "HTTP / 1.". When the request data contains both of these strings, the device confirms that the HTTP request is an authentication request that needs to be processed.

[0032] Step S103: Process concurrent requests and respond to the first authentication request.

[0033] When performing network connectivity checks, some mobile terminals may concurrently establish multiple Socket connections and send several HTTP authentication requests. To avoid repeated redirects or processing chaos caused by this, this invention employs a mechanism to lock the first request.

[0034] The device internally maintains a global variable, such as `g_auth_socket_fd`, initialized to an invalid value. When the first HTTP authentication request arrives, the device creates a socket connection for it and records the connection's identifier, such as the file descriptor `fd`, in `g_auth_socket_fd`. If the device detects a new TCP connection being established, and the received data is also identified as an HTTP authentication request, the device checks `g_auth_socket_fd`. If `g_auth_socket_fd` is already a valid value, it indicates that an authentication process is already underway, and the device will proactively close any subsequent authentication socket connections established, retaining and processing only the first established connection.

[0035] For the initial authentication request that is blocked, the device extracts its HTTP protocol version information, such as the version number from "HTTP / 1.1", and then constructs a compatible HTTP response. This response is an HTTP 302 status code response, and its header contains a crucial Location field. The value of this field is set to the access address of the smart device's built-in network configuration page, such as http: / / 192.168.4.1 / config.html. This HTTP redirection instruction is then sent to the mobile terminal.

[0036] Step S104: Send the network distribution page data and switch to normal Web service mode.

[0037] After receiving the HTTP 302 response, the mobile browser will automatically send a new GET request to http: / / 192.168.4.1 / config.html to access the network configuration page, based on the location field.

[0038] When the smart device receives this access request to the power distribution page, it performs two key operations: The entire data of the network configuration page, including HTML, inline CSS, and JavaScript, is read from internal flash memory and encapsulated in a single HTTP response message before being sent to the mobile terminal. This method effectively avoids data packet transmission failures caused by network instability, ensuring that the page loads completely and quickly.

[0039] After sending the network configuration page data, immediately stop or disable the previously enabled DNS hijacking service. At this point, the device seamlessly switches from "authentication hijacking mode" to "normal web service mode".

[0040] Stopping the DNS service is one of the core steps of this invention. Its purpose is to ensure that subsequent data interactions on the configuration page will not be misjudged as authentication requests and hijacked again, thereby avoiding problems such as looping or abnormal page functionality.

[0041] Step S105: Complete the network configuration interaction and connect to the target network.

[0042] In the normal web service model, users interact with the network configuration page on their mobile device's browser.

[0043] When a user clicks the "Scan Wi-Fi" button, the page initiates an AJAX request via JavaScript. Upon receiving this request, the device activates its Wi-Fi module to scan for nearby Wi-Fi hotspots and encapsulates the scan results into JSON format, returning the list to the mobile terminal. The page then dynamically displays this list.

[0044] Users select their home Wi-Fi network from the list and enter the password. After clicking the "Connect" button, the page submits connection parameters containing the target Wi-Fi name (SSID) and password to the smart device via an AJAX request, for example, POST / api / connect.

[0045] After receiving the connection parameters, the device first sends a network configuration result page to the mobile terminal, such as "Connecting, please wait..." or "Configuration successful", to provide users with immediate feedback.

[0046] Subsequently, the device exits AP mode and attempts to connect to the user-specified target WiFi network using the received connection parameters. Upon successful connection, the device completes the entire network configuration process and can communicate normally with the cloud server.

[0047] Preferably, enabling the DNS service for intercepting network requests includes: When the smart device enters AP mode, the DNS service is immediately activated to intercept network requests from the mobile terminal, and the DNS service is ensured to be active before intercepting HTTP authentication requests in order to improve the efficiency of network request capture. Once the DNS service is enabled, it hijacks the mobile terminal's preset URL requests, ensuring that all HTTP authentication requests are processed internally by the smart device.

[0048] In one embodiment provided in this application, enabling the DNS service immediately after the device enters AP mode can minimize the delay between the mobile terminal initiating a network probe request and the device's ability to respond. This means that when the mobile terminal attempts to connect to the network, the device can detect this behavior more quickly. By actively hijacking specific URL requests initiated by the mobile terminal, it can be ensured that even if the mobile terminal's operating system uses different preset URLs for network probes, these requests can still be effectively captured by the device. This effectively avoids the problem of probe requests not being recognized by the device due to factors such as the mobile terminal's operating system version or manufacturer differences. Only after successfully capturing the mobile terminal's HTTP authentication request can the device perform subsequent HTTP redirection operations. The efficient activation and hijacking mechanism of the DNS service is a prerequisite for successfully triggering automatic redirection. Ensuring that the DNS service is active before capturing the HTTP authentication request means that DNS hijacking is already in effect when the authentication request occurs, and the request can be redirected to the device immediately. This avoids the situation where the device needs to wait for the DNS service to take effect after starting AP mode, during which time the request may be ignored.

[0049] Preferably, receiving the HTTP authentication request from the mobile terminal already connected to the AP mode includes: The HTTP request data sent by the mobile terminal is parsed, and when a preset authentication feature character is detected in the request data, the HTTP request is confirmed to be an authentication request. The preset authentication feature characters include at least one of “GET / ” and “HTTP / 1.”.

[0050] In one embodiment provided in this application, by matching features such as GET / and HTTP / 1., network probe requests typically initiated by the operating system can be accurately identified. These requests usually have a highly consistent structure, effectively distinguishing them from URLs actively entered by the user. Without feature matching, directly blocking all HTTP requests might affect users attempting to access other pages not used for authentication, leading to unexpected redirects or connection interruptions. This feature intelligently identifies and blocks only target requests; including HTTP / 1. as a feature means compatibility with different versions of the HTTP protocol, thereby improving adaptability to various mobile terminals; after accurately identifying authentication requests, the device can clearly know that a redirection operation needs to be performed without additional processing of non-authentication requests.

[0051] Preferably, the process of identifying and locking the first received HTTP authentication request includes: Record the identifier of the first established authentication socket connection; When a subsequent authentication socket connection created by the mobile terminal is detected, the subsequent authentication socket connection is actively closed, and only the initially established authentication socket connection is kept for the network configuration process.

[0052] In one embodiment provided in this application, many smart devices do not adequately consider the behavior of concurrent requests from mobile terminals during their design. When a mobile terminal initiates multiple requests simultaneously, responding to each request may lead to chaos on the mobile terminal, such as overlapping pop-ups, pages failing to load properly, or redirects. By processing only the first socket, such problems are effectively avoided; having only one active authentication socket connection simplifies the device's internal processing logic, reduces resource contention, and thus improves the stability of the entire network configuration process; users will only see one normal browser redirect and network configuration process, without encountering annoying repeated pop-ups or redirect failures, greatly improving the user experience; actively closing illegal subsequent socket connections avoids unnecessary resource consumption (such as CPU and memory), enabling the device to process legitimate network configuration processes more efficiently.

[0053] Preferably, the HTTP redirection instruction is an HTTP 302 status code response, and the header of the HTTP 302 status code response includes a Location field, the value of which is the access address of the network configuration page built into the smart device.

[0054] In one embodiment provided in this application, the HTTP 302 status code and the Location field are standard mechanisms widely supported by web browsers, and can be automatically recognized and executed by the vast majority of mobile operating systems and browsers. Without any user intervention, the browser will automatically load the specified network configuration page; the Location field directly provides the accurate address of the network configuration page, ensuring that the browser accesses the device's preset web interface for network configuration, rather than other irrelevant addresses; this completely eliminates the cumbersome step of manually entering the IP address, significantly lowering the barrier to network configuration and allowing non-technical users to easily connect their devices to the network; and the use of standard HTTP protocol specifications ensures consistent automatic redirection across different brands and models of mobile terminals.

[0055] Preferably, the method further includes: Extract the HTTP protocol version information from the HTTP authentication request; Based on the HTTP protocol version information, an HTTP redirection instruction compatible with the mobile terminal is generated.

[0056] In one embodiment provided in this application, the mobile terminal operating system and browser may have different support for HTTP protocol versions. By identifying and matching the protocol version, the device can generate a more adaptable redirection response, avoiding redirection failure due to protocol mismatch; ensuring that the generated HTTP response conforms to the HTTP protocol specifications supported by the target mobile terminal and can be correctly parsed, thereby successfully triggering browser redirection; avoiding problems such as "protocol not supported" or "incorrect response format" on some terminals, further improving the robustness of the network configuration process; this feature reflects that in AP mode, the device can not only identify requests, but also dynamically adjust its own response according to the details of the request (such as the protocol version), demonstrating higher technical intelligence.

[0057] Preferably, sending the data of the network configuration page to the mobile terminal includes: All data content of the network configuration page is encapsulated in a single HTTP response message and sent at once to avoid loading failures caused by data packet transmission.

[0058] In one embodiment provided in this application, by sending all necessary data at once, the risk of incomplete page loading due to packet fragmentation and reassembly failures during transmission is reduced. This is particularly effective in environments with unstable networks; in areas with poor signal, packet transmission is more prone to problems. The one-time sending strategy better handles this situation, ensuring the smooth progress of the network configuration process; after receiving a complete HTTP response, the browser can directly parse and render it without waiting for subsequent packets, reducing loading complexity.

[0059] Preferably, in the normal Web service mode, the method further includes: In response to the WiFi list acquisition request initiated by the mobile terminal through the network configuration page, the system scans for nearby WiFi hotspots, encapsulates the scan results, and sends them to the mobile terminal. The system receives connection parameters for the target WiFi network submitted by the mobile terminal through the network configuration page. These connection parameters include the WiFi name and password.

[0060] In one embodiment provided in this application, by scanning and displaying a list of nearby WiFi networks, users do not need to manually enter the SSID; they can directly select from the list, greatly simplifying the operation and avoiding input errors. Receiving the WiFi name and password submitted by the user is a necessary step to complete the Wi-Fi connection. The device must accurately obtain these parameters to perform subsequent connection operations. Data transmission in normal Web service mode avoids interference that may be caused by DNS hijacking, ensuring the correct refresh of the WiFi list and the reliable transmission of user-input parameters to the device. This is a crucial stage in translating user intent into actual network connection parameters for the device, laying the foundation for subsequent connection and final successful network configuration.

[0061] Preferably, the method further includes: After receiving the connection parameters, a network configuration result page is sent to the mobile terminal; Control the smart device to exit AP mode and attempt to connect to the target WiFi network using the connection parameters.

[0062] In one embodiment provided in this application, the user can immediately know whether the network configuration was successful, avoiding uncertainty. This includes displaying a page indicating successful connection or providing error information in case of failure, facilitating user troubleshooting; the device can autonomously attempt to connect to the target WiFi network based on the received parameters, which is fundamental to its networking function; after network configuration is completed, the AP mode is turned off, saving device resources and avoiding potential interference to the user's home WiFi network (e.g., IP address conflicts) caused by the continued existence of the AP hotspot; the entire network configuration process, from automatic jump to final connection, forms a complete closed loop, greatly improving the user experience.

[0063] Preferably, the method further includes: Maintain a session state identifier throughout the entire power distribution process; the session state identifier is used to distinguish between the authentication phase and the power distribution interaction phase. During the authentication phase, the DNS service remains enabled; during the network configuration interaction phase, the DNS service remains disabled. When the network distribution process is abnormally interrupted, the service mode is restored according to the session status identifier.

[0064] In one embodiment provided in this application, the DNS service is ensured to be enabled during the authentication phase and stopped when it should not be interfered with, such as during the network configuration interaction phase. This solves the problem in the prior art where the continuous operation of the DNS service leads to page interaction failure; through clear phase division and corresponding service modes, service status confusion at different stages is avoided, thereby reducing failures caused by incorrect service status; when unexpected situations occur during network configuration, the device can intelligently restart or adjust the service based on the recorded session state, guiding the user back to the correct network configuration path, rather than simply failing. For example, if the user tries to reconnect to the AP after exiting the network configuration page, the device can handle it according to the current state (which may still be in the network configuration interaction phase) or return to the authentication phase; even in the case of network fluctuations or user operation errors, the system can guide the user to complete the network configuration as much as possible, reducing the frustration of the user caused by device crashes or repeated errors.

[0065] In one specific embodiment, this embodiment illustrates the key stages of the method, including AP mode startup, authentication request processing, and network configuration page access.

[0066] When the smart device initiates AP mode, it first activates a DNS service to hijack network requests from the mobile terminal. Specifically, the DNS service modifies the local DNS resolution table to redirect a preset URL (such as http: / / captive.apple.com / ) initiated by the mobile terminal to the smart device's own IP address, thereby ensuring that all HTTP authentication requests are processed internally. The DNS service employs a standard DNS hijacking mechanism, listening on a UDP port and activating immediately to reduce latency, ensuring efficient capture of requests while the mobile terminal performs network connectivity checks.

[0067] When a mobile terminal connects to the AP hotspot of a smart device, its operating system (such as Android's ConnectivityManager or iOS's Captive Network Assistant) automatically initiates an HTTP authentication request. In this embodiment, the step of receiving the HTTP authentication request involves parsing the HTTP request data sent by the mobile terminal. The specific parsing process is as follows: The processor of the smart device reads the request message and checks whether the request data contains preset authentication feature characters, such as "GET / " indicating a root path request, or "HTTP / 1." indicating an HTTP protocol version feature. If these characters are detected, the request is confirmed as an authentication request, and subsequent processing logic is triggered. This feature matching mechanism is based on a string comparison algorithm, which improves the accuracy of request identification and avoids interference with non-authentication requests (such as user-defined URL access).

[0068] To address the possibility of multiple concurrent HTTP authentication requests, this embodiment employs a Socket connection management mechanism to identify and lock the first received request. The smart device records the identifier of the initially established authentication Socket connection, which includes the source IP address, port number, and socket descriptor. When subsequent additional Socket connections created by the mobile terminal are detected, the smart device actively closes these connections (e.g., by sending an RST packet), retaining only the initial Socket connection for the network configuration process. This management strategy, based on TCP / IP connection state tracking, ensures that only one active connection is processed, preventing resource contention and repeated redirects. For example, if the mobile terminal sends multiple concurrent GET requests, the device will close all connections except the first one, preventing the browser from repeatedly displaying the network configuration page.

[0069] Upon receiving the initial HTTP authentication request after the device is locked, the smart device generates and sends an HTTP redirection instruction. This instruction uses an HTTP 302 status code response, and the response header includes a Location field. The value of this field is set to the access address of the smart device's built-in network configuration page. The value of the Location field is based on the device's AP IP address and a predefined path, ensuring that the browser automatically redirects to the correct network configuration page. This redirection mechanism utilizes standard HTTP protocol functionality; the browser parses the response and automatically initiates a new request without user intervention.

[0070] Upon receiving an access request from a mobile terminal for the network configuration page, the smart device switches to normal web service mode. Specific steps include: sending the network configuration page data to the mobile terminal, with the data encapsulated in a single HTTP response message to avoid loading failures caused by data packet fragmentation; simultaneously, stopping the DNS service by closing the DNS listening port and restoring standard network routing to ensure that subsequent HTTP requests (such as retrieving a Wi-Fi list) are not hijacked. This mode switching is based on internal state machine management; the processor updates service status flags to transition from hijacking mode to normal mode, preventing loop redirection issues.

[0071] This embodiment avoids compatibility issues caused by concurrent requests and improves network configuration stability by locking the uniqueness of the Socket connection; the standardized use of HTTP redirection commands simplifies user operations and reduces the failure rate of network configuration; and the dynamic stopping of the DNS service ensures reliable interaction of the network configuration page, meeting the application needs of IoT devices in diverse mobile terminal environments.

[0072] The above description represents the preferred embodiments of the present invention. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present invention, and these improvements and modifications are also considered to be within the scope of protection of the present invention.

Claims

1. A method for automatic switching during AP network configuration, applied to smart devices, characterized in that, include: The smart device is put into AP mode and DNS service for intercepting network requests is enabled to receive HTTP authentication requests from mobile terminals connected to AP mode. For the HTTP authentication request initiated by the mobile terminal, perform the following operations: 1) In the case of multiple concurrent HTTP authentication requests from the mobile terminal, identify and lock the first received HTTP authentication request for processing; 2) In response to the first received HTTP authentication request, send an HTTP redirection instruction to the mobile terminal, the HTTP redirection instruction being used to instruct the browser of the mobile terminal to automatically access the network configuration page built into the smart device; Upon receiving the mobile terminal's access request to the network configuration page, the smart device sends the data of the network configuration page to the mobile terminal and stops the DNS service to switch to the normal web service mode, ensuring that subsequent data interactions are not intercepted again.

2. The method for automatic switching during AP network configuration according to claim 1, characterized in that, Enabling the DNS service for intercepting network requests includes: When the smart device enters AP mode, the DNS service is immediately activated to intercept network requests from the mobile terminal, and the DNS service is ensured to be active before intercepting HTTP authentication requests in order to improve the efficiency of network request capture. Once the DNS service is enabled, it hijacks the mobile terminal's preset URL requests, ensuring that all HTTP authentication requests are processed internally by the smart device.

3. The method for automatic switching during AP network configuration according to claim 1, characterized in that, Receiving an HTTP authentication request from a mobile terminal already connected to the AP mode includes: The HTTP request data sent by the mobile terminal is parsed, and when a preset authentication feature character is detected in the request data, the HTTP request is confirmed to be an authentication request. The preset authentication feature characters include at least one of "GET / " and "HTTP / 1." 4. The method for automatic switching during AP network configuration according to claim 1, characterized in that, The process of identifying and locking the first received HTTP authentication request includes: Record the identifier of the first established authentication socket connection; When a subsequent authentication socket connection created by the mobile terminal is detected, the subsequent authentication socket connection is actively closed, and only the initially established authentication socket connection is kept for the network configuration process.

5. The method for automatic switching during AP network configuration according to claim 1, characterized in that, The HTTP redirection instruction is an HTTP 302 status code response. The header of the HTTP 302 status code response includes a Location field, the value of which is the access address of the network configuration page built into the smart device.

6. The method for automatic switching during AP network configuration according to claim 3, characterized in that, The method further includes: Extract the HTTP protocol version information from the HTTP authentication request; Based on the HTTP protocol version information, an HTTP redirection instruction compatible with the mobile terminal is generated.

7. The method for automatic switching during AP network configuration according to claim 1, characterized in that, Sending the data of the network configuration page to the mobile terminal includes: All data content of the network configuration page is encapsulated in a single HTTP response message and sent at once to avoid loading failures caused by data packet transmission.

8. The method for automatic switching during AP network configuration according to claim 1, characterized in that, In the normal web service model, the method further includes: In response to the WiFi list acquisition request initiated by the mobile terminal through the network configuration page, the system scans for nearby WiFi hotspots, encapsulates the scan results, and sends them to the mobile terminal. The system receives connection parameters for the target WiFi network submitted by the mobile terminal through the network configuration page. These connection parameters include the WiFi name and password.

9. The method for automatic switching during AP network configuration according to claim 8, characterized in that, The method further includes: After receiving the connection parameters, a network configuration result page is sent to the mobile terminal; Control the smart device to exit AP mode and attempt to connect to the target WiFi network using the connection parameters.

10. The method for automatic switching during AP network configuration according to claim 1, characterized in that, The method further includes: Maintain a session state identifier throughout the entire power distribution process; the session state identifier is used to distinguish between the authentication phase and the power distribution interaction phase. During the authentication phase, the DNS service remains enabled; during the network configuration interaction phase, the DNS service remains disabled. When the network distribution process is abnormally interrupted, the service mode is restored according to the session status identifier.

Images