Device access method and electronic device

Abstract

This application provides a device access method and electronic device, relating to the field of terminal technology. The method includes: a STA device sending an authentication request to an AP device; a first driver in the AP device sending the authentication request to a first process and starting a first timer; if the first driver receives an indication message from the first process before the first timer expires, the first driver sends the indication message to the STA, instructing the STA device to initiate access to the AP device after a waiting period. After receiving the indication message and waiting for the specified period, the STA device initiates access to the AP device. This instructs the STA device to promptly initiate access to the AP device when the AP device can process the authentication response, thereby shortening the network access time for the STA device.

Description

Technical Field

[0001] This application relates to the field of terminal technology, and in particular to device access methods and electronic devices. Background Technology

[0002] In a wireless local area network (WLAN), a station (STA) can connect to an Ethernet network by connecting to a wireless access point (AP) to perform related communication services.

[0003] When multiple STAs connect to an AP simultaneously, authentication requests sent by the STAs to the AP may not be processed in a timely manner due to factors such as the AP's routing processing capabilities and internal anomalies. If a STA's authentication request goes unanswered, the STA may attempt to reconnect to the AP again after a considerable period, or it may simply blacklist the AP and prevent automatic reconnection.

[0004] Regardless of which implementation method is described above, it will result in a longer network access time for STA devices. Summary of the Invention

[0005] This application provides a device access method and electronic device, which are applied in the field of terminal technology and can effectively shorten the network access time of STA devices.

[0006] Firstly, embodiments of this application propose a device access method. Applied to an access point (AP) device, the AP device includes a first driver and a first process. The method includes:

[0007] The first driver receives the authentication request sent by the STA device at the receiving station;

[0008] The first driver sends an authentication request to the first process and starts the first timer;

[0009] If the first driver receives the indication information sent by the first process before the first timer expires, the first driver sends the indication information to the STA, which instructs the STA device to initiate access to the AP device after the waiting time.

[0010] In this implementation, when the AP device determines that it cannot process the authentication request, it informs the STA device via an indication message to initiate access after a specified waiting period. This waiting period is determined by the AP device, thus ensuring accuracy. This allows the STA device to promptly initiate access when the AP device is able to process the authentication request, effectively reducing the network access time for the STA device.

[0011] In one possible implementation, before the first driver receives the instruction information sent by the first process, the method further includes:

[0012] If the first process receives an authentication request, it discards the authentication request based on the AP device's device capability information and / or the first process's process status information.

[0013] The first process determines the waiting time based on device capability information and / or process status information;

[0014] The first process generates an instruction message based on the waiting time.

[0015] In this implementation, the first process determines whether it can process the authentication request based on device capability information and / or process status information. If it determines that it cannot be processed, the authentication request is discarded, thus determining the waiting time and generating indication information. This ensures the rationality of discarding the authentication request. Furthermore, determining the waiting time using device capability information and / or process status information effectively guarantees the accuracy of informing the STA of the device's waiting time.

[0016] In one possible implementation, the device capability information includes at least one of the following: CPU idle rate and a first quantity, wherein the first quantity is the number of STA devices connected to the AP device;

[0017] The process status information includes at least one of the following: the number of messages in the message queue of the first process and the exception reference information, which is used to indicate whether there is an exception in the first process.

[0018] In one possible implementation, the first process discards the authentication request based on the AP device's device capability information and / or the first process's process state information, including:

[0019] If the device capability information and / or process status information meet at least one of the following conditions: CPU idle rate is less than idle rate threshold, first quantity is greater than or equal to first quantity threshold, message quantity is greater than or equal to second quantity threshold, and abnormal reference information indicates that the first process is abnormal, then the first process discards the authentication request.

[0020] In this implementation, device capability information and / or process status information are compared with corresponding thresholds to determine whether the authentication request can be processed. The authentication request is discarded only when the corresponding threshold condition for discarding is met, thus ensuring that the first process only discards the authentication request when it is truly unable to process it.

[0021] In one possible implementation, after the first process discards the authentication request based on the AP device's device capability information and / or the first process's process state information, the method further includes:

[0022] The first process determines the cause of the anomaly based on the device capability information and / or process status information. The cause of the anomaly is used to indicate why the AP device did not send an authentication response to the STA device.

[0023] The indication information also includes the reason for the abnormality.

[0024] In this implementation, by including the reason for the exception in the indication information, the STA device can be informed why it did not send an authentication response, thereby avoiding unnecessary power consumption caused by the STA device performing a self-check.

[0025] In one possible implementation, the waiting time is determined as follows:

[0026] When the exception reference information indicates that the first process does not have an exception, the waiting time is inversely proportional to the CPU idle rate, and the waiting time is directly proportional to the first quantity, and the waiting time is directly proportional to the number of messages, or...

[0027] When the exception reference information indicates that there is an exception in the first process, the waiting time is the time taken to restart the first process.

[0028] In this implementation, by pre-setting the ratio between the waiting time and the corresponding parameters, the accuracy of informing the STA device of the waiting time can be effectively improved.

[0029] In one possible implementation, before the first driver receives the instruction information sent by the first process, the method further includes:

[0030] If the first driver does not receive the response message sent by the first process after the first timer expires, the first driver determines the waiting time based on the device capability information of the AP device. The response message includes an authentication response and indication information.

[0031] The first driver generates indication information based on the waiting time.

[0032] In this implementation, if the first timer times out and the first driver still has not received the response information sent by the first process, the first process determines the waiting time and generates an indication message. This can prevent the access process from being unable to continue when the first process is unable to send the response information, thus avoiding a long waiting time and a longer network access time for the STA device.

[0033] In other words, the purpose of setting the first timer in this application is also to shorten the network access time of the STA device. If the first driver has not received the response sent by the first process when the first timer expires, the first driver will proceed to the next step of the process.

[0034] In one possible implementation, the device capability information includes at least one of the following: CPU idle rate and a first number of STA devices connected to the AP device;

[0035] Among them, the waiting time is inversely proportional to the CPU idle rate, and the waiting time is directly proportional to the first quantity.

[0036] In one possible implementation, the method also includes:

[0037] The first driver determines the cause of the anomaly based on the device capability information. The cause of the anomaly is used to indicate why the AP device did not send an authentication response to the STA device.

[0038] The indication information also includes the reason for the abnormality.

[0039] Secondly, embodiments of this application propose a device access method. Applied to STA devices, the method includes:

[0040] Send an authentication request to the AP device;

[0041] Receive indication information sent by the AP device. The indication information is used to instruct the STA device to initiate access to the AP device after waiting for a certain period of time.

[0042] After waiting for the specified time after receiving the instruction, initiate access to the AP device.

[0043] In one possible implementation, the indication information also includes an exception reason, which indicates why the AP device did not send an authentication response to the STA device.

