論文吉田坂本

学士論文

Android 端末間の

アドホックネットワークの構築

大阪工業大学

情報科学部 情報ネットワーク学科

N11-040 坂本浩基

N11-107 吉田和矢

目次

第1 章 緒言 1 1.1 研究の背景・・・・・・・・・・・・・・・・・・・・・・・・ 1 1.2 研究の目的・・・・・・・・・・・・・・・・・・・・・・・・ 1 第2 章 研究の概要 2 2.1 アドホックネットワーク・・・・・・・・・・・・・・・・・・ 2 2.2 Android に搭載されている端末通信方式・・・・・・・・・・・ 2 第3 章 開発環境について 6 3.1 Android の歴史及び基本知識・・・・・・・・・・・・・・・・ 6 3.2 開発用パーソナル・コンピューター・・・・・・・・・・・・・ 9 3.3 動作確認用Android 端末・・・・・・・・・・・・・・・・・・ 9

3.4 Android のカスタム OS Cyanogenmod について・・・・・・・ 10

第4 章 方式 のアドホックネットワークの実装準備 10 4.1 Bootloader について・・・・・・・・・・・・・・・・・・・・ 11 4.2 root 権限について・・・・・・・・・・・・・・・・・・・・・ 11 4.3 adb コマンドの解説とデバイスの接続手順・・・・・・・・・・ 12 4.4 Bootloader のアンロック・・・・・・・・・・・・・・・・・・ 14 4.5 カスタムリカバリの導入・・・・・・・・・・・・・・・・・・ 17 4.6 root 権限の取得・・・・・・・・・・・・・・・・・・・・・・ 18 4.7 Cyanogenmod のカーネル構築とインストール・・・・・・・・ 24 第5 章 Cyanogenmod によるアドホックモード接続実験 30 5.1 Cyanogenmod の WiFi 設定画面・・・・・・・・・・・・・・ 31 5.2 ビーコンフレームの調査・・・・・・・・・・・・・・・・・・ 34 第6 章 方式 のまとめ 36 第7 章 Android に相乗りする形での Linux の動作 37 7.1 Android 端末でのアドホックネットワーク構築の際の課題・・・ 37 7.2 Debian-kit について・・・・・・・・・・・・・・・・・・・・ 39 7.3 Debian-kit を利用するための条件・・・・・・・・・・・・・・ 40 7.4 Debian-kit での Debian 環境の構築・・・・・・・・・・・・・ 40 7.5 wireless-tools のインストール・・・・・・・・・・・・・・・・ 47 7.6 ルーティングソフトの動作・・・・・・・・・・・・・・・・・ 49 第8 章 アドホックネットワーク構築と Android での利用 50 第9 章 方式 のまとめ 52 第10 章 まとめ 53 謝辞 参考文献

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

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

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

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

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

6 これはグーグルが意図的にアドホックモードへの変更に対応させていないか らである。図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 の登場によって市場が２つに

分かれることになる。Android と iPhone との最大の違いは OS のオープンソフ トライセンス化である．これにより各社で同じAndroidOS を導入しても各社独 自のAndroidOS が導入されることになった。Android の大きなメリットは無償 であることと、オープンソースであることだ。端末メーカーはAndroid を搭載 したスマートフォンを作るためのライセンス料がかからないため、制作コスト を抑える事ができる。また、開発者にはOS に関するコードが公開されているた め、カスタマイズがしやすくなる。また、Google が中心になっているため、Gmail、

7

Google カレンダー、YouTube など Google が提供するサービスと連携している のも特徴である。

Android は Linux カーネルを採用している．Linux カーネルは、メモリやプ

ロセスの管理、ファイルシステム、セキュリティといった基本機能を加え各種 ドライバーを提供している．結果、Android は Linux カーネルの上にミドルウ ェアが搭載されている．しかし、そのうえで動作するミドルウェアとの結合は 弱く、比較的ユーザーによる変更自由度は高い．たとえばXperia のカスタム ROM では純正カーネルではなくソニーエリクソン製のものが使われ、その上で Android が動作している． 図3.1 Android のレイヤー構成 図3.1 で示した通り Android はハードウェア上に主に主に５つのスタック で構成される．一番下はLinux カーネルであり、前述した通り PC などで使わ れるLinux カーネルを Android 用にカスタマイズしたものである。

