Method and apparatus for determining a cause of a communication link interruption

Abstract

The embodiment of the present application provides a kind of communication link interruption reason determination method and equipment, the method comprises: in the process of bluetooth encryption start, obtain decryption data packet and receive abnormal result;If the receive abnormal result indicates that the decryption data packet exists receiving exception, then the decryption data packet is identified, to determine whether the original data packet before decryption is connection termination control packet;According to whether the original data packet is connection termination control packet, report communication link interruption reason.Utilize this method, if indicating decryption data packet exists receiving exception in the process of bluetooth encryption start, then whether the original data packet before decryption is connection termination control packet is correctly identified by the characteristics of data packet identification, according to whether the original data packet is connection termination control packet, report communication link interruption reason, avoid false report disconnect reason, ensure that equipment can still accurately identify real disconnect reason under complex link state, improve communication stability and system robustness.

Description

Technical Field

[0001] This invention relates to the field of wireless communication technology, and in particular to a method and apparatus for determining the cause of communication link interruption. Background Technology

[0002] The Bluetooth communication protocol consists of multiple layers, with the Link Layer being the core layer responsible for establishing, maintaining, and terminating connections. In Bluetooth Low Energy (BLE), the Link Layer handles low-level operations such as sending, receiving, encrypting, and decrypting data packets. Once a BLE connection is established between the central and peripheral Bluetooth devices, an encryption startup process is executed to enable encrypted communication and ensure data transmission security.

[0003] Before the BLE encryption process is complete, the master and slave Bluetooth devices can still send certain control packets, such as LL_TERMINATE_IND, to actively disconnect. However, because the link layer enters the "encrypted receive state" prematurely, the received unencrypted LL_TERMINATE_IND is misinterpreted and reported as a Message Integrity Code Error (MIC Error), thus failing to correctly obtain the true reason for the peer's active disconnection. Summary of the Invention

[0004] This invention provides a method and device for determining the cause of communication link interruption, enabling the device to accurately identify the real cause of disconnection even under complex link conditions, thereby improving communication stability and system robustness.

[0005] Firstly, this embodiment provides a method for determining the cause of a communication link interruption, the method comprising: During the Bluetooth encrypted startup process, the decryption data packet is acquired and the abnormal result is received. If the received abnormal result indicates that the decrypted data packet has a received abnormality, then the decrypted data packet is subjected to feature identification to determine whether the original data packet before decryption is a connection termination control packet; Based on whether the original data packet is a connection termination control packet, report the reason for the communication link interruption.

[0006] Secondly, this embodiment provides a method for determining the cause of a communication link interruption, the method comprising: During the Bluetooth encrypted startup process, the original data packet is acquired and abnormal results are received. If the received error result indicates that the original data packet has a received error, then determine whether the original data packet is a connection termination control packet; Based on whether the original data packet is a connection termination control packet, report the reason for the communication link interruption.

[0007] Thirdly, this embodiment provides a Bluetooth device, including: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, which enables the at least one processor to perform the method for determining the cause of communication link interruption as described in any embodiment of the present invention.

[0008] This invention provides a method and device for determining the cause of a communication link interruption. The method includes: during Bluetooth encryption startup, acquiring a decryption data packet and a reception anomaly result; if the reception anomaly result indicates that the decryption data packet has a reception anomaly, then performing feature recognition on the decryption data packet to determine whether the original data packet before decryption is a connection termination control packet; and reporting the cause of the communication link interruption based on whether the original data packet is a connection termination control packet. This technical solution, during Bluetooth encryption startup, if it indicates that the decryption data packet has a reception anomaly, correctly identifies whether the original data packet before decryption is a connection termination control packet by identifying the data packet's features, and reports the cause of the communication link interruption based on whether the original data packet is a connection termination control packet. This avoids erroneous reporting of disconnection causes, ensuring that the device can accurately identify the true disconnection cause even in complex link conditions, improving communication stability and system robustness. Furthermore, it does not require modification of the Bluetooth standard, possessing extremely high practical feasibility and versatility.

[0009] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This is a flowchart illustrating a method for determining the cause of a communication link interruption according to Embodiment 1 of the present invention. Figure 2 This is a flowchart illustrating another method for determining the cause of communication link interruption provided in Embodiment 2 of the present invention; Figure 3 This is a flowchart illustrating a method for determining the cause of communication link interruption in a certain application scenario, as provided in Embodiment 2 of the present invention. Figure 4 This is a flowchart illustrating another method for determining the cause of communication link interruption provided in Embodiment 3 of the present invention; Figure 5 This is a flowchart illustrating another method for determining the cause of communication link interruption provided in Embodiment 4 of the present invention; Figure 6 This is a schematic diagram of the structure of a Bluetooth device provided in Embodiment 5 of the present invention. Detailed Implementation

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

[0013] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0014] The following section introduces the existing technology, starting with an overview of the Bluetooth link layer and encryption process. The Bluetooth communication protocol consists of multiple layers, with the link layer being the core layer responsible for establishing, maintaining, and terminating connections. In BLE, the link layer is responsible for low-level operations such as sending, receiving, encrypting, and decrypting data packets. Once a BLE connection is established between two devices (usually referred to as the master and slave Bluetooth devices), to ensure data transmission security, both parties execute an Encryption Start Procedure to enable encrypted communication.

[0015] In this embodiment, the encryption startup process can be understood as at least a portion of the process from when the Bluetooth device begins executing the relevant processing for enabling encrypted communication until both communicating parties complete the encryption state switch and enter the normal encrypted communication state. During this process, the protocol allows either party to send an unencrypted connection termination control packet LL_TERMINATE_IND. If the receiving end is already in encrypted mode, it will incorrectly decrypt the connection termination control packet, thus failing to correctly identify the packet.

[0016] Secondly, the BLE encrypted boot process is explained. The BLE encrypted boot process mainly includes the following steps: Key calculation phase: Both parties calculate a temporary session key based on session parameters (such as random number and distribution key).

[0017] Initiating an encryption request from a Bluetooth device: After calculating the Session Key from the Bluetooth device's link layer, send an LL_START_ENC_REQ data packet (unencrypted).