[0044] Thirdly, embodiments of this application provide a device access device, which can be an electronic device, or a chip or chip system within an electronic device. The device access device may include a display unit and a processing unit. When the device access device is an electronic device, the display unit may be a display screen. The display unit is used to perform display steps to enable the electronic device to implement a device access method described in the first or second aspect. When the device access device is an electronic device, the processing unit may be a processor. The device access device may further include a storage unit, which may be a memory. The storage unit is used to store instructions, and the processing unit executes the instructions stored in the storage unit to enable the electronic device to implement a device access method described in the first or second aspect. When the device access device is a chip or chip system within an electronic device, the processing unit may be a processor. The processing unit executes the instructions stored in the storage unit to enable the electronic device to implement a device access method described in the first or second aspect. The storage unit may be a storage unit within the chip (e.g., a register, cache, etc.), or a storage unit located outside the chip within the electronic device (e.g., a read-only memory, random access memory, etc.).

[0045] Fourthly, embodiments of this application provide an electronic device including a processor and a memory, the memory for storing code instructions, and the processor for executing the code instructions to perform the methods described in the first or second aspect.

[0046] Fifthly, embodiments of this application provide a computer-readable storage medium storing a computer program or instructions that, when executed on a computer, cause the computer to perform the methods described in the first or second aspect.

[0047] In a sixth aspect, embodiments of this application provide a computer program product including a computer program, which, when run on a computer, causes the computer to perform the methods described in the first or second aspect.

[0048] In a seventh aspect, this application provides a chip or chip system including at least one processor and a communication interface. The communication interface and the at least one processor are interconnected via a circuit. The at least one processor is used to run computer programs or instructions to perform the methods described in the first or second aspect. The communication interface in the chip can be an input / output interface, pins, or circuits, etc.

[0049] In one possible implementation, the chip or chip system described above in this application further includes at least one memory storing instructions. The memory can be an internal storage unit of the chip, such as a register or cache, or it can be a storage unit of the chip itself (e.g., read-only memory, random access memory, etc.).

[0050] It should be understood that the second to seventh aspects of this application correspond to the technical solutions of the first aspect of this application, and the beneficial effects achieved by each aspect and the corresponding feasible implementation are similar, and will not be repeated here. Attached Figure Description

[0051] Figure 1 This is a schematic diagram of a communication scenario provided in an embodiment of this application;

[0052] Figure 2 Signaling interaction diagram of the access process provided in the embodiments of this application;

[0053] Figure 3 This is a schematic diagram of the software architecture of the AP device provided in the embodiments of this application;

[0054] Figure 4 Interaction flow of the device access method provided in the embodiments of this application Figure 1 ;

[0055] Figure 5 Interaction flow of the device access method provided in the embodiments of this application Figure 2 ;

[0056] Figure 6 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0057] To facilitate a clear description of the technical solutions in the embodiments of this application, some terms and technologies involved in the embodiments of this application will be briefly introduced below:

[0058] 1. BSS

[0059] A BSS (basic service set) is the most basic building block of a Wireless Local Area Network (WLAN). It refers to a network consisting of a group of wireless devices (which may include wireless network cards, wireless routers, etc.) that use the same wireless channel and connect through the same SSID (Service Set Identifier).

[0060] 2. PTK

[0061] PTK (pairwise transient key) is used for encrypting and decrypting unicast data frames.

[0062] 3. GTK

[0063] GTK (group temporal key) is used for encrypting and decrypting multicast and broadcast data frames, while management frames, control frames, and empty data frames do not need to be encrypted.

[0064] 4. Other terms

[0065] In the embodiments of this application, terms such as "first" and "second" are used to distinguish identical or similar items with substantially the same function and purpose. For example, "first chip" and "second chip" are used only to distinguish different chips and do not limit their order of execution. Those skilled in the art will understand that terms such as "first" and "second" do not limit the quantity or execution order, and that "first" and "second" do not necessarily imply that they are different.

[0066] It should be noted that, in the embodiments of this application, the terms "exemplary" or "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design scheme described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0067] In this application embodiment, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can represent: a, b, c, ab, a--c, bc, or abc, where a, b, and c can be single or multiple.

[0068] 5. Electronic equipment

[0069] The electronic devices in this application embodiment may include handheld devices, vehicle-mounted devices, etc., with network access capabilities. For example, some electronic devices include: mobile phones, tablets, PDAs, laptops, mobile internet devices (MIDs), wearable devices, virtual reality (VR) devices, augmented reality (AR) devices, wireless terminals in industrial control, wireless terminals in self-driving vehicles, wireless terminals in remote medical surgery, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, wireless terminals in smart homes, cellular phones, cordless phones, session initiation protocol (SIP) phones, wireless local loop (WLL) stations, personal digital assistants (PDAs), handheld devices with wireless communication capabilities, computing devices or other processing devices connected to a wireless modem, in-vehicle devices, wearable devices, terminal devices in 5G networks, or future evolution of public land mobile communication networks. Terminal devices in a network (PLMN), etc., are not limited to this in the embodiments of this application.

[0070] The electronic devices in the embodiments of this application may also be referred to as: terminal equipment, user equipment (UE), mobile station (MS), mobile terminal (MT), access terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, terminal, wireless communication equipment, user agent, or user device, etc.

[0071] In this embodiment, the electronic device may include an AP device and a STA device. The specific examples of the electronic devices described above can serve as AP devices or STA devices in this embodiment.

[0072] To better understand the technical solution of this application, the relevant technologies involved in this application will be further described in detail below.

[0073] First, combine Figure 1 The application scenarios of this application are described. Figure 1 This is a schematic diagram of a communication scenario provided in an embodiment of this application. (Refer to...) Figure 1 In this communication scenario, one end is an AP device and the other end is a STA device.

[0074] An Access Point (AP) is the creator of a wireless network and its central node. A typical wireless router used in a home or office is an AP. More specifically, an AP can be understood as an access point for mobile users to enter a wired network. It is mainly deployed in homes, buildings, and campuses, with a typical coverage radius of tens to hundreds of meters; it can also be deployed outdoors. An AP acts as a bridge connecting wired and wireless networks, its main function being to connect various wireless network clients together and then connect the wireless network to the Ethernet. Specifically, an AP can be a terminal device or network device with a wireless fidelity (WiFi) chip.

[0075] In this context, STA refers to a device connected to a wireless network. Each device connected to an AP is considered a station. Communication between stations in a wireless network occurs through the AP. For example, STA can be a wireless communication chip, a wireless sensor, or a wireless communication terminal. Examples include mobile phones, tablets, set-top boxes, smart TVs, smart wearable devices, in-vehicle communication devices, and computers that support WiFi communication.

[0076] In this communication system, the STA can also be referred to as an access terminal, user equipment, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, terminal, wireless communication equipment, user agent, or user device. User equipment can be a cellular phone, cordless phone, Session Initiation Protocol (SIP) phone, Wireless Local Loop (WLL) station, Personal Digital Assistant (PDA), handheld device with wireless communication capabilities, computing device, or other processing device connected to a wireless modem, in-vehicle device, wearable device, and user equipment in a 5G network, etc. As an example and not a limitation, in this embodiment, the STA device can also be a wearable device. Wearable devices can also be called wearable smart devices.