次にHAL（Hardware Abstraction Layer）で、ハードウェア抽象レイヤ

ーと呼ばれる。主にHAL の内部では Linux カーネルにあるデバイスドライバ ー（デバイスを制御するプログラム）にアクセスしてデータを取得している。 これによりAndroid のハードウェアごとの差異を HAL 以下のレイヤーに抑え ることができ、HAL より上位のレイヤーでは、ハードに依存しないコードにな る。 HAL の上部にあるのがライブラリとアンドロイド・ランタイムである。ライ ブラリには様々なミドルウェアが格納されている。組み込み機器向けに開発さ れているOpenGL｜ES や、データベースライブラリにある SQLite などがある。 一方アンドロイド・ランタイムはAndroid のアプリケーションを動作させるた Linuxカーネル

H AL（H ardw are　Abstraction Layer）

ライブラリ アンドロイド・ランタイム

アプリケーション・フレームワーク アプリケーション

8 めの実行環境である。この中には基本的な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 レベル、コードネームをまとめたものである。

9 表3.1Android のバージョン一覧 3.2 開発用パーソナル・コンピューター 前述した方式①では、パーソナル・コンピューターでカーネルの構築を行う。 ソースファイルをダウンロード、ビルドする際又はカーネル構築を行う時に Linux 系の OS で使用されるコマンドを使用する。なので、今回使用する PC は Linux 系の OS である Ubuntu バージョン 14.04 を導入したものを使用した。 3.3 動作確認用 Android 端末

今回はASUS 社の Nexus7 2013 flo を採用した。採用理由は２つあり一つ目

は以前の卒業生の先輩方の研究で使用していたTOSHIBA 社の REGZA TabletAT570 を使用していた。このタブレットは残念ながらルート権限を取得 してもAndroid のカーネルを操作することができないため、本研究には不向き だということが判明した。もう一つの理由はこのNexus7 が後述するカスタム OS である Cyanogenmod に対応しており、このカスタム OS に対応したアドホ ックネットワークを利用可能にするパッチを配布しているサイトを見つけたの で採用した。また、Nexus7 には製造された各年度によってバージョンが異なる。 現状では2012 年度バージョン(grouper)と 2013 年度バージョン(flo)である。 Cyanogenmod を用いたカスタム OS 導入の方法でアドホックネットワークを構 築する際には同年度のNexus7 で使用しないとカーネル構造の違いからインス バージョン APIレベル コードネーム 1 1 B ase(ベース) 1.1 2 B ase1.1 1.5 3 C upcake(カップケーキ) 1.6 4 D onut(ドーナッツ) 2 5 Eclair(エクレア) 2.1 7 Eclair M RI 2.2 7 Froyo(フロヨ) 2.3 9 G ingerbread(ジンジャーブレッド) 3 11 H oneycom b(ハニカム) 3.1 12 H oneycom b M R1 3.2 13 H oneycom b M R2

4 14 Ice C ream Sandw ich(アイスクリームサンドイッチ) 4.1 16 Jelly B ean(ジェリービーン)

4.2 17 Jelly B ean M R1 4.3 18 Jelly B ean M R2 4.4 19 KitKat(キットカット)

10

トールを行うことができないので注意しなくてはならない。 3.4 Android の拡張 OS Cyanogenmod について

図3.2 Cyanogenmod11 「kitkat」のメニュー画面

Cyanogenmod とは Cyanogenmod 社が提供している AndroidOS をカスタマ

イズしたオープンソースのスマートフォン及びタブレット向けのオペレーティ

ングシステムである。Cyanogenmod の開発者たちは Open Android Alliance

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

11 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 を配布している。

12

ンロック)しなくてはならないが、近年アンロック可能な機種が増え既にアンロ

ックされたデバイスも増えつつある。

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

