Intelligent hardware equipment network distribution method and device based on Wi-Fi promiscuous mode

Abstract

The invention discloses an intelligent hardware equipment network distribution method and device based on a Wi-Fi promiscuous mode, and is applied to the technical field of data processing. Intelligent hardware equipment presets a WiFi decryption rule agreed with a mobile phone APP, automatically enters the WiFi promiscuous mode when power is on and network distribution is not carried out, and prestores an intelligent hardware equipment identifier and cloud communication parameters; wiFi data frames conforming to a frequency band are received in a promiscuous mode, and effective data packets are filtered and screened according to rules; extracting a payload part, verifying the payload part, decrypting the payload part to obtain an SSID (Service Set Identifier) and a password of the target WiFi, and switching to a Station mode; processing the decryption information to generate connection scene information, and further generating connection operation information; and converting into an actual connection action, adapting to the attribute of the router, and generating related parameter information, so that the intelligent hardware equipment successfully accesses the target WiFi network.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a method and apparatus for configuring a network for smart hardware devices based on Wi-Fi promiscuous mode. Background Technology

[0002] In existing technologies, network configuration for smart hardware devices (such as smart home devices and surveillance cameras) typically relies on the following methods: Manual Input Mode: Users manually input the SSID and password of the target Wi-Fi network via device buttons or the display screen. This operation is cumbersome, especially unsuitable for devices without an interactive interface. AP Mode Network Configuration: The device automatically creates a temporary hotspot (AP) after power-on. Users need to connect to this hotspot via their mobile phones, then input their home Wi-Fi information in the app and send it to the device. This mode requires users to manually switch mobile networks, which is complex and results in a poor user experience. Bluetooth / Zigbee Assisted Network Configuration: This establishes short-range communication between the device and the mobile phone via Bluetooth or Zigbee protocols to transmit Wi-Fi information. However, it is limited by the communication distance (usually ≤10 meters) and requires the device to integrate an additional Bluetooth / Zigbee module, increasing hardware costs.

[0003] In addition, the transmission of distribution network information (such as SSID and password) in the existing technology has the following defects: some schemes use plaintext transmission, which poses a risk of being eavesdropped on; there is a lack of effective authentication mechanism, which may lead to unauthorized devices accessing the network or the distribution network information being maliciously intercepted; and there is a lack of accurate filtering of Wi-Fi data frames propagating in the air, which is easily interfered with by irrelevant signals, resulting in a low success rate of distribution network (especially in multi-Wi-Fi environments).

[0004] In existing technologies, Wi-Fi chips mainly operate in two modes: Station mode (client mode, used to access the router) and AP mode (hotspot mode, used for other devices to access). However, the application of promiscuous mode (Monitor Mode) has the following limitations: promiscuous mode is usually used for network monitoring or packet analysis tools and is not widely used in smart hardware network configuration scenarios. Even if some technologies involve promiscuous mode, they do not form a complete closed loop of "capturing air data frames - filtering valid information - decryption verification - switching mode connection". They also lack optimization for network configuration scenarios (such as data frame filtering rules, repeated broadcast confirmation mechanisms, etc.). Summary of the Invention

[0005] To solve the above-mentioned technical problems, the present invention provides the following technical solution: A method for configuring a smart hardware device based on Wi-Fi promiscuous mode is applied to the smart hardware device. The method includes: receiving pre-set Wi-Fi decryption rules agreed upon with a mobile app, and an instruction to enter Wi-Fi promiscuous mode based on preset operations after power-on without network configuration; generating basic rules and mode setting information required for network configuration; and pre-storing the device's unique identifier and basic configuration parameters of the cloud communication protocol; filtering and managing all Wi-Fi data frames transmitted over the air in Wi-Fi promiscuous mode that conform to supported frequency bands according to pre-set Wi-Fi frame broadcast rules, and processing the received data frames to generate data packet information and decryption content information conforming to the agreed rules, wherein different data frame information includes various types of Wi-Fi data packets that the device needs to capture; receiving pre-set decryption rule instructions, processing the decryption content information corresponding to the data packet information conforming to the agreed rules, extracting the payload, verifying the data packet according to verification rules, and using... The decryption rules decrypt the target Wi-Fi's SSID and password, exit promiscuous mode and switch to Station mode, generating decrypted network information and mode switching result information. The decryption rule instructions are generated from pre-set rules agreed upon with the mobile app during device manufacturing. Based on network connection instructions, the decrypted SSID and password information are processed to generate target Wi-Fi connection scenario information. The target Wi-Fi connection scenario information, decrypted network information, and mode switching result information are processed to generate operation information for connecting the device to the target router. Based on preset network configuration requirements and the device's network connection target, the connection operation information is transformed into actual connection actions. The preset network configuration requirements, device network connection target, connection operation information, and target router attributes are extracted and categorized to generate network adaptation parameter information, connection scheduling rule information, network configuration permission verification information, and device-router association mapping information, enabling the device to successfully access the target Wi-Fi network.

[0006] A network configuration device for smart hardware devices based on Wi-Fi promiscuous mode includes: an acquisition module, used to receive pre-set Wi-Fi decryption rules agreed upon with a mobile APP, and instructions to enter Wi-Fi promiscuous mode based on preset operations when not configuring the network after power-on; generating basic rules and mode setting information required for network configuration; and pre-storing basic configuration parameters of the device's unique identifier and cloud communication protocol; a processing module, used to filter and manage all Wi-Fi data frames that conform to the supported frequency bands received in Wi-Fi promiscuous mode, according to pre-set Wi-Fi frame broadcast rules, and perform effective data packet screening to generate data packet information and decryption content information that conform to the agreed rules, wherein different data frame information includes various types of Wi-Fi data packets that the device needs to capture; receiving pre-set decryption rule instructions, processing the decryption content information corresponding to the data packet information that conforms to the agreed rules, extracting the payload, and verifying the data packets according to verification rules. The system verifies and decrypts the target Wi-Fi SSID and password using decryption rules, exits promiscuous mode and switches to Station mode, generating decrypted network information and mode switching result information. The decryption rule instructions are generated from rules pre-set during device manufacturing and agreed upon with the mobile app. Based on network connection instructions, the decrypted SSID and password information are processed to generate target Wi-Fi connection scenario information. The target Wi-Fi connection scenario information, decrypted network information, and mode switching result information are processed to generate operation information for connecting the device to the target router. Based on preset network configuration requirements and the device's network connection target, the connection operation information is transformed into actual connection actions. The preset network configuration requirements, device network connection target, connection operation information, and target router attributes are extracted and categorized to generate network adaptation parameter information, connection scheduling rule information, network configuration permission verification information, and device-router association mapping information, enabling the device to successfully access the target Wi-Fi network.

[0007] Its beneficial effects are as follows: This invention provides a method for configuring a smart hardware device based on Wi-Fi promiscuous mode. The device has pre-set Wi-Fi decryption rules agreed upon with a mobile app. When powered on but not configured, it automatically enters Wi-Fi promiscuous mode, while pre-storing the device's unique identifier and cloud communication parameters. In promiscuous mode, the device receives Wi-Fi data frames that conform to the supported frequency bands and filters valid data packets according to pre-set rules. Subsequently, it extracts the payload portion of the data packets, verifies and decrypts them to obtain the SSID and password of the target Wi-Fi network, exits promiscuous mode, and switches to Station mode.

[0008] Based on the decrypted information, the system verifies the integrity of the format, the validity of characters, and the consistency of encryption. Through mechanisms such as repair and filtering, it generates target Wi-Fi connection scenario information. Further processing generates connection operation information, transforming it into actual connection actions. Adapting to router attributes and incorporating mechanisms such as retry and parameter adjustment, the system ultimately enables the device to successfully connect to the target Wi-Fi network and simultaneously completes cloud binding. Through a closed-loop process of "promiscuous mode capture - encryption / decryption - multi-dimensional verification - dynamic optimization," it solves the problems of complex operation, low security, and insufficient success rate of traditional network configuration methods. This achieves efficient, secure, and automated network configuration for smart hardware devices, while also considering compatibility and cloud integration requirements. Attached Figure Description

[0009] Figure 1 A flowchart illustrating a Wi-Fi promiscuous mode-based smart hardware device network configuration method applied to a smart hardware device, as provided in this embodiment of the invention. Figure 2 This is a schematic diagram of a smart hardware device network configuration device based on Wi-Fi promiscuous mode, provided as an embodiment of the present invention. Detailed Implementation

[0010] The preferred embodiments of the present invention will be described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit the present invention. Figure 1 This application describes a conference live streaming system and its implementation method according to exemplary embodiments. In one embodiment, this application also proposes a smart hardware device network configuration method based on Wi-Fi promiscuous mode.

[0011] In this application embodiment, a method for configuring a smart hardware device based on Wi-Fi promiscuous mode is applied to cloud service devices, such as... Figure 1 As shown: S101 receives the pre-set Wi-Fi decryption rules agreed upon with the mobile APP, and the instruction to enter the Wi-Fi promiscuous mode based on preset operations when the device is powered on but not configured with the network. It generates the basic rules and mode setting information required for network configuration, and at the same time, it pre-stores the device's unique identifier and the basic configuration parameters of the cloud communication protocol.