[0077] The relationship between an Access Point (AP) and a Single Target (STA) is that the AP provides the opportunity for wireless access to the network, while the STA is the actual device that connects to the network through the AP. The communication range of a STA is determined by the coverage area of ​​the AP; only STAs within the AP's coverage area can connect to the network.

[0078] In actual implementation, the specific implementation methods of AP devices and STA devices can be selected according to actual needs. This embodiment does not impose any restrictions on this, as long as the AP device can be used as an access point and the STA device can be used as a site.

[0079] Based on the above introduction, the following will further combine... Figure 2 The interaction process of STA devices connecting to AP devices is described in further detail. Figure 2 This is a signaling interaction diagram of the access process provided in an embodiment of this application.

[0080] like Figure 2 As shown, the access process includes:

[0081] 1. The STA device sends a probe request to the AP device.

[0082] The STA device will send probe request frames via broadcast to detect the surrounding BSS.

[0083] 2. The AP device sends a probe response to the STA device.

[0084] After receiving a probe request, the AP device can send a probe response frame to the STA device. The probe response frame may include, for example, the device information of the AP device, so that the STA device can perform authentication and connection based on the device information.

[0085] Device information may include, for example, SSID, MAC (Media Access Control Address), encryption method, etc.

[0086] 3. The STA device sends an authentication request to the AP device.

[0087] After receiving the probe response from the AP device, the STA device can enter the authentication phase. During the authentication phase, the STA device can send an authentication request frame to the AP device. The authentication request is used to request the AP device to authenticate the STA device, and may also include the STA device's capability information to facilitate capability negotiation between the STA device and the AP device.

[0088] 4. The AP device sends an authentication response to the STA device.

[0089] The AP device authenticates the STA device based on the authentication request sent by the STA device, and then the AP device sends an authentication response frame to the STA device.

[0090] If authentication of the STA device is successful, the authentication response frame indicates successful authentication, meaning the AP device can access the same STA device. If authentication fails, the authentication response frame indicates authentication failure, meaning the AP device refuses access to the STA device.

[0091] In addition, the authentication response can also include the capability information of the AP device to enable capability negotiation between the STA device and the AP device.

[0092] 5. The STA device sends an association request to the AP device.

[0093] After the STA device discovers the AP device and authenticates its identity, the STA device can send an association request frame to the AP device. The association request frame is used to request association with the AP device.

[0094] 6. The AP device sends an association response to the STA device.

[0095] In response to the association request frame, the AP device sends an association response frame to the STA device. The association response frame is used to indicate whether the AP device and the STA device have successfully associated.

[0096] 7. The AP device and the STA device perform a four-way handshake.

[0097] After the AP and STA devices successfully associate, they will further perform an EAPOL (Extensible Authentication Protocol over LAN) four-way handshake. The purpose of this four-way handshake is to calculate the PTK and GTK keys used for subsequent data encryption. Furthermore, the four-way handshake is a key exchange process; it does not directly transmit the password but rather exchanges messages via EAPOL.

[0098] The following is an example illustrating the specific process of the EAPOL four-way handshake:

[0099] 7.1 The AP device sends message 1 (or message a) to the STA device.

[0100] Message 1 may include an annonce generated by AP.

[0101] 7.2 The STA device sends message 2 (or message b) to the AP device.

[0102] After receiving message 1, the STA device can generate a random number (Snonce). Then, the STA device combines the Anonce and the Snonce to generate the AMIC (AP Messages Integrity Check) value, and sends the Snonce and AMIC to the AP through message 2.

[0103] At the same time, the STA device will generate a PTK.

[0104] 7.3 The AP device sends message 3 (or message c) to the STA device.

[0105] After receiving message 2 as described above, the AP can calculate the PTK and MIC, and after successful verification, send the encrypted GTK to the STA via message 3.

[0106] 7.4 The STA device sends message 4 (or message d) to the AP device.

[0107] After receiving message 3, the STA can install GTK and PTK, and reply with an acknowledgment message (ack) to the AP device via message 4. The AP device will also install GTK and PTK.

[0108] 8. The STA device sends a DHCP discovery message to the AP device.

[0109] After the four-way handshake is completed, the AP device and STA device can perform DHCP (Dynamic Host Configuration Protocol) related processing.

[0110] First, the STA device can broadcast a DHCP discover message to the AP device.

[0111] 9. The AP device sends a DHCP offer to the STA device.

[0112] After receiving the DHCP Discover message, the AP device can select an IP address according to the priority of IP address allocation and send it along with other parameters to the STA device via a DHCP Offer message.

[0113] 10. The STA device sends a DHCP request to the AP device.

[0114] For an STA device, it may receive multiple DHCP offer messages. The STA device can select one of the IP addresses corresponding to the multiple DHCP offer messages and send a DHCP request message in a broadcast manner. This message contains the IP address assigned by the DHCP server in the DHCP offer message.

[0115] 11. The AP device sends a DHCP confirmation to the STA device.

[0116] After receiving a DHCP request message from a STA device, if the AP device is certain that it will assign the IP address indicated in the DHCP request message to the STA device, it will return a DHCP ACK message. At this point, the STA device will be assigned an IP address and can access the network.

[0117] Based on the above introduction, the following will further combine... Figure 3 Based on the software architecture of the AP device, the specific implementation of the authentication process will be further described in detail. Figure 3 This is a schematic diagram of the software architecture of the AP device provided in the embodiments of this application.

[0118] like Figure 3 As shown, the software architecture includes: application layer, business layer, HAL (Hardware Abstraction Layer), and kernel layer.

[0119] The application layer can include, for example, a routing WebUI (website user interface) and a routing web app. Users can configure the AP device or enter relevant control commands through the routing WebUI or the routing web app.

[0120] The business layer provides support for business processing. For example, the business layer may include modules such as routing protocols, plug-in platforms, device management, privacy and security, AP management, and STA management.

[0121] The HAL layer encapsulates kernel drivers, providing interfaces to higher-level components and shielding them from the implementation details of lower-level hardware. For example... Figure 3 As shown, the HAL layer includes the kernel HAL and hostapd (Host Access Point Daemon). hostapd is a user-space daemon used for APs and authentication servers, implementing related access management.

[0122] The driver layer includes various drivers, such as those that can be... Figure 3 The diagram shows a network card driver and an access point (AP) driver, where the AP driver can also be called a Wi-Fi driver. Furthermore, the driver layer may also include general-purpose drivers such as USB drivers and memory drivers, input / output drivers such as LED drivers and button drivers, network card drivers, and other drivers. This embodiment does not limit the specific driver content included in the driver layer.

[0123] Based on the software architecture described above, during the authentication phase between the STA and AP devices, the STA device sends an authentication request to the AP device. (Refer to...) Figure 3 For example, the authentication request can be received by the AP driver in the AP device.

[0124] After receiving an authentication request, the AP driver can perform preliminary authentication of the STA device based on relevant information. If the preliminary authentication is successful, such as... Figure 3 As shown, the AP driver can send this authentication request to hostapd so that hostapd can perform further authentication of the STA device.