[0018] According to the standard, at this point, the Bluetooth device is set to a state where it can receive encrypted data packets.

[0019] Master Bluetooth device responds to encryption request: After receiving LL_START_ENC_REQ, the master Bluetooth device needs to send an LL_START_ENC_RSP response packet (this packet needs to be sent encrypted).

[0020] At the same time, the main Bluetooth device also needs to be ready to receive encrypted data packets.

[0021] In other words, after the master Bluetooth device sends LL_START_ENC_RSP, the master Bluetooth device's hardware decryption logic can enter the state for receiving and decrypting encrypted data packets. After sending LL_START_ENC_REQ from the Bluetooth device, it can also enter the same decryption and reception state.

[0022] In real-world protocol implementations, data packet decryption is typically handled automatically by hardware: when a data packet is received, the receiving logic performs decryption as it is received (i.e., real-time decryption).

[0023] The following section describes special cases during the encryption process. According to the Bluetooth core specification, the Asynchronous Connection-Less Link (ACL) termination process can be initiated while other link layer control processes are in progress. Therefore, even before the encryption initiation process is complete, one device may still initiate a connection termination process and send an unencrypted connection termination control packet LL_TERMINATE_IND.

[0024] This means that before encryption is fully established, either party may send an unencrypted LL_TERMINATE_IND to indicate a desire to terminate the current connection. However, the peer's link layer may already be in the "receive encrypted data packets" state. Therefore, in some implementations, if the receiving end receives an unencrypted connection termination control packet after entering the encrypted data packet receiving state, it may process the packet as an encrypted packet, resulting in a message integrity check error or other reception anomalies. Some hardware implementations may also report a length field error (LengthError). For example, when the receiving end processes the unencrypted connection termination control packet according to the encrypted data packet format, its length information does not match the expected format of the encrypted data packet. Specifically, some hardware implementations will report a length field error (Length Error) because encrypted data packets require at least 4 bytes in length, while the plaintext LL_TERMINATE_IND is only 2 bytes. Different hardware implementations have different methods, but they generally cannot correctly report the true reason carried by LL_TERMINATE_IND. For ease of description, the following uses the example of hardware reporting a MIC error to illustrate this. In the current implementation, the system mistakenly interprets such MIC errors as "decryption failure" or "data corruption" and reports them directly to the application layer. As a result, the application layer cannot know the actual reason for the disconnection (such as timeout, user-initiated disconnection, etc.), leading to misjudgment by the upper-layer logic.

[0025] For example, consider the following scenario: The master Bluetooth device sends LL_START_ENC_RSP, entering "receive encrypted packet" mode; the slave Bluetooth device waits for a response from the peer; the slave Bluetooth device needs to disconnect and sends an unencrypted LL_TERMINATE_IND; the master Bluetooth device receives the packet but incorrectly attempts to decrypt it, detecting a MIC Error; the master Bluetooth device reports the MIC Error to the application layer, but the application layer cannot know the true reason for the disconnection. This results in a hardware malfunction during decryption, where a normal disconnection is mistakenly interpreted as an encryption failure, and the user or application cannot know the true reason for the disconnection. Therefore, a method is needed to solve this problem.

[0026] Example 1 Figure 1 This is a flowchart illustrating a method for determining the cause of a communication link interruption according to Embodiment 1 of the present invention. This method is applicable to situations where the cause of a communication link interruption needs to be determined. This method can be executed by a device for determining the cause of a communication link interruption. The device for determining the cause of a communication link interruption can be implemented in hardware and / or software and is generally integrated into a Bluetooth device.

[0027] like Figure 1As shown, the method for determining the cause of communication link interruption provided in this embodiment can specifically include the following steps: S101. During the Bluetooth encryption startup process, acquire the decryption data packet and receive abnormal results.

[0028] It should be noted that after receiving a data packet, the device will generally first check whether the Cyclic Redundancy Check (CRC) is correct. Only if the CRC is correct will it check whether there is a message integrity check error (MIC Error). Therefore, when the hardware reports a MIC Error, it is usually because the CRC is correct.

[0029] In some embodiments, the cyclic redundancy check (CR) of the received data packet is determined to be successful before connection termination control packet identification. Connection termination control packet identification is performed in response to a successful CR and a failed message integrity check. If the CR fails, the received data packet is discarded or processed according to the reception error procedure, without performing connection termination control packet identification.

[0030] In this embodiment, the original data packet can be specifically understood as a link-layer data packet received by the Bluetooth device from the communication link that has not yet been decrypted by the current receiving end, or a portion of it that needs to be decrypted. The decrypted data packet can be specifically understood as the data obtained by the receiving end performing decryption operations on the portion of the original data packet that is considered encrypted, according to the decryption parameters of the current connection. It is understood that the original data packet may actually be an encrypted data packet, or it may be a data packet sent in unencrypted form under a specific protocol state but mistakenly treated as an encrypted data packet by the receiving end. The reception anomaly result can be specifically understood as the verification result of the decrypted data packet. For example, the reception anomaly result may be whether the decryption is abnormal, whether the message integrity check is incorrect, whether the length field is incorrect, or other results indicating whether there is a mismatch between the received data packet and the current decryption state. Preferably, the reception anomaly result includes whether the message integrity check is incorrect and / or whether the length field is incorrect.

[0031] In some embodiments, the decryption of data packets and the message integrity check can be implemented by hardware, software, or a combination of both. Under different implementation methods, the data formats that subsequent processing modules can obtain can be different.

[0032] In some embodiments, decryption and message integrity checks are performed on the received data packets to obtain decrypted data and message integrity check results. Specifically, during Bluetooth encryption startup, the subsequent processing module can obtain the decrypted data packets obtained after decrypting the original data packets and the corresponding message integrity check results (MICs), but cannot directly obtain or access the original data packets before decryption. For example, in one implementation, decryption and message integrity checks are performed by hardware, and the software can obtain the decrypted data packets and message integrity check results provided by the hardware. The decrypted data packets are obtained by the hardware after decrypting the received original data packets, and the message integrity check results are also generated by the hardware during the decryption process and provided to the software to indicate the integrity and validity of the decrypted data packets. This embodiment mainly describes the situation where the subsequent processing module cannot directly obtain or access the original data packets.

