RTL8822be bluetooth disappears with Buster/Bullseye

[Inclined Plane]

I got a new laptop that has an RTL8822be dual wifi/bluetooth chip. I initially installed Buster on it and the wifi works fine but there is no sign of the bluetooth adapter. It doesn't appear in rfkill or lsusb. I upgraded to Bullseye and still nothing. However, when I installed Stretch on an external hard drive booted that it works fine. I've done a lot of web searches and found several comments that said if it doesn't appear in lsusb then anything after that is not relevant. The output of lsusb on Stretch is

Code: Select all

Bus 002 Device 002: ID 0080:a001 Assmann Electronic GmbH Digitus DA-71114 SATA
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 13d3:56c9 IMC Networks 
Bus 001 Device 003: ID 0bda:b00b Realtek Semiconductor Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

The output of lsusb on Buster or Bullseye is

Code: Select all

Bus 002 Device 002: ID 0080:a001 Assmann Electronic GmbH Digitus DA-71114 SATA
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 13d3:56c9 IMC Networks HP TrueVision HD Camera
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

The line
Bus 001 Device 003: ID 0bda:b00b Realtek Semiconductor Corp.
is missing on the later releases. I tried booting an OpenSUSE live iso and it was there and it worked fine (kernel 4.12) but it was not there with an Ubuntu 18.04 (kernel 4.18) or Ubuntu 19.10 (kernel 5.0) live boot. I guess there was a change in the kernel at some point that keeps it from being found since the older releases seem to work and the newer ones don't.

Do I have any options to get the rtl8812be bluetooth recognized by the later kernels? Maybe a kernel option added to /etc/default/grub? I'd really prefer not to have to install Stretch on the main drive at this point or permanently use a USB dongle (only two USB ports available).

[arzgi]

Install firmware-realtek, it's in non-free.

[Inclined Plane]

Install firmware-realtek, it's in non-free.

Thanks for responding. The firmware is installed, but this problem happens before that stage. The kernel doesn't detect that the bluetooth part of chip even exists so never gets to the point where it tries to load the driver and firmware. On the older kernels it shows up in lsusb and tries to load the driver even without the firmware, but of course gives the error about missing firmware. (Tried it on Stretch.) On later kernels, absolutely nothing.

It looks like someone else has the same problem, which couldn't be solved. I'll just keep trying new kernels as they come out and hope that this regression gets addressed.

[Head_on_a_Stick]

I'll just keep trying new kernels as they come out and hope that this regression gets addressed.

A bug report might speed that up somewhat. How can the developers fix a problem if they don't know it exists?

[CwF]

When you look through the models in the firmware list you might see that one doesn't mention bluetooth, and some models do. I have a 8192 in the same state. For windows there is an addtional *TWOPORT.sys driver. In all the raw linux drivers I have, no mention of bluetooth in many two port models. ?

this is what I got in a short look, and aborted, its wifi is weak anyway...

Code: Select all

[512859.472090] usb 4-1.2.4: New USB device strings: Mfr=0, Product=2, SerialNum
ber=0
[512859.472103] usb 4-1.2.4: Product: CSR BS8510
[512859.474081] Bluetooth: hci0: unexpected event for opcode 0x0000
[512859.518357] rtl8192cu: Board Type 4
[512859.518572] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
[512859.518816] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
[512859.520228] usb 4-1.2.2: firmware: direct-loading firmware rtlwifi/rtl8192cu
fw_TMSC.bin

[CwF]

My prior comments were from old notes, and a quickie test.
I got onto a tangent and ended up testing again with different results. I swear the wifi on my combo 8192CU worked (poorly) in that last session under Jessie and/or Stretch, and BT did not show up.

With the same evolved image now Buster I first verified with an alternate wifi dongle and a separate BT dongle. Both work as expected. Then plugged in the combo, that was formerly on XP as BT. I'm not saying the last state in windows may have made the difference, but this time, by the end of the story BT was working fine and wifi was not.

In all the test one thing is consistent, the OS generally *thinks* the function is working even though it doesn't. IE, a command to scan BT make the dongle lights up and flashes, seems to get a result, and nothing. The wifi scans, blinks, seems to do things, and nothing. It seems the only issue is no return data from the dongle, it does what you tell it to and then says no response. The other dongles return data from a scan within seconds, varying results with radio power.

this got me curious

Code: Select all