[0125] If hostapd also passes authentication, for example, hostapd can send an authentication response to the AP driver, and then the AP driver will send the authentication response to the STA device to complete the authentication process.

[0126] The above describes the successful authentication scenario. However, in some abnormal situations, after the AP driver sends an authentication request to hostapd, if hostapd is unable to process the authentication request due to some issues, the AP driver may not receive the authentication response from hostapd. Consequently, the AP driver will also be unable to send an authentication response to the STA device.

[0127] Here are some examples illustrating several situations where hostapd fails to process authentication requests:

[0128] Scenario 1: hostapd is busy

[0129] For example, in scenarios where the AP device restarts or powers on again after a power outage, STA devices that previously established a connection with the AP device may simultaneously send reconnection requests to the AP device. This could result in a large number of STA devices simultaneously connecting to the AP device.

[0130] During the STA device access process, the STA device will perform the detection and authentication processes described above. Since the access of multiple STA devices is performed in parallel, hostapd may receive a large number of authentication requests during the authentication phase.

[0131] When the number of authentication request messages exceeds the limit that hostapd can handle, hostapd may choose to discard some of the authentication request messages. In this case, hostapd may be unable to process the authentication requests.

[0132] Scenario 2: AP driver busy

[0133] In the same scenario as above, during the authentication phase, the AP driver may receive a large number of authentication requests. After receiving the authentication requests, the AP driver will forward them to hostapd.

[0134] However, because the number of authentication requests forwarded at the same time is too large, some authentication requests may not be successfully sent to hostapd, and hostapd will naturally be unable to process these authentication requests.

[0135] In practical implementation, scenarios where hostapd and AP driver are busy are not limited to the AP device power-on scenario described above, and therefore involve a large number of STA devices reconnecting. In any scalable scenario, the AP device may receive a large number of authentication requests sent concurrently by STA devices, leading to hostapd and AP driver busyness. The technical solution described in this application can be applied to any scenario causing hostapd and AP driver busyness.

[0136] Scenario 3: HostAPD internal error

[0137] If hostapd encounters an internal exception and receives an authentication request, it will not send an authentication response because it is temporarily unable to process the request due to the internal exception.

[0138] Regardless of the specific scenario described above, after the AP driver sends an authentication request to hostapd, it fails to receive an authentication response from hostapd. Consequently, the AP driver is also unable to send an authentication response to the STA device.

[0139] For STA devices, during the authentication phase, if they do not receive an authentication response from AP devices after sending an authentication request, they may try to send another authentication request to AP devices. However, based on the various possible scenarios described above, hostapd may still be unable to process the authentication request sent by the STA device again.

[0140] If the STA device sends authentication requests multiple times but never receives an authentication response from the AP device, for example, if the STA device determines that the access process has exceeded a certain time limit, meaning the access process has timed out, then the STA device will determine that the access process has failed.

[0141] Because current chip or protocol designs do not include timeout handling mechanisms for STA devices, there are no detailed constraints on the subsequent behavior of STA devices when they send authentication requests multiple times but still fail to access the device.

[0142] For power consumption reasons, most manufacturers typically configure STA devices to enter an exception handling process after determining a connection failure. This exception handling process may include the following:

[0143] The first approach is for the STA device to attempt to reconnect to the AP device again after a pre-set initial duration, meaning it will repeat the access process described above. This initial duration is not fixed and depends on the individual STA device's settings; for example, the initial duration may differ between STA devices from different manufacturers.

[0144] The second approach is for the STA device to blacklist the AP device. If authentication fails, the STA device determines that the AP device is temporarily unavailable. If the STA device attempts to connect multiple times, it may still fail. Therefore, for power consumption reasons, the STA device can blacklist the AP device to avoid multiple unproductive reconnections and excessive power consumption.

[0145] After the STA device adds the AP device to the blacklist, the STA device will no longer automatically connect to the AP device. If the user wants to connect to the AP device later, the user will need to manually connect it on the STA device.

[0146] Regarding the two abnormal handling procedures for STA devices described above, whether the STA device attempts to reconnect again after the first set of time, or the STA device adds the AP device to the blacklist and then the user manually connects and reconnects, both will cause the STA device to spend a certain amount of time accessing the network.

[0147] However, the situations described above where hostapd cannot handle authentication requests may actually be alleviated in the short term. Even when hostapd can handle authentication requests, based on the STA's exception handling process described above, the STA device will still not initiate a reconnection to the AP device. This results in the STA device failing to connect in a timely manner when a connection is possible, leading to a longer network access time for the STA device.

[0148] To address the aforementioned technical issues, this application proposes the following technical concept: The reason why the STA device continues to wait for reconnection or directly abandons reconnection even when hostapd can process the authentication request is because the STA device is unsure why the AP device has not responded with an authentication response, nor when it will receive a response after sending another authentication request. The AP device, however, can determine the specific reason for its inability to respond with an authentication response and can estimate when its problem will be resolved. Therefore, when hostapd cannot respond with an authentication response, the AP device can send an instruction message to the STA device to inform it of the current situation and / or instruct the STA device to attempt reconnection again after a specified time. This ensures that the STA device can reconnect promptly when hostapd can process the authentication response, thereby shortening the STA's network connection latency.

[0149] Based on this, the device access method provided in this application will be described in detail below with reference to specific embodiments. As can be seen from the above description of the embodiments, there may be various situations that cause hostapd to be unable to process authentication requests.

[0150] Among them, Situations 1 and 3 described above can be classified into one type, in which hostapd receives the authentication request, but hostapd cannot process it, so the AP driver will not receive the authentication response sent by hostapd.

[0151] The scenario 2 described above can be categorized as another type, in which hostapd does not receive the authentication request sent by the AP driver, and therefore the AP driver will naturally not receive the authentication response sent by hostapd.

[0152] The implementation methods for device access in these two scenarios will be described below.

[0153] First, combine Figure 4 The first type mentioned above, namely the types corresponding to cases 1 and 3, will be introduced. Figure 4 Interaction flow of the device access method provided in the embodiments of this application Figure 1 .

[0154] like Figure 4 As shown, the method includes:

[0155] S401, the STA device sends a probe request to the AP driver.

[0156] S402, AP driver sends probe response to SAT device.

[0157] The specific implementation of the probe request and probe response can be referred to the description in the above embodiments, and will not be repeated here.

[0158] Furthermore, it should be noted that the AP device in this application includes a first driver and a first process. The first driver can be, for example, an AP driver, but is not limited to this implementation. Any driver used to process authentication requests from STA devices can be understood as the first driver in this embodiment. For example, the AP driver in this embodiment can also be understood as a Wi-Fi chip.

[0159] Furthermore, the first process can be hostapd, but it is not limited to this implementation. Any process used to handle authentication requests from STA devices can be understood as the first process in this embodiment.

[0160] In this embodiment and the embodiments described below, the first driver is the AP driver and the first process is hostapd as an example. When the first driver and the first process are other implementations, they can be replaced accordingly.

[0161] S403, STA devices send authentication requests to the AP driver.

