Equipment access method and electronic equipment

Abstract

The embodiment of the invention provides an equipment access method and electronic equipment, and relates to the technical field of terminals. The method comprises the following steps: STA equipment sends an authentication request to AP equipment, a first driver in the AP equipment sends the authentication request to a first process, and a first timer is started; and if the first driver receives indication information sent by the first process before the first timer is overtime, the first driver sends the indication information to the STA, and the indication information is used for indicating the STA equipment to initiate access to the AP equipment after the waiting duration. And the STA equipment initiates access to the AP equipment after receiving the waiting duration of the indication information. Thus, the STA equipment can be indicated, and when the AP equipment can process the authentication response, access can be initiated to the AP equipment in time, so that the network access time consumption of the STA equipment is shortened.

Description

Technical Field

[0001] This application relates to the technical field of terminals, and in particular, to a device access method and an electronic device. Background Art

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

[0003] When multiple STAs access an AP simultaneously, due to reasons such as the routing processing ability of the AP device and internal anomalies, the authentication requests sent by the STAs to the AP may not be processed in a timely manner. In the case where there is no response to the authentication request of the STA device, the STA device may attempt to reconnect to the AP device again after a long time, or directly add the AP device to the blacklist and no longer automatically reconnect.

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

[0005] Embodiments of this application provide a device access method and an electronic device, which are applied to the technical field of terminals and can effectively shorten the network access time of the STA device.

[0006] In a first aspect, an embodiment of this application proposes 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 an authentication request sent by a station STA device;

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

[0009] If, before the first timer times out, the first driver receives indication information sent by the first process, the first driver sends the indication information to the STA, and the indication information is used to instruct the STA device to initiate access to the AP device after a waiting duration.

[0010] In this implementation, when the AP device determines that it cannot process the authentication request, the AP device notifies the STA device to initiate access after a waiting duration through the indication information, where the waiting duration is determined by the AP device, so accuracy can be guaranteed. So that when the AP device can process the authentication request, the STA device can initiate access to the AP device in a timely manner, thereby effectively shortening the network access time of the STA device.

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

[0012] If the first process receives an authentication request, the first process discards the authentication request according to the device capability information of the AP device and / or the process status information of the first process;

[0013] The first process determines the waiting duration according to the device capability information and / or the process status information;

[0014] The first process generates indication information according to the waiting duration.

[0015] In this implementation, the first process determines whether it can process the authentication request according to the device capability information and / or the process status information. When it is determined that it cannot process, the authentication request is discarded, and then the waiting duration is determined and the indication information is generated, so as to ensure the reasonableness of discarding the authentication request. And by using the device capability information and / or the process status information to determine the waiting duration, the accuracy of the waiting duration informed to the STA device can be effectively ensured.

[0016] In a possible implementation, the device capability information includes at least one of the following: the CPU idle rate of the central processing unit and the first quantity, where the first quantity is the number of STA devices accessing the AP device;

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

[0018] In a possible implementation, the first process discards the authentication request according to the device capability information of the AP device and / or the process status information of the first process, including:

[0019] If the device capability information and / or the process status information meet 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 number of messages is greater than or equal to the second quantity threshold, and the exception reference information indicates that there is an exception in the first process, the first process discards the authentication request.

[0020] In this implementation, by comparing the device capability information and / or the process status information with the corresponding thresholds, it is then determined whether the authentication request can be processed. When it is determined that the corresponding threshold conditions for discarding are met, the authentication request is discarded, so as to ensure that the first process discards the authentication request only when it is really unable to process the authentication request.

[0021] In a possible implementation, after the first process discards the authentication request according to the device capability information of the AP device and / or the process status information of the first process, the method further includes:

[0022] The first process determines the cause of the anomaly based on the device capability information and / or the process status information, where the cause of the anomaly is used to indicate the reason why the AP device fails to send an authentication response to the STA device;

[0023] Among them, the indication information also includes the cause of the anomaly.

[0024] In this implementation, by including the cause of the anomaly in the indication information, the STA device can be informed of the reason for not sending the authentication response, so as to avoid the device power consumption caused by the STA device's self-check in unnecessary situations.

[0025] In a possible implementation, the determination method of the waiting duration is as follows:

[0026] When the anomaly reference information indicates that there is no anomaly in the first process, the waiting duration is inversely proportional to the CPU idle rate, and the waiting duration is directly proportional to the first quantity, and the waiting duration is directly proportional to the number of messages. Or,

[0027] When the anomaly reference information indicates that there is an anomaly in the first process, the waiting duration is the restart time of the first process.

[0028] In this implementation, by presetting the proportional relationship between the waiting duration and the corresponding parameters, the accuracy of the waiting duration informed to the STA device can be effectively improved.

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

[0030] If the first driver still has not received the response message sent by the first process after the first timer times out, the first driver determines the waiting duration according to the device capability information of the AP device, where the response message includes the authentication response and the indication information;

[0031] The first driver generates the indication information according to the waiting duration.