[0012] In one implementation, during the manufacturing phase, the smart hardware device is programmed with pre-agreed Wi-Fi decryption rules agreed upon with the mobile app. For example, the device may have a built-in symmetric encryption algorithm decryption rule (such as the decryption key for the AES-128 encryption algorithm) agreed upon with the mobile app. This key perfectly matches the key used by the mobile app to encrypt network configuration information. The device is only allowed to decrypt encrypted data packets containing target Wi-Fi information broadcast by the mobile app, providing basic encryption logic support for subsequent parsing of network configuration information and ensuring the security of network configuration information transmission.

[0013] The device has a factory-preset mode switching trigger mechanism: After power-on, the system automatically checks whether network configuration has been completed (i.e., whether valid Wi-Fi connection information is stored in the flash memory). If network configuration is not completed, the device enters Wi-Fi promiscuous mode by pressing and holding (e.g., pressing continuously for 5 seconds) the button on the device. If network configuration is successful, the device exits Wi-Fi promiscuous mode; if network configuration fails within 90 seconds, it also exits Wi-Fi promiscuous mode. For example, after the smart speaker is powered on, if the system detects that there is no SSID and password stored in the flash memory, it immediately calls the wireless network card driver interface to switch the network card's working mode, putting it into Wi-Fi promiscuous mode, and begins listening for all Wi-Fi data frames propagating in the air that conform to the device's supported frequency band (e.g., 2.4GHz).

[0014] Based on the received decryption rules and mode switching instructions, the device integrates and generates the basic rules and mode setting information required for network distribution. For example, it specifies the decryption algorithm type (e.g., AES-128), specific identifiers for packet filtering (e.g., the agreed frame header field "0xAB-CD"), limits the listening to Wi-Fi frames that only broadcast UDP, and the listening frequency band (2.4GHz) in promiscuous mode, etc. At the same time, it records the current working mode as "to be distributed - promiscuous mode" and specifies the encoding rules for parsing information through the Wi-Fi frame data length (e.g., 65 bytes correspond to the ASCII character "A"), providing clear operational standards for subsequent data frame capture and filtering processing.

[0015] During device manufacturing, a unique hardware identifier (such as the SN code "SN2024050001") is written into the device, serving as a globally unique credential for its identity. Simultaneously, basic configuration parameters for cloud communication protocols are pre-stored, such as the default port (1883) for the MQTT protocol and the basic data exchange format (JSON). These parameters provide the identity foundation and protocol support for the device to connect to the manufacturer's cloud server and complete the binding with the user account after successful network configuration. For example, after the device connects to a Wi-Fi network, it can initiate an authentication request to the cloud server using the pre-stored SN code, ensuring that the cloud accurately identifies the device's identity.

[0016] S102 receives all Wi-Fi data frames that conform to the supported frequency bands and are transmitted over the air in Wi-Fi promiscuous mode. It then performs filtering management and effective data packet screening on the received data frames according to the preset Wi-Fi frame broadcast rules, and generates data packet information and decryption content information that conform to the agreed rules.

[0017] In one implementation, all Wi-Fi data frames received in Wi-Fi promiscuous mode that conform to the supported frequency bands are grouped and classified according to preset Wi-Fi frame broadcast rules, generating data sources and associated data frame information corresponding to each rule. After receiving all Wi-Fi data frames in the surrounding 2.4GHz frequency band in Wi-Fi promiscuous mode, the device groups them according to preset Wi-Fi frame broadcast rules (such as frame header identifiers, specific field lengths, etc.). For example, rule 1 is "the frame header contains the field '0xAB-CD' and the data length is between 128 and 256 bytes", and rule 2 is "the frame header contains the field '0xEF-12' and carries an encryption identifier bit". The device matches all received data frames with the rules, and classifies data frames containing the target router information of the encrypted broadcast of the mobile APP and the cloud temporary communication token as core data sources. Other frames belonging to rule 1 are classified as data source 1, and other frames belonging to rule 2 are classified as data source 2. The device records their reception time, signal strength, and other information respectively, forming a set of data sources divided according to the rules.

[0018] Based on filtering requirements, the effective data packet selection content of grouped data frames is designed and arranged, clarifying the selection criteria, data packet types, and extraction range information to generate data packet selection design information. For the grouped data source, selection rules are designed in conjunction with the information required by the distribution network (such as encrypted data packets containing the target Wi-Fi SSID and password, and cloud temporary communication tokens). For example, the selection criteria are set as "data packets carrying a 'distribution network information identifier' and an encryption algorithm identifier of AES-128, while also containing a cloud temporary communication token field"; the data packet type is clearly defined as "management frames broadcast from a mobile app to the router, with target router information and a temporary communication token embedded in the frame"; the extraction range is limited to "the first 100 bytes of the payload portion of the frame (including encrypted network information) and bytes 101-120 (including the cloud temporary communication token)". These designs generate data packet selection design information containing selection conditions, target types, and extraction boundaries, ensuring that only effective data related to the distribution network and subsequent cloud interactions is considered.

[0019] Based on network distribution planning and monitoring requirements, corresponding repeat broadcast confirmation nodes are set for the data packet filtering design information of each rule to ensure that the captured data packets are network distribution information broadcast by the mobile APP. To avoid misjudging non-network distribution data packets, a repeat broadcast confirmation mechanism is set for different filtering design information. For example, for the filtering design corresponding to core data sources containing target router information and cloud temporary communication tokens, "detecting the same data packet broadcast continuously 2 or more times" is set as the confirmation node; for the filtering design corresponding to other data sources, "receiving the same characteristic data packets 5 or more times within 10 seconds" is set as the confirmation node. When the node conditions are met, the device determines that the data packet is network distribution information sent by the mobile APP, reducing the random error of capturing a single frame.

[0020] In another implementation, the device transmits password information by continuously sending data packets of decreasing length (e.g., 255 bytes initially, 254 bytes later, and 253 bytes a third time). The mobile app, upon detecting two consecutive decreasing data packet lengths, can confirm that the device is sending password information, thus accurately capturing such data packets. This further enriches the criteria for determining repeated broadcast confirmation nodes, ensuring that the device and app can accurately identify key information related to the power distribution network, while also meeting the requirement of "filtering valid data packets through specific identifiers."

[0021] The system processes the group management results, data packet filtering design information, and repeated broadcast confirmation nodes to generate data packet information and decryptable content information that conform to the agreed rules, including rule grouping information, filtering schemes, and confirmation criteria. The device integrates the grouped data sources (such as the core data source, data source 1, and data source 2), the corresponding filtering design (such as AES-128 encryption identifier, payload, and temporary communication token extraction range), and confirmation nodes (such as two consecutive broadcasts) to form a complete filtering result. For example, after processing, a data packet broadcast twice consecutively in the core data source is confirmed to conform to all agreed rules, and it is marked as a "data packet conforming to the agreed rules." The payload portion of this data packet (including target router information) and the cloud temporary communication token are extracted as "content information to be decrypted." Simultaneously, its rule group, filtering conditions, and number of confirmations are recorded, providing a clear processing object and basis for subsequent decryption and cloud interaction steps.

[0022] S103 receives preset decryption rule instructions, processes the data packet information corresponding to the decryption content information that conforms to the agreed rules, extracts the payload part, verifies the data packet according to the verification rules, decrypts the target Wi-Fi SSID and password using the decryption rules, exits promiscuous mode and switches to Station mode, and generates decrypted network information and mode switching result information.

[0023] In one implementation, the device receives pre-set decryption and verification rules agreed upon with the mobile app, as well as processing instructions for data packets conforming to the agreed rules, and generates processing requirement information for the content to be decrypted. Regarding the decryption rules, the device has a built-in symmetric encryption algorithm and key that perfectly match the mobile app. Taking AES-128 as an example, the key length of this algorithm is 128 bits. This key is written into the hardware secure storage area (such as the SE chip) during device manufacturing and is consistent with the key used by the mobile app to encrypt network configuration information. This means that only data packets encrypted by the mobile app according to the agreement can be decrypted by the device using this key, ensuring that network configuration information is only transmitted between the agreed device and the app, preventing information leakage or acquisition by unauthorized devices.

[0024] Regarding the verification rules, the method follows the principle of "summing the data bytes, taking the remainder after dividing by 256, and using the least significant byte for verification." For example, in a data packet broadcast by a mobile app, the payload contains multiple data bytes. The device sums these bytes sequentially (e.g., byte values ​​6, 82, 71, 66, 49, 50, 51, totaling 375), then takes the remainder after dividing the sum by 256 (375 / 256=119). The remainder 119 is the least significant byte for verification. The device compares this calculation result with the checksum carried in the data packet. Only if the two match is the data packet considered untampered, ensuring data integrity.

