green network:providing connectivity where the internet is ...tpc/papers/green.pdf · school of...

School of Computer Science

Green Network:providing connectivity

where the Internet is restricted

presented by :

Arash Mahabadian

supervised by :

Tom Chothia

September 10, 2011

1

ACKNOWLEDGEMENTS

First of all, I would like to convey my deepest gratitude to my supervisor, Dr.Tom Chotia whose encouragement, supervision and support from the prelim-inary to the concluding level enabled me to develop an understanding of thesubject and also completing this research. His time, patience, and understand-ing is massively appreciated. My heartly thanks also go to the Department ofComputer Science of the University of Birmengham for giving me the opportu-nity of conducting such an important research whose �ndings could be greatlybene�cial for my home country, Iran.

I am also grateful to my dear friend, Donatto Capitella whose compony andkind support made this path much easier and this academic experience muchmore pleasant.

Finally, I would like to give my sincerest gratitude to my parents for thiergenerous and kind support throughout this crucial phase of my life. Withoutall these supports completing this thesis would have been impossible.

Contents

1 Introduction 71.1 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2 Aims . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.3 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 Background 102.1 Android Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.1.1 Android software stack . . . . . . . . . . . . . . . . . . . 102.2 Radio transmiters . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.2.1 3G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.2 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.3 WiFi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 System Design and Security 143.1 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2 System Structure and Protocol . . . . . . . . . . . . . . . . . . . 143.3 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.3.1 Packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.3.2 Client Protocol . . . . . . . . . . . . . . . . . . . . . . . . 153.3.3 Ad_Hoc phase . . . . . . . . . . . . . . . . . . . . . . . . 15

3.3.3.1 Possible attacks . . . . . . . . . . . . . . . . . . 173.3.4 Managed Phase . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3.4.1 Possible attacks . . . . . . . . . . . . . . . . . . 183.4 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.4.1 Registering a new user . . . . . . . . . . . . . . . . . . . . 203.4.2 Delivering user data . . . . . . . . . . . . . . . . . . . . . 203.4.3 Possible attack on the server . . . . . . . . . . . . . . . . 20

3.5 Design choices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.5.1 Wireless Technologies: Bluetooth vs WiFi . . . . . . . . . 213.5.2 Transport Protocols: UDP vs TCP . . . . . . . . . . . . . 213.5.3 IP allocation mechanism . . . . . . . . . . . . . . . . . . 22

2

CONTENTS 3

4 Case Study : Sending Tweets 244.1 Twitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.1.1 Twitter API . . . . . . . . . . . . . . . . . . . . . . . . . . 244.1.1.1 OAuth . . . . . . . . . . . . . . . . . . . . . . . 254.1.1.2 Protocol work�ow . . . . . . . . . . . . . . . . . 25

4.2 System components . . . . . . . . . . . . . . . . . . . . . . . . . 264.2.1 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.2.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5 Evaluation and Testing 375.1 Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.1.1 Hardware Speci�cations . . . . . . . . . . . . . . . . . . . 375.1.2 General Development Platform . . . . . . . . . . . . . . . 37

5.2 Delivery Rate Probability . . . . . . . . . . . . . . . . . . . . . . 385.3 Performance Test . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.4 Battery Consumption Test . . . . . . . . . . . . . . . . . . . . . . 405.5 Simulator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.5.1 General characteristics and requirements of simulation stud-ies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.5.2 Available MANET simulators . . . . . . . . . . . . . . . . 425.5.3 Shadow simulator . . . . . . . . . . . . . . . . . . . . . . 435.5.4 Map and Node Manager . . . . . . . . . . . . . . . . . . . 43

5.5.4.1 Markovian Random Walk . . . . . . . . . . . . . 435.5.5 Protocol Manager . . . . . . . . . . . . . . . . . . . . . . 455.5.6 Reporter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.5.7 Simulation Results . . . . . . . . . . . . . . . . . . . . . . 46

5.5.7.1 Delivery rate . . . . . . . . . . . . . . . . . . . 465.5.7.2 Maximum memory usage for bridges . . . . . . . 485.5.7.3 Rate of message spreading . . . . . . . . . . . . 485.5.7.4 Rate of lost messages . . . . . . . . . . . . . . . 48

6 Conclusion and future work 506.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.2.1 Filtering issues . . . . . . . . . . . . . . . . . . . . . . . . 516.2.2 Simulation Improvement . . . . . . . . . . . . . . . . . . . 51

A Android ad-hoc con�guration 55A.1 General Steps to change Interface to ad-hoc for HTC Hero mobile

phones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56A.1.1 General Steps to change Interface to ad-hoc for HTC De-

sire mobile phones . . . . . . . . . . . . . . . . . . . . . . 56A.1.2 The results of the tests . . . . . . . . . . . . . . . . . . . . 57

CONTENTS 4

B Installation and con�guration of Green Shadow 58B.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58B.2 How to Send a tweet . . . . . . . . . . . . . . . . . . . . . . . . . 58

List of Figures

2.1 Android mascot. . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2 Android operation system software stack(taken from wikipedia) 112.3 Managed mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4 Adhoc-mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1 The protocol used in Managed mode . . . . . . . . . . . . . . . . 18

4.1 OAuth work�ow . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.2 General view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.3 blob Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.4 Forwarding process . . . . . . . . . . . . . . . . . . . . . . . . . . 284.5 Receiving process . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.6 Data base diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 344.7 Twitter authorisation . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.1 Test mobile phones . . . . . . . . . . . . . . . . . . . . . . . . . . 385.2 probabilistic evaluation of the protocol . . . . . . . . . . . . . . . 385.3 Map of the test area(taken from google map) . . . . . . . . . . . 395.4 Battery consumption chart . . . . . . . . . . . . . . . . . . . . . 415.5 Markov chain and probability matrix of Markovian random walk

mobility model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.6 Mobile node's movement pattern using Markovian random walk

model[15] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.7 Comparision of Delivery Rate . . . . . . . . . . . . . . . . . . . . 475.8 Comparison of maximum memory usage by bridges . . . . . . . . 485.9 Comparision of message spreading . . . . . . . . . . . . . . . . . 495.10 Rate of Lost Messages caused by Bye Attack . . . . . . . . . . . 49

A.1 Minimal script to change HTC Hero to ad-hoc mode . . 56A.2 Minimal script to switch HTC Desire to ad-hoc mode . . 56

B.1 Green Shadow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5

List of Algorithms

4.1 Network Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.2 IP Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.3 Forward Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.4 Forwarder Helper . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.5 Receiver Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.6 Receiver Helper . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6

Chapter 1

Introduction

1.1 Motivations

This research attempts to investigate the possibility of creating an independentdecentralized network for network-capable mobile devices, particularly mobilephones that provides connectivity in areas where the internet is blocked. Thisindependent network is meant to give the opportunity to its users to report newsto the outside world. The main motivation for conducting this research is thelack of such a network in those countries where internet blockade and trackingusers have been common in the past recent years.

In year 2009, tweeter again played a crucial role in the post-election turmoilin Iran. Internet, including tweeter, facebook, opposition websties and blogswere all shut down by the state after acccouncing the result of the presidentialelection in order to avoide leaking any information from the opposition side. De-spite of all suppressions imposed on protestors by the state agents, �ltering thenews and information in the national media and blocking internert connectionsin major cities of Iran, ciziten journalists who were actually ordinary protesterswithout any professional background in computer science or journalism, madea sigi�nicant contribution in updating news and videos of demonstrations ontheir blogs, tweeters, facebook and youtube channells. It was through thesesocial networks that the most powerful and in�uential media around the world,including CNN, BBC and Aljazeera could cover the scenes and news relating tothis turmoil1. After a short period of time, Internet blockade and prosecution ofthe uploders became one of the main targets of the current regime in Iran. Theymade special arrangements for �ltering and hacking into the opposition websiteswhich lead to the widespread arressts of the Internet users and supression of theGreen movement.

On another account, in 2011, Egyptians' use of twitter and Facebook madea signi�cant e�ect on the government's crack down. According to the availableaccounts and in contrast to the case of Iran �the act of censorship of internet was

1http://www.washingtontimes.com/news/2009/jun/16/irans-twitter-revolution/

7

CHAPTER 1. INTRODUCTION 8

spectacularly unsuccessful�2 in Egypt. The successful experience of Egyptianrevolution and the role of internet in orgazing demonstrations in this country onone hand, and the constant internet blockade in Iran which left a huge e�ect inthe failure of the Green movement on the other, imply that totalitarian govern-ments could be heavily challeneged by the use of internet and the opportunitesit dedicates to its users in crucial moments.

However, in the past recent years, totalitarian regimes have begun to realizethe importance of the virtual social networks and the way they could problema-tize their legitimacy. The current state in Iran, for instance, has organized ateam of computer science experts and hackers, called Cyber Army of the IslamicRepublic of Iran in order to block, censor and report opposition news websitesand identify uploaders and users who have been active since the post-electionturmoil3. The main reason for identi�cation and detention of a large numberof these users was the lack of an independent netwrok that provides them witha secure and anonymous connection at the time of uploading. Invesgating thepossibility of developing such an independent network is the focous point of thisresearch.

1.2 Aims

This project attempts to investigate the possibility of creating an independentdecentralized network for mobile phones, more generaly, network-capable mo-bile devices, that provides connectivity in areas where the internet is blockedand to give the opportunity to its users to report news to the outside world.

In particular, these are the main aims of this research:

• To investigate the more suitable radio transmitter technology available inmobile phones for our purposes.

• To design a protocol for transmitting messages between mobile phones.

• To implement a working prototype of the protocol for a real-life case study(for example, twitter)

• To �nd a way to evaluate the prototype properties in larg scale scenar-ios(for example by simulation).

1.3 Structure

The rest of this research is structured as follows:Chapter 1 - Background In this chapter, the areas that are the founda-

tions of this research will be brie�y introduced. First of all, Android platform

2http://www.bbc.co.uk/news/world-middle-east-124003193http://www.pbs.org/wgbh/pages/frontline/tehranbureau/2010/02/pulling-the-strings-

of-the-net-irans-cyber-army.html

CHAPTER 1. INTRODUCTION 9

will be explaind and then we explore available radio transmitters in mobilephones.