[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 duration and generates the indication information, so as to avoid the access process from being unable to continue when the first process cannot send the response information, resulting in a long wait and thus a long network access time for the STA device.

[0033] That is to say, the purpose of setting the first timer in this application is also to shorten the network access time of the STA device. In the case where the first timer times out, if the first driver has not received the response sent by the first process, the first driver will advance the next process.

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

[0035] Wherein, the waiting duration is inversely proportional to the CPU idle rate, and the waiting duration is directly proportional to the first quantity.

[0036] In a possible implementation, the method further includes:

[0037] The first driver determines an exception cause according to the device capability information, and the exception cause is used to indicate the reason why the AP device does not send an authentication response to the STA device;

[0038] Wherein, the indication information further includes the exception cause.

[0039] In a second aspect, an embodiment of the present application proposes a device access method. Applied to an STA device, the method includes:

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

[0041] Receiving indication information sent by the AP device, where the indication information is used to indicate that the STA device initiates access to the AP device after a waiting duration;

[0042] After the waiting duration of receiving the indication information, initiating access to the AP device.

[0043] In a possible implementation, the indication information further includes an exception cause, and the exception cause is used to indicate the reason why the AP device does not send an authentication response to the STA device.

[0044] In a third aspect, an embodiment of the present application provides a device access device, which may be an electronic device, or a chip or a chip system within the 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 configured to perform the display step so that the electronic device implements a device access method described in the first aspect or the 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 configured to store instructions, and the processing unit executes the instructions stored in the storage unit so that the electronic device implements a device access method described in the first aspect or the second aspect. When the device access device is a chip or a chip system within the electronic device, the processing unit may be a processor. The processing unit executes the instructions stored in the storage unit so that the electronic device implements a device access method described in the first aspect or the second aspect. The storage unit may be a storage unit within the chip (e.g., register, cache, etc.), or a storage unit outside the chip within the electronic device (e.g., read-only memory, random access memory, etc.).

[0045] In a fourth aspect, an embodiment of the present application provides an electronic device, including a processor and a memory. The memory is configured to store code instructions, and the processor is configured to run the code instructions to execute the method described in the first aspect or the second aspect.

[0046] In a fifth aspect, an embodiment of the present application provides a computer-readable storage medium, in which a computer program or instructions are stored. When the computer program or instructions are run on a computer, the computer is caused to execute the method described in the first aspect or the second aspect.

[0047] In a sixth aspect, an embodiment of the present application provides a computer program product including a computer program. When the computer program is run on a computer, the computer is caused to execute the method described in the first aspect or the second aspect.

[0048] In a seventh aspect, the present application provides a chip or a chip system, which includes at least one processor and a communication interface. The communication interface and the at least one processor are interconnected by a line. The at least one processor is configured to run a computer program or instructions to execute the method described in the first aspect or the second aspect. Among them, the communication interface in the chip may be an input / output interface, a pin, a circuit, etc.

[0049] In a possible implementation, the chip or chip system described above in this application further includes at least one memory, and instructions are stored in the at least one memory. The memory may be a storage unit inside the chip, such as a register, cache, etc., or it may be a storage unit of the chip (such as a read-only memory, random access memory, etc.).

[0050] It should be understood that the technical solutions of the second to seventh aspects of this application correspond to those of the first aspect of this application, and the beneficial effects obtained by each aspect and the corresponding feasible implementation manners are similar, so they will not be elaborated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] Figure 1 Schematic diagram of a communication scenario provided by an embodiment of this application;

[0052] Figure 2 Signaling interaction diagram of an access process provided by an embodiment of this application;

[0053] Figure 3 Schematic diagram of the software architecture of an AP device provided by an embodiment of this application;

[0054] Figure 4 Interaction process of a device access method provided by an embodiment of this application Figure 1 ;

[0055] Figure 5 Interaction process of a device access method provided by an embodiment of this application Figure 2 ;

[0056] Figure 6 Schematic diagram of the hardware structure of an electronic device provided by an embodiment of this application. DETAILED DESCRIPTION OF THE EMBODIMENTS

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

[0058] 1. BSS

[0059] BSS (basic service set) is the most basic component unit of a wireless local area network (WLAN). It refers to a network composed of a group of wireless devices (which may include wireless network cards, wireless routers, etc.), and these devices use the same wireless channel and are connected through the same SSID (Service Set Identifier).

[0060] 2. PTK

[0061] PTK (Pairwise Transient Key), which is used for the encryption and decryption of unicast data frames.

[0062] 3. GTK

[0063] GTK (Group Temporal Key), which is used for the encryption and decryption of multicast data frames and broadcast data frames. Management frames, control frames, and null data frames do not need to be encrypted.

[0064] 4. Other terms

[0065] In the embodiments of the present application, terms such as "first" and "second" are used to distinguish identical or similar items with basically the same functions and roles. For example, the first chip and the second chip are only used to distinguish different chips, and do not limit their order. Those skilled in the art can understand that terms such as "first" and "second" do not limit the quantity and execution order, and "first", "second", etc. do not necessarily mean different.

[0066] It should be noted that in the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design solution described as "exemplary" or "for example" in the present application should not be construed as being more preferred or having more advantages than other embodiments or design solutions. Rather, the use of words such as "exemplary" or "for example" is intended to present related concepts in a specific manner.

[0067] In the embodiments of the present application, "at least one" means one or more, and "a plurality" means two or more. "And / or" describes the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone, where A and B can be singular or plural. The character " / " generally represents an "or" relationship between the associated objects before and after. "At least one (item)" or its similar expression refers to any combination of these items, including any combination of single item (item) or multiple items (items). For example, at least one (item) of a, b, or c can represent: a, b, c, a - b, a - c, b - c, or a - b - c, where a, b, c can be single or multiple.

[0068] 5. Electronic device

[0069] The electronic device according to the embodiment of the present application may include a handheld device with network access function, a vehicle-mounted device, etc. For example, some electronic devices are: mobile phone, tablet computer, handheld computer, laptop computer, mobile internet device (MID), wearable device, virtual reality (VR) device, augmented reality (AR) device, wireless terminal in industrial control, wireless terminal in self-driving, wireless terminal in remote medical surgery, wireless terminal in smart grid, wireless terminal in transportation safety, wireless terminal in smart city, wireless terminal in smart home, cellular phone, cordless phone, session initiation protocol (SIP) phone, wireless local loop (WLL) station, personal digital assistant (PDA), handheld device with wireless communication function, computing device or other processing device connected to a wireless modem, vehicle-mounted device, wearable device, terminal device in a 5G network or terminal device in a future evolved public land mobile network (PLMN), etc. The embodiment of the present application is not limited thereto.

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

[0071] In this embodiment, the electronic device may include an AP device and may also include an STA device. Each of the specific examples of the electronic device introduced above may be used as the AP device in this embodiment or may also be used as the STA device in this embodiment.

[0072] To better understand the technical solution of the present application, the related technologies involved in the present application will be further introduced in detail below.

[0073] First, the application scenario of the present application will be described in combination with Figure 1 the following. Figure 1 FIG. is a schematic diagram of a communication scenario provided by an embodiment of the present application. Referring to Figure 1 FIG., in this communication scenario, one end is an AP device and the other end is an STA device.

[0074] Among them, an AP is the creator of a wireless network and the central node of the network. The wireless router commonly used in a general family or office is an AP. Further, an AP can be understood as an access point for a mobile user to enter a wired network, mainly deployed in homes, inside buildings, and inside campuses, with a typical coverage radius of dozens of meters to hundreds of meters. Of course, it can also be deployed outdoors. An AP is equivalent to a bridge connecting a wired network and a wireless network, and its main function is to connect various wireless network clients together and then connect the wireless network to an Ethernet. Specifically, an AP can be a terminal device or a network device with a wireless-fidelity (WiFi) chip.

