ASUS USB-BT500 not working properly after first use with Bumble, works again after reset

[zyv]

I'm doing an ordinary outbound RFCOMM connect that begins with an SDP browse to a Bluetooth Classic accessory. After the first run of my program to successful completion, upon the next run, the controller locks up after establishing the bidirectional ACL link. I have noticed that after re-plugging the dongle, it starts working again. For now, my best idea is to just reset the controller inside my program upon startup.

I'm not sure whether it's a firmware issue, or Bumble does something upon termination that leaves the controller in a bad state, or maybe I'm using Bumble in a way that causes this... Since I'm very new to all of this, I'd appreciate any help.

Steps to reproduce

1. Physically plug in an ASUS USB-BT500 dongle
2. Run a Bumble script that connects to a Classic peer and does an SDP browse → works
3. Let the script exit normally; do not unplug anything
4. Run the same script again → hangs; no L2CAP channel is ever established
5. usb.core.find(idVendor=0x0b05, idProduct=0x190e).reset(), then run again → works

Environment

Bumble	0.0.233
Python	3.14.4
OS	macOS 15.7.7 (arm64)
Transport	usb:0
Dongle	ASUS USB-BT500, VID 0x0B05 PID 0x190E
Controller	Realtek (manufacturer 93), RTL8761B
ROM firmware	HCI v10 rev 11, LMP v10 subver 0x8761
Patched firmware	HCI v10 rev 57286, LMP v10 subver 0xd922

Details

I've looked at the BUMBLE_SNOOPER capture and noted the following:

• The peer is reachable and does respond — its Info_Req arrives normally. So the ACL link is up and bidirectional at least briefly.

• After the host's Info_Rsp, no further inbound ACL data arrives at all — 1 inbound packet versus 47 in a working run. The host eventually times out and disconnects.

• The controller reports Number_Of_Completed_Packets count=1 for each ACL packet the host submits, i.e. it claims to have transmitted them. I cannot tell whether the controller stops transmitting or stops delivering received packets upward.

• HCI_Reset (which Bumble does issue) does not clear the condition.

[barbibulle]

Thanks for the report. I have a few BT-500 adapters (different variants). I'll try to replicate this issue soon (I don't have the adapters with me currently, but I will look into it when I get back in a couple weeks)

[zyv]

Thanks and do let me know if you can't easily replicate it... I hope that you'll just get the same effect immediately by running Bumble examples against an accessory, but if not, I'll have to extract a self-contained reproducer from my code. Unfortunately, I can't simply share the complete code base, and I also do not have any accessories at home, so it's quite some work - which is why I decided to start with this report.