論文吉田坂本

Transcription

1 学士論文 Android 端末間の アドホックネットワークの構築 大阪工業大学情報科学部情報ネットワーク学科 N 坂本浩基 N 吉田和矢

2 目次 第 1 章緒言 研究の背景 研究の目的 1 第 2 章研究の概要 アドホックネットワーク Android に搭載されている端末通信方式 2 第 3 章開発環境について Android の歴史及び基本知識 開発用パーソナル コンピューター 動作確認用 Android 端末 Android のカスタム OS Cyanogenmod について 10 第 4 章方式のアドホックネットワークの実装準備 Bootloader について root 権限について adb コマンドの解説とデバイスの接続手順 Bootloader のアンロック カスタムリカバリの導入 root 権限の取得 Cyanogenmod のカーネル構築とインストール 24 第 5 章 Cyanogenmod によるアドホックモード接続実験 Cyanogenmod の WiFi 設定画面 ビーコンフレームの調査 34 第 6 章方式のまとめ 36 第 7 章 Android に相乗りする形での Linux の動作 Android 端末でのアドホックネットワーク構築の際の課題 Debian-kit について Debian-kit を利用するための条件 Debian-kit での Debian 環境の構築 wireless-tools のインストール ルーティングソフトの動作 49 第 8 章アドホックネットワーク構築と Android での利用 50 第 9 章方式のまとめ 52 第 10 章まとめ 53 謝辞 参考文献

3 第 1 章緒言 1.1 研究の背景 近年の PC やスマートフォンなどの情報機器の普及により各種情報を入手しやすい時代になった 特にスマートフォンは普及率が世界的に著しく伸びている 総務省の平成 25 年度版情報通信白書によると 世界的にスマートフォンの普及が本格化したのが 2009 年から 2011 年である 日本では 2011 年から 2013 年での普及率の推移は 40% ほど上昇している また PC の保有率の推移が減少していることから 今後の情報機器のニーズはスマートフォンが握ることになるということがわかる スマートフォンは通信キャリアの提供する無線ネットワークを利用して通信している しかし 自然災害などにより情報を提供する通信キャリアのネットワークが使えなくなると 情報が入手することができなくなる また 災害現場だけではなく 回線の混雑しているイベント会場等でも 特定の端末間の通信を安定して行うことができるなど他のことにも応用を行うこともできる そこで通信キャリアに頼らず無線ネットワークを構築することのできるアドホックネットワークをスマートフォンで利用することを考えた 1.2 研究の目的 上記を踏まえて本研究の目的は代表的なスマートフォンである Android をアドホックネットワークが利用可能な状態にするための機能の実装と検討である 自然災害時や PC などの大型の通信機器が使用しづらい状況の中で即座にネットワークの構築が可能になる. 今回 AndroidOS を用いたアドホックネットワークを構築する理由は, もう一つの主流なスマートフォン OS である Apple 社の iphone にはすでにアドホックネットワークを利用することができる機能が備わっているからである. つまり,Android 上でアドホックネットワークが利用できるようになれば, スマートフォンでのアドホックネットワークの利用に大きく貢献できると思い, 今回 Android でのアドホックネットワークの実装の検討を行った. 今回行った方式は以下の2 点となる 方式 1 Android のカスタム OS にアドホックモード接続可能なパッチを用い てカーネル構築をする 方式 2 Android に相乗りさせる形で Linux を動作させる 1

4 第 2 章研究の概要 2.1 アドホックネットワークとはまず 今回の研究の元となるアドホックネットワークについて説明を行う アドホックネットワークとは無線 LANのようなアクセスポイントや通信キャリアの提供するネットワークを必要としない 無線で接続することのできる端末で構成されたネットワーク Ad-Hoc とはラテン語で 特定の目的のための や 限定目的の などといった意味のラテン語の語句である アドホックネットワークでは IEEE802.11x や Bluetooth などの技術を用いながら点在するアクセスポイントの介在なしに相互に接続する形態 ( マルチポップ ) を取っている このため アドホックネットワークでは通信キャリアの用意したネットワークやアクセスポイントが不要となり 簡易なネットワークの構築が可能となる 図 2.1 アクセスポイントを利用した通信の仕組み 2

5 図 2.2 アドホックネットワークを用いた通信のイメージ また このアドホックネットワークには 2 つの技術が用いられている 一つ目はアドホックモードで アクセスポイントを介さずに端末同士が直接通信するモードのことである そしてもう一つはマルチホップである これは端末同士がほかの端末を経由することでより広範囲の端末との通信を可能にする技術である 図 2.4 では両端の端末は直接通信してないが 上の端末を経由することで通信を可能にしている 図 2.3 アドホックモードの様子 3

6 図 2.4 マルチホップ通信の様子 2.2 Android に搭載されている端末通信方式 バージョン 4.0 以降の Android では WiFiDirect と呼ばれる端末通信方式が実装されている WiFiDirect とは WiFiAlliance という業界団体が決めた無線 LAN 規格のことである WiFiDirect ではソフトウェアアクセスポイント ( ソフトウェア AP) によって端末にアクセスポイントの機能を持たせ 直接接続を行う アドホックネットワークとの違いは無線 LAN アクセスポイントの機能をソフトウェア的に実現し 他の端末や機器はこの WiFiDirect を使用している端末としか通信することはできず アドホックネットワークのマルチホップのように 大きなネットワークを構築することはできない 4

7 図 2.5 WiFiDirect とアドホックモードの違い 2.3 Android でアドホックネットワークを実装する際の問題点 図 2.5 では周囲にアドホックネットワークが存在する上で Android の WiFi 設定画面を表示させたがアドホックネットワークは表示されなかった また 自らアドホックネットワークを作成することもできない 図 2.6 Android の WiFi 設定画面 5

8 これはグーグルが意図的にアドホックモードへの変更に対応させていないからである 図 2.7 のように無線 LAN 制御に使用している wpa_supplicant 内にあるプログラムで アドホックネットワークの接続先を表示させないようにしている Google はアドホックネットワーク未対応の理由について 特に発表はしていない Android4.0.1 内部にある External/wpa_supplicant_8/wpa_supplicant/events.c を見てみると if 文によってアドホックモード (IBSS モード ) であるかどうかを判断し アドホックモードであればデバック情報を出力して以下の処理をスキップしている 図 2.7 wpa_supplicant/events.c 内部の一部 (Android4.0.1) 第 3 章開発環境について 3.1 Android の歴史及び基本知識 Android とは Google 社が中心となって開発しているオープンソフトライセンスのスマートフォン用 OS である 元々 2003 年に設立された Android 社がデジタルカメラ向けの OS として設計したのが Android だった しかし開発者のアンディ ルービン氏はデジタルカメラの OS では大きな市場は見込めないとしてターゲットをスマートフォンに変更した そして 2005 年に Google 社が Android 社を買収し,2007 年 11 月に発表された それまでのスマートフォンのシェアは Apple 社の iphone が多くを占めていが Android の登場によって市場が2つに分かれることになる Android と iphone との最大の違いは OS のオープンソフトライセンス化である. これにより各社で同じ AndroidOS を導入しても各社独自の AndroidOS が導入されることになった Android の大きなメリットは無償であることと オープンソースであることだ 端末メーカーは Android を搭載したスマートフォンを作るためのライセンス料がかからないため 制作コストを抑える事ができる また 開発者には OS に関するコードが公開されているため カスタマイズがしやすくなる また Google が中心になっているため Gmail 6