[0075] Among them, an STA refers to a device connected to a wireless network. Each device connected to an AP is regarded as a station. In a wireless network, communication between stations is carried out through an AP. Exemplarily, an STA can be a wireless communication chip, a wireless sensor, or a wireless communication terminal. For example, a mobile phone supporting WiFi communication function, a tablet computer supporting WiFi communication function, a set-top box supporting WiFi communication function, a smart TV supporting WiFi communication function, a smart wearable device supporting WiFi communication function, a vehicle-mounted communication device supporting WiFi communication function, and a computer supporting WiFi communication function.

[0076] The STA in this communication system can also be referred to as an access terminal, a user equipment, a user unit, a user station, a mobile station, a mobile device, a remote station, a remote terminal, a mobile device, a user terminal, a terminal, a wireless communication device, a user agent, or a user device. The user equipment can be a cellular phone, a cordless phone, a Session Initiation Protocol (SIP) phone, a Wireless Local Loop (WLL) station, a Personal Digital Assistant (PDA), a handheld device with wireless communication function, a computing device, or other processing devices connected to a wireless modem, a vehicle-mounted device, a wearable device, and a user equipment in a 5G network, etc. By way of example and not limitation, in the embodiments of the present application, the STA device can also be a wearable device. A wearable device can also be referred to as a wearable intelligent device.

[0077] The relationship between an AP and a STA is that the AP provides the opportunity for a wireless access network, while the STA is the actual device that connects to the network through the AP. The communication range of the STA is determined by the coverage range of the AP, and only the STA within the coverage range of the AP can connect to the network.

[0078] In the actual implementation process, the specific implementation methods of the AP device and the STA device can be selected according to actual requirements, and this embodiment does not limit this. As long as the AP device can be used as an access point and the STA device can be used as a station.

[0079] Based on the above introduction, the following will further combine Figure 2 to further introduce in detail the interaction process of the STA device accessing the AP device. Figure 2 This is the signaling interaction diagram of the access process provided by the embodiment of the present application.

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

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

[0082] Among them, the STA device will send a probe request frame in a broadcast manner to detect the surrounding BSS.

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

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

[0085] Among them, the device information can include, for example, the 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 sent by the AP device, the STA device can enter the authentication stage. In the authentication stage, 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 the authentication request can also include the capability information of the STA device to realize the capability negotiation between the STA device and the AP device.

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

[0089] Based on the authentication request sent by the STA device, the AP device authenticates the STA device. After that, the AP device sends an authentication response frame to the STA device.

[0090] In the case where the authentication of the STA device is successful, the authentication response frame is used to indicate successful authentication, indicating that the AP device allows the STA device to access. In the case where the authentication fails, the authentication response frame is used to indicate failed authentication, indicating that the AP device rejects the STA device's access.

[0091] In addition, the authentication response may 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 passes the authentication, the STA device can send an association request frame to the AP device. Among them, 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 are successfully associated.

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

[0097] After the AP device and the STA device are successfully associated, the AP device and the STA device will further perform an EAPOL (Extensible Authentication Protocol over LAN) four-way handshake. Among them, the purpose of the four-way handshake is to calculate the keys PTK and GTK for subsequent data encryption. Further, the four-way handshake is a key exchange process. The four-way handshake does not directly transmit passwords, but exchanges messages through EAPOL.

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

[0099] 7.1. The AP device sends Message 1 (Message1, or also known as Message a) to the STA device.

[0100] Among them, the message 1 may include a random number (Anonce) generated by the AP.

[0101] 7.2. The STA device sends message 2 (message2, or also known as message b) to the AP device.

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

[0103] Meanwhile, the STA device will generate a PTK.

[0104] 7.3. The AP device sends message 3 (message3, or also known as message c) to the STA device.

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

[0106] 7.4. The STA device sends message 4 (message4, or also known as message d) to the AP device.

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

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

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

[0110] First of all, the STA device can send a DHCP discovery (DHCP discover) packet to the AP device in a broadcast manner.

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

[0112] After receiving the DHCP discovery message, the AP device can select an IP address according to the priority of IP address allocation, and send it to the STA device through a DHCP offer message together with other parameters.

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

[0114] For a 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. The message includes 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 the AP receives the DHCP request message from the STA device, if it confirms that the IP address indicated in the DHCP request message is allocated to the STA device, it returns a DHCP confirmation (DHCP ack) message. At this point, the STA device is allocated an IP address and can access the network.

[0117] Based on the above introduction, Figure 3 Based on the software architecture of the AP device, the specific implementation of the authentication process is further introduced in detail. Figure 3 A schematic diagram of the software architecture of the AP device provided in an embodiment of the present 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 may include, for example, a router WebUI (website user interface), and the application layer may also include a router web APP (application). A user may configure an AP device or input related control instructions in the router WebUI or the router web APP.

[0120] Among them, the business layer is used to provide relevant support for business processing. For example, the business layer may include modules such as routing protocol, plug-in platform, device management, privacy security, AP management, and STA management.

[0121] The HAL layer is a package of the kernel driver, providing an interface to the upper layer and shielding the implementation details of the low-level hardware.Figure 3 As shown in the figure, the HAL layer includes the kernel HAL and hostapd (Host Access Point Daemon). Hostapd is a daemon process in user space for the AP and authentication server, which implements the relevant access management.

[0122] Among them, the driver layer includes various drivers. For example, it can include Figure 3 the network card driver and the AP driver shown in the figure. Among them, the AP driver can also be called the wifi driver. And, in the driver layer, for example, it can also include general drivers such as USB drivers and memory drivers, and can also include input / output drivers such as LED drivers and button drivers, and can also include network card drivers, other drivers, etc. This embodiment does not limit the specific driver content included in the driver layer.

[0123] Based on the software architecture introduced above, during the authentication phase of the STA device and the AP device, the STA device sends an authentication request to the AP device. Referring to Figure 3 , for example, the AP driver in the AP device can receive the authentication request.

[0124] After receiving the authentication request, the AP driver can perform a preliminary authentication on the STA device according to the relevant information. After the preliminary authentication is passed, as Figure 3 shown in the figure, the AP driver can send the authentication request to hostapd so that hostapd can perform a further authentication on the STA device.

[0125] In the case where hostapd is also authenticated successfully, for example, hostapd can send an authentication response to the AP driver, and then the AP driver sends the authentication response to the STA device to complete the authentication process.