[0033] In some embodiments, the received data packets are decrypted and their length fields are checked. When the receiving end processes the received data packets according to the format of the encrypted data packets, it determines whether the length information matches the expected format of the encrypted data packets and determines the length field check result.

[0034] S102. If the received abnormal result indicates that the decrypted data packet has a received abnormality, then the decrypted data packet is subjected to feature identification to determine whether the original data packet before decryption is a connection termination control packet.

[0035] Preferably, the reception anomaly includes message integrity check errors and / or length field errors. In one scenario, the reception anomaly may include a message integrity check error; in another, it may include a length field error; and in yet another, it may include both a message integrity check error and a length field error. The core function of Message Integrity Check (MIC) is to verify the integrity of transmitted data and detect whether the data has been tampered with during transmission. In some implementations, after the receiving end has entered the state of receiving encrypted data packets, if it receives a connection termination control packet sent in unencrypted form, it may process the packet as an encrypted data packet, generating a message integrity check error or other reception anomalies. Some hardware implementations may also report a length field error. For example, when the receiving end processes the unencrypted connection termination control packet according to the format of the encrypted data packet, its length information does not match the expected format of the encrypted data packet. Specifically, some hardware implementations will report a length field error because encrypted data packets require at least 4 bytes in length, while the plaintext LL_TERMINATE_IND is only 2 bytes.

[0036] Unlike existing technologies, where an attempt is made to decrypt a connection termination control packet (LL_TERMINATE_IND) sent by a peer device, resulting in a message integrity check error being reported or a length field error, in this embodiment, if an abnormal result indicates that the decrypted data packet has a reception abnormality during the encryption startup process, the device does not immediately report the error. Instead, it first suspends the reception abnormality reporting, and then performs feature identification on the decrypted data packet to determine whether it matches the characteristics of a connection termination control packet.

[0037] In this embodiment, if the reception anomaly result indicates a reception anomaly in the decrypted data packet, feature identification is performed on the decrypted data packet to determine whether the original data packet before decryption is a connection termination control packet. There are no specific limitations on the method for determining whether it conforms to the characteristics of a connection termination control packet. For example, the packet data can be restored to its original state before decryption to determine if it conforms to the characteristics of a connection termination control packet. Alternatively, the decrypted data packet can be parsed to obtain its link identifier to determine if it conforms to the characteristics of a connection termination control packet. Or, the decrypted data packet can be parsed to obtain its link identifier and a length field representing the payload length to determine if it conforms to the characteristics of a connection termination control packet.

[0038] It should be noted that if the message integrity check and length field of the decrypted data packet are correct, the Bluetooth encryption startup process will continue.

[0039] S103. Report the reason for the communication link interruption based on whether the original data packet is a connection termination control packet.

[0040] In this embodiment, if the original data packet is a connection termination control packet, the peer's active disconnection is reported as the reason for the communication link interruption. The disconnection reason can also be further parsed and reported. If the original data packet is not a connection termination control packet, the reception exception result is reported according to the normal procedure. For example, the reason for the communication link interruption is reported to the application layer, reported to the protocol stack, written to the event register, or written to the log.

[0041] It should be noted that the above technical solution can be implemented in the protocol stack link layer software (Link Layer Controller) or in the hardware BLE controller firmware (LLC Firmware) layer, without modifying the Bluetooth core protocol standard, and has good compatibility.

[0042] Understandably, in this embodiment, the receiving end has enabled decryption, but the peer end sends a connection termination control packet that is allowed to be sent unencrypted during the transition state. The plaintext connection termination control packet is incorrectly decrypted, generating a seemingly genuine MIC error. Then, by utilizing the structural characteristics of the unencrypted packet and the reversible recovery mechanism for error decryption, the true authentication failure and the pseudo-MIC error caused by protocol state misalignment are distinguished. During the encrypted state transition phase where the Bluetooth device has enabled receive decryption processing but the peer end is still sending unencrypted connection termination control packets, the system effectively distinguishes between message integrity check errors caused by genuine encrypted data anomalies and message integrity check errors caused by the incorrect decryption of the unencrypted connection termination control packet, and accurately obtains the connection termination reason indicated by the peer end.

[0043] The above technical solution, if an abnormality is detected in the decryption data packet during the Bluetooth encryption startup process, correctly identifies whether the original data packet before decryption is a connection termination control packet by recognizing the characteristics of the data packet. Based on whether the original data packet is a connection termination control packet, the reason for the communication link interruption is reported, avoiding incorrect reporting of the disconnection reason. This ensures that the device can accurately identify the real disconnection reason even in complex link conditions, improving communication stability and system robustness. At the same time, it does not require modification of the Bluetooth standard and has extremely high practical feasibility and versatility.

[0044] Example 2 Figure 2 This is a flowchart illustrating another method for determining the cause of communication link interruption provided in Embodiment 2 of the present invention. This embodiment is a further optimization of the above embodiment. In this embodiment, the limitation optimizations are made to "perform feature recognition on the decrypted data packet to determine whether the original data packet before decryption is a connection termination control packet" and "report the cause of communication link interruption based on whether the original data packet is a connection termination control packet".

[0045] like Figure 2 As shown in the figure, this embodiment 2 provides a method for determining the cause of communication link interruption, which specifically includes the following steps: S201. During the Bluetooth encryption startup process, obtain the decryption data packet and receive the abnormal result.

[0046] S202. If the received error result indicates that the decrypted data packet has a received error, then parse the header of the decrypted data packet to obtain the link identifier in the decrypted data packet used to indicate the data packet type.

[0047] In this embodiment, to reduce unnecessary restoration processing and save processor overhead, a filtering condition can be added before performing the restoration. That is, instead of restoring the decrypted data packet, the Logical Link Identifier (LLID) in the data packet, which indicates the data packet type, is used to determine whether the original data packet is a connection termination control packet. Specifically, the header of the decrypted data packet is parsed to obtain the LLID indicating the data packet type.