Chapter 2 - Design and Security This chapter describes the architectureof the system and the protocol we propose to build a decentralised network.After presenting the protocol, some possible attacks on di�erent componentsof our architecture will be dicussed. Finally, we explore some possible designalternatives and elaborate on the selected choice of this project.

Chapter 3 - Case Study:Twitter This chapter discusses the implemen-tation details of a case study: Green Shadow, a system to post tweets in zoneswhere the Internet has been restricted. We show the system architecture andanalyse the implementation details of each software component. We also o�er anoverview of the implementation issues that were faced during the development.

Chapter 4 - Evaluation of the Prototype In this chapter we try to eval-uate the system in terms of performance and energy consumption. In order toevaluate the performance of the prototype for large-scale scenarios, we designedand implemented a simulator. We also document how we improved the initialperformances.

Chapter 5 - Conclusion and Future Work In this chapter we o�er asummary of the main �ndings of the project. Moreover, we explore some openissues and propose some possible solutions that could be implemented in thefuture.

Appendix A - Android ad-hoc con�guration This chapter deals withthe neccessary steps to switch into ad-hoc mode in two di�erent types of Androidmobile phone as we found this work challenging due to the lack of availabledocumentation.

Appendix B - Green Shadow Installation This chapter deals with therequired steps to install and run Green Shadow on Android mobile phones indetails.

Chapter 2

Background

2.1 Android Platform

Android (referred to as Android) is a new operating system for mobile phones,but is also moving towards tablet PCs and netbooks. It is developed by theOpen Handset Alliance led by Google.

Android is built on top of a solid and proven foundation: the Linux kernel.It is Created by Linus Torvalds in 1991. The Android platform is providedthrough GNU General Public License Version 2 (GPLv2) which means anythird-party improvements must continue to fall under the open source licensingagreement terms. The Android framework is distributed under the ApacheSoftware License (ASL/Apache2), which allows the distribution of both closedand open source derivations of the source code.

Android operating system consists of di�erent layers which can be seen in2.2

2.1.1 Android software stack

The lowest layer is a heavily modi�ed GNU/Linux kernel version 2.6 for han-dling core system infrastructure services such as process managment, memorymanagement, security, network stack. Moreover, the radio drivers are in thekernel, which must be recon�gure to establish an ad-hoc network.

Figure 2.1: Android mascot.

10

CHAPTER 2. BACKGROUND 11

Figure 2.2: Android operation system software stack(taken from wikipedia)

Above the kernel, there are two layers, the libraries and the Android Run-time. The former consists of a collection of c and c++ libraries that get datafrom the application framework layer, and passes it to the the kernel. Throughthe application framework developers can exploit the full capabilities of them.Android Runtime composed of two major parts: a virtual machine called Dalvikand a group of core libraries.

Dalvik virtual machine is one of the most important components in android.It is developed by Dan Bornstein and named after the Dalvik village in Iceland.The Dalvik VM is highly CPU optimized interpreter and capable to run multiplevirtual machines also it is optimised for low memory requirements. By havingmultiple virtual machines, it is possible for each application to run on its ownvirtual machine, thus increasing safety. The Dalvik VM relies on the underlyinglayer to handle process isolation, memory management and threads.

Android's core libraries provide most of the functionality available in thecore libraries of Java needed for applications development (�le access, I/O func-tionalitues,etc.).

On top of these two layers is the framework layer that is the layer betweenthe applications and the libraries, this layer is there to making it easier for thedevelopers by o�ering a higher level of abstraction than the c and c++ libraries.

On the top level is the applications, which is witten in Java, The compiledapplication is binded by the aapt tool into an Android package .apk . Basically,each android application is a single linux process and has its own VM instance.


2.2 Radio transmiters

To implement and use an Ad-Hoc network a radio transmiter and recevier isrequired. In most of the Android devices, three options are available: 3G,Bluetooth and Wi�. Each of them has its own advantages and disadvantages.

2.2.1 3G

3G is a technology for mobile service providers. The 3G antenna is used forsending and receiving data over a great distance by using the infrastructureprovided by the phone operators. It can support data rates from 384 kbps up to2 Mbps[4]. However, this option is not intended for direct connection betweentwo mobile phones and thus cannot be used to build an ad-hoc network.

2.2.2 Bluetooth

Blutooth is a standard wire-replacement communications protocol developedby Ericson in 1994 intended for creating small scale ad-hoc networks. EachBluetooth device can act as a master or slave node: a master and up to sevenslave nodes can form a network called piconet. The slaves in a piconet onlycommunicate with the master. If a bigger network is required, a �scatter � netcan be formed by linking two or more piconets. In this network a node can bea slave in one piconet and a master in another one but not at the same time[5].This property, together with short radio range, makes this option inapropriatefor very large and dynamic networks. Generally, in terms of distance range,bluetooth devices are devided into three classes:

• Class 3 radios � have a range of up to 1 meter or 3 feet

• Class 2 radios � most commonly found in mobile devices � have a rangeof 10 meters or 33 feet

• Class 1 radios � used primarily in industrial use cases � have a range of100 meters or 300 feet

The nominal rate of Bluetooth ranges from 1Mbit/s to about 3 Mbit/s.

2.2.3 WiFi

One of the mainstream WiFi standards that has been adopted in Android de-vices is IEEE 802.11g. This standard transmits on the 2.4 GHz band and cantransmit up to 54 Mbit/s. The IEEE 802.11g supports two operational archi-tectures: managed �gure 2.3 and ad-hoc �gure 2.4.

The former is a centralised architecture where stations connect to an accesspoint to get the desired network services. On the other hand, ad-hoc is adecentralised architecture that allows the nodes to communicate directly withother devices in range without the need of a central station.


Figure 2.3: Managed mode

Figure 2.4: Adhoc-mode

The nodes can communicate in one of the following modalities: unicast,multicast or broadcast. In the unicast mode, each network frame has a singlereceiver; in the multicast mode the sender can specify a group of receivers.Finally, in broadcast mode a network packet is delivered to all the nodes withinthe range of the sending device. A WiFi antenna transmits the message in alldirections, with a range from 25m (inside) to 300m (outside)[9]. Although thisoption seems the best choice, the Android API does not support ad-hoc modeout of the box.

Technology Distance Range Data Range Support Ad-Hoc Support Managed Android API For Ad-hoc

3G Not Available 380kbps-2Mbps No Yes Not Available

Bluetooth 5m-10m 1Mbps-3Mbps Yes No Available

Wi� 100m-300m up to 54Mbps Yes Yes Not Available

Table 2.1: Comparision of transmissions technologies available in mo-bile phones

Chapter 3

System Design and Security

This chapter describes the system and design of the protocol wehave devised for our system and explores its security aspects.

3.1 Scenario

Our scenario consists of two main element: mobile nodes and central server.The former can act as a regular node which is a node that has not access to theInternet and wish to send messages on the Internet or a Bridge which is a nodewhich potentialy has access to the Internet in the next 24 hours. For exampletravellers which physically leave the restricted zone or embassy employees whichhave uncensored access to the Internet.

The bridges do not contact to the destination but they transfer the messagesto the central server which is located outside of the restriced area. The centralserver is responsible of managing duplicated messages as well as contacting tothe �nal destination.

3.2 System Structure and Protocol

The shadow network architucter consists of two parts: (1) a client which isused by mobile nodes to send data(blobs) to either other mobile nodes or, ifthey have internet access, to the server and (2) a server which is responsible forposting received data to Twitter as well as managing duplicated packets. In thefollowing subsection we analyse the details of both of them.

3.3 Client

The client component used by mobile phones is intended to receive data fromother nodes or its users, store and send data securely either through the internetto the destination web site or using adhoc network to other nodes which might

14

CHAPTER 3. SYSTEM DESIGN AND SECURITY 15

have access to the Internet. First We strat de�ning required packets then welook at the details of the protocols.

3.3.1 Packets

This section deals with the design of the packets in our protocol. Particularcare has been put in minimising the number and the size of the packets to savethe energy and bandwith of the mobile phones.

In the communication protocol the following packets are used:Hello_Packet is a packet which is used to start a run of the protocol

and announce to the neigboures about a blob which is ready to be shared. Itconsists of the MD5 of the blob(16 bytes), the number of data packets of theblob(1 byte), a unique ID(4 bytes) and TTL(1 byte). Thus the total size of thepacket is 22 bytes.

Hello_Reply_Packet is a packet which is used to response to a hello toshow intrest in the blob. It solely consists of the ID from hello packet.(4 bytes)

Data_Packet is a packet used to send the actual blob, it consists of theID(4 bytes), the sequence number of the data packet(1 byte) and the data itself(each blob can have from 1 to 5 data packets).

Request_Packet is a packet which is used by a receiver to ask for re-transmission of a lost packet, it consists of the ID (4 bytes) and the sequencenumber(1 byte) of the data packet.

Bye_Packet is a packet which the receiver of a blob sends to the senderto show the data has been completely received. It consists of the ID(4 bytes).

3.3.2 Client Protocol

Notations

Table 3.1 shows the notations used in the client protocol.The protocol used in the client architecture consists of two phases :

• Ad_Hoc phaseIn this phase the phone is in Ad-Hoc Mode and communicates with otherstations in the network for a pre-determined time, adhoc_mode_timespan(table 3.1).

• Managed phaseIn this phase the device is in Managed Mode. If the internet connectionis available, the client contacts the server and sends all the available blobsto it in managed_mode_timespan(table 3.1). Otherwise, it switches backto the Ad-Hoc phase.

In the following sections we describe the details of each phase.

3.3.3 Ad_Hoc phase

Here we present one run of the protocol to transfer a blob from one node to oneor more nodes in the network.


Notation Description

blobIt is a unit of data which is encrypted

and transmitted by the mobile phones

adhoc_mode_timespanThe time span which the clinet spends

in adhoc mode and transmits and receives blobs

managed_mod_timespanThe time span which the client spends in managed

mode and send blobs to the server through the internet

max _keeping _timespanThe time span for which each node keeps a copy

of the received blob's MD5s to check the duplications

forwarding queueThe queue of the forwardable blobs1

final queueThe queue of the non-forwardable blobs2

listening_timespanThe time span for which the client waits

and listens for a response from other nodes

max _no _forwardsThe number of times each blob has to

be forwarded by a node before being deleted

