Lower Level Host Stack bug - 0x1a (remote host feature) using EDR+SCO to non-capable Taiwanese/Chinese devices

[Luke McKee <hojuruku@gmail.com>]

This bug at first sight appears to be a regression of this bug:
https://lists.freedesktop.org/archives/pulseaudio-discuss/2015-March/023305.html
reported by Georg Chini that's well known of by many pulseaudio users
but I believe it's a new one, brought about by incompatibility of many
Taiwanese Bluetooth stacks that support EDR only for A2DP / EDR
connection-less streams.   Many thanks for to Georg for support given
on #pulseaudio given to me (hojuruku)

The feedback from hcidump is near identical to the previous bug,
because but after even applying a patch to hci_event.c from George
(included below) however it didn't attempt a reconnect, so the cause
may be different, but the symptoms are the same.

The HSP or HFP protocols don't work due to the reliance on SCO with
this device and all other TW based hardware I have laying around here
(headphones / speakers)
https://www.mikrocontroller.net/attachment/193445/CW6626-Datasheet-DS6626V1.1.pdf
FYI this is the speaker:
http://www.szaodasen.com/en/productmore.asp?id=119&pid=6&i=119 It also
has a rfcomm profile and a proprietary app to remote control,
configure it set the clock etc. I might ask how to sniff rfcomm
connections later ;)

Unlike the previous issues this bluetooth speaker supports eSCO, but
not eSCO with a EDR packet type. This is affecting 4.9.13

The symptoms in userspace and hcidump are nearly identical but I have
verified the appropriate patches have been applied to work around the
issue of eSCO not being present in the bluetooth headset, as that's
not the problem here.

https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Bluetooth/

"The "Protocol not supported" problem

There was some regression in the kernel that was introduced in 3.12
and fixed in 3.18 that caused failure when trying to activate HSP/HFP
with some headsets. This problem can be identified by this error
message in pulseaudio log:

backend-native.c: connect(): Protocol not supported"

Here is a decent bug report for the 2015 bug mentioned above:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788466