[0048] S203. If the link identifier is not a control packet identifier, then it is determined that the original data packet is not a connection termination control packet.

[0049] Given that the connection termination control packet is a control packet, if the link identifier of the decrypted data packet is not a control packet identifier, then it is determined that its original data packet is not a connection termination control packet.

[0050] S204. If the link identifier is a control packet identifier, then further feature identification is performed on the decrypted data packet to determine whether the original data packet is a connection termination control packet.

[0051] Specifically, if the link identifier of the decrypted data packet is a control packet, further feature identification is performed on the decrypted data packet. For example, the length field representing the payload length of the decrypted data packet is parsed to determine whether the original data packet is a connection termination control packet based on whether the length field meets the requirements of the length field in the connection termination control packet. Alternatively, the decrypted data packet can be restored to obtain the original data packet, and then its identity can be determined based on whether the original data packet conforms to the characteristics of a connection termination control packet. The term "restoration processing" in this document refers to performing corresponding operations on the data obtained after decryption based on the cryptographic operation parameters used by the receiving end when performing decryption processing on the unencrypted original data packet, in order to restore the original data content before decryption processing.

[0052] As a specific implementation, the step of further feature identification of the decrypted data packet to determine whether the original data packet is a connection termination control packet can be optimized, including: a1) Based on the header of the decrypted data packet, obtain the effective payload length of the decrypted data packet.

[0053] In this embodiment, to reduce unnecessary restoration processing and save processor overhead, the length field representing the payload length of the decrypted data packet can be parsed. This allows for further determination of whether the original data packet is a connection termination control packet based on whether the length field meets the requirements of the length field in the connection termination control packet. Specifically, the header of the decrypted data packet is parsed to obtain the payload length of the decrypted data packet.

[0054] b1) If the payload length does not meet the set value, then the original data packet is determined not to be a connection termination control packet.

[0055] Considering the connection termination control packet's length, i.e., the payload length, is 2 bytes, the setting is set to the payload length of the connection termination control packet, which can be set to 2 bytes. It then checks if the payload length of the decrypted data packet is equal to the setting value. If its payload length does not meet the setting value, it is determined that the original data packet is not a connection termination control packet.

[0056] c1) If the payload length meets the set value, then the original data packet is determined to be a connection termination control packet.

[0057] In this embodiment, if the payload length of the decrypted data packet meets the set value, the original data packet is determined to be a connection termination control packet.

[0058] The above technical solution specifies the steps for determining whether the original data packet is a connection termination control packet. It determines whether the original data packet is a connection termination control packet based on the link identifier and the payload length. This can be implemented quickly at the hardware level and provides a basis for reporting the cause of communication link interruption.

[0059] As another specific implementation, the step of further feature identification of the decrypted data packet to determine whether the original data packet is a connection termination control packet can be optimized, including: a2) Based on the header of the decrypted data packet, obtain the effective payload length of the decrypted data packet.

[0060] To reduce unnecessary restoration processing and save processor overhead, the length field representing the payload length of the decrypted data packet can be parsed. This allows for further analysis based on whether the length field meets the requirements of the length field in a connection termination control packet, thereby determining whether the original data packet is a connection termination control packet. Specifically, the header of the decrypted data packet is parsed to obtain the payload length of the decrypted data packet.

[0061] b2) If the payload length does not meet the set value, then the original data packet is determined not to be a connection termination control packet.

[0062] Considering the connection termination control packet's length, i.e., the payload length, is 2 bytes, the setting is set to the payload length of the connection termination control packet, which can be set to 2 bytes. It then checks if the payload length of the decrypted data packet is equal to the setting value. If its payload length does not meet the setting value, it is determined that the original data packet is not a connection termination control packet.

[0063] c2) If the payload length meets the set value, then further feature identification is performed on the decrypted data packet to determine whether the original data packet is a connection termination control packet.

[0064] In this embodiment, if the payload length meets the set value, further feature identification, such as restoration processing, is performed on the decrypted data packet to obtain the original data packet. Then, based on whether the features of the original data packet meet the features of the connection termination control packet, it is determined whether the original data packet is a connection termination control packet.

[0065] The above technical solution provides another way to determine whether the original data packet is a connection termination control packet. Based on the link identifier, payload length, and restoration processing, it can accurately determine whether the original data packet is a connection termination control packet, providing a basis for subsequent reporting of the cause of communication link interruption.

[0066] As a specific implementation, the step of further feature identification of the decrypted data packet to determine whether the original data packet is a connection termination control packet can be optimized, including: c21) The decrypted data packet is restored to obtain the original data packet before decryption.

[0067] Specifically, since decrypting a data packet is obtained by decrypting the original data packet, restoring the decrypted data packet can yield the original data packet before decryption.

[0068] In some embodiments, Bluetooth encryption employs a counter-based encryption / decryption operation. The receiving end can store or retrieve the cryptographic parameters used to decrypt the received original data packet. These parameters may include a session key, initialization vector, packet count value, communication direction indicator, and / or other parameters used to generate the cipher stream. Before determining that recovery processing is necessary, the receiving end can store the cryptographic parameters corresponding to the erroneous decryption; or retrieve the corresponding cryptographic parameters based on the connection context. Specifically, the receiving end can retain the packet count value corresponding to the current data packet before completing the message integrity check; if the message integrity check fails, the corresponding cryptographic parameters are not released or are overwritten.

[0069] When the received original data packet is actually an unencrypted data packet, but the receiving end performs a decryption operation on it according to the encrypted data packet, the resulting decrypted data is the result of the operation between the unencrypted data and the corresponding cryptographic stream. The receiving end can use the same cryptographic operation parameters to perform the corresponding reverse operation on the decrypted data, thereby recovering at least part of the content of the received original data packet before the erroneous decryption.

