Embed Size (px)
Citation preview
Bachelor Thesis
Building a secure, mobile VoIP networkover Bluetooth
Albert-Ludwigs-University FreiburgFaculty of Applied Sciences
Professorship of Communication SystemsProf. Gerhard Schneider
Konstantin Welke, matriculation no. [email protected]
March 2006
2
3
ERKLÄRUNGHiermit erkläre ich, dass ich diese Abschlussarbeit selbständig verfasst habe, keine anderen
als die angegebenen Quellen/Hilfsmittel verwendet habe und alle Stellen, die wörtlich oder sin-ngemäß aus veröffentlichten Schriften entnommen wurden, als solche kenntlich gemacht habe.Darüber hinaus erkläre ich, dass diese Abschlussarbeit nicht, auch nicht auszugsweise, bereitsfür eine andere Prüfung angefertigt wurde.
__________________ _________________________________________Ort, Datum Unterschrift
4
5
Abstract
Using the Linux smartphone Motorola A780, it is possible to join an auto-configuringBluetooth IP network. Through this network, a secure connection to a trusted host is es-tablished. VoIP phone calls can be created and received over this connection. Thanks tointeractions of various network layers and applications, connection breaks can be recovered,so that they only disrupt an ongoing phone for about 3 to 4 seconds.
For user-friendly interaction, an application was created to perform VoIP and GSM tele-phony. It also starts all necessary daemons and allows the user do all necessary configura-tions.
6
AcknoledgementsI want to thank Dirk von Suchodoletz for his constant support, time and advice. I want to thank
Professor Dr. Gerhard Schneider for the many opportunities to learn and for taking responsibilityfor this thesis. I also want to thank Prof. Dr. Christoph Scholl for correcting this thesis.
I want to thank my parents for their efforts and for being there for me.Finally, I want to thank Stefan Buchholz for the fun time we had studying.
CONTENTS 7
Contents1 Introduction 11
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.2 General Idea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.3 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3.1 The Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.3.2 The Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.3.3 The Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 Existing Concepts 132.1 Existing Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1.1 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.1.2 SIP and RTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2.1 connectblue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2.2 Lunar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2.3 Optimized Link State Routing . . . . . . . . . . . . . . . . . . . . . . . 172.2.4 Voice over Bluetooth based MANETs . . . . . . . . . . . . . . . . . . . 17
3 Available Devices 193.1 Operating Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.1 Windows Mobile Devices . . . . . . . . . . . . . . . . . . . . . . . . . 193.1.2 Symbian Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.1.3 Linux Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 The Motorola A780 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.2.1 Hardware in General . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.2.2 Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2.3 Sound . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2.4 Hardware GSM Codec . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.2.5 Preinstalled Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2.6 Flashing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2.7 Flex Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2.8 Getting a Shell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.2.9 Filesystem Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.2.10 Installing Third-party Applications . . . . . . . . . . . . . . . . . . . . . 243.2.11 Compiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2.12 Writing GUI Applications . . . . . . . . . . . . . . . . . . . . . . . . . 243.2.13 What is not Possible . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4 Network Layout 274.1 Network Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.2 Bluetooth IP connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8 CONTENTS
4.2.1 Why IP? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.2.2 Connecting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.2.3 Fine-tuning the Bluetooth Connection . . . . . . . . . . . . . . . . . . . 294.2.4 Multiple Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.2.5 Encountered problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.2.6 Security Implications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3 Choosing an IP Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.3.1 Issues with the Motorola A780 . . . . . . . . . . . . . . . . . . . . . . . 32
4.4 Routing to the Phone Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.4.1 Static Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.4.2 Uses and Non-Uses for olsr . . . . . . . . . . . . . . . . . . . . . . . . 32
4.5 Securing the Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.5.1 Bluetooth Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.5.2 openvpn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.5.3 About Internet Access . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.6 Link Failure Detection and Recovery . . . . . . . . . . . . . . . . . . . . . . . . 354.7 Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.8 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5 The Phone Application 395.1 Initializing Existing Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.3 Link Quality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.4 Making and Answering Phone Calls . . . . . . . . . . . . . . . . . . . . . . . . 405.5 VoIP calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.5.1 Fixing the Audio Output on this Side . . . . . . . . . . . . . . . . . . . 425.5.2 Fixing the Audio Output on the Other Side . . . . . . . . . . . . . . . . 43
5.6 Making GSM phone calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.6.1 Analyzing the Phone Application . . . . . . . . . . . . . . . . . . . . . 465.6.2 Making GSM Phone Calls . . . . . . . . . . . . . . . . . . . . . . . . . 485.6.3 Encoutered problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.7 Accessing the Address Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.8 Power consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 505.9 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6 Conclusions and Outlook 51
References 53
Appendix 55
LIST OF FIGURES 9
A configuration files 55A.1 olsrd.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55A.2 openvpn-server.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55A.3 openvpn-client.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55A.4 Access Point startup script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56A.5 Access Point dev-up script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56A.6 Mobile Device startup script . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56A.7 Mobile Device dev-up script . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
List of Figures1 Bluetooth connection types.
source: [BTCore] Vol.1, Part A, 3.1 Core Traffic Bearers . . . . . . . . . . . . . 132 ACL packet types.
source: [BTCore], Vol 2, Part B, 6.7 Packet Summary . . . . . . . . . . . . . . . 143 SIP Handshake.
source: http://en.wikipedia.org/wiki/Image:SIP_signaling.png . . . . 154 The Motorola A780
source: http://www.motorola.com/motoinfo/product/images/0„70,00.html . . . . 205 Network Layout, simplified . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 A screenshot of the phone application . . . . . . . . . . . . . . . . . . . . . . . 397 Incoming phone call.
(Note: the phone number has been edited) . . . . . . . . . . . . . . . . . . . . . 41
10 LIST OF FIGURES
11
1 Introduction
1.1 Motivation
Next to body language, speech is the most natural mode of human communication. This isprobably the reason why the main form of fast communication within an organisation is thephone call. Usually, every employee has a telephone on their desk and internal phone calls withinan organisation are free. If however, an employee is highly mobile, this is no longer feasible. Inthese cases, he or she is equipped with a mobile phone. Usually, this is a very expensive solution.
Most mobile phones use GSM1 to make phone calls. In environments where the employeemoves inside a limited area, such as a building, it’s a self-evident idea to cut costs by providinglocal infrastructure. One cannot simply start installing GSM stations to provide local access,though. However, another form of radio communication could be used for phone calls, whileretaining GSM capabilities for flexibility.
The most obvious choice for radio communication is Wireless LAN, which provides morethan enough bandwidth for voice communication. Nowadays it is very simple to get a wirelessconnection inside a city. Unfortunately, few2 mobile phones have a Wireless LAN interface.Most phones have a Bluetooth interface, though, which only provides a fraction of WLAN’sbandwidth, but it is still sufficient.
Furthermore, many mobile devices, such as PDAs, have a Bluetooth interface and audio in-and output. This means that the same infrastructure as for phone calls can be used, given enoughcomputing power.
The goal of this Bachelor Thesis is to investigate how a presend-day smartphone, or equiva-lent device, can use Bluetooth for telephony.
1.2 General Idea
The main idea is to equip a given building with Bluetooth Access Points. These provide a networkfor the Mobile Devices, such as mobile phones or PDAs. The Access Points are connected to thePhone Gateway using a pre-existing wired network, e.g. ethernet. A Mobile Device uses anAccess Point to connect to the Phone Gateway. Through this connection, it creates and receivesphone calls.
Audio data has to be split into data packets before being sent to the Phone Gateway. Theobvious choice is to use Voice over IP (VoIP).
Furthermore, this infrastructure could be used for intelligent call routing, depending on signalstrength, or location-based services. This is not part of this Bachelor Thesis but of a parallelMasters Thesis.
1see http://en.wikipedia.org/wiki/GSM2The Motorola CN620, running Windows CE 4.2, is the such a mobile phone. It is, however, only available in
the US. see http://www.motorola.com/wlan/index.html and http://www.motorola.com/wlan/docs_pdf/cn62mod.pdfThere is also the BenQ P50, also running Windows, http://benq.com/NewProducts/product.cfm?product=13 and
the NTT DoCoMo N900iL.
12 1 INTRODUCTION
1.3 Requirements
1.3.1 The Application
From an end-user’s point of view, making a call using VoIP should be as simple as possible. Itshould not be much more complicated than making an ordinary (GSM) phone call, and about ascomplicated as making a VoIP phone call using a computer. There should be as few configuraionoptions as possible. The ability to make a VoIP phone call should be integrated into the phone asseemlessly as possible. If this proves unfeasible, an application should be provided that lets theuser enter a phone number or select one from the address book in order to place a VoIP or GSMphone call. It should also display the signal strength of available GSM and Bluetooth networks,and let the user do any needed configuration. The user should be able to select wether they makea GSM or VoIP phone call, or whether to let the Mobile Device handle this decision.
1.3.2 The Network
The Mobile Device should automatically detect and connect to the Access Points (AP). TheMobile Device should connect to multiple APs, if possible, in order to gracefully handle con-nection breaks: If one connection goes down, it should detect this and use the other connection.Optimally, this should be done in a way that only minimally disturbs a phone call.
The Phone Gateway takes care of routing the phone call to its destination.The network should be built in a way that minimizes latency, which is critical for phone
calls. All users should be authenticated prior to making a phone call. The network should alsobe secure, which means that eavesdropping or manipulating user communication is infeasible.
Depending on the administrators choice, Mobile Device access to the internet is anonymous,authenticated, or impossible.
1.3.3 The Device
The Mobile Device needs to have a Bluetooth interface, speaker and microphone. It also needsa user-friendly input and output method. The device has to provide enough computing power tohandle VoIP.
The user must be allowed to run arbitrary code on the device. User code must have thepriviledge to create and use Bluetooth connections, to access the speaker and microphone and torun a graphical user application.
Furthermore, support for the Internet Protocol, modification of routing tables and supportfor the creation of encrypted connections is favorable. Also, since modifying existing softwareis easier, faster and less error-prone than writing from scratch, existing open-source software isdesirable for the Mobile Device.
13
2 Existing Concepts
2.1 Existing TechnologyThis section gives a short overview of the technology and protocols used in this thesis. VoIP isactually not a protocol but a category of many different protocols. I will present the two mostcommon open protocols used for VoIP. These are SIP and RTP.
2.1.1 Bluetooth
Bluetooth is a packet-based radio communication, standardized by the Bluetooth Special InterestGroup [BTCore]. It operates in the unlicensed 2.4 GHz frequency band. This band is dividedinto 79 frequencies. Each Bluetooth device has a physical clock which changes its frequencyat a rate of 1600 Hz in a pseudo-random fashion. In order to communicate with each other,two devices need to synchronize their clock and their frequency hopping pattern. After sucha synchronisation, a piconet is formed. A piconet always consists of a master, which sets theclock time and hopping pattern, and up to 7 slaves, which accept these settings. A device canbe a master in only one piconet, but can be a slave in any number of piconets. This allows theformation of scatternets, which can be used to route data across multiple piconets. However, nostandard is provided to allow for such routing.
Figure 1: Bluetooth connection types. source: [BTCore] Vol.1, Part A, 3.1 Core Traffic Bearers
14 2 EXISTING CONCEPTS
Bluetooth distinguishes between different connection types. ACL connections are reliable,which means that they will be acknowledged if received, retransmitted if no acknowledgementis received and an error will be reported if retransmission ultimately fails. ACL links are compa-rable to the TCP protocol of the IP stack.
ASB and PSB transmissions are unreliable. There is no way for the sender to know if thepacket arrived at the destination at all. These packet types allow only the master to send broad-casts in a piconet.
ACL, ASB and PSB connections are framed, which that means it is possible to send datawhich is bigger than an actual packet, as the data will be distributed over multiple packets. Theyare also asynchronous, which basically means that no bandwidth will be reserved for them.
SCO and eSCO connections are synchronous, unreliable and unframed. Upon connectionestablishment, time slots are reserved for these packets, and no other device may send dataduring a reserved time slot. They are primarily used for sending PCM audio data to headsets orhands-free speaking systems.
Figure 2: ACL packet types.source: [BTCore], Vol 2, Part B, 6.7 Packet Summary
Bluetooth ACL packets can have different sizes. The smallest packet, DM1, transports up to17 bytes of user data and uses a 2/3 FEC checksum for reliability. It uses one time slot. TheDH1 packet transports up 27 bytes in a time slot, by leaving out the 2/3 FEC checksum. Packetscan also span multiple time slots: The DM3 and DH3 packets each use 3 time slots, while theDM5 and DH5 packets use 5. These exist in symmetric and asymmetric modes: The symmetricmode allows both master and slave to send equally big packets. In the asymmetric mode onlythe master sends big packets while the slave is limited to sending one-time slot packets. Thisincreases the master’s upstream bandwidth and decreases the slave’s. The values in the table are,of course, theoretical values without packet overhead. For example, over a ACL link using DH5,one can send about 300 to 320 kbit/s of UDP user data.
2.1 Existing Technology 15
2.1.2 SIP and RTP
The Session Initiation Protocol, or SIP, is a control protocol for audio and video communication[RFCSIP]. It has been created to provide a superset of conventional telephone functions. It canbe used to make, redirect, answer and terminate phone calls, although the protocol can also beused to control other forms of communication like video streams or instant messaging.
SIP can carry the Session Description Protocol, or SDP, to describe the session properties,such as which port number and codec to use.
Figure 3: SIP Handshake.source: http://en.wikipedia.org/wiki/Image:SIP_signaling.png
SIP introduces SIP URIs of the form sip:name@domain, which are used to identify a peer.For example, Peter’s IP address is 1.2.3.4, and his SIP phone listens on the default port, 5060.Calling sip:[email protected] will send him a SIP INVITE message. If Peter wants to pick up, hesends back OK, after which an RTP stream is created to carry the audio data.
However, one usually does not know the IP address of the peer you want to call. This iswhy the domain part of the URI usually points to a SIP proxy. Each user can register himselfat his proxy to publish information about his presence, such as his IP address. For example,
16 2 EXISTING CONCEPTS
Peter works at the University of Freiburg, which has a SIP proxy. His URI is [email protected]. When a caller wants to contact Peter, the proxy forwards the INVITE message tothe address under which he previously registered. From here on, all communication between thecaller and Peter is direct, the proxy is not involved anymore.
The Real-Time Protocol, or RTP, is used to transfer the actual audio data [RFCRTP]. RTP isa UDP-based protocol, so packets can be lost or arrive out of order. Propably the most importantproperty of an RTP packet is the timestamp. This identifies when a given piece of audio shouldbe played. The timestamp depends on the sampling rate, e.g. 20 ms at 8000 Hz use 160 timesteps.
Note that SIP has problems with network address translation (nat). E.g. A one might registerhimself or send an INVITE using a private IP address, which in turn cannot be routed correctlyby its peer. Furthermore, both RTP and SIP establish peer to peer connections. This is onlypossible through nat if forwarded ports are configured correctly, or if a method like STUN3 isused. Another option is to let the SIP proxy work as a Back to Back User Agent4, and let bothpeers connect to the proxy instead of each other.
2.2 Related WorkThe problems of this thesis have already been subject to various research efforts. The IETF hasa working groups on MANETs5, which is yet another word for ad-hoc network. However, mostefforts are directed towards Wireless LAN, and it is hard to find papers that explicitely mentionBluetooth.
2.2.1 connectblue
Igor Gurovski & Velimir Karadzic researched how to create Bluetooth ad-hoc networks withvery small embedded systems [connectblue]. However, they did not make an implementationpublicly available. Even if they did, it would be unlikely that this implementation could be useddirectly on a smartphone.
2.2.2 Lunar
Lunar is a proactive ad-hoc network protocol, developed by Uppsala University and the Uni-versity of Basel. Olaf Rensfield ported it to Bluetooth as his master thesis. He developed twovariants: one that runs in the Linux kernel and one that runs completely in userspace, and uses atun device [BTLunar]. Unfortunately, these Bluetooth modifications are not part of lunar distri-bution, nor published anywhere. I tried to get in contact with the universities, but did not receivea response.
The thesis is especially interesting at section 3, “Design”, where the Bluetooth-specific prob-lems of creating ad-hoc networks are clearly analysed.
3http://en.wikipedia.org/wiki/STUN4see http://en.wikipedia.org/wiki/Back-to-back_user_agent5http://www.ietf.org/html.charters/manet-charter.html
2.2 Related Work 17
2.2.3 Optimized Link State Routing
olsr is a proactive ad-hoc network protocol that has been made into the experimental RFC3626[RFCOLSR]. Several implementations exist, the most popular one was originally written byAndreas Tønnesen [OLSR]. It has been adopted by freifunk.net to create free Wireless LANmeshes6.
olsr works completely on the IP layer7 and is thus easily portable throughout different phys-ical networks and operating systems. Yet, this has the disadvantage that in order to discover anode, the underlying protocol must have already established a connection. For Bluetooth con-nections, this means olsr is not suited for node discovery, but for building routing topologies.
2.2.4 Voice over Bluetooth based MANETs
In his Diploma Thesis, Stefan Ribhegge works almost on the same subject as this thesis [Ribhegge]:The establishment of Voice Communication over Bluetooth using mobile devices. However, hisfocus is on transfering voice through a pure Bluetooth network8, where this thesis uses AccessPoints to reach a central Phone Gateway. He transmits uncompressed voice data over a RF-COMM9 Bluetooth connection and designs a reactive ad-hoc network protocol suited especiallyfor Bluetooth. Due to a lack of physical devices, he extensively simulates the scalability of hisad-hoc network.
Since no implementation of the presented ad-hoc network network is made available and themethod of sending audio data is not as sophisticated as RTP, I could not directly use the con-cepts Stefan Ribhegge developed. However, the analysis of the problems concerning bluetoothnetworking and voice transmissions is very accurate.
6MESH is yet another word for ad-hoc network. see http://freifunk.net/wiki/ESSIDFreifunkNet for a list ofconnected cities.
7See [RFCOLSR], Section 3, Packet Format and Forwarding8[Ribhegge] mentions an Access Point infrastructure in his conclusions, on page 78.9Bluetooth serial line emulation
18 2 EXISTING CONCEPTS
19
3 Available DevicesThis section gives a short overview over present-day smartphone operating systems. While otherdevices can use the Bluetooth network described in this thesis, too, they will not be listed here.This is because the integration of traditional phone calls into the application is required, whichcannot be done in a PDA, for example.
Afterwards, a short overview of the device that was selected for this Thesis is given.
3.1 Operating Systems3.1.1 Windows Mobile Devices
There is a growing number of mobile phones running Windows Mobile10. These devices typ-ically offer enough computing power for VoIP, an easy-to-use graphical user interface, a BSD-style socket library for internet connections and audio input and output. It also allows placementof GSM phone calls and access to the address book. However, it seems that the number of open-source applications is rather limited, and that most available third-party software is closed-sourcefreeware, shareware or commercial software.
I was not able to find out if it is possible to load kernel drivers, for example to create a tunnelinterface or if such drivers exist.
3.1.2 Symbian Devices
Symbian11 is propably the most popular smartphone operating system12. It has different variantsthat mostly introduce new GUI classes: Nokia ships its phones with Series 6013 and Series 8014,while Sony Ericsson, Siemens and Motorola use UIQ15. Nokia has recently opened a portal foropen source software16. They are currently undertaking efforts to create an open-source VoIPframework. Using GnuBox17, it is possible to use IP over a Bluetooth connection.
While the Symbian API is well-documented, no documentation how to write drivers is freelyavailable. The Bluetooth API seems to be limited to inquiries and the creation of RFCOMMconnections.
3.1.3 Linux Devices
While many Linux smartphones18 have been released in Asia, none of them seem to have beenmade available in Europe or in the USA. This changed when Motorola started shipping its Linux
10http://www.windowsfordevices.com/articles/AT2468909181.html11http://www.symbian.org/12http://www.symbian.com/news/pr/2006/pr20063419.html13http://www.s60.com/14http://www.forum.nokia.com/main/0,6566,010_50,00.html15http://www.uiq.com/16http://opensource.nokia.com/projects/17http://gnubox.dnsalias.org/gnubox/18see http://www.linuxdevices.com/articles/AT9423084269.html for an (incomplete) list
20 3 AVAILABLE DEVICES
smartphones worldwide. In order to port a command-line application to a Linux smartphone,one only needs to compile it using a cross compiler, if the application has been programmedwith portability in mind. However, the Linux envrionment on the phone can vary strongly froma usual Linux desktop environment, thus needing some sort of adjustment. For example, mostgraphical applications for Linux are written for the X Window System, while most phones writegraphics directly to a framebuffer device. This is, however, usually not a very big problem. Forexample, all needed applications are available as command-line applications.
There are also ongoing efforts to run Linux on Windows Smartphones19.As advanced features, such as tunnel devices, or Bluetooth IP connections exist for Linux as
open-source implementations, it should be possible to use them on the phone, and to modify tothem to suit our needs.
For these reasons, I choose the Motorola A780. It is the only Linux phone available at presentin Germany.
3.2 The Motorola A780Motorola introduced the A780 by the end of 2004. It is widely recognized as the first Linux phoneto be available in Europe and the USA20. By the end of 2005, it was available for about 420 Euroswithout an operator’s contract. There are three communities that try to get the most out of theinstalled Linux: [Motorolafans], [openezx] or ccmove21 formed to join efforts in understandingthe phone and creating applications for it.
Figure 4: The Motorola A780source: http://www.motorola.com/motoinfo/product/images/0„70,00.html
3.2.1 Hardware in General
The Motorola A780 mainly consists of 2 processors22: one so-called Application Processor run-ning Linux, and a so-called Baseband Processor which runs a proprietary realtime OS. While
19http://wiki.xda-developers.com/index.php?pagename=Xanadux20see http://linuxdevices.com/news/NS3567256959.html21http://www.ccmove.com/22see http://wiki.openezx.org/index.php/Hardware::A780
3.2 The Motorola A780 21
the Application Processor draws on the touchscreen, gets keyboard and touchscreen input, playssounds, initates phone calls and runs the programs visible for the user, the Baseband Processorcommunicates via GSM and other mobile phone technologies. both Processors talk to each otherusing USB.
The touchscreen has a resolution of 320x240 pixels and supports millions of colors. Thedevice /dev/ezx_ts tells the touch position and pressure23.
A camera and a GPS chip are also integrated into the phone. I did not try to use them.The Application Processor has 48 megabyte of RAM and 48 megabyte of DiskOnChip flash
memory. This stores various file systems.Furthermore, there is a transflash mini reader for more persistent memory, which comes
equipped with a 256 megabyte flashcard.
3.2.2 Bluetooth
The Motorola A780 is shipped with a proprietary Bluetooth stack. Ho Ming Shun, alias cyph,provided a packet to replace it with the Linux BlueZ stack24. It contains the usual BlueZ kernelmodule, library and userland tools in binary form, and an small programm that initializes theBluetooth chip and sets the hardware address.
3.2.3 Sound
The kernel uses an OpenSound System (OSS) sound driver to access the speaker and microphone.There are three sound devices: /dev/dsp, /dev/dsp16 and /dev/audio. I do not know if /dev/audiohas any purpose. Experiments showed that /dev/dsp can only output stereo, and /dev/dsp16 canonly output mono. Both use signed 16-bit (2’complements) integers. /dev/dsp can be set to 8000or 44100Hz, and /dev/dsp16 only to 8000Hz. It is possible to both write raw audio or PCM waveto the devices and to read raw audio from them.
Per default, sound output is directed to the same speaker as the ring tone. For phone conver-sations, this is annoying. Luckily, it is possible to change the sound output device to the earpiecefor phone calls. In order to do so, one opens /dev/mixer and sets SOUND_MIXER_OUTSRC25.Possible values can be found in output_enum in the linux kernel header file ezx-common.h26. Toplay a ring tone, set it to LOUDERSPEAKER_OUT, for phone conversations to EARPIECE_OUT.
3.2.4 Hardware GSM Codec
As the goal is to make VoIP phone calls, using a hardware voice codec can be a great way tosave CPU usage and battery life. According to the [openezx] wiki, the speaker and microphoneare attached to the so-called PCAP2 chip. This chip can communicate with both the Application
23see http://svnweb.gnumonks.org/trunk/a780/doc/touchscreen.txt24see http://www.motorolafans.com/index.php?name=Forums&file=viewtopic&t=160825it seems that ’alebm’ discovered this first: http://www.motorolafans.com/index.php?name=Forums&file=viewtopic&t=119026see ezx-common.h in Motorolas Linux kernel source: http://cvs.sourceforge.net/viewcvs.
py/e680/original_kernel/linux-2.4.17/drivers/sound/ezx-common.h?rev=1.1.1.1&view=markup
22 3 AVAILABLE DEVICES
Processor and the Baseband Processor. The Baseband Processor takes care of GSM coding. Itis not clear to me if GSM audio communication goes through the Application Processor at all.Also, I was not able to find a way of getting the audio stream back from the Baseband Processorafter encoding or decoding.
Fortunately, hardware GSM coding is not really necessary, as the Application Processor ispowerfull enough to do this in software.
3.2.5 Preinstalled Software
The software installed on the phone consists mostly of a modified “MontaVista Linux ConsumerElectronics Edition 3.0”. It contains a Linux kernel, version 2.4.20, and a graphical user interface,Qt/Embedded 2.3, which runs on its framebuffer device. Both Linux and Qt/Embedded have beenmodified by MontaVista and Motorola to suit their needs. The Linux modifications have beenmade public27, while Qt/Embedded exists under a proprietary license which does not requirepublishing the source code. Motorola seems to have named their distribution “ezx”, as this stringappears all over the phone.
The phone comes shipped with a number of user applications, including an e-mail client, aweb browser, a file system explorer etc. These programs can be started from the program menu.
3.2.6 Flashing
Before booting the linux kernel, the bootloader sets certain blocks on the DiskOnChip flashmemory as being write protected. These blocks cannot be modified afterwards. Two tools existto circumvent this limitation: Motorola’s Phone Services, which are not publicly available, andcyph’s flashkit28. Using cyph’s flashkit, it is possible to change the content of the read-onlyfilesystems, even to replace them with other filesystems, and to use a self-compiled the Linuxkernel.
As mistakes in this procedure can lead to an unusuable phone, I refrained from trying them.While replacing the kernel and modifiying some files in /etc could have helped to avoid someproblems, it was never really necessary.
3.2.7 Flex Bits
The A780, like most mobile phones, can be configured by so-called flex bits. These bits enable ordisable functions installed on the phone. For example, a vpn client lies in /language/preloadapps/qtapps/motoVPN.This client understands various proprietary vpn protocols. Starting the motoVPN applicationshows the client mask, but the values are instantly forgotten. Connecting to a VPN server is notpossible. This is probably because the right flexbit is not enabled.
Enabling certain flexbits also enables a built-in VoIP client, according to [Motorolafans]29.However, in order to do so, one needs Motorola’s Phone Service Tools, which are not legally
27http://sourceforge.net/projects/e68028http://www.motorolafans.com/index.php?name=Forums&file=viewtopic&t=131329http://www.motorolafans.com/index.php?name=Forums&file=viewtopic&t=1462
3.2 The Motorola A780 23
available to the public.
3.2.8 Getting a Shell
In the phone configuration, one can select wether the phone goes into modem or mass storagemode when connecting it via USB. However, when the string “MotNet” is sent to /proc/usbd-switch, it goes into networking mode and assigns itself the IP 192.168.1.2. The connected com-puter can access it using IP over USB. Two notable daemons are running on the phone: samba andtelnet. samba has 2 pre-configured shares: “home” which corresponds to /diska, and “system”which corresponds to the root directory. Telnet allows root login without a password. Both dae-mons are controlled by inetd and only allow connections coming from the networks 192.168.1/24and 169.254/16. A bash shell30 is installed on the phone, however it lacks certain functions suchas command completition and history. The installed userland lacks some important programs,such as awk, gunzip, killall, netstat, or route. This is why [openezx] advises to install busybox31,an optimized C library and userland for embedded systems.
Propably the easiest way to set the phone into networking mode is using Sam Revitch’s“USBMode for A780”32, which has a graphical user interface.
3.2.9 Filesystem Layout
After logging in as root, a bash shell is started. The system looks like a typical Linux system,having directories like /etc, /dev/, /var, /usr and so forth. mount reveals a number of mount points:
rootfs on / type rootfs (rw)/dev/root on / type cramfs (rw)none on /ram type ramfs (rw)proc on /ram/proc type proc (rw)/dev/tffsa on /usr/language type cramfs (rw)/dev/roflash2 on /usr/setup type cramfs (rw)none on /dev/pts type devpts (rw)/dev/mtdblock2 on /ezxlocal type vfm (rw,noatime)/dev/mmca1 on /mmc/mmca1 type vfat (rw,noatime)/dev/tffsb1 on /diska type vfat (rw,noatime)
The first thing to note is that mount is not completely accurate, as most of these filesystemsare readonly. In fact, /ram is writeable, but the files are erased after a shutdown. /ezxlocal is apersistent read-writeable vfm filesystem of about 5.2 megabyte, of which about half is free ona new phone. /diska is a 40 megabyte FAT filesytem, which seems to exist primarily for userdata. /mmc/mmca1 is the transflash card, which is, by default, also a FAT filesystem. The factthat /ezxlocal is a vfm filesystem is very important, as vfm supports unix special files, such asdevices nodes and symbolic links. Those are needed for various purposes.
30http://www.gnu.org/software/bash/31http://www.busybox.net/32http://lsb.blogdns.net/pages/usbmode-for-a780
24 3 AVAILABLE DEVICES
3.2.10 Installing Third-party Applications
When connecting the phone via USB, it switches into “mass storage” mode and a part of itsdisk (/diska) can be mounted by the USB. The phone recognizes files ending with .mpkg asinstallable files. An mpkg file is a gzip compressed tar archive which contains an applicationbinary, a program symbol for the menu and a .desktop file which contains pointers to those filesand the program name. Clicking on the file in the Explorer copies the application to a destinationhidden to the user (e.g. /diska/.system/QTDownload) and adds an entry to the program menu.
While Motorola apparently does not want third parties to write application for their Linuxphones33, they could not prevent the creation of unauthorized third-party application, such asEditorE34, a text editor, and eKonsole35, a text console.
3.2.11 Compiling
The Application Processor is an ARM CPU with some customizations done by intel36. Themost notable is “Wireless MMX” which consists of a parallelized floating point unit. There aretwo compilers for this chip, both based on “Crosstools for gcc”: One is called “Leprechauns”37
(based on gcc 3.3.2) and “Crosstool for EZX”38 (based on gcc 3.3.6). Both compilers seem toexhibit strange behavoir when invoked with optimization flags39.
Compiling a basic application is very easy: Instead of invoking gcc, ld, etc. one simplyprefixes these with arm-linux-, to invoke crosscompilation. For example, ‘arm-linux-gcc hel-loworld.c -o helloworld-arm‘ compiles a hello world command-line program for the arm plat-form. Things get a little more complicated when the application uses configure scripts, but usu-ally passing “–host=arm-linux” to the application works. Also, if the application-to-be-compileddepends on libraries, the easiest way is to install them all into a folder, mimicking a typical /usrdirectory layout. For example, the correct configuration to build openvpn (which depends onopenssl) looks like this:
./configure --enable-pthread --disable-lzo \--with-ssl-headers=/ezx/phone/armbuild/ezxlocal/usr/include \--with-ssl-lib=/ezx/phone/armbuild/ezxlocal/usr/lib \--prefix=/ezxlocal/usr/ --host=arm-linux
3.2.12 Writing GUI Applications
Sam Revitch published an “Unofficial EZX Software Development Kit”, which consists of Qtand EZX header files, partly reverse-engineered from the C++ object files. It does not contain,
33http://www.linuxdevices.com/news/NS9440744013.html34http://www.motorolafans.com/index.php?name=Forums&file=viewtopic&t=276235http://www.motorolafans.com/index.php?name=Forums&file=viewtopic&t=294636http://www.intel.com/design/embeddedpca/applicationsprocessors/302302.htm37http://marcus.bluetroll.se/e680/38http://lsb.blogdns.net/ezx-crosstool39https://lists.gnumonks.org/pipermail/openezx-devel/2005-November/000045.html
3.2 The Motorola A780 25
however, any library files for copyright reasons. Those must be copied from the phone to thedevelopment machine. It also includes a graphical hello world application, build instructions,and the Makefile can create mpkg files (see above). However, programs created with this toolkitfall under the GPL, as the used Qt header files are distributed under the GPL. Alternatively, onecould purchase a commercial license from trolltech (the company that develops Qt/Embedded).
3.2.13 What is not Possible
Without flashing the phone, which is risky, it is impossible to modify the root filesystem. Thismeans it is impossible to add new users, change the passwords or start daemons at boot time.
I was also incapable of accessing the syslog or dmesg, loading the IPv6 or bridge kernelmodule or getting the raw sockets kernel module to work properly.
26 3 AVAILABLE DEVICES
27
4 Network Layout
4.1 Network RequirementsAs presented in the Requirements section, the network layer that provides IP services shouldbe low-latency, secure, authenticated, self-configurating and robust. Low-latency is important,because the goal is to make phone calls, which require fast response times. The network shouldbe secure in order to prevent eavesdropping and data manipulation. Only authorized users shouldhave access to the service40. When within range of a wireless Access Point, the devices shouldconnect and configure themselves automatically. Furthermore, the network should be robustagainst disruptions and automatically re-establish connections or use redundant routes to ensurepacket delivery. Optimally, all these goals should be archieved by using free, open, standardizedcomponents.
The Mobile Device has a Bluetooth interface to do wireless networking and has limited com-puting power. This means that some requirements described above may not be feasible, or mayonly feasible at the expense of another feature. An example would be encryption, which increasesthe connection latency. If the latency is too high for telephony, encryption strength would needto be reduced41 or even disabled.
The approach used in this Thesis to build a network is first to establish basic connectivityand then to build more features on top of that. This section presents step by step how to createBluetooth IP connections, assign IP addresses, set up routing, secure the connection, and recoverfrom link failures. It then summarises what daemons must be running on the Phone Gateway, theAccess Point and the Mobile Device, and how they must be configured.
4.2 Bluetooth IP connections4.2.1 Why IP?
Theoretically, it would be possible to send and receive audio data packets directly over Bluetooth.These packets could then be translated into IP packets by the Access Points, who would sendthem to the phone gateway. This would save at least 28 bytes per packet: 20 for the IP headerand 8 for a UDP header. A GSM-encoded RTP strem generates about 52 packets per second42,so the total saved bandwidth is about 1.42 kilobyte per second. Luckily, the bandwidth is notso scarce that this type of economization is needed. Moreover, there are two reasons why thisdoes not make sense: The reason, why the Internet Protocol (IP) was invented in the first placewas to interconnect different physical networks without the need for such artificial inflexibility.
40Only “basic” authentication is required to use the network layer, as using the network is basically a “yes or no”question. More complex conditions can be implemented in the telephone gateway. This is not part of this thesis, butof a parallel master thesis.
41down to a limit where it would make no more sense to do encryption, as calculating the key would be no morechallenge for a modern computer.
42experimental value
28 4 NETWORK LAYOUT
Figure 5: Network Layout, simplified
Furthermore modifying the existing applications to not to use IP is very difficult if not impossible:For example VoIP clients typically assume that they have an IP and tell it their peers; we mightuse encryption software that uses IP-in-IP tunneling, which relies on kernel devices to tunnel IPinto IP, etc. pp. The bottom line is that the savings of not using IP on the Mobile Device is notworth the extra cost.
4.2.2 Connecting
The first step is to establish a Bluetooth connection which has IP capabilities. The mobile deviceshould scan regulary for Bluetooth devices which offer their services as an IP gateway. Thereare currently two ways to do IP over Bluetooth: One is to create a virtual serial line, calledRFCOMM43 and then create a PPP connection over it. The newer way is called PAN44 anddirectly uses the Bluetooth layer, which results in a lower per-packet-overhead45. The linuxBluetooth stack BlueZ [BlueZ] ships with a fully working PAN daemon, pand. Windows alsosupports PAN46. In order to create a PAN, one end needs to listen for incoming connections,and the other end needs to initiate the connection. The obvious choice for the listening daemonwould be to run on the Access Point, while the Mobile Device initiates the connection. In orderto do this, the Mobile Device needs to know the Bluetooth address of the Access Point, whichcannot be assumed to be known in advance, because maintaining a list of Bluetooth addresses
43http://www.bluetooth.org/foundry/adopters/document/RFCOMM_SPEC_V1.1/en/1/RFCOMM_SPEC_V1.1.zip44http://www.bluetooth.org/foundry/adopters/document/PAN_Spec_v1_0/en/1/PAN_Spec_v1_0.zip45see http://affix.sourceforge.net/affix-newdoc/Affix-enduser/c283.htmlTheoretically, when using PAN, the piconet master could do Bluetooth multi- oder broadcasts, which would result
in effective IP broad-/multicasts. However the PAN specification makes this optional: “It is left to manufacturers todevelop suitable means for providing efficient support for broadcast and multicast packets destined to these PANUs[which are nodes running PAN].” Furthermore, at PAN uses ACL-U packets, which are point-to-point.
46http://support.microsoft.com/kb/883259
4.2 Bluetooth IP connections 29
would conflict with our minimal configuration requirement. This is not a problem, however,because the Mobile Device can simply scan47 for Bluetooth devices within the connection range.However, this can take a long time (over 60 seconds), depending on the numer of Bluetoothdevices present. When only a handful of devices is present, a typical scanning time is about 10seconds. pand can perform this scanning. It can also, upon detecting a Bluetooth connectionfailure, search for another Access Point and build a new connection. The default behavior is touse SDP48, the Bluetooth Service Discovery Protocol. This means that in order to establish aPAN connection, the following steps are taken:
1. Scan for available Bluetooth devices
2. Pick an arbitrary device that has not yet been picket;if no such device is left, go back to Point 1
3. Use SDP to inquire whether the device listens on a PAN channel;if the device does not listen on a PAN channel, go back to Point 2
4. Connect to the device;if the connection fails, go back to Point 2.
5. If the connection breaks, go back to Point 1.
In practice, I was able to observe that connecting to an access point fails sometimes because ofSDP errors. It seems that there was a missing or corrupted PAN entry in the sdpd49 running onthe Access Point, but I was not able to further investigate this error. Luckily, pand can be usedwithout SDP, eleminating Point 3 in the above process, which also speeds up connection estab-lishment by about a seconds. When a connection is successfully established, a bnep interface iscreated and can be configured like any interface. Altogether, the process of inquring for devicesand establishing a connection takes about 20 seconds. This may be more if many Bluetoothdevices are present.
4.2.3 Fine-tuning the Bluetooth Connection
Each Bluetooth link has a link supervision timeout50. If no data is successfully sent or receivedover that link for the specified timeout, the link removed. BlueZ sets the default timeout to 20seconds. As quick link failure detection is wanted for phone calls, it makes sense to decrease thisvalue in accordance to other timeouts.
One might suspect that pand would use an unreliable Bluetooth connection, such as ASB,to reflect the unreliability51 of the Internet Protocol. However, the reliable ACL transport is
47see [BTCore], Volume 1, 3.3.3 Inquiry Scan Channel48[BTCore], Vol. 3, Part B Service Discovery Protocol49BlueZ SDP daemon50See [BTCore], Vol. 2, Part E, 6.22 Link Supervision Timeout51also called “best effort”
30 4 NETWORK LAYOUT
used. By default, packet are resent for an indefinite time, but it is possible to set the retransmis-sion timeout52 in increments of 0.625 ms. As packets are typically buffered for about 60 ms tocompensate for jitter delay, this value is set to 50 ms (80 time steps).
The default packet type is DH5, which allows for 300 to 320 kbit/s user data (the theoreticallimit is 433.0 kbit/s). hcitool from the bluez-utils package allows to change the packet type, butthis seems to have no effect on a connection to the Motorola A780: I measured the same 300to 320 kbit/s for any packet type, which is more than the theoretical maximum for every otherconnection type.
4.2.4 Multiple Connections
Since a piconet can consist of up to 8 devices (1 master & 7 slaves), the Mobile Device canconnect to more than one Access Point at a time53. However, each pand can only create oneconnection. This would mean that if we want to connect to two Access Points using existingtools, we would need to run two pands. This introduces a range of problems: First of all, startingtwo pands simultaneously leads to both performing inquiries at the same time. If they both try toconnect to the same host at the same time, race conditions might occur, as BlueZ tracks its panconnections by Bluetooth address. Furthermore, as one pand creates its connection, and uses it toprovide an IP layer, the other one will constantly try to discover and connect to an Access Point.This interferes with sending Bluetooth user data, i.e. the IP layer: Bluetooth divides its basebandinto 79 physical channels and changes the channel it uses 1600 times per second54. However,when inquirying, this frequency is slowed down to make it easier for devices to be found55.This changing of the channel hop frequency interferes with the correct sending and receptionof the user data. This behavior can easily be observed when sending ICMP ping requests to aBluetooth device: With only one connected pand, the average round trip time (artt) is 34.001ms with a standard derivation (sder) of 11.880 ms. When one pand is running and the other isinquirying, these values drastically increase to an artt of 184.168 ms with a sder of 292.543 ms.When both pand are finally connected, this still has an impact on the connection, as the artt andthe sder increase to 82.302 ms and 27.824 ms, respectively.
To solve the inquiry problem, I modified pand to support multiple connections using threenew command-line arguments: maxconn, inqint and lockfile. Instead of opening only one con-nection and waiting for it to break down, it tries to create up to <maxconn> connections after thefirst inquiry. It then waits <inqint> seconds for connections to break down, and, if <maxconn>connections have not been reached, it performs a new inquiry and tries to connect to more AccessPoints. This reduces the amount of time spent inquiring and thus improves connection quality.Furthermore, if used with the lockfile argument, it only inquires if no connection is currentlyestablished or if it can acquire an advisory write lock56 on the <lockfile>. This way, the phoneapplication can simply writelock the <lockfile> when making a phone call, which will then be
52see http://people.csail.mit.edu/albert/bluez-intro/x556.html#bzi-l2cap-unreliable53It can connect to an arbitrary number of Access Points, if it connects in slave mode.54see [BTCore] Vol. 1, Part A, 1.2 “Nomenclature”, p. 9155[BTCore], Vol 1, Part A, 3.3.3.2 Characteristics56http://www.erlenstar.demon.co.uk/unix/faq_3.html#SEC35
4.3 Choosing an IP Address 31
undisturbed by inquiries. I submitted this patch to BlueZ, but it did not get accepted because itsimply was too big. I will split it into smaller parts and try to submit it as soon as I find the time.
4.2.5 Encountered problems
As described in 4.2.2 on page 28, using SDP caused some problems which could be solved bynot using SDP.
If the connection loss is only detected on one side of the connection, the other side leaves theconnection open and refuses further connections from the same device with the error message“bnep0: file exists”, until the connection times out. As connections time out rather fast, thisshould not be a problem.
On the A780, it is not possible to auto-configure the freshly created interface, as the root filesystem is write-protected. However, the pand knows when it creates an interface and I created apatch57 that runs an arbitrary script after creation. This patch was accepted by BlueZ maintainerMarcel Holtmann and will be in the next bluez-utils release. Now, it is trivial to configure theinterface once it comes up.
4.2.6 Security Implications
Encryption and authentication are not issues, they will be handled later on in this chapter. How-ever it is be possible to conduct a denial of service (DoS) attack by installing fake Access Points,which provide PAN service but no IP access. The device could detect this by measuring linkquality to the telephone gateway on a per-Access Point basis. However, in its current implemen-tation, the Mobile Device only changes the Access Point when the Bluetooth connection failsand not when it fails to do proper IP routing.
4.3 Choosing an IP AddressAs one or more interfaces capable of IP are supplied by pand, we need to assign IP addresses.There are basically three ways to do it: 1) assign a static address, 2) get a dynamic address usingDHCP58, or 3) use IP zero-configuration59, also called zeroconf. Assigning a static IP contradictsour minimal configuration requirement, as each Mobile Device would need a user configuringits IP address. Unfortunately, using DHCP does not work on the A780. In order to use DHCP,raw socket support is needed, which requires a kernel module. I was able to compile it and loadit on the A780. Sending DHCP packets was also possible. However upon reception of a DHCPpacket, the phone crashed, which turned the screen black and required removing the battery inorder to boot again. I was not able to fix this.
The last choice is using zeroconf. According to its specification60, an address from the169.254/16 subnet should be choosen pseudo-randomly. Then, ARP packets are sent in order
57see http://article.gmane.org/gmane.linux.bluez.devel/690958http://www.ietf.org/html.charters/dhc-charter.html and http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol59http://www.zeroconf.org/60http://files.zeroconf.org/rfc3927.txt
32 4 NETWORK LAYOUT
to detect address conflicts61. Obviously, a user space implementation also needs access to rawsockets in order to send ARP packets. However, we can (unsafely) assume that the probabilityfor an address conflict is relatively small. Of course, the more devices are connected, the higherthe risk of IP conflicts.
I wrote an IP zeroconfigurator for linux, which generates an IP address based on the interfacehardware address and the system clock and does not use any mechanism to check for addressconflicts. I can be found on the enclosed CD or on the website of the thesis (see section 6,“Conclusions and Outlook” on page 51).
In the case of using olsr (see below), there is an olsr plugin which assigns addresses auto-matically in a similar manner to zeroconf and uses olsr to detect and repair address conflicts.However, it has never been released due to software patent issues. Please note that there iscurrently a discussion going on62 how to detect and react to address conflicts in olsr, as this isconsidered a severe problem.
4.3.1 Issues with the Motorola A780
On the Motorola A780, telnetd allows root access without a password, if the client IP comes fromthe 192.168.1/24 or 169.254/16 subnets. As the root filesystem is write-protected, this cannot bechanged without flashing the phone, from which I refrained. Thus, 169.254/16 is not an optimalsubnet for IP autoconfiguration. The 10.1/16 subnet is used.
4.4 Routing to the Phone GatewayThe Mobile Device needs to be able to establish an IP connection to the Phone Gateway, usingthe Access Point. As the AP already has a route to the PG, it simply routes the packet whiledoing Network Address Translation to hide the Mobile Device’s private IP address.
4.4.1 Static Routes
As long as each Mobile Device is only connected to one Access Point, routing can be very easy.The Mobile Device only needs to know the Access Point’s IP address, which it uses as a gateway.The Access Point does not need to know the Mobile Device’s IP address in advance, it simplyroutes the responses using Network Address Translation. It suffices to give each Access Pointthe same IP address, e.g. 10.1.0.1. No Mobile Device may pick this address then, of course. Thisobviously no longer works if a Mobile Device is connected to more than one AP.
4.4.2 Uses and Non-Uses for olsr
Another approach is to use an ad-hoc networking algorithm63. The olsr.org OLSR daemon isa popular implementation of the Optimized Link State Routing protocol[RFCOLSR]. It can be
61see rfc3927, 2.2. Claiming a Link-Local Address, et. seqq.62http://www.olsr.org/pipermail/olsr-users/2006-February/069782.html63see http://en.wikipedia.org/wiki/Ad_hoc_network
4.5 Securing the Connection 33
easily deployed under Unixoid and Windows operating systems. When the daemon is running,it broadcasts so-called HELLO messages every given interval (default is 20 times per second)on every (specified) interface. When it receives a HELLO message from another host, it addsit to its list of direct neighbours. Those neighbours then exchange topology information, whichmeans that each host tells the other one which routes it has to other hosts. Routes are usuallycalculated using a shortest path metric, but there is also an option to use a link quality metric,which is based on packet loss statistics. While this may seem optimal for our needs, there is onebig drawback: An arbitrary number of routers exists between the Access Point and the PhoneGateway, and we cannot install and run olsr on everyone of them64. One or more routers (notrunning olsr) between two hosts result in those hosts not “seeing” each other, and thus not findinga route between the Phone Gateway and the Access Point, because the routers do not forwardbroadcasted packets. Even if they did, it would result in the Phone Gateway thinking it has aroute to a 10.1/16 address, which would be discarded by the first router anyway. Thus, olsrcannot replace NAT on the Access Point.
However, olsr can be useful in trying to expand the range of the Bluetooth network: If a pandalso listens on the Mobile Device “A”, another Mobile Device B, that is not within range of anAccess Point, could connect to the Mobile Device A that has a connection to the Access Point.olsr would calculate a route from B to the Phone Gateway through A.
Also, if the Mobile Device is connected to multiple Access Points, the routing scheme for“static routes” does not work anymore. olsr is a good solution for this. Using HELLO pack-ets, it collects information about its network neighbourhood. Nodes can advertise routes outsideof the olsr network using so-called Host and Network Association (HNA) messages65. EachAccess Points thus announces a route to the Phone Gateway. Note that each Access Point alsoneeds to add the Phone Gateway to its own routing table for the following reason: If a MobileDevice is connected to two Access Points, both will advertise a connection to the Phone Gate-way with netmask 255.255.255.255. The Mobile Device will forward these HNA messages toeach Access Point. If the Access Point doesn’t already have an entry for the PG with netmask255.255.255.255, olsrd adds it, using the other Access Point as a gateway. Now the first routeto the PG in each AP is through the other AP. Both Access Points would forward messagesdesignated to the Phone Gateway to each other, without ever reaching it.
4.5 Securing the Connection
So far, all communication channels are completely insecure: All Bluetooth communication canbe listened to using the right equipment66, as it is completely unencrypted. The IP layer is com-pletely unencrypted too, which means that a malicious Access Point can intercept and manipulate
64This has a number of reasons: First of all, routers are a critical infrastructure and an arbitrary daemon runningon one of them increases the “threat surface”. Secondly, there might not be an olsr implementation for the routeroperating system. Lastly but no least, we might not even have administrative access to these routers because theybelong to a “third party” network that we route our traffic through.
65see Chapter 12 of rfc 3626 “Non OLSR Interfaces”66See Frontline http://www.fte.com/ and LeCroy/CatC http://www.lecroy.com/ for devices that allow so called
“on the air” sniffing
34 4 NETWORK LAYOUT
the communication at will. Furthermore, as the Access Point accepts Bluetooth connection fromand provides IP routing for everybody, anyone can use this network to access the internet. Insome cases, this might be undesired.
4.5.1 Bluetooth Encryption
An obvious choice would be to use Bluetooth encryption. Virtually all Bluetooth devices supportthis feature, and it is, in general, considered to be secure67. However, this does not apply for ourscenario. In order to establish a secure channel with another Bluetooth device, a pre-sharedsecret, called PIN is needed. A symmetric key is generated from this PIN. On customer devices,this PIN is usually consists of 4 or 5 digits, but it can be an UTF-8 string of up to 16 bytes68.If a whole network would use this PIN to encrypt its communication, anyone knowing this PINcould, from a theoretical point of view, decrypt all communication69. An equivalent scenariowould be to encrypt a network using AES and publish the AES key, which would compromisesecurity.
Most importantly, the encryption ends at the Access Point, which means that the AccessPoint, or any host that can manipulate the communication between the Mobile Device and thePhone Gateway, can jeopardize the data. The bottom line is that Bluetooth encryption is notsuited for our scenario. Still, if other means of securing the connection are not feasible, wecould use Bluetooth encryption to make it hard, altough not impossible, to manipulate or sniffthe communication “on the air”.
4.5.2 openvpn
Another obvious option for network security is the creation of a virtual private network (vpn).Many open-source projects exist70. The most notable are FreeS/WAN71 and openswan72 whichboth enable IPsec in the Linux kernel. However, these require rather big modifications to theLinux kernel. In contrast, openvpn73 runs in userland and only needs the tun kernel module74.
openvpn is an open-source project that can be used to create TLS75-encrypted point-to-pointconnections. In order to establish such a connection, both client and server first exchange theirpublic keys. openvpn requires countermeasures to disable man-in-the-middle-attacks. The best
67The trifinite group http://trifinite.org/ which is a group of Bluetooth security experts that recently startedcollaborating with the Bluetooth Special Interest Group, said in its presentation at the Chaos Communi-cations Congress 2005: “Bluetooth is secure standard (per se). Problems are at the application level”http://trifinite.org/Downloads/trifinite.presentation_22c3_berlin.pdf page 45
68see [BTCore], Vol. 3, Part C, 3.2.3 “Bluetooth passkey (Bluetooth PIN)”69In practice, there are some obstacles: An attacker would need to sniff the key exchange of two devices or use
an attack like BlueDump http://trifinite.org/trifinite_stuff_bluedump.html to reset this key.70for a list of IPsec implementations for linux, see http://www.openswan.org/docs/feature_comparison.php71http://www.freeswan.org/72http://www.openswan.org/73http://openvpn.net/74The tun kernel module has only a memory size of about 4128 bytes, and an active openvpn client consumes
about 1708 kilobyte of resident memory, including shared libraries.75http://www.ietf.org/html.charters/tls-charter.html
4.6 Link Failure Detection and Recovery 35
way to do so is to create a Certificate Authority (CA) which signs the servers public key. The CA’spublic key can be installed on the Mobile Device together with the phone application, so that theMobile Device can verify the server’s public key integrity. Using this secure, but slow channel,both sides can exchange a symmetric key and use it to encrypt their communication. Each hostin the VPN thus is assigned an IP address which can be used for secure communication. openvpnsupports Pluggable Authentication Modules (PAM)76, which means that in order to connect to theVPN, the clients needs to supply openvpn with a username and password, which could be verifiedusing an existing LDAP server. The openvpn server can run on the Phone Gateway, securing allcommunication between the Mobile Device and the Phone Gateway. Furthermore, openvpn canbe configured to ignore from which real IP an encrypted packlet comes, thus allowing clients tochange their IPs while maintaining their VPN channel. However, a change of IP address is onlyallowed after the connection from the current IP times out. The implications of this are discussedin section 4.6.
openvpn creates a network interface, usually called tun0. This interface will be auto-configuredfor an IP from the VPN’s address pool by the openvpn server.
4.5.3 About Internet Access
While the main goal of the network is to enable VoIP communication, normal IP communicationis established as well. If the Mobile Device advertises the whole internet (0.0.0.0/0) instead ofonly the Phone Gateway via HNA, any connected Bluetooth device can access the internet. Ifthis is not desired, the Access Point must block all traffic coming from any Bluetooth interfaceand not going to the Phone Gateway.
If only authenticated users are allowed to access the internet, the easiest solution is to letthe Phone Gateway do network address translation. In this way, the internet connection is alsoencrypted between the PG and the Mobile Devices.
Finally, if no internet access at all is desired, the Phone Gateway simply does not translatenetwork addresses, nor does it route packets from the vpn to hosts outside the vpn.
Note that it is impossible to “only allow DNS traffic”, for example in order to resolve thePhone Gateway’s name. The trivial approach is to only allow UDP traffic port 53, which is thedefault port of DNS. However, any UDP traffic, such as a openvpn’s IP-over-UDP tunnel, coulduse the Access Point to access the Internet. Even if DNS traffic is checked at application level, itis possible to build an IP tunnel through77.
4.6 Link Failure Detection and Recovery
As long as only one Bluetooth connection is established, link failure detection is not critical.When the only link goes down, it takes about 30 seconds (in the best case) to establish a newconnection. This interrupts any ongoing phone conversation, of course. However, if multipleconnections are established, it is critical to detect a connection break in order to use alternative
76http://www.kernel.org/pub/linux/libs/pam/77see http://thomer.com/howtos/nstx.html for a howto. It is also possible to build an IP tunnel over ICMP.
36 4 NETWORK LAYOUT
paths. olsr was explictly created for this purpose. It sends HELLO packets regulary, and if 3HELLO packets are not acknoledged, it decides that the link is broken78. It then calculates newroutes, if possible.
Both olsrd and openpvn modify the routing table. By default, this leads to a broken connec-tion if routes change. Here is an example of a routing table, modified by olsrd only, for a MobileDevice connected to two Access Points:
Destination Gateway Genmask Flags Iface5.6.7.8 10.1.0.1 255.255.255.255 UGH bnep15.6.7.8 10.1.0.2 255.255.255.255 UGH bnep010.1.0.1 0.0.0.0 255.255.255.255 UH bnep110.1.0.2 0.0.0.0 255.255.255.255 UH bnep010.1.0.0 0.0.0.0 255.255.0.0 U bnep010.1.0.0 0.0.0.0 255.255.0.0 U bnep1127.0.0.0 0.0.0.0 255.0.0.0 U lo
The bnep0 and bnep1 Bluetooth interfaces, created by pand, are both configured to haveaddresses from the 10.1.0.0/16 subnet. olsrd detected that these interfaces are connected to thehosts 10.1.0.1 and 10.1.0.2, respectively. Furthermore, both hosts advertise that they can act as arouter to the Phone Gateway, 5.6.7.8.
Now when openvpn connects, it will add routes to the Phone Gateway and a default routeusing the encrypted connection. Note that openvpn assigns IP addresses in pairs (here: 10.8.0.5and .6), where the lower address is the gateway address. As the openvpn server only respondsto its real vpn address (here: 10.8.0.1), the first entry simply makes sure it is sent to the rightdestination.
Destination Gateway Genmask Flags Iface10.8.0.5 0.0.0.0 255.255.255.255 UH tun05.6.7.8 10.1.0.1 255.255.255.255 UGH bnep15.6.7.8 10.1.0.2 255.255.255.255 UGH bnep010.1.0.1 0.0.0.0 255.255.255.255 UH bnep110.1.0.2 0.0.0.0 255.255.255.255 UH bnep010.8.0.1 10.8.0.5 255.255.255.255 UH tun010.1.0.0 0.0.0.0 255.255.0.0 U bnep010.1.0.0 0.0.0.0 255.255.0.0 U bnep1127.0.0.0 0.0.0.0 255.0.0.0 U lo0.0.0.0 10.8.0.5 128.0.0.0 UG tun0
Note that olsrd usually only adds one of multiple HNA entries to the same destination. How-ever, if a Bluetooth connection is destroyed, all of its routes are destroyed automatically. olsrdrepairs new HNA routes only after a few seconds, so for a short time, there would be no routeto the Phone Gateway. Using a simple patch79, olsrd adds multiple HNA routes to the samedestination, if they all share the same (lowest) hopcount. Thus, if one connection fails, there isstill a valid entry in the routing table to the Phone Gateway.
78see the olsr.conf manpage for HelloValidityTime http://www.olsr.org/docs/olsrd.conf.5.html79see the patches direcory on the enclosed CD
4.7 Latency 37
Also, note that openvpn thinks it added the currently active route to the Phone Gateway to therouting table, despite the fact that it already existed. Thus, when exiting or re-starting, it removesthis entry. olsrd meanwhile does not re-add it, as it keeps an internal list of its modifications tothe routing table, and thus thinks the route still exists. This behavior can be corrected, however,by telling openvpn to not automatically modify the routing table (route-noexec) but to run thecommands specified in the route-up options (see A.3 on page 55 in the appendix)80.
If an interface is destroyed but another connection exists, openvpn simply uses the new route.However, this means that from the Phone Gateways point of view, the openvpn client changedits IP address81. Thanks to the “float” option82, the openvpn server will accept packets fromany host if the link key is valid. This allows fast connection re-establishment when the client IPaddress changes. However, it requires the connection to time out first. As openvpn uses UDPpackets, it can freely define the meaning of timeout. Since a quick recovery from link failures isnecessary, openvpn was configured to send a keep-alive message once a second, and consider 3seconds without a message a timeout.
Unfortunately, when a new Bluetooth connection comes up, olsrd may change the routingtable to use a new Access Point as router to the Phone Gateway. This breaks the vpn connectionin the same way as if a link went down. After the servers ping timeout period, it will detect alink failure. This seems absurd as the creation of a new connection should make a network morestable, not interrupt it. However, it is unlikely that a new Bluetooth connection will be createdduring a phone call. Using the lockfile option, no inquiries will be made during a phone call. Butthe phone could just have finished inquiring and try to connect to new devices at the beginningof a phone call. This can lead to a connection interruption just at the beginning of the phoneconversation.
This is also the reason why the oslrd’s Link Quality metric should not be used: It would causethe Mobile Device to change Access Points rather ofter. Each such change would need to triggerthe timeout in the openvpn server before the new Access Point could be recognized.
4.7 Latency
Depending on the internet connection quality, a latency of up to 60 ms between Access Pointand Phone Gateway can be considered normal83. The Bluetooth PAN connection between theAP and the Mobile Device further adds about 50-70 ms, and the vpn tunnel adds 40-60 ms. Inthe worst case, this is a raw network delay of about 200 ms. Additionally, the audio data mustbe read from the sound card, encoded, sent, received, buffered to compensate for jitter, decodedand written to the soundcard buffer. In total, this accumulates to a little less than one second ofaudio delay, measured by saying “ping” into the phone.
80Furthermore, openvpn refuses to automatically add a default gateway if none previously existed. This behavioris not reflected in the above routing table, in order to simplify matters. It is not very important, as the route-upcommands fix this behavior, too.
81as the different Access Point have different IP addresses and do network address translation for the MobileDevice
82see the openvpn vpn page, http://openvpn.net/man.html83of course, if the Phone Gateway is on the same ethernet, or very close, it usually is less than 10 ms
38 4 NETWORK LAYOUT
4.8 SummaryThe Phone Gateway runs asterisk, or a similar telephony server, as a Back to Back User Agent84.It also runs openvpn in server mode. openvpn uses PAM to verify user credentials. Depending onthe administrator’s choice, the Phone Gateway does or does not do network address translation.
Each Access Points runs a listening pand, to allow Mobile Devices to connect. IP addressfrom the 10.1.0.0/16 subnet are assigned to the bnep interfaces created by pand. Access Pointsdo network address translation so that the Mobile Devices can connect to the Phone Gateway.Depending on the administrator’s choice, all connections to hosts that are not the Phone Gatewayare blocked. Furthermore, olsrd is running on all bnep interfaces, and annouces routes to thePhone Gateway.
On each Mobile Device, pand is running and tries connect to multiple Access Points. IPaddresses from the 10.1.0.0/16 subnet are assigned to the bnep interfaces created by pand. olsrdruns on all bnep interfaces and adds routes to the Phone Gateway. openvpn tries to create a secureconnection to the Phone Gateway.
olsrd on both sides send HELLO packts every 2 seconds. Bluetooth tries to resend packetsfor 50 ms, and considers a link to be broken is no packets are successfully transmitted or receivedfor 2.5 seconds. openvpn on both sides send keepalive messages once a second, if no other trafficgoes through the secure channel. Both openvpn endpoints consider the connection to have timedout when no traffic from the other side has been received for 3 seconds. In this case, the openvpnserver accept valid encrypted packets from any IP address for fast connection re-establishment.
If the active Bluetooth connection breaks, and another Bluetooth connection can be used asa fallback, the secure channel is interrupted for about 3 to 4 seconds.
84see “SIP and RTP” on page on page 16
39
5 The Phone ApplicationThe user wants the unified phone application to make both GSM and VoIP phone calls, accessthe address book and do all necessary configuration. This section gives an overview how it hasbeen implemented on the Motorola A780, or why it could not implemented.
Figure 6: A screenshot of the phone application
5.1 Initializing Existing SoftwareUsually, necessary initializations, such as starting the right daemons and loading the kernel mod-ules is done at boot time. However, this is not possible on this platform, so it has to be done bythe application. For this, it needs to have root privileges. One way of archieving those would beto set the suid bit, but it is easier to call the start-stop-daemon installed in /sbin, as this does notrequire a chmod85.
85The application could be installed somewhere where a suid is impossible, such as a FAT filesystem
40 5 THE PHONE APPLICATION
First of all, a script loads the BlueZ module, modified by Ho Ming Shun, and starts theBluetooth daemons hcid and pand. It then inserts the tun kernel module to be used by openvpn.It can also starts olsrd and sets a nameserver.
The phone application directly loads openvpn and communicates with it through a Unix pipe.This is needed because openvpn prompts for a username and password, which get passed toPAM modules for authentication. Normally, openvpn does not support this behavior, and wantsthe data to be written into a temporary file or to be read from a tty. openvpn was modified to readfrom stdin.
After an openvpn communication is established, linphone86 is started and registers itself atthe Phone Gateway. This is needed in order to receive incoming calls.
5.2 Configuration
All user-configurable options can be accessed in the “Configuration” menu. These options arethen serialized and stored to a file.
Furthermore, options relevant for VoIP are written to the linphone configuration file. Afterwriting the new configuration files, openvpn is restarted and linphone is terminated until a newvpn connection is established.
5.3 Link Quality
Twice a second, the client sends a ping (ICMP request) to the Phone Gateway. Once a seconds,the number of received ICMP replies is read and written into a ring buffer of length 8. Then,link quality is derived by calculating the quota of received packets and scaling to 8. This is thendisplayed on the phone statusbar, right next to the usual GSM reception strength. This can beseen on the presented screenshots.
As an alternative to sending 2 ping packets per second to the Phone Gateway, a numbermethods exist to measure the Bluetooth link quality. The obvious choice, ‘hcitool lq‘, alwaysreturns 255 on the Motorola A780. ‘hcitool rssi‘ returns more meaningful values. ‘ifconfigbnepX‘ always shows 0 errors. On link failure, the link is destroyed without showing a singleerror. Finally, one could use the link quality extension of olsrd and parse the value of the currentlink. All these techniques do not show how good the connection to the Phone Gateway is.
I was not able to find a way to read the GSM reception strength. However, it is displayed inthe upper left corner on the screen, so the user will see it all the time.
5.4 Making and Answering Phone Calls
In order to make any phone call, the user enters a phone number. Then, he or she can click onGSM or VoIP, depending which kind of phone call is desired. Alternatively, the user can set themode to Auto, to let the phone decide what type of call should be made. Currently, VoIP calls
86see 5.5 on the next page
5.5 VoIP calls 41
are only made when the link quality is better than 5/8. Ideally, a price table could be entered intothe phone, so that it automatically uses the cheapest method, but this was not implemented.
While calling, the application writelocks /ezxlocal/blue.lock so that pand does not inquire.Tests have shown that inquiries during a phone call distrupt the call.
5.5 VoIP callsA number of open-source VoIP phones exist, most notably linphone, KPhone and minisip. lin-phone has decent speech quality, a command-line client and detailled build instructions for cross-compiling, so it was the application of choice.
If the user receives a VoIP phone call, linphone signals by using a ring sound and writinga notice to standard out87, which is redirected to the unified phone application. I modified lin-phone to switch the sound output to the loudspeaker, before sending the ring sound. The user isprompted whether he or she wants to pick up or ignore the phone call, and linphone is told soaccordingly. If the user picks up, the sound output is switched to the earpiece.
Figure 7: Incoming phone call. (Note: the phone number has been edited)
87I needed to tell linphone to flush its output after each message. see man 3 fflush
42 5 THE PHONE APPLICATION
After modifying linphone to use the right sound device, /dev/dsp16, it did not seem to workvery well. There was no sound output at all on the Mobile Device, and the sound output onthe other end was so disturbed that the words were completely incomprehensible. It soundedlike there were “holes” in the voice data. These problems were not due to insufficient CPUpower: If the thread finds that it is too slow to process the VoIP data, it outputs “Must catchup nmiliseconds”88.
5.5.1 Fixing the Audio Output on this Side
When starting linphone with the option ’-d 6’, it shows all debugging output. The problem wasobvious, since this message was repeated over and over:
rtp_getq(): asking for too old packet ! oldest=52765
Upon reception of an RTP packet, linphone stores it in a list, which is ordered by timestamp.linphone builds a list of so-called MSFilters89 for each stream: one filter for audio input and onefor audio output. A typical setup is that one filter chain reads from the sound card, encodes theaudio data and sends it in an RTP packet. The other filter chain consists of a filter processingincoming RTP packets, a filter to decode them and finally a filter to output the audio data usingthe sound card. A filter that does not have any input filters is called a source filter. Here is anexample output of a filter chain:
Message:ms_filter_add_link: OssRead,0 -> GSMEncoder,0Message:ms_filter_add_link: GSMEncoder,0 -> RTPSend,0Message:ms_filter_add_link: RTPRecv,0 -> GSMDecoder,0Message:ms_filter_add_link: GSMDecoder,0 -> OssWrite,0
Upon each iteration of the main loop90, the thread first processes all source filters and thenprocesses chained filters. The RTPRecv process function91 remembers the timestamp of the lastprocessed packet in the variable MSRtpRecv.prev_ts. At the beginning of an RTP stream, it isinitialized to 0. It then uses rtp_session_recvm_with_ts()92 from the oRTP93 library to get apacket with this timestamp, and any newer packet, from the list of received packets. As RTPtimestamps do no necessarily start at 0, the oRTP library remembers the difference between theactual RTP timestamp and the representation for linphone. It also makes sure that enough packetsare buffered to compensate for jitter. Then it calls rtp_getq()94 to finally get the right packet. Or,in this case, to see that the requested timestamp already was discarded.
88see ms_timer_synchronize() in mediastreamer/mstimer.c, line 58 et.sqq89the MS stands for MediaStreamer. See mediastreamer/msfilter.h line 40 et.sqq.90ms_thread_run() in mediastreamer/ms.c, line 153 et.sqq91ms_rtp_recv_process() in mediastreamer/msrtprecv.c, line 90 et.sqq92in oRTP/src/rtpsession.c, line 1341 et.sqq93http://linphone.org/ortp/94oRTP/src/rtpmod.c, line 71 et.sqq.
5.5 VoIP calls 43
The first attempt to fix this problem was to simply ignore the error and return the oldestpacket. This worked, but introduced a rather high latency of about 6 to 10 seconds to the voiceconnection.
As this was not very desirable, I decided that the calculation of the requested timestamp wassomehow erroneous and that maybe the simplest way to fix the problem was to ignore it. Inrtp_session_recvm_with_ts(), I used the timestamp from the first packet of the list, and addedthe jitter delay, converted to timestamp scale (RTPSession.rtp.jittctl.jitt_comp_ts). This howeverbrought me back to the initial problem, where no sound was played at all, because the packetswere discarded too soon. Adding an arbitrary value, instead of jitt_comp_ts, solved the problemsomehow. This lead to the conclusion that the jitter compensation delay simply was too big: Itis calculated in jitter_control_set_payload()95, based on the JitterControl.jitt_comp variable (inmilliseconds) and the clock rate96 of the voice codec. The jitt_comp variable is read from aconfiguration file97, the default value is 60. The maximum of this value and the block size ofthe sound card, divided by 8, is finally used as jitter delay98. The sound card block size on theMotorola A780 is uncommonly high, 8192, which results in a jitter delay of 1024 milliseconds.By removing the comparison to the sound card blocksize, the jitter delay is set to the defaultvalue of 60. This leads to a clear, low-delay audio output.
5.5.2 Fixing the Audio Output on the Other Side
As the previous problem was a timestamp problem, it was self-evident to first investigate in thisdirection. The RTPSend process function99 calls get_new_timestamp()100 to generate a times-tamp. linphone uses two methods of timestamp creation: Section 5.1, of [RFC 1889] “FixedHeader Fields” defines: “If RTP packets are generated periodically, the nominal sampling in-stant as determined from the sampling clock is to be used [to generate the timestamp], not areading of the system clock”. linphone does exactly that by incrementing the last timestamp(MSRtpSend.ts) for each packet by the codec-dependent value MSRtpSend.ts_inc. However, italso calculates an up-to-date timestamp clockts from the system clock. If clockts is newer101 thants+2*ts_inc, it is used, otherwise ts+ts_inc is used102.
On the Motorola A780, clockts is almost never newer than ts+2*ts_inc. By eleminating theRFC-compliant behavior and simply always calculating the timestamp from the system clock,the sound quality is acceptable103. I then compared the actual incrementations to the ones thatwould have been done by ts_inc. The output is basically a repetition of the following:
clock inc: 0, clockts/ts+inc diff: -160
95oRTP/src/jitter.c, line 58 et.sqq.96The clock rate defines how long a timestamp is.97rtp_config_read(), core_api/linphonecore.c, line 654 et.sqq.98see core_api/linphonecore.c, line 134699ms_rtp_send_process in mediastreamer/msrtpsend.c, line 107 et.sqq
100see mediastreamer/msrtpsend.c, line 84 et. sqq101A newer timestamp has a bigger value.102mediastreamer/msrtpsend.c, line 91 to 99103However, from time to time, this method does not seem to work and the audio is completely scrambled again
44 5 THE PHONE APPLICATION
clock inc: 80, clockts/ts+inc diff: -80clock inc: 80, clockts/ts+inc diff: -80clock inc: 0, clockts/ts+inc diff: -160clock inc: 80, clockts/ts+inc diff: -80clock inc: 80, clockts/ts+inc diff: -80clock inc: 0, clockts/ts+inc diff: -160clock inc: 80, clockts/ts+inc diff: -80clock inc: 0, clockts/ts+inc diff: -160clock inc: 80, clockts/ts+inc diff: -80clock inc: 80, clockts/ts+inc diff: -80clock inc: 0, clockts/ts+inc diff: -160clock inc: 80, clockts/ts+inc diff: -80clock inc: 80, clockts/ts+inc diff: -80clock inc: 0, clockts/ts+inc diff: -160clock inc: 80, clockts/ts+inc diff: -80clock inc: 0, clockts/ts+inc diff: -160clock inc: 80, clockts/ts+inc diff: -80clock inc: 80, clockts/ts+inc diff: -80clock inc: 0, clockts/ts+inc diff: -160clock inc: 80, clockts/ts+inc diff: -80clock inc: 80, clockts/ts+inc diff: -80clock inc: 0, clockts/ts+inc diff: -160clock inc: 80, clockts/ts+inc diff: -80clock inc: 0, clockts/ts+inc diff: -160clock inc: 2880, clockts/ts+inc diff: 2720
The ts_inc of the GSM codec is 160, so the RFC-compliant behavior would be to increase thetimestamp by 160 on each iteration. However, this listing shows that packets are sent ratherirregulary: more often than they should, and then not at all for a short period of time. Note thatthe total timestamp increase in this listing only differs by 80 from the RFC-compliant increase.
One explanation would be that the that the system clock is unreliable and glitches, and the“holes“ in the audio stream are cause by the sudden ’big’ increase caused by clockts: As clocktsregulary suddently is much bigger than ts+2*tc_inc, it will get used. This leads to the times-tamp being increased 50% faster than it should. Changing the comparision from “clockts >ts+2*tc_inc” to “clockts > ts+4000” leads to a constant timestamp increase of 160. However, itdoes not improve voice quality at all. So the most propable explanation is that the system clockis accurate and that some sort of scheduling problem interrupts audio encoding regulary. Thisalso explains why the audio sounded like it had “holes” in it: the timestamp should have beenincreased by a smaller value than it was. As a result, the audio was playing too late, with nothingin between.
Still, this is not a perfect solution. About every third loop iteration, the timestamp does notincrease at all, which means that two packets arrive for the same timestamp. In other words:about 1/4 of the packets are discarded.
5.5 VoIP calls 45
A simple approach is to simply smooth those incrementations: Since we know that the typ-ical increase is 80, 0, 80 we can change it to 80, 40, 40 by checking if the timestamp actuallyincreased. If it isn’t, it will be increased by ts_inc/4. This delivers a good sound quality. How-ever, it is not a very clean solution, as ts_inc/4 was simply interpolated from the need to somehowget the value 40. Still, this solution works for other codecs too, such as ALAW and ULAW. Hereis the output this method:
clock inc: 40, clockts/ts+inc diff: -120clock inc: 40, clockts/ts+inc diff: -120clock inc: 80, clockts/ts+inc diff: -80clock inc: 40, clockts/ts+inc diff: -120clock inc: 40, clockts/ts+inc diff: -120clock inc: 40, clockts/ts+inc diff: -120clock inc: 40, clockts/ts+inc diff: -120clock inc: 80, clockts/ts+inc diff: -80clock inc: 40, clockts/ts+inc diff: -120clock inc: 40, clockts/ts+inc diff: -120clock inc: 80, clockts/ts+inc diff: -80clock inc: 40, clockts/ts+inc diff: -120clock inc: 40, clockts/ts+inc diff: -120clock inc: 40, clockts/ts+inc diff: -120clock inc: 40, clockts/ts+inc diff: -120clock inc: 80, clockts/ts+inc diff: -80clock inc: 40, clockts/ts+inc diff: -120clock inc: 40, clockts/ts+inc diff: -120clock inc: 80, clockts/ts+inc diff: -80clock inc: 40, clockts/ts+inc diff: -120clock inc: 40, clockts/ts+inc diff: -120clock inc: 40, clockts/ts+inc diff: -120clock inc: 40, clockts/ts+inc diff: -120clock inc: 80, clockts/ts+inc diff: -80clock inc: 40, clockts/ts+inc diff: -120clock inc: 2760, clockts/ts+inc diff: 2600
It would still be much better not to have such “big” delays, but this seems to be a schedulingproblem out of reach of linphone.
Even with these changes, the sound quality is bad on the other side in about 1 of 5 phonecalls, while being good on this side. I was unable to find out why. Terminating the call andcalling again usually “fixes” the problem.
The author of linphone has been notified about both sound issues and solutions.
46 5 THE PHONE APPLICATION
5.6 Making GSM phone calls5.6.1 Analyzing the Phone Application
The only ’official’ way of making a GSM phone call is by using Java104. This is, of course, notvery practical, as calling a Java application from C++ is slow and memory consuming. How-ever, the native Motorola application seems to have a way to make phone calls directly, so it isinteresting to to mimic that behavior.
The obvious candidate for a more detailed inspection would, of course, be the applicationnamed ‘phone‘.
By looking through the filesystem, one can easily identify /usr/lib/ezx/lib/libezxphone-xscale-r.so as a library propable responsible for handling phone calls. Using ‘string‘ on the library con-firms this, as it contains strings such as ’MakeCall’ or ’VoiceCall_Java_MakeCall’. If one couldrun ‘ltrace‘105 on the phone application to see what library calls are made, it should be possibleto mimic this behavior in a C program, by using the same library calls and linking against library.However, this is not easily possible, as it seems that Motorola implemented some countermea-sures to specifically prohibit this:
• After about half a minute of running, when tracing ‘phone‘, the ltrace utility receives aSIGKILL, which causes it to terminate.
• While ltracing ‘phone‘, it is not possible to make phone calls
Fortunately, there is also the ‘strace‘ utility, which logs all system calls made by a program.strace receives a no SIGKILL, nor is it impossible to make a phone call while it runs. Whileidling, the output of ’strace -p ‘pidof phone‘’ looks like this:
select(19, [3 5 11 13 16 18], [], NULL, {0, 370000}) = 0 (Timeout)times({tms_utime=2440, tms_stime=421, tms_cutime=566, tms_cstime=284}) = 684762times({tms_utime=2440, tms_stime=421, tms_cutime=566, tms_cstime=284}) = 684762times({tms_utime=2440, tms_stime=421, tms_cutime=566, tms_cstime=284}) = 684762ioctl(3, FIONREAD, [0]) = 0times({tms_utime=2440, tms_stime=421, tms_cutime=566, tms_cstime=284}) = 684762select(19, [3 5 11 13 16 18], [], NULL, {0, 80000}) = 0 (Timeout)times({tms_utime=2440, tms_stime=421, tms_cutime=566, tms_cstime=284}) = 684770times({tms_utime=2440, tms_stime=421, tms_cutime=566, tms_cstime=284}) = 684770ioctl(3, FIONREAD, [0]) = 0
104seehttp://www.motocoder.com/motorola/download.jsp?EVENT_TYPE_ID=12&FILENAME=downloads/pdf/DG_A780.pdf
page 69 et. seqq. for details on how to use the Java Telephony API on the Motorola A780.105The ltrace utility was ported to the Motorola A780 by Ho Ming Shun, alias
cyph. See https://lists.gnumonks.org/pipermail/openezx-devel/2005-December/000114.html andhttp://wiki.openezx.org/index.php/Software::AP::OpenEZX#ltrace
5.6 Making GSM phone calls 47
It seems like one or more QT Timers106 are running inside the application, while it is waiting foruser action or an incoming call. When making a phone call, it starts being active, here are someextracts from the strace when calling 12345678901:
access("/tmp/emergency_call", F_OK) = 0open("/tmp/emergency_call", O_RDONLY) = 21fstat64(21, {st_mode=S_IFREG|0644, st_size=17592186044416, ...}) = 0fstat64(21, {st_mode=S_IFREG|0644, st_size=17592186044416, ...}) = 0old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x400d8000read(21, "911\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096) = 132fstat64(21, {st_mode=S_IFREG|0644, st_size=17592186044416, ...}) = 0close(21) = 0[...]writev(12, [{"\1\2024\0\0\0\0\0", 8}, {"12345678901\0"
"\374\tA\n\0\0\0\20\376\32\0\370\2\25\0\310"..., 52}], 2) = 60read(12, "\1\202\5\0\0\0\0\0", 8) = 8read(12, "\0\0\0\0\26", 5) = 5[...]access("/ezxlocal/download/appwrite/phone", F_OK) = 0lstat64("/ezxlocal/download/appwrite/phone",
{st_mode=S_IFDIR|0755, st_size=17592186044416, ...}) = 0open("/ezxlocal/download/appwrite//phone/rc_d", O_RDWR|O_CREAT, 0666) = 22fstat64(22, {st_mode=S_IFREG|0644, st_size=17592186044416, ...}) = 0lseek(22, 296, SEEK_SET) = 296write(22, "12345678901\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 72) = 72close(22) = 0
It appears that, among other things, the phone application first opens /tmp/emergency_call to seeif the outgoing call goes to an emergency number. This is important, as it should be possible tocall emergency numbers even without a SIM card or without entering the PIN number. After that,it writes the phone number, among other things, to file descriptor 12. Later it writes the phonenumber to /ezxlocal/download/appwrite/phone/rc_d. These are the only two locations where thephone number appears in the strace output.
Looking at /ezxlocal/download/appwrite/phone/rc_d reveals some more phone numbers, sep-arated by special characters. These appear to be the few last phone numbers that have been called.This has probably nothing to do directly with placing a phone call. The obvious choice is there-fore investigating further on file descriptor 12. Sending SIGTERM to the phone terminates theapplication, but it restarts immediately. strace’ing the freshly started phone application revealsthe following:
socket(PF_FILE, SOCK_STREAM, 0) = 12
106see http://doc.trolltech.com/2.3/qobject.html#7fd5bf
48 5 THE PHONE APPLICATION
connect(12, {sa_family=AF_FILE, path="/tmp/tapisock"}, 15) = 0fcntl64(12, F_GETFL) = 0x2 (flags O_RDWR) fcntl64(12, F_SETFL, O_RDWR) = 0getpid() = 676writev(12, [{"\2\201 \0\0\0\0\0", 8}, {"\244\2\0\0\n\0\0\0\0\0\0\0", 12},
{"\0\2\0\4\0\6\0\7\0\10\0\t\0\n\0\ r\0\16\0\21", 20}], 3) = 40read(12, "\2\201\4\0\0\0\0\0", 8) = 8read(12, "\0\0\0\0", 4) = 4
This basically means that file descriptor 12 is a file socket107 to /tmp/tapisock. Upon initializa-tion, some bytes that probably have a special meaning are written to it. When making a phonecall, some more bytes, followed by the phone number as a C string (terminated by the 0 byte),followed by some more bytes, are written. When strace’ing the phone application multiple times,I discovered that the initialization bytes and the bytes before the phone number were identical,while the bytes after the phone number varied.
5.6.2 Making GSM Phone Calls
As I was not able to figure out the meaning of the bytes after the phone number, I decided that itwas possible that they did not matter and replaced them by null bytes to pad the message to 60bytes (not counting the initialization message). This worked. The following C code can be usedto make a phone call to a number specified in argv[1] which does not exceed 52 decimals:
char *tapiname = "/tmp/tapisock";struct sockaddr *addr; char buf[100] = { 0 };ssize_t socksize = sizeof(addr->sa_family) + strlen(tapiname) + 1;int fd = socket(PF_FILE, SOCK_STREAM, 0);addr = (struct sockaddr*) malloc(socksize);addr->sa_family = AF_FILE;strcpy(addr->sa_data, tapiname);memset(buf, 0, 100);memcpy(buf, "\2\201\0\0\0\0\0\244\2\0\0\n\0\0\0\0\0\0\0\0\2\0\4\0\6"
"\0\7\0\10\0\t\0\n\0\r\0\16\0\21\1\2024\0\0\0\0\0", 48);memcpy(buf+48, argv[1], strlen(argv[1]));connect(fd, addr, socksize-1);write(fd, buf, 100);
A complete program, that also includes sanity checks and error handling can found on the en-closed CD.
These 100 bytes made a phone call to the number specified in argv[1]. But not only that, theyalso completely mimicked the behavior of making a phone call from the address book or the dialpad: The same dialing window appears and also takes care of audio, terminating the call, etc.This is very fortunate as it would have been more difficult to take care of decoding the incomingaudio and encoding the outgoing audio.
107as called named pipe
5.7 Accessing the Address Book 49
5.6.3 Encoutered problems
There was a small surprise when I integrated this code into the unified phone application. Aftermaking a call, the application was terminated. This can easily be avoided by using fork() andexec() to run a different application, which then places the phonecall.
5.7 Accessing the Address Book
In order to comfortably select a phone number to call, integration with the phone’s address bookis necessary. Luckily, a [Motorolafans] member named matiu figured out the structure of theaddress book database108, lying in /ezxlocal/sysDatabase/native.db. It is a berkeley database109,with several subdatabases. One of them is called “780_contact_table” or “contact_table”, de-pending on the phone model. Every row in that subdatabase represents one contact entry, whichbasically is an array of fixed-length C strings. matiu also created usync, an application to ex-port the address book database to various formats, such as plain text, comma-seperated values,or vCard text file. usync is intended to run on a regular Linux workstation, not the phone. Itrequires berkeley database library version 4.2. As usync has a very modular design, it was easyto isolate the part that read the contact data from the database. I planned to integrate this into thephone application.
However, I was not able to read any data from the database when running on the MotorolaA780. The berkeley database library reported that it opened the database, but when retrievinga record, it reported “DB_NOTFOUND: No matching key/data pair found”. I tried to trace thesystem calls made by the library, but was unable to find any evidence: After opening the database,which succeeds, no data is written to or read from the database file, not even when accessing thefirst record fails.
The berkeley database comes with example applications. On of them, ex_access reads anumber of strings from the user and writes them into a database. It then displays all databaseentries. I was able to run this program successfully on my Linux workstation, but not on thephone. It could not even read from an existing database, such as the one created from ex_access.The berkeley database library compiled for the phone is obviuosly defective. I was unable to finda reason for this behavior.
Another option to select a number from the address book for the phone application would beto use copy & paste. While the phone application is running, one can open the address book,select an entry and copy the desired number to the clipboard. However, it is not possible to pasteit into the phone application. It seems that the Qt/Embedded widgets do not support this, butthe only the less known, Motorola customized widgets allow clipboard access. There are twoavailable application that support the clipboard: EditorE and eKonsole. However, I was not ableto find the source code to any of them. I can only presume that they are closed source becausethey use Motorola’s SDK for Linux phones, which is not publicly available.
108see http://www.motorolafans.com/index.php?name=Forums&file=viewtopic&t=1074109http://www.sleepycat.com/products/bdb.html
50 5 THE PHONE APPLICATION
5.8 Power consumptionSending and receiving Bluetooth packets is power-consuming. If no Access Points are in range,the device constantly does Bluetooth inquires. If connected to an Access Point, it constantlysends pings. A more efficient approach in terms of energy consumptions would be to send lessfrequent keep-alive messages when the application is not in foreground, or the phone lid is closed.Unfortunately, there is currently no know way of detecting this.
5.9 InstallationMotorola intended user applications to be installed using a .mpkg file. This would be extractedto a directory, from where it could be run. This however, does not make much sense in ourscenario, as a big number of daemons and kernel modules need to be installed: busybox, BlueZ,tun, openvpn, olsrd and the phone application. As long as [openezx], or a similar project, doesnot establish a standardized way to install packages in a similar fashion as on Linux distributions,the best approach is to give detailled instructions in a README file.
51
6 Conclusions and OutlookThrough small modifications in existing applications, I was able to create an autoconfiguringBluetooth IP network. This network should have the potential to become a real ad-hoc scatternet.However, it was only tested on a small scale, with only one mobile node at a time. Further workon this subject could analyse its scalability and optimize for Bluetooth.
I was able to create secure connections using openvpn. Luckily, the Motorola A780 is pow-erful enough to handle both encryption and voice coding. Thanks to multiple Bluetooth con-nections and openvpn’s flexibility regarding the clients IP address, connection failures can behandled very quickly. It should be possible to make openvpn recognize IP address changes with-out waiting for a connections timeout. This is especially useful if no connection break occurs,but olsr simply selects another Access Point. Only after this problem is solved, it makes senseto use olsrd’s link qualtity extension, which could help changing to better Bluetooth connectionsearlier.
Furthermore, thanks to small modifications in linphone, I was able to make phone calls ingood quality. Further analysis could show how to generalize my modifications, so that they canhelp linphone’s portablility to difficult platforms, such as embedded systems. Also, the patches Icreated for pand, olsrd and hcitool should be reviewed and relevant sections should be merged.
Unfortunately, I was not able to integrate the phone’s address book into the phone application.Finally, location-based services could be built on top of this infrastructure.
This Bachelor Thesis, the source code to the phone application and the patches for theexisting applications can be found on the enclosed CD or on http://lastpageofthe.net/bachelorthesis/
52 6 CONCLUSIONS AND OUTLOOK
REFERENCES 53
References[BTCore] Bluetooth Core Specification, Version 1.2;
http://bluetooth.org/foundry/adopters/document/Bluetooth_Core_Specification_v1.2
[BlueZ] BlueZ - Official Linux Bluetooth protocol stack;http://bluez.org
[BTLunar] Olof Rensfelt: Lunar over Bluetooth;http://user.it.uu.se/~olofr/docs/btlunar_final.pdf
[Ribhegge] Stefan Ribhegge - Sprachübertragung in Bluetooth basierten Ad-hoc Netzw-erken; April 2002http://www.ribhegge.gmxhome.de/
[connectblue] Igor Gurovski & Velimir Karadzic - Self-configuring Bluetooth Networks;December 2002http://www.connectblue.se/fileadmin/Connectblue/PDF/White_papers/Self-configuring_Bluetooth_Networks.pdf
[RFCOLSR] RFC 3626 - Optimized Link State Routing Protocolhttp://ietf.org/rfc/rfc3626.txt
[OLSR] Implementing and Extending the Optimized Link State Routing Protocolhttp://www.olsr.org/index.cgi?action=doc
[RFCSIP] RFC 3261 - SIP: Session Initiation Protocol;http://www.ietf.org/rfc/rfc3261.txt
[RFCSDP] RFC 2327 - SDP: Session Description Protocol;http://www.ietf.org/rfc/rfc2327.txt
[RFCRTP] RFC 1889 - RTP: A Transport Protocol for Real-Time Applications;http://www.faqs.org/rfcs/rfc1889.html
[openezx] openezx projecthttp://www.openezx.org
[Motorolafans] Motorolafanshttp://www.motorolafans.com
54 REFERENCES
55
A configuration files
A.1 olsrd.confHna4 { 5.6.7.8 255.255.255.255 }
A.2 openvpn-server.confmode serverplugin /path/to/openvpn-auth-pam.so \"system-auth login USERNAME password PASSWORD"floatdev tunca /root/vpn/keys/ca.crtcert /root/vpn/keys/server.crtkey /root/vpn/keys/server.key # secretdh /root/vpn/keys/dh1024.pemserver 10.8.0.0 255.255.0.0ping 1ping-restart 3push "redirect-gateway def1"push "dhcp-option DNS 132.230.200.200"push "dhcp-option DNS 132.230.200.201"client-cert-not-requiredusername-as-common-name#drop priviledgesuser nobodygroup nobodypersist-keypersist-tunstatus openvpn-status.log
A.3 openvpn-client.confclientpullauth-user-passdev tundev-node /ezxlocal/tunnobindca /ezxlocal/usr/etc/ca.crttls-remote serverpersist-key
56 A CONFIGURATION FILES
persist-tunping 1ping-restart 3route-noexec# route_vpn_gateway is filled by openvpn automaticallyroute-up "/ezxlocal/bin/route add 10.8.0.1 gw $route_vpn_gateway"route-up "/ezxlocal/bin/route add default gw $route_vpn_gateway"
A.4 Access Point startup scriptIn addition to this script, pand must be listening. The system must be configured to run theAccess Point dev-up script when a bnep interface is created.
#!/bin/bash#set this to the real addressphone_gw_addr=5.6.7.8#maybe you need to adjust this, depending on your route to the phone gatewayroute add $phone_gw_addr eth0iptables -t nat -A POSTROUTING -j MASQUERADE -o eth0sysctl net.ipv4.ip_forward=1hciconfig hci0 upolsrd -hint 2 -tcint 2 -midint 2 -hnaint 2 -d 0 -i bnep0 bnep1 bnep2 bnep3 \bnep4 bnep5 bnep6 bnep7#uncomment to deny anonymous internet access from the Access Point.#iptables -A FORWARD -j ACCEPT -d $phone_gw_addr#iptables -A FORWARD -j ACCEPT -s $phone_gw_addr#iptables -A FORWARD -j drop
A.5 Access Point dev-up script#!/bin/bash# $1 is interface name# $2 is bluetooth hardware address/path/to/zeroconf-x86 $1
A.6 Mobile Device startup script#!/bin/bashecho -n ’starting daemons... ’export PATH=$PATH:/diska/bluez/bin:/diska/bluez/sbinexport LD_LIBRARY_PATH=/diska/bluez/libcd /diska/bluezif [ "x‘/sbin/lsmod | /bin/grep bluez‘" = x ]; then
A.7 Mobile Device dev-up script 57
echo -n ’bluez’/diska/bluez/btinit.sh > /dev/null;echo -n ’. ’#/bin/sleep 3
fi/diska/bluez/sbin/hciconfig hci0 upif [ "x‘/bin/ps ax | /bin/grep hcid | /bin/grep -v grep‘" = x ]; then
echo -n "hcid"/diska/bluez/sbin/hcid -f /diska/bluez/etc/bluetooth/hcid.confecho -n ’. ’
fiif [ "x‘/bin/ps ax | /bin/grep pand | /bin/grep -v grep‘" = x ]; then
echo -n "pand"/diska/bluez/bin/pand --search --role PANU --persist --nosdp \
--devup /ezxlocal/usr/etc/devup.sh --maxconn 3 --master \--lockfile /ezxlocal/blue.lock
echo -n ’. ’fiif [ "x‘/bin/pidof olsrd‘" = x ]; then
echo -n "olsrd"/ezxlocal/usr/sbin/olsrd -d 0 -hint 2 -tcint 2 -midint 2 -hnaint 2 \
-i bnep0 bnep1 bnep2 bnep3 bnep4 > /dev/nullecho -n ’. ’
fiif [ "x‘/sbin/lsmod | /bin/grep tun‘" = x ]; then
echo -n "tun"insmod -f /ezxlocal/lib/modules/tun.o > /dev/nullecho -n ’. ’
fiecho "nameserver 132.230.200.200\nnameserver 132.230.200.201" \
> /etc/resolv.confecho "done."
A.7 Mobile Device dev-up script#!/bin/bashLD_LIBRARY_PATH=$LD_LIBRARY_PATH:/diska/bluez/lib#configure the interface/ezxlocal/usr/sbin/zeroconf $1#set link supervision timeout to 2.5 seconds/diska/bluez/bin/hcitool lst $2 4000#set flush timeout to 50 ms/ezxlocal/usr/sbin/setflush-arm $2 80