[0162] The implementation of authentication requests is similar to that described above, and will not be repeated here.

[0163] S404, the AP driver sends an authentication request to the daemon (hostapd).

[0164] exist Figure 4 In the example, hostapd is described as a daemon process. In fact, hostapd and daemon process are the same concept. In the following text, hostapd will be used as the description object for related introduction.

[0165] After receiving an authentication request, the AP driver can perform preliminary authentication of the STA device based on the information carried in the authentication request. If the preliminary authentication is successful, the AP driver sends an authentication request to hostapd so that hostapd can perform further authentication of the STA device.

[0166] S405, AP driver starts the first timer.

[0167] In one implementation, the AP driver can start the first timer immediately after sending the authentication request to hostapd. In another implementation, the AP driver can start the first timer simultaneously with sending the authentication request to hostapd.

[0168] In this embodiment, the function of the first timer is to set a preset duration. When the preset duration is reached from the start time of the first timer, it can be confirmed that the first timer has timed out.

[0169] S406, hostapd determines the cause of the error and the waiting time.

[0170] After receiving an authentication request from the AP driver, hostapd can determine whether there are sufficient resources to process the authentication request based on the AP device's capability information and / or the process status information of the first process (i.e., hostapd). If hostapd determines that it cannot process the authentication request, it can choose to discard it. Specifically, hostapd can choose not to add the authentication request to the message queue, thus discarding the authentication request.

[0171] The device capability information reflects the processing capabilities of the AP device. For example, the device capability information may include at least one of the following: CPU idle rate and a first quantity, where the first quantity is the number of STA devices connected to the AP device. The first quantity may consist of two parts: one part is the number of STA devices already connected to the AP device, and the other part is the number of STA devices currently performing the connection process with the AP device.

[0172] In actual implementation, the device capability information can be expanded according to actual needs. For example, the device capability information can also include CPU utilization, number of CPU cores, etc. Any information that reflects the processing capability of the AP device can be used as the device capability information in this embodiment.

[0173] Furthermore, process state information is used to reflect the state of the first process (i.e., hostapd). For example, process state information may include at least one of the following: the number of messages in the message queue of the first process, and exception reference information, wherein the exception reference information is used to indicate whether the first process has an exception. The first process can clearly determine whether it has an exception; therefore, when the first process has an exception, the exception reference information can indicate the exception.

[0174] In actual implementation, process status information can also be extended according to actual needs. For example, process status information can also include process priority, etc. Any information used to reflect the status of the first process can be used as process status information in this embodiment.

[0175] In one implementation, when hostapd determines whether there are sufficient resources to process the received authentication requests based on device capability information and / or process status information, for example, the following strategy can be adopted:

[0176] If the device capability information and / or process status information meet at least one of the following conditions: CPU idle rate is less than idle rate threshold, first quantity is greater than or equal to first quantity threshold, message quantity is greater than or equal to second quantity threshold, and abnormal reference information indicates that the first process is abnormal, then the first process determines that it does not have enough resources to process the authentication request, and therefore may choose to discard the authentication request.

[0177] For example, the idle rate threshold can be set to 20%, the first quantity threshold can be set to N% of the maximum number of STA devices supported by the AP device (N is a value greater than or equal to 0, for example, it can be set to 80%), and the second quantity threshold can be set to M, where M can be less than or equal to the maximum capacity of the message queue. In actual implementation, the specific implementation methods of the idle rate threshold, the first quantity threshold, and the second quantity threshold can be set according to actual needs.

[0178] The following example illustrates the following: The idle rate threshold is 20%, the first quantity threshold is 80% of the maximum quantity (assuming the maximum quantity is 50, then the first quantity threshold is 40), and the second quantity threshold is 40 (assuming the maximum message queue capacity is 50 messages). Several specific examples will be used to illustrate this further.

[0179] If the CPU idle rate of the AP device is 10%, the number of STA devices connected to the AP device is 30, and the number of messages in the message queue in hostapd is 45, then it can be determined that the current device capability information and / or process status information meet the conditions described above. Therefore, it can be determined that the current hostapd resources are insufficient to support the processing of the authentication request, so the authentication request can be dropped.

[0180] Alternatively, if the CPU idle rate of the AP device is 60%, the initial number of STA devices connected to the AP device is 30, and the number of messages in the message queue of hostapd is 20, then it can be determined that the current device capability information and / or process status information do not meet the conditions described above. Therefore, it can be determined that the current hostapd resources are sufficient to support the processing of the authentication request, and thus the authentication request can be processed normally. Afterwards, for example, an authentication response can be sent to the AP driver, and then the AP driver can send an authentication response to the STA device. This embodiment will not elaborate on this scenario of hostapd normally processing authentication requests.

[0181] In actual implementation, hostapd can select which device capability information and process status information to refer to for the discard decision based on actual needs. That is, it can select some parameters from the multiple parameters mentioned above, determine whether the corresponding conditions are met, and then discard the authentication request when the conditions are met.

[0182] Furthermore, when hostapd chooses to discard an authentication request, it can also determine the reason for the exception and the waiting time for that authentication request.

[0183] The exception reason is used to indicate why the AP device cannot process the authentication request. For example, if hostapd determines that the device capability information and / or process status information meet at least one of the following conditions: CPU idle rate is less than the idle rate threshold, a first quantity is greater than or equal to a first quantity threshold, and the number of messages is greater than or equal to a second quantity threshold, then the exception reason may be, for example, hostapd being busy or the AP device being busy (corresponding to case 1 described above).

[0184] Alternatively, if hostapd determines that the process status information satisfies the condition that the exception reference information indicates that the first process has an exception, then the reason for the exception could be, for example, that hostapd has an internal exception (corresponding to case 3 described above).

[0185] In actual implementation, the specific implementation of exception reasons can be set according to actual needs. Furthermore, hostapd may encounter other exceptions that prevent it from processing authentication requests. The corresponding exception reasons can be adaptively set according to the exception situations in hostapd, as long as the exception reason can indicate why hostapd cannot process the authentication request.

[0186] Furthermore, when hostapd is unable to process the authentication request, in this embodiment, hostapd will further estimate when it expects to be able to process the authentication request, and then determine a waiting time. This waiting time is used to instruct the STA device to access the AP device after the waiting time.

[0187] In this embodiment, the waiting time is the estimated time that hostapd can use to resolve any abnormal situations. Because hostapd estimates the waiting time based on its own actual situation, it can ensure that the STA device can access the AP device only after the waiting time has elapsed, and hostapd can process the authentication requests it sends.

[0188] The estimated wait time by hostapd will vary depending on the abnormal situation. The following is an example of how hostapd estimates the wait time under several abnormal situations:

[0189] In one implementation, when the exception reference information indicates that the first process does not have an exception, the waiting time is inversely proportional to the CPU idle rate, directly proportional to the first quantity, and directly proportional to the number of messages.