9 Google カレンダー YouTube など Google が提供するサービスと連携しているのも特徴である Android は Linux カーネルを採用している.Linux カーネルは メモリやプロセスの管理 ファイルシステム セキュリティといった基本機能を加え各種ドライバーを提供している. 結果 Android は Linux カーネルの上にミドルウェアが搭載されている. しかし そのうえで動作するミドルウェアとの結合は弱く 比較的ユーザーによる変更自由度は高い. たとえば Xperia のカスタム ROM では純正カーネルではなくソニーエリクソン製のものが使われ その上で Android が動作している. アプリケーション アプリケーション フレームワーク ライブラリ アンドロイド ランタイム HAL(Hardware Abstraction Layer) Linux カーネル ハードウェア 図 3.1 Android のレイヤー構成 図 3.1 で示した通り Android はハードウェア上に主に主に5つのスタックで構成される. 一番下は Linux カーネルであり 前述した通り PC などで使われる Linux カーネルを Android 用にカスタマイズしたものである 次に HAL(Hardware Abstraction Layer) で ハードウェア抽象レイヤーと呼ばれる 主に HAL の内部では Linux カーネルにあるデバイスドライバー ( デバイスを制御するプログラム ) にアクセスしてデータを取得している これにより Android のハードウェアごとの差異を HAL 以下のレイヤーに抑えることができ HAL より上位のレイヤーでは ハードに依存しないコードになる HAL の上部にあるのがライブラリとアンドロイド ランタイムである ライブラリには様々なミドルウェアが格納されている 組み込み機器向けに開発されている OpenGL ES や データベースライブラリにある SQLite などがある 一方アンドロイド ランタイムは Android のアプリケーションを動作させるた 7

10 めの実行環境である この中には基本的な Java ライブラリが含まれているコアライブラリと Dalvik VM(Dalvik 仮想マシン ) という独特の仮想マシンを搭載している Dalvik VM はスマートフォンのようにメモリ容量の少ない環境でも高速に動作するように設定されていて Android のアプリは CPU の違いを意識せずにアプリケーションを動作させることができる ライブラリとアンドロイド ランタイムの上にあるのがアプリケーション フレームワークである これは 端末上に表示されるボタンやテキストボックスなどの Android アプリケーションを動作させるのに必要なライブラリが含まれている 先ほどのライブラリなどを Java から操作するためのラッパーライブラリなども含まれている 一番上にあるのがアプリケーションである ここで Android の様々なアプリケーションが動作している AndroidNDK を利用して作成した Android アプリケーションも含めて すべてのアプリケーションは すべてこのレイヤーで動作する Android は 2007 年 11 月 5 日のリリース以来 多くのバージョンアップが行われてきている. また バージョン 1.5 以降はコードネームがつくようになる. なお タブレット向けの Android はバージョン 3.0~3.2 が存在している. そのため 携帯電話用 Android はバージョン 2.3 からバージョン 4.0 へいきなりバージョンアップされている インターフェースの変更や大きなバージョンアップが多く ツールの画面構成や使用方法が若干異なったり機能が失われていたりするので注意が必要になる. また Android のバージョンアップで改善される API レベルとは Android のフォームバージョンで提供されるフレームワーク API リビジョンを識別する数値である. 現行の主流な AndroidOS のバージョンは Android4.4kitkat であり 昨年 10 月に Google から最新バージョンの Android5.0 が発表された 以下はこれまでの Android のバージョン及び API レベル コードネームをまとめたものである 8

11 バージョン APIレベル コードネーム 1 1 Base( ベース ) Base Cupcake( カップケーキ ) Donut( ドーナッツ ) 2 5 Eclair( エクレア ) Eclair M RI Froyo( フロヨ ) Gingerbread( ジンジャーブレッド ) 3 11 H oneycom b( ハニカム ) Honeycomb MR Honeycomb MR Ice C ream Sandw ich( アイスクリームサンドイッチ ) Je ly B ean( ジェリービーン ) Je ly B ean M R Je ly B ean M R KitKat( キットカット ) 5 21 Lo lipop( ロリポップ ) 表 3.1Android のバージョン一覧 3.2 開発用パーソナル コンピューター 前述した方式 1では パーソナル コンピューターでカーネルの構築を行う ソースファイルをダウンロード ビルドする際又はカーネル構築を行う時に Linux 系の OS で使用されるコマンドを使用する なので 今回使用する PC は Linux 系の OS である Ubuntu バージョン を導入したものを使用した 3.3 動作確認用 Android 端末 今回は ASUS 社の Nexus flo を採用した 採用理由は2つあり一つ目は以前の卒業生の先輩方の研究で使用していた TOSHIBA 社の REGZA TabletAT570 を使用していた このタブレットは残念ながらルート権限を取得しても Android のカーネルを操作することができないため 本研究には不向きだということが判明した もう一つの理由はこの Nexus7 が後述するカスタム OS である Cyanogenmod に対応しており このカスタム OS に対応したアドホックネットワークを利用可能にするパッチを配布しているサイトを見つけたので採用した また Nexus7 には製造された各年度によってバージョンが異なる 現状では 2012 年度バージョン (grouper) と 2013 年度バージョン (flo) である Cyanogenmod を用いたカスタム OS 導入の方法でアドホックネットワークを構築する際には同年度の Nexus7 で使用しないとカーネル構造の違いからインス 9

12 トールを行うことができないので注意しなくてはならない 3.4 Android の拡張 OS Cyanogenmod について 図 3.2 Cyanogenmod11 kitkat のメニュー画面 Cyanogenmod とは Cyanogenmod 社が提供している AndroidOS をカスタマイズしたオープンソースのスマートフォン及びタブレット向けのオペレーティングシステムである Cyanogenmod の開発者たちは Open Android Alliance を構成している 完全にカスタマイズでき かつ Google やほかの権利に頼らない Android の雰囲気 への貢献をゴールとする組織である オープンソースのオペレーティングシステムを使用する一つの主な利点は多くの人が欠けている機能を自由に追加することができ セキュリティホールなどのバグや欠陥をいち早く見つけることができる点である Cyanogenmod でサポートされる機能は FLAC ロスレス音楽形式 システムレベルのテーマ変更 OpenVPN 電源メニューからのリブートおよびスクリーンショット Bluetooth でのデザリング 通知バー上のトグル機能 DSP コライザーといった公式ファームウェアにはない拡張機能をサポートしている 第 4 章方式のアドホックネットワークの実装準備 10

