# Bluetooth and FreeBSD



## sidetone (Jan 8, 2021)

Someone asked, and I'll post this here...


> How did you get a usb bluetooth dongle to work?  I gather that FreeBSD only has support for v1.1 and my bluetooth dongles are version v4.0.  Any thoughts or advice is welcome



I've never gotten it to work. I've only gotten remote devices (as in apart from the dongle) to show up, but they didn't show up as Bluetooth devices. I don't remember the output status of my Bluetooth dongle (it was either version 3 or 4).

Avoid building the base from /usr/src/ (source), and there will be less impediments: removing features through src.conf may strip away components that Bluetooth may need.

There's a possibility that Bluetooth V1 in the base could be used with version 4 of Bluetooth devices with v1.1 features.


When people say they got Bluetooth to work in these forums, the context in which they're referring to isn't often specific. I see lack of mention of which version driver is used and which version of dongle and components are used. To know, you can look up the source in the /usr/src/ directory or online. A developer once told me that Bluetooth of higher versions worked (which had power saving capabilities available in version 4), but I couldn't follow this, and this may have been inaccurate.

I don't know how familiar you are with hardware configuration on FreeBSD or other OS's. Play around with the commands kldload and kldstat. Check your /dev directory, and there's some manpages on FreeBSD to look at for Bluetooth V1.1.


Does anyone have information related to this, or updates?


----------



## sidetone (Feb 23, 2021)

Bluetooth devices/peripherals that were connected by Bluetooth dongles have showed up, but not as Bluetooth devices through `dmesg` or at /dev/. For me, a Bluetooth gamepad showed up like this years ago.

It has worked on a Bluetooth version 5 dongle for audio peripherals: Thread using-bluetooth-audio-devices-speaker-headphones-earbuds-with-freebsd.78992


----------



## trev (Feb 23, 2021)

These are my notes from 2016...​Hardware​
Xbee board with an HC-06 bluetooth module
Jaluino Bee v2.1 board with PIC18F27J53 microcontroller
USB Bluetooth adapter (Mac Mini has one built-in but not usable from FBSD)
*Setup*

To connect wirelessly:

If your kernel does not have the Bluetooth device drivers compiled into the kernel, you should be able to load them  as kernel modules. Before attaching a device, you need to load the drivers into the kernel:
# kldload ng_ubt

If the Bluetooth device is present in the system during system startup, load the module from /boot/loader.conf:
ng_ubt_load="YES"

Plug in your USB dongle. The output similar to the following will appear in /var/log/messages:
ubt0: <vendor 0x0a12 product 0x0001, class 224/1, rev 2.00/19.15, addr 7> on uhub2
ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2
ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=49; nframes=6, buffer size=294


The /etc/rc.d/bluetooth script is used to start and stop the Bluetooth stack. It is a good idea to stop the stack before unplugging the device, but it is not (usually) fatal. Since FreeBSD 5.5, there is an entry in devd.conf which sets up the Bluetooth stack when a device is plugged in. If you stop the stack at any time (eg restart it), you can start it again without re-plugging the USB Bluetooth adapter with:
# /etc/rc.d/bluetooth start ubt0

Check for Bluetooth devices in range with:
# hccontrol -n ubt0hci inquiry
Inquiry result, num_responses=1
Inquiry result #0
BD_ADDR: 28:cf:da:02:e5:ae
Page Scan Rep. Mode: 0x1
Page Scan Period Mode: 0x2
Page Scan Mode: 00
Class: 3a:01:04
Clock offset: 0x4b34
Inquiry result, num_responses=1
Inquiry result #0
BD_ADDR: 00:11:06:14:03:12
Page Scan Rep. Mode: 0x1
Page Scan Period Mode: 0x2
Page Scan Mode: 00
Class: 00:1f:00
Clock offset: 0x500b
Inquiry complete. Status: No error [00]


The first address is the USB Bluetooth adapter and the second address is the Bluetooth Xbee.
Check you can ping the USB Bluetooth adapter and the Bluetooth Xbee:
# l2ping -a 28:cf:da:02:e5:ae
44 bytes from 28:cf:da:02:e5:ae seq_no=1 time=40.234 ms result=0  44 bytes from 28:cf:da:02:e5:ae seq_no=2 time=51.189 ms result=0  44 bytes from 28:cf:da:02:e5:ae seq_no=3 time=35.241 ms result=0  
# l2ping -a 00:11:06:14:03:12