[0190] Specifically, a lower CPU idle rate indicates a busier AP device, and the longer it takes to alleviate the AP device's busyness, thus the waiting time is inversely proportional to the CPU idle rate. Similarly, a larger first quantity indicates a larger number of STAs currently connected to the AP device, resulting in a higher AP device busyness and a longer waiting time to alleviate the AP device's busyness, thus the waiting time is directly proportional to the first quantity. Furthermore, a larger message quantity indicates a larger number of messages that hostapd needs to process, resulting in a higher AP device busyness and a longer waiting time to alleviate the AP device's (or hostapd's) busyness, thus the waiting time is also directly proportional to the message quantity.

[0191] Specifically, when determining the first duration, the choice of which parameters among CPU idle rate, the first quantity, and the number of messages to refer to can be made based on actual needs. As described above, these parameters and the waiting duration all exhibit the proportional relationships described above. For example, a first preset function can be used to process at least one of the parameters—CPU idle rate, the first quantity, and the number of messages—to determine the first duration. In this first preset function, the first duration satisfies the corresponding proportional relationships with the parameters described above.

[0192] In another implementation, when the exception reference information indicates an exception in the first process, hostapd will typically restart itself to attempt to resolve the exception. Therefore, the waiting time can be set to the hostapd restart time. The hostapd restart time can be preset or estimated in real-time by hostapd.

[0193] It should also be noted that hostapd can execute operation S406 after receiving the authentication request from the AP driver. Furthermore, the AP driver can execute operation S405 after sending the authentication request to hostapd. Therefore, in this embodiment, the execution order of S405 and S406 can be determined based on the actual situation. It is possible that S405 is executed first, then S406; or S406 is executed first, then S405; or S405 and S406 are executed in parallel.

[0194] S407, hostapd sends instruction information to the AP driver.

[0195] The indication information includes the cause of the error and the waiting time. The specific implementation of the cause of the error and the waiting time has been described in detail above, and will not be repeated here.

[0196] S408, AP driver stops the first timer.

[0197] Based on the above description, it can be determined that the function of the first timer in this embodiment is to measure whether a response from hostapd has been received within a preset time period. Therefore, after the AP driver receives the indication information sent by hostapd, the first timer can be stopped.

[0198] S409, AP driver sends instruction information to STA device.

[0199] As described above, the indication information includes the reason for the error and the waiting time.

[0200] For STA devices, the reason for the error in the indication information is used to tell the STA device why it did not send an authentication response.

[0201] Furthermore, the waiting time in the instruction message instructs the STA device to initiate the access procedure only after the specified waiting time. Because the waiting time in the instruction message is determined by hostapd based on its actual settings, it ensures that the issue of hostapd being unable to send an authentication response after the STA device initiates the access procedure after the specified waiting time has been resolved. Therefore, hostapd and the AP can then send an authentication response to the terminal device. For example, the waiting time could be 3 seconds, 5 seconds, etc.

[0202] In one implementation, since hostapd is currently unable to handle the authentication request from the STA device, the AP driver can first send an authentication response to the STA device. This response informs the STA device that the current authentication request has been rejected. Furthermore, by adding the aforementioned indication information, the AP driver can further inform the STA device why its authentication request was rejected and instruct it on how long to wait before attempting to reconnect.

[0203] In this embodiment, the indication information can be carried in the authentication response sent by the AP driver, for example. Alternatively, the indication information and the authentication response can be two separate pieces of information. This embodiment does not limit the specific method of sending the indication information, and it can be selected according to actual needs.

[0204] S410. After the waiting period following the receipt of the instruction information, the STA device and the AP device perform the access process.

[0205] For the STA device, it can start timing from the moment it receives the indication information. After the waiting time expires, the STA device initiates an access request to the AP device, thereby performing an access process with the AP device. The detailed implementation of the access process can be referred to the above. Figure 2 The details of the embodiments will not be repeated here.

[0206] It is understood that the waiting time in this embodiment is the time determined by hostapd. Since hostapd can clearly know the specific situation of the AP device, the STA device can re-execute the access process after waiting for the specified time according to the instructions determined by hostapd, thus ensuring that both the AP driver and hostapd can complete their respective tasks.

[0207] This section further analyzes the implementation method described above, where the STA device attempts to reconnect with the AP device after a pre-set first duration. This first duration is actually a preset value set by the manufacturer for device power consumption and network connectivity purposes, and it is completely unrelated to the AP device's state. Furthermore, the STA device itself cannot determine the AP device's state. In traditional solutions, the STA device cannot even determine why it did not receive an authentication response from the AP device, and therefore cannot accurately predict when to reconnect and receive a response. Thus, the STA device will initiate a reconnection attempt with the AP device again after the first duration has elapsed.

[0208] In this embodiment, hostapd can clearly understand its current status and, based on device capability information and / or process status information, and referring to the implementation method described in this embodiment, can accurately estimate how long it will take for the problem to be resolved (e.g., the busy period is alleviated, or hostapd recovers from an abnormal state). Afterward, hostapd can process the authentication response normally. Therefore, the indication information sent by hostapd that tells the STA device the waiting time is very accurate.

[0209] Furthermore, in traditional solutions, manufacturers, for power-saving purposes, typically avoid allowing STA devices to reconnect too frequently. Therefore, the initial timeout is usually set relatively long, such as 5 minutes. However, the problem of hostapd being unable to handle authentication requests is usually resolved quickly, so the waiting time indicated by hostapd is usually short, such as a few seconds. Therefore, in one implementation, the waiting time in this embodiment is shorter than the initial timeout preset by the STA device, so that the STA device can connect to the AP device as quickly as possible after hostapd recovers, shortening the network connection time of the STA device.

[0210] It should also be noted that, normally, when a STA device sends an authentication request but does not receive an authentication response, the STA device may perform a series of self-checks to prevent similar problems from occurring in subsequent network access. For example, the STA device will check whether its authentication request has format errors, data anomalies, etc. However, in the application scenario of this application, the STA device's failure to receive an authentication response is not due to the STA device's fault, but rather because the AP device itself has certain anomalies.

[0211] Therefore, in this embodiment, the indication information sent by hostapd to the STA device also includes the reason for the error, which tells the STA device why it did not receive the authentication response. If the STA determines that the failure to receive the authentication response is due to a problem with the AP device based on the reason for the error, the STA device will not perform any further self-checks, thus saving power consumption caused by unnecessary actions by the STA device.

[0212] Next, let's combine... Figure 5 The second type mentioned above, that is, the type corresponding to case 2, will now be introduced. Figure 5 Interaction flow of the device access method provided in the embodiments of this application Figure 2 .

[0213] like Figure 5 As shown, the method includes:

[0214] S501 and STA devices send probe requests to the AP driver.

[0215] The S502 and AP drivers send probe responses to the SAT devices.

[0216] The S503 and STA devices send authentication requests to the AP driver.

[0217] The implementation of authentication requests is similar to that described above, and will not be repeated here.

[0218] S504, the AP driver sends an authentication request to the daemon (hostapd).

[0219] S505, AP driver starts the first timer.

[0220] The implementation methods of S501 to S505 are similar to those of S401 to S405 described above, and will not be repeated here.

[0221] S506, AP driver determines the first timer timeout.