13 4.1 Bootloader について Bootloader とは Android の端末でシステムを立ち上げるときに使われるプログラムの名称である PC の BIOS に相当する部分で この Bootloader がフラッシュメモリ上に作られたシステムイメージを読み込んで Linux カーネルを起動する 通常時この Bootloader は 起動時のメーカーロゴなどを表示している間に動き Linux カーネルを読み込んで起動する カーネルはその後 Android の環境を立ち上げていく このため 一般的には Bootloader の画面を見ることは出来ないが 特別な方法を用いることで Bootloader をカーネルの読み込み前に止め 内蔵しているユーザーインターフェースを表示することができる ここで外部からフラッシュメモリに入れたカスタムリカバリを導入することでカスタム OS が利用できるが メーカー初期搭載の Bootloader は正しく電子著名された OS ファイルしか読み込まない様になっている このような状態のことを Bootloader が ロック されているという しかし メーカーの中にはこのロックを解除できる使用にしている端末を提供している事もある このロックを解除するという一連の操作を Bootloader アンロック という 今回使用する Nexus7 はその一例であり Google が販売する Nexus 系のデバイスでは 出荷時には Bootloader がロックされた状態であるが ユーザーが任意でアンロックすることができる 4.2 root 権限について今回 Android にカスタム OS を導入するにあたって Android の root 権限の取得を行った Android の root 化とはユーザーが Android サブシステム内で特定の管理権限のある領域にアクセスする特権を取得する方法である Android は組み込み系 Linux に分類されており Linux 系 OS のコンピューターの管理者権限の取得に類似している root 権限の取得によって全ファイルシステムにアクセスが可能になり ブートローダーから OS のインストール等が可能になる root 権限の取得方法はデバイスによって異なる メーカーの対応は消極的で root 権限を取得するとデバイスの保障が無効になるケースがある しかし カスタム OS の普及やユーザーによる root 権限の取得が盛んになったことで 米国議会図書館の jailbreak モバイルデバイスの認定宣言が行われた その後 メーカーやキャリアもユーザーが独自に作成したファームウェアや OS の配布に対する姿勢にも変化が起き HTC Samsung Motorola Sony Mobile Communications などの企業が開発を支援している 特に Cyanogenmod は代表的なカスタム OS であり さまざまな企業が販売するデバイスに対応した OS を配布している また root 権限の取得にはデバイスのブートローダーのロックを解除する ( ア 11

14 ンロック ) しなくてはならないが 近年アンロック可能な機種が増え既にアンロ ックされたデバイスも増えつつある 4.3 adb コマンドの解説とデバイスの接続手順 adb コマンドとは Android debug bridge の略である adb コマンドは PC を使用して Android を開発する場合に Android 側との通信を受け持ち さまざまな機能を提供する 実際には Android 側で動作している adbd(adb deamon) と通信を行い 実際の処理は adbd 側で行い その実行メッセージなどを adb へ返して adb がコマンドプロントウィンドウ内でメッセージを表示する adb などの記述だと adb.exe を実行している PC を ローカル USB ケーブルなどに接続されている Android 側を リモート と呼ぶ また PC 上で起動しているエミュレーターにも接続することができる adb コマンドを利用するにはまず PC 側に AndroidSDK をインストールする必要がある AndroidSDK は Android 公式サイトからダウンロードすることが可能である インストール先のディレクトリは自分が分かりやすい所にしておくのが無難である ADB コマンドを使用するために PC に ADB 用デバイスドライバーをインストールする必要がある 今回は AndroidSDK 内にある Google USB Driver を使用する AndroidSDK 内の SDK マネージャーを起動し Extra 内にある Google USB Driver にチェックを入れてインストールを行う 次に Android 側の準備として USB で PC と Android を接続し デバイスドライバーを PC にインストールする そうすることで デバイスとして PC が認識する また 初回の接続では Android 側が PC との USB 接続を行うかどうかの確認画面を表示するのでチェックボックスにチェックを入れる必要がある 続いて 再び AndroidSDK を用いて今度は platform-tools をインストールする platform-tools は AndroidSDK をインストールしたフォルダの下に作られるので PC 側の端末画面で platform-tools に移動し platform-tools>adb devices と入力する 端末の識別番号のあとに device と表示されていれば接続が完了している証拠になる これ以降も adb コマンドは使用することが多いので platform-tools までの Path の設定を行う必要がある Path の設定に関しては省略する List of devices attached の後に何も表示されないのであれば 認識に失敗しているためこれまでの手順を見直す必要がある Windows で接続したデバイスが認識されない場合は おそらく端末を PC に認識する段階で不具合が発生している場合が多い 対処方法はまず 端末の Vendor ID(VID) と Product ID(PID) を調べる必要がある これによって PC は USB 接続されている端末とドライバーの結びつきを管理している 端末を USB 12

15 ケーブルで接続し ドライバーが正常にインストールできなかったというメッセージが表示されるが無視し デバイスマネージャーを開く 自分の端末が ほかのデバイス として認識されている この行を左ダブルクリックしプロパティを表示する プロパティのプルダウンメニューから ハードウェア ID を選択する すると端末の VID と PID が表示されているのでそれらをメモしておく 次にインストールした USB ドライバー内にある inf ファイル ( システム定義ファイル ) を編集する USB ドライバーは AndroidSDK をインストールしたフォルダの中の extras google usb_driver の中にある android_winusb.inf をテキストエディターで開く inf ファイルでは [] で囲まれた名前をセクション名と呼び 次のセクション名までの区間をセクションと呼ぶ Google.NTx86 セクションは 32bit 環境向け Ntamd64 セクションは 64bit 環境向けの記述となる PC の OS が 32bit であれば 32bit 環境向けの記述欄を編集すればいい 内容を見ていくと今回実験で使用した端末の ;Google Nexus 7 の項目が見える ここに先ほどメモを行った VID と PID を以下のように追加する 編集が終了したら保存しドライバーのインストールを行う デバイスマネージャーから 全般 の画面で ドライバーの更新 を選択する そして編集した android_winusb.inf の場所を指定する inf ファイルの編集が正しければドライバーのインストールが完了する adb の主要コマンドは以下のとおりである 13

16 表 4.1 adb の主要なコマンド 4.4 Bootloder のアンロック Bootloader root adb コマンドの理解を踏まえた上で Nexus7 にカスタム OS を導入するまでを解説する 始めに Nexus7 を USB ケーブルで PC に接続し PC に予めダウンロードした AndroidSDK の platform-tools フォルダ内でコマンドウィンドウを開く PC のコマンド入力画面で adb reboot bootloader と入力すると 端末が再起動してブートローダー (Fastboot モード ) が起動する 下の図のようにドロイド君が倒れている画面が表示されていれば成功である 14

17 図 4.2 起動したブートローダー画面 PC のコマンド入力画面に戻って fastboot oem unlock と入力すると 端末 がブートローダーをアンロックするか訪ねてくるので ボリュームボタンで Yes を選択し 電源ボタンを押して決定する 15

18 図 4.3 ブートローダーのアンロック確認画面 PC のコマンド入力画面で Unlocking bootloader done! と表示されれば ブートローダーのアンロックが完了する 図 4.4 ブートローダーのアンロック完了画面 16