4 bytes from 00:11:06:14:03:12 seq_no=1633905441 time=14.022 ms result=0 4 bytes from 00:11:06:14:03:12 seq_no=1633905441 time=25.685 ms result=0 4 bytes from 00:11:06:14:03:12 seq_no=1633905441 time=27.683 ms result=0


The hcsecd(8) daemon is responsible for handling of all Bluetooth authentication requests. You need to add an entry for the Bluetooth Xbee to /etc/bluetooth/hcsecd.conf (note you can't use a name for bdaddr here, it must be a numeric address):
device {
bdaddr  00:11:06:14:03:12;
name    "BlueXbee";
key     nokey;
pin     "1234";
}


Now start hcsecd by running:
# /etc/rc.d/hcsecd start

You may need to execute the following command to ensure that some devices will pair:
# hccontrol -n ubt0hci write_authentication_enable 1

The following line can be added to the /etc/rc.conf file to have hcsecd started automatically on system start:
hcsecd_enable="YES"

To find the name of a Bluetooth device given its address, execute:
# hccontrol -n ubt0hci remote_name_request 00:11:06:14:03:12
BD_ADDR: 00:11:06:14:03:12 Name: BlueXbee


The rfcomm_sppd(1) utility implements the Serial Port profile. A pseudo tty is used as a virtual serial port abstraction. To connect to a remote device Serial Port service (ie our Bluetooth Xbee):
# rfcomm_sppd -a 00:11:06:14:03:12 -t /dev/ttyp7
rfcomm_sppd[36607]: Starting on /dev/ttyp7...


The flashing connection LED on the Bluetooth Xbee should now be lit solid to indicate a valid connection.
To list the connected devices, execute:
# hccontrol -n ubt0hci read_connection_list
Remote BD_ADDR    Handle Type Mode Role Encrypt Pending Queue State
00:11:06:14:03:12      0  ACL    0 MAST    NONE       0     0 OPEN


To talk to the Bluetooth Bee, execute:
# cu -l ttyp7

You should now see the 0101 pattern repeating, and pressing 0-5 on the keyboard should slow down or speed up the flashing user LED on the Bluetooth Bee. HINT: To exit from cu, type ~ followed by CTRL-D.
Once you tire of typing Bluetooth addresses, you can setup /etc/bluetooth/hosts


----------



## trev (Feb 23, 2021)

The JAL code for the microcontroller:


```
-- Title: Blink-a-led with UART output for Jaluino Bee, 18F27J53 based
-- Author: Sébastien Lelong, Copyright (c) 2008..2009, all rights reserved.
-- Adapted-by: Trev
-- Compiler: 2.4o
--
-- This file is part of jaluino  (http://jaluino.googlecode.com)
-- Released under the BSD license (http://www.opensource.org/licenses/bsd-license.php)
--
-- Description: this program blinks a LED for ever... LED is built-in, onboard,
-- connected to pin 13 (RC2) and outputs 0 for LED off and 1 for LED on wirelessly
-- via an inserted bluetooth Xbee. Solder jumpers for serial hardware are set to
-- TX1/RX1 for the default UART.

include jaluino_bee -- jaluino bee defaults
include delay       -- include the delay library

-- Use onboard user LED
onboard_led_direction =  output

-- disable analog I/O
-- enable_digital_io() [included in jaluino_bee.jal]

-- ok, now setup serial i/o
const serial_hw_baudrate = 9_600  -- bluetooth default baudrate
include serial_hardware           -- include the serial i/o library
serial_hw_init()                  -- initialise serial hardware

-- output library
include print                     -- include print library
const byte string1[]="Gday! Gday! Gday!"  -- sign on message

-- output signon message
print_string(serial_hw_data, string1)

-- store received char
var byte rxchar

-- store delay; default (10 x 100ms) 1 second
var byte ndelay = 10

-- LOOP
forever loop
   onboard_led = on    -- turn on LED
   serial_hw_data = 49 -- send "0" via serial port

   delay_100ms(ndelay) -- do delay
   onboard_led = off   -- turn off LED
   serial_hw_data = 48 -- send "1" via serial port

   if serial_hw_read(rxchar)    then
      serial_hw_write(rxchar)   -- echo received character
   end if

   -- check for special received characters and set delay
   if rxchar == "0" then
         ndelay = 10
   elsif rxchar == "1" then
         ndelay = 1
   elsif rxchar == "2" then
         ndelay = 2
   elsif rxchar == "3" then
         ndelay = 3
   elsif rxchar == "4" then
         ndelay = 4
   elsif rxchar == "5" then
         ndelay = 5
   end if

   delay_100ms(ndelay)  -- do delay
end loop
```


----------



## sidetone (Feb 23, 2021)

trev
Were the instructions you used for a dongle of Bluetooth version 1.x or maybe 2.x? Which Bluetooth version(s) was the dongle of?

Also, if you were aware at the time, which version(s) of Bluetooth were the peripherals of?


Bluetooth 1.1 is the most standard one, which is in FreeBSD's base. ng_ubt(4) in base is for v1.1. Manpages also of note: hccontrol(8), hcsecd(8), hcsecd.conf(5), l2ping(8), cu(1) and rfcomm_sppd(1).

There are (or were) a few Bluetooth 2.x drivers in ports, but they're not standard.

Bluetooth versions 3.x to 5.x possibly work without Bluetooth drivers.


----------



## trev (Feb 24, 2021)

The BT HC-06 module specs:

Built-in CSR company Bluetooth chip BC417143
Bluetooth® Technology v2.0 + EDR
TTL data transparent transfer between a host Bluetooth device
Compatible with all Bluetooth adapters that support SPP
Coverage up to 30 ft / 10 m (Class 2)
Built in antenna
Power input: +3.1 to 4.2 VDC (bluetooth module)
Compact Size
Can set the module control parameters and control commands via AT commands
The maximum serial baud rate: 1382400 bps, support for hardware flow control transfer
Provide seven input and output ports, scalable user IO resources
Connection/non-connection status indicators


----------



## sidetone (Feb 24, 2021)

It seems like a Bluetooth version 2.0 dongle worked on the ng_ubt driver, which is for Bluetooth version 1.1. So a 2.0 Bluetooth dongle functioned as a v1.1 Bluetooth capability device?

ng_ubt(4) states:

```
Isochronous USB transfers are broken.  This means that the USB device
     will not be able to transfer SCO data (voice).  USB interrupt transfers
     are implemented as bulk-in transfers (not really a bug).
```
SCO = synchronous connection oriented

I think it means, this driver allows sound transfer, but not real-time two way audio for communication.


----------



## trev (Feb 24, 2021)

According to the BC417143 datasheet:



> 9.1.1 Key Features of the HCI Stack: Standard Bluetooth Functionality
> 
> Bluetooth v2.0 + EDR mandatory functionality:
> 
> ...



As to the different BT version specifications:



> *Version 1.0 – 3.0: Bluetooth Classic*​
> When we talk about each iteration of Bluetooth, three factors help distinguish between the different versions: *range*, *data speed and power consumption*. These factors are determined by the modulation scheme and data packet being used. When the first version of Bluetooth came out, it paved the way for the wireless headphones, speakers and game controllers that we use today. However, back then Bluetooth 1.0 *was far slower than what we have now*. Data speeds capped off at 1 Mbps and the range only reached as far as 10 meters.
> 
> 
> ...



All of which suggests to me that ng_ubt(4) should support v2.0 devices (it cerrainly did back in 2016 when I was running some version of FreeBSD 10). The man page hasn't been updated since Dec 2012...


----------



## sidetone (Feb 24, 2021)

I see that ng_ubt supported a v2.0 Bluetooth device. I was wondering if the driver supported the v2.0 dongle under v1.1 functionality or v2.0 functionality. Either way, it supports it enough on some level.

Documentation on Bluetooth hasn't been updated in a while, so I wonder what the functionalities of Bluetooth are, according to what some say rather than what is in many ways outdated documentation.

Maybe versions 1.1 and 2.x work under ng_ubt. I'm starting to think that version 3 and/or 4 don't work. Bluetooth v5.x dongles made for audio only might work in another way, perhaps not as Bluetooth devices.


----------



## trev (Feb 24, 2021)

Looking at the code, these are listed as supported devices:


```
)/* List of supported bluetooth devices */
static const STRUCT_USB_HOST_ID ubt_devs[] =
{
        /* Generic Bluetooth class devices */
        { USB_IFACE_CLASS(UDCLASS_WIRELESS),
          USB_IFACE_SUBCLASS(UDSUBCLASS_RF),
          USB_IFACE_PROTOCOL(UDPROTO_BLUETOOTH) },

        /* AVM USB Bluetooth-Adapter BlueFritz! v2.0 */
        { USB_VPI(USB_VENDOR_AVM, 0x3800, 0) },

        /* Broadcom USB dongles, mostly BCM20702 and BCM20702A0 */
        { USB_VENDOR(USB_VENDOR_BROADCOM),
          USB_IFACE_CLASS(UICLASS_VENDOR),
          USB_IFACE_SUBCLASS(UDSUBCLASS_RF),
          USB_IFACE_PROTOCOL(UDPROTO_BLUETOOTH) },

        /* Apple-specific (Broadcom) devices */
        { USB_VENDOR(USB_VENDOR_APPLE),
          USB_IFACE_CLASS(UICLASS_VENDOR),
          USB_IFACE_SUBCLASS(UDSUBCLASS_RF),
          USB_IFACE_PROTOCOL(UDPROTO_BLUETOOTH) },

        /* Foxconn - Hon Hai */
        { USB_VENDOR(USB_VENDOR_FOXCONN),
          USB_IFACE_CLASS(UICLASS_VENDOR),
          USB_IFACE_SUBCLASS(UDSUBCLASS_RF),
          USB_IFACE_PROTOCOL(UDPROTO_BLUETOOTH) },

        /* MediaTek MT76x0E */
        { USB_VPI(USB_VENDOR_MEDIATEK, 0x763f, 0) },

        /* Broadcom SoftSailing reporting vendor specific */
        { USB_VPI(USB_VENDOR_BROADCOM, 0x21e1, 0) },

        /* Apple MacBookPro 7,1 */
        { USB_VPI(USB_VENDOR_APPLE, 0x8213, 0) },

        /* Apple iMac11,1 */
        { USB_VPI(USB_VENDOR_APPLE, 0x8215, 0) },

        /* Apple MacBookPro6,2 */
        { USB_VPI(USB_VENDOR_APPLE, 0x8218, 0) },

        /* Apple MacBookAir3,1, MacBookAir3,2 */
        { USB_VPI(USB_VENDOR_APPLE, 0x821b, 0) },

        /* Apple MacBookAir4,1 */
        { USB_VPI(USB_VENDOR_APPLE, 0x821f, 0) },

        /* MacBookAir6,1 */
        { USB_VPI(USB_VENDOR_APPLE, 0x828f, 0) },

        /* Apple MacBookPro8,2 */
        { USB_VPI(USB_VENDOR_APPLE, 0x821a, 0) },

        /* Apple MacMini5,1 */
        { USB_VPI(USB_VENDOR_APPLE, 0x8281, 0) },

        /* Bluetooth Ultraport Module from IBM */
        { USB_VPI(USB_VENDOR_TDK, 0x030a, 0) },

        /* ALPS Modules with non-standard ID */
        { USB_VPI(USB_VENDOR_ALPS, 0x3001, 0) },
        { USB_VPI(USB_VENDOR_ALPS, 0x3002, 0) },

        { USB_VPI(USB_VENDOR_ERICSSON2, 0x1002, 0) },

        /* Canyon CN-BTU1 with HID interfaces */
        { USB_VPI(USB_VENDOR_CANYON, 0x0000, 0) },

        /* Broadcom BCM20702A0 */
        { USB_VPI(USB_VENDOR_ASUS, 0x17b5, 0) },
        { USB_VPI(USB_VENDOR_ASUS, 0x17cb, 0) },
        { USB_VPI(USB_VENDOR_LITEON, 0x2003, 0) },
        { USB_VPI(USB_VENDOR_FOXCONN, 0xe042, 0) },
        { USB_VPI(USB_VENDOR_DELL, 0x8197, 0) },
        { USB_VPI(USB_VENDOR_BELKIN, 0x065a, 0) },
};
```


----------



## trev (Feb 25, 2021)

As the Intel Mac mini 2011 (models 5,1 and 5,2) is supported, it's BT is Bluetooth 4.0 and as I happen to have one running FreeBSD, dmesg shows: ugen1.6: <Apple Inc. Bluetooth USB Host Controller> at usbus1. I've never tried to use it though, my BT experiments were carried out with a 2009 Mac mini running FreeBSD.


----------



## Phishfry (Jul 4, 2021)

trev said:


> Xbee board


Can you tell me how you are interfacing Xbee on FreeBSD?
Is it using USB via the XBee Explorer boards?


----------



## trev (Jul 25, 2021)

It was a blank Xbee PCB which I bought and to which I soldered a BT HC-06 module for insertion into a Jaluino Bee I'd constructed. See pic - the two rows of horizontal headers on the left were for the Xbee PCB to plug in. It communicated with FreeBSD over BT.


----------