# hciconfig
hci0:	Type: Primary  Bus: USB
	BD Address: :::::  ACL MTU: 310:10  SCO MTU: 64:8
	UP RUNNING 
	RX bytes:1722 acl:0 sco:0 events:101 errors:0
	TX bytes:5981 acl:0 sco:0 commands:99 errors:0

this shows "RX bytes" from WHAT? Other tools show nothing?
So I fired up btscanner using the combo and let it run. A working BT returns results quickly, this one nothing... But the "RX bytes" keeps climbing after every scan test...So after many minutes on the combo all of a sudden a detected address popped up. I turned on my wonderful GOFLIP3's bluetooth and it appeared instantly, engaged BT audio and streamed audio to the desktop just fine...?

Meanwhile, nothing complains that the wifi doesn't work. It tries and comes back with nothing? Last time, under stretch maybe, the wifi worked but was terrible, BT didn't work. Now the opposite. Nothing I did while testing disturbed the audio flow, playing the majority of the time once working.

So I started over, could not get the wifi engaged, BT still takes 10x longer for it to find, then works fine. And again, the image works well with working dongles, so no issue with the OS. I assume the firmware in my particular case is better than it was, but still not right even with 5+ versions to choose from. So I'm thinking, including the OP's 8822, this is a firmware issue more than a kernel issue.

Earlier test, earlier firmware, ~debian pre-release stretch likely kernel ~4.09

Code: Select all

[ 3655.932863] rtl8192cu: Chip version 0x10
[ 3656.624357] rtl8192cu: Board Type 4
[ 3656.626226] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
[ 3656.626282] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
[ 3656.629049] usb 2-3: firmware: failed to load rtlwifi/rtl8192cufw_TMSC.bin (-2)
[ 3656.629058] usb 2-3: Direct firmware load for rtlwifi/rtl8192cufw_TMSC.bin fa

Wifi kinda works and no BT. look for this type of error, ambiguous firmware choices...
Here cleaner, under debian ~10.1 release kernel 4.19.06

Code: Select all

[512859.472090] usb 4-1.2.4: New USB device strings: Mfr=0, Product=2, SerialNum
ber=0
[512859.472103] usb 4-1.2.4: Product: CSR BS8510
[512859.474081] Bluetooth: hci0: unexpected event for opcode 0x0000
[512859.518357] rtl8192cu: Board Type 4
[512859.518572] rtl_usb: rx_max_size 15360, rx_urb_num 8, in_ep 1
[512859.518816] rtl8192cu: Loading firmware rtlwifi/rtl8192cufw_TMSC.bin
[512859.520228] usb 4-1.2.2: firmware: direct-loading firmware rtlwifi/rtl8192cu
fw_TMSC.bin
[512859.528501] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
[512859.528999] usbcore: registered new interface driver rtl8192cu
[512859.542128] rtl8192cu 4-1.2.2:1.0 wlxe000: renamed from wlan0
[535075.286881] rtl8192cu: MAC auto ON okay!
[535075.319698] rtl8192cu: Tx queue select: 0x05
[535075.908842] IPv6: ADDRCONF(NETDEV_UP): wlxe000: link is not ready
[540940.264390] input: ::::: as /devices/virtual/input/input24

that last line is me pairing the BT to my phone.

Still no wifi for me, but evidence of firmware evolution.
On the BT side this sequence gets it working:

Code: Select all

#hciconfig
 check for response
#hciconfig hci0 up
 for good measure
#hcitool scan
 seems faster than gui tools
#l2ping “MAC”
 use the MAC from something else you know is on
#sdptoiol browse --tree --l2cap “MAC”
 just for fun on known MAC from above
#btscanner “M:A:C”

point it to the known address and let it run awhile
After btscanner finally located the known mac, then gui tools started working. ? no idea...

Maybe informative for some, fun for me. Even under windows, this 8192 combo is crap. Combo units have to be worse than dedicated ones, but we have what we have. I suppose usb3's higher power allowance and bandwidth could eliminate the issue. In building mobile embedded things I noticed long ago pushing a higher voltage helps immensely for radio devices. I'll push 5.25 on a dedicated leg, 4.65 on most, and allow the 3.65-4.1 typical for the rest. My other BT dongle is twice the range, and my Ralink (firmware-misc-nonfree) 3504N wifi dongle is ridiculously powerful, easily twice the range of any else I've tried. But in the end I use a dd-wrt router backwards and am wired to it to receive a hotspot restricted to one user, into the my debian nest.