19 4.5 カスタムリカバリの導入 続いて Nexus7 にカスタムリカバリ TWRP を導入する TWRP を導入することで Nexus7 の現在の状態をまるごとバックアップ及び復元を行うことができるようになり カスタム ROM を導入できるようになる まず初めに 先ほどの手順と同様に adb コマンドで adb reboot bootloader と入力しブートローダーを起動する 続に TWRP を次の URL からダウンロードする ( の端末上で /platform-tools に移動し fastboot flash recovery と入力して img ファイルをダウンロードした場所を追加する 以下のように表示されれば TWRP の導入は完了する 図 4.5 TWRP の導入画面 最後に TWRP が起動するかを確認する ブートローダー起動状態でボリュー ムボタンを押し Recovery mode にして電源ボタンで決定する そして以下 の様なカスタムリカバリの画面が起動すれば TWRP の導入は成功している 17

20 図 4.6 カスタムリカバリの起動画面 4.6 root 権限の取得 Root 権限を取得するために SuperSU という実行ファイルが必要になる SuperSU とはインストールしたすべてのアプリのすべての権限を管理するものでこのアプリケーションで管理者権限を取得して他のアプリケーションが管理者権限を必要とした際に手助けを行う SuperSU の zip ファイルは次の URL からダウンロードすることができる ( ダウンロードした zip ファイルを Nexus7 の内部ストレージに保存する TWRP の Install タブから zip ファイルを選び インストールする Successful と表示されたら Reboot System をタップし 再起動する 18

21 図 4.7 SuperSU インストール画面 再起動後 adb コマンドで root にログイン出来るかを確認した 図 4.8 root ログイン画面 4.7 Cyanogenmod の修正パッチの編集 今回 Cyanogenmod に提供されていたパッチは ThinkTube の Cyanogenmod による AndroidAdhoc のページからダウンロードしたものを使用している し かし 今回提供されていた Nexus7 用の修正パッチは Nexus 年度バージ 19

22 ョン (grouper) 用であり Nexus 年度バージョン (flo) 用は存在しなかった その為 ダウンロードしたパッチファイルを Nexus7 flo 用に修正する必要があった 以下が Nexus7 flo 用に修正した修正パッチである 今回修正パッチを当てた Cyanogenmod のファイルは root ディレクトリ以下 external freamworks drivers packages の4つである 今回の修正において重要な wpa_supplicant がある external についてのみ解説する また 今回の修正パッチの名前は IBSS-all-in-one.diff だが diff ファイルについても簡単に解説する diff ファイルとは ファイルの差分を作成するコマンドで patch は差分からファイルの変更を再現するコマンドである Linux の場合さまざまなサーバアプリケーションや ソフトウェアがソースで提供されているため 自分の環境にあった仕組みに改造したり ユーザーの手によって使いやすく改良したり 提供元が修正する前にユーザーの手によってバグや問題を解決することができた しかし 毎回何処を修正したと報告してもプログラムソースを読むことができない人にはそれを反映するのは難しい そこで diff と patch が使われてきたのである オリジナルのソースファイルから diff を使用して差分ファイルを作っておけば その差分ファイルを作っておけば そのオリジナルソースに patch コマンドを実行するだけで 修正した箇所を再現することができる 20

23 1 diff --git a/src/drivers/driver.h b/src/drivers/driver.h 2 index e9f926f.fc1b06f =--- a/external/w pa_supplicant_8/src/drivers/driver.h 4 =+++ b/external/w pa_supplicant_8/src/drivers/driver.h -834,6 struct wpa_driver_capa { 6 #define W PA_D RIVER _0x /* D river expects user space im plem entation of M LM E in A P m ode */ 8 #define W PA_D RIVER _FLAG S _AP_0x /* D river supports IB SS (Ad-hoc) m ode */ 10 +#define W PA_D RIVER_FLAG S_IB SS 0x unsigned int flags; in t m ax_sc an _ssids; 15 diff --git a/src/drivers/driver_nl80211.c b/src/drivers/driver_nl80211.c 16 index b085e3b.760e55b =--- a/external/w pa_supplicant_8/src/drivers/driver_nl80211.c 18 =+++ b/external/w pa_supplicant_8/src/drivers/driver_nl80211.c -2470,6 static int wiphy_info_handler(struct nl_msg *msg,void *arg) 20 case N L80211_IFTYPE_AP: 21 capa->flags = W PA_D RIVER_FLAG S_AP; 22 break; 23 + case N L80211_IFTYPE_AD H O C : 24 + capa->flags = W PA_D RIVER_FLAG S_IB SS; 25 + break; 26 case N L80211_IFTYPE_P2P_G O : 27 p2p_go_supported = 1; 28 break; 29 diff --git a/w pa_supplicant/config_file.c b/w pa_supplicant/config_file.c 30 index a.e4c787a =--- a/external/w pa_supplicant_8/w pa_supplicant/config_file.c 32 =+++ b/external/w pa_supplicant_8/w pa_supplicant/config_file.c -676,6 static void wpa_config_write_network(file *f,struct wpa_ssid *ssid) 34 IN T _D E F e (fragm e n t_size, D E F A U L T _F R A G M E N T _S IZ E ); 35 #endif /* IEEE8021X _EA P O L */ 36 IN T (m o de ); 37 + IN T (frequency); 38 IN T (pro ac tive _ke y_c ac h in g); 39 IN T (disable d); 40 IN T (pe e rke y); 41 diff --git a/w pa_supplicant/ctrl_iface.c b/w pa_supplicant/ctrl_iface.c 42 index bcf27be.0886b 図 4.8 IBSS-all-in-one.diff 内の external の修正部分 (1) 21

24 43 =--- a/external/w pa_supplicant_8/w pa_supplicant/ctrl_iface.c 44 =+++ b/external/w pa_supplicant_8/w pa_supplicant/ctrl_iface.c , ,45 static int ctrl_iface_get_capability_auth_alg(int res,char *strict, 46 return pos - buf; 47 } static int ctrl_iface_get_capability_m odes(int res,char *strict, 50 + struct w pa_driver_capa *capa, 51 + char *buf,size_t buflen) 52 +{ 53 + int ret, first = 1 ; 54 + char *pos,*end; 55 + size_t len; pos = buf; 58 + end = pos + buflen; if (re s < 0 ) { 61 + if (strict) 62 + return 0; 63 + len = os_strlcpy(buf, " IB SS AP", buflen); 64 + if (len >= buflen) 65 + return -1; 66 + return len; 67 + } if (capa->flags & (W PA_D RIVER _FLAG S _IB SS)) { 70 + ret = os_snprintf(pos,end - pos,"%sib S S ",first? "" :" "); 71 + if (re t < 0 re t > = e n d - po s) 72 + return pos - buf; 73 + pos += ret; 74 + first = 0; 75 + } if (capa->flags & (W PA_D RIVER _FLAG S _AP)) { 78 + ret = os_snprintf(pos,end - pos,"%sap", 79 + first? "" :" "); 80 + if (re t < 0 re t > = e n d - po s) 81 + return pos - buf; 82 + pos += ret; 83 + first = 0; 84 + } return pos - buf; 87 +} 図 4.9 IBSS-all-in-one.diff 内の external の修正部分 (2) 22

25 88 89 static int ctrl_iface_get_capability_channels(struct w pa_supplicant *w pa_s, 90 char *buf,size_t buflen) -2457,7 static int ctrl_iface_get_capability_channels(struct wpa_supplicant *wpa_s, 92 default: 93 continue; 94 } 95 - ret = os_snprintf(pos,end - pos,"m ode[%s] C hannels:",hm ode); 96 + ret = os_snprintf(pos,end - pos,"m ode[%s] C hannels:\n",hm ode); 97 if (re t < 0 re t > = e n d - po s) 98 return pos - buf; 99 pos += ret; -2465,7 static int ctrl_iface_get_capability_channels(struct wpa_supplicant *wpa_s, 101 for (i= 0;i< w pa_s->hw.m odes[j].num _channels;i++) { 102 if (c h n l[i].flag & H O S T A P D _C H A N _D IS A B L E D ) 103 continue; ret = os_snprintf(pos,end - pos," %d",chnl[i].chan); ret = os_snprintf(pos,end - pos," %d = %d M H z%s\n", chnl[i].chan,chnl[i].freq, chnl[i].flag & H O S T A P D _C H A N _N O _IB S S? " (N O _IB S S )" :""); 108 if (re t < 0 re t > = e n d - po s) 109 return pos - buf; 110 pos += ret; -2530,6 static int wpa_supplicant_ctrl_iface_get_capability( 112 return ctrl_iface_get_capability_auth_alg(res,strict,& capa, 113 buf,buflen); if (os_strcm p(field, "m odes" ) == 0 ) return ctrl_iface_get_capability_m odes(res,strict,& capa, buf,buflen); if (o s_strc m p(fie ld, " c h an n e ls" ) = = 0 ) 120 return ctrl_iface_get_capability_channels(w pa_s,buf,buflen); diff --git a/w pa_supplicant/w pa_cli.c b/w pa_supplicant/w pa_cli.c 123 index 3986b9b..97e11bb =--- a/external/w pa_supplicant_8/w pa_supplicant/w pa_cli.c 125 =+++ b/external/w pa_supplicant_8/w pa_supplicant/w pa_cli.c -2417,7 static struct wpa_cli_cmd wpa_cli_commands[] = { 127 "<<idx> <bssid>> = get detailed scan result info" }, 128 { " ge t_c apability", w pa_c li_c m d_ge t_c apability, N U L L, 129 cli_cm d_flag_none, "<eap/pairw ise/group/key_m gm t/proto/auth_alg/channels> " "<eap/pairw ise/group/key_m gm t/proto/auth_alg/channels/m odes> " 132 "= get capabilies" }, 133 { " re c o n figu re ", w pa_c li_c m d_re c o n figu re, N U L L, 134 cli_cm d_flag_none, 135 diff --git a/api/current.txt b/api/current.txt 136 index c57a541..b2d9c2a 図 4.10 IBSS-all-in-one.diff 内の external の修正部分 (3) 今回の修正で 主に Android における WiFi アドホックモードの修正や WiFi 設定画面でアドホックネットワークに接続できるインターフェースの追加等を 行った 23

26 4.7 Cyanogenmod のカーネル構築とインストール今回行った Cyanogenmod のカーネル構築について順を追って解説する 尚 前提条件として使用する端末と PC が USB 接続されている事 端末のアンロックが済んでおり ブートメニューが開ける状態であること AndroidSDK がインストールされている事とする まず初めに apt-get install コマンドを用いてビルド環境が 32bitPC であっても 64bitPC であっても以下のプログラムをインストールする bison build-essentialcurlflex git gnupg gperf libesd0-dev liblz4-toollibncurses5-dev libsdl1.2 - dev libw xgtk2.8 - dev libxm l2 libxm l2 - utils lzop openjdk- 6 - jdk openjdk- 6 - jre pngcrush schedtoolsquashfs-tools xsltproc zip zlib1g-dev 尚 64bitPC の場合は以下のプログラムもインストールを行う g++-m ultilib gcc-m ultilib lib32ncurses5-dev lib32readline-gplv2-dev lib32z1-dev 次にダウンロードする Cyanogenmod のソースファイルを置いておくディレ クトリを作成する ソースファイルを置くディレクトリは分かりやすいように /android/system とする $ m kdir -p ~/bin $ m kdir -p ~/android/system ディレクトリの作成が終わったら Cyanogemnod のソースファイルをインストールするために必要な repo コマンドを bin ディレクトリ内にインストールする repo コマンドとは Android のプロジェクト管理用に作られた git の管理ツールである 複数の git リポジトリを一括で管理することができる 普通に独自のプロジェクトに利用することが可能なため 規模が大きくなり 複数リポジトリを管理する必要があるプロジェクトに使うのが最適である repo コマンドの 24

27 インストールの方法は以下のとおりである インストールし終わった repo コマ ンドにはパスを通しておく必要がある パスの通し方については解説を省略す る $ curlhttps://storage.googleapis.com /git-repo-dow nloads/repo > ~/bin/repo $ chm od a+x ~/bin/repo Cyanogenmod のソースリポジトリを初期化するために次のように入力する リポジトリとは倉庫 集積所などの意味の通りなんらかのデータや情報プログラムが体系立てて保存されている場所である アプリケーションやシステムの設定情報がまとめて記録されているファイルやフォルダのことや 複数の開発者が参加するプログラミング環境においてソースコードや使用に関する情報をまとめて保管してくれるシステムなどを指すことが多いとされている 今回ダウンロードする Cyanogenmod のバージョンは 10,2 なので以下のように入力する $ cd ~/android/system / $ repo init -u /C yanogenm od/android.git -b cm メールアドレスやユーザー名を聞いてくるので入力を行い repo has been initialized in ( ソースコードを保管するディレクトリの場所 ) が表示されれば準備が完了した証拠である そして以下コマンドを行うことでソースコードのダウンロードが始まる このダウンロードには PC のスペックや電波状況などにより数時間から約半日の時間がかかるため注意が必要になる 尚 管理者権限等で repo コマンドが実行できない場合は以下のように sudo を付け加えた上で repo を置いてあるディレクトリの場所を記述することで repo コマンドが動く $sudo ~/bin/repo sync インストールが完了すると system ディレクトリ内に以下のようなファイル が生成される 25

28 図 4.11 ダウンロードされた Cyanogenmod10.2 のソースファイル しかし インストールした段階では足りないディレクトリがいくつかあるのでそれらは別途 GitHub からダウンロードしなくてはならない GitHub とはプログラムのソースコードを公開 共有するサイトで Cyanogenmod のダウンロードもそのサイトから行っている 今回は drivers のディレクトリが repo コマンド入力時には存在していなかったので GitHub からダウンロードし system ディレクトリ内に組み込んだ また external device freamworks packages の4つのディレクトリに関しては次のステップでパッチを当てるのであらかじめ権限を解除しておく必要がある ソースファイルのダウンロードが完了したのを確認したら 先ほどの4つのディレクトリのパッチファイルを当てる部分のみを取り出し パッチに記載されている通りのディレクトリの階層構造に修正しておく 当初は system ディレクトリ内で patch コマンドを使用しようとしたがエラーが出てしまい 会費が困難だったため以下の手順でパッチを当てる 1 パッチファイルが動作するように階層を整理した4つのディレクトリとパッチファイルである IBSS-all-in-one.diff を一度端末内に adb push コマンドを用いて移動する 2 adb shell コマンドを用いて端末内を PC 側で操作できるようにして 端末のルートディレクトリで以下のコマンドを入力する patch -p1 < IB SS-a l-in-one.diff 3 パッチを当て終わったファイルを adb pull コマンドを用いて再び PC 側に送 り返す 26

29 図 4.12 WiFiNative.java 内の修正箇所 ( 左 ) と実際に修正されたソースコード ( 右 ) 上記のソースコードの一部を見てわかるように 端末から送り返された修正後のファイルは IBSS-all-in-one.diff に記載されていた部分を追加 又は削除されている これらを再び元のソースファイルに入れることで次の段階へ進む 次に vender ディレクトリ配下の cm ディレクトリに移動し以下のコマンドを入力することでカーネルの上で動作するアプリの取得を行う $ cd ~/android/system /vendor/cm $./get-prebuilts 次にソースコード内のルートディレクトリ (~/android/system) に戻り 次のよ 27

30 うに入力する これは使用する端末固有の設定とカーネルのソースをダウンロードする breakfast コマンドの入力によってローカルマニフェストの作成が不要になる ここの詳細な説明はまだ把握できていない箇所が多くあるので割愛する また breakfast コマンドの後には Nexus72013 年度バージョンのコードネームである flo を入力する $ source build/envsetup.sh $ breakfast flo 端末が接続されていることを改めて adb device で確認し 以下のコマンドを 使い 処理が終了したらソースファイルのルートディレクトリ (~/android/system) へ移動する $ cd ~/android/system /device/asus/flo $./extract-files.sh 最後に brunch コマンドを用いてカーネル構築を行う為に ソースファイルをビルドする この際 repo コマンドを用いてダウンロードした時と同様に非常に時間がかかる また PC のスペックにも依存してくるので極力スペックの高い PC を用いてビルドを行うことを進める ( 今回使用した PC は Acer Aspire S3 series である ) $ brunch grouper 余談であるが ディレクトリの階層構造が当初ソースファイルをインストールした時と違っていたりすると うまくカーネル構築が行えないことがあった もしエラーがでてしまいうまく進まないときは修正し 再び取り込んだ修正済みのディレクトリがちゃんと元の場所にあるかどうかを確認することを忘れずにしてもらいたいと思う それでもうまくいかない場合は PC 自体のスペック不足も考えられるので別の PC で行うことも勧める どちらが原因にしてもこのカ 28

31 ーネル構築は非常に根気のいる作業になるのでエラーの出るたびに作業の見直 しや手順のやり直しを行うべきである ビルドが成功し終わるとソースファイル内に out ディレクトリが生成される 図 4.13 ビルドが終了した Cyanogenmod のソースファイル ~/android/system/out/target/product/flo のディレクトリの内部に cm-10.2-( 生成した年月日 )-UNOFFICIAL-flo.zip と名前の付けられた zip ファイルがある これを端末内へ移動させ カスタムリカバリからこの zip ファイルを読み込むことで修正した Cyanogenmod のインストールが完了する 図 4.14 生成された Cyanogenmod 生成された zip ファイルは SuperSU と同じように TWRP を用いて Nexus7 にインストールする インストールを行う前に Wipe タブから Dalvik Cache System Data Cache の4つを選択し 消去する その後 Install タブから Cyanogenmod の zip ファイルをインストールする 29

32 図 4.15 Wipe 画面 図 4.16 Cyanogenmod のインストール画面 30

33 第 5 章 Cyanogenmod によるアドホックモード接続実験 5.1 Cyanogenmod の WiFi 設定画面 Cyanogenmod を起動し WiFi 設定画面を開くと Android の場合とは異なり周辺にアドホックネットワークがある状態であれば設定画面に表示される また ネットワークの追加タブを開くと詳細オプションにアドホックネットワークについての項目が増えているのを確認した 図 5.1 Cyanogenmod の WiFi 設定画面 31

34 図 5.2 Cyanogenmod のネットワーク追加画面 設定画面でのアドホックネットワーク作成が可能となったので 実際に構築できるかの検証を行った 使用機器 ASUS Nexus (Cyanogenmod インストール済み ) 1 acer Aspire S3 2 内容 PC2 台と Nexus7 でのアドホックモードでの接続の検証 表 5.1 実験の構成 32

35 実験の結果 WiFi 設定画面からはアドホック接続済みという表示が出た しかし複数回検証した結果 アドホック接続済みと表示されても実際にアドホック接続が行われているかは分からなかった アドホック接続と表示された後 Nexus7 から Ping を送信してみると出来る場合と出来ない場合があった また ルーティングテーブルも Ping を送信できていない場合は表示されなかった 図 5.3 アドホックモード接続画面 図 5.4 接続成功時のルーティングテーブル 図 5.5 Nexus7 からの Ping 送信画面 33

36 5.2 ビーコンフレームの調査検証の結果 Nexus7 でのアドホックモードの接続は不安定であった この原因を調査する為にビーコンフレームの調査を行った その際 使用したソフトウェアは WireShark である この WireShark は 高機能なパケット取得ソフトで 800 以上のプロトコルを解析することができる これを用いて 5.1 の環境でビーコンフレームの調査を行った ビーコンフレームを調査するのには理由がある アクセスポイントを利用するネットワークではネットワークを利用する各端末はアクセスポイントの MAC アドレスを BSSID として保持する アドホックモードを利用する場合も同様に各端末は BSSID を保持する この BSSID は最初にアドホックモードを立ち上げた端末が作成する BSSID はビーコンフレームに含まれておりアドホックモードで接続している各端末はこのビーコンフレームを定期的に送信しあっている つまり アドホックモードで接続している各端末は同じ BSSID を含むビーコンフレームを送信している 図 5.5 各ネットワークの BSSID の共有 34

37 図 5.6 ビーコンフレームの送受信の様子 WireShark でビーコンフレームを調査した結果 Nexus7 は PC と同じ頻度 でビーコンフレームを送信していることがわかった また ビーコンフレーム を一つ一つ見ていくと すべて同じ BSSID であることがわかった しかし 今 回は アドホックモードの接続が不安定で Ping が送信出来る場合と出来ない 場合がある原因を突き止めることはできなかった 図 5.7 各端末のビーコンフレーム 35

38 図 5.8 Nexus7 のビーコンフレーム 図 5.9 PC1 PC2 のビーコンフレーム 第 6 章 方式①のまとめ 今回行った方式は Android のカスタム OS にアドホック接続可能なパッチを 用いてカーネル構築するというものであった アドホックモードへの変更は行 うことが出来たが Ping の送受信には不安定さが残った また ルーティング ソフトなどは実装できておらず その為マルチホップ通信にも未対応である 今後は接続の不安定さを解決し より安定したアドホックモードの利用を目 指していく 36

39 第 7 章方式 Android に相乗りする形での Linux の動作 7.1 Android 端末でのアドホックネットワーク構築の際の課題 Android 端末でのアドホックネットワーク構築を考える際 最低限満たさなければいけない点が 2 つある 1 つは Android 端末の無線ネットワークインターフェースをアドホックモードに変更すること もう 1 つはアドホックネットワークに接続している各端末のルーティングテーブルを交換するために必要なルーティングソフトを Android 端末に移植すること である この 2 点は PC でアドホックネットワークを構築する際にも必要な点であるが Android 端末には PC でアドホックネットワークを構築する場合よりも難しい点がいくつか存在する 無線ネットワークインターフェースのモード変更 Linux には wireless-tools という無線ネットワークインターフェースの設定や 詳細表示等を行うツールが存在し 以下の 5 つのコマンドを入力することで使 用できる iwconfig iwlist iwspy iwpriv ifrename 無線ネットワークインターフェースの参照 設定を行う無線ネットワークインターフェースの詳細情報を表示する無線ネットワークインターフェースでアドレスのリストを設定 それらのリンク情報の品質をフィードバックする無線ネットワークインターフェースのプライベートパラメータを設定 取得する無線ネットワークインターフェースの名前を変更する表 7.1 wireless-tools のコマンド一覧 wireless-tools の中にある iwconfig コマンドは無線ネットワークインターフェースのモードを変更することができる PC でアドホックネットワークを構築する際 このコマンドを利用し無線ネットワークインターフェースのモードを変更する 通常 AndroidOS には wireless-tools のコマンドは用意されていない だが wireless-tools はユーザランドのプログラムなので Android のビルドシステムを使用することでビルドすることができる そのため iwconfig コマンドを Android 端末で利用できるようにすれば無線ネットワークインターフェースのモード変更ができると考えた 37

40 ルーティングソフト nuolsrv2 について OLSRv2 とはアドホックネットワーク用のプロアクティブ型ルーティングプロトコルであり OLSR というルーティングプロトコルの改良版である OLSRv2 は経路制御メッセージのサイズを削減できるアドレスのサイズ圧縮機能のような OLSR にはない いくつかの追加機能を有している nuolsrv2 とは OLSRv2 に完全準拠した ルーティングソフトである ユビキタスネットワーク研究室では PC でアドホックネットワークを構築する際 このソフトウェアを使用しているため 今回 Android 端末間のアドホックネットワークでもこのソフトウェアを使用しようと考えた Android 上にある実行ファイル形式のアプリケーションは java 言語で書かれたものである しかし 今回使用を考えた nuolsrv2 は C 言語で書かれたソフトウェアである Android では C 言語でライブラリを作成する Java 言語で書かれたプログラムから C 言語の処理を呼ぶ等の事は可能だが C 言語のみで実行ファイル形式のアプリケーションを作成することはできない そのため nuolsrv2 を Android に移植するには ライブラリ化するか Java 言語で書き換える必要がある 上記の無線ネットワークインターフェースとルーティングソフトの問題を解決するために 今回 Android 端末内で Android と Linux を同時に動作させる方法を検討した Android は Linux カーネルを使用しており 組み込み系 Linux に分類される また Android はアプリケーションをほぼ全て Android ランタイムにある Dalvik で動作させるため CPU は何でも良く 特に決まったものを使う必要はない しかし性能やコスト等の面から ほぼ全ての Android 端末は CPU に ARM アーキテクチャを用いている 図 7.1 Linux を追加した Android の構成図 38

41 また今回 Android 端末内で動作させる Linux として選んだ OS は Debian である Debian は Android で用いられる ARM アーキテクチャをサポートしており ARM アーキテクチャの CPU が使われている端末であれば Debian を利用することができる そのため 今回 Android 端末での動作に最適であると考えた 7.2 Debian-kit について 今回 Android 端末内で Debian を動作させるために用いたのが Debian-kit である この Debian-kit は Debian 等のフルバージョンを Android 端末に debootstrap でインストールすることができるというものである debootstrap は既にインストールされたシステムのディレクトリに Debian をインストールするツールで インストール CD 等を必要としない利点があり このツールを利用することで CD ドライブのない Android 端末にもインストールが可能になる また Debian-kit は人為的なルートディレクトリを作成せず Android のルートディレクトリと同じ位置に Debian のルートディレクトリを配置する そのため 稼働している Android 環境に相乗りする形で Debian を動作させることが可能で Debian 側からも Android のデータやプロセスを操作することが可能になる Android 端末でアドホックネットワークを構築できたとしても 通常の PC のように AndroidOS をアンインストールし ただ Linux を Android 端末にインストールして アドホックネットワークを構築するだけでは Android 端末を使う意味がない ユビキタスネットワークシステム研究室では Android 端末で構築されたアドホックネットワークを利用したアプリケーションの開発も行っている そのため 今後開発されたアプリケーションを利用することを考えた場合 Android の環境を端末に残しておく必要があった この Debian-kit を用いた方式であれば Debian 側に Linux 用の wireless-tools をインストールすることができるため Android 用にビルドする必要がなくなる そして iwconfig コマンドによって無線ネットワークインターフェースのモードの変更を行うことができる また今回使用する nuolsrv2 も Debian 側であればライブラリ化や Java 言語での書き換え等も必要なく そのまま動作することができる この 3 点から今回 Denia-kit を採用することにした 39

42 7.3 Debian-kit を利用するための条件 この Debian-kit を Android 端末で利用するためにはいくつかの前提条件があ る 1. Android 端末の root( 管理者 ) 権限を取得している 2. カーネルがループデバイスをサポートしている 3. カーネルが ext2 ext3 ext4 のファイルシステムをサポートしている 4. Android 端末の CPU アーキテクチャが ARM または I386 である 5. Android に端末エミュレーターアプリケーションがインストールされている または端末と ADB 接続が可能である まず 1 については 今回の研究で使用した端末である Nexus7 の root 権限は既に取得している 2 と 3 についても今回使用した Nexus7 のカーネルは対応していた 4 については Nexus7 の CPU は Krait という ARM 系コアであった 5 については root 権限を取得する際 busybox という実行ファイルをまとめたパッケージと Android Terminal Emulator という端末エミュレーターアプリケーションをインストールしたので 今回は Nexus7 上で直接コマンド入力を行った 7.4 Debian-kit での Debian 環境の構築 Debian-kit を用いた Android 上での Debian 環境の構築は以下の通りである 1.Debian-kit を から Android 端末上にダウンロードし インストールする 2.Android 端末上でイメージファイルを作成し Debian-kit のスクリプトを使って Debian をインストールする 3. 自動的に Debian が起動する その後 androidmize というパッケージと Debian-kit 用と Android4.3 以降の SELinux に合わせたパッケージをインストールする この流れに沿って行うことで Debian 環境の構築が可能である ここから順に詳しく説明する まず上記の URL にアクセスし Debian-kit をダウンロードする サイトにある debian-kit-1-5.shar というのが今回利用する Debian-kit である ダウンロー 40

43 ドを行う際 使用したブラウザ等の関係からか拡張子が.shar ではなく.jpeg と なったが 問題なく利用することができた 図 7.2 Debian-kit のダウンロード画面 次に ダウンロードした debian-kit-1-5.jpeg を Android にインストールする ここからはあらかじめ Nexus7 に用意した端末アプリケーションを起動し その端末上で行った Debian-kit のインストールは sh コマンドで行い これによって複数のスクリプトがインストールされる 図 7.3 debian-kit-1-5.jpeg のインストール 41

44 Y を押すと debian-kit のインストールが始まる インストールが終わるとイメージファイルを作成するかどうかを聞かれる Debian-kit では 2GB 以下のイメージファイルなら選択するだけで自動的に作成を行う しかし今回は容量に余裕を持たせるために 4GB のイメージファイルを用意し そのイメージファイルを Debian-kit のスクリプトに渡してインストールする形を取った 図 7.4 イメージサイズ選択画面 イメージファイルを作成するのに使用したコマンドは dd コマンドである このコマンドはファイルのコピーと変換を行うもので ファイルシステムを問わずイメージファイルを作成することができる この dd コマンドを利用して /sdcard/linuximages 内に squeeze-armel.img という 4GB のサイズのイメージファイルを作成し スクリプトに渡した 図 7.5 イメージファイルの作成 42

45 図 7.6 スクリプトによるイメージファイルへの Debian のインストール Debian イメージの作成が完了すると deb と入力するように指示がでて 入 力すると 2nd ステージに自動的に移行する この処理が終了しプロンプトが帰 ってくると既に Debian squeeze の root ログイン状態になっている 43

46 図 7.7 Debian-kit 2nd ステージ 44

47 次に パッケージのリフレッシュと andromize というパッケージのインストールを行った andromize とは Android 側に追随して /etc/resolv.conf を変更することが可能になるものである すでに Debian の root ログイン済状態なので apt-get コマンドを利用してインストールを行った 同じように SELinux のパッケージについてもインストールした 図 7.8 パッケージリフレッシュと andromize のインストール 45

48 図 7.9 SELinux のインストール Android と Debian が同時に動作することができるのは Debian を起動する際に使用する bootdeb というスクリプトによるものである bootdeb は debian-kit-1-5.shar に含まれるスクリプトである このスクリプトが起動した時点で chroot が行われ Debian 側のルートディレクトリを Android 側のルートディレクトリと同じ位置にする この時 Android と Debian にはルートディレクトリ上にあるディレクトリの内 同じ名前のものが 7 つある /dev /etc /mnt /proc /root /sbin /sys の 7 つである このうちの /dev /mnt /proc /sys の 4 つのディレクトリは Android 側の 46

49 ものをそのままマージして利用する 残り /etc /root /sbin の 3 つのディレクトリは Android 側のものをリネーム保存し シンボリックリンクを作成して中身を Debian 側の /etc /root /sbin にマージする Android 側の 3 つはそれぞれ /.etc.debian-android /.root.debian-android /.sbin.debian-android として隠しディレクトリとしてルートディレクトリ上に保存される 他の Android 独自のディレクトリ Debian で追加されたディレクトリはそれぞれルートディレクトリ上に置かれる すると Debian と Android の両方が動作している状態になる 図 7.10 Debian マウント後の Android のルートディレクトリ 7.5 wireless-tools のインストール Debian の起動に成功したので wireless-tools のインストールを行う この 47

50 ツールも先ほど使用した apt-get コマンドを使用することでインストールが可 能である 図 7.11 wireless-tools のインストール インストールした wireless-tools で Nexus7 の無線ネットワークインターフェースを変更できるかを検証した wlan0 は Nexus7 の無線ネットワークインターフェース名である また iwconfig の各項目については以下の通りであえる Qcom ESSID Nickname Mode Channel Cell Bit Rate Tx-Power RTS thr Fragment thr Encryption key 無線 LAN 規格 ESSID 無線ネットワークインターフェースのニックネーム接続モード Ad-hoc はアドホックモード Managed はインフラストラクチャモードチャンネル BSSID ビット レート出力パワー RTS/CTS(Request To Send/Clear To Send) のしきい値フラグメンテーションのしきい値暗号化キー表 7.2 iwconfig の項目一覧 wlan0 の Mode の部分をみてみると Ad-Hoc になっていることが分かる つ 48

51 まり iwconfig によって無線ネットワークインターフェースのモードを変更でき たことがわかった 図 7.12 無線ネットワークインターフェース画面 7.6 ルーティングソフトの動作 次にルーティングソフト nuolsrv2 を動作させる まず nuolsrv2.zip を Nexus7 に用意する そして Debian 側から nuolsrv2.zip を解凍し 解凍した nuolsrv2 の中にある nuolsrv2d ディレクトリ内で make コマンドによりコンパイルする 次に nuolsrv2 の実行を行う コマンドラインから nuolsrv2d ディレクトリ内で /nuolsrv2d nuolsrv2d.conf と入力し 実行する Nexus7 の Debian 側でも nuolsrv2 を利用できることを確認した 図 7.13 nuolsrv2 のコンパイル 49

52 図 7.14 nuolsrv2 の実行画面 第 8 章アドホックネットワークの構築と Android での利用 Debian wireless-tools nuolsrv2 をすべて準備したので 実験を行った 使用機器 ASUS Nexus7 flo (Debian インストール済 ) 1 acer Aspire s3 (OS Ubuntu12.04) 3 この 4 つ全てに nuolsrv2 を用意する Nexus7 と PC3 台でアドホックネットワークを構築する その後 Nexus7 の Android 側から構築したアドホックネットワークを利用できるかを検証する 使用機器にはそれぞれ ifconfig コマンドで IP アドレスを割り振った 使用機器 IP アドレス Nexus PC PC PC 表 8.1 使用機器と IP アドレス 50

53 結果 Nexus7 と PC3 台でアドホックネットワークを構築することに成功した 各端末のルーティングテーブルをまとめたものが以下になる Nexus7 のルーティングテーブルをみると PC2 とは直接つながっており PC1 と PC3 は共に PC2 を経由したマルチホップ通信をしていることがわかる 図 8.1 Nexus7 のルーティングテーブル 図 8.2 PC3 のルーティングテーブル 図 8.3 ルーティングテーブルのまとめ 51

54 Nexus7 がマルチホップ通信をしていることが分かった そこで Nexus7 の Android 側から構築したアドホックネットワークを利用できるかを確認するために Ping 通信を利用して検証した Nexus7 から PC1 PC3 に Ping を送信したところきちんと送信することができた これで Android 側からでもアドホックネットワークを利用できることが分かった 図 8.4 Nexus7 から PC1 への Ping 送信 図 8.5 Nexus7 から PC3 への Ping 送信 第 9 章方式のまとめ 方式 2は Android に相乗りさせる形で Linux を動作させ Linux 側でアドホックネットワークの構築を行うという手法をとった その結果 アドホックネットワーク構築に必要なモード変更のコマンドやルーティングソフトを Android で利用できるように変更を加える必要なく Linux 側でそのまま利用することができた また Android 側でも Linux 側で構築したアドホックネットワークを利用することができることができ 今後 Android でアドホックネットワークを利用するアプリケーションが開発された場合にも対応することができると言える 52

55 第 10 章まとめ 今回 Android でアドホックネットワークを構築するために 2 つの方式を検討した 方式 1 Android のカスタム OS にアドホックモード接続可能なパッチを用いてカーネル構築をする 方式 2 Android に相乗りさせる形で Linux を動作させる 方式では GUI で簡単に設定を行うことができるアドホックモードの利用を目指した アドホックモードへの変更は行うことが出来たが Ping 送受信の不安定さや ルーティングソフトが未実装である点など クリア出来ていない課題が多いので これらの改善 実装が必要である 方式では Linux のコマンドラインの操作を Android で実現することによってアドホックモードの利用を行った 無線ネットワークインターフェースのアドホックモードへの変更 ルーティングソフトの実装を行い Android でアドホックネットワークの構築を可能にし 構築したネットワークを Android で利用することもできた しかし この方式では Debian のフルインストールが必要であった 今後は iwconfig コマンドやルーティングソフトのみの Android への実装を検討していく 表 10.1 方式 1 方式のまとめ 53

56 謝辞本研究を進めるにあたり ご指導を頂いた卒業論文指導教員の松井進教授に感謝いたします また 多くの知識や示唆を頂いた井上雄紀准教授 西口敏司准教授 ユビキタスネットワークシステム研究室の皆様に感謝します 54

57 参考文献 Tae Yeon Kim ( 著 ), Hyung Joo Song ( 著 ), Ji Hoon Park ( 著 ), Bak Lee ( 著 ), Ki Young Lim ( 著 ) Android フレームワーク研究会 ( 翻訳 ) (2013/12/18) Android のなかみ Inside Android パーソナルメディア 総務省平成 25 年度版情報通信白書第 2 部情報通信の現況 政策の動向第 3 節インターネットの利用動向 < html> (2015/02/03) Cyanogenmod < (2014/09/25) Cyanogenmod:Wiki < >(2014/09/25) Thinktube-Android Adhoc < >(2014/09/25) How To Build CyanogenMod Android for Google Nexus 7 (Wi-Fi, 2012 version) ("grouper") < > (2014/12/03) Android 徹底解説 --- 内部構造, 移植, 開発 - Android の仕組みを知る :ITpro < ev> (2015/02/03) 差異が多い Android の無線 LAN 802.1X では EAP や認証方式に注意 :ITpro < />(2015/02/03) 新型 Nexus7(2013) の開発者向けオプションを表示させて USB デバッグをオンにする方法 < l > (2014/10/20) 55

58 新型 Nexus7(2013) のブートローダーアンロック (Bootloader Unlock) 方法 < l> (2014/10/20) 新型 Nexus7(2013) にカスタムリカバリ TWRP を導入する方法 < html > (2014/10/20) 新型 Nexus7(2013) の Root 化方法 手順 < (2014/10/20) Debian Kit for Android < Optimized Link State Routing Protocol(RFC 3626) < 56