Created attachment 140571 [details] Patch to skip page scan commands on broadcom devices hciconfig hci0 up fails sending the "Read Page Scan Type" command: < HCI Command: Read Page Scan Type (0x03|0x0046) plen 0 0.376888 > HCI Event: Command Complete (0x0e) plen 4 0.379873 Read Page Scan Type (0x03|0x0046) ncmd 1 Status: Unsupported Feature or Parameter Value (0x11) This device seems to have the same page scan issues as the BlueFRITZ! devices. I've attached a simple patch against kernel 3.15.1 that fixes the problem for me, though this solution is probably too broad for general use.
Created attachment 140581 [details] hcidump output This is full output from hcidump while running hciconfig hci0 up.
I doubt the issue applies to all Broadcom adapters since those are probably the most common ones on the market. I've got several of them and they all work fine. Here's a decoded snippet (using btmon instead of hcidump) from the provided HCI log: < HCI Command: Read Local Version Information (0x04|0x0001) plen 0 0.316895 > HCI Event: Command Complete (0x0e) plen 12 0.319876 Read Local Version Information (0x04|0x0001) ncmd 1 Status: Success (0x00) HCI version: Bluetooth 1.2 (0x02) - Revision 3 (0x0003) LMP version: Bluetooth 1.2 (0x02) - Subversion 2048 (0x0800) Manufacturer: Broadcom Corporation (15) < HCI Command: Read BD ADDR (0x04|0x0009) plen 0 0.319905 > HCI Event: Command Complete (0x0e) plen 10 0.321874 Read BD ADDR (0x04|0x0009) ncmd 1 Status: Success (0x00) Address: 00:0D:3A:A8:0B:BE (Microsoft Corp.) What's interesting is that the adapter is using an address allocated to Microsoft, which leads me to wonder whether this is an authentic Broadcom device or not (we've seen before cheap Asian manufacturers having similar inconsistencies in manufacturer information). If this is a USB device could you also provide the USB id, etc for it. Usually the relevant part from the output of the usb-devices command is enough. This would allow us to make a very specific quirk for this piece of hardware.
Yep, it's a Microsoft USB bluetooth dongle. I should have mentioned that in the original report: Bus 007 Device 004: ID 045e:009c Microsoft Corp. Wireless Transceiver for Bluetooth 2.0 Bus 007 Device 003: ID 045e:3500 Microsoft Corp. > I doubt the issue applies to all Broadcom adapters since those are probably > the most common ones on the market. I agree, which is why I mentioned that, though the patch works for me it's probably too broad for general use. Let me know what else you need.
(In reply to Bernie Hackett from comment #3) > Bus 007 Device 004: ID 045e:009c Microsoft Corp. Wireless Transceiver for > Bluetooth 2.0 That's funny. Not supporting the HCI command in question makes this hardware look like a 1.1 device. The Read Local Version HCI command claims it's a 1.2 device and on USB it identifies itself as a 2.0 device.
Is there any other information I can provide that would help develop a workaround for this specific hardware?
Could you please try with a patch that was just a moment ago pushed to the bluetooth-next tree: https://git.kernel.org/cgit/linux/kernel/git/bluetooth/bluetooth-next.git/commit/?id=417287de88bfbb724bab2f50782395d2606b28e1 If that works for you then we'll make sure the patch makes it to the 3.19 kernel release.
That patch does appear to allow the adapter to come up. I can also pair a keyboard after. Sadly, only the j, k, and l keys seem to work (as 1, 2, and 3) but I think that's a totally different problem. I think this particular issue is solved.