[0070] In some embodiments, if the decryption process employs a data transformation method based on a cryptographic stream, there is a reversible operational relationship between the original data before erroneous decryption and the decrypted data obtained after erroneous decryption. For example, suppose the received unencrypted original data is P, and the cryptographic stream generated according to the cryptographic operation parameters corresponding to the current connection is KS. After the receiving end erroneously processes the original data as encrypted data, the resulting decrypted data D can be expressed as D=P⊕KS, where "⊕" represents an XOR operation. Since performing an XOR operation twice consecutively on the same data and the same cryptographic stream can recover the data, the receiving end can generate the same cryptographic stream KS again based on the same cryptographic operation parameters and perform an XOR operation on the decrypted data D to obtain D⊕KS=P, thereby recovering the original data before erroneous decryption. Thus, even if the receiving end has already performed decryption processing on the unencrypted data packet, it can still recover at least a portion of the original data packet based on the cryptographic operation parameters used when performing the decryption processing.

[0071] In other embodiments, the receiving end can save the cipher stream generated during the erroneous decryption process and use the saved cipher stream to recover the data content before the erroneous decryption. At the hardware level, even if MIC verification fails, the decryption result can still be saved in an accessible buffer.

[0072] c22) Perform type identification on the original data packet to obtain the type of the original data packet.

[0073] In this embodiment, the original data packet is type-identified to determine whether it meets the characteristics of a connection termination control packet, thus obtaining the type of the original data packet. Specifically, it is determined whether the opcode of the original data packet is the opcode of a connection termination control packet (LL_TERMINATE_IND).

[0074] c23) If the type of the original data packet is a connection termination control packet, then the original data packet is determined to be a connection termination control packet.

[0075] Specifically, if the opcode of the original data packet is the opcode of a connection termination control packet, it is equivalent to the type of the original data packet being a connection termination control packet, then the original data packet is determined to be a connection termination control packet.

[0076] c24) If the type of the original data packet is not a connection termination control packet, then the original data packet is determined to be a connection termination control packet.

[0077] Specifically, if the opcode of the original data packet is not the opcode of the connection termination control packet, it is equivalent to the type of the original data packet not being the type of the connection termination control packet, and therefore the original data packet is determined not to be a connection termination control packet.

[0078] The above technical solution specifies the steps for restoring the original data packet before the decryption operation to determine whether the original data packet is a connection termination control packet, providing a basis for subsequent reporting of the cause of communication link interruption.

[0079] S205. If the original data packet is not a connection termination control packet, then the abnormal reception result shall be used as the cause of the communication link interruption and reported.

[0080] In this embodiment, if the original data packet is not a connection termination control packet, it is determined that the decrypted data packet is indeed a message integrity check error and / or a length field error. When a message integrity check error occurs, the current connection is terminated or instructed to terminate according to a preset exception handling procedure. Therefore, the message integrity check error is treated as the cause of the communication link interruption and reported. Similarly, when a length field error occurs, the current connection is terminated or instructed to terminate according to a preset exception handling procedure. Therefore, the length field error is treated as the cause of the communication link interruption and reported. Furthermore, when both message integrity check errors and length field errors occur, the current connection is terminated or instructed to terminate according to a preset exception handling procedure. Therefore, both message integrity check errors and length field errors are treated as the cause of the communication link interruption and reported. For example, the reporting method could be reporting the communication link interruption cause to the application layer, to the protocol stack, writing to the event register, or writing to the log, etc.

[0081] S206. If the original data packet is a connection termination control packet, then the active disconnection by the peer end is taken as the reason for the interruption of the communication link and reported.

[0082] In this embodiment, if the original data packet is a connection termination control packet, which is equivalent to the peer sending a connection termination control packet, then the reason for the disconnection is determined to be that the peer actively disconnected by sending a connection termination control packet. Therefore, the peer actively disconnected is taken as the reason for the communication link interruption and reported.

[0083] The above technical solution specifies the steps for feature identification of decrypted data packets to determine whether the original data packet is a connection termination control packet, and the steps for reporting the cause of communication link interruption based on whether the original data packet is a connection termination control packet. By introducing a message integrity check error secondary identification and data packet restoration judgment mechanism during the Bluetooth Low Energy encryption startup phase, the problem of mis-encryption caused by the unencrypted transmission of the connection termination control packet is solved. This ensures that the device can accurately identify the real cause of disconnection even under complex link conditions, improving communication stability and system robustness. Furthermore, it requires no modification to the Bluetooth standard, possessing extremely high practical feasibility and versatility.

[0084] As a specific implementation, when the original data packet is obtained through restoration processing, the specific reason for the other end's active disconnection can be further obtained based on the original data packet, and the specific reason for the other end's active disconnection can be used as the reason for the communication link interruption and reported.

[0085] As a specific implementation method, the step of reporting the active disconnection by the peer as the cause of communication link interruption can be optimized, including: Based on the original data packet, the reason for the other end's active disconnection is obtained and the reason for the other end's active disconnection is used as the reason for the communication link interruption and reported.

[0086] In this embodiment, if the original data packet is a connection termination control packet, it indicates that the peer has initiated connection termination. Upon receiving the connection termination control packet sent by the peer, it is treated as a link interruption event type. The connection termination reason field in the original data packet is parsed to obtain the specific reason for the peer's active disconnection, and this reason is reported to the application layer as the communication link interruption reason.

[0087] The above technical solution specifies the steps for taking the other end's active disconnection as the cause of communication link interruption. The specific reason for the other end's active disconnection can be obtained by software parsing the original data packets.

[0088] To more clearly illustrate the method for determining the cause of communication link interruption provided in this embodiment of the invention, a practical application scenario for determining the cause of a communication link interruption will be used as an example. For instance, Figure 3 This is a flowchart illustrating a method for determining the cause of communication link interruption in a certain application scenario, as provided in Embodiment 2 of the present invention. Figure 3 As shown, the specific steps of the method for determining the cause of communication link interruption may include: S1. Reception Phase: After the device receives a data packet (and the CRC has been verified to be correct), it enters the MIC verification phase.

[0089] S2. Obtain the MIC verification result and determine whether there is a MIC Error. If yes, proceed to step S4; otherwise, proceed to step S3.

[0090] S3. If the MIC is correct: This means the data packet has been correctly encrypted and decrypted, and should be processed according to normal logic.