13 ケーブルで接続し、ドライバーが正常にインストールできなかったというメッ セージが表示されるが無視し、デバイスマネージャーを開く。自分の端末が「ほ かのデバイス」として認識されている。この行を左ダブルクリックしプロパテ ィを表示する。プロパティのプルダウンメニューから「ハードウェア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 の主要コマンドは以下のとおりである。

14 表4.1 adb の主要なコマンド。 4.4 Bootloder のアンロック Bootloader、root、adb コマンドの理解を踏まえた上で、Nexus7 にカスタム OS を導入するまでを解説する。始めに Nexus7 を USB ケーブルで PC に接続 し、PC に予めダウンロードした AndroidSDK の platform-tools フォルダ内で コマンドウィンドウを開く。

PC のコマンド入力画面で「adb reboot bootloader」と入力すると、端末が再起

動してブートローダー（Fastboot モード）が起動する。下の図のようにドロイ

15

図4.2 起動したブートローダー画面

PC のコマンド入力画面に戻って「fastboot oem unlock」と入力すると、端末

がブートローダーをアンロックするか訪ねてくるので、ボリュームボタンで

16

図4.3 ブートローダーのアンロック確認画面

PC のコマンド入力画面で「Unlocking bootloader done!」と表示されれば、

ブートローダーのアンロックが完了する。

17 4.5 カスタムリカバリの導入

続いて、Nexus7 にカスタムリカバリ TWRP を導入する。TWRP を導入する

ことで、Nexus7 の現在の状態をまるごとバックアップ及び復元を行うことがで

きるようになり、カスタムROM を導入できるようになる。

まず初めに、先ほどの手順と同様にadb コマンドで「adb reboot bootloader」

と入力しブートローダーを起動する。続にTWRP を次の URL からダウンロー

ドする。（http://www.teamw.in/project/twrp2/193）PC の端末上で

/platform-tools に移動し、「fastboot flash recovery」と入力して img ファイル

をダウンロードした場所を追加する。以下のように表示されればTWRP の導入 は完了する。 図4.5 TWRP の導入画面 最後にTWRP が起動するかを確認する。ブートローダー起動状態でボリュー ムボタンを押し、「Recovery mode」にして電源ボタンで決定する。そして以下 の様なカスタムリカバリの画面が起動すれば、TWRP の導入は成功している。

18 図4.6 カスタムリカバリの起動画面 4.6 root 権限の取得 Root 権限を取得するために SuperSU という実行ファイルが必要になる。 SuperSU とはインストールしたすべてのアプリのすべての権限を管理するもの でこのアプリケーションで管理者権限を取得して他のアプリケーションが管理

者権限を必要とした際に手助けを行う。SuperSU の zip ファイルは次の URL

からダウンロードすることができる。

（http://forum.xda-developers.com/showthread.php?t=1538053）

ダウンロードしたzip ファイルを Nexus7 の内部ストレージに保存する。TWRP

のInstall タブから zip ファイルを選び、インストールする。Successful と表示

19

図4.7 SuperSU インストール画面

再起動後、adb コマンドで root にログイン出来るかを確認した。

図4.8 root ログイン画面

4.7 Cyanogenmod の修正パッチの編集

今回Cyanogenmod に提供されていたパッチは ThinkTube の Cyanogenmod

によるAndroidAdhoc のページからダウンロードしたものを使用している。し

20

ョン(grouper)用であり Nexus7 2013 年度バージョン(flo)用は存在しなかった。

その為、ダウンロードしたパッチファイルをNexus7 flo 用に修正する必要があ

った。以下がNexus7 flo 用に修正した修正パッチである。今回修正パッチを当

てたCyanogenmod のファイルは root ディレクトリ以下 external、freamworks、

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

21

図4.8 IBSS-all-in-one.diff 内の external の修正部分(1)

1 diff --git a/src/drivers/driver.h b/src/drivers/driver.h 2 index e9f926f..fc1b06f 100644