TTLThe number of hops a blob can still traverse

max _no _TTLThe maximum number of hops each

blob can travers before being discarded

AliceA client who plays the sender role

Boba client who might have access to the internet

hash_listThe list of MD5s of the blobs

received during max_keeping_timespan

volunteerA node willing to accept a blob

max _try _t o_connectthe maximum number of times

a client try to connect to the internet

forwarding_ The amount of time the sender

safe_delay_ts must wait after forwarding a blob again

Table 3.1: Notation used in client architucter protocol


1. Alice(table 3.1) selects a blob from forwarding queue(table 3.1).

2. Alice generates a hello packet and broadcasts it to �nd new receivers. Shelistens for listening_timespan(table 3.1) to receive hello replys.

3. The nodes which receive the hello packet will check their hash lists(table 3.1)to see if they already have this blob or not. If they do not, they will senda Hello Reply packet to Alice to show they are interestd in this blob.

4. After listening_timespan has expired, Alice will lock the blob which meansshe will discard any further hello reply packets related to this blob. Atthis point, if there is any volunteer(table 3.1), Alice will multicast the blobwith some precautions we will discuss later.

5. Each device which has received the packets completely sends a bye packetto the sender to con�rm it the successful reception of the packet. Afterthat, the receivers will decrease the TTL(table 3.1). If TTL becomes zerothe node will move the blob to the �nal queue(table 3.1).

6. When Alice receives a bye packet, she will decrease the number of forwardsby one for each received bye packet. If this number becomes zero she willdelete the blob.

7. Alice repeats these steps for another blob until no blobs remain in thequeue or adhoc_mode_timespan �nishes.

In case of lost packet, the receiving node can send a request packet to ask forretransmition of a particular sequence number of the blob within 1 seccond afterreceiving hello packet.

3.3.3.1 Possible attacks

The TTL number can be used to �nger print the sender. If the attacker isrunning a corrupted node and he sees a packet with a maximum TTL he knowsthe packet was orginated by the sender and not by someone else. At this pointif he can monitor, the tra�c in and out of the server he can wait until there isno activity and then send the blob. Of course the output of the server will bethe message from the node and if it is not encrypted the attacker will be ableto link the node to the message or if it is encrypted he can link the sender tothe destination web site. The current implementation of the protocol defeatsthis attack by adding a randomness to decreasing mechanism of TTL. when theTTL has got the maximum value the node that forwards it will decreas it with25% of probability.

There is also a possible denial of service attack which we call it bye attack .The adversary after receiving a hello packet can generate several Hello replypackets with di�erent IP addresses followed by several bye packets to fool thesender, and it will make the sender to decrease the left forward number to zeroand consequently delete the blob. This issue is solved by the current implemen-tation in the following way. The sender will forward the blob normally if the


1 i f ( there_is_blob_to_send ) {2 switch_to (Managed_mod ) ;3 f o r (max_try_to_connect ) {4 connect_to_internet ( ) ;5 i f ( connec t i on_es tab l i shed )6 break ;7 }8 whi l e ( connec t i on_ava i l ab l e9 AND managed_mode_timespan not e lapsed10 AND we_have_blob ){11 blob = get_Blob ( ) ;12 send_to_server ( blob ) ;13 i f ( succeed ) d e l e t e ( blob ) ;14 }15 }

Figure 3.1: The protocol used in Managed mode

number of left forwards is more than 25% of the maximum forward number thathas been con�gured. If not, the sender will check the time when the packet waslast forwarded and, if it is more than 1 hour, it will forward the blob. Other-wise, it will just ignore the request. So, in case the maximum forward numberis 6 and the left forwards for the blob is greater than 2, then the sender willforward the blob normally. If the left forwards is less or equal to 2, the senderwill not forward the blob unless 1 hour has elasped since the last forward. Inthis case the adversary must follow the sender for at least three hours to launcha successfull attack.

3.3.4 Managed Phase

Here we present one run of the protocol for the managed phase (�gure 3.1):

1. If there is any blob to send to the server, the client switches to Managedmode.

2. If the connection is available, the client table 3.1 goes to the next step, oth-erwise it switches back to the Ad-Hoc phase aftermax_try_to_connect(table 3.1)failures to connect.

3. It contacts to the server and sends it all the blobs in the blob's and �nalqueues. If the procedure is successful, it deletes the blobs from the queues.

4. The client switches back to Ad-Hoc mode either if there is no blob to sendor the managed_mode_timespan �nishes.

3.3.4.1 Possible attacks

As the clients(bridges) need to connect to the server to send blobs, if the ad-versary controls the ISP, it could be able to lunch two types of DOS attacks.


The �rst is a Man In the Middle attack where the adversary impersonates theserver; in the second kind of attack the adversary bans the server by IP blockingor URL blocking. Needless to say, these attacks are not appliable to most of thebridges since they are users which either physically move from the area wherethe attacker controls the Internet (travallers , �ight assistants, etc...) or theyhave direct access to an internet connection without censoring and blocking (ie.embassy employees).

By lunching MMA, the attacker can actually fool the clients into sendingblobs to the attacker instead of the server. Although the attacker cannot readthe blobs as all of them are encrypted, it can stop the server from receivingthem. To defend against this attack the clients should use HTTPS to connectto the server and the web server must be con�gured to support secure channels.Moreover, the server must have a signed certi�cate from a trusted CA.

The second attack needs more e�ort to be defeated. In our prototype wehave implement propose one approach which can mitigate the consequences ofthis attack: using Tor to make the connection �ltering hard.

Using Tor with Tor bridges Tor was originally designed, implemented, anddeployed as a third-generation onion routing project of the U.S. Naval ResearchLaboratory. It is a network of virtual tunnels that allows people and groups toimprove their security and privacy on the Internet.

Tor Bridge is a step forward in the blocking resistance race. They are similarto regular Tor relays but they aren not listed in the main Tor directory. Sincethere is no complete public list of them, even if ISPs try to �lter connections toall the known Tor relays, they will not be able to block all the bridges.

To use a bridge, we need to locate one. To do so, we can visit a dedicatedURL 3 with a browser. If the page is �ltered, a public bridge addresses can befound by sending an email to [email protected] with the line get bridgesby itself in the body and title of the mail. The email must be sent with a gmailaccount, though (otherwise it will be too easy for an attacker to make a lot ofemail addresses and learn about all the bridges). Almost instantly, The Torbridge relays will be receive through a reply[3].

In a worst case scenario, if the URL and email address are blocked a list ofbridges can be obtained by phoning someone outside the restricted zone.

Main �uxing adopted from BotNets

3.4 Server

The server is intended to deliver clients blobs to a particular destination speci�edby the users and it also has to recognise duplicated packets that are likely tooccurr because of the routing protocol adopted. To do so, it is necassary for theserver to be able to authenticate users.

3https://bridges.torproject.org/


As a consequence, the server responsibility is divided into two parts:

• Registering a new user;

• Receiving and posting user blobs to a destination web site in a secure way.

3.4.1 Registering a new user

The shodow network uses a simple protocol to register a new user. The protocolconsists of the following steps:

1. Get user information: username, password, email address

2. Ask for the destination website (eg. twitter).

3. Redirect the user to the website to get explicit permission and obtain writeaccess to the user's pro�le (the steps for getting permission from a website can be di�erent for each website supported).

4. Store user information and the website permission information (accesstoken and access token secret) into the database.

3.4.2 Delivering user data

Here we present one run of the protocol to deliver user data to a website whena new blob is received by the server.

1. Check if the blob is a new blob. If so, decrypt the blob, otherwise discardit.

2. Store MD5 of the blob to the database (to be able to recognise subsequentduplicates).

3. Authencticate the user with username and password embedded in theblob. If the credentials are invalid, delete the data and terminate.

4. Fetch website access information according to the username and websitename provided.

5. Send user data to the destination by using the website access information.

3.4.3 Possible attack on the server

The attacks on the server are the genaral attacks that can be lunched againstany kind of server. For examle, the adversary could overload the server witha high number of requests to lunch a DoS attack. This kind of attacks canbe mitigated at the network and system administration levels. So we do notconsider this attack as a threat to this system.


3.5 Design choices

This section deals with the design choices and alternatives we considered. Herewe present them and we dicsuss in detail why we have made these particularchoices.

3.5.1 Wireless Technologies: Bluetooth vs WiFi

Bluetooth and Wi-Fi (IEEE 802.11g) are the two main wireless technologiesavailable to today's mobiles phone. The Android platform supports, with somelimitations, both of them. Another widespread technology is 3G but we did notconsider it as an option since it relies on an existing infrastructure and is notsuitable for creating independent ad-hoc networks[9].

As already mentioned in ??, Bluetooth is suitable for ad-hoc networking withlow energy consumption requirements. One disadvantage of this technology isthat, in order to build a real ad-hoc network, each node needs to act both asa slave and a master at the same time. This requires the introduction of someconcurrency level to the code in the form of at least two threads, one that acts asa slave and one that acts as a master. However, a node can only be connected toa master at a time, so this makes the implementation of a true ad-hoc networkvery challenging.

A further disadvantage of Bluetooth is the short distance range permittedand the low data rate. Broadcasting is another issue: from the speci�cationsof the Bluetooth protocol stack, it is not clear how to broadcast messages di-rectly. Moreover, the transport level protocol available in the Android platform,RFCOMM[7], is connection-oriented and this makes broadcasting to neighboursimpossible. We consider this last issue a major drawback which makes this op-tion useless for our work.

On the other hand, as explained in ??, Wi-Fi o�ers a longer communicationrange as well as a larger bandwidth (as a consequence, though, it consumesmore battery power). Another advantage over Bluetooth is that it also allowsbroadcasting as we can use UDP on top of it. For these reasons, we chose WiFias our physical layer.

3.5.2 Transport Protocols: UDP vs TCP

As far as the transport layer is concerned, the most commonly used protocolsare UDP and TCP, both supported by the Android platform. The former is con-nectionless protocol which is used to send and receive datagrams. The datagramsize can be up to 64 kbytes. This protocol does not give any guarantee neitheron the delivery of the packets nor the orders of them. The only guarantee UDPprotocol o�ers is the checksum of the packet. The main advantages of UDPover the TCP are that (1) it supports a primitive way of broadcasting packets,(2) it has a lighter packet format and (3) it does not require the overhead of aconnection.