[0126] The above is the case where the authentication is successful. However, in some abnormal situations, after the AP driver sends an authentication request to hostapd, if hostapd cannot process the authentication request due to some problems, then the AP driver may not receive the authentication response sent by hostapd. Correspondingly, the AP driver cannot send an authentication response to the STA device.

[0127] Here, several situations where hostapd cannot process the authentication request are introduced exemplarily:

[0128] Situation 1: hostapd is busy

[0129] For example, in scenarios where the AP device restarts and powers on, or the power supply to the AP device is restored after a power outage and then the device powers on again, STA devices that were previously connected to the AP device may simultaneously send reconnection requests to the AP device. In this case, a large number of STA devices may attempt to access the AP device simultaneously.

[0130] During the process of STA device access handling, the STA device will execute the detection process and authentication process described above. Since the access of multiple STA devices is executed in parallel, in the authentication stage, hostapd may receive a large number of authentication requests.

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

[0132] Case 2: AP driver is busy

[0133] Based on the same scenario as above, in the authentication stage, the AP driver may receive a large number of authentication requests. After receiving the authentication requests, the AP driver will forward the authentication requests to hostapd.

[0134] However, because the number of simultaneously forwarded authentication requests is too large, some authentication requests may not be successfully sent to hostapd, and naturally hostapd cannot handle these authentication requests.

[0135] In the actual implementation process, the scenarios of hostapd being busy and the AP driver being busy are not limited to the AP device powering on again as described above, so there are scenarios where a large number of STA devices reconnect. In any scalable scenario, there may be a situation where the AP device receives a large number of authentication requests sent in parallel by STA devices, resulting in hostapd being busy and the AP driver being busy. Any scenario that causes hostapd to be busy and the AP driver to be busy can apply the technical solutions introduced in this application.

[0136] Case 3: Internal exception in hostapd

[0137] When there is an internal exception in hostapd, if hostapd receives an authentication request and is temporarily unable to handle it due to the internal exception, it will not send an authentication response.

[0138] Regardless of which of the above cases is involved, in general, after the AP driver sends an authentication request to hostapd, the AP driver does not receive the authentication response sent by hostapd. Naturally, the AP driver is also unable to send an authentication response to the STA device.

[0139] For the STA device, during the authentication phase, after the STA device sends an authentication request, if it does not receive an authentication response from the AP device, then the STA may try to send the authentication request to the AP device again. However, based on the various possible situations described above, it is possible that hostapd still cannot handle the authentication request sent again by the STA device.

[0140] In the case where the STA device sends the authentication request multiple times but never receives an authentication response from the AP device, for example, when the STA device determines that the duration of this access process has exceeded a certain time limit, that is, this access process has timed out, then the STA device will determine that this access process connection has failed.

[0141] Because there is no timeout handling mechanism designed for the STA device in the current chip or protocol design, when the STA device sends the authentication request multiple times but still fails to access, the subsequent behavior of the STA device is not detailedly constrained.

[0142] Most manufacturers, considering power consumption, usually set the STA device to enter an exception handling process after determining a connection failure. The exception handling process may include the following solutions:

[0143] The first solution is that after a preset first duration, the STA device tries to reconnect to the AP device again, that is, performs all the operations of the above-described access process again. Among them, the first duration is not fixed and depends on the settings of each STA device itself. For example, there may be certain differences in the first durations corresponding to STA devices of different manufacturers.

[0144] The second solution is that the STA device adds the AP device to the blacklist. In the case of authentication failure, the STA device determines that the AP device is temporarily inaccessible. After that, if the STA device makes multiple attempts, it may still be unable to access. Then, considering power consumption, the STA device can add the AP device to the blacklist to avoid the STA device making multiple reconnections without benefit and causing 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. After that, if it wants to connect to the AP device, the user needs to perform a manual connection operation on the STA device.

[0146] For the two exception handling processes of the STA device described above, whether the STA device tries to reconnect again after the first duration or the STA device adds the AP device to the blacklist and then the user manually connects and reconnects, it will cause the network access of the STA device to consume a certain amount of time.

[0147] However, the several situations where hostapd cannot handle authentication requests introduced above may actually be alleviated in a short period of time. Then, in the case where hostapd can already handle authentication requests, based on the abnormal handling process of the STA introduced above, the STA device still will not initiate a reconnection to the AP device, resulting in the STA device not connecting in a timely manner when connection can be achieved, and further leading to a long time-consuming for the STA device to access the network.

[0148] In view of the above-introduced technical problems, the present application proposes the following technical concept: The reason why the STA device is still waiting for reconnection or directly giving up reconnection when hostapd can already handle authentication requests is that the STA device is not sure why the AP device does not reply with an authentication response, nor is it sure when to send an authentication request again to get a response. And the AP device itself can determine specifically what problem causes it to be unable to reply with an authentication response, and at the same time it can estimate when its problem can be solved. Therefore, when hostapd cannot reply with an authentication response, the AP device can send indication information to the STA device to inform the current specific situation, and / or indicate that the STA device tries to reconnect after a specified duration, so as to ensure that when hostapd can handle the authentication response, the STA device can reconnect in a timely manner, thereby shortening the time-consuming of the STA's network connection.

[0149] Based on this, the device access method provided by the present application will be introduced in detail below in combination with specific embodiments. It can be determined from the introduction of the above embodiments that there may be various situations that cause hostapd to be unable to handle authentication requests.

[0150] Among them, situation 1 and situation 3 introduced above can be classified into one type, both of which are that hostapd receives an authentication request but hostapd cannot handle it, so the AP driver will not receive the authentication response sent by hostapd.

[0151] And situation 2 introduced above can be classified into another type, which is that hostapd does not receive the authentication request sent by the AP driver, so naturally the AP driver will not receive the authentication response sent by hostapd.

[0152] Below, the implementation manners of the device access method in these two types of situations will be introduced respectively.

[0153] First, in combination with Figure 4 the first type introduced above, that is, the type corresponding to situation 1 and situation 3 will be introduced. Figure 4 is the interaction process of the device access method provided by the embodiments of the present application Figure 1 .

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

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

[0156] S402. The AP driver sends a probe response to the SAT device.

[0157] Among them, the specific implementation of the probe request and the probe response can refer to the introduction of the above embodiments, and will not be elaborated here.