3 =--- a/external/w pa_supplicant_8/src/drivers/driver.h 4 =+++ b/external/w pa_supplicant_8/src/drivers/driver.h 5 @ @ -834,6 +834,9 @ @ struct w pa_driver_capa { 6 #define W PA_D RIVER_FLAG S_IN AC TIVITY_TIM ER0x00800000

7 /* D river expects user space im plem entation of M LM E in AP m ode */ 8 #define W PA_D RIVER_FLAG S_AP_M LM E0x01000000

9 +/* D river supports IB SS (Ad-hoc) m ode */

10 +#define W PA_D RIVER_FLAG S_IB SS 0x02000000 11 +

12 unsigned int flags; 13

14 int m ax_scan_ssids;

15 diff --git a/src/drivers/driver_nl80211.c b/src/drivers/driver_nl80211.c 16 index b085e3b..760e55b 100644

17 =--- a/external/w pa_supplicant_8/src/drivers/driver_nl80211.c 18 =+++ b/external/w pa_supplicant_8/src/drivers/driver_nl80211.c

19 @ @ -2470,6 +2470,9 @ @ static int w iphy_info_handler(struct nl_m sg *m sg, 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 531957a..e4c787a 100644

31 =--- 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

33 @ @ -676,6 +676,7 @ @ static void w pa_config_w rite_netw ork(FILE *f, struct w pa_ssid *ssid) 34 IN T_D EFe(fragm ent_size, D EFAU LT_FRAG M EN T_SIZE);

35 #endif /* IEEE8021X_EAPO L */ 36 IN T(m ode); 37 + IN T(frequency); 38 IN T(proactive_key_caching); 39 IN T(disabled); 40 IN T(peerkey);

41 diff --git a/w pa_supplicant/ctrl_iface.c b/w pa_supplicant/ctrl_iface.c 42 index bcf27be..0886b17 100644

22

図4.9 IBSS-all-in-one.diff 内の external の修正部分(2)

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 @ @ -2432,6 +2432,45 @ @ static int ctrl_iface_get_capability_auth_alg(int res, char *strict, 46 return pos - buf;

47 } 48

49 +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; 56 +

57 + pos = buf; 58 + end = pos + buflen; 59 +

60 + if (res < 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 + } 68 +

69 + if (capa->flags & (W PA_D RIVER_FLAG S_IB SS)) {

70 + ret = os_snprintf(pos, end - pos, "%sIB SS", first ? "" : " "); 71 + if (ret < 0 || ret >= end - pos)

72 + return pos - buf; 73 + pos += ret;

74 + first = 0; 75 + }

76 +

77 + if (capa->flags & (W PA_D RIVER_FLAG S_AP)) { 78 + ret = os_snprintf(pos, end - pos, "%sAP", 79 + first ? "" : " "); 80 + if (ret < 0 || ret >= end - pos) 81 + return pos - buf; 82 + pos += ret;

83 + first = 0; 84 + }

85 +

86 + return pos - buf; 87 +}

23

図4.10 IBSS-all-in-one.diff 内の external の修正部分(3)

今回の修正で、主にAndroid における WiFi アドホックモードの修正や WiFi

設定画面でアドホックネットワークに接続できるインターフェースの追加等を 行った。

88

89 static int ctrl_iface_get_capability_channels(struct w pa_supplicant *w pa_s,

90 char *buf, size_t buflen)

91 @ @ -2457,7 +2496,7 @ @ static int ctrl_iface_get_capability_channels(struct w pa_supplicant *w pa_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 (ret < 0 || ret >= end - pos)

98 return pos - buf; 99 pos += ret;

100 @ @ -2465,7 +2504,9 @ @ static int ctrl_iface_get_capability_channels(struct w pa_supplicant *w pa_s, 101 for (i = 0; i < w pa_s->hw .m odes[j].num _channels; i++) {

102 if (chnl[i].flag & H O STAPD _C H AN _D ISAB LED ) 103 continue;

104 - ret = os_snprintf(pos, end - pos, " %d", chnl[i].chan); 105 + ret = os_snprintf(pos, end - pos, " %d = %d M H z%s\n", 106 + chnl[i].chan, chnl[i].freq,

107 + chnl[i].flag & H O STAPD _C H AN _N O _IB SS ? " (N O _IB SS)" : ""); 108 if (ret < 0 || ret >= end - pos)

109 return pos - buf; 110 pos += ret;

111 @ @ -2530,6 +2571,10 @ @ static int w pa_supplicant_ctrl_iface_get_capability( 112 return ctrl_iface_get_capability_auth_alg(res, strict, &capa,

113 buf, buflen); 114

115 + if (os_strcm p(field, "m odes") == 0)

116 + return ctrl_iface_get_capability_m odes(res, strict, &capa,

117 + buf, buflen); 118 +

119 if (os_strcm p(field, "channels") == 0)

120 return ctrl_iface_get_capability_channels(w pa_s, buf, buflen); 121

122 diff --git a/w pa_supplicant/w pa_cli.c b/w pa_supplicant/w pa_cli.c 123 index 3986b9b..97e11bb 100644

124 =--- 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

126 @ @ -2417,7 +2417,7 @ @ static struct w pa_cli_cm d w pa_cli_com m ands[] = { 127 "<<idx> | <bssid>> = get detailed scan result info" }, 128 { "get_capability", w pa_cli_cm d_get_capability, N U LL, 129 cli_cm d_flag_none,

130 - "<eap/pairw ise/group/key_m gm t/proto/auth_alg/channels> " 131 + "<eap/pairw ise/group/key_m gm t/proto/auth_alg/channels/m odes> " 132 "= get capabilies" },

133 { "reconfigure", w pa_cli_cm d_reconfigure, N U LL, 134 cli_cm d_flag_none,

135 diff --git a/api/current.txt b/api/current.txt 136 index c57a541..b2d9c2a 100644

24 4.7 Cyanogenmod のカーネル構築とインストール 今回行ったCyanogenmod のカーネル構築について順を追って解説する。尚、 前提条件として使用する端末とPC が USB 接続されている事、端末のアンロッ クが済んでおり、ブートメニューが開ける状態であること、AndroidSDK がイ ンストールされている事とする。

まず初めにapt-get install コマンドを用いてビルド環境が 32bitPC であって

も64bitPC であっても以下のプログラムをインストールする。 尚、64bitPC の場合は以下のプログラムもインストールを行う。 次にダウンロードするCyanogenmod のソースファイルを置いておくディレ クトリを作成する。ソースファイルを置くディレクトリは分かりやすいように /android/system とする。 ディレクトリの作成が終わったら、Cyanogemnod のソースファイルをインス トールするために必要なrepo コマンドを bin ディレクトリ内にインストールす る。

repo コマンドとは Android のプロジェクト管理用に作られた git の管理ツー

ルである。複数のgit リポジトリを一括で管理することができる。普通に独自の

プロジェクトに利用することが可能なため、規模が大きくなり、複数リポジト

リを管理する必要があるプロジェクトに使うのが最適である。repo コマンドの

bison build-essential curl flex git gnupg gperf libesd0-dev liblz4-tool libncurses5-dev libsdl1.2-dev libw xgtk2.8-dev libxm l2 libxm l2-utils lzop openjdk-6-jdk openjdk-6-jre pngcrush schedtool squashfs-tools xsltproc zip zlib1g-dev

g++-m ultilib gcc-m ultilib lib32ncurses5-dev lib32readline-gplv2-dev lib32z1-dev

$ m kdir -p ~/bin

25 インストールの方法は以下のとおりである。インストールし終わったrepo コマ ンドにはパスを通しておく必要がある。パスの通し方については解説を省略す る。 Cyanogenmod のソースリポジトリを初期化するために次のように入力する。 リポジトリとは倉庫、集積所などの意味の通りなんらかのデータや情報プログ ラムが体系立てて保存されている場所である。アプリケーションやシステムの 設定情報がまとめて記録されているファイルやフォルダのことや、複数の開発 者が参加するプログラミング環境においてソースコードや使用に関する情報を まとめて保管してくれるシステムなどを指すことが多いとされている。今回ダ ウンロードするCyanogenmod のバージョンは 10,2 なので以下のように入力す る。

メールアドレスやユーザー名を聞いてくるので入力を行い、「repo has been

initialized in (ソースコードを保管するディレクトリの場所)」が表示されれば準 備が完了した証拠である。 そして以下コマンドを行うことでソースコードのダウンロードが始まる。こ のダウンロードにはPC のスペックや電波状況などにより数時間から約半日の 時間がかかるため注意が必要になる。尚、管理者権限等でrepo コマンドが実行 できない場合は以下のようにsudo を付け加えた上で repo を置いてあるディレ クトリの場所を記述することでrepo コマンドが動く。 インストールが完了するとsystem ディレクトリ内に以下のようなファイル が生成される。

$ curl https://storage.googleapis.com /git-repo-dow nloads/repo > ~/bin/repo $ chm od a+x ~/bin/repo

$ cd ~/android/system /

$ repo init -u https://github.com /C yanogenM od/android.git -b cm -10.2

26 図4.11 ダウンロードされた Cyanogenmod10.2 のソースファイル しかし、インストールした段階では足りないディレクトリがいくつかあるの でそれらは別途GitHub からダウンロードしなくてはならない。GitHub とはプ ログラムのソースコードを公開、共有するサイトでCyanogenmod のダウンロ ードもそのサイトから行っている。今回はdrivers のディレクトリが repo コマ ンド入力時には存在していなかったのでGitHub からダウンロードし、system ディレクトリ内に組み込んだ。また、external、device、freamworks、packages の４つのディレクトリに関しては次のステップでパッチを当てるのであらかじ め権限を解除しておく必要がある。 ソースファイルのダウンロードが完了したのを確認したら、先ほどの４つの ディレクトリのパッチファイルを当てる部分のみを取り出し、パッチに記載さ れている通りのディレクトリの階層構造に修正しておく。当初はsystem ディレ クトリ内でpatch コマンドを使用しようとしたがエラーが出てしまい、会費が 困難だったため以下の手順でパッチを当てる。 ① パッチファイルが動作するように階層を整理した４つのディレクトリとパ

ッチファイルであるIBSS-all-in-one.diff を一度端末内に adb push コマンド

を用いて移動する。 ② adb shell コマンドを用いて端末内を PC 側で操作できるようにして、端末の ルートディレクトリで以下のコマンドを入力する。 ③ パッチを当て終わったファイルをadb pull コマンドを用いて再び PC 側に送 り返す。 patch -p1 < IB SS-all-in-one.diff

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

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

29 ーネル構築は非常に根気のいる作業になるのでエラーの出るたびに作業の見直 しや手順のやり直しを行うべきである。 ビルドが成功し終わるとソースファイル内に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 の４つを選択し、消去する。その後、Install タブから、 Cyanogenmod の zip ファイルをインストールする。

30

図4.15 Wipe 画面

31

第5 章 Cyanogenmod によるアドホックモード接続実験

5.1 Cyanogenmod の WiFi 設定画面

Cyanogenmod を起動し WiFi 設定画面を開くと、Android の場合とは異なり

周辺にアドホックネットワークがある状態であれば設定画面に表示される。ま た、ネットワークの追加タブを開くと詳細オプションにアドホックネットワー クについての項目が増えているのを確認した。

32

図5.2 Cyanogenmod のネットワーク追加画面

設定画面でのアドホックネットワーク作成が可能となったので、実際に構築 できるかの検証を行った。

使用機器

ASUS Nexus7 2013 （Cyanogenmod インストール済み）×1

acer Aspire S3 ×2

内容

PC2 台と Nexus7 でのアドホックモードでの接続の検証。

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

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

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

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

37 第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 端末で利用できるようにすれば無線ネッ トワークインターフェースのモード変更ができると考えた。

38 ・ルーティングソフト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

アーキテクチャを用いている。

39

また今回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 を採用することにし た。

40 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 を http://sven-ola.dyndns.org/repo/ から Android 端末上にダウ ンロードし、インストールする。

2.Android 端末上でイメージファイルを作成し、Debian-kit のスクリプトを使

ってDebian をインストールする。

3.自動的に Debian が起動する。その後 androidmize というパッケージと、 Debian-kit 用と Android4.3 以降の SELinux に合わせたパッケージをインスト ールする。

この流れに沿って行うことでDebian 環境の構築が可能である。ここから順に詳

しく説明する。

まず上記のURL にアクセスし、Debian-kit をダウンロードする。サイトにあ

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

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

43

図7.6 スクリプトによるイメージファイルへの Debian のインストール

Debian イメージの作成が完了すると、deb と入力するように指示がでて、入

力すると2nd ステージに自動的に移行する。この処理が終了しプロンプトが帰

44

45

次に、パッケージのリフレッシュとandromize というパッケージのインスト

ールを行った。andromize とは、Android 側に追随して/etc/resolv.conf を変更

することが可能になるものである。すでにDebian の root ログイン済状態なの

で、apt-get コマンドを利用してインストールを行った。同じように SELinux

のパッケージについてもインストールした。

46

図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 側の

47

ものをそのままマージして利用する。残り/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 のインストールを行う。この

48 ツールも先ほど使用したapt-get コマンドを使用することでインストールが可 能である。 図7.11 wireless-tools のインストール インストールしたwireless-tools で Nexus7 の無線ネットワークインターフェ ースを変更できるかを検証した。 wlan0 は Nexus7 の無線ネットワークインターフェース名である。また、 iwconfig の各項目については以下の通りであえる。 Qcom 無線LAN 規格 ESSID ESSID Nickname 無線ネットワークインターフェースのニックネーム

Mode 接続モード Ad-hoc はアドホックモード Managed はイ

ンフラストラクチャモード

Channel チャンネル

Cell BSSID

Bit Rate ビット・レート

Tx-Power 出力パワー

RTS thr RTS/CTS（Request To Send/Clear To Send）のしきい値

Fragment thr フラグメンテーションのしきい値

Encryption key 暗号化キー

表7.2 iwconfig の項目一覧

49 まりiwconfig によって無線ネットワークインターフェースのモードを変更でき たことがわかった。 図7.12 無線ネットワークインターフェース画面 7.6 ルーティングソフトの動作 次にルーティングソフトnuOLSRv2 を動作させる。まず nuOLSRv2.zip を

Nexus7 に用意する。そして Debian 側から nuOLSRv2.zip を解凍し、解凍した nuOLSRv2 の中にある nuOLSRv2d ディレクトリ内で make コマンドによりコ

ンパイルする。次にnuOLSRv2 の実行を行う。コマンドラインから nuOLSRv2d

ディレクトリ内で/nuolsrv2d nuOLSRv2d.conf と入力し、実行する。Nexus7

のDebian 側でも nuOLSRv2 を利用できることを確認した。

50

図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 アドレス Nexus7 192.168.1.1 PC1 192.168.1.2 PC2 192.168.1.3 PC3 192.168.1.4 表8.1 使用機器と IP アドレス

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

52 Nexus7 がマルチホップ通信をしていることが分かった。そこで Nexus7 の Android 側から構築したアドホックネットワークを利用できるかを確認するた めにPing 通信を利用して検証した。 Nexus7 から PC1、PC3 に Ping を送信したところきちんと送信することがで きた。これでAndroid 側からでもアドホックネットワークを利用できることが 分かった。 図8.4 Nexus7 から PC1 への Ping 送信 図8.5 Nexus7 から PC3 への Ping 送信 第9 章 方式 のまとめ

方式②は、Android に相乗りさせる形で Linux を動作させ、Linux 側でアド

ホックネットワークの構築を行うという手法をとった。その結果、アドホック ネットワーク構築に必要なモード変更のコマンドやルーティングソフトを Android で利用できるように変更を加える必要なく、Linux 側でそのまま利用 することができた。また、Android 側でも、Linux 側で構築したアドホックネ ットワークを利用することができることができ、今後Android でアドホックネ ットワークを利用するアプリケーションが開発された場合にも対応することが できると言える。