[0025] The processing instructions for data packets that conform to the agreed rules clearly define the specific operational boundaries. For example, the starting offset for extracting the payload is set to the 10th byte, meaning that valid content is extracted starting from the 10th byte of the data packet, excluding irrelevant information such as the frame header identifier in the first 9 bytes; the data length is limited to 64-128 bytes, because the SSID of the target Wi-Fi and the amount of data after encryption are usually within this range. The device only processes payloads within this length range, which can filter out invalid data packets that are too long or too short, reducing unnecessary calculations.

[0026] The processing requirements for the content to be decrypted, generated based on these instructions, clearly define the following: the data packets to be processed must have a payload length of 64-128 bytes, a frame header containing a predefined identifier (such as "0xAB-CD"); decryption must use a pre-set AES-128 key; and verification is based on the least significant byte obtained by summing the data bytes and taking the remainder after dividing by 256. This information provides precise guidance for subsequent data packet processing, ensuring that the device only decrypts and verifies network distribution data packets that meet the requirements, thus improving processing efficiency and security.

[0027] Based on verification rule instructions and processing instructions, the device performs targeted processing on the decryption content information corresponding to data packets that conform to the agreed rules. It extracts the payload portion through extraction, calculates the checksum, confirms the consistency between the high and low bytes, takes the low checksum, and completes the data packet verification. Based on the decryption rules, it decrypts to obtain the target Wi-Fi's SSID and password, performs a mode switching operation to exit promiscuous mode and switch to Station mode, and generates processed network information and mode switching result elements. For data packets that conform to the agreed rules (such as data packets with a frame header containing the identifier "0xAB-CD" or broadcast more than twice consecutively), the device strictly extracts the payload according to the range specified by the instructions: extraction starts from the 10th byte of the data packet. The first 9 bytes are auxiliary information such as the frame header identifier and data type, and are not treated as valid network configuration content. For example, if a data packet has a total length of 90 bytes, and the first 9 bytes are a fixed frame header of "0xAB-CD-01-02-03-04-05-06-07", the device extracts valid content starting from the 10th byte. Extract an 80-byte payload. This length covers the total capacity of the encrypted target Wi-Fi SSID (maximum 32 bytes), password (maximum 64 bytes), and cloud-based temporary communication token (16 bytes), ensuring complete inclusion of the core information required for network configuration. For example, in the extracted payload, the first 32 bytes are the encrypted SSID, the middle 64 bytes are the encrypted password (padded with padding bits if the actual password length is insufficient), and the last 16 bytes are the cloud-based temporary communication token, together forming an 80-byte effective payload.

[0028] The verification process strictly follows the rule of "summation and modulo, comparison of low-order bytes" to ensure the integrity of data transmission: all bytes in the extracted 80-byte payload are summed sequentially. Taking a portion of the bytes in the example (6, 82, 71, 66, 49, 50, 51) as an example, the sum is 375. The sum of the complete payload is calculated in the same way. The sum is converted to 16-bit binary (e.g., 375 is converted to "0000 0001, 0111 0111"), where the high-order byte is "0000 0001" (decimal 1) and the low-order byte is "0111 0111" (decimal 119). The device first confirms the logical consistency of the high and low bytes (i.e., whether the sum is within the range of 0-65535 to ensure no overflow error), then extracts the low byte 119 as a check bit and compares it with the check bit carried in a special field in the data packet (such as the low value in the 89th-90th bytes of the frame tail). If the two are consistent, it is determined that the data packet has not been tampered with and the verification passes.

[0029] Decryption is based on a pre-configured AES-128 algorithm and key to ensure the security of network configuration information: The AES-128 algorithm uses a 128-bit key (16 bytes) and CBC encryption mode, with the initialization vector (IV) contained in the first 16 bytes of the payload. The device retrieves the key agreed upon with the mobile app from the hardware secure storage area, for example, the key is "0x12-34-56-78-9A-BC-DE-F0-F1-E2-D3-C4-B5-A6-77-88". The verified payload (64 bytes after removing the IV) is decrypted to obtain the plaintext information. For example, after decryption, the SSID field is "Home-WiFi", the password field is "12345678", and the cloud temporary communication token is "TMP-8A7B6C5D4E3F2G1H", which correspond to the network identifier, access credentials, and temporary permission credentials for subsequent cloud interactions required for network configuration, respectively.

[0030] Mode switching is a crucial step in transitioning a device from "listening state" to "connected state": The device disables full-band listening in promiscuous mode by calling the underlying driver interface of the wireless network card (e.g., "wlan_mode_switch (STATION_MODE)"), releasing the hardware resources occupied by listening. After switching, the device queries the current mode via the "wlan_get_mode()" interface. A return value of "Station" confirms a successful switch, and the switching time (e.g., 200ms) is recorded. If the switch fails (e.g., "Error"), a retry mechanism is triggered (up to 3 times). If it still fails, a "switching exception" result is generated, awaiting the next round of network configuration commands. The processed network information explicitly records the decrypted SSID, password, and encryption type (e.g., "WPA2-PSK"). The mode switching result includes the status ("success" or "failure"), the current mode, and the time elapsed, providing clear status information for subsequent connection to the target router. Through these steps, the device completes the entire process from packet parsing to state transition, with each step strictly following preset instructions to ensure the accuracy, security, and validity of the network configuration information and the device status.

[0031] The processed network information and mode switching results are collaboratively optimized to ensure information accuracy and mode switching effectiveness. Information accuracy verification revolves around the decrypted SSID and password, strictly adhering to Wi-Fi protocol specifications and pre-defined rules: According to Wi-Fi naming conventions, the SSID must meet the following requirements: "length 1-32 bytes," "do not contain non-printable characters (such as ASCII codes 0-31 and 127)," and "do not contain system-reserved special identifiers (such as '*', '?', '@#', etc., characters that may cause parsing conflicts)." For example, if the device decrypts the SSID to "Home@#-WiFi," it is deemed abnormal due to the presence of the illegal character "@#," immediately triggering a re-decryption process: the payload portion of the data packet is re-extracted, and the key calls and algorithm parameters (such as the AES-128 CBC mode initialization vector) during decryption are checked for correctness. If character garbled text is found due to byte offset errors during decryption, it is corrected and re-decrypted to obtain "Home-WiFi." If the verification confirms compliance with the specifications, the SSID is considered valid. Passwords must meet the following requirements: "Length 8-64 bytes" and "Support ASCII printable characters (32-126)". For example, if the decrypted password is 6 bytes long (e.g., "123456"), which does not meet the minimum length requirement, the device will initiate dual verification: on the one hand, it will re-check the payload extraction range (to confirm whether any bytes are missing), and on the other hand, it will check whether the data packet broadcast by the mobile APP has a truncated password field. If it is confirmed that the information is incomplete due to data packet fragmentation during transmission, it will wait for the complete data packet to be captured and then decrypted again until a password of the correct length is obtained (e.g., "12345678").

[0032] The validity verification of mode switching is achieved through hardware interface query and status repair mechanisms to ensure successful switching from promiscuous mode to Station mode: The device calls the wireless network card status query interface (e.g., "wlan_status_get()"). If the returned information includes "Mode: Station" and "Channel: 6" (corresponding to the target Wi-Fi frequency band), the switch is confirmed to be successful; if it returns "Mode: Monitor" (still in promiscuous mode) or "Mode: Error" (switching failed), it is determined to be invalid. For switching failures, the device performs tiered processing: First, it calls the "wlan_mode_reset()" interface to reset the network card status (releasing occupied frequency band resources), and after a 500ms interval, it executes the switching command again ("wlan_mode_switch (STATION_MODE)"); if two consecutive switching failures occur, a soft restart of the wireless network card is triggered ("wlan_restart()"), clearing the underlying driver's abnormal state and retrying the switch, with a maximum of 3 retries. For example, if the first switch fails due to network card driver occupancy, resetting the status and switching again will return "Mode: Station," confirming the switch is valid.

[0033] Through the above verification and optimization process, the device clearly defines the processing requirements for the content to be decrypted, specifically including the following: data packets are limited to those that are "broadcast continuously twice or more," "have a frame header containing a pre-defined identifier (such as 0xAB-CD)," and "have a payload length of 64-128 bytes (ensuring complete inclusion of the encrypted SSID, password, and temporary token)." Invalid data packets with "mismatched checksums" or "abnormal SSID / password format after decryption that cannot be corrected by re-decryption" must be excluded. The AES-128 symmetric encryption algorithm is fixed, the key is retrieved from the hardware secure storage area, and the encryption mode is CBC (the initialization vector IV is included in the first 16 bytes of the payload), ensuring complete matching with the encryption method of the mobile app.

[0034] The verification criteria include: "The low-order byte of the sum of payload bytes modulo 256 matches the checksum carried in the data packet" (data integrity verification); "The decrypted SSID is 1-32 bytes and does not contain illegal characters"; and "The password is 8-64 bytes and consists of printable characters" (information validity verification). All three criteria must be met simultaneously for the data distribution information to be considered valid. These processing requirements provide precise execution standards for subsequent data packet screening and decryption operations, ensuring the reliability of the data distribution information and improving the process's fault tolerance through an anomaly repair mechanism.