[0158] In addition, it should be noted that the AP device in this application includes a first driver and a first process. Among them, the first driver can be, for example, an AP driver, but is not limited to this implementation. Any driver used to process the authentication request of the STA device can be understood as the first driver in this embodiment. Exemplarily, the AP driver in this embodiment can also be understood as a wifi chip.

[0159] And, the first process can be hostapd, but is not limited to this implementation. Any process used to process the authentication request of the STA device can be understood as the first process in this embodiment.

[0160] In this embodiment and the following embodiments, taking the first driver as the AP driver and the first process as hostapd as an example for introduction, when the first driver and the first process are other implementations, corresponding replacements can be made.

[0161] S403. The STA device sends an authentication request to the AP driver.

[0162] Among them, the implementation manner of the authentication request is also similar to the above introduction, and will not be elaborated here.

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

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

[0165] Among them, after receiving the authentication request, the AP driver can, for example, perform a preliminary authentication on the STA device according to the information carried in the authentication request. In the case where the preliminary authentication is passed, the AP driver sends an authentication request to hostapd so that hostapd performs a further authentication on the STA device.

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

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

[0168] In this embodiment, the role of the first timer is to set a preset duration. When the preset duration is reached starting 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 exception and the waiting duration.

[0170] After hostapd receives the authentication request sent by the AP driver, hostapd can determine whether there are sufficient resources to process the authentication request based on the device capability information of the AP device 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 the authentication request. Specifically, hostapd can not add the authentication request to the message queue, thus realizing the discarding of the authentication request.

[0171] Among them, the device capability information is information used to reflect the processing capability of the AP device. Exemplarily, the device capability information can include at least one of the following: the CPU idle rate and the first quantity, where the first quantity is the number of STA devices connected to the AP device. Among them, the first quantity can be composed of the following two parts of quantities for example: one part is the number of STA devices already connected to the AP device, and the other part is the number of STA devices that are in the process of accessing the AP device.

[0172] In the actual implementation process, the device capability information can also be extended according to actual needs. For example, the device capability information can also include the CPU occupancy rate, the number of CPU cores, etc. Any information used to reflect the processing capability of the AP device can be used as the device capability information in this embodiment.

[0173] And, the process status information is information used to reflect the status of the first process (i.e., hostapd). Exemplarily, the process status information can include at least one of the following: the number of messages in the message queue in the first process, the exception reference information, where the exception reference information is used to indicate whether there is an exception in the first process. Among them, the first process can clearly know whether there is an exception in itself. Therefore, when there is an exception in the first process, the exception reference information can realize the indication of the exception.

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

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

[0176] If the device capability information and / or the process status information meet 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 exception reference information indicates that there is an exception in the first process, then the first process determines that there are not enough resources to process the authentication request. Therefore, it can choose to discard the authentication request.

