Linux: WL18xx BT disconnect issue

Hello Nathan,

Going over the logger file i can say the following:

Please send the log file from power up - So we can see the power up sequence and make sure all is working well.

I can see three disconnections in the log file:

The first one -
The remote side disconnected the connection.

The second one - same thing, happens after encryption process passed successfully.

The third one - same as the second one.

Can you please add some more information about the scenario?
Can you please add air sniffer logs?

BR,
Chen Loewy

Hi Loewy,

Thanks for your reply.

During the BT SPP transmission test  , we found Bluetooth disconnected about 4 minutes / time

Please find the new log is from power up and fw in the attached files.

In addition , can you teach me how to capture BT sniffer?

6403.2018723.7z

TIInit_11.8.32_4.2_20180720.bts.7z

Nathan Kuo

Looking at the logs, it appears the disconnects are initiated from the Local Host. It seems, you are using Bluez stack right? I suggest taking, btsnoop logs with HCIdump or BTMon on the Linux Host.

Thanks

Dear Sir,

Attachment is hcidump log , please give me some advice

hcidump_20180725.7z

Nathan Kuo

Hi

Any update?

Nathan Kuo

Hi,

From the logs, it looks like due to some reason local stack (Bluez) is closing the RFCOMM channels and there by closing the connection. Not, usre why Bluez stack is issuing? Could, it be application terminating the SPP/RFCOM connection?

2000-01-07 12:58:35.718714 < ACL data: handle 1 flags 0x00 dlen 8
L2CAP(d): cid 0x004d len 4 [psm 3]
RFCOMM(s): DISC: cr 0 dlci 2 pf 1 ilen 0 fcs 0xd9
2000-01-07 12:58:35.721809 > HCI Event: Number of Completed Packets (0x13) plen 5
handle 1 packets 1
2000-01-07 12:58:35.774296 > ACL data: handle 1 flags 0x02 dlen 8
L2CAP(d): cid 0x0040 len 4 [psm 3]
RFCOMM(s): UA: cr 0 dlci 2 pf 1 ilen 0 fcs 0xf3
2000-01-07 12:58:35.774713 < ACL data: handle 1 flags 0x00 dlen 8
L2CAP(d): cid 0x004d len 4 [psm 3]
RFCOMM(s): DISC: cr 0 dlci 0 pf 1 ilen 0 fcs 0x9c
2000-01-07 12:58:35.778052 > HCI Event: Number of Completed Packets (0x13) plen 5
handle 1 packets 1
2000-01-07 12:58:35.781855 > ACL data: handle 1 flags 0x02 dlen 8
L2CAP(d): cid 0x0040 len 4 [psm 3]
RFCOMM(s): UA: cr 0 dlci 0 pf 1 ilen 0 fcs 0xb6
2000-01-07 12:58:35.782558 < ACL data: handle 1 flags 0x00 dlen 12
L2CAP(s): Disconn req: dcid 0x004d scid 0x0040
2000-01-07 12:58:35.785651 > HCI Event: Number of Completed Packets (0x13) plen 5
handle 1 packets 1
2000-01-07 12:58:35.785671 > ACL data: handle 1 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x0040 scid 0x004d
2000-01-07 12:58:35.785811 < ACL data: handle 1 flags 0x00 dlen 12
L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x004d
2000-01-07 12:58:35.789299 > HCI Event: Number of Completed Packets (0x13) plen 5
handle 1 packets 1
2000-01-07 12:58:35.793009 > ACL data: handle 1 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x004d scid 0x0040
2000-01-07 12:58:36.399542 < HCI Command: Write Local Name (0x03|0x0013) plen 248
name 'GNSS-6000002'
2000-01-07 12:58:36.401466 > HCI Event: Command Complete (0x0e) plen 4
Write Local Name (0x03|0x0013) ncmd 1
status 0x00
2000-01-07 12:58:39.786689 < HCI Command: Disconnect (0x01|0x0006) plen 3
handle 1 reason 0x13
Reason: Remote User Terminated Connection
2000-01-07 12:58:39.787806 > HCI Event: Command Status (0x0f) plen 4
Disconnect (0x01|0x0006) status 0x00 ncmd 1
2000-01-07 12:58:39.792716 > HCI Event: Disconn Complete (0x05) plen 4
status 0x00 handle 1 reason 0x16
Reason: Connection Terminated by Local Host


Taking, hcidump with (-B, --btsnoop) option give btsnoop log file, which can be viewed with Frontline BT viewer..

Thanks

Hi Hari,

We use "hcidump -i hci0 -Xt -w" to captured the log , and we can open it on wireshark. as shown below.

 

I also added this log file to the attachment , can you help me review  the log and give some comments?

Thanks.hcidump_20180802.7z

Nathan Kuo

Dear Sir,

Have any ideas for this issue ?  we really need TI's help. 

Nathan Kuo

Hi,

Reviewing the logs, it appears in all 3 instances Host application/Bluez profiles (SPP/RFCOMM ) initiated the DISCONNECT. There is no disconnect from the controller as such..

Hi Hari ,

Thanks for your answer.

We also captured the BT air log and checked the log and have some questions below.

From the air log analysis, when the issue occurs, the host (mobile phone)sends and exits the sniff request. After the LMP layer issues lmp unsniff req, the WL8 device has ack, and both parties exit the sniff mode.

In the active mode stage, the WL8 device does not output packets, the mobile phone as the host, there are every 40 slots poll to WL8 devices, but the WL8 devices have no response packet.

We check the TX frequence of the mobile phone to meet the spec and expectations, the mobile phone behaves normally, but the WL8 device does not response the packet and causes the disconnection.

Can you help me to analyze it and give some ideas?

Please find the bt log and BT analyzer software as below link.

After it's downloaded , please install "BluetoothAnalyzer" software included in the 7z file and then open the "1621.btt" log file on the "BluetoothAnalyzer  to see the BT air log.

Thanks.

Nathan Kuo

Any update for this issue?

Can, you please provide the time in the Ellisys sniffer log, at which you saw the issue?

Thanks

Hi Hari,

You can set the item filter to the "L2CAP" and then you will find the disconnection event.

Nathan Kuo

Humm.. L2CAP disconnects could be channel disconnections due to upper layer profiles disconnecting them, for example after SDP discovery channels may get disconnected etc.. L2CAP is host resident stack, and since you are using BlueZ, these disconnects are initiated from that stack...

Hi Hari,

After we upgraded the firmware to the  service pack 4.3 , we got the connection timeout event in the hcidump log.

Do you have any comments for this ?

hcidump_20180906.log

Nathan Kuo

Yes, from these logs it seems there was timeout.. Can, you take FW logs to analyze further?

Thanks