[0035] The integrated processing and optimization results generate decrypted network information and mode switching result information, including complete decrypted network information and mode switching results. The integrated network information covers the core connection parameters of the target Wi-Fi, ensuring that subsequent device connection operations have a clear basis. The SSID (Service Set Identifier) ​​is explicitly "HomeWiFi," a name that has passed format verification, contains no illegal characters, and is within the 1-32 byte length range, conforming to Wi-Fi protocol specifications. It is the unique identifier for the device to identify the target network. The password record is "12345678," 8 bytes in length, falling within the valid range of 8-64 bytes, and all are ASCII printable characters. Its validity has been verified, ensuring that the device can successfully access the network with this credential. The encryption type is marked "WPA2-PSK," extracted from the decrypted payload and matched with the target router's encryption method. The device can then invoke the corresponding authentication algorithm (such as CCMP encryption algorithm) to ensure the security of the connection process.

[0036] The mode switching result clearly reflects the device's current working status, providing status support for connection operations: a "successful" status indicates that the device has successfully switched from Wi-Fi promiscuous mode (MonitorMode) to Station mode (client mode), possessing the hardware foundation to access the target Wi-Fi network. The time taken is "200ms," a parameter reflecting the efficiency of the mode switching and serving as a basis for device performance evaluation. If the time is too long (e.g., exceeding 1 second), it indicates a driver abnormality or hardware bottleneck in the wireless network card. The current mode is explicitly set to "Station," obtained and confirmed in real-time through the network card status query interface, ensuring that the device is currently in a working mode capable of connecting to the router, rather than remaining in a listening state or experiencing a mode switching failure.

[0037] Recording key parameters during the processing provides a basis for subsequent troubleshooting and data support for connection optimization. The decryption time is recorded as "50ms," reflecting the execution efficiency of the AES-128 decryption algorithm. Abnormal time (e.g., exceeding 500ms) may indicate a problem with the key call process or hardware encryption module. The checksum value is recorded as "119," consistent with the checksum carried in the data packet, proving that the data packet was not tampered with during transmission, ensuring data integrity, and providing a verification basis for tracing the processing logic of the data packet later. The payload extraction range is "bytes 10-89," clearly defining the extraction boundary of the effective payload. If subsequent connection failures occur, this parameter can be used to check whether network information is missing due to payload extraction errors. Through the above integration, the resulting complete set contains all the core information required for the device to access the target Wi-Fi, ensuring the accuracy of network parameters and the validity of mode status. The key parameter recording also enables traceability of the network configuration process, laying a reliable data foundation for subsequent operations such as device connection to the target router and cloud binding.

[0038] S104 processes the decrypted SSID and password information based on the network connection command to generate target Wi-Fi connection scenario information.

[0039] In one implementation, the decrypted SSID and password information are obtained based on a network connection command, and the information's format integrity, character validity, and encryption consistency features are extracted. The device responds to the network connection command, retrieves the decrypted network information (e.g., SSID is "HomeWiFi" and password is "12345678"), and extracts three core features, specifically: Format integrity: Checks whether the SSID contains the necessary identifier structure (e.g., no empty values, conforms to the basic format of Wi-Fi naming), and whether the password has any missing segments (e.g., whether it has been truncated to "1234"); Character validity: Identifies whether the SSID and password contain non-printable characters (e.g., ASCII codes 0-31) or system-reserved characters (e.g., "*" or "?"), and whether the length is within the specified range; Encryption consistency: Verifies whether the decrypted encryption identifier (e.g., "WPA2-PSK") matches the preset encryption rules (e.g., the device is manufactured to support only WPA2 / WPA3).

[0040] The system verifies the format integrity of SSIDs and passwords, identifying format errors and missing information, and generating information integrity parameters. The SSID, as the unique identifier of the target Wi-Fi network, directly affects the device's ability to accurately identify the network. The device sets verification standards according to Wi-Fi protocol specifications: if the decrypted SSID is an empty string (e.g., "") or consists only of spaces (e.g., ""), it is considered a "format error". For example, if the SSID field is empty due to frame loss during data packet transmission, the device cannot locate the target network based on the empty value and must mark it as a format error. The system checks for obvious structural breaks in the SSID (e.g., a normal SSID is "Office-5G", but decrypts to "Office-"). If there are truncated or incomplete field identifiers, it is also considered a "format error". When the SSID is "HomeWiFi" (complete and without empty values), it is considered "format complete"; when the SSID is "" (empty value) or "Café" (extra spaces at the end causing a logical null value), it is considered "format error".

[0041] The integrity of the password format determines whether a device can access the network through authentication. The device primarily verifies the following dimensions: Length integrity: If the password length is 0 (empty password, not conforming to Wi-Fi security specifications), or the actual length is much shorter than expected (e.g., the original password "12345678" is reduced to "1234" due to decryption offset), it is considered "missing anomaly". For example, if the password field is fragmented and lost during transmission, resulting in only the first half being decrypted, the device cannot complete authentication with an incomplete password. Segment integrity: For passwords containing special formats (e.g., "ABC-1234-DEF" containing separators "-"), if the middle segment is missing after decryption (e.g., "ABC-1234"), it is considered "missing anomaly" because incomplete segments may cause password verification failure. When the password is "12345678" (complete 8 characters), it is considered "format complete"; when the password is "" (length 0) or "5678" (only the second half, the original password should be "12345678"), it is considered "missing anomaly".

[0042] The device quantifies the verification results into parameters ranging from 0 to 1 (1 indicates complete integrity, 0 indicates severe missing information), intuitively reflecting the usability of the information: If the SSID format is complete and the password is not missing (e.g., SSID is "HomeWiFi", password is "12345678"), the parameter "SSID format complete (1), password format complete (1)" is generated. If the SSID format is complete but the password is partially missing (e.g., only the first 4 characters "1234" are decrypted, the original length should be 8 characters), the parameter "SSID format complete (1), password missing (0.5)" is generated, where 0.5 indicates that the password integrity is moderate (half missing). If the SSID is empty and the password length is 0, the parameter "SSID format error (0), password severely missing (0)" is generated, indicating that the information is completely unusable and a re-decryption process needs to be triggered. Through the above verification, the device can accurately identify the format problems of the network configuration information, providing a basis for subsequent format repair (e.g., requesting a rebroadcast of the complete data packet), ensuring that the SSID and password used for connection have basic format validity.

[0043] The validity of characters is verified to check for illegal characters or exceeding length limits, generating a character compliance factor. The validity of SSID characters directly affects the device's identification and matching of the target network. The verification standard follows the Wi-Fi protocol, with length limits: the protocol stipulates that the SSID length must be between 1 and 32 bytes (1 byte corresponds to 1 ASCII character). For example, an SSID of "LongNetworkNameExceeding32Bytes" contains 33 characters (33 bytes), exceeding the maximum limit and is judged as "length exceeded"; if the SSID is "Home" (4 bytes), the length is compliant. Character type: only printable ASCII characters (decimal 32-126) are allowed, including letters, numbers, and common symbols (such as "-", "_", "."). If the SSID contains non-printable characters (such as newline characters, tab characters) or special control characters (such as ASCII codes 0-31), such as "Office\nWiFi" (including newline characters), it is marked as "invalid character". SSID “LivingRoom-2.4G” (14 bytes, including letters, numbers, and hyphens) was determined to be “valid character”; SSID “LongNameWith33CharactersExactly” (33 bytes) was determined to be “length exceeded”; SSID “Kitchen@WiFi” (containing “@”, a symbol allowed by the protocol) was determined to be “valid character” (“@” is a legal character in SSID, but may be considered illegal only in password verification).

[0044] The validity of a password determines whether a device can pass the router's authentication. The verification standard combines security and compatibility in its design, with a length limit: to ensure security, the password length must be between 8 and 64 bytes. For example, the password "1234567" (7 bytes) is considered "insufficient length," "123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234" (65 bytes) is considered "exceeding the length limit," while "12345678" (8 bytes) is within the acceptable length. Special characters that may cause router parsing errors are prohibited (such as "@#$%^&*()"), etc. The specific prohibited list is consistent with the mobile app's conventions. For example, the password "Pass@word123" contains "@", which is considered "invalid character"; the password "Pass_word123" (containing "_", which is a allowed character) is considered "valid character." The password "Home1234" (8 bytes, containing only letters and numbers) was determined to be "valid characters"; the password "Admin#2024" (containing "#") was marked as "invalid characters"; the password "UserPassword With64CharactersExactly1234567890" (64 bytes) was determined to be "length compliant".

[0045] The device quantifies the verification result into a compliance factor in the range of 0-1 (1 represents full compliance, 0 represents complete non-compliance), intuitively reflecting the usability of the information: If the SSID is “BedroomWiFi” (11 bytes, character compliance) and the password is “Secure123” (8 bytes, character compliance), the generation factor is “SSID length compliance (1), password character compliance (1)”. If the SSID is “LongNetworkNameExceeding32Bytes” (33 bytes) and the password is “Pass@word” (containing the illegal character “@”), the generation factor is “SSID length exceeds limit (0), password contains illegal characters (0.3)”, where 0.3 indicates that although the password contains illegal characters, its length is compliant (partial compliance).