[0177] Exemplarily, 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 for access (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 the actual implementation process, the specific implementation manners of the idle rate threshold, the first quantity threshold, and the second quantity threshold can all be set according to actual needs.

[0178] Taking the idle rate threshold of 20%, the first quantity threshold of 80% of the maximum number (assuming the maximum number is 50, then the first quantity threshold is 40), and the second quantity threshold of 40 (assuming the maximum capacity of the message queue is 50 messages) as an example, several specific examples are combined for illustration:

[0179] If the CPU idle rate of the AP device is 10%, the first quantity of STA devices accessing the AP device is 30, and the message quantity in the message queue of hostapd is 45, it can be determined that the current device capability information and / or the process status information meet the above-introduced conditions. Therefore, it can be determined that the resources of the current hostapd are not sufficient to support the processing of the authentication request, and thus the authentication request can be chosen to be discarded.

[0180] Alternatively, if the CPU idle rate of the AP device is 60%, the first number of STA devices connected to the AP device is 30, and the number of messages in the message queue in hostapd is 20, 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 resources of the current hostapd are sufficient to support the processing of authentication requests, and thus the authentication request can be processed normally. After that, 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. In this embodiment, the scenario where hostapd processes authentication requests normally is not elaborated.

[0181] In the actual implementation process, which device capability information and process status information hostapd specifically refers to for the discard determination here can be selected according to actual needs. That is to say, some parameters can be selected from the multiple parameters described above according to requirements, and then it is determined whether the corresponding conditions are met, and then the authentication request is selected to be discarded when the conditions are met.

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

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

[0184] Alternatively, if hostapd determines that the process status information meets: the exception reference information indicates that the first process has an exception, the reason for the exception can be, for example, that there is an internal exception in hostapd (corresponding to the situation 3 described above).

[0185] In the actual implementation process, the specific implementation of the reason for the exception can also be set according to actual needs. And there may be other abnormal situations where hostapd cannot process authentication requests. Then, the corresponding reason for the exception can be adaptively set according to the abnormal situation of hostapd, as long as the reason for the exception can indicate the reason why hostapd cannot process the authentication request.

[0186] In addition, when hostapd cannot process the authentication request, hostapd in this embodiment will further estimate when hostapd is expected to process the authentication request, and then determine a waiting duration, which is used to indicate that the STA device accesses the AP device after the waiting duration.

[0187] In this embodiment, the waiting duration is the duration estimated by hostapd to resolve the abnormal situation of hostapd. Since hostapd estimates the waiting duration based on its actual situation, it can ensure that the STA device accesses the AP device after the waiting duration, and hostapd can process the authentication request sent by it.

[0188] In different abnormal situations, there will be certain differences in the waiting duration estimated by hostapd. The following is an exemplary introduction to the implementation method of hostapd estimating the waiting duration in several abnormal situations of hostapd:

[0189] In one implementation, when the abnormal reference information indicates that the first process has no abnormality, the waiting duration is inversely proportional to the CPU idle rate, and the waiting duration is directly proportional to the first quantity, and the waiting duration is directly proportional to the number of messages.

[0190] Specifically, when the CPU idle rate is lower, it means that the current AP device is busier, and the time required to relieve the busy situation of the corresponding AP device is longer. Therefore, the waiting duration is inversely proportional to the CPU idle rate. In addition, when the first quantity is larger, it means that the number of STAs accessing the AP device is larger, then the busier the AP device is, and the time required to relieve the busy situation of the corresponding AP device is longer. Therefore, the waiting duration is directly proportional to the first quantity. In addition, when the number of messages is larger, it means that the more messages hostapd needs to process, and the busier the corresponding AP device is. Then the time required to relieve the busy situation of the AP device (or hostapd) is longer. Therefore, the waiting duration is also directly proportional to the number of messages.

[0191] Among them, when determining the first duration, specifically which of the parameters such as the CPU idle rate, the first quantity, and the number of messages are referred to for determination can be selected according to actual needs. It can be determined from the above introduction that these parameters and the waiting duration have the proportional relationships introduced above. Exemplarily, for example, a first preset function can be used to process at least one of the parameters such as the CPU idle rate, the first quantity, and the number of messages to obtain the determined first duration. In the first preset function, the first duration satisfies the corresponding proportional relationships with the above-introduced parameters.

[0192] In another implementation, when the exception reference information indicates that there is an exception in the first process, hostapd usually chooses to restart hostapd to try to resolve the exception. Therefore, the waiting duration can be set to the restart time of hostapd. Among them, the restart time of hostapd can be pre-set, or it can also be estimated in real time by hostapd.

[0193] It should also be noted that after hostapd receives the authentication request sent by the AP driver, it can perform the operation of S406. And after the AP driver sends the authentication request to hostapd, it can perform the operation of S405. Therefore, in this embodiment, the execution order of S405 and S406 can be determined according to the actual situation. It is possible to execute S405 first and then S406; it is also possible to execute S406 first and then S405; it is also possible that S405 and S406 are executed in parallel.

[0194] S407. Hostapd sends indication information to the AP driver.

[0195] Among them, the indication information includes the reason for the exception and the waiting duration. The specific implementation of the reason for the exception and the waiting duration has been introduced in detail above and will not be elaborated here.

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

[0197] Based on the above introduction, 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 the preset duration. Therefore, after the AP driver receives the indication information sent by hostapd, it can stop the first timer.

[0198] S409. The AP driver sends indication information to the STA device.

[0199] Similar to the above introduction, the indication information includes the reason for the exception and the waiting duration.

[0200] For the STA device, the reason for the exception in the indication information is used to inform the STA device of the reason for not sending the authentication response.

[0201] And, the waiting time in the indication information is used to instruct the STA device to initiate the access process after the waiting time. Because the waiting time in the indication information is determined by hostapd according to the actual situation of hostapd, it can be ensured that if the STA device initiates the access process after the waiting time, the problem that hostapd cannot send the authentication response has been solved, and then hostapd and AP can send the authentication response to the terminal device. Exemplarily, the waiting time can be 3 seconds, or 5 seconds, etc.

[0202] In one implementation, because the current hostapd cannot process the authentication request of the STA device, the AP driver can also send an authentication response to the STA device first, wherein the authentication response is used to inform the STA device that the current authentication request is rejected. In addition, with the above-mentioned indication information, the STA device can be further informed of why its authentication request is rejected and how long it will take for the STA device to try to reconnect again.

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

[0204] S410: After receiving the waiting time of the indication information, the STA device and the AP device perform an access process.

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

[0206] It can be understood that the waiting time in this embodiment is the time determined by hostapd, because hostapd can clearly understand the specific situation of the AP device. Therefore, the STA device executes the access process again after the waiting time according to the instruction information determined by hostapd, which can ensure that the AP driver and hostapd can complete their corresponding tasks.

[0207] Here, the implementation method of the STA device attempting to reconnect to the AP device again after a preset first duration will be analyzed. The first duration is actually a preset value set by the manufacturer for the purpose of device power consumption and ensuring network connection, and it has nothing to do with the status of the AP device. Moreover, the STA device itself cannot determine the status of the AP device. Under the traditional solution, the STA device cannot even determine why it has not received the authentication response sent by the AP device, and naturally cannot accurately estimate when to attempt reconnection again to obtain a response. Therefore, the STA device will initiate a reconnection to the AP device again after the first duration arrives.

[0208] In this embodiment, hostapd can clearly understand the specific situation of the current hostapd. And based on the device capability information and / or process status information, referring to the implementation method introduced in this embodiment, hostapd can accurately estimate how long it will take for the problem to be fixed (for example, the busyness is alleviated, or hostapd returns to normal from an abnormal state). After that, hostapd can normally process the authentication response. Therefore, the waiting duration informed to the STA device in the indication information sent by hostapd is very accurate.

[0209] Moreover, under the traditional solution, considering the purpose of power saving, the manufacturer usually does not allow the STA device to perform reconnection attempts too frequently. Therefore, the first duration is usually set relatively long, for example, it can be set to 5 minutes. However, the problem that hostapd cannot process the authentication request is usually solved within a short time. Therefore, the waiting duration indicated by hostapd is usually relatively short, for example, usually a few seconds. Therefore, in one implementation, the waiting duration in this embodiment is less than the first duration preset by the STA device, so that when hostapd returns to normal, the STA device can access the AP device as soon as possible, shortening the time-consuming of the STA device's network connection.

[0210] It should also be noted that usually, when the STA device sends an authentication request but does not receive an authentication response, the STA device may also perform a series of self-check actions to avoid similar problems in subsequent network access. For example, the STA device will check whether there are format errors, data anomalies, etc. in the authentication request it sends. In the application scenario of this application, the reason why the STA device does not receive the authentication response is not due to the STA device itself, but because there are certain anomalies in the AP device itself.

[0211] Therefore, in this embodiment, the indication information sent by hostapd to the STA device further includes the reason for the exception, which can inform the STA device of the reason why the authentication response was not received currently. When the STA determines based on the reason for the exception that the authentication response was not received due to a problem with the AP device, the STA device will not perform self-check again, thus saving the power consumption caused by unnecessary actions of the STA device.

[0212] Next, in combination with Figure 5 the second type introduced above, that is, the type corresponding to Case 2, will be introduced. Figure 5 is the interaction process of the device access method provided by the embodiments of the present application Figure 2 .

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

[0214] S501. The STA device sends a probe request to the AP driver.

[0215] S502. The AP driver sends a probe response to the SAT device.

[0216] S503. The STA device sends an authentication request to the AP driver.

[0217] Among them, the implementation manner of the authentication request is similar to that introduced above, and will not be elaborated here.

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

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

[0220] Among them, the implementation manners of S501 to S505 are similar to those of S401 to S405 introduced above, and will not be elaborated here.

[0221] S506. The AP driver determines that the first timer times out.

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

[0223] In one implementation manner, if the AP driver receives the response message sent by hostapd before the first timer times out, the AP driver can turn off the first timer. Therefore, the first timer in this embodiment is used to measure whether the response message sent by hostapd is received within the preset duration.

[0224] If the AP driver determines that the first timer has timed out, it means that after the authentication request is sent by the AP driver, after a preset duration, no response message returned by hostapd has been received. The response message here can be an authentication response, or it can also be the indication information introduced above. Exemplarily, any message sent by hostapd to the AP driver after the AP driver sends an authentication request can be understood as a response message.

[0225] Therefore, in the case of this embodiment, after the AP driver sends an authentication request, after a preset duration, no response sent by hostapd is received. Then the AP driver can determine that hostapd will not reply with a response message.

[0226] S507. The AP driver determines the cause of the exception and the waiting duration.

[0227] When the AP driver determines that hostapd will no longer reply with a response message, in order to provide an indication to the STA device, the AP driver can determine the cause of the exception and the waiting duration according to the device capability information.

[0228] The cause of the exception and the waiting duration here are similar to those introduced in the above embodiment. The difference is that the cause of the exception and the waiting duration introduced in the above embodiment are determined by hostapd, while the cause of the exception and the waiting duration in this embodiment are determined by the AP driver. This is because hostapd does not provide any response, so the AP driver determines the cause of the exception and the waiting duration. And because the AP driver does not receive the response from hostapd, it is also impossible to determine the process status information of hostapd. Therefore, the AP driver can determine the cause of the exception and the waiting duration according to the device capability information that it can obtain.

[0229] The device capability information in this embodiment is similar to that introduced in the above embodiment and will not be elaborated here. In one implementation, when the AP driver determines the cause of the exception according to the device capability information, for example, the following strategy can be adopted:

[0230] Among them, the cause of the exception is used to indicate the reason why the AP device cannot process the authentication request. Exemplarily, 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, and the first quantity is greater than or equal to the first quantity threshold, the cause of the exception can be, for example, that hostapd is busy or the AP device is busy (corresponding to case 1 introduced above).

[0231] Alternatively, since the AP driver does not receive the response sent by hostapd, the AP device actually cannot determine what exactly happened to hostapd. Then, the reason for the exception can also be, for example, "unknown". Alternatively, the reason for the exception can also be directly described as "the authentication response sent by hostapd is not received", or it can also be described as "the timeout for hostapd to send the authentication response", etc. This embodiment does not limit the specific description method of the reason for the exception, as long as it can indicate the reason why the AP device cannot process the authentication request.

[0232] In addition, the AP driver in this embodiment can further estimate when hostapd is expected to process the authentication request, and then determine a waiting duration, which is used to indicate that the STA device accesses the AP device after the waiting duration.

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

[0234] In one implementation, the implementation method for the AP driver to estimate the waiting duration may include: the waiting duration is inversely proportional to the CPU idle rate, and the waiting duration is directly proportional to the first quantity.

[0235] Specifically, when the CPU idle rate is lower, it means that the current AP device is busier, and the time required to relieve the busy situation of the corresponding AP device is longer. Therefore, the waiting duration is inversely proportional to the CPU idle rate. In addition, when the first quantity is larger, it means that the number of STAs accessing the AP device is larger, then the busier the AP device is, and the time required to relieve the busy situation of the corresponding AP device is longer. Therefore, the waiting duration is directly proportional to the first quantity.

[0236] Among them, when determining the first duration, specifically which of the parameters such as the CPU idle rate and the first quantity are referred to for determination can be selected according to actual needs. It can be determined from the above introduction that these parameters and the waiting duration have the proportional relationships introduced above. Exemplarily, for example, a second preset function can be used to process at least one of the parameters such as the CPU idle rate and the first quantity to obtain the determined first duration. In the second preset function, the first duration satisfies the corresponding proportional relationships with the above-introduced parameters.

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

[0238] S508: The AP driver sends instruction information to the STA device.

[0239] The indication information includes the cause of the exception and the waiting time.

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

[0241] And, the waiting time in the indication information is used to instruct the STA device to initiate the access process after the waiting time. The waiting time in the indication information is determined by the AP driver according to the actual situation of the current AP device. Therefore, it can be ensured that if the STA device initiates the access process after the waiting time, the problem that hostapd cannot send the authentication response has been solved, and then hostapd and AP can send the authentication response to the terminal device. Exemplarily, the waiting time can be 3 seconds, or 5 seconds, etc.

[0242] Similar to the above embodiment, the AP driver may also first send an authentication response to the STA device, where the authentication response is used to indicate that the authentication request of the STA device is rejected. In the current case, the implementation method of the authentication response sent by the AP device can refer to the introduction of the above embodiment and will not be repeated here.

[0243] S509: After receiving the waiting time of the indication information, the STA device and the AP device perform an access process.

[0244] The implementation method of S509 is similar to the implementation method of S410 described above, and will not be repeated here.

[0245] In this embodiment, the AP driver determines the waiting time according to the device status information, so it can ensure that the waiting time notified to the STA device through the indication information is accurate, so that when the busyness of the AP device is relieved, the STA device can access the AP device as soon as possible, shortening the time taken for the STA device to connect to the network. Figure 4 The beneficial effects described in the embodiments are similar and will not be repeated here.

[0246] Based on the content introduced in the above embodiments, when hostapd recovers from an exception, hostapd can, for example, also send notification information to the AP driver to inform the AP driver of the exception recovery of hostapd. Alternatively, the AP driver can also determine the exception recovery of hostapd by periodically checking the status of hostapd.

[0247] When the AP driver determines the exception recovery of hostapd, for example, it can send announcement information to the STA device by means of broadcasting, where the announcement information is used to indicate that the status of the AP device has returned to normal, and further can be used to indicate that the STA device can access the AP device. Thus, it can further ensure that when the AP device recovers from an exception, the STA device can access the AP device as soon as possible, so as to shorten the time-consuming of the network connection of the STA device.

[0248] Exemplarily, for example, a beacon message can be sent by means of broadcasting, and the above-introduced announcement information is included in the beacon message.

[0249] It should be noted that the module names involved in the embodiments of the present application can all be defined as other names, as long as the functions of each module can be realized, and no specific restrictions are imposed 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 for analysis, stored data, displayed data, etc.) involved in the embodiments of the present application are all information and data authorized by the user or fully authorized by all parties, and the collection, use, and processing of relevant data need to comply with the relevant laws, regulations, and standards of relevant countries and regions, and corresponding operation entrances are provided for users to choose to authorize or refuse.

