Bluetooth keeps stopping issue (Huawei P8 Lite 2017 - PRA-LX1)

[GianlucaPolcino]

Bluetooth keeps crashing randomically on my P8 Lite 2017 (and this is my only problem with this ROM :))
This is the log:
bluetoothcrash.txt

[phhusson]

Here is relevant extract of the log:

01-22 22:54:14.986 D/bt_btif_config(28564): btif_get_address_type: Device [fa:f7:86:15:38:59] address type 1
01-22 22:54:14.986 D/bt_btif_config(28564): btif_get_device_type: Device [fa:f7:86:15:38:59] type 2
01-22 22:54:14.987 I/bt_stack(28564): [INFO:gatt_api.cc(1109)] GATT_Connectgatt_if=7 fa:f7:86:15:38:59
01-22 22:54:14.989 W/bt_stack(28564): [WARNING:btm_ble.cc(2024)] LE Create Connection attempt failed, status=0x0c
01-22 22:54:14.989 F/bt_stack(28564): [FATAL:btm_ble.cc(2032)] LE Create Connection - command disallowed

@elpollol could you describe your bluetooth systems?
Like what devices do you have connected?
Are you doing anything specific at the moment it crashes?
Were you playing music?

[GianlucaPolcino]

I wear a Mi Band 3...
Don't hate me pls
Jokes aside, the band works. Like I said, those crashes are pretty random.
I play music with a pair of bluetooth headset though, they work without problems

[phhusson]

the crashes appear only when playing music? I think that you should be able to reproduce the issue by simply forcing Mi Band to refresh data while playing music over Bluetooth. Can you try that? If it doesn't crash, then have music playing on Bluetooth and move your band away enough for it to disconnect and come close again to reconnect Le mar. 22 janv. 2019 à 23:47, elpollol <notifications@github.com> a écrit :

…

I wear a Mi Band 3... Don't hate me pls Jokes aside, the band works. Like I said, those crashes are pretty random. I play music with a pair of bluetooth headset though, they work without problems — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#376 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAOOlGsLpo0W1EjO0k68KqV0gax0JE4ks5vF5UCgaJpZM4aNppp> .

[GianlucaPolcino]

Nope, they appears without playing music.
It's only the band I suppose.
I tried to get the band away and then to get it close to the phone again: doesn't crash

UPDATE
I just find an interesting fact: I can stop the crashing loop opening Mi Fit application and simply waiting the pairing.

[penn5]

I have the same issue on my Honor 9 Lite. It crashes mostly while playing music (more often then) but can happen at any time. The sympton is that Bluetooth toggles off and on again. I remember at one point i got logs for dil3mm4, and it was a native crash. I'll see if i can find them and upload. It usually happens when multiple devices are connected (I think) but tbh its pretty random. It is not caused by a device connect or disconnect.

[penn5]

Just googling for the issue, i found this. noble/noble#658. Perhaps the adapter Huawei have used in hi6250 doesn't support scanning and connecting at the same time?

[DaveidWeba]

Using a Huawei Mate SE (essentially a Honor 7X) I can stream Bluetooth audio to a car just fine, but connecting a Honor Band 4 or other devices such as hotel rooms via Hilton's Digital Key, Bluetooth is constantly crashing and unable to successfully pair. Here's two identical logs of the crash:
https://del.dog/owupadefex
https://del.dog/agaxehusir

If there's any other data I can provide to help resolve this issue, let me know. Thank you

[penn5]

             << loghex(status);

if (status == HCI_ERR_COMMAND_DISALLOWED) {
  /* There is already either direct connect, or whitelist connection
   * pending, but we don't know which one, or to which state should we
   * transition now. This can be triggered only in case of rare race
   * condition. Crash to recover. */
  LOG(FATAL) << "LE Create Connection - command disallowed";
}

[penn5]

Reverting system/bt#f8e8c59bcb6443651fdafbccbf24910cf84ed0fe should fix it but isn't the root cause. It would just prevent the crash (meaning only the device that caused the crash ends up in a weird state, rather than the entire bluetooth service restarting).

[penn5]

From: Hackintosh 5 <penn.mackintosh@gmail.com>
Date: Thu, 7 Feb 2019 20:09:42 +0000
Subject: [PATCH] Try to fix huawei messups

---
 hci/src/hci_layer.cc | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/hci/src/hci_layer.cc b/hci/src/hci_layer.cc