[0046] If the SSID is "" (0 bytes, insufficient length) and the password is "12345" (5 bytes, insufficient length), the generation factor "SSID length violation (0), password length violation (0)" indicates that the information is completely non-compliant and requires re-decryption or a request for the mobile app to resend the data packet. Through the above verification, the device can accurately identify character problems in the network configuration information, providing a basis for subsequent character filtering (such as removing illegal characters) or re-acquiring information, ensuring that the SSID and password used for connection ultimately comply with the Wi-Fi protocol specifications, and reducing the risk of access failure.

[0047] Verify the encryption consistency characteristics to confirm the matching of the decryption result with the preset encryption rules and generate encryption matching coefficients. The device verifies the encryption type obtained from decryption with the preset rules: if the decryption result shows that the target Wi-Fi encryption type is "WPA2-PSK" and the device's preset rules support this type (such as only allowing WPA2-PSK / WPA3-SAE), then the matching is determined to be "consistent"; if the encryption type is the obsolete "WEP" (not supported by the device's preset rules), then it is determined to be "mismatched"; generate encryption matching coefficients, such as "encryption type matches (1)" or "encryption type not supported (0)".

[0048] Based on preset connection preparation rules, the device processes information integrity parameters, character compliance factors, and encryption matching coefficients. It employs a format repair mechanism to improve the information structure, character filtering technology to remove invalid content, and an encryption verification algorithm to confirm decryption validity, generating a connection preparation result. The device's processing of these three types of parameters—information integrity parameters, character compliance factors, and encryption matching coefficients—according to preset rules is a key optimization step to ensure that network configuration information can be directly used for connection operations. For information format anomalies caused by byte offsets or transmission interference during decryption, the device automatically corrects them through preset logic: if the SSID ends with an extra null character due to decryption offset (e.g., "HomeWiFi" contains an invisible space at the end), the device automatically removes the null character and restores it to "HomeWiFi" according to the Wi-Fi protocol's requirement that "SSIDs do not contain meaningless null characters," ensuring accurate SSID identification. If a password field has missing segments but its complete length can be traced (e.g., the original password should be 16 bytes, but after decryption only the first 10 bytes are complete, and the last 6 bytes are garbled), the device, based on preset password length verification rules, determines it as "repairable missing". It then requests to recapture the data packets broadcast in the same batch (using a repeated broadcast confirmation mechanism) to extract the complete password field and complete the repair. Before repair, the SSID was "Office-5G" (including a trailing null character); after repair, it is "Office-5G". Before repair, the password was displayed as "ABC123??" (the last two digits are garbled) due to packet loss; after recapture of the data packets, it was repaired to "ABC12345".

[0049] To address issues such as passwords containing illegal characters or being too short, the device employs a character filtering and supplementation mechanism for compliance processing: If the password contains illegal characters prohibited by the protocol, such as "@#" (e.g., "123@#4567"), the device activates character filtering technology, removing "@#" from a pre-set "illegal character blacklist" (consistent with the prohibited character set agreed upon by the mobile app), resulting in "1234567". Because its length is only 7 bytes (less than the minimum standard of 8 bytes), it automatically supplements with preset characters (e.g., adding "8") to reach "12345678", ensuring compliance with password length specifications. If the SSID contains non-printable characters (e.g., control characters with ASCII codes 0-31), such as "LivingRoom\x00" (containing an empty character), the device filters out these non-printable characters and corrects them to "LivingRoom" to prevent the router from being unable to recognize the password due to character anomalies. The original password "Pass@word#123" becomes "Password123" (11 bytes, which meets the length requirement) after filtering out the illegal character "@#"; the original SSID "Bedroom\x0A" (including newline characters) becomes "Bedroom" (8 bytes, which is compliant) after filtering.