[0222] In this embodiment, the function of the first timer is to set a preset duration. When the preset duration is reached from the start time of the first timer, it can be confirmed that the first timer has timed out.

[0223] In one implementation, if the AP driver receives a response message from hostapd before the first timer expires, the AP driver can close the first timer. Therefore, in this embodiment, the first timer is used to measure whether a response message from hostapd is received within a preset time.

[0224] If the AP driver determines that the first timer has expired, it means that after the preset time has elapsed since the AP driver sent the authentication request, no response message has been received from hostapd. This response message can be an authentication response, or it can be the indication information described above. For example, any message sent by hostapd to the AP driver after the AP driver sends the authentication request can be understood as a response message.

[0225] Therefore, in this embodiment, if the AP driver does not receive any response from hostapd after a preset time has elapsed after sending the authentication request, the AP driver can determine that hostapd will not reply with a response message.

[0226] S507 and AP drivers determine the cause of the anomaly and the waiting time.

[0227] When the AP driver determines that hostapd will no longer respond to messages, in order to provide an indication to the STA device, the AP driver can determine the cause of the anomaly and the waiting time based on the device capability information.

[0228] The cause of the anomaly and the waiting time here are similar to those described in the previous embodiments. The difference lies in that the cause of the anomaly and the waiting time in the previous embodiments were determined by hostapd, while in this embodiment, the cause of the anomaly and the waiting time are determined by the AP driver. This is because hostapd did not provide any response, therefore the AP driver determines the cause of the anomaly and the waiting time. Furthermore, since the AP driver did not receive a response from hostapd, it cannot determine the process status information of hostapd. Therefore, the AP driver can determine the cause of the anomaly and the waiting time based on the device capability information it can obtain.

[0229] The device capability information in this embodiment is similar to that described in the previous embodiments, and will not be repeated here. In one implementation, when the AP driver determines the cause of the anomaly based on the device capability information, it can, for example, adopt the following strategy:

[0230] The exception reason is used to indicate why the AP device cannot process the authentication request. For example, if the AP driver determines that the device capability information meets at least one of the following conditions: the CPU idle rate is less than the idle rate threshold, or the first quantity is greater than or equal to the first quantity threshold, then the exception reason can be, for example, hostapd being busy or the AP device being busy (corresponding to case 1 described above).

[0231] Alternatively, since the AP driver did not receive a response from hostapd, the AP device cannot actually determine what exactly happened by hostapd. In this case, the exception reason could also be "unknown". Alternatively, the exception reason could be directly described as "no authentication response received from hostapd", or it could be described as "hostapd timed out sending authentication response", etc. This embodiment does not limit the specific way of describing the exception reason, as long as it can indicate why the AP device cannot process the authentication request.

[0232] Furthermore, the AP driver in this embodiment can further estimate when hostapd expects to be able to process the authentication request, and thus determine a waiting time, which is used to instruct the STA device to access the AP device after the waiting time.

[0233] In this embodiment, the waiting time is the estimated time by the AP driver to resolve abnormal situations of hostapd. Because the AP driver estimates the waiting time based on the actual situation of the AP device, it can ensure that the STA device can connect to the AP device after the waiting time, and hostapd can process the authentication request it sends.

[0234] In one implementation, the AP driver can estimate the waiting time in a way that allows the waiting time to be inversely proportional to the CPU idle rate, or in a way that allows the waiting time to be directly proportional to a first quantity.

[0235] Specifically, a lower CPU idle rate indicates a busier AP device, and the longer it takes to alleviate the AP device's busyness, the longer the waiting time is. Therefore, the waiting time is inversely proportional to the CPU idle rate. Conversely, a larger first quantity indicates a larger number of STAs currently connected to the AP device, resulting in a higher AP device busyness and a longer waiting time to alleviate the AP device's busyness. Therefore, the waiting time is directly proportional to the first quantity.

[0236] Specifically, when determining the first duration, the choice of which parameters among CPU idle rate and the first quantity are referenced can be made based on actual needs. As described above, these parameters and the waiting duration all exhibit the proportional relationships described above. For example, a second preset function can be used to process at least one of the parameters, such as CPU idle rate and the first quantity, to determine the first duration. In the second preset function, the first duration satisfies the corresponding proportional relationships with the parameters described above.

[0237] In actual implementation, the coefficients used by hostapd to determine the first duration (coefficients used to characterize direct and inverse proportional relationships) and the coefficients used by AP driver to determine the first duration (coefficients used to characterize direct and inverse proportional relationships) can be the same or different. It can be understood that these two coefficients are independent of each other.

[0238] The S508 and AP drivers send instruction information to the STA devices.

[0239] The notification information includes the reason for the error and the waiting time.

[0240] For STA devices, the reason for the anomaly in the indication information is used to inform the STA device why the AP device did not send an authentication response.

[0241] Furthermore, the waiting time specified in the instruction information instructs the STA device to initiate the access procedure only after the specified waiting time. This waiting time is determined by the AP driver based on the actual situation of the current AP device. Therefore, it ensures that if the STA device initiates the access procedure after the specified waiting time, the issue of hostapd being unable to send an authentication response is resolved, allowing hostapd and the AP to send an authentication response to the terminal device. For example, the waiting time could be 3 seconds, 5 seconds, etc.

[0242] Similar to the embodiments described above, the AP driver can also first send an authentication response to the STA device. This authentication response is used to indicate that the authentication request of the STA device is rejected. In the current case, the implementation of the authentication response sent by the AP device can be referred to the description in the embodiments above, and will not be repeated here.

[0243] S509. After the waiting period following the receipt of the instruction information, the STA device and the AP device perform the access procedure.

[0244] The implementation of S509 is similar to that of S410, and will not be repeated here.

[0245] In this embodiment, the AP driver determines the waiting time based on device status information. Therefore, it ensures that the waiting time communicated to the STA device via the indication information is accurate. This allows the STA device to connect to the AP device as quickly as possible when the AP device's workload is reduced, shortening the network connection time for the STA device. The beneficial effects of the various technical features in this embodiment are the same as those described above. Figure 4 The beneficial effects described in the examples are similar and will not be repeated here.

[0246] Based on the above embodiments, when hostapd recovers from an anomaly, hostapd can, for example, send a notification message to the AP driver to inform it of the recovery. Alternatively, the AP driver can determine the recovery of hostapd by periodically checking its status.

[0247] When the AP driver determines that hostapd has recovered from an anomaly, it can send an announcement to the STA device via broadcast, for example, to indicate that the AP device's status has returned to normal. Furthermore, it can also indicate that the STA device can connect to the AP device. This further ensures that the STA device can connect to the AP device as quickly as possible after the AP device recovers from an anomaly, thereby shortening the network connection time for the STA device.

[0248] For example, a beacon message can be sent via broadcast, which includes the announcement information described above.

[0249] It should be noted that the module names involved in the embodiments of this application can all be defined as other names, as long as they can achieve the function of each module, and no specific restrictions are placed on the module names.