[0091] S4. If MIC Error: Enter the abnormal packet identification process, determine whether the LLID is a control packet. If not, proceed to step S9. If yes, proceed to step S5, and only perform further analysis on the control packet (Control PDU).

[0092] S5. Determine if Length is 2. If not, proceed to step S9. If yes, proceed to step S6. Only control packets with a length of 2 are restored (i.e., they may be LL_TERMINATE_IND).

[0093] S6. Restore the original data packet before decryption.

[0094] S7. Determine if the original data packet is LL_TERMINATE_IND. If not, proceed to step S9. If yes, proceed to step S8.

[0095] S8. If it is determined to be LL_TERMINATE_IND, then parse its connection termination reason field and report the correct disconnection reason.

[0096] S9. Otherwise, report a normal MIC error.

[0097] To illustrate with a practical application scenario, consider this example: A master Bluetooth device and a slave Bluetooth device are negotiating encryption. After sending LL_START_ENC_RSP, the master Bluetooth device enters the encrypted receiving state. If the slave Bluetooth device actively disconnects due to a timeout, it sends an unencrypted LL_TERMINATE_IND packet. The master Bluetooth device mistakenly attempts to decrypt this packet and encounters a MICError. Using the method provided in this embodiment, the master Bluetooth device recognizes that the packet's CRC is correct but its content is abnormal. It restores the packet and finds that its structure conforms to LL_TERMINATE_IND (LLID = control packet, length = 2). Therefore, it parses the connection termination reason field and reports "connection actively disconnected." This prevents the application layer from receiving an incorrect "encryption failure" event.

[0098] As can be seen, the method provided in this embodiment performs a secondary judgment on MIC Error to avoid false alarms and can correctly identify LL_TERMINATE_IND; it also supports obtaining the real disconnection reason, and the application layer can accurately know the root cause of the connection termination; in addition, it can reduce false reporting and reduce the burden of upper-layer reconnection or error recovery logic; it has good hardware compatibility, does not require modification of standard protocols, and is only implemented at the control logic layer.

[0099] Example 3 Figure 4 This is a flowchart illustrating another method for determining the cause of communication link interruption provided in Embodiment 3 of the present invention. This device is applicable to situations where the cause of communication link interruption needs to be determined. The method for determining the cause of communication link interruption can be implemented by the device for determining the cause of communication link interruption in hardware and / or software, and is generally integrated into Bluetooth devices.

[0100] like Figure 4As shown, the method for determining the cause of communication link interruption provided in this embodiment three may specifically include the following steps: S301. During the Bluetooth encryption startup process, acquire the original data packet and receive abnormal results.

[0101] In some implementations, the decryption of received data packets and message integrity checks can be performed by software. In this case, the software can obtain or access the received original data packet before performing decryption. Therefore, even if the message integrity check fails, the original data packet can still be retained or obtained without needing to recover the original data packet from the decrypted data. Connection termination control packet identification can be performed directly based on the original data packet. In other implementations, even if the decryption and message integrity checks are performed by hardware or a combination of hardware and software, as long as the subsequent processing module can obtain or access the original data packet in the event of a reception anomaly such as a message integrity check failure or a length field error, the above-described method of identification based directly on the original data packet can also be used. This embodiment mainly describes the case where the original data packet can be directly obtained or accessed.

[0102] Specifically, the original data packet can be understood as a link-layer data packet received by the Bluetooth device from the communication link that has not yet been decrypted by the current receiving end, or a portion of it awaiting decryption. The reception anomaly result can be understood as the verification result of the original data packet. For example, the reception anomaly result could be whether the message integrity check is incorrect, whether the length field is incorrect, or other results indicating whether there is a mismatch in the received original data packet. Preferably, the reception anomaly result includes whether the message integrity check is incorrect and / or whether the length field is incorrect.

[0103] In some embodiments, a message integrity check is performed on the received raw data packet, and the message integrity check result is used as a reception anomaly result. In some embodiments, a length field verification is performed on the received raw data read to determine whether the raw data packet matches the expected format, and the length field verification result is used as a reception anomaly result. In some embodiments, both message integrity check and length field verification are performed on the received raw data packet, and the message integrity check result and length field verification result are used as reception anomaly results.

[0104] S302. If the received error result indicates that the original data packet has a received error, then determine whether the original data packet is a connection termination control packet.

[0105] Preferably, the reception anomaly includes message integrity check errors and / or length field errors. In one scenario, the reception anomaly may include a message integrity check error; in another, it may include a length field error; and in yet another, it may include both a message integrity check error and a length field error. The core function of Message Integrity Check (MIC) is to verify the integrity of transmitted data and detect whether the data has been tampered with during transmission. In some implementations, after the receiving end has entered the state of receiving encrypted data packets, if it receives a connection termination control packet sent in unencrypted form, it may process the packet as an encrypted data packet, generating a message integrity check error or other reception anomalies. Some hardware implementations may also report a length field error. For example, when the receiving end processes the unencrypted connection termination control packet according to the format of the encrypted data packet, its length information does not match the expected format of the encrypted data packet. Specifically, some hardware implementations will report a length field error because encrypted data packets require at least 4 bytes in length, while the plaintext LL_TERMINATE_IND is only 2 bytes.

[0106] In this embodiment, if the reception error result indicates that the original data packet has a reception error, the error is not reported immediately. Instead, reception error reporting is paused first, and then it is determined whether the original data packet is a connection termination control packet. As a specific implementation, the step of determining whether the original data packet is a connection termination control packet can be described as follows: parse the header of the original data packet to obtain the link identifier, payload length, and opcode of the original data packet; if the link identifier is a control packet identifier, the payload length meets the set value, and the opcode is the opcode corresponding to a connection termination control packet, then the original data packet is determined to be a connection termination control packet; otherwise, the original data packet is determined not to be a connection termination control packet.

[0107] S303. Report the reason for the communication link interruption based on whether the original data packet is a connection termination control packet.

