Bluetooth は免許のいらない 2.4 GHz の帯域を利用して、 10 m 程度のパーソナルネットワークを作る無線技術です。 ネットワークはたいていの場合、その場その場で、携帯電話や PDA やノートパソコンなどの携帯デバイスから形成されます。 Wi-Fi などの他の有名な無線技術とは違い、 Bluetooth はより高いレベルのサービスを提供します。 たとえば、FTP のようなファイルサーバ、ファイルのプッシュ、 音声伝送、シリアル線のエミュレーションなどのサービスです。
FreeBSD 内での Bluetooth スタックは Netgraph フレームワーク (netgraph(4) 参照) を使って実現されています。 ng_ubt(4) ドライバは、 多種多様な Bluetooth USB ドングルに対応しています。 Broadcom BCM2033 チップを搭載した Bluetooth デバイスは ubtbcmfw(4) および ng_ubt(4) ドライバによって対応されています。 3Com Bluetooth PC カード 3CRWB60-A は ng_bt3c(4) ドライバによって対応されています。 シリアルおよび UART を搭載した Bluetooth デバイスは sio(4), ng_h4(4) および hcseriald(8) ドライバによって対応されています。 この節では USB Bluetooth ドングルの使用法について説明します。 Bluetooth に対応しているのは FreeBSD 5.0 以降のシステムです。
訳注: 5.0, 5.1 Release ではカーネルモジュールは利用可能ですが、 種々のユーティリティとマニュアルは標準でコンパイルされていません。
デフォルトでは Bluetooth デバイスドライバはカーネルモジュールとして利用できます。 デバイスを接続する前に、 カーネルにドライバを読み込む必要があります。
# kldload ng_ubt
Bluetooth デバイスがシステム起動時に存在している場合、 /boot/loader.conf からモジュールを読み込んでください。
ng_ubt_load="YES"
USB ドングルを挿してください。コンソールに (または syslog に) 下記のような表示が現れるでしょう。
ubt0: vendor 0x0a12 product 0x0001, rev 1.10/5.25, addr 2
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
/usr/share/examples/netgraph/bluetooth/rc.bluetooth を /etc/rc.bluetooth のようなどこか便利な場所にコピーしてください。 このスクリプトは Bluetooth スタックを開始および終了させるのに使われます。 デバイスを抜く前にスタックを終了するのはよい考えですが、 (たいていの場合) しなくても致命的ではありません。 スタックを開始するときに、下記のような出力がされます。
# /etc/rc.bluetooth start ubt0 BD_ADDR: 00:02:72:00:d4:1a Features: 0xff 0xff 0xf 00 00 00 00 00 <3-Slot> <5-Slot> <Encryption> <Slot offset> <Timing accuracy> <Switch> <Hold mode> <Sniff mode> <Park mode> <RSSI> <Channel quality> <SCO link> <HV2 packets> <HV3 packets> <u-law log> <A-law log> <CVSD> <Paging scheme> <Power control> <Transparent SCO data> Max. ACL packet size: 192 bytes Number of ACL packets: 8 Max. SCO packet size: 64 bytes Number of SCO packets: 8
ホストコントローラインタフェース (HCI) は、 ベースバンドコントローラおよびリンクマネージャへのコマンドインタフェースを提供し、 ハードウェアステータスおよびコントロールレジスタへアクセスします。 このインタフェースは Bluetooth ベースバンド機能へアクセスする画一的な方法を提供します。 ホストの HCI 層は Bluetooth ハードウェア上の HCI ファームウェアと、 データとコマンドをやり取りします。 ホストコントローラトランスポート層 (つまり物理的なバス) のドライバは、 両方の HCI 層に相互に情報を交換する能力を与えます。
一つの Bluetooth デバイスにつき、hci タイプの Netgraph ノードが一つ作成されます。 HCI ノードは通常 Bluetooth デバイスドライバノード (下流) と L2CAP ノード (上流) に接続されます。 すべての HCI 動作はデバイスドライバノード上ではなく、 HCI ノード上で行われなくてはいけません。 HCI ノードのデフォルト名は “devicehci” です。 詳細については ng_hci(4) マニュアルを参照してください。
最も一般的なタスクの一つに、無線通信的に近傍にある Bluetooth デバイスの発見があります。 この動作は inquiry (問い合わせ) と呼ばれています。 Inquiry や他の HCI に関連した動作は hccontrol(8) ユーティリティによってなされます。 下記の例は、どの Bluetooth デバイスが通信圏内にあるかを知る方法を示しています。 デバイスのリストが表示されるには数秒かかります。 リモートデバイスは discoverable (発見可能な) モードにある場合にのみ inquiry に返答するということに注意してください。
% hccontrol -n ubt0hci inquiry
Inquiry result, num_responses=1
Inquiry result #0
BD_ADDR: 00:80:37:29:19:a4
Page Scan Rep. Mode: 0x1
Page Scan Period Mode: 00
Page Scan Mode: 00
Class: 52:02:04
Clock offset: 0x78ef
Inquiry complete. Status: No error [00]
BD_ADDR は Bluetooth デバイスに固有のアドレスです。 これはネットワークカードの MAC アドレスに似ています。 このアドレスはデバイスとの通信を続けるのに必要となります。 BD_ADDR に人間が判読しやすい名前を割り当てることもできます。 /etc/bluetooth/hosts ファイルには、 既知の Bluetooth ホストに関する情報が含まれています。 次の例はリモートデバイスに割り当てられている、 人間が判読しやすい名前を得る方法を示しています。
% hccontrol -n ubt0hci remote_name_request 00:80:37:29:19:a4 BD_ADDR: 00:80:37:29:19:a4 Name: Pav's T39
リモートの Bluetooth デバイス上で inquiry を実行すると、 あなたのコンピュータは “your.host.name (ubt0)” と認識されます。 ローカルデバイスに割り当てられた名前はいつでも変更できます。
Bluetooth システムは一対一接続 (二つの Bluetooth ユニットだけが関係します) または一対多接続を提供します。 一対多接続では、接続はいくつかの Bluetooth デバイス間で共有されます。 次の例は、ローカルデバイスに対するアクティブなベースバンド接続のリストを得る方法を示しています。
% hccontrol -n ubt0hci read_connection_list Remote BD_ADDR Handle Type Mode Role Encrypt Pending Queue State 00:80:37:29:19:a4 41 ACL 0 MAST NONE 0 0 OPEN
connection handle はベースバンド接続の終了が必要とされるときに便利です。 もっとも、通常はこれを手動で行う必要はありません。 Bluetooth スタックはアクティブでないベースバンド接続を自動的に終了します。
# hccontrol -n ubt0hci disconnect 41 Connection handle: 41 Reason: Connection terminated by local host [0x16]
利用可能な HCI コマンドの完全な一覧を得るには、 hccontrol help を参照してください。 HCI コマンドのほとんどはスーパユーザ権限を必要としません。
ロジカルリンクコントロールおよびアダプテーションプロトコル (L2CAP) は、プロトコル多重化ケーパビリティおよび分割・再編成動作を備えた、 上位層プロトコルへのコネクション指向およびコネクションレスデータサービスを提供します。 L2CAP は上位層プロトコルおよびアプリケーションが 64 KB までの長さの L2CAP データパケットを送受信することを可能にします。
L2CAP は チャネル の概念に基づいています。 チャネルはベースバンド接続の上位に位置する論理的な接続です。 それぞれのチャネルは多対一の方法で一つのプロトコルに結びつけられます。 複数のチャネルを同じプロトコルに結びつけることは可能ですが、 一つのチャネルを複数のプロトコルに結びつけることはできません。 チャネル上で受け取られたそれぞれの L2CAP パケットは、 適切なより上位のプロトコルに渡されます。 複数のチャネルは同じベースバンド接続を共有できます。
一つの Bluetooth デバイスに対して、l2cap タイプの Netgraph ノードが一つ作成されます。 L2CAP ノードは通常 Bluetooth HCI ノード (下流) と Bluetooth ソケットノード (上流) に接続されます。 L2CAP ノードのデフォルト名は “devicel2cap” です。 詳細については ng_l2cap(4) マニュアルを参照してください。
便利なコマンドに、他のデバイスに ping を送ることができる l2ping(8) があります。Bluetooth 実装によっては、 送られたデータすべては返さないことがあります。 したがって次の例で 0 バイト は正常です。
# l2ping -a 00:80:37:29:19:a4 0 bytes from 0:80:37:29:19:a4 seq_no=0 time=48.633 ms result=0 0 bytes from 0:80:37:29:19:a4 seq_no=1 time=37.551 ms result=0 0 bytes from 0:80:37:29:19:a4 seq_no=2 time=28.324 ms result=0 0 bytes from 0:80:37:29:19:a4 seq_no=3 time=46.150 ms result=0
l2control(8) ユーティリティは L2CAP ノード上でさまざまな操作を行うのに使われます。 この例は、ローカルデバイスに対する論理的な接続 (チャネル) およびベースバンド接続の一覧を得る方法を示しています。
% l2control -a 00:02:72:00:d4:1a read_channel_list L2CAP channels: Remote BD_ADDR SCID/ DCID PSM IMTU/ OMTU State 00:07:e0:00:0b:ca 66/ 64 3 132/ 672 OPEN % l2control -a 00:02:72:00:d4:1a read_connection_list L2CAP connections: Remote BD_ADDR Handle Flags Pending State 00:07:e0:00:0b:ca 41 O 0 OPEN
別の診断ツールが btsockstat(1) です。 これは netstat(1) と同様の作業を、Bluetooth ネットワークに関するデータ構造についての行います。 下記の例は上の l2control(8) と同じ論理的な接続を示します。
% btsockstat Active L2CAP sockets PCB Recv-Q Send-Q Local address/PSM Foreign address CID State c2afe900 0 0 00:02:72:00:d4:1a/3 00:07:e0:00:0b:ca 66 OPEN Active RFCOMM sessions L2PCB PCB Flag MTU Out-Q DLCs State c2afe900 c2b53380 1 127 0 Yes OPEN Active RFCOMM sockets PCB Recv-Q Send-Q Local address Foreign address Chan DLCI State c2e8bc80 0 250 00:02:72:00:d4:1a 00:07:e0:00:0b:ca 3 6 OPEN
RFCOMM プロトコルは L2CAP プロトコルを介してシリアルポートのエミュレーションを提供します。 このプロトコルは ETSI (訳注: 欧州電気通信標準化機構) 標準 TS 07.10 に基づいています。 RFCOMM プロトコルは、単純な伝送プロトコルに RS-232 (EIATIA-232-E) シリアルポートの 9 本の結線をエミュレートする項目を加えたものです。 RFCOMM プロトコルは、二つの Bluetooth デバイス間で、最大 60 までの同時接続 (RFCOMM チャネル) に対応しています。
RFCOMM の目的から、完全な通信経路は、異なるデバイス上 (通信の端点) で動作している二つのアプリケーションと、 その間の通信セグメントを含んでいます。RFCOMM は、それが動いているデバイスのシリアルポートを利用するアプリケーションをカバーするためのものです。 通信セグメントはあるデバイスから他のデバイスへの Bluetooth リンクです (直接接続)。
RFCOMM は直接接続している場合のデバイス間の接続、 またはネットワークの場合のデバイスとモデムの間の接続にだけ関係があります。 RFCOMM は、一方が Bluetooth 無線技術で通信し、 もう一方で有線インタフェースを提供するモジュールのような、 他の構成にも対応できます。
FreeBSD では RFCOMM プロトコルは Bluetooth ソケット層に実装されています。
デフォルトでは Bluetooth 通信は認証されておらず、 すべてのデバイスが他のすべてのデバイスと通信できます。 Bluetooth デバイス (たとえば携帯電話) は特定のサービス (たとえばダイアルアップサービス) を提供するために、 認証を要求することも選択できます。 Bluetooth 認証は通常 PIN コード で行われます。 PIN コードは最長 16 文字のアスキー文字列です。 ユーザは両デバイスで同じ PIN コードを入力することを要求されます。 一度 PIN コードを入力すると、 両デバイスは リンクキー を作成します。 その後、リンクキーはそのデバイス自身または、 不揮発性記憶デバイス内に格納できます。 次の機会には、両デバイスは前に作成されたリンクキーを使用するでしょう。 このような手続きをペアリング (pairing) と呼びます。いずれかのデバイス上でリンクキーが失われたときには、 ペアリングをやり直さなければならないことに注意してください。
hcsecd(8) デーモンが Bluetooth 認証要求のすべてを扱う責任を負っています。 デフォルトの設定ファイルは /etc/bluetooth/hcsecd.conf です。 PIN コードが “1234” に設定された携帯電話に関する例は以下の通りです。
device {
bdaddr 00:80:37:29:19:a4;
name "Pav's T39";
key nokey;
pin "1234";
}
PIN コードには (長さを除いて) 制限はありません。 いくつかのデバイス (たとえば
Bluetooth ヘッドフォン) には固定的な PIN コードが組み込まれているかもしれません。
-d オプションは hcsecd(8)
デーモンがフォアグラウンドで動作するように強制するため、
何が起きているのか確認しやすくなります。
リモートデバイスがペアリングを受け取るように設定して、 リモートデバイスへの
Bluetooth 接続を開始してください。
リモートデバイスはペアリングが受け入れらた、と応答して PIN
コードを要求するでしょう。 hcsecd.conf 内にあるのと同じ
PIN コードを入力してください。 これであなたの PC
とリモートデバイスがペアとなりました。
また、リモートデバイスからペアリングを開始することもできます。 以下は hcsecd の出力例です。
hcsecd[16484]: Got Link_Key_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4 hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', link key doesn't exist hcsecd[16484]: Sending Link_Key_Negative_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4 hcsecd[16484]: Got PIN_Code_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4 hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', PIN code exists hcsecd[16484]: Sending PIN_Code_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4
サービスディスカバリプロトコル (SDP) は、 クライアントアプリケーションが、 サーバアプリケーションが提供するサービスの存在とその属性を発見する手段を提供します。 サービスの属性には提示されているサービスのタイプまたはクラス、 および、サービスを利用するのに必要な仕組みまたはプロトコルの情報が含まれます。
SDP には SDP サーバと SDP クライアント間の通信が含まれます。 SDP サーバは、サーバに関連づけられたサービスの特性について記述しているサービスレコードの一覧を維持しています。 各サービスレコードにはそれぞれ 1 つのサービスの情報が書かれています。 クライアントは SDP リクエストを出すことによって、 SDP サーバが維持しているサービスレコードから情報を検索できます。 クライアントまたはクライアントに関連づけられたアプリケーションがサービスを利用することにしたら、 サービスを利用するためには、 サービスプロバイダへの接続を別途開かなければなりません。 SDP はサービスとそれらの属性を発見するための仕組みを提供しますが、 そのサービスを利用するための仕組みは提供しません。
通常 SDP クライアントは希望するサービスの特性に基づいてサービスを検索します。 しかしながら、サービスに関する事前の情報なしに、 どのタイプのサービスが SDP サーバのサービスレコードに記述されているか知ることが望ましいことがあります。 この、提供されている任意のサービスを閲覧する手順を、 ブラウジング (browsing) と呼びます。
現在のところ Bluetooth SDP サーバおよびクライアントは、 ここ からダウンロードできる第三者パッケージ sdp-1.5 で実装されています。 sdptool はコマンドラインの SDP クライアントです。 次の例は SDP ブラウズの問い合わせ方法を示しています。
# sdptool browse 00:80:37:29:19:a4 Browsing 00:80:37:29:19:A4 ... Service Name: Dial-up Networking Protocol Descriptor List: "L2CAP" (0x0100) "RFCOMM" (0x0003) Channel: 1 Service Name: Fax Protocol Descriptor List: "L2CAP" (0x0100) "RFCOMM" (0x0003) Channel: 2 Service Name: Voice gateway Service Class ID List: "Headset Audio Gateway" (0x1112) "Generic Audio" (0x1203) Protocol Descriptor List: "L2CAP" (0x0100) "RFCOMM" (0x0003) Channel: 3
... 等々。 それぞれのサービスは属性の一覧 (たとえば RFCOMM チャネル) を持っていることに注意してください。サービスによっては、 属性のリストの一部についてメモをとっておく必要があるかもしれません。 Bluetooth 実装のいくつかは、サービスブラウジングに対応しておらず、 空の一覧を返してくるかもしれません。この場合、 特定のサービスを検索をすることは可能です。下記の例は OBEX オブジェクトプッシュ (OPUSH) サービスを検索する方法です。
# sdptool search --bdaddr 00:07:e0:00:0b:ca OPUSH
FreeBSD 上における Bluetooth クライアントへのサービス提供は sdpd サーバが行います。
# sdpd
sdptool は、ローカル SDP サーバにサービスを登録するのにも用いられます。 下記の例は PPP (LAN) サービスを備えたネットワークアクセスを登録する方法を示しています。 一部のサービスでは属性 (たとえば RFCOMM チャネル) を要求することに注意してください。
# sdptool add --channel=7 LAN
ローカル SDP サーバに登録されたサービスの一覧は SDP ブラウザの問い合わせを “特別な” BD_ADDR に送ることで得られます。
# sdptool browse ff:ff:ff:00:00:00
ダイアルアップネットワーク (DUN) プロファイルはほとんどの場合、 モデムや携帯電話とともに使用されます。 このプロファイルが対象とする場面は以下のものです。
コンピュータから携帯電話またはモデムを、 ダイアルアップインターネットアクセスサーバへの接続、 または他のダイアルアップサービスを利用するための無線モデムとして使うこと
データ呼び出しを受けるための、 コンピュータによる携帯電話またはモデムの使用
PPP (LAN) によるネットワークアクセスプロファイルは、 次の状況で利用できます。
単一の Bluetooth デバイスへの LAN アクセス
マルチ Bluetooth デバイスへの LAN アクセス
(シリアルケーブルエミュレーション上の PPP ネットワーク接続を使用した) PC から PC への接続
FreeBSD ではどちらのプロファイルも ppp(8) と rfcomm_pppd(8) (RFCOMM Bluetooth 接続を PPP が制御可能なように変換するラッパ) で実装されています。 いずれかのプロファイルが使用可能となる前に、 /etc/ppp/ppp.conf 内に新しい PPP ラベルが作成されていなければなりません。 例については、 rfcomm_pppd(8) のマニュアルページを参照してください。
次の例では、DUN RFCOMM チャネル上で BD_ADDR が 00:80:37:29:19:a4 のリモートデバイスへの RFCOMM 接続を開くのに rfcomm_pppd(8) が使われます。実際の RFCOMM チャネル番号は SDP を介してリモートデバイスから得ます。 手動で RFCOMM チャネルを指定することもでき、その場合 rfcomm_pppd(8) は SDP 問い合わせを実行しません。 リモートデバイス上の RFCOMM チャネルを見つけるには、 sdptool を使ってください。
# rfcomm_pppd -a 00:80:37:29:19:a4 -c -C dun -l rfcomm-dialup
PPP (LAN) サービスでネットワークアクセスを提供するためには、 sdpd サーバが動いていなければなりません。 これはローカル SDP サーバに LAN サービスを登録するのにも必要です。 LAN サービスは RFCOMM チャネル属性を必要とすることに注意してください。 /etc/ppp/ppp.conf ファイル内に LAN クライアントの新しいエントリを作成しなければなりません。 例については rfcomm_pppd(8) のマニュアルページを参照してください。 最後に、RFCOMM PPP サーバが実行され、 ローカル SDP サーバに登録されているのと同じ RFCOMM チャネルで待ち受けていなければなりません。 次の例は RFCOMM PPP サーバを起動する方法を示しています。
# rfcomm_pppd -s -C 7 -l rfcomm-server
OBEX はモバイルデバイス間で広く使われている単純なファイル転送プロトコルです。 これは主に赤外線通信で利用されており、ノートパソコンや PDA 間の汎用的なファイル転送、および PIM アプリケーションを搭載した携帯電話その他のデバイス間で名刺やカレンダーエントリを転送するのに用いられます。
OBEX サーバおよびクライアントは、 ここ からダウンロードできる obexapp-1.0 という第三者のパッケージとして実装されています。 このパッケージは openobex ライブラリ (上記の obexapp に含まれます) および devel/glib12 port を必要とします。 なお、obexapp はルート権限を必要としません。
OBEX クライアントは OBEX サーバとの間でオブジェクトを渡したり (プッシュ) および受け取ったり (プル) するのに使用されます。 オブジェクトは、たとえば名刺や予定などになります。 OBEX クライアントは RFCOMM チャネル番号を SDP によってリモートデバイスから得ることができます。 これは RFCOMM チャネル番号の代わりにサービス名を指定することによって行うことができます。 対応しているサービス名は IrMC, FTRN および OPUSH です。 RFCOMM チャネルを番号で指定することもできます。 下記は、デバイス情報オブジェクトを携帯電話から受け取り、 新しいオブジェクト (名刺) が携帯電話に渡される場合の OBEX セッションの例です。
% obexapp -a 00:80:37:29:19:a4 -C IrMC obex> get get: remote file> telecom/devinfo.txt get: local file> devinfo-t39.txt Success, response: OK, Success (0x20) obex> put put: local file> new.vcf put: remote file> new.vcf Success, response: OK, Success (0x20) obex> di Success, response: OK, Success (0x20)
OBEX プッシュサービスを提供するためには、 sdpd サーバが実行されていなければなりません。 また OPUSH サービスをローカル SDP サーバに登録することも必要です。 なお、OPUSH サービスには RFCOMM チャネル属性が必要です。 渡されるオブジェクトをすべて格納するルートフォルダを作成しなければいけません。 ルートフォルダのデフォルトパスは /var/spool/obex です。 最後に OBEX サーバが実行され、 ローカル SDP サーバに登録されているのと同じ RFCOMM チャネルで待ち受けていなければなりません。 下記の例は OBEX サーバの起動方法を示します。
# obexapp -s -C 10
シリアルポート (SP) プロファイルは Bluetooth デバイスが RS232 (または同様の) シリアルケーブルエミュレーションを行えるようにします。 このプロファイルが対象とする場面は、 レガシーアプリケーションが、仮想シリアルポート抽象を介して Bluetooth をケーブルの代替品として使うところです。
rfcomm_sppd(1) ユーティリティはシリアルポートプロファイルを実装します。 Pseudo tty が仮想シリアルポート抽象概念として用いられます。 下記の例はリモートデバイスのシリアルポートサービスへ接続する方法を示します。 なお、RFCOMM チャネルを指定する必要はありません。— rfcomm_sppd(1) は SDP を介してリモートデバイスからその情報を得ることができます。 これを上書きしたい場合にはコマンドラインで RFCOMM チャネルを指定してください。
# rfcomm_sppd -a 00:07:E0:00:0B:CA -t /dev/ttyp6 rfcomm_sppd[94692]: Starting on /dev/ttyp6...
接続された pseudo tty はシリアルポートとして利用することができます。
# cu -l ttyp6
古い Bluetooth デバイスのなかにはロールスイッチング (role switching) に対応していないものがあります。 デフォルトでは FreeBSD が新しい接続を受け付けるときに、 ロールスイッチを実行してマスタになろうとします。 これに対応していないデバイスは接続できないでしょう。 なお、ロールスイッチングは新しい接続が確立されるときに実行されるので、 ロールスイッチングに対応しているかどうかリモートデバイスに問い合わせることはできません。 ローカル側でロールスイッチングを無効にする HCI オプションがあります。
# hccontrol -n ubt0hci write_node_role_switch 0
できます。 ここ からダウンロードできる第三者パッケージ hcidump-1.5 を使ってください。 hcidump ユーティリティは tcpdump(1) と似ています。 これはターミナル上の Bluetooth パケットの内容の表示および Bluetooth パケットをファイルにダンプするのに使えます。
本文書、および他の文書は ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/ からダウンロードできます。
FreeBSD に関する質問がある場合には、ドキュメント を読んだ上で <questions@FreeBSD.org> まで (英語で)
連絡してください。
本文書に関する質問については、<doc@FreeBSD.org> まで電子メールを (英語で)
送ってください。