This is not just a pulseaudio issue, bluez-alsa (for 5.x bluez
https://github.com/Arkq/bluez-alsa) reports the same:

bluealsa: Couldn't open SCO link: Protocol not supported

Both bluealsa & puleaudio work fine with ACL/A2DP. Also did a test to
make sure after a cold boot with only a HSP profile connection
attempted, used the distro kernel (sabayon) and the same kernel
bluetooth kernel configuration as Georg who worked around the old
issue with eSCO not being supported by the speaker.

This is on 4.9.13 sabayon.org sources that's pretty close to mainline,
and my own sensible kernel configuration for a Haswell. The distro
kernel also has the same problems. I can test again on vanilla if
requested.

hcidump of the failure:
< HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
     handle 12 voice setting 0x0060 ptype 0x0380
 > HCI Event: Command Status (0x0f) plen 4
     Setup Synchronous Connection (0x01|0x0028) status 0x1a ncmd 1
     Error: Unsupported Remote Feature / Unsupported LMP Feature
 > HCI Event: Max Slots Change (0x1b) plen 3
     handle 12 slots 1
 > HCI Event: Mode Change (0x14) plen 6
     status 0x00 handle 12 mode 0x02 interval 800
     Mode: Sniff

bluetoothd:
bluetoothd[2477]: src/profile.c:ext_connect() Headset Voice gateway
connected to 30:21:57:95:5A:3A
bluetoothd[2477]: src/service.c:change_state() 0x563d7d550920: device
30:21:57:95:5A:3A profile Headset Voice gateway state changed:
disconnected -> connecting (0)
bluetoothd[2477]: src/service.c:change_state() 0x563d7d550920: device
30:21:57:95:5A:3A profile Headset Voice gateway state changed:
connecting -> connected (0)
bluetoothd[2477]: src/device.c:device_profile_connected() Headset
Voice gateway Success (0)
bluetoothd[2477]: src/service.c:btd_service_ref() 0x563d7d550920: ref=3
bluetoothd[2477]: plugins/policy.c:service_cb() Added Headset Voice
gateway reconnect 0
bluetoothd[2477]: src/device.c:att_disconnected_cb()
bluetoothd[2477]: src/device.c:att_disconnected_cb() Success (0)
bluetoothd[2477]: src/gatt-client.c:btd_gatt_client_disconnected()
Device disconnected. Cleaning up.
bluetoothd[2477]: src/device.c:att_disconnected_cb() Automatic
connection disabled
bluetoothd[2477]: attrib/gattrib.c:g_attrib_unref() 0x563d7d545c30:
g_attrib_unref=0

hciconfig -a

hci0: Type: Primary  Bus: USB
BD Address: 00:19:86:00:00:2E  ACL MTU: 1021:7  SCO MTU: 64:1
UP RUNNING
RX bytes:2505067 acl:176 sco:0 events:357072 errors:0
TX bytes:430951824 acl:713834 sco:0 commands:103 errors:0
Features: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0x79 0x83
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH HOLD SNIFF PARK
Link mode: SLAVE ACCEPT
Name: 'hojuruku'
Class: 0x0c0104
Service Classes: Rendering, Capturing
Device Class: Computer, Desktop workstation
HCI Version: 2.1 (0x4)  Revision: 0x5332
LMP Version: 2.1 (0x4)  Subversion: 0x420e
Manufacturer: Broadcom Corporation (15)

lsusb
Bus 003 Device 007: ID 0a5c:2148 Broadcom Corp. BCM92046DG-CL1ROM
Bluetooth 2.1 Adapter

loading btusb with the option to tweak the SCO MTU made no difference either.

hcitool info 30:21:57:95:5A:3A
Requesting information ...
BD Address:  30:21:57:95:5A:3A
Device Name: JY-17
LMP Version: 3.0 (0x5) LMP Subversion: 0x1f4
Manufacturer: CONWISE Technology Corporation Ltd (66)
Features page 0: 0xbf 0x3a 0x85 0xfa 0x98 0x1d 0x59 0x87
<3-slot packets> <5-slot packets> <encryption> <slot offset>
<timing accuracy> <role switch> <sniff mode> <RSSI> <SCO link>
<HV2 packets> <HV3 packets> <CVSD> <power control>
<broadcast encrypt> <EDR ACL 2 Mbps> <enhanced iscan>
<interlaced iscan> <interlaced pscan> <inquiry with RSSI>
<extended SCO> <AFH cap. slave> <AFH class. slave>
<3-slot EDR ACL> <5-slot EDR ACL> <pause encryption>
<AFH cap. master> <AFH class. master> <extended inquiry>
<simple pairing> <encapsulated PDU> <non-flush flag> <LSTO>
<inquiry TX power> <EPC> <extended features>
Features page 1: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00

 hciconfig
hci0: Type: Primary  Bus: USB
BD Address: 00:19:86:00:00:2E  ACL MTU: 1021:7  SCO MTU: 64:1
UP RUNNING
RX bytes:2505684 acl:176 sco:0 events:357085 errors:0
TX bytes:430951868 acl:713834 sco:0 commands:111 errors:0

^^ As you can see A2DP profile works fine using sbc ^^

hciconfig hci0 features
hci0: Type: Primary  Bus: USB
BD Address: 00:19:86:00:00:2E  ACL MTU: 1021:7  SCO MTU: 64:1
Features page 0: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0x79 0x83
<3-slot packets> <5-slot packets> <encryption> <slot offset>
<timing accuracy> <role switch> <hold mode> <sniff mode>
<park state> <RSSI> <channel quality> <SCO link> <HV2 packets>
<HV3 packets> <u-law log> <A-law log> <CVSD> <paging scheme>
<power control> <transparent SCO> <broadcast encrypt>
<EDR ACL 2 Mbps> <EDR ACL 3 Mbps> <enhanced iscan>
<interlaced iscan> <interlaced pscan> <inquiry with RSSI>
<extended SCO> <EV4 packets> <EV5 packets> <AFH cap. slave>
<AFH class. slave> <3-slot EDR ACL> <5-slot EDR ACL>
<sniff subrating> <pause encryption> <AFH cap. master>
<AFH class. master> <EDR eSCO 2 Mbps> <EDR eSCO 3 Mbps>
<3-slot EDR eSCO> <extended inquiry> <simple pairing>
<encapsulated PDU> <err. data report> <non-flush flag> <LSTO>
<inquiry TX power> <extended features>
Features page 1: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00

Similar bug - only userspace errors reported
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1331748

This one is very interesting, it shows a hcidump of it retrying until
a connection is made with a DIFFERENT pkgtype. The patch seems applied
to 4.9.13 yet my system borks after only once unsuccessful attempt to
connect with a 0x1a remote feature not supported error.
https://marc.info/?l=linux-bluetooth&m=144076356407749&w=1

2015-05-18 01:27:57.336610 > HCI Event: Synchronous Connect Complete
(0x2c) plen 17
    status 0x1a handle 0 bdaddr 30:7C:30:B3:A8:86 type SCO
    Error: Unsupported Remote Feature / Unsupported LMP Feature
2015-05-18 01:27:57.336685 < HCI Command: Setup Synchronous Connection
(0x01|0x0028) plen 17
    handle 256 voice setting 0x0060 ptype 0x03c8
2015-05-18 01:27:57.337603 > HCI Event: Command Status (0x0f) plen 4
    Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
2015-05-18 01:27:57.342608 > HCI Event: Max Slots Change (0x1b) plen 3
    handle 256 slots 1
2015-05-18 01:27:57.377631 > HCI Event: Synchronous Connect Complete
(0x2c) plen 17
    status 0x00 handle 257 bdaddr 30:7C:30:B3:A8:86 type eSCO
    Air mode: CVSD

Thanks in advance to anyone willing provide a patch for me to test. In
the meantime I'll try and track down a bluetooth 2.0 non EDR capable
dongle that works to prove my theory, as people did last time with a
non eSCO capable dongle.

These patches only make 4.9.13 have the identical fix to George's
proposed patch to 3.17 and didn't solve the issue
(https://lists.freedesktop.org/archives/pulseaudio-discuss/2015-March/023366.html)

diff -u  /usr/src/linux/net/bluetooth/hci_conn.c /usr/src/hci_conn.c
--- /usr/src/linux/net/bluetooth/hci_conn.c 2016-12-12 02:17:54.000000000 +0700
+++ /usr/src/hci_conn.c 2017-03-16 14:53:44.211312575 +0700
@@ -45,8 +45,8 @@
  { EDR_ESCO_MASK & ~ESCO_2EV3, 0x000a, 0x01 }, /* S3 */
  { EDR_ESCO_MASK & ~ESCO_2EV3, 0x0007, 0x01 }, /* S2 */
  { EDR_ESCO_MASK | ESCO_EV3,   0x0007, 0x01 }, /* S1 */
- { EDR_ESCO_MASK | ESCO_HV3,   0xffff, 0x01 }, /* D1 */
- { EDR_ESCO_MASK | ESCO_HV1,   0xffff, 0x01 }, /* D0 */
+ { EDR_ESCO_MASK | ESCO_HV3,   0xffff, 0xff }, /* D1 */
+ { EDR_ESCO_MASK | ESCO_HV1,   0xffff, 0xff }, /* D0 */
 };

 static const struct sco_param sco_param_cvsd[] = {

--- /usr/src/linux/net/bluetooth/hci_event.c 2016-12-12 02:17:54.000000000 +0700
+++ /usr/src/hci_event.c 2017-03-16 15:53:52.569396159 +0700
@@ -1519,8 +1519,13 @@
  if (sco) {
  sco->state = BT_CLOSED;

- hci_connect_cfm(sco, status);
+/* hci_connect_cfm(sco, status);
  hci_conn_del(sco);
+ */
+ if (!hci_setup_sync(sco, handle)) {
+ hci_connect_cfm(sco, status);
+ hci_conn_del(sco);
+ }
  }
  }