[0251] The device access method of the embodiments of the present application has been described above. Next, the device for executing the above method provided by the embodiments of the present application will be described. Those skilled in the art can understand that the method and the device can be combined and referenced with each other, and the relevant device provided by the embodiments of the present application can execute the steps in the above device access method.

[0252] The device access method provided by the embodiments of the present application can be applied to an electronic device with communication functions. The electronic device includes a terminal device, and the specific device form of the terminal device can refer to the above relevant description, which will not be elaborated here.

[0253] The embodiments of the present application provide 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, so that the terminal device executes the above method.

[0254] For example, reference may be made to Figure 6 for understanding. Figure 6 which is a schematic diagram of the hardware structure of the electronic device provided by the embodiment of the present application.

[0255] As Figure 6 shown, the terminal device 60 includes: a processor 601 and a memory 602; the memory 602 stores computer-executable instructions; the processor 601 executes the computer-executable instructions stored in the memory 602, so that the terminal device 60 executes the above method.

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

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

[0258] The embodiment of the present 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, the above method is implemented. The methods described in the above embodiments can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. If implemented in software, the functions can be stored as one or more instructions or codes on a computer-readable medium or transmitted on a computer-readable medium. The computer-readable medium may include a computer storage medium and a communication medium, and may also include any medium that can transfer a computer program from one place to another. The storage medium may be any target medium accessible by a computer.

