Intel AX200 not receiving SCO data

Intel AX200 not receiving SCO data

[Andrew Fuller]

I sent this email yesterday, but it doesn't seem to have gone through.
I'm re-sending it now but this time without the attachments (maybe
that caused it to be redirected to /dev/null?)
If the attachments would be useful, please advise how to manage them
-- direct paste into the body?

If the first was just delayed, then this becomes a double-post.
Apologies in advance if that happens.

Original message below,
-Andrew


---- 8< ----------


First of all, I hope I'm in the right place for this, and if not
please direct me to where this is better suited.

Secondly, I know very little about Bluetooth, so please excuse my ignorance.

I have an Intel AX200 chip in my laptop and wish to use my Plantronics
Voyager Legend for teleconferencing under Linux.  It didn't work out
of the box, so I've been learning little pieces of Bluetooth and
profiles and such as I've dug progressively deeper into this.

I am now at the point where I understand (thanks Pali!) that SCO is
required for HSP/HFP and that my device doesn't seem to be receiving
any SCO packets.

Attached are the HCI logs from btmon and bluetoothd debug logs
(running master from a couple days ago).

Notably I see:

$ ag "SCO Data" hcitrace.txt
2048:< SCO Data TX: Handle 257 flags 0x00 dlen 96              #386
[hci0] 66.554983
2055:< SCO Data TX: Handle 257 flags 0x00 dlen 96              #387
[hci0] 66.554998
2690:< SCO Data TX: Handle 257 flags 0x00 dlen 96             #473
[hci0] 123.337072
2697:< SCO Data TX: Handle 257 flags 0x00 dlen 96             #474
[hci0] 123.337084

Looks like 4 SCO transmits, but 0 SCO receives.

Also looking peculiar to me is the content:

< SCO Data TX: Handle 257 flags 0x00 dlen 96              #386 [hci0] 66.554983
       00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
       00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
       00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
       00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
       00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
       00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
< SCO Data TX: Handle 257 flags 0x00 dlen 96              #387 [hci0] 66.554998
       00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
       00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
       00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
       00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
       00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
       00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

Is it typical/good/happy to be sending 96 bytes of nothing?

A little more detail about the bt chip in question:

$ lsusb
Bus 001 Device 006: ID 8087:0029 Intel Corp.

$  dmesg | ag blue
[    4.762863] Bluetooth: Core ver 2.22
[    4.762877] Bluetooth: HCI device and connection manager initialized
[    4.762879] Bluetooth: HCI socket layer initialized
[    4.762881] Bluetooth: L2CAP socket layer initialized
[    4.762887] Bluetooth: SCO socket layer initialized
[    4.975584] Bluetooth: hci0: Firmware revision 0.0 build 128 week 11 2020
[    5.037566] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio
is unblocked
[    5.821248] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[    5.821249] Bluetooth: BNEP filters: protocol multicast
[    5.821253] Bluetooth: BNEP socket layer initialized
[   17.926249] Bluetooth: RFCOMM TTY layer initialized
[   17.926262] Bluetooth: RFCOMM socket layer initialized
[   17.926268] Bluetooth: RFCOMM ver 1.11

"Firmware revision 0.0" also looks strange to me, but AFAICT it's
loading ibt-20-1-3.sfi from the linux-firmware package.  Week 11 2020
certainly looks in line with what I would expect.

Googling has suggested that in the case of another vendor's chip SCO
traffic was being routed to PCI pins instead of HCI and that a
vendor-specific HCI command switched it to HCI, fixing the issue.

So, my questions are:
1. Am I in the right place?
2. Does this chip require a magic HCI command to route SCO to HCI?  It
appears some Intel folks are active here, perhaps they could chime in?
2a. If yes, where do I find the magic command?
3. Is the missing SCO Rx likely a symptom of something else gone wrong
in software, or likely the first indication of a hardware/firmware
issue?
4. Is there somewhere else I should be looking?

Thanks in advance,
-Andrew

Re: Intel AX200 not receiving SCO data

[Andrew Fuller]

Update for posterity:

I found a newer firmware from the upstream git repo and that resolved
the SCO troubles.