[0050] To ensure network access security, the encryption verification algorithm confirms the consistency between the decryption result and the preset rules: The device extracts the decrypted encryption type (e.g., "WPA2-PSK"), calculates its feature value using a hash algorithm (e.g., SHA-1 hash value "a1b2c3d4"), and compares it with the list of supported encryption type feature values ​​in the preset rules (e.g., "WPA2-PSK: a1b2c3d4; WPA3-SAE: e5f6g7h8"). If they match, the encryption type is considered a match. If the decrypted encryption type is "WEP" (not supported by the device's preset rules due to insufficient security), the encryption verification fails, and the device triggers a re-decryption process. If multiple attempts fail, the message "Encryption type not supported" is displayed. If the decrypted encryption type is "WPA2-PSK" and its hash value matches the corresponding value in the preset list, the verification passes; if the obtained encryption type is "WEP" and its hash value is not in the list, the verification fails.

[0051] The device integrates the above processing results to generate a clear connection preparation status description: If the format repair is complete, the character filtering conforms to the specifications, and the encryption verification passes, the generated result is as follows: "Format repair complete (SSID removes empty characters, password supplemented to 8 bytes), character filtering conforms to the specifications (removes illegal characters such as @#), encryption verification passes (WPA2-PSK matches preset rules)." If any processing fails (e.g., encryption type consistently mismatches), the generated result is as follows: "Format repair complete, character filtering conforms to the specifications, encryption verification fails (WEP encryption type not supported)", and a retry mechanism is triggered (e.g., recapture and decrypt data packets). Through the above processing, the device optimizes the original decrypted information into valid parameters that conform to the Wi-Fi protocol specifications and can be directly used for connection, laying a reliable foundation for subsequent access to the target router, while ensuring the fault tolerance and security of the network configuration process.

[0052] Integrate the connection preparation results to generate target Wi-Fi connection scenario information that meets the Wi-Fi access conditions. Specify the encryption type as "WPA2-PSK" and the channel priority based on signal strength (e.g., 2.4GHz channel 6 has higher priority than channel 1). Cloud pre-connection parameters include the temporary connection port for the MQTT protocol (e.g., 1883), the pre-connection timeout (e.g., 5 seconds), and the nearest server address predicted based on the phone's request IP (e.g., "us-mqtt.taocloud.xxx" for US region devices). The final generated scenario information is "Target Wi-Fi: SSID=HomeWiFi, Encryption Type=WPA2-PSK, Channel Priority=6 (2.4GHz), Cloud Pre-connection Parameters=(Port 1883, Timeout 5 seconds, Server us-mqtt.taocloud.xxx)", ensuring that all necessary parameters are specified before device access.

[0053] S105 processes the target Wi-Fi connection scenario information, decrypted network information, and mode switching result information to generate operation information for the device to connect to the target router.

[0054] In one implementation, multi-dimensional feature extraction is performed on the target Wi-Fi connection scenario information, decrypted network information, and mode switching result information. The adaptation parameters of the connection scenario and the validity parameters of the network information are analyzed, and the status parameters of the mode switching and the device's operating mode attributes are identified, generating a set of features to be processed that includes scenario adaptation features, network validity features, and mode status features. The device extracts key features from these three types of information to form the set to be processed. Scenario adaptation features: Analyzing adaptation parameters in the target Wi-Fi connection scenario information, such as encryption type (WPA2-PSK), channel priority (channel 6 is preferred over channel 1), and MQTT pre-connection parameters (server address us-mqtt.taocloud.xxx, port 1883); Network validity features: Extracting validity parameters from the decrypted network information, such as the format compliance of SSID "HomeWiFi" (1-32 bytes) and the length validity of password "12345678" (8 bytes); Mode status features: Identifying status parameters in the mode switching result, such as switching status (successful), current mode (Station), and switching time (200ms). Specifically, the generated feature set is as follows: "Scenario adaptation features: encryption type = WPA2-PSK, channel priority = 6; network validity features: SSID compliant (yes), password valid (yes); mode status features: current mode = Station, switch successful (yes)".

[0055] Based on preset connection execution rules, the feature set is processed collaboratively. A network parameter matching algorithm is used to adapt the connection scenario to network information. Mode state verification technology is employed to confirm the validity of mode switching. A connection timing planning tool is used to coordinate the operation steps, generating connection processing results and evaluation information covering scenario matching degree and mode validity. Network parameter matching compares scenario adaptation features with valid network features, such as confirming that the encryption type "WPA2-PSK" matches the encryption rules supported by the device, and that channel 6 is consistent with the target router's current operating channel. Mode state verification calls the network card interface to confirm the mode state a second time; a return of "Mode: Station" indicates a valid switch. The timing planning specifically coordinates the operation steps as follows: "① Initialize network card driver → ② Enter SSID and password → ③ Initiate authentication request → ④ Connect to MQTT server". The generated evaluation information is "Scenario matching degree = 90% (encryption type and channel are both adapted), Mode validity = 100% (switched to Station mode)". The connection processing results include the specific execution steps.

[0056] Based on the evaluation information, targeted optimizations are performed. Parameter adjustment mechanisms are used to handle scenario mismatches, and a state reset algorithm is applied to correct mode switching anomalies. Invalid network information is re-decrypted to generate optimized connection content with high adaptability and stable state. If channel 6 is busy, resulting in low matching, it automatically switches to the second-priority channel 1 and updates the MQTT server address to the nearest node (e.g., if the device is detected to be located in the United States, it switches to us-mqtt.taocloud.xxx). If the mode state check finds it is still in promiscuous mode, a state reset is performed (restarting the wireless network card → re-switching to Station mode). If the password length after decryption is less than 8 bytes, a re-decryption process is triggered, extracting the complete password "12345678" from the captured data packet. Example: The optimized connection content is "Channel adjusted to 1, mode switching state corrected to successful, password updated to valid length".

[0057] The system integrates and optimizes connection content, performs final parameter verification based on the real-time and stability requirements of the target device's network connection, and generates operation information for the device to connect to the target router, including connection steps, verification mechanisms, and anomaly handling solutions. Specifically, it defines the steps as follows: "① Configure network card parameters (encryption type = WPA2-PSK, channel = 1) → ② Enter SSID = HomeWiFi, password = 12345678 → ③ Initiate Wi-Fi connection → ④ Connect to the MQTT server (address us-mqtt.taocloud.xxx:1883)". The verification mechanism sets connection success criteria, such as obtaining an IP address (192.168.1.100) via Wi-Fi and a normal MQTT heartbeat response. For connection timeouts (e.g., failure to obtain an IP address within 10 seconds), a retry mechanism is initiated (maximum 3 times); if the MQTT connection fails, it switches to the backup server address (hk-mqtt.taocloud.xxx). The operation information fully records the steps, verification criteria, and anomaly policies to ensure that the device efficiently connects to the target router and cloud services according to the process.

[0058] S106: Based on the preset network distribution requirements and device network connection targets, the connection operation information is transformed into actual connection actions. The preset network distribution requirements, device network connection targets, connection operation information and target router attributes are extracted and classified to generate network adaptation parameter information, connection scheduling rule information, network distribution permission verification information and device-router association mapping information, so that the device can successfully access the target Wi-Fi network.

[0059] In one implementation, connection operation information is processed based on preset network configuration requirements and device network connection goals. A time-series execution mechanism is used to transform this information into actual connection actions. A processing module combining parameter matching and verification adapts the target router attributes. Based on classification rules, the preset network configuration requirements, device network connection goals, connection operation information, and target router attributes are extracted and processed to generate network adaptation parameter information, connection scheduling rule information, network configuration permission verification information, device-router association mapping information, and connection status evaluation information. The device uses preset network configuration requirements (e.g., "prioritize connecting to the 5GHz band" and "complete network connection within 10 seconds") and network connection goals (e.g., "immediately bind to the cloud after connection") as a basis to transform connection operation information into sequentially executed actions. Time-series execution: For example, the action sequence is "① Initialize wireless network card → ② Enter SSID and password → ③ Initiate router authentication → ④ Receive IP address → ⑤ Connect to MQTT server," ensuring that the steps are executed in a logical order. Parameter matching: By comparing the target router's attributes (such as supported encryption type WPA2-PSK, working channel 6) with the device connection parameters, the module generates network adaptation parameters (such as "encryption algorithm = CCMP, channel = 6").

[0060] The information extraction categories are as follows: network adaptation parameters: such as "maximum retransmission count = 3, timeout = 5 seconds"; connection scheduling rules: such as "prioritize the 2.4GHz band, switch when 5GHz connection fails"; network configuration permission verification information: such as device SN code "SN2024050001" and temporary token "TMP-8A7B6C"; device and router association mapping: such as "device MAC address = AA:BB:CC:DD:EE:FF → router BSSID = FF:EE:DD:CC:BB:AA"; connection status evaluation information: such as "current progress = 30%, estimated remaining time = 2 seconds".

[0061] Based on connection status assessment information, various generated information is validated from multiple dimensions. A retry mechanism is initiated for connection timeouts. For devices with mismatched parameters, a dynamic adjustment service is invoked for secondary parameter adaptation. For devices with failed authorization verification, a credential update process is triggered, generating an optimized connection scheme including exception handling strategies and retry time windows. Devices perform validation and optimization based on assessment information (such as "connection timeout 5 seconds" or "encryption type mismatch"). Connection timeout retry: If the router is unresponsive for more than 10 seconds, a retry mechanism is initiated (up to 3 times), with a 2-second interval between each retry. For example, the channel is switched to 1 during the first retry, and the transmission rate is reduced during the second retry. Secondary parameter adaptation: If the router only supports WPA3 encryption (mismatched with the device's initial WPA2 parameters), the encryption algorithm is dynamically adjusted to WPA3, generating a new parameter "encryption type = WPA3-SAE".

[0062] If SN code verification fails (e.g., the device is not recorded in the cloud), a credential update process is triggered to re-obtain the device SN code and send a verification request to the cloud, generating a new token "TMP-9C8D7E". The optimization scheme includes "anomaly handling strategy: retry 3 times after timeout, switch the channel to 1; retry time window: 2 seconds / time; adaptation parameters: update the encryption type to WPA3".

[0063] The optimized connection scheme is integrated and executed, responding to connection operation commands and generating a final connection result indicating successful device access to the target Wi-Fi network. The device integrates and executes the optimized scheme, and upon successful access, synchronously achieves cloud interaction. For example, it initiates a connection using the adjusted parameters "SSID=HomeWiFi, Password=12345678, Encryption Type=WPA3, Channel=1", successfully obtaining the IP address "192.168.1.105". Based on the pre-stored MQTT configuration, it establishes a connection with TAO Cloud using the server address "us-mqtt.taocloud.xxx", account "SN2024050001", and password "PWD-7G6H5J4K" issued by the cloud, reporting the "online" status and SN code.

[0064] The final result generated is "Connection status = Successful, Wi-Fi signal strength = -65dBm, MQTT connection status = Bound, Bound user ID = 12345", while logging "Network configuration completed at 10:30:00 on May 20, 2024, taking 8 seconds". Through the above steps, the device not only successfully connects to the target Wi-Fi, but also simultaneously completes cloud binding. Furthermore, the stability of the process is ensured through an exception handling mechanism, meeting the core objective of "one-click network configuration + seamless cloud integration".

[0065] Optionally, in another embodiment based on the method described above in this application, the method further includes: During the network configuration phase, smart hardware devices provide their pre-stored unique identifier to the mobile app for the app to obtain. After the smart hardware device connects to the target Wi-Fi network, it reads the locally stored SN code and the basic parameters of the cloud communication protocol, and sends an authentication request to the cloud service device. The request carries the SN code and the temporary communication token transmitted by the mobile APP during the network configuration phase. The smart hardware device receives the target MQTT account and password generated by the cloud service device based on the SN code registration, and the target MQTT server address sent by the cloud service device based on the IP address requested by the mobile phone. The device stores the above information in local flash and completes the identity binding with the cloud service device. The smart hardware device sends a connection request to the target MQTT server based on the pre-stored MQTT protocol parameters and the target MQTT server address, target MQTT account and password issued by the cloud service device, and completes authentication using the account and password; Receive user control commands sent by cloud service devices.

[0066] In one implementation, when the smart hardware device is not connected to the network (before entering the Wi-Fi promiscuous mode after power-on), it will provide its unique identifier (i.e., the SN code written during the production stage, such as "SN2024050001") to the mobile APP through a pre-set information transmission mechanism. After the device powers on and detects that it is not network-connected, it enters the Wi-Fi promiscuous mode and broadcasts a low-power Wi-Fi data frame containing its own serial number (SN) into the air according to preset rules (frame broadcast rules agreed upon with the mobile APP). This ensures that the mobile APP can capture the SN. After the mobile APP enables the network connection function, it is also in a listening state. It will filter out the SN data packet broadcast by the device from the Wi-Fi data frame in the air according to preset filtering rules (such as recognizing the frame header "0xAB-CD" and receiving the same data packet twice or more consecutively) to complete the SN acquisition. The device SN is a globally unique hardware identifier written during the production stage. There is no duplication. During the broadcast process, a check bit is carried with the data packet (generated according to the rule of "summing the data bytes and taking the remainder after dividing by 256 and taking the low-order bit", such as the remainder after summing the SN data segment). The mobile APP will verify this check bit to ensure that the acquired SN has not been tampered with.

[0067] The smart hardware device obtains the SSID and password of the target Wi-Fi network through Wi-Fi promiscuous mode. After switching to Station mode and successfully connecting to the target Wi-Fi network, it immediately initiates the authentication process with the cloud service device (TAO Cloud). The device reads two types of pre-stored core information from its local flash storage: a unique identifier SN code (e.g., "SN2024050001") and basic parameters of the cloud communication protocol (e.g., the default port 1883 for the MQTT protocol, the data exchange format JSON, and the basic encryption algorithm identifier AES-128). The device associates the SN code with a "temporary communication token" (extracted from the data packets broadcast by the mobile APP during the network configuration phase, such as "TMP-8A7B6C5D4E3F2G1H," which is generated by the mobile APP after obtaining the SN code and requesting it from the TAO Cloud, and broadcast to the device with the network configuration data frame). It then assembles the authentication request data packet according to the basic format of the MQTT protocol, ensuring that the request contains the binding relationship between the "device SN and temporary token." Based on the target Wi-Fi network, the device sends an authentication request to the TAO Cloud's preset authentication server address (such as "auth.taocloud.xxx", which is one of the pre-stored basic cloud communication parameters). During the sending process, the TCP protocol is used to ensure the reliability of data transmission and avoid request loss.

[0068] After receiving the device's authentication request, the TAO cloud server completes device registration and information distribution based on the SN code. The device receives and stores the relevant information, completing the identity binding with the cloud. TAO Cloud first verifies the legality of the SN code in the request (querying the database to confirm that the SN code belongs to a legitimate device already manufactured), and simultaneously verifies the validity of the temporary communication token (confirming that the token and SN code binding relationship has not expired and that it was applied for by a legitimate mobile app). After successful verification, it registers a unique MQTT account and password for the device (e.g., account "SN2024050001", password "PWD-7G6H5J4K", the account is associated with the SN code, and the password is randomly generated and encrypted). TAO Cloud parses the "mobile request IP" (e.g., US region IP "192.168.1.100") carried by the mobile app when applying for the temporary communication token, locates the device's region through the IP address, and then distributes the nearest MQTT server address in that region (e.g., "us-mqtt.taocloud.xxx" for the US region, avoiding cross-regional connection delays). The device receives the "target MQTT account password" and "target MQTT server address" sent by TAO Cloud, encrypts and stores the two types of information in the secure storage area of ​​local flash (stored in the same partition as the preset AES-128 decryption key to prevent information leakage), and updates the local status to "cloud identity binding completed" to avoid repeated binding process.

[0069] After the device completes identity binding, it starts the MQTT client and establishes a connection with the target MQTT server based on pre-stored parameters and information sent from the cloud, completing authentication. The device calls the local MQTT protocol stack, loads pre-stored basic MQTT parameters (such as default port 1883, heartbeat interval of 30 seconds, and 3 reconnection attempts), and imports the target MQTT server address (such as "us-mqtt.taocloud.xxx") and username and password ("SN2024050001" and "PWD-7G6H5J4K") sent from the cloud to complete the client configuration.

[0070] The device sends a CONNECT connection request to the target MQTT server, carrying the "client ID" (generated by combining the SN code and the device's MAC address to ensure uniqueness) and the MQTT account password. Upon receiving the request, the server verifies the validity of the account password (by comparing it with the information registered with TAO Cloud). If the verification is successful, it returns a CONNACK confirmation message, completing the connection authentication. After establishing an MQTT connection, the device sends PINGRESP heartbeat packets to the server at preset heartbeat intervals (30 seconds). If no PINGRESP response is received (e.g., due to network interruption), a reconnection mechanism is triggered—the connection request is resent. If the reconnection fails within 10 seconds, the device switches to a backup MQTT server address (e.g., "hk-mqtt.taocloud.xxx") and tries again, retrying a maximum of 3 times to ensure connection stability.

[0071] After establishing a stable connection with the TAO Cloud MQTT server, the device continuously listens for user control commands sent from the cloud and executes the corresponding operations, forming a control loop. Once connected to the MQTT server, the device automatically subscribes to a dedicated control topic assigned to it by TAO Cloud (e.g., "device / SN2024050001 / control"). This topic is used only to receive user control commands specific to the device (e.g., "turn on device" or "adjust parameters"), preventing command confusion.

[0072] When a user initiates a control request via the mobile app (such as "adjust the brightness of the smart light to 80%), TAO Cloud will encapsulate the request into an MQTT command message (JSON format, such as "{"cmd":"set_brightness","param":{"value":80}}) and push it to the control topic subscribed to by the device. After receiving the command, the device will verify the command format (whether it contains the "cmd" and "param" fields) and the command signature (generated by TAO Cloud based on the device's unique key, and verified by the device using a preset key) to ensure that the command is legal and executable. After the device verification command passes, the command is parsed into an operation that can be executed by the local hardware (e.g., for a smart light, it is parsed as "adjust the LED driver PWM signal to 80% duty cycle"). After execution, the current status of the device is collected (e.g., "brightness 80%" "operating normally"). The status is then encapsulated into a status feedback message according to a preset format and reported to the TAO cloud "status feedback topic" (e.g., "device / SN2024050001 / status") via MQTT connection, thus completing the command response closed loop.

[0073] like Figure 2 As shown, a smart hardware device network configuration device based on Wi-Fi promiscuous mode includes: an acquisition module 201, used to receive the Wi-Fi decryption rules agreed upon with the mobile APP and the instruction to automatically enter the Wi-Fi promiscuous mode when the device is powered on but not configured, generate the basic rules and mode setting information required for network configuration, and pre-store the device's unique identifier and the basic configuration parameters of the cloud communication protocol. Processing module 202 is used to receive all Wi-Fi data frames that conform to the supported frequency bands and are transmitted over the air in Wi-Fi promiscuous mode, and to filter and manage the received data frames according to preset Wi-Fi frame broadcast rules to select effective data packets, generating data packet information and decryption content information that conform to the agreed rules. The different data frame information includes various types of Wi-Fi data packets that the device needs to capture. It receives preset decryption rule instructions, processes the decryption content information corresponding to the data packet information that conforms to the agreed rules, extracts the payload, verifies the data packets according to verification rules, decrypts the target Wi-Fi SSID and password using the decryption rules, exits promiscuous mode and switches to Station mode, and generates decrypted network information and mode switching result information. The process involves several steps. First, the decryption rule instructions are generated from pre-defined rules agreed upon with the mobile app during device manufacturing. Second, the decrypted SSID and password information are processed based on network connection instructions to generate target Wi-Fi connection scenario information. Third, the target Wi-Fi connection scenario information, decrypted network information, and mode switching results are processed to generate operation information for connecting the device to the target router. Finally, based on preset network configuration requirements and the device's network connection target, the connection operation information is transformed into actual connection actions. This involves extracting and classifying the preset network configuration requirements, device network connection target, connection operation information, and target router attributes to generate network adaptation parameter information, connection scheduling rule information, network configuration permission verification information, and device-router association mapping information, enabling the device to successfully access the target Wi-Fi network.

[0074] A computing device includes a memory for storing computer program instructions and a processor for executing the computer program instructions, wherein when the computer program instructions are executed by the processor, the device is triggered to execute any of the smart hardware device network configuration methods based on Wi-Fi promiscuous mode.

[0075] The methods and / or embodiments in this application can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. When the computer program is executed by a processing unit, it performs the functions defined in the methods of this application.

[0076] It should be noted that the computer-readable medium described in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0077] It will be apparent to those skilled in the art that this application is not limited to the details of the exemplary embodiments described above, and that this application can be implemented in other specific forms without departing from the spirit or essential characteristics of this application.

Claims

1. A method for Wi-Fi hybrid mode-based smart hardware device network configuration, applied to a smart hardware device, and characterized in that, The application relates to a Wi-Fi connection method and device. Receiving preset Wi-Fi decryption rules agreed with a mobile phone APP and instructions for entering a Wi-Fi mixed mode based on preset operations when not being configured with a network after power-on, generating basic rules and mode setting information required for network configuration, pre-storing a unique device identifier and basic configuration parameters of a cloud communication protocol, laying a foundation for subsequent transmission of network configuration information and interaction with the cloud; Receiving all Wi-Fi data frames in a supported frequency band in a Wi-Fi mixed mode, filtering and managing the received data frames according to preset Wi-Fi frame broadcast rules and performing effective data packet screening processing, generating data packet information and to-be-decrypted content information in accordance with the agreed rules, wherein different data frame information includes various Wi-Fi data packets that need to be captured by the device; Receiving preset decryption rule instructions, processing the to-be-decrypted content information corresponding to the data packet information in accordance with the agreed rules, extracting a payload part, checking the data packet according to a checking rule, decrypting the target Wi-Fi SSID and password by using the decryption rule, exiting the mixed mode and switching to a station mode, and generating network information after decryption and mode switching result information; Processing the decrypted SSID and password information based on network connection instructions to generate target Wi-Fi connection scene information; Processing the target Wi-Fi connection scene information, the network information after decryption and the mode switching result information to generate operation information of the device connecting a target router; Based on preset network configuration requirement information and a device networking target, the connection operation information is converted into actual connection actions, and preset network configuration requirement information, device networking target, connection operation information and target router attributes are extracted and classified to generate network adaptation parameter information, connection scheduling rule information, network configuration permission verification information and device and router association mapping information, so that the device can be efficiently transmitted with the router to connect data and successfully access the target Wi-Fi network.

2. The Wi-Fi hybrid mode based smart hardware device network configuration method according to claim 1, characterized in that, Receiving all Wi-Fi data frames in a supported frequency band in a Wi-Fi mixed mode, filtering and managing the received data frames according to preset Wi-Fi frame broadcast rules and performing effective data packet screening processing, generating data packet information and to-be-decrypted content information in accordance with the agreed rules, including: Grouping and classifying all Wi-Fi data frames in a supported frequency band received in a Wi-Fi mixed mode according to preset Wi-Fi frame broadcast rules to generate data sources and associated data frame information corresponding to each rule; Arranging and designing effective data packet screening contents of the grouped data frames based on filtering requirements to obtain screening standards, data packet types and extraction range information and generate data packet screening design information; According to network configuration planning and listening requirements, corresponding repeated broadcast confirmation nodes are set for the data packet screening design information of each rule to ensure that the captured data packet is the network configuration information broadcasted by the mobile phone APP; Processing the grouping management result, data packet screening design information and repeated broadcast confirmation nodes to generate data packet information and to-be-decrypted content information in accordance with the agreed rules, including rule grouping information, screening schemes and confirmation standards. 3.The Wi-Fi hybrid mode based smart hardware device network configuration method according to claim 1, wherein, Receiving the preset decryption rule instruction, processing the to-be-decrypted content information corresponding to the data packet information meeting the agreed rule, extracting the payload part, checking the data packet according to the check rule, decrypting to obtain the SSID and password of the target Wi-Fi using the decryption rule, exiting the mixed mode and switching to the Station mode, generating the decrypted network information and mode switching result information, including: Receiving the preset decryption rule and check rule instructions agreed with the mobile phone APP and the processing instructions for the data packet information meeting the agreed rule, generating the processing requirement information of the to-be-decrypted content; Based on the check rule instruction and the processing instruction, the to-be-decrypted content information corresponding to the data packet information meeting the agreed rule is executed for targeted processing, the payload part is obtained through extraction operation, the check bit is calculated and the consistency of the high-order byte and the low-order byte is confirmed, the low-order check is taken, the data packet check is completed, the SSID and password of the target Wi-Fi are decrypted based on the decryption rule, the mode switching operation is executed to exit the mixed mode and switch to the Station mode, and the processed network information and mode switching result elements are generated; The processed network information and mode switching result elements are cooperatively optimized to ensure information accuracy and mode switching effectiveness; Integrating the processing and optimization results, generating the decrypted network information and mode switching result information containing the complete decrypted network information and mode switching result.

4. The Wi-Fi hybrid mode based smart hardware device network configuration method according to claim 1, characterized in that, Based on the network connection instruction, the decrypted SSID and password information are processed to generate the target Wi-Fi connection scene information, including: Based on the network connection instruction, the decrypted SSID and password information is obtained, the format integrity, character validity and encryption consistency characteristics of the information are extracted; The format integrity characteristics are checked to identify the format error and missing anomaly of the SSID and password, and the information integrity parameter is generated; The character validity characteristics are verified to check whether illegal characters or length limit are included, and the character compliance factor is generated; The encryption consistency characteristics are checked to confirm the matching of the decryption result and the preset encryption rule, and the encryption matching coefficient is generated; Based on the preset connection preparation rule, the information integrity parameter, the character compliance factor and the encryption matching coefficient are processed, the information structure is perfected using the format repair mechanism, the invalid content is removed using the character filtering technology, and the decryption effectiveness is confirmed using the encryption check algorithm, and the connection preparation result is generated; Integrating the connection preparation result, the target Wi-Fi connection scene information meeting the Wi-Fi access conditions is generated.

5. The Wi-Fi hybrid mode based smart hardware device network configuration method according to claim 4, characterized in that, Processing the target Wi-Fi connection scene information and the decrypted network information and mode switching result information, generating the operation information of the device connecting the target router, including: Multi-dimensional feature extraction is performed on the target Wi-Fi connection scene information, the decrypted network information and the mode switching result information, the adaptation parameters of the connection scene, the effectiveness parameters of the network information, the state parameters of the mode switching and the device working mode attributes are identified, and the to-be-processed feature set containing the scene adaptation features, the network effective features and the mode state features is generated; The feature set is cooperatively processed based on a preset connection execution rule, the connection scene and network information are adapted through a network parameter matching algorithm, the mode switching effectiveness is confirmed using a mode state verification technology, the operation steps are coordinated using a connection timing planning tool, and a connection processing result and evaluation information covering scene matching degree and mode effectiveness are generated; According to the evaluation information, targeted optimization is performed, parameter adjustment mechanism is used to process scene mismatch, state reset algorithm is used to correct mode switching exception, and decryption operation is performed again for invalid network information, generating optimized connection content with high adaptability and stable state; Integrate the optimized connection content, and perform final parameter verification according to the real-time and stability requirements of the device networking target to generate operation information of the device connection target router including connection steps, verification mechanism and exception handling scheme. 6.The Wi-Fi hybrid mode based smart hardware device network configuration method according to claim 1, wherein, Based on the preset network deployment requirement information and the device networking target, the connection operation information is converted into actual connection actions, and the preset network deployment requirement information, the device networking target, the connection operation information and the target router attribute are extracted and classified to generate network adaptation parameter information, connection scheduling rule information, network deployment permission verification information and device and router association mapping information, so that the device successfully accesses the target Wi-Fi network, including: Based on the preset network deployment requirement information and the device networking target, the connection operation information is processed, and a timing execution mechanism is used to convert it into actual connection actions, a parameter matching and verification combined processing module is used to adapt the target router attribute, and the preset network deployment requirement information, the device networking target, the connection operation information and the target router attribute are extracted and processed according to the classification rules to generate network adaptation parameter information, connection scheduling rule information, network deployment permission verification information, device and router association mapping information and connection state evaluation information; According to the connection state evaluation information, the generated various information is checked in multiple dimensions, a retry mechanism is started for connection timeout, a dynamic adjustment service is called for parameter secondary adaptation for parameter mismatched devices, and a credential update process is triggered for devices with failed permission verification to generate an optimized connection scheme including exception handling strategy and retry time window; The optimized connection scheme is integrated and executed, the connection operation instruction is responded, and the final connection result of the device successfully accessing the target Wi-Fi network is generated. 7.The Wi-Fi hybrid mode based smart hardware device provisioning method according to claim 1, wherein, The method further includes: In the network deployment stage, the smart hardware device provides its pre-stored unique identifier to the mobile phone APP for the mobile phone APP to obtain; After the smart hardware device accesses the target Wi-Fi network, the local pre-stored SN code and cloud communication protocol basic parameters are read, an identity verification request is sent to the cloud service device, and the SN code and the temporary communication token passed by the mobile phone APP in the network deployment stage are carried in the request; The smart hardware device receives the target MQTT account password generated by the cloud service device based on the SN code registration, and the target MQTT server address issued by the cloud service device according to the mobile phone request IP, stores the above information to the local flash, and completes the identity binding with the cloud service device; The intelligent hardware device sends a connection request to a target MQTT server based on pre-stored MQTT protocol parameters and a target MQTT server address, a target MQTT account password issued by the cloud service device, and completes authentication using the account password. The user control instruction sent by the cloud service device is received.

8. A Wi-Fi hybrid mode based smart hardware device provisioning apparatus, comprising: The device comprises: The acquisition module is configured to receive a preset Wi-Fi decryption rule agreed with a mobile phone APP, and an instruction for entering a Wi-Fi mixed mode based on a preset operation when the device is powered on and not configured, to generate basic rules and mode setting information required for network configuration, and to pre-store a device unique identifier and basic configuration parameters of a cloud communication protocol. The processing module is configured to receive all Wi-Fi data frames conforming to a supported frequency band in a Wi-Fi mixed mode, filter and manage the received data frames according to a preset Wi-Fi frame broadcast rule, and perform effective packet screening processing to generate data packet information and decryption content information conforming to the agreed rule, wherein different data frame information includes various Wi-Fi data packets that the device needs to capture; receive a preset decryption rule instruction, process the decryption content information corresponding to the data packet information conforming to the agreed rule, extract a payload part, verify the data packet according to a verification rule, decrypt the data packet using the decryption rule to obtain a target Wi-Fi SSID and password, exit the mixed mode and switch to a Station mode, and generate decrypted network information and mode switching result information, wherein the decryption rule instruction is generated based on rule information agreed with the mobile phone APP when the device is produced; process the decrypted SSID and password information based on a network connection instruction to generate target Wi-Fi connection scene information; process the target Wi-Fi connection scene information, the decrypted network information, and the mode switching result information to generate device connection operation information for a target router; and convert the connection operation information into actual connection actions based on preset network configuration requirement information and a device networking target, extract and classify the preset network configuration requirement information, the device networking target, the connection operation information, and target router attributes to generate network adaptation parameter information, connection scheduling rule information, network configuration permission verification information, and device and router association mapping information, so that the device successfully accesses a target Wi-Fi network.

9. An electronic device, comprising: It comprises: a first processor; and a memory for storing executable instructions of the first processor; wherein the first processor is configured to execute the executable instructions to perform the network configuration method of the intelligent hardware device based on the Wi-Fi mixed mode according to any one of claims 1-7.

10. A computing device, the device comprising a memory for storing computer program instructions and a processor for executing the computer program instructions, wherein, When the computer program instructions are executed by the processor, the device is triggered to perform the network configuration method of the intelligent hardware device based on the Wi-Fi mixed mode according to any one of claims 1-7.

Images