[0108] In this embodiment, if the original data packet is not a connection termination control packet, the abnormal reception result is used as the cause of the communication link interruption and reported. For example, the reporting method could be to report the cause of the communication link interruption to the application layer, to the protocol stack, write to the event register, or write to the log. If the original data packet is a connection termination control packet, it is equivalent to the peer sending a connection termination control packet, so the cause of the disconnection is determined to be that the peer actively disconnected by sending a connection termination control packet. Therefore, the peer's active disconnection is used as the cause of the communication link interruption and reported. Specifically, based on the original data packet, the cause of the peer's active disconnection is obtained and used as the cause of the communication link interruption and reported.

[0109] The above technical solution, if an abnormal result is received during the Bluetooth encryption startup process indicating that the original data packet has a reception abnormality, correctly identifies whether the original data packet is a connection termination control packet. Based on whether the original data packet is a connection termination control packet, it reports the reason for the communication link interruption, avoiding the incorrect reporting of the disconnection reason. This ensures that the device can still accurately identify the real disconnection reason under complex link conditions, improving communication stability and system robustness. At the same time, it does not require modification of the Bluetooth standard, and has extremely high practical feasibility and versatility.

[0110] Example 4 Figure 5 This is a flowchart illustrating another method for determining the cause of communication link interruption provided in Embodiment 4 of the present invention. This embodiment is a further optimization of the above embodiment. In this embodiment, the limitation optimization of "determining whether the original data packet is a connection termination control packet" and the limitation optimization of "reporting the cause of communication link interruption based on whether the original data packet is a connection termination control packet" are further optimized.

[0111] S401. During the Bluetooth encryption startup process, acquire the original data packet and receive abnormal results.

[0112] S402. If the reception error result indicates that the original data packet has a reception error, then parse the header of the original data packet to obtain the link identifier, payload length and opcode of the original data packet.

[0113] In this embodiment, the header of the original data packet is parsed to obtain the Link Identifier (LLID) field indicating the data packet type, the length field of the payload length, and the opcode field. Then, it is determined whether the Link Identifier is a control packet identifier, whether the payload length meets the requirements of the length field in the connection termination control packet, and whether the opcode is the opcode of the connection termination control packet (LL_TERMINATE_IND), so as to determine whether the original data packet is a connection termination control packet.

[0114] S403. If the link identifier is a control packet identifier, the payload length meets the set value, and the opcode is the opcode corresponding to the connection termination control packet, then the original data packet is determined to be a connection termination control packet.

[0115] In this embodiment, considering that the packet length of the connection termination control packet, i.e., the payload length, is 2 bytes, the setting value is set to the payload length of the connection termination control packet, which can be set to 2 bytes. Specifically, if the link identifier is the control packet identifier, the payload length meets the setting value, and the opcode is the opcode corresponding to the connection termination control packet, that is, the original data packet meets the characteristics of the connection termination control packet, then the original data packet is determined to be a connection termination control packet.

[0116] S404. If the link identifier is not a control packet identifier, or the payload length does not meet the set value, or the opcode is not the opcode corresponding to the connection termination control packet, then the original data packet is determined to be a connection termination control packet, or the original data packet is determined not to be a connection termination control packet.

[0117] Specifically, if the link identifier is not a control packet identifier, or the payload length does not meet the set value, or the opcode is not the opcode corresponding to the connection termination control packet, that is, the original data packet does not meet the characteristics of the connection termination control packet, then it is determined that the original data packet is not a connection termination control packet.

[0118] S405. If the original data packet is not a connection termination control packet, then the abnormal reception result shall be used as the cause of the communication link interruption and reported.

[0119] In this embodiment, when a message integrity check error occurs, the current connection is terminated or instructed to be terminated according to a preset exception handling procedure. Therefore, the message integrity check error is treated as a communication link interruption and reported. Similarly, when a length field error occurs, the current connection is terminated or instructed to be terminated according to a preset exception handling procedure. Therefore, the length field error is treated as a communication link interruption and reported. Furthermore, when both message integrity check errors and length field errors occur, the current connection is terminated or instructed to be terminated according to a preset exception handling procedure. Therefore, both message integrity check errors and length field errors are treated as communication link interruptions and reported.

[0120] S406. If the original data packet is a connection termination control packet, then the active disconnection by the peer end shall be taken as the reason for the interruption of the communication link and reported.

[0121] In this embodiment, if the original data packet is a connection termination control packet, which is equivalent to the peer sending a connection termination control packet, then the reason for the disconnection is determined to be that the peer actively disconnected by sending a connection termination control packet. Therefore, the peer's active disconnection is taken as the reason for the communication link interruption and reported. Specifically, based on the original data packet, the reason for the peer's active disconnection is obtained and taken as the reason for the communication link interruption and reported. As a specific implementation method, the step of reporting the active disconnection of the peer as the cause of communication link interruption can be optimized, including: obtaining the cause of the active disconnection of the peer based on the original data packet and reporting the cause of the active disconnection of the peer as the cause of communication link interruption.

[0122] In this embodiment, if the original data packet is a connection termination control packet, it indicates that the peer has initiated connection termination. Upon receiving the connection termination control packet sent by the peer, it is treated as a link interruption event type. The connection termination reason field in the original data packet is then parsed to obtain the specific reason for the peer's active disconnection, which is then reported as the communication link interruption reason. The above technical solution specifies the steps for treating the peer's active disconnection as the communication link interruption reason; the specific reason for the peer's active disconnection can be obtained through software parsing of the original data packet.

[0123] The above technical solution specifies the steps for determining whether the original data packet is a connection termination control packet and the steps for reporting the cause of communication link interruption based on whether the original data packet is a connection termination control packet. By introducing a secondary identification and judgment mechanism for reception anomalies during the Bluetooth Low Energy encryption startup phase, the problem of mis-encryption caused by the unencrypted transmission of the connection termination control packet is solved. This ensures that the device can accurately identify the real cause of disconnection even under complex link conditions, improving communication stability and system robustness. Furthermore, it requires no modification to the Bluetooth standard, possessing extremely high practical feasibility and versatility.

[0124] Example 5 Figure 6 This is a schematic diagram of the structure of a Bluetooth device according to Embodiment 5 of the present invention. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the invention described and / or claimed herein.