[0250] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in the embodiments of this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0251] The device access method according to the embodiments of this application has been described above. The apparatus for performing the above method provided in the embodiments of this application is described below. Those skilled in the art will understand that the methods and apparatus can be combined with and referenced by each other, and the related apparatus provided in the embodiments of this application can perform the steps in the above device access method.

[0252] The device access method provided in this application can be applied to electronic devices with communication functions. Electronic devices include terminal devices, and the specific device form of the terminal device can be referred to the above-mentioned descriptions, which will not be repeated here.

[0253] This application provides a terminal device, which includes a processor and a memory; the memory stores computer execution instructions; the processor executes the computer execution instructions stored in the memory, causing the terminal device to perform the above-described method.

[0254] For example, you can refer to Figure 6 To understand, Figure 6 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application.

[0255] like Figure 6 As shown, the terminal device 60 includes: a processor 601 and a memory 602; the memory 602 stores computer execution instructions; the processor 601 executes the computer execution instructions stored in the memory 602, causing the terminal device 60 to perform the above-described method.

[0256] When the memory 602 is set up independently, the terminal device also includes a bus 603 for connecting the memory 602 and the processor 601.

[0257] This application provides a chip. The chip includes a processor, which is used to call a computer program in memory to execute the technical solutions in the above embodiments. Its implementation principle and technical effects are similar to those in the related embodiments described above, and will not be repeated here.

[0258] This application also provides a computer-readable storage medium. The computer-readable storage medium stores a computer program. When the computer program is executed by a processor, it implements the methods described above. The methods described in the above embodiments can be implemented wholly or partially by software, hardware, firmware, or any combination thereof. If implemented in software, the functionality can be stored as one or more instructions or code on or transmitted over the computer-readable medium. The computer-readable medium can include computer storage media and communication media, and can also include any medium that can transfer a computer program from one place to another. The storage medium can be any target medium accessible by a computer.

[0259] In one possible implementation, a computer-readable medium may include RAM, ROM, compact disc read-only memory (CD-ROM) or other optical disc storage, disk storage or other magnetic storage devices, or any other medium targeted to carry or to store the required program code in the form of instructions or data structures, and accessible by a computer. Furthermore, any connection is appropriately referred to as a computer-readable medium. For example, if software is transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave, then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. As used herein, disks and optical discs include optical discs, laser discs, optical discs, Digital Versatile Discs (DVDs), floppy disks, and Blu-ray discs, where disks typically reproduce data magnetically, while optical discs optically reproduce data using lasers. Combinations of the above should also be included within the scope of computer-readable media.

[0260] This application provides a computer program product, which includes a computer program that, when run, causes the computer to perform the above-described method.

[0261] This application describes embodiments of methods, apparatus (systems), and computer program products according to embodiments of this application with reference to flowchart illustrations and / or block diagrams. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processing unit of a general-purpose computer, special-purpose computer, embedded processor, or other programmable device to produce a machine, such that the instructions, which execute via the processing unit of the computer or other programmable data processing device, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0262] The above specific embodiments further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solution of the present invention should be included within the scope of protection of the present invention.

Claims

1. A device access method, characterized in that, Applied to an access point (AP) device, the AP device including a first driver and a first process, the method includes: The first driver receives an authentication request sent by the STA device; the first driver sends the authentication request to the first process and starts a first timer; If the first process receives the authentication request before the first timer expires, the first process discards the authentication request based on the device capability information of the AP device and / or the process status information of the first process. The first process determines the waiting time based on the device capability information and / or the process status information; The first process generates indication information based on the waiting time, the indication information being used to instruct the STA device to initiate access to the AP device after the waiting time; If the first driver receives the instruction information sent by the first process, then the first driver sends the instruction information to the STA.

2. The method according to claim 1, characterized in that, The device capability information includes at least one of the following: CPU idle rate and a first quantity, wherein the first quantity is the number of STA devices connected to the AP device; The process status information includes at least one of the following: the number of messages in the message queue of the first process and anomaly reference information, wherein the anomaly reference information is used to indicate whether there is an anomaly in the first process.

3. The method according to claim 2, characterized in that, The first process discards the authentication request based on the device capability information of the AP device and / or the process state information of the first process, including: If the device capability information and / or the process status information satisfy at least one of the following conditions: the CPU idle rate is less than the idle rate threshold, the first quantity is greater than or equal to the first quantity threshold, the message quantity is greater than or equal to the second quantity threshold, and the abnormal reference information indicates that the first process is abnormal, then the first process discards the authentication request.

4. The method according to any one of claims 2-3, characterized in that, After the first process discards the authentication request based on the device capability information of the AP device and / or the process state information of the first process, the method further includes: The first process determines the cause of the anomaly based on the device capability information and / or the process status information. The cause of the anomaly is used to indicate why the AP device did not send an authentication response to the STA device. The indication information also includes the cause of the anomaly.

5. The method according to any one of claims 2-4, characterized in that, The waiting time is determined as follows: When the anomaly reference information indicates that the first process is not abnormal, the waiting time is inversely proportional to the CPU idle rate, and the waiting time is directly proportional to the first quantity, and the waiting time is directly proportional to the number of messages, or... When the abnormal reference information indicates that the first process is abnormal, the waiting time is the restart time of the first process.

6. The method according to any one of claims 1-5, characterized in that, Before the first driver receives the indication information sent by the first process, the method further includes: If the first driver still does not receive the response message sent by the first process after the first timer expires, the first driver determines the waiting time based on the device capability information of the AP device. The response message includes an authentication response and the indication information. The first driver generates the indication information based on the waiting time.

7. The method according to claim 6, characterized in that, The device capability information includes at least one of the following: CPU idle rate and a first number of STA devices connected to the AP device; The waiting time is inversely proportional to the CPU idle rate, and the waiting time is directly proportional to the first quantity.

8. The method according to any one of claims 1-3, characterized in that, The method further includes: The first driver determines the cause of the anomaly based on the device capability information. The cause of the anomaly is used to indicate why the AP device did not send an authentication response to the STA device. The indication information also includes the cause of the anomaly.

9. A device access method, characterized in that, Applied to STA equipment, the method includes: Send an authentication request to the AP device; The STA device receives an indication message sent by the AP device, the indication message being used to instruct the STA device to initiate access to the AP device after a waiting period; the waiting period is determined by the first process in the AP device based on the AP device's device capability information and / or the first process's process status information; After waiting for the specified time period following receiving the instruction information, an access request is initiated to the AP device.

10. The method according to claim 9, characterized in that, The indication information also includes an error reason, which is used to indicate why the AP device did not send an authentication response to the STA device.

11. An electronic device, characterized in that, include: Processor and memory; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the electronic device to perform the method as described in any one of claims 1-10.

12. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1-10.

13. A chip system, characterized in that, It includes at least one processor and a communication interface, the communication interface and the at least one processor being interconnected via a line, the at least one processor being configured to run a computer program or instructions to perform the method as described in any one of claims 1-10.

14. A computer program product, characterized in that, Includes a computer program that, when run, causes a computer to perform the method as described in any one of claims 1-10.

Images