[0259] In one possible implementation, the computer-readable medium may include RAM, ROM, compact disc read-only memory (CD-ROM), or other optical disc storage, magnetic disk storage, or any other medium targeted to carry or store the required program code in the form of instructions or data structures and accessible by a computer. Moreover, any connection is properly termed 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, Digital Subscriber Line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of the medium. As used herein, disk and optical disc include optical disc, laser disc, optical disc, Digital Versatile Disc (DVD), floppy disk, and Blu-ray disc, where disks typically reproduce data magnetically, while optical discs utilize lasers to optically reproduce data. Combinations of the above should also be included within the scope of computer-readable media.

[0260] An embodiment of the present application provides a computer program product. The computer program product includes a computer program that, when run, causes a computer to execute the above method.

[0261] Embodiments of the present application are described with reference to the flowcharts and / or block diagrams of methods, apparatuses (systems), and computer program products according to embodiments of the present application. It should be understood that each flow and / or block in the flowcharts and / or block diagrams, as well as combinations of flows and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to the processing unit of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable devices to generate a machine such that the instructions executed by the processing unit of the computer or other programmable data processing device generate means for implementing the functions specified in Figure 1 one or more of the flows or Figure 1 blocks or combinations of blocks.

[0262] The above specific implementation manners further elaborate the objectives, technical solutions, and beneficial effects of the present invention. It should be understood that the above are only specific implementation manners of the present invention and are not used to limit the protection scope of the present invention. Any modifications, equivalent replacements, improvements, etc. made on the basis of the technical solutions of the present invention should be included within the protection scope of the present invention.

Claims

1. A device access method, characterized in that, applied to an access point AP device, the AP device includes a first driver and a first process, and the method includes: the first driver receives an authentication request sent by a station STA device; the first driver sends the authentication request to the first process and starts a first timer; if, before the first timer times out, the first driver receives indication information sent by the first process, then the first driver sends the indication information to the STA, and the indication information is used to instruct the STA device to initiate access to the AP device after a waiting duration.

2. The method according to claim 1, characterized in that, before the first driver receives the indication information sent by the first process, the method further includes: if the first process receives the authentication request, the first process discards the authentication request according to the device capability information of the AP device and / or the process status information of the first process; the first process determines the waiting duration according to the device capability information and / or the process status information; the first process generates the indication information according to the waiting duration.

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

4. The method according to claim 3, characterized in that, the first process discards the authentication request according to the device capability information of the AP device and / or the process status information of the first process, including: if the device capability information and / or the process status information meet 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 number of messages is greater than or equal to the second quantity threshold, and the exception reference information indicates that there is an exception in the first process, then the first process discards the authentication request.

5. The method according to any one of claims 2-4, characterized in that, after the first process discards the authentication request according to the device capability information of the AP device and / or the process status information of the first process, the method further includes: the first process determines an exception cause according to the device capability information and / or the process status information, and the exception cause is used to indicate the reason why the AP device does not send an authentication response to the STA device; wherein, the indication information further includes the exception cause.

6. The method according to any one of claims 3-5, characterized in that, the determination method of the waiting duration is: When the exception reference information indicates that there is no exception in the first process, the waiting duration is inversely proportional to the CPU idle rate, and the waiting duration is directly proportional to the first quantity, and the waiting duration is directly proportional to the number of messages, or, When the exception reference information indicates that there is an exception in the first process, the waiting duration is the restart time of the first process.

7. The method according to any one of claims 1-6, 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 times out, the first driver determines the waiting duration according to the device capability information of the AP device, and the response message includes an authentication response and the indication information; The first driver generates the indication information according to the waiting duration.

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

9. The method according to any one of claims 2-4, characterized in that, The method further includes: The first driver determines the cause of the exception according to the device capability information, and the cause of the exception is used to indicate the reason why the AP device does not send an authentication response to the STA device; Wherein, the indication information further includes the cause of the exception.

10. A device access method, characterized in that, Applied to an STA device, the method includes: Sending an authentication request to the AP device; Receiving the indication information sent by the AP device, and the indication information is used to indicate that the STA device initiates access to the AP device after a waiting duration; Initiating access to the AP device after the waiting duration of receiving the indication information.

11. The method according to claim 10, characterized in that, The indication information further includes the cause of the exception, and the cause of the exception is used to indicate the reason why the AP device does not send an authentication response to the STA device.

12. An electronic device, characterized in that, Comprising: A processor and a memory; The memory stores computer execution instructions; The processor executes the computer execution instructions stored in the memory, so that the electronic device executes the method according to any one of claims 1-11.

13. A computer-readable storage medium, the computer-readable storage medium stores a computer program, characterized in that, When the computer program is executed by a processor, it implements the method according to any one of claims 1-11.

14. A chip system, characterized in that, Comprising at least one processor and a communication interface, the communication interface and the at least one processor are interconnected by a line, and the at least one processor is configured to run a computer program or instructions to execute the method according to any one of claims 1-11.

15. A computer program product, characterized in that it includes a computer program which, when run, causes a computer to execute the method according to any one of claims 1-11.

Images