[0125] like Figure 6 As shown, the Bluetooth device 50 includes at least one processor 51 and a memory, such as a read-only memory (ROM) 52 and a random access memory (RAM) 53, communicatively connected to the at least one processor 51. The memory stores computer programs executable by the at least one processor. The processor 51 can perform various appropriate actions and processes based on the computer program stored in the ROM 52 or loaded into the RAM 53 from storage unit 58. The RAM 53 can also store various programs and data required for the operation of the Bluetooth device 50. The processor 51, ROM 52, and RAM 53 are interconnected via a bus 54. An input / output (I / O) interface 55 is also connected to the bus 54.

[0126] Multiple components in the Bluetooth device 50 are connected to the I / O interface 55, including: an input unit 56, such as a keyboard or mouse; an output unit 57, such as various types of displays or speakers; a storage unit 58, such as a disk or optical disc; and a communication unit 59, such as a network interface card (NIC), a modem, or a wireless transceiver. The communication unit 59 allows the Bluetooth device 50 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0127] Processor 51 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 51 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 51 performs the various methods and processes described above, such as methods for determining the cause of communication link interruption.

[0128] In some embodiments, the method for determining the cause of a communication link interruption may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 58. In some embodiments, part or all of the computer program may be loaded and / or installed on the Bluetooth device 50 via ROM 52 and / or communication unit 59. When the computer program is loaded into RAM 53 and executed by processor 51, one or more steps of the method for determining the cause of a communication link interruption described above may be performed. Alternatively, in other embodiments, processor 51 may be configured to perform the method for determining the cause of a communication link interruption by any other suitable means (e.g., by means of firmware).

[0129] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0130] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0131] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0132] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A method for determining the cause of a communication link interruption, characterized in that, include: During the Bluetooth encrypted startup process, the decryption data packet is obtained and the abnormal result is received; If the received abnormal result indicates that the decrypted data packet has a received abnormality, then the decrypted data packet is subjected to feature identification to determine whether the original data packet before decryption is a connection termination control packet; Based on whether the original data packet is a connection termination control packet, report the reason for the communication link interruption.

2. The method according to claim 1, characterized in that, The received exceptions include message integrity check errors and / or length field errors.

3. The method according to claim 1, characterized in that, The step of reporting the reason for the communication link interruption based on whether the original data packet is a connection termination control packet includes: If the original data packet is not a connection termination control packet, the abnormal reception result will be used as the cause of the communication link interruption and reported. If the original data packet is a connection termination control packet, then the active disconnection by the peer end will be reported as the reason for the interruption of the communication link.

4. The method according to claim 3, characterized in that, The step of reporting the active disconnection by the peer as a cause of communication link interruption includes: Based on the original data packet, the reason for the other end's active disconnection is obtained and the reason for the other end's active disconnection is used as the reason for the communication link interruption and reported.

5. The method according to claim 1, characterized in that, The step of performing feature recognition on the decrypted data packet to determine whether the original data packet before decryption is a connection termination control packet includes: Parse the header of the decrypted data packet to obtain the link identifier in the decrypted data packet that indicates the data packet type; If the link identifier is not a control packet identifier, then the original data packet is determined not to be a connection termination control packet; If the link identifier is a control packet identifier, then the decrypted data packet is further characterized to determine whether the original data packet is a connection termination control packet.

6. The method according to claim 5, characterized in that, The step of further feature identification of the decrypted data packet to determine whether the original data packet is a connection termination control packet includes: Based on the header of the decrypted data packet, the effective payload length of the decrypted data packet is obtained; If the payload length does not meet the set value, then the original data packet is determined not to be a connection termination control packet; If the payload length meets the set value, then the original data packet is determined to be a connection termination control packet.

7. The method according to claim 5, characterized in that, The step of further feature identification of the decrypted data packet to determine whether the original data packet is a connection termination control packet includes: Based on the header of the decrypted data packet, the effective payload length of the decrypted data packet is obtained; If the payload length does not meet the set value, then the original data packet is determined not to be a connection termination control packet; If the payload length meets the set value, the decrypted data packet is further characterized to determine whether the original data packet is a connection termination control packet.

8. The method according to claim 5 or 7, characterized in that, The step of further feature identification of the decrypted data packet to determine whether the original data packet is a connection termination control packet includes: The decrypted data packet is restored to obtain the original data packet before decryption; The type of the original data packet is determined by performing type identification on the original data packet; If the type of the original data packet is a connection termination control packet, then the original data packet is determined to be a connection termination control packet; If the type of the original data packet is not a connection termination control packet, then the original data packet is determined not to be a connection termination control packet.

9. A method for determining the cause of a communication link interruption, characterized in that, include: During the Bluetooth encrypted startup process, the original data packet is acquired and abnormal results are received. If the received error result indicates that the original data packet has a received error, then determine whether the original data packet is a connection termination control packet; Based on whether the original data packet is a connection termination control packet, report the reason for the communication link interruption.

10. The method according to claim 9, characterized in that, The received exceptions include message integrity check errors and / or length field errors.

11. The method according to claim 9, characterized in that, Determining whether the original data packet is a connection termination control packet includes: Parse the header of the original data packet to obtain the link identifier, payload length, and opcode of the original data packet; If the link identifier is a control packet identifier, the payload length meets the set value, and the opcode is the opcode corresponding to the connection termination control packet, then the original data packet is determined to be a connection termination control packet. Otherwise, it is determined that the original data packet is not a connection termination control packet.

12. The method according to claim 9, characterized in that, The step of reporting the reason for the communication link interruption based on whether the original data packet is a connection termination control packet includes: If the original data packet is not a connection termination control packet, the abnormal reception result will be used as the cause of the communication link interruption and reported. If the original data packet is a connection termination control packet, then the active disconnection by the peer end will be reported as the reason for the interruption of the communication link.

13. The method according to claim 12, characterized in that, The step of reporting the active disconnection by the peer as a cause of communication link interruption includes: Based on the original data packet, the reason for the other end's active disconnection is obtained and the reason for the other end's active disconnection is used as the reason for the communication link interruption and reported.

14. A Bluetooth device, characterized in that, include: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the method for determining the cause of communication link interruption as described in any one of claims 1-13.

Images