TCP, Transmission Control Protocol, is a connection-oriented protocol con-sisting of 3 phases: establishing the connection via a 3-way handshake, trasmit-ting data and closing the connection. TCP o�ers reliable transmission: thismeans that it gives guarantees on the delivery and order of the packets and alsoensures that lost data is retransmitted. However, TCP is not suitable for ourpurposes, as it does not support broadcasting and it also has ae larger overheadthan UDP.

Both of the protocols follow the client and server model, which means thatto create a real ad-hoc network, each node has to have at least two threads tobe able to send and receive data concurently.

3.5.3 IP allocation mechanism

Address con�guration is an essential phase before nodes in a network cna startto communicate. For the networks with a central server, this issue is dealt witheasily by the introduction of Dynamic Host Con�guration Protocol (DHCP).

DHCP is the �rst mechanism proposed for dynamically assigning IP addresses[10].It is based on a client/server architecture where a central entity, the DHCPserver, is responsible for assigning IPs to requesting nodes and for maintainingthe state for each address of the available address range: thus address du-plication is totally avoided. When a new node starts and has no IP addresscon�gured, it broadcasts a message to discover if a DHCP server is present. If aDHCP exists, it replies to inform the new node (DHCP client) of its presence.Then the DHCP client requests directly the DHCP server for an IP address,the DHCP server picks a free IP out of its pool and sends it to the client whocon�rms its reception of the o�er.

A DHCP infrastructure is not suitable in case of dynamic networks likeadhoc networks where centralizing the address con�guration is not feasible. ForAd Hoc networks, as there is no central node, each node must be capable toautocon�gure itself.

In general, any address autocon�guration mechanism should consider thefollowing issues [7]:

• Topology change: ad hoc nodes are mobile and could join and leave thenetwork at any moment without noti�cation. This dynamism of networktopology should be considered when designing an autocon�guration mech-anism.

• Network partitioning and merging: during its lifetime, an ad hoc networkcould be divided in two or more disconnected networks. These partitionsor other mobile networks could remerge later. The autocon�guration pro-tocol should be able to deal with these situations and the resulting addresscon�icts or address leaks.

As an example of autocon�guraiton protocols, we can mention zero conf proto-col. In this protocol, when a node joins the network, it randomly chooses an IPaddress and sends an ARP message destinated to the chosen address. If the IP


address is already used, the new node will receive a message indicating there isa node which use this address, then it chooses another address and restarts theprocedure. If the new node receives nothing, it concludes that the IP is free andso it can use it. However in wireless networks the broadcast ARP message mustbe also broadcasted by all the neigbors because there might be hidden stations.

In our case neither approach is not suitable. DHCP is too centralized forsuch a dynamic environment and each node in the network must switch betweenDHCP server and client to be able to communicate with other stations. More-over, zero conf is assumed to be too much energy-consuming and error-prone.

Our light-weight solution

As all of the available autocon�guration mechanisms are too much energy andbandwidth consuming and we are not intrested in routing packet to a speci�c IPadress in this network, we decided to use a very light autocon�guration systemwhich does not try to detect and solve con�icts, but just assumes that con�ictsare very unlikely to happen:

• each node uses a psudo random number generator seeded by its MACaddress to randomly choose an IP from 10.0.0.0/24;

• uses it for prede�ned timespan and when this timespan expires it generatesa new IP address.

As the address space is very large (224) and the number of nodes that havedirect access to each other is fairly small, we can ignore the probability of thecon�ict. In the worse case scenario, if the con�ict happens, after the predi�nedtime, the two nodes will choose di�erent IP addresses (as their random numbergenerators are seeded with di�erent MACs) and they can start communicatingagain. Moreover, if there is another node close to them, the direct communi-cation is not necessary at all, since the third station could act as a bridge totransfer the blobs.

Chapter 4

Case Study : Sending Tweets

This chapter discusses the implementation details of a case study of the Shadownetwork. The aim is to use the network to send messages(tweets) to Twitter.We start this chapter with a brief explantion about Twitter and the ways theTwitter API allows us to communicate.

4.1 Twitter

Twitter is an online social networking and microblogging service which is some-times described as �the SMS of the Internet�. It was designed to let users answerthe question �What are you doing?�. Users have up to 140 characters for eachposting to say whatever they wish. The posts are informally known as tweets.

Twitter was created and lunched in 2006 by Jack Dorsey. It is one of themost popular social networking websites, with 200 million users as of 2011,generating over 200 million tweets and handling over 1.6 billion search queriesper day[11].

4.1.1 Twitter API

To use the Twitter API, the �rst step to take is to register a client application.Each client application will be provided a consumer key and secret. This keyand secret scheme is similar to the public and private key scheme and will beused to sign the requests for the API. It is through this signing proccess thattwitter will be capable to identify the application.

In the next step the user (who has an account on twitter) must authorizethe application to have access to his/her con�dential data as well as specifythe access level of the apllication to it. To do this the user must be authenti-cated through one of the authentication processes o�ered by the Twitter API.Basically, there are two main types of the authenctication processes: XAuth andOAuth. The former is similar to basic authentication proccess(username/password)

24

CHAPTER 4. CASE STUDY : SENDING TWEETS 25

which needs explicit permission from Twitter to be used. We are not going toexplore the details of XAuth as we are not going to use it.

In the following subsection we will analyse OAuth.

4.1.1.1 OAuth

Many luxury cars come with two di�erent keys. (1)Valet key which is a specialkey you give the parking attendant and it allows the car to be driven for a shortdistance while restrict access to the trunk and the onboard phone. (2) Regularkey, which is used to unlock everything else. The idea of giving limited accessto the car is very clever and can be used in virtual worlds as well.

As the web grows, more and more sites rely on distributed services: a socialnetwork using your Google address book to look for friends, or a third-partyapplication utilizing APIs from multiple services.

The problem is, in order for these applications to access user data on othersites, they ask for usernames and passwords. It means these applications willhave unlimited access to act as they wish. They can do anything, includingchanging the password and lock the user out. Moreover, people often set thesame password to use with di�erent websites (online banking).

OAuth provides a method for users to grant a third-party access to theirresources without sharing their passwords. It also provides a way to grantlimited access (in scope, duration, etc.).

For example, a web user (resource owner) can grant a printing service (client)access to her private photos stored at a social networking site (server), withoutsharing her username and password with the printing service. Instead, the userauthenticates directly with the social networking site which issues the printingservice delegation-speci�c credentials.

In the basic client-server authentication model, a client uses its creden-tials(username and password) to access its data hosted in the server. OAuthadds a third role to this model: the resource owner (for example a user of twit-ter). In the OAuth model, a third party client requests access to the resources(eg. private photos) controlled by the resourse owner, hosted by the server (eg.twitter).

4.1.1.2 Protocol work�ow

Figure (4.1) illustrates the steps of open authenticatin. The �rst step to au-thenticate a user is to obtain a request token from Twitter. This step servestwo purposes: �rst, to tell Twitter what you are about to do. Second, to tellTwitter what you want to do for the OAuth callback.

When a client added support for the particular server(twitter), it obtained aset of client's credentials (consumer key and secret) to be used with the servers.The client uses its credentials to sign a request to get temporary credentials.