index f1e0e7a60..25303843c 100644
--- a/hci/src/hci_layer.cc
+++ b/hci/src/hci_layer.cc
@@ -533,6 +533,20 @@ static void command_timed_out(void* original_wait_entry) {
     LOG_EVENT_INT(BT_HCI_TIMEOUT_TAG_NUM, HCI_UNKNOWN_COMMAND_TIMED_OUT);
   } else {
     command_timed_out_log_info(original_wait_entry);
+
+    for (const list_node_t* node = list_begin(commands_pending_response);
+      node != list_end(commands_pending_response); node = list_next(node)) { //We iterate over all pending commands, and when we get to one that is the same one that timed out, we check if it is a Huawei messup or not.
+    waiting_command_t* wait_entry =
+        reinterpret_cast<waiting_command_t*>(list_node(node));
+      if (wait_entry == original_wait_entry) { //We only care about the actual error.
+        if (wait_entry->opcode == 0x804) {
+          LOG_ERROR(LOG_TAG, "%s: ignoring a Huawei error (opcode=0x%x).", __func__, wait_entry->opcode);
+          lock.unlock();
+          return; //We don't care about Huawei. They want to kill us.
+        }
+      }
+    }
+
     lock.unlock();
   }
 
-- 
2.17.1

for system/bt
this might fix it im not sure yet

[penn5]

opcode 0x804 on my device snoop logs is almost always data from Wear OS, which is why smartwatch users see this bug more often (i think)

[penn5]

opcode 0x804 is Exit Sniff Mode according to wireshark. In my HCI log in Wireshark, it seems that there is a delay of 300ms in normal scenarios, but sometimes it takes up to 4500ms. I've increased the timeout for 0x804 to 5000ms, see patch below.

From: Hackintosh 5 <penn.mackintosh@gmail.com>
Date: Fri, 8 Feb 2019 09:31:51 +0000
Subject: [PATCH] Fix huawei timeouts

---
 hci/src/hci_layer.cc | 14 ++++++++------
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/hci/src/hci_layer.cc b/hci/src/hci_layer.cc
index f1e0e7a60..9a6e36f33 100644
--- a/hci/src/hci_layer.cc
+++ b/hci/src/hci_layer.cc
@@ -78,6 +78,8 @@ static const int BT_HCI_RT_PRIORITY = 1;
 
 // Abort if there is no response to an HCI command.
 static const uint32_t COMMAND_PENDING_TIMEOUT_MS = 2000;
+// But let the buggy Huawei commands have a longer timeout so we don't crash if there is no error.
+static const uint32_t HUAWEI_COMMAND_PENDING_TIMEOUT_MS = 5000;
 static const uint32_t COMMAND_PENDING_MUTEX_ACQUIRE_TIMEOUT_MS = 500;
 static const uint32_t COMMAND_TIMEOUT_RESTART_MS = 5000;
 static const int HCI_UNKNOWN_COMMAND_TIMED_OUT = 0x00ffffff;
@@ -127,7 +129,7 @@ static void enqueue_packet(void* packet);
 static void event_packet_ready(void* packet);
 static void command_timed_out(void* context);
 
-static void update_command_response_timer(void);
+static void update_command_response_timer(int opcode);
 
 static void transmit_fragment(BT_HDR* packet, bool send_transmit_finished);
 static void dispatch_reassembled(BT_HDR* packet);
@@ -430,7 +432,7 @@ static void event_command_ready(waiting_command_t* wait_entry) {
   // Send it off
   packet_fragmenter->fragment_and_dispatch(wait_entry->command);
 
-  update_command_response_timer();
+  update_command_response_timer(wait_entry->opcode);
 }
 
 static void enqueue_packet(void* packet) {
@@ -623,7 +625,7 @@ static bool filter_incoming_event(BT_HDR* packet) {
                  __func__, opcode);
       }
     } else {
-      update_command_response_timer();
+      update_command_response_timer(wait_entry->opcode);
       if (wait_entry->complete_callback) {
         wait_entry->complete_callback(packet, wait_entry->context);
       } else if (wait_entry->complete_future) {
@@ -650,7 +652,7 @@ static bool filter_incoming_event(BT_HDR* packet) {
           "%s command status event with no matching command. opcode: 0x%04x",
           __func__, opcode);
     } else {
-      update_command_response_timer();
+      update_command_response_timer(wait_entry->opcode);
       if (wait_entry->status_callback)
         wait_entry->status_callback(status, wait_entry->command,
                                     wait_entry->context);
@@ -725,7 +727,7 @@ static int get_num_waiting_commands() {
   return list_length(commands_pending_response);
 }
 
-static void update_command_response_timer(void) {
+static void update_command_response_timer(int opcode) {
   std::lock_guard<std::recursive_timed_mutex> lock(
       commands_pending_response_mutex);
 
@@ -733,7 +735,7 @@ static void update_command_response_timer(void) {
   if (list_is_empty(commands_pending_response)) {
     alarm_cancel(command_response_timer);
   } else {
-    alarm_set(command_response_timer, COMMAND_PENDING_TIMEOUT_MS,
+    alarm_set(command_response_timer, (opcode == 0x804) ? HUAWEI_COMMAND_PENDING_TIMEOUT_MS : COMMAND_PENDING_TIMEOUT_MS,
               command_timed_out, list_front(commands_pending_response));
   }
 }
-- 
2.17.1

[penn5]

Interesting, for testing this, opening either Spotify for Wear OS both force a transition to to non-sniff mode. But the timeout only seems to happen when playing music.

[phhusson]

@elpollol said "Nope, they appears without playing music."