The BlueZ package contains the Bluetooth protocol stack for Linux.
This package is known to build and work properly using an LFS-7.4 platform.

*http://www.bluez.org/

BlueZ 4.x was released in Aug 2008 with the following major changes over BlueZ 3.x:

-Merged bluez-libs and bluez-utils together -Main daemon now called bluetoothd (instead of hcid) -Main config file is /etc/bluetooth/main.conf following an INI-style syntax -GLib no longer optional (eglib support fully removed) -Old D-Bus API from 3.x series fully removed -New D-Bus API is defined in ​doc/network-api.txt

https://m.blog.naver.com/PostView.nhn?blogId=juke45ef&logNo=220827583111&proxyReferer=&proxyReferer=https%3A%2F%2Fwww.google.co.kr%2F
http://bluez.sourceforge.net/contrib/HOWTO-PAN
https://wiki.gumstix.com/index.php/Category:How_to_-_bluetooth
https://delog.wordpress.com/2014/10/29/bluetooth-on-raspberry-pi-with-buildroot/
https://delog.wordpress.com/2014/10/24/customize-buildroot-to-build-bluez-tools/
https://www.slackwiki.com/Bluetooth
https://learn.adafruit.com/install-bluez-on-the-raspberry-pi/installation
https://www.bluetooth.com
http://www.dreamy.pe.kr/zbxe/CodeClip/3768999

https://elinux.org/Bluetooth_Network
Dial up (DUN) via bluetooth and Network Manager. https://ubuntuforums.org/showthread.php?t=2124919
Bluetooth https://wiki.archlinux.org/index.php/Bluetooth
http://www.tik.ee.ethz.ch/~beutel/pub/bluezhowto.pdf
http://www.ioncannon.net/linux/1570/bluetooth-4-0-le-on-raspberry-pi-with-bluez-5-x/
Bluetooth headset https://wiki.archlinux.org/index.php/Bluetooth_headset
http://trac.gateworks.com/wiki/wireless/bluetooth

https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-wireless/bluez/files/?hideattic=0

*Download (HTTP): http://www.kernel.org/pub/linux/bluetooth/bluez-4.101.tar.xz
*Download (FTP): ftp://ftp.kernel.org/pub/linux/bluetooth/bluez-4.101.tar.xz
*Download MD5 sum: c828c172f01f20c6ecd7f407894956a2
*Download size: 868 KB
*Estimated disk space required: 42 MB
*Estimated build time: 0.8 SBU

D-Bus-1.6.14 and GLib-2.36.4

alsa-lib-1.0.27.2, Check-0.9.10, gst-plugins-base-0.10.36, libsndfile-1.0.25, and libusb-compat-0.1.5

User Notes: http://wiki.linuxfromscratch.org/blfs/wiki/bluez

아래와 같이 커널 설정에 필요한 옵션을 인에이블 한다. 이와 같이 되어 있지 않았었다면 커널을 재 컴파일 해야겠지:

[*] Networking support --->
  <*> or <M> Bluetooth subsystem support --->
    <*> or <M> RFCOMM protocol support
    [*] RFCOMM TTY support
    <*> or <M> BNEP protocol support
    [*] Multicast filter support
    [*] Protocol filter support
    <*> or <M> HIDP protocol support

    Bluetooth device drivers --->

블루투스 디바이스 드라이버는 우리 하드웨어에 따라 설정한다.

우리의 BlueZ 라이브러리는 Buildroot를 통해 설치 할 수 있다.

아래와 같이 BlueZ를 따로 설치 가능하다.

./configure --prefix=/usr        \
            --sysconfdir=/etc    \
            --localstatedir=/var \
            --libexecdir=/lib    \
            --enable-bccmd       \
            --enable-dfutool     \
            --enable-dund        \
            --enable-hid2hci     \
            --enable-hidd        \
            --enable-pand        \
            --enable-tools       \
            --enable-wiimote     \
            --disable-test       \
            --without-systemdunitdir &&
make

This package does not come with a test suite.

Now, as the root user:

make install

Install required configuration files as the root user:

for CONFFILE in audio input network serial ; do
  install -v -m644 ${CONFFILE}/${CONFFILE}.conf /etc/bluetooth/${CONFFILE}.conf
done
unset CONFFILE

If desired, install the API documentation as the root user:

install -v -m755 -d /usr/share/doc/bluez-4.101 &&
install -v -m644 doc/*.txt /usr/share/doc/bluez-4.101

–enable-bccmd: This switch enables building of the BCCMD interface utility.

–enable-dfutool: This switch enables building of the DFU firmware upgrade utility.

–enable-dund: This switch enables building of the DUN daemon.

–enable-hid2hci: This switch enables building of the HID mode switching utility.

–enable-hidd: This switch enables building of the HID daemon.

–enable-pand: This switch enables building of the PAN daemon.

–enable-tools: This switch enables building of the Bluetooth utilities.

–enable-wiimote: This switch enables building of the Wii Remote plugin.

–disable-test: This switch disables installation of the test programs.

–without-systemdunitdir: This switch disables installation of the systemd units.

–enable-cups: This switch enables CUPS backend support. Note that CUPS does not need to be installed for this support.

/etc/init/bluetooth.conf - bluetooth daemon init

buildroot로 만든 rootfs에는 이의 폴더와 파일은 존재하지 않는다.
폴더만 나중에 새로 생성한다

/etc/bluetooth/main.conf - main bluetooth daemon config

• name of device (when discoverable)

존재는 하지만 실제 사용되는지는 알 수 없다.
실제로 여기의 변수를 수정하여도 적용되는 것 같지 않다.
변화가 전혀 없다.

/etc/bluetooth/input.conf - configuration of the input service

buildroot로 만든 rootfs에는 이의 폴더와 파일은 존재하지 않는다.

/etc/bluetooth/audio.conf - configuration of the audio service (SCO routing: PCM or HCI)

buildroot로 만든 rootfs에는 이의 폴더와 파일은 존재하지 않는다.

/etc/bluetooth/network.conf - configuration of the network service (link encryption)

buildroot로 만든 rootfs에는 이의 폴더와 파일은 존재하지 않는다.

/etc/bluetooth/rfcomm.conf - configuration of rfcomm layer

존재는 하지만 실제 사용되는지는 알 수 없다.
실제로 여기의 변수를 수정하여도 적용되는 것 같지 않다.
변화가 전혀 없다.

/etc/bluetooth/serial.conf - configuration of serial (DUN tty, UID)

buildroot로 만든 rootfs에는 이의 폴더와 파일은 존재하지 않는다.

To automatically start the bluetoothd daemon when the system is rebooted, install the /etc/rc.d/init.d/bluetooth bootscript from the blfs-bootscripts-20130908 package.

make install-bluetooth

The standard user psace tools are:

bluetoothd - Bluetooth Daemon that manages all Bluetooth devices and configured via /etc/bluetooth/main.conf. Provides a number of services via D-Bus message bus system
hcitool
hciattach
hciconfig
l2ping
l2test
sdptool

some distros (ie Ubuntu) will provide a set of bluetooth compatibility binaries in a bluez-compat package that provide the following tools which were removed from bluez4:

​pand - Personal Area Network (PAN) networking daemon
​dund - Dial-Up Networking daemon
​hidd - Bluetooth HID daemon

bccmd
ciptool
dfutool
gatttool
hid2hci
rfcomm

libbluetooth.so

/etc/bluetooth, /usr/include/bluetooth, /usr/lib/bluetooth, /usr/share/doc/bluez-4.101, and /var/lib/bluetooth

• bccmd - is used to issue BlueCore commands to Cambridge Silicon Radio devices.
  
• bluetoothd - is the Bluetooth daemon.
• ciptool - is used to set up, maintain, and inspect the CIP configuration of the Bluetooth subsystem in the Linux kernel.
• dfutool - is used to verify, archive and upgrade firmware files.
• dund - is the Bluetooth dial-up networking daemon.
• hciattach - is used to attach a serial UART to the Bluetooth stack as HCI transport interface.
• hciconfig - is used to configure Bluetooth devices.
• hcitool - is used to configure Bluetooth connections and send some special command to Bluetooth devices.
• hid2hci - is used to set up switch supported Bluetooth devices into the HCI mode and back.
• hidd - is the Bluetooth HID daemon.
• l2ping - is used to send a L2CAP echo request to the Bluetooth MAC address given in dotted hex notation.
• pand - is the Bluetooth daemon that allows you to connect to ethernet networks using Bluetooth.
• rfcomm - is used to set up, maintain, and inspect the RFCOMM configuration of the Bluetooth subsystem in the Linux kernel.
• sdptool - is used to perform SDP queries on Bluetooth devices.
• libbluetooth.so - contains the BlueZ API functions.

* https://code.google.com/archive/p/bluez-tools/

The BlueZ stack uses the ​D-Bus message bus system which is a simple way for applications to talk to one another.

The BlueZ 4 D-Bus API is defined in ​doc/network-api.txt. Some example usage using dbus-send:

* First you need to get the path to the bluetooth controller you wish to use. We will assign it to a shell env variable and export it for future use:

export BTADAPTER=`dbus-send --system --dest=org.bluez --print-reply / org.bluez.Manager.DefaultAdapter | tail -1 | sed 's/^.*"\(.*\)".*$/\1/'`

* To introspect with you can use something like:

# dbus-send --system --dest=org.bluez --print-reply $BTADAPTER org.freedesktop.DBus.Introspectable.Introspect

* To make your controller discoverable:

# dbus-send --system --dest=org.bluez --print-reply $BTADAPTER org.bluez.Adapter.SetProperty string:Discoverable variant:boolean:true

* To disable discovery:

# dbus-send --system --dest=org.bluez --print-reply $BTADAPTER org.bluez.Adapter.SetProperty string:Discoverable variant:boolean:false

* To list paired devices:

# dbus-send --system --dest=org.bluez --print-reply $BTADAPTER org.bluez.Adapter.ListDevices

* To trust a device:

dbus-send --system --dest=org.bluez --print-reply $BTADAPTER/dev_54_46_6B_01_7B_2B org.bluez.Device.SetProperty string:Trusted variant:boolean:true

* To connect to an HID device (must pair first and can see the path above):

# dbus-send --system --dest=org.bluez --print-reply $BTADAPTER/dev_54_46_6B_01_7B_2B org.bluez.Input.Connect
[ 2710.946655] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
[ 2710.952642] Bluetooth: HIDP socket layer initialized
method return sender=:1.3 -> dest=:1.13 reply_serial=2
root@ventana:~# [ 2711.352289] hid-generic 0005:0A5C:8502.0001: unknown main item tag 0x0
[ 2711.359234] input: Bluetooth FAVI as /devices/soc0/soc.0/2100000.aips-bus/2184000.usb/ci_hdrc.0/usb1/1-1/1-
1:1.0/bluetooth/hci0/hci0:42/0005:0A5C:8502.0001/input/input1
[ 2711.374829] hid-generic 0005:0A5C:8502.0001: input: BLUETOOTH HID v1.1b Keyboard [Bluetooth FAVI] on 

00:15:83:3d:0a:57

evtest /dev/input/event1

In order to use Bluetooth a device must be compatible with a subset of Bluetooth profiles for specific services. These profiles sit on top of the Bluetooth Core specification and protocols.

The way a device uses Bluetooth technology depends on its profile capabilities. The profiles provide standards which manufacturers follow to allow devices to be compatible.

A full list of profiles can be found ​here however here are some common ones are described in detail in the sections below

PAN

The Personal Area Network Device Profile (PAN) allows encapsulating IP over bluetooth using the Bluetooth Network Encapsulation Protocol (BNEP). The kernel bnep module (CONFIG_BT_BNEP) is responsible for registering a bnep<n> network interface when requested by the Bluetooth daemon. You do not need to use paring for PAN connections. Once a PAN connection is active and you have a bnep<n> interface you can use standard networking tools to configure and/or bridge the interface.

*NAP - Network Access Point
*PANU - PAN User (client to a PAN NAP)
*GN - Group Network (adhoc based)

*Using the pand tool from the bluez-compat package

to use the pand application for BlueZ 4.x you must disable the internal network plugin in its bluetooth daemon.
To do this add a 'DisablePlugins=network' to /etc/bluetooth/main.conf under the [General] section and restart the bluetooth daemon)

* Using the bt-network application from the bluez-tools package (requires pairing):

Machine1: server / NAP:

# hciconfig hci0 up # bring up controller
# hciconfig hci0 piscan # make discoverable
# brctl addbr br0 # add a bridge
# bt-network --server nap br0 # run NAP service
NAP server registered

Machine2: client / PANU:

# hciconfig hci0 up # bring up controller
# hciconfig hci0 piscan # make discoverable
# sdptool search NAP # search for NAP service
# bt-network --connect 00:02:72:C9:56:47 nap &

https://www.raspberrypi.org/forums/viewtopic.php?t=37655
https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=127873

https://www.raspberrypi.org/forums/viewtopic.php?f=36&t=47499

Bluetooth: main.conf seems to be ignored
https://www.raspberrypi.org/forums/viewtopic.php?t=86963

https://bbs.archlinux.org/viewtopic.php?pid=1376448#p1376448
https://www.linuxquestions.org/questions/linux-wireless-networking-41/setting-up-bluez-with-a-passkey-pin-to-be-used-as-headset-for-iphone-816003/
http://egloos.zum.com/chammoru/v/4532626
https://sites.google.com/a/honglab.org/honglab-project/raspberrypi/osonnoteu-bojogigi/6beullutuseupaekijiseolchihagohyudaepongwayeongyeolhagi
http://gun0123.tistory.com/85
https://manpages.debian.org/jessie/bluez-tools/bt-obex.1.en.html#OPTIONS
https://www.linuxquestions.org/questions/linux-software-2/bluez-hcitool-not-able-to-scan-734689/
https://www.linuxquestions.org/questions/linux-general-1/issue-with-bluez-pin-i-think-547891/
network manager no option for bluetooth devices https://bbs.archlinux.org/viewtopic.php?id=105121
https://stackoverflow.com/questions/45887176/is-it-possible-to-use-bluez-4-101-create-ble-peripheral-and-service
https://www.linuxquestions.org/questions/linux-wireless-networking-41/setting-up-bluez-with-a-passkey-pin-to-be-used-as-headset-for-iphone-816003/
https://askubuntu.com/questions/439088/how-to-change-bluetooth-device-class
https://forum.odroid.com/viewtopic.php?f=95&t=13187
https://bugzilla.mozilla.org/show_bug.cgi?id=1191265
https://bugzilla.mozilla.org/show_bug.cgi?id=1143925
https://lists.debian.org/debian-user/2013/07/msg00766.html
https://www.linuxquestions.org/questions/linux-wireless-networking-41/setting-up-bluez-with-a-passkey-pin-to-be-used-as-headset-for-iphone-816003/
https://www.linuxquestions.org/questions/slackware-14/bluetooth-not-working-slackware-14-0-rc4-and-bluez-4-99-a-4175427292-print/
https://forums.gentoo.org/viewtopic-t-923578-start-0.html

http://alnova2.tistory.com/84
Bluetooth dongle은 class I, class II, class III 로 분류가 된다. Class I은 100 meter까지 send/receive 가 가능한 장치가 되고, class II는 10 meter까지, class III는 1 meter까지 가능하다. 대부분 laptop과 PDA에는 class II 장치 들이 들어가 있다.

1. Bluetooth 관련 package 설치 pacman -S bluz-libs bluez-utils iptables ppp (BlueZ Bluetooth 설치) – BlueZ는 http://www.bluez.org/ 에서 볼수 있다. 이 경우 pacman이라는 Arch linux용 package manager가 된다. /etc/bluetooth/pin 파일을 수정하고 숫자를 넣는다. (기본적으로 BlueZ로 되어 있으나 어떤 장치들은 숫자 PIN으로만 동작 할수도 있다.) /etc/bluetooth/rfcomm.conf 파일을 수정하고..(다음은 예제이다.)

rfcomm0 {

      # Automatically bind the device at startup
      bind yes;     # original: bind yes

      # Bluetooth address of the device
      # device 11:22:33:44:55:66
      # comment out the devices' MAC addresses

      # RFCOMM channel for the connection
      channel 3; # was channel 1

      # Description of the connection
      comment "Bluetooth Access Point";

}

/etc/bluetooth/hcid.conf 를 수정한다.( 옵션이지만 유용하다.)

name “%d h%” —> name “BlueZ” 그리고 /etc/ppp/options 를 수정하는데, “auth”를 “noauth”로 수정하고 (약 25-30라인쯤) 15-20라인쯤에 DNS 정보를 추가한다. (다음은 예시이다.)

ms-dns 216.148.227.62 ms-dns 204.127.202.2 (잘 모르겠으면 /etc/resolv.conf의 IP address를 복사하면 됨) 2. The Access Point service 다음은 실제 서비스를 시작할때 필요하다.

/etc/rc.d/bluetooth start /etc/rc.d/bluetooth stop

(bluetooth를 시작하고 정지 해야 된다..아마 다른 initializing factor가 존재하기 때문인듯) 그리고 다음의 script를 수행한다.

modprobe rfcomm modprobe hci_usb

mknod /dev/rfcomm0 c 216 0 mknod /dev/rfcomm1 c 216 1 mknod /dev/rfcomm2 c 216 2 mknod /dev/rfcomm3 c 216 3

hciconfig hci0 up hcid sdptool add SP sdpd rfcomm bind all # first IP address is the one of the server, # second the one of the client; change accordingly, depending on your network dund –listen –msdun –channel 3 10.0.0.102:10.0.0.111 echo '1' > /proc/sys/net/ipv4/ip_forward # use a different eth0 name if your server's incoming #internet connection is coming from a different device #(e.g. might be sit0 or ppp1, depending how your Arch Linux is connected to the outside world). iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE iptables -A FORWARD -i ppp0 -j ACCEPT iptables -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT 하나의 btlan.sh라는 script로 만들어서 실행 권한을 주고 chmod +x btlan.sh

이걸 /usr/sbin/ 에 놓음 이걸 실행 시키면 된다~

3. 클라이언트에서 접속 bluetooth services를 시작하고 (/etc/rc.d/bluetooth start 또는 /etc/rc.d/init.d/bluetooth start) 다음과 같은 작업을 한다 hcitool scan # the above will give you something like: # 00:11:22:33:44:55 BlueZ

modprobe bnep

# use the number found above pand -c 00:11:22:33:44:55

# this is the IP address of your Linux client, change accordingly ifconfig bnep0 10.0.0.111 netmask 255.255.255.0

# this is the address of your Arch Access Point server, change accordingly route add default gw 10.0.0.102

ifconfig bnep0 up

[출처는 http://www.osnews.com/story.php/9836/Make-your-Arch-Linux-a-Bluetooth-Access-Point/page1/ 이고 몇몇 내용은 추가하였습니다]

출처: http://alnova2.tistory.com/84 [몽상가]

http://blog.fraggod.net/2015/03/28/bluetooth-pan-network-setup-with-bluez-5x.html
It probably won't be a surprise to anyone that Bluetooth has profiles to carry regular network traffic, and BlueZ has support for these since forever, but setup process has changed quite a bit between 2.X - 4.X - 5.X BlueZ versions, so here's my summary of it with 5.29 (latest from fives atm).

First step is to get BlueZ itself, and make sure it's 5.X (at least for the purposes of this post), as some enerprisey distros probably still have 4.X if not earlier series, which, again, have different tools and interfaces. Should be easy enough to do with bluetoothctl –version, and if BlueZ doesn't have “bluetoothctl”, it's definitely some earlier one. Hardware in my case was two linux machines with similar USB dongles, one of them was RPi (wanted to setup wireless link for that), but that shouldn't really matter.

Aforementioned bluetoothctl allows to easily pair both dongles from cli interactively (and with nice colors!), that's what should be done first and serves as an authentication, as far as I can tell.

— machine-1 % bluetoothctl [NEW] Controller 00:02:72:XX:XX:XX malediction [default] [bluetooth]# power on Changing power on succeeded [CHG] Controller 00:02:72:XX:XX:XX Powered: yes [bluetooth]# discoverable on Changing discoverable on succeeded [CHG] Controller 00:02:72:XX:XX:XX Discoverable: yes [bluetooth]# agent on …

— machine-2 (snipped) % bluetoothctl [NEW] Controller 00:02:72:YY:YY:YY rpbox [default] [bluetooth]# power on [bluetooth]# scan on [bluetooth]# agent on [bluetooth]# pair 00:02:72:XX:XX:XX [bluetooth]# trust 00:02:72:XX:XX:XX … Not sure if the “trust” bit is really necessary, and what it does - probably allows to setup agent-less connections or something.

As I needed to connect small ARM board to what amounts to an access point, “NAP” was the BT-PAN mode of choice for me, but there are also “ad-hoc” modes in BT like PANU and GN, which seem to only need a different topology (who connects to who) and pass different UUID parameter to BlueZ over dbus.

For setting up a PAN network with BlueZ 5.X, essentially just two dbus calls are needed (described in “doc/network-api.txt”), and basic cli tools to do these are bundled in “test/” dir with BlueZ sources.

Given that these aren't very suited for day-to-day use (hence the “test” dir) and are fairly trivial, did rewrite them as a single script, more suited for my purposes - bt-pan.

Update 2015-12-10: There's also “bneptest” tool, which comes as a part of e.g. “bluez-utils” package on Arch, which seem to do same thing with its “-s” and “-c” options, just haven't found it at the time (or maybe it's a more recent addition).

General idea is that one side (access point in NAP topology) sets up a bridge and calls “org.bluez.NetworkServer1.Register()”, while the other (“client”) does “org.bluez.Network1.Connect()”.

On the server side (which also applies to GN mode, I think), bluetoothd expects a bridge interface to be setup and configured, to which it adds individual “bnepX” interfaces created for each client by itself.

Such bridge gets created with “brctl” (from bridge-utils), and should be assigned the server IP and such, then server itself can be started, passing name of that bridge to BlueZ over dbus in “org.bluez.NetworkServer1.Register()” call:

#!/bin/bash

br=bnep

-n "$(brctl show $br 2>&1 1>/dev/null)" && {

brctl addbr $br
brctl setfd $br 0
brctl stp $br off
ip addr add 10.1.2.3/24 dev $br
ip link set $br up

}

exec bt-pan –debug server $br (as mentioned above, bt-pan script is from fgtk github repo)

Update 2015-12-10: This is “net.bnep” script, as referred-to in “net-bnep.service” unit just below.

Update 2015-12-10: These days, systemd can easily create and configure bridge, forwarding and all the interfaces involved, even running built-in DHCP server there - see “man systemd.netdev” and “man systemd.network”, for how to do that, esp. examples at the end of both.

Just running this script will then setup a proper “bluetooth access point”, and if done from systemd, should probably be a part of bluetooth.target and get stopped along with bluetoothd (as it doesn't make any sense running without it):

[Unit] After=bluetooth.service PartOf=bluetooth.service

[Service] ExecStart=/usr/local/sbin/net.bnep

[Install] WantedBy=bluetooth.target Update 2015-12-10: Put this into e.g. /etc/systemd/system/net-bnep.service and enable to start with “bluetooth.target” (see “man systemd.special”) by running systemctl enable net-bnep.service.

On the client side, it's even simplier - BlueZ will just create a “bnepX” device and won't need any bridge, as it is just a single connection:

[Unit] After=bluetooth.service PartOf=bluetooth.service

[Service] ExecStart=/usr/local/bin/bt-pan client –wait 00:02:72:XX:XX:XX

[Install] WantedBy=bluetooth.target Update 2015-12-10: Can be /etc/systemd/system/net-bnep-client.service, don't forget to enable it (creates symlink in “bluetooth.target.wants”), same as for other unit above (which should be running on the other machine).

Update 2015-12-10: Created “bnepX” device is also trivial to setup with systemd on the client side, see e.g. “Example 2” at the end of “man systemd.network”.

On top of “bnepX” device on the client, some dhcp client should probably be running, which systemd-networkd will probably handle by default on systemd-enabled linuxes, and some dhcpd on the server-side (I used udhcpd from busybox for that).

Enabling units on both machines make them setup AP and connect on boot, or as soon as BT donges get plugged-in/detected.

Fairly trivial setup for a wireless one, especially wrt authentication, and seem to work reliably so far.

Update 2015-12-10: Tried to clarify a few things above for people not very familiar with systemd, where noted. See systemd docs for more info on all this.

In case something doesn't work in such a rosy scenario, which kinda happens often, first place to look at is probably debug info of bluetoothd itself, which can be enabled with systemd via systemctl edit bluetooth and adding a [Service] section with override like ExecStart=/usr/lib/bluetooth/bluetoothd -d, then doing daemon-reload and restart of the unit.

This should already produce a ton of debug output, but I generally find something like bluetoothd[363]: src/device.c:device_bonding_failed() status 14 and bluetoothd[363]: plugins/policy.c:disconnect_cb() reason 3 in there, which is not super-helpful by itself.

“btmon” tool which also comes with BlueZ provides a much more useful output with all the stuff decoded from the air, even colorized for convenience (though you won't see it here):

…

ACL Data RX: Handle 11 flags 0x02 dlen 20 [hci0] 17.791382

    L2CAP: Information Response (0x0b) ident 2 len 12
      Type: Fixed channels supported (0x0003)
      Result: Success (0x0000)
      Channels: 0x0000000000000006
        L2CAP Signaling (BR/EDR)
        Connectionless reception

> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 17.793368

      Num handles: 1
      Handle: 11
      Count: 2

> ACL Data RX: Handle 11 flags 0x02 dlen 12 [hci0] 17.794006

    L2CAP: Connection Request (0x02) ident 3 len 4
      PSM: 15 (0x000f)
      Source CID: 64

< ACL Data TX: Handle 11 flags 0x00 dlen 16 [hci0] 17.794240

    L2CAP: Connection Response (0x03) ident 3 len 8
      Destination CID: 64
      Source CID: 64
      Result: Connection pending (0x0001)
      Status: Authorization pending (0x0002)

> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 17.939360

      Num handles: 1
      Handle: 11
      Count: 1

< ACL Data TX: Handle 11 flags 0x00 dlen 16 [hci0] 19.137875

    L2CAP: Connection Response (0x03) ident 3 len 8
      Destination CID: 64
      Source CID: 64
      Result: Connection refused - security block (0x0003)
      Status: No further information available (0x0000)

> HCI Event: Number of Completed Packets (0x13) plen 5 [hci0] 19.314509

      Num handles: 1
      Handle: 11
      Count: 1

> HCI Event: Disconnect Complete (0x05) plen 4 [hci0] 21.302722

      Status: Success (0x00)
      Handle: 11
      Reason: Remote User Terminated Connection (0x13)

@ Device Disconnected: 00:02:72:XX:XX:XX (0) reason 3

… That at least makes it clear what's the decoded error message is, on which protocol layer and which requests it follows - enough stuff to dig into.

BlueZ also includes a crapton of cool tools for all sorts of diagnostics and manipulation, which - alas - seem to be missing on some distros, but can be built along with the package using –enable-tools –enable-experimental configure-options (all under “tools” dir).

I had to resort to these tricks briefly when trying to setup PANU/GN-mode connections, but as I didn't really need these, gave up fairly soon on that “Connection refused - security block” error (from that “policy.c” plugin) - no idea why BlueZ throws it in this context and google doesn't seem to help much, maybe polkit thing, idk.

Didn't need these modes though, so whatever.

I would like to connect multiple Pis in a PAN network, with one Pi running as the bridge. To that end I'm using multiple GBU521 USB Bluetooth adapters (show up as Broadcom devices).
So far I have been able to connect a Pi over PAN to a desktop (Ubuntu 13.04) acting as a bridge, but not a Pi to a Pi acting as a bridge.
Necessary packages:
Code:Select all

# apt-get install bluez-compat bluez-tools bridge-utils

First I paired the desktop and the Pi:
Code: Select all

# bt-adapter --set Discoverable 1
# bt-adapter --set Pairable 1
# bluez-simple-agent # on desktop

Code: Select all

# bt-adapter --set Discoverable 1
# bt-adapter --set Pairable 1
# bluez-simple-agent hci0 $DESKTOP_MAC_ADDRESS # on Pi

Next, on the desktop, I create a pan0 device for a bridge, and start the PAN using this device. I create the below two files and then run the following commands.
/etc/bluetooth/pan/dev-up:
Code: Select all

#!/bin/sh
ifconfig $1 up
brctl addif pan0 $1

/etc/bluetooth/pan/dev-down:
Code: Select all

#!/bin/sh
brctl delif pan0 $1
ifconfig $1 down

Code: Select all

# brctl addbr pan0
# brctl setfd pan0 0
# brctl stp pan0 off
# ifconfig pan0 192.168.2.1 netmask 255.255.255.0
# bt-network -s nap pan0

Finally, I connect from the client Pi:
Code: Select all

# pand -c $DESKTOP_MAC_ADDRESS
# ifconfig bnep0 down 192.168.2.2 netmask 255.255.255.0 up

After this I can ping, ssh, etc between the desktop and the Pi.
However, if I try to recreate the bridge steps on another Pi, I can't. There are no errors or differences in output on the bridge, but when the client runs “pand -c $OTHER_PI_MAC_ADDRESS”, no bnep0 device is created on the client, so ifconfig fails.
Yes, everything is using different (manual) IP addresses. Yes, I am getting the MAC addresses right… does anyone have ideas?

http://rakuraku.tistory.com/159

http://samse.tistory.com/entry/android-Bluetooth-LE-programmingBLE
http://chiccoder.tistory.com/15