Then temporary credentials are used to redirect the resource owner(twitter'suser) to the server for granting the necessary permissions, after the user suc-cessfully logged in to the server(twitter). Once approval has been granted, the


Figure 4.1: OAuth work�ow

server redirects the user back to the client's callback address. Finally, the clientcan send a request with authorized request token to get access credentials(accesstoken, access token secret). These credentials can be stored and used to accessto the server as long as the resource owner has not revoked them.

4.2 System components

Figure (4.2) illustrates the general architecture of the proposed system with allits main components. The following sections will deal in details with every ofthese components.

4.2.1 Client

As far as the client side is concerned, the system can be divided into the followingmodules:

Blob generator It is a class whose job is to receive user data (username,password and tweet) and generate a blob. A blob(�gure 4.3) consists of threeparts. The �rst part is an initialisation vector of 16 bytes needed by CipherBlock Chaining mode.


Figure 4.2: General view

The seccond part(key part) is a 256 bytes block containing a newly generatedAES key(128 bits) encrypted with the server's RSA public key(2048 bits).

The third and �nal part(data part) is a block encrypted with the AES keycontaining the username(4 to 10 character) and password(4 to 10 characters)to connect to the server together with the tweet message(up to 140 characters)and the current date(8 bytes).

As the message can be delivered with considereable delay the date is pub-lished with the message to indicate the actual sending date. The size of thedata part can vary up to 168 bytes. As we use padding the size of the encrypteddata part will be up to 180 bytes. Therfore, the maximum size of the blob canbe 452 bytes.

These are the steps followed by the blob generator:

1. receives user data.

2. generates an initialise vector used in cipher block chaining mode.

3. generates a session AES key.

4. encrypts data with the session key using IV in CBC mode with padding.

5. encrypts the session key with server's RSA public key.

6. write IV|encrypted key|encrypted data as an output.

.

Memory Manager It is a static class used by other classes to have readand write access to the shared variables used by di�erent threads. Indeed,all concurrency issues related to shared memory are dealt with in this class.Moreover, this class manages the persistence layer of the application (read andwrite to/from disk).


IV = initial vector used by CBC D = Date of writing the tweet

Ek(x)= x enrypted with the key : k U = User name

pk = Server's RSA public key P = Password

key = a fresh AES symmetric key T = Tweet

Figure 4.3: blob Structure

Figure 4.4: Forwarding process

Network Manager It is the main thread of the application whose job isto switch between adhoc and managed mode according to the timers and theavailability of the blobs. Algorithm 4.1shows details of network manager. Theprocedure consists of two parts:

• a part that runs in adhoc modeIn this part, after the network interface is set to adhoc mode, networkmanager will start three threads which are neccessary for intercommuni-cation between mobile phones (IP Manager, Forward Manager, ReceiveManager). It stays in this mode for a prede�ned time, adhoc_mod_ts.During this time mobile phones can send and receive blobs using WiFi.

• a part that runs in managed modeIf there is any blob to be sent to Twitter, �rst the manager stops thethreads used in adhoc mode. Then, it starts managed mode by recon-�guring the network interface. It continues by trying to connect to theinternet. If the connection is established, blobs will be sent to the serverthat will eventually decrypt and forward them to Twitter (of course, eachblob will be deleted after having been forwarded to the server).

IP Manager Thread It is a thread whose job is to set a newly generatedIP address each time the ip_manager_ts timer expires. The IP generator algo-rithm uses the MAC address as a seed to generate random numbers. Algorithm4.2 illustrates the details of IP Manager.

Forwarder Manager Thread Figure 4.4 illustrates the general architectureof the forwarding proccess. Forwarder Manager is a thread whose job is to


Algorithm 4.1 Network Manager

1 whi l e ( appl icat ion_not_terminated ) {23 switch_to (ad_hoc_mod) ;4 s t a r t ( ip_manager ) ;5 s t a r t ( forward_manager ) ;6 s t a r t ( receive_manager ) ;7 wait_for ( adhoc_mode_timespan ) ;89 i f ( there_is_blob_to_send ) {10 stop ( ip_manager ) ;11 stop ( forward_manager ) ;12 stop ( receive_manager ) ;13 switch_to (Managed_mod) ;14 f o r (max_try_to_connect ) {15 connect_to_internet ( ) ;16 i f ( connec t i on_es tab l i shed )17 break ;18 }1920 whi l e ( connect i on_ava i l ab l e21 AND managed_mode_timespan not e lapsed22 AND there_is_blob_to_post ) {23 blob = se l ec t_b lob ( ) ;24 send_to_server ( blob ) ;25 i f ( s end_is_succes s fu l )26 d e l e t e ( blob ) ;27 }28 }

Algorithm 4.2 IP Manager

1 /∗ random number generator i s seeded by network i n t e r f a c e MACaddress . ∗/

2 gen = new genera to r (MAC_ADDRESS) ;34 while (True ) {5 num1 = gen . next (255) ; // generate a number l e s s than 2556 num2 = gen . next (255) ;7 num3 = gen . next (255) ;8 set_IP (10 .num1 . num2 . num3) ;9 s l e ep_for (IP_MANAGER_TS) ;10 }


Algorithm 4.3 Forward Manager

1 Star t ( forwarder_helper_thread ) ;2 While (True ) {3 // blob_queue i s a queue o f forwardab l e b l o b s4 blob = dequeue ( blob_queue ) ; // b l o c k i n g i f queue i s empty5 h e l l o = generate_he l l o ( blob ) ;6 forwarding_hash_l ist . i n s e r t ( blob ) ; //a l i s t o f b l o b s which are

cu r r en t l y be ing forwarded . Rece ivers can send reque s t onlyf o r t h i s b l o b s .

7 broadcast ( h e l l o ) ;8 /∗ during t h i s time another thread ( Receive Manager ) i s

l i s t e n i n g and record ing the informat ion o f the nodesi n t e r e s t e d in t h i s b l o b ∗/

9 wait_for ( l i s t en ing_t ime ) ;10 mult icast_to_interested_nodes ( blob . getDataPacket ( ) ) ;11 }

forward any availabe blobs according to their left_forwards_no. Algorithm 4.3shows the details of forward manager. The procedure follows these steps:

1. it wakes up and starts to work when at least a blob is available in thesystem (either received from other devices or generated by the user);

2. it reads a blob from the blob queue through memory manager methods;

3. it inserts the blob into the forwarding queue. From this moment on,requests for this blob are acceptable and will be answered. In other words,the receivers can only send retransmition requests for a blob if the blob isavailable in the forwarding queue. Otherwise, the request will be silentlydiscarded;

4. it generates and broadcasts a hello packet to discover interested nodes;

5. it sleeps for listening_ts to register interested nodes;

6. it multicasts data to the interested nodes.

Forwarder Helper Thread It is a simple thread whose job is to move eachblob form forwarding list back to the blob queue when the forwarding_ts for thisblob has expired. After removing the blob from forwarding queue any furtherretransmition request for this blob will be discarded silently. Algorithm 4.4shows details of the forwarder helper.

Receive Manager Thread Receive Manager ThreadFigure 4.5 shows the general architecture of the receiving proccess. Receiver

Manager is a thread whose responsibility is to read received packets from a bu�erand respond to them. Algorithm 4.5 describes the detals of the procedure. Theprocedure follows these steps:


Algorithm 4.4 Forwarder Helper

1 While (True ) {2 blob = dequeue ( f o rward ing_l i s t ) ;3 i f ( blob_forwarding_ts_expired ( blob ) ) {4 tranfer_from_forwarding_to_blob_queue ( blob ) ;5 }6 s l e ep_for ( forwarder_helper_ts ) ;7 }

Figure 4.5: Receiving process


1. receiver manager reads a packet from bu�er;

2. if packet is a hello for a new blob, Receiver Manager will send a reply andcreate a blob based on the information from hello packet. It inserts thenew blob to receiving list;

3. if packet is a reply, it checks if the respective blob is listening for a newrecepinet. If so, it records the IP of the reply's sender in recepent's list ofthe blob;

4. if packet is a data, it fetchs the blob from reciving list and adds the receivedpacket to the blob. After that, it checks if the blob has completely received.If so, �rst it sends a bye to the sender, then it will change TTL of the blobas described in the algorithm (lines 24-29). Finally it moves the blob toeither �nal queue or blob queue based on its TTL;

5. if packet is a request and the sender IP is in the blob's recepinet's list. Itsends the requested packet;

6. if packet is a bye. It decreases the left_forward_no of the blob.if left_forward_nobecoms zero , it delets the blob.

Receiver Helper Thread It is a thread whose job is to send retransmissionrequests for blobs which have not been received completely after prede�nedretransmission_ts and discard blobs which have not been completely receivedafter max_request_no unsuccessful try(Algorithm 4.6).

UDP Sender Thread It is a static class used by other threads to unicast,multicast and broadcast datagrams.

UDP Receiver Thread It is a thread run by Receiver Manager whose jobis to listen to unicast port and write packets into the bu�er.

UDP Broadcast Receiver It is a thread run by Receiver Manager whosejob is to listen to broadcast port and write packets into the bu�er.

Tweeter Poster It is a static class whose job is to post tweets to the server.In case of successful post, it will delete the blob subsequently. It uses https toconnect to the server.

4.2.2 Server

The server is intended to deliver clients data to Twitter and to recognize dupli-cated packets. The server responsibilities are divided into two parts:

• Register a new user


Algorithm 4.5 Receiver Manager

1 s t a r t ( Rece iver_helper ) ;2 While (True ) {3 packet = read_packet_from ( bu f f e r ) ;4 switch ( packet . getType ( ) ) {5 case HELLO_PACKET:6 i f ( is_new_blob ( packet ) ) {// check ing MD5 hash i n s i d e the

h e l l o packet7 send ( he l l o_rep ly ) ;8 blob= generate_empty_blob_from ( packet ) ; // s e t b l o b hash ,

t t l and number o f data packe t s9 in s e r t_to_re c e i v i ng_ l i s t ( blob ) ;10 }11 break ;1213 case REPLY_PACKET:14 i f ( the_listening_time_not_expired_for_ID ( packet . getID ) {15 store_receiver_ip_for_ID ( packet . getID , packet . senderIP

( ) ) ;16 }17 break ;18 case DATA_PACKET:19 blob = load_blob_from_rece iv ing_l ist ( packet . getID ) ;20 add_packet_to ( blob , packet ) ;21 i f ( blob_is_completed and22 blob_is_val id ) {23 send ( bye ) ;24 i f ( b lob_tt l== 0 )25 add_to_f ina l_l i s t ( blob ) ; //non−f o rwardab l e b l o b26 else {27 i f ( b lob_tt l== MAX_TTL)28 decrease_ttl_by_one_with_25%_chance ( ) ;29 else decrease_ttl_by_one ( ) ;30 add_to_blob_list ( ) ;31 }32 }33 break ;34 case REQUEST_PACKET:35 i f ( sender_is_val id ) {// i f i t i s one the node we have sent

the b l o b to i t36 send_requested_packet ( packet . getID ( ) , packet . getSeqNum

( ) ) ;37 }38 break ;39 case BYE_PACKET:40 i f ( sender_is_val id ) {41 dec r ea se ( left_forward_number_of_the_blob ) ;42 }43 break ;44 }45 }


Algorithm 4.6 Receiver Helper

1 While (True ) {2 blob = dequeue ( r e c e i v i n g_ l i s t ) ;3 i f ( blob_receiving_ts_has_expired ( blob ) ) {4 for ( pkt : each_non_received_packet_of ( blob ) ) {5 i f ( pkt . number_of_retrasmissions < MAX_REQUSET_NUMBER)6 send_request_for ( pkt )7 else {8 /∗ g i v e up ∗/9 d e l e t e ( blob ) ;10 break ( ) ;11 }12 }13 }14 s l e ep_for ( r ece ive r_he lpe r_ts ) ;15 }

Figure 4.6: Data base diagram

• Receive and deliver user data to a destination web site.

As far as the server is concerned, the system can be divided to the followinglayers:

• Data Base

• Data Access Layer

• Web Application

Data Base We use PostgreSql as a dababase server (�gure 4.6). The shadownetwork data base consists of 3 tables: users, credentials, blob_hashes.

The user's table consists of only 3 columns: id, screen_name and password.The column screen_name is the username of the client which is the same user-name used by Twitter. It will be obtained from Twitter during the authentica-tion proccess. The column password is the SHA-1 hash of the password (saltedwith screen_name) chosen by the user. Screen_name and password have to besent to the server as part of the blob.

Credentials' and blob_hashes' tables are used to store web access credentialsand blobs hashes respectively.


Data access layer We use Hibernate as a data access layer, all the operationsrelated to the database are executed in a static class called hibernateUtil.

Web application The Web application responsibilities are divided into twoparts: user registration and posting tweets. It consists of three servlets: user_register,callback and post_tweet. The �rst two are used to register a new user. The pro-cedure follows these steps:

• user_register sends an unauthorised request to Twitter and redirects theuser to it.

• the user is asked for authorising the application(Figure (4.7)) .

• once the permission are granted, Twitter redirects the user to the calbackservlet.

• callback receives the access token and access token secret from Twitter.

• The user is asked to choose a password.

• screen name, password and twitter credential are stored in data base.

Post_tweet is a servlet whose job is to decrypt received data if the blob is anew blob, then it checks the validity of the credentials in the dycrypted blob. Ifit is valid, the tweet gets posted.


Figure 4.7: Twitter authorisation

Chapter 5

Evaluation and Testing

5.1 Environment

This section describes the environment used for the tests, that is the two Androidmobile phones and the development platform.

5.1.1 Hardware Speci�cations

The experimentation has been carried out with following two Android mobilephones:

• Model Name: HTC Hero (Figure5.1b)

CPU: 528 MHz ARM 11 processor, Adreno 130 GPU, QualcommMSM7200Achipset

Memory: Internal 288 MB RAM, 512 MB ROM

WLan: Wi-Fi 802.11 b/gBluetooth: v2.0

• Model Name:HTC Desire Bravo (Figure 5.1a)

CPU: 1 GHz Scorpion processor, Adreno 200 GPU, Qualcomm QSD8250Snapdragon chipset

Memory: Internal 576 MB RAM; 512 MB ROMWLan: Wi-Fi 802.11 b/gBluetooth: v2.1

5.1.2 General Development Platform

The development has been conducted on a computer equiped with Ubuntu ver-sion 11.04 using Eclipse 3.5.2 with the Android SDK1 plugin version 2.2. In

1http://developer.android.com/sdk/index.html

37

CHAPTER 5. EVALUATION AND TESTING 38

(a) HTC DESIRE (b) HTC HERO

Figure 5.1: Test mobile phones

u = the number of users.

b = the number bridges.

c = the number of message copies in the network.

Ps = probability that at least one of the bridges

receives the message

Pf = probability that none of the bridges

receives the message

Ps = 1− Pf = 1 - (u−bu ∗ u−b−1

u−1 ∗...u−b−c+1u−c+1 )

Figure 5.2: probabilistic evaluation of the protocol

order to test the communication between the devices, two network packet anal-ysers, Wireshark2 and Tcpdump3, were used respectively on the computer andthe mobile phones.

5.2 Delivery Rate Probability

We start with the probabilistic evaluation of the protocol: �gure 5.2 shows thenotations and the formula for computing the probability of deliverying messagesto at least one bridge when we have at least c copies of each message. Forexample:

u = 100,000

b = 50 (1 out of 2,000)

t = 7776(65,six forwards in five hops)

Ps = 0.98252

2http://www.wireshark.org/download.html3http://www.vbsteven.be/blog/android-debugging-inspectin-network-tra�c-with-

tcpdump/


Figure 5.3: Map of the test area(taken from google map)

spot 1 2 3 4 5

average time(ms) 4340 4980 5320 5700 6100

Table 5.1: Performance test result standard version

Although, Ps shows very high probability of success, in this formula we haveignored the factor of the delivery time. Note that the formula can be used to�nd more suitable values for TTL and number of forwards by testing di�erentparameters.

5.3 Performance Test

The performance tests were conducted in an area of 270 meters inside the Uni-versity of Birmingham. Figure 5.1 shows the map of the area: the red spotsindicate the positions where the measurments were taken(approximately 54 me-ters apart from each other). Two mobile phones were used, one was �xed inthe initial point on the left of the map, the other one was moving towards theright side the map. For each spot (numbered from 1 to 5) we measured theaverage times of three runs of the protocol for exchanging 20 blobs in ad-hocmode. table 5.1 shows the result.

The result of the test in the �rst spot shows a run of the protocol to senda blob takes, on average, approximately 217ms and most of this time is spent


spot 1 2 3 4 5

average time(ms) 420 920 1200 1470 2057

Table 5.2: Performance test result of improved version

Name Value

Battery Type Rechargeable Lithium-ion batteryCapacity 1400 mAhTalk Time Up to 390 mins

Standby Time Up to 360 hours

Table 5.3: Battery speci�cation

waiting(200ms) for Hello replies to �nd intrested nodes. To improve this weimplemented di�erent version of the protocol for the ad-hoc phase that avoidswaiting:

1. At prede�ned intervals(for example each 2 seconds) Alice broadcasts ahello packet containing a list of the MD5's of all the blobs she has.

2. The nodes which receive the List will check their hash lists(table 3.1) tosee if there are any new blobs in the list. If so, they will send a HelloReply for each of the new blobs to Alice.

3. Alice will send the blobs to the reply's sender with some precautions diss-cussed in 3.3.3.1 on page 17.

4. Each device which has received the packets completely sends a bye packetto the sender to con�rm it the successful reception of the packet. Afterthat, the receivers will decrease the TTL(table 3.1). If TTL becomes zerothe node will move the blob to the �nal queue(table 3.1).

5. When Alice receives a bye packet, she will decrease the number of forwardsby one for each received bye packet. If this number becomes zero she willdelete the blob.

The table table 5.2 shows the result of the same test for the improved versionof the protocol. As it can be seen the result shows a two to tenfold improvementin the average time for sending 20 blobs. Moreover, in the seccond version ofthe protocol the number of broadcasted Hello packets is decreased �vefold incomparison to the initial version since we broadcast Hello each seccond insteadof each 200ms.

5.4 Battery Consumption Test

The battery consumption tests were conducted using the HTC DESIRE witha fully charged and healthy battery. Table.5.3 shows the informaiton about the


Figure 5.4: Battery consumption chart

battery from the manufacturer4.The tests have been repeated two times for each test scenario. In the �rst

scenario, we ran Green Shadow on the two available mobile phones. One of themobile phones(HTC HERO) has been pluged in to the AC adapter (to preventit from turning o� before the HTC DESIRE, the mobile where took the mea-surements). After the mobile phones start the Green Shadow application, theyexchange messages until the HTC DESIRE battery dies. During this period,whenever the battery level changes, the new value for level and voltage of thebattery will be written into a �le for subsequent comparasion. In the second sce-nario, we repeat the test without running the Green Shadow application, withthe mobile phone in stand-by. Figure �gure 5.4shows the result of two tests. Asexpected, battery consumption increases signi�cantly when we use wi�, goingfrom approximately 46 hours to around 7 hours.

5.5 Simulator

To evalute and compare the most signi�cant aspects of the system in largescale scenarios, using a simulator is necessary. Simulations provide a valuablemeans to compare di�erent protocols and study their performances in terms ofe�ciency and robustness.

The mobility of nodes is the key attribute of mobile ad-hoc networks, andthe performances of Green Shadow need to be studied with regards to mobility.The movement patterns followed by the nodes in real-life situations can be un-predictable and complex and this greatly in�uences the performances of mobilead-hoc networks [12].

4http://www.htc.com/uk/product/desire/speci�cation.html


5.5.1 General characteristics and requirements of simula-tion studies

Generally speaking, simulation can be de�ned as the process of designing amodel of a real system and conducting experiments with this model for thepurpose of understanding the behavior of the system and evaluating di�erentstrategies for its control.

A number of steps have to be followed in any simulation study[14] :

• de�nition of the model of the real systemthis step involves de�ning the characteristics of the chosen representationof the real system and the objective of the study. In the other words, inthis phase we decide the resolution level which has to be considered andwhat is going to be seen through the lensess of the experimenter.

• collection of data from the real systemThe second phase concerns the practical acquisition of input data fromthe real system. Input data are necessary to set the main parameters ofthe model.

• de�nition of the experimental design and of the actual run ofthe simulation using the de�ned modelThe third, �nal step, concerns the issue of the de�nition of the wholeexperimental design and other necessary operational details: the durationof the simulations, the number of runs, the data that have to be collected,the measures of e�ectiveness to be used, the characteristics of the randomnumber generators, etc.

5.5.2 Available MANET simulators

We identi�ed OPNET5, NS-26 and OMNeT++7 as the best possible candidatesto run simulation studies in MANETs. They constitute the state-of-the-art inthe �eld of simulators for mobile ad-hoc networks. All of them support theimplementation of the OSI layers with almost all details and well known rout-ing algorithms like Adhoc On-demand Distance Vecotr(AODV) and DynamicSource Routing(DSR). However, they have some limitations which make themnot very useful for our project:

• it is not clear how to de�ne a new routing algortihm.

• there is no possibility to have di�erent nodes with di�erent communicationprotocols to simulate malicious nodes in the system. Gnerally, they do nottake into account any security related issues.

• none of them gives any information related to memory capacity, availablememory and so on which we are interested in.

5http://www.opnet.com/?gclid=CLi-iLPCiKsCFRQNfAodsG1gzQ6http://isi.edu/nsnam/ns/7http://www.omnetpp.org/


Name GUI Ease of use Documentation developed by

opnet(commerciaL) yes complex Poor(free version) OPNET Technologies Inc

ns-2 no complex poor(out of date) U.C. Berkeley/LBNL

omnet++(open source) yes easy Excellent András Varga

Table 5.4: Comparition of Simulators

5.5.3 Shadow simulator

Shadow simulator is a MANET simulator we developed to study the main prop-erties of Green Shadow. It has 3 main components:

• Map and Node Manager

• Protocol Manager

• Reporter

In the following subsections we brie�y describe each of them.

5.5.4 Map and Node Manager

Map and Node Manager is a component whose job is divided into 3 parts. First,it can design a map either randomly based on the input parameters (such as:map size, types and percentage of the roads and speed limitations of them) orby loading a matrix and its size as input parameters. In this case, the numberin each cell of the matrix indicates the type of the road. Secondly, it generatesnodes based on the type (reuglar, bridge or malicious), sets the appropriatecommunication protocol for each of them based on the type, places the nodesinto the map. Lastly, it moves the nodes inside the map at each time intervalusing the Markovian Random Walk Mobility method.

5.5.4.1 Markovian Random Walk

The Markovian Random Walk (MRW) mobility model [15] is a modi�ed formof the random walk model, also known as probabilistic random walk, and usesthe Markov chain to model the movement introducing memory in the movementbehavior in MANET. The movement coordinates x and y are represented usingthree states in the model:

• The state zero indicates the current position of the mobile node.

• The state one indicates the previous position of the mobile node.

• The state two indicates the next position of the mobile node.

Figure 5.5 shows the Markov chain for the movement coordinates x and yof a mobile node. Each entry of the probability matrix P(i, j) represents theprobability that a mobile will go from a state i to a state j. That is, P(i, j) isexpressed as follows:


Figure 5.5: Markov chain and probability matrix of Markovian random walkmobility model

p =

p(0, 0) p(0, 1) p(0, 2)p(1, 0) p(1, 1) p(1, 2)p(2, 0) p(2, 1) p(2, 2)

The values within this matrix are used for updating node's x and y positions.

The matrix P1 has been used for shadow simulator and have been illustrated inthe Markov chain �owchart in �gure 5.5

p1 =

0.1 0.4 0.40.3 0.7 0.00.3 0.0 0.7

The properties of this mobility model are summarized below:

• Nodes change their speed randomly (within certain limitations) each timeinterval

• Random walk can have retaining barriers that imply that mobile nodescannot move past them.

• Random walk can also have absorbing barriers from where mobiles cannotleave. That is, it is impossible to leave an absorbing barrier.

• Each mobile node bounces o� the simulation boundary with an angle ofθ(t) or π − θ(t) determined by the incoming direction when the nodereaches the boundary.

• Once a mobile node starts to move it is likely to remain in the samedirection because the probability that it stays in states (1) or (2) of theMarkov chain is greater than the probability that it goes back to state (0).


Figure 5.6: Mobile node's movement pattern using Markovian random walkmodel[15]

• The model does not allow sudden changes of the way of the movementbecause there is no one-step transition between states (1) and (2). Thisimplies that the mobile node has to stop before changing the way.

The aim of this method is to simulate movements thar are more likely to beclose to realistic behaviours rather then simple random movements. For exam-ple, once we have decided our destination, we tend to move in a semi-constantforward direction rather than turning around to retrace our steps or takingrandom steps that might or might not bring us to the place we need to reach.However, choosing appropriate values of P(i, j) may prove di�cult, if not im-possible. The �gure [15] represents a sample of node's movement pattern usingMRW.

5.5.5 Protocol Manager

The Protocol Manager is a component whose job is to simulate a run of theprotocol for each individual node in each time interval and update the statusof the nodes. In Green Shadow, we have di�erent protocols for regular, bridgesand malicious nodes.

5.5.6 Reporter

The Reporter is a component whose job is to export the results of the simulationto a �le. The result of the simulation consists of:

• The maximum amount of memory used by nodes to store network packets.

• The number of generated messages.

• The number of messages delivered to the bridges.


• The number of cleaned messages. A Cleaned message ia a message whichhas been delivered to a bridge and there is no redundant copy of it inthe network. The ideal protocol must maximise the number of cleanedmessages.

• The number of lost messages. A lost message is a message which has notbeen delivered to any bridge and there is no copy of it in the network.The ideal protocol must have minimum number of lost messages.

• Delivery rate of the messages. Delivery rate is the number of messagesdelivered to the bridges divided by the total number of the generatedmessages. The ideal protocol must have maximum delivery rate.

• The total number of all message copies.

• The rate of blob generation. The rate of blob generation is the totalnumber of message copies divided by the current simulation duration.The ideal protocol must maximise the rate of blob generation.

• The number of con�icting IPs.

5.5.7 Simulation Results

In this section we present the results of our simulations using di�erent versionsof the protocol:

• Initial protocol with bye attack defence

• Improved protocol with bye attack defence

• Unsafe Improved protocol (without bye attack defence, to evaluateto what extent our solution is e�ective)

Table table 5.5 shows input values for the simulatior (the same for all thesimulations). Each simulation gets the time duration of a run of its protocol asan input parameter based on the results of performance tests5.3. Needless tosay, in all simulations the map, the nodes movement, the number of generatedmessages and the time of message generations are identical. The only di�erencesis in the version of the running protocol and consequently the behaviour ofthe nodes. In the following subsections we compare and study some of themain properties of the protocols in the period of 150 minutes of simulation.Unfortunately, the computational resource usage policy of the Computer Sciencedepartment in University of the Birmingham prevented us from simulating alonger period as the simulator is extremely time and resource consuming.

5.5.7.1 Delivery rate

Figure 5.7 shows delivery rates of the protocols for 159 minutes. In the �rst50 minutes, the delivery rate of the unsafe version of the improved protocol


Name Value

Map Size 252 km2(wBirmingham area)Users 9000(w 1% of Birmingham populaiton)

Maliciouse Nodes 90(1% of users)Bridges 9(0.1% of users)Vehicles 450(20% of users)

Speed Limitation of users up 50 cm/sSpeed Limitation of Vehicles 40 km/h-90 km/hIP Changing Time Interval 1 minutes

Node Movement Time Interval 500 msDelay Time for Safe Forward 30 minutes8

WiFi distace coberage 150m

Table 5.5: Input values for the simulator

Figure 5.7: Comparision of Delivery Rate

is signi�cantltly better than the others due to the unsafe way of forwardingmessages, while the initial protocol and the safe version of the improved protocolhave roughly the same delivery rate. One reason can be, in this period, most ofthe nodes have few messages to forward, so the amount of time which the sendermust spend on wait for recepients in the initial protocol is not considerable.

After that, the �gure for the safe improved protocol increases from approxi-mately 20% to more than 50% in 150th minute of simulation. However, in thesame period, the �gures for unsafe and initial protocol do not show consider-able increases due to the rate of lost packets and the forwarding delay timerespectively. From the chart, we can say the modi�cation of the protocol hassigni�cant e�ect on the delivary rate of the system.


Figure 5.8: Comparison of maximum memory usage by bridges

5.5.7.2 Maximum memory usage for bridges

Figure 5.8 compares the maximum amount of memory in KBytes used by bridgesin the di�erent versions of the protocol for a period of 150 minutes of simulation.

In the �rst 50 minutes, all the simulations show similar maximum usage ofthe bridge memory. However, after that, the maximum bridge memory usageof the safe improved protocol shows a signi�cant increase from less than 500KBto approximately 2MB. A value which is extremely small in comparison to thegiga-bytes of memory available in mobile phones.

On the other hand, in the same period, the �gures for the unsafe and initialprotocols show a gentle increase for the same reason explained in the previoussubsection.

5.5.7.3 Rate of message spreading

Figure 5.9 illustrate the power of message spreading of our protocols for a periodof 150 minutes of simulation. The rate of message spreading of the unsafe versionof the improved protocol is extremely higher than the others due to the unsafeway of forwarding messages used by nodes. However, the great amount of lostmessages in this protocol(�gure 5.10) causes to not have acceptable deliveryrate.

On the other hand, The initial and safe improved protocols has almost thesimilar power of messae spreading in compare to unsafe version. However, after100th minute of the simulation the improved version started to overtake theinitial version. The longer period of simulation is neccessary to compare thebehavior of these two protocols.

5.5.7.4 Rate of lost messages

The �gure 5.10 shows the percentage of lost messages during 250 minutes ofsimulation. While the unsafe protocol shows more than 10% of lost messageswithin 250 minutes, none of the other protocols show considerable percentage of


Figure 5.9: Comparision of message spreading

Figure 5.10: Rate of Lost Messages caused by Bye Attack

dropped messages in comparison to the unsafe version. Although, it shows ourapproach to mitigate the bye attack is e�ective, the longer period of simulationis necessary.

Chapter 6

Conclusion and future work

6.1 Summary

With regard to the objectives presented in the introduction, I started my workwith investigating available radio transmitters to �nd a suitable for my project. Idecided to use 802.11 because of the larg distance permitted by the technologyand the fast transmittion(54 Mbps); this choice was a challege because theandroid platform does not support using ad-hoc mode out of the box and alsothere is almost no documentation about how to switch to ad-hoc mode since itis di�erent for each model of mobile phones.

The next step was the design of a protocol to transfer messages to the inter-net from the a zone where the internet has been restricted or blocked(chapter 3).The protocol is based on a decentralised network of mobile nodes which dividedto regular nodes which do not have access to the internet and bridges which po-tentially have access to a central server through the internet(travellers, embassyemployers). The aim of the protocol is to transfer messages from regular nodesto bridge which can eventually post them on the internet. To show the feasi-bility of the protocol I have implemented a prototype for Twitter for publishingtweets which runs on the android platform (chapter 4).

As far as last aim is concerned, I designed and implemented a simulator tostudy the main properties of the protocol for large scale scenarios. One veryimportant property we are intrested in is the delivery rate which we de�ned asthe percentage of message which are eventually posted on the internet. Thesimulation allowed me to compare di�erent versions of the protocol and to ex-amine the e�ectivness of our solution for bye attack (section 3.3.3.1 on page 17)on the nodes. The result shows: (1) the delivery rate of our protocol can bee�ectively improved by 10% (from 30% to 40%) by eliminating useless waits anddecreasing the number of broadcasted packets. (2) our approach allows to min-imise the e�ectiveness of some attacks on the nodes by delaying the forwardingof some messages: the rate of the lost messages decreased from ... to ... .

50

CHAPTER 6. CONCLUSION AND FUTURE WORK 51

6.2 Future work

This project was the �rst example of providing access to the Net in area wherethe Internet has been restricted, however much has yet to be done before thissystem can be considered as a strong solution. Some open issues remained.

Firstly, the current version of Green Shadow only can be used to reportnews. The next possible extenstion could be the addition of bidirectional com-munication like an instant messaging protocol.

6.2.1 Filtering issues

One central issue of our architecture is �ltering, In our implemetation the cen-tral server is a single point of failure thus by making it unavailale in certainzones through �ltering an attacker can reduce the number of bridges that cansuccesfully deliver messages to the Internet. Of course the system survives be-cause we assume that at least a percentage of the bridges are �lter resistant(can physically leave th restricted zone). In our implementation we mitigatethe e�ect of this attack by using Tor bridges. Other approches needs to beexplored:

(1) domain �uxing, a technique used by malware to become more resistant to�ltering, domain �ux uses a domain generation algorithm(DGA) to compute along list of domain names which is di�erent in each prede�ned period of time (forexample one day). The client attempts to connect to each of them sequentially inorder until successfully resolves to an IP address and the corresponding serverprovides a valid response. Then the client can be use the address until nextround of domain generation. Even if it is possible to reverse engineer the DGA,it is very resource consuming to block, say every day, all the possible domainsname.

(2) the bridges can be replaced or connected to the Internet through Internetin briefcase which is an experimental project by U.S government to bulid smalldevices that have independent access to the internet.

6.2.2 Simulation Improvement

As an extra part we implemented a simulator which is able of evaluating themain properties( delivery rate, rate of lost,etc...) of the of various versions of theprotocol. Four extensions are possible. The �rst one consists of implementingpart of the OSI model to measure aspects at layers di�erent from the applica-tion layer, for example collision at physical layer and so on. The second extesioncould be an improvment in the way nodes movement are simulated. Currently,the nodes move using Markovian Random Walk. More sophisticated solutionsshould be investigated to produce movments more similar to real life. The otherpossible improvment is graphical presentation of the simulation and the possi-bility for the user to interact with the simulation by adding, moving, deletingnodes and generating, modifying and deleting the messages during simulation.

CHAPTER 6. CONCLUSION AND FUTURE WORK 52

Finally, the current version supports simple maps beased on bidimentional vec-tors; the possibility of providing more complex maps based topography of realcities should be explored.

Bibliography

[1] Android DeveloMore so�sticated solution should be in-vestigated to produce movments more similar to reallife. to per Website, �Wi�Manager Interface� [online athttp://developer.android.com/reference/android/net/wi�/Wi�Manager.html,accessed 21 Jul 2011]

[2] Bluetooth,�Basices� [online at http://www.bluetooth.com/Pages/Basics.aspx,accessed 21 Jul 2011]

[3] Tor Bridge [online at https://www.torproject.org/docs/bridges#FindingMore,accessed 09-09-2011]

[4] William Lehra, Lee W. McKnightb, �Wireless Internet access: 3G vs.WiFi�,MIT Research Program on Internet and Telecoms Convergence, Mas-sachusetts Institute of Technology

[5] �Understanding Bluetooth�, HP Invent, January 2002 [online athttp://www.hp.com/rnd/library/pdf/understandingBluetooth.pdf, ac-cessed 21 Jul 2011]

[6] WHITE PAPER Broadcom, �IEEE 802.11g The New Mainstream WirelessLAN Standard �

[7] Bachar Wehbi, �Address Autocon�guration in Ad Hoc Networks � May 2005

[8] Android Bluetooth API at http://developer.android.com/reference/android/bluetooth/package-descr.html

[9] Rabie Khodr Jradi Lasse Seligmann Reedtz , �Ad-hoc network on Android�,2010

[10] Dr eric Cole �Swarm Intelligence and Network Administration: Applica-tions in Ad Hoc Wireless Auto-Con�guration �, 2006

[11] wikipedia �twitter� [online at �http://en.wikipedia.org/wiki/Twitter�, ac-cessed 21 Auguest]

[12] Camp, T et al (2002) A survey of mobility models for ad hoc networkresearch. WCMC 2(5)

53

BIBLIOGRAPHY 54

[13] Hossmann T (2006) Mobility Prediction in MANETs � Master's Thesis.Swiss Federal Institute of Technology, Zurich

[14] Gianni A. Di Caro �Analysis of simulation environments for mobile ad hocnetworks �

[15] Camp, T et al (2002) A Survey of Mobility Models for Ad Hoc Networkresearch. WCMC

[16] US State Department Backing �Shadow� Inter-net and Cellphone Projects [online at 08-09-2011http://blogs.discovermagazine.com/80beats/2011/06/14/us-state-department-backing-shadow-internet-and-cellphone-projects/]

Appendix A

Android ad-hoc con�guration

As ad-hoc networking is not directly available in the Android API and alsobecause there is no documentaion about it, getting ad-hoc WiFi to work isextermely challenging. The only available resourse on the net is a project fundedby Google called android-wi�-tether1 which sets up an ad-hoc network to sharemobile-phone Internet between other stations. Unfortunately, the code is notwell-documentent and does not work on one of our mobile phones (HTC Desire):it is not able to change the network interface to ad-hoc. The investigation ofthis code required approximately ten days.

This tether application provides a GUI front-end to con�gure and executea shell script which performs a series of steps to tether the 3G data connectionover the WiFi network:

• Shuts down any running WiFi services

• Reloads the WiFi system driver with a new con�guration.

• Starts a DHCP server to serve clients on the adhoc network with addressesin 192.168.2.0/24 subnet

• Sets up iptables to perform a NAT function. The mobile phone is con-�gured to act as the router on the 192.168.2.0 subnet. The script canoptionally restrict access based on a white-list of MAC addresses usingadditional iptables2 rules.

• Registered WiFi clients append entries into a tether.log �le, which can beviewed through the GUI.

However the HTC Desire phone uses a di�erent network driver (bcm4329.ko)than the HTC Hero(wlan.ko) so the steps to change the wireless interface toad-hoc are completely di�erent. Even if the authors of the script state that itworks with HTC Desire, a bug was found which shows that this script has neverbeen tested with this type of mobile phone.

1http://code.google.com/p/android-wi�-tether/2Iptables is the command line interface to the Linux �rewall (net�lter).

55

APPENDIX A. ANDROID AD-HOC CONFIGURATION 56

insmod /system/lib/modules/wlan.ko

wlan_loader -f/system/etc/wifi/Fw1251r1c.bin

-e/proc/calibration -i /data/local/bin/tiwlan.ini

ifconfig tiwlan0 10.0.0.1 netmask 255.0.0.0

ifconfig tiwlan0 up

Figure A.1: Minimal script to change HTC Hero to ad-hoc mode

insmod /system/lib/modules/bcm4329.ko

iwconfig eth0 mode ad-hoc

iwconfig eth0 essid shadow

iwconfig eth0 channel 6

ifconfig eth0 10.0.0.2 netmask 255.0.0.0

ifconfig eth0 up

Figure A.2: Minimal script to switch HTC Desire to ad-hoc mode

A.1 General Steps to change Interface to ad-hoc

for HTC Hero mobile phones

Figure A.1 shows a minimal script that has been adopted from the tetheringproject and that changes the network interface of a HTC Hero mobile to ad-hoc.

Warning: The wireless must be disabled before running the commands.It can be done throuhg wi�-manager api or shell command:

svc wifi disable

A.1.1 General Steps to change Interface to ad-hoc forHTC Desire mobile phones

In a �rst phase, 12 di�erent version of Roms are tested in order to �nd a reliablerom. Generally speaking, almost all available HTC Desire Roms proved to bebuggy as far as WiFi ad-hoc mode is concerned.

The most common bugs found were:

• Fail to remount �le system in write mode: ./adb remount

• Fail to remove the driver from kernel through : rmmod bcm4329

• Fail to load the driver to kernel through: insmod bcm4329.ko

Figure A.2 shows the reuired steps adopted from tethering project:

APPENDIX A. ANDROID AD-HOC CONFIGURATION 57

Dicoverable3

Send a receive a send a receive a

packet packet broacast packet broadcast packet

HTC Desire Failed Succeeded Succeeded Succeeded Failed

HTC Hero Succeeded Succeeded Succeeded Succeeded Succeeded

Ubuntu Succeeded Succeeded Succeeded Succeeded Succeeded

Table A.1: Mobile Ad-Hoc test results

However this script does not work since according to the source code of bcm4329.ko,after changing the ESSID, there is no way to change the value of any interface'sproperties and any try will result in an error, thus the right order of the com-mands is:

insmod /system/lib/modules/bcm4329.ko

iwconfig eth0 mode ad-hoc

iwconfig eth0 channel 6

iwconfig eth0 essid shadow

ifconfig eth0 10.0.0.2 netmask 255.0.0.0

ifconfig eth0 up

Warning: The wireless must be disabled before running the commands.It can be done throuhg wi�-manager api or shell command:

svc wifi disable

A.1.2 The results of the tests

The development has been conducted on a computer equipped with Ubuntuversion 11.04 using Eclipse 3.5.2 with Android SDK plugin version 2.2. In orderto test the communication between the devices two network packet analysers,Wireshark and Tcpdump, have been used respectively on the computer and themobile phones.

The table A.1 shows the results of the test.Unfortunately HTC Desire (all supported Android versions) has a well-

known problem to receive broadcast messages and, therefore, it cannot recieveARP packets which is a broadcast message and it cannot be discovered by otherdevices before it has tried to contact them. According to some android de-veloper's forums, this is an open issue for HTC Desire4.However,we found acustomized Rom5 which can actually receive broadcast messages.

4http://code.google.com/p/android/issues/detail?id=8407http://forum.xda-developers.com/showthread.php?t=6505325http://androidforums.com/hero-all-things-root/374776-htc-hero-cronos-ginger-x-2-3-1-

android-2-3-4-a.html

Appendix B

Installation and con�guration

of Green Shadow

To install Green shadow, �rst of all we need to have root access to the phone.The instructure to get root access of the phone can be found in the Unlocekrweb site1 for each speci�c type of mobile phone.

B.1 Installation

In the next step, we have to follow this structure:

1. Copy the APK �le of Green Shadow to the Android's memory card andinsert the card into the phone.(it can be done by using a USB cable todirectly copy the �le into the memory card)

2. Download and install the Apps Installer2 application from the AndroidMarket3.

3. Once installed, the Apps Installer will display the APK �les on the memorycard.

4. Click and install Green Shadow APK �le.

Then we can use Green shadow by pressing on its Icon.

B.2 How to Send a tweet

First of all, The user needs to register to the shadow website4 to get a user nameand password which is required in the sending process.

1http://www.unlockr.com/2https://market.android.com/details?id=com.IQBS.android.appInstaller&hl=en3https://market.android.com/?hl=en4studentweb.cs.bham.ac.uk/axm131/Shadow/

58

APPENDIX B. INSTALLATION AND CONFIGURATIONOFGREEN SHADOW59

(a) Main Page (b) Setup Page

Figure B.1: Green Shadow

When the registration is completed, the user can run Green Shadow to sendtweets. The procedure follows these steps:

1. press the menu button to see the available menu items, then chooseSetup(�gure B.1b).

2. in the setup page, the user name and password can be set.

3. after setting username and password by pressing save button, the appli-cation shows the main page.

4. then we can easily write a tweet inside a text box available in the mainpage(�gure B.1a).

5. by pressing send, the message will be disappear from the screen and willsend in appropriate time.

green network:providing connectivity where the internet is ...tpc/papers/green.pdf · school of...

Documents