汝の名はBlueZ - (6)

前回の続きから。
hiro99ma blog: 汝の名はBlueZ - (5)

---

前回は、BlueZの新しいソースを持ってきて、Raspberry Piでビルドしていて、眠たくて中断させたところまでだ。
Raspberry Piでのセルフビルドは進めるとして、クロスコンパイルも出来た方がよいだろう。
BlueZをgitで落としてきて、まずはconfigureのhelpを確認。
・・・configureがない。

$ aclocal
$ autoconf
configure.ac:32: error: possibly undefined macro: AC_DISABLE_STATIC
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.
configure.ac:33: error: possibly undefined macro: AC_PROG_LIBTOOL

怒られた(私はxubuntu14.04でやってる)。
検索すると、以下が出てきた。
Karuraの日記: autoconf automake の失敗 (undefind macro)
書いてあるようにdpkg-reconfigureすると、直った。ありがたい。

というところで、Raspberry Piでのセルフビルドが終わってしまった。
クロスコンパイルは、そのうちやろう(やらないパターン)。

---

さて、書いてある手順通りにやったのだけど、うまくいかん。
うまくいかんというか、USBドングルが動いてないみたいだ。
dmesgを見てもbtusbがあるといってるし、lsusbで見てもHCIモードになってると出てるし。
うーむ。。。。とごにょごにょやっていたら、動いた。
1つ勘違いしていたのは、hci0が/devに見えてないから動いてないと思っていたことだ。
eth0と同じで、これは見えないようである。
hciconfigだけ打つと、hci0が動いていたら出てくるので、まずはそれで確認するのがよいだろう。
(lescanしても動かなかったのだけど。。。まあ動いているからよしとしよう)

ではgatttoolで、と思ったら、コマンドがない。
ビルドはされてるのに・・・。
と思ったら、こちらによると手動コピーらしい。
Linux でBLEのドングルを刺して通信させる。 | mbed
こちらのサイト、上の方しか見てなかったんだけど、下の方にBlueZをRaspberry Piでビルドすることも書かれているのね・・・。

なので、ここであれこれ書いたことよりも、上記のサイトを見た方がわかりやすいと思う。

---

さて、connectで気になっていたことを確認しよう。
Central側でSCANNINGを行っていなくてもCONNECTできるかどうか、だ。
Raspberry Piを再起動させて一からやっておこう(PeripheralはTI SensorTag)。

pi@raspberrypi ~ $ hciconfig
hci0:   Type: BR/EDR  Bus: USB
        BD Address: 00:1B:DC:05:7F:D0  ACL MTU: 310:10  SCO MTU: 64:8
        DOWN
        RX bytes:564 acl:0 sco:0 events:29 errors:0
        TX bytes:358 acl:0 sco:0 commands:29 errors:0

pi@raspberrypi ~ $ sudo hciconfig hci0 up
pi@raspberrypi ~ $ hciconfig
hci0:   Type: BR/EDR  Bus: USB
        BD Address: 00:1B:DC:05:7F:D0  ACL MTU: 310:10  SCO MTU: 64:8
        UP RUNNING
        RX bytes:1128 acl:0 sco:0 events:58 errors:0
        TX bytes:716 acl:0 sco:0 commands:58 errors:0

pi@raspberrypi ~ $ sudo gatttool -b 34:B1:F7:D4:FA:33 -I
[34:B1:F7:D4:FA:33][LE]> connect
Attempting to connect to 34:B1:F7:D4:FA:33
Connection successful
[34:B1:F7:D4:FA:33][LE]>primary
attr handle: 0x0001, end grp handle: 0x000b uuid: 00001800-0000-1000-8000-00805f9b34fb
attr handle: 0x000c, end grp handle: 0x000f uuid: 00001801-0000-1000-8000-00805f9b34fb
attr handle: 0x0010, end grp handle: 0x0022 uuid: 0000180a-0000-1000-8000-00805f9b34fb
attr handle: 0x0023, end grp handle: 0x002d uuid: f000aa00-0451-4000-b000-000000000000
attr handle: 0x002e, end grp handle: 0x0038 uuid: f000aa10-0451-4000-b000-000000000000
attr handle: 0x0039, end grp handle: 0x0043 uuid: f000aa20-0451-4000-b000-000000000000
attr handle: 0x0044, end grp handle: 0x004e uuid: f000aa30-0451-4000-b000-000000000000
attr handle: 0x004f, end grp handle: 0x005d uuid: f000aa40-0451-4000-b000-000000000000
attr handle: 0x005e, end grp handle: 0x0068 uuid: f000aa50-0451-4000-b000-000000000000
attr handle: 0x0069, end grp handle: 0x006d uuid: 0000ffe0-0000-1000-8000-00805f9b34fb
attr handle: 0x006e, end grp handle: 0x0078 uuid: f000ccc0-0451-4000-b000-000000000000
attr handle: 0x0079, end grp handle: 0x0085 uuid: f000bcc0-0451-4000-b000-000000000000
attr handle: 0x0086, end grp handle: 0xffff uuid: f000ffc0-0451-4000-b000-000000000000
[34:B1:F7:D4:FA:33][LE]> quit

Peripheralのアドレスがわかっていて、PeripheralがAdvertisingしていれば、Central側はScanningしなくてもConnectionができるということがわかった。
ただ、もしかしたらgatttoolが自動的にScanningをしているのかもしれない。
というよりも、Scannningというステータスにするかどうかは別として、飛んでる無線を捉まえないといかんから受信はするのだ。
だから「BlueZではアドレスがわかっていたらgatttoolでconnectできる」くらいにしておこう。
まあ、事前にアドレスがわかるっていう状況がどういう場合かはわからんがね。

あと、今のgatttoolは「[CON]」と表示されるのではなく、アドレスの表示色が変わるようになっていた。
上のログは、一番最後のアドレス部分が青く出力されている(TeraTerm上では)。

---

connectした状態でgatttoolからdisconnectしたり、Peripheralから切断したりすると、こう出てきた。

(gatttool:2202): GLib-WARNING **: Invalid file descriptor.

どこかで、イベントを処理する部分があるようだ。
g_main_loop_run()がそれっぽいのだが、本体がBlueZの中にはない。
検索すると、GLibのようだ。
https://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.html#g-main-loop-run

g_で始まってるのがいくつかあるから、グローバル変数とかグローバル関数とかのプレフィクスかと思ってたけど、GLibなのか・・・。
せめて「glib_」になってるとうれしいのだが、せんなきことじゃ。