Remote Access of Home Network from MobileDevice using DLNA and Linux

RIKARD GUSTAFSSON AND GUSTAV REIZ

Master’s Thesis at the Department of Computer ScienceAdvisor/Examiner: Boris Magnusson

Advisor: Stefan Ekenberg

February 15, 2010

AbstractIn today’s technically aware society comfort has become a big demand.From this demand the DLNA standard rose up in order to let peoplefuse all of their technical devices together, to share, to view and totransfer their digital content. In parallel with this development, ourmobile phones are evolving into more and more advanced multi-purposedevices which we rely on in many of our daily activities.

In this Master’s Thesis the aim is to conjoin these two trends inorder to develop a prototype system in which a user is able to control hishome network with the use of a mobile phone over the cellular networkor when connected to the Internet through Wi-Fi. The user will be ableto connect to, and control, his home network and the devices within.

Analysis of available related solutions, the advantages and disad-vantages of them, are first presented. A new, more suitable, solution isthereafter proposed.

ReferatI dagens tekniskt medvetna samhälle så har bekvämlighet blivit ett stortkrav och det är utifrån detta krav som den nya DLNA standarden växtefram. Med hjälp av DLNA möjliggör man för användare att integrerasina tekniska enheter med varandra. Därigenom förenklas möjligheternaatt dela, titta på och hantera digital media. Parallellt med denna utveck-ling så blir våra mobiltelefoner mer och mer avancerade och spelar enallt större roll i vår vardag.

Det här examensarbetet ämnar att koppla samman dessa två tren-der för att utveckla ett prototypsystem som skall kunna används föratt kontrollera ett hemmanätverk via en mobiltelefon över det celluläranätverket eller via Wi-Fi. Visionen är att en användare skall kunna,givet att han har Internetuppkoppling, ansluta till och kontrollera sitthemmanätverk enbart med hjälp av sin mobiltelefon.

Analys av redan existerande lösningar, dess för- och nackdelar, somberör ämnet med “Remote Access” kommer att presenteras. Utifrånvad som finns tillgängligt idag så kommer en lösning, för att uppnå fullkontroll över sitt hemmanätverk, att beskrivas.

AcknowledgementWe would like to express our gratitude to everyone who gave us thepossibility to complete this Master’s Thesis. We would especially liketo thank our advisor Stefan Ekenberg at ST-Ericsson for his valuablecomments and guidance throughout the course of the thesis and JohanSörensen at ST-Ericsson for his comments and suggestions.

We would also like to thank our examiner Boris Magnusson on LTHfor his time spent on reading and commenting the thesis. Finally wethank Mikael Torstensson at NetOnNet for allowing us to use imagesfrom their website as part of our illustrations.

Contents

1 Introduction 11.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 The Work Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 DLNA Overview 52.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Evolution of DLNA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.3 Device Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4 Device Classes and Categories . . . . . . . . . . . . . . . . . . . . . . 7

2.4.1 Home Network Device Category, HND . . . . . . . . . . . . . 82.4.2 Mobile Handheld Device Category, MHD . . . . . . . . . . . 92.4.3 Home Infrastructure Device Category, HID . . . . . . . . . . 10

2.5 Device Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.5.1 Interaction Examples . . . . . . . . . . . . . . . . . . . . . . . 11

2.6 A Typical Home Network . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Analysis 153.1 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.1 DLNA Proxy System . . . . . . . . . . . . . . . . . . . . . . . 153.1.2 W-DLNA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.1.3 xUPnP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.1.4 Web Based User Interface . . . . . . . . . . . . . . . . . . . . 183.1.5 Atom Architecture . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2 Related Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.2.1 DD-WRT and OpenVPN . . . . . . . . . . . . . . . . . . . . 20

3.3 Developement Libraries for UPnP . . . . . . . . . . . . . . . . . . . 213.3.1 Intel’s libupnp . . . . . . . . . . . . . . . . . . . . . . . . . . 213.3.2 Cyberlink for C++ . . . . . . . . . . . . . . . . . . . . . . . . 213.3.3 GUPnP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.3.4 Platinum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.3.5 Allegro RomPlug . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.4 Possible Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.4.1 Client & Server Application . . . . . . . . . . . . . . . . . . . 233.4.2 Ethernet Bridging using DD-WRT and OpenVPN . . . . . . 25

3.5 Choosing an Approach . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4 Design and Implementation 294.1 Tools and Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.2 VPN Bridge Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.3 Remote DMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5 Limitations 355.1 Router Bottleneck . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.2 Power Consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.3 Multi-Interface Support . . . . . . . . . . . . . . . . . . . . . . . . . 38

6 Conclusions 39

7 Future Work 41

Appendix 41

A User manual - OpenVPN 43A.1 Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43A.2 Generating Certificates and Keys . . . . . . . . . . . . . . . . . . . . 43A.3 Configure the Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 45A.4 Configure the Client . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

B User manual - RG DMC 51B.1 Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

B.1.1 Installation on a Debian Based System (e.g. Ubuntu) . . . . 51B.1.2 Installation on a Linux System. . . . . . . . . . . . . . . . . . 52

B.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52B.3 Starting the Application . . . . . . . . . . . . . . . . . . . . . . . . . 53B.4 Using the Application . . . . . . . . . . . . . . . . . . . . . . . . . . 53

B.4.1 Console View . . . . . . . . . . . . . . . . . . . . . . . . . . . 53B.4.2 GUI View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Bibliography 59

Chapter 1

Introduction

This opening chapter will give an introduction to this Master’s Thesis, its purposeand background in Section 1.1, and the work process behind it in Section 1.2.

In Chapter 2 an introduction to the DLNA standard will be given. Chapter3 will present already developed solutions, techniques and tools relating to theproblem with remote access to home networks. Chapter 4 will describe how thesolution was implemented. Chapter 5 will show some limitations with this solution.Chapter 6 will summarize the Master’s Thesis and the solution developed. Chapter7 will suggest future work which can be conducted in the area of DLNA and remoteaccess.

1.1 Background

People today are becoming more and more dependent on digital media and con-necting different media entertainment systems. They are acquiring, viewing, andmanaging media to a larger and larger extent. Having many different media de-vices at home which can not directly communicate with each other forces users toutilize extra devices or transport agents such as DVD-discs. Taking the commoncase where a person wants to play his home videos, stored on his computer, on hisTV. The first thing he will have to do is to convert the video to a format that issupported. Then it needs to be burnt to a DVD disc and played in the DVD player.This has resulted in a greater demand for comfort and that is where the Digital Liv-ing Network Alliance (DLNA) standard becomes important. The goal with DLNAis to allow technical devices to interact with one another in order to create a flexiblehome network where digital media can be viewed, shared, and managed in an easyway without the need for any additional software or advanced configuration of thedevices.

DLNA is based on the Universal Plug and Play (UPnP) protocol standard whichspecifies a set of guidelines on how technical devices can discover and interact withone another in a Local Area Network (LAN). This introduces a limitation due to theUPnP discovery mechanism, which limits its use to a private IP configured home

1

1.2. THE WORK PROCESS

network since it uses multicast packages [2]. Multicast packages are often limitedto a LAN since Internet routers often blocks multicasts in order to reduce networktraffic.

What if a user wants to access and control his home network from a remotelocation outside the LAN? Picture a scenario where a user is stuck in traffic andhis favorite show is about to start, or maybe his kids are home alone and he needto keep them entertained. What does he do? Wouldn’t it be fantastic if he, justby connecting to the Internet, would be able to manage his Digital Video Recorder(DVR), and access his previous recordings? By gaining this control he would beable to record the show he does not want to miss, or play a previously recordedcartoon show on his TV for the kids.

This is the type of scenarios that this Master’s Thesis aims to enable. With aDLNA network setup at home one will be able to connect to it remotely using amobile phone (given that Internet access is provided) and control all the devices,and the services that they provide, within that network.

1.2 The Work Process

During the course of this project we were located in the office building of ST-Ericssonin order to work closely with our advisor at the company. We were given our ownworkstations, with one computer each. We treated the project as a somewhat realemployment, working 8-15 four days of the week and 8-12 on Fridays, and extrawhen needed.

We started off the project by making a work plan to get a clear overview ofthe project and what tasks it involved. The plan could be divided into the threeparts Analysis, Implementation, and Documentation. During the Analysis part westudied the DLNA standard, which were completely new to us at the time. Wealso analyzed other solutions aiming to solve the problem with remote access tohome networks. After familiarizing ourselves with the problem at hand, and witha greater insight in the DLNA standard, we created our own solution.

With an idea for a solution we proceeded to implement and design it, duringwhich we formulated the solution on paper and finally in code. During the devel-opment of our solution we had a few demonstrations of our work for our advisorsto keep them updated on our progress and to gain feedback. When developing oursolution we had a network set up at Gustav’s apartment which we connected to inorder to test our implementations.

The last part, Documentation, mainly consisted of report writing, which weplanned to be working on continuously throughout the project. This, however,would prove hard during the implementation part where our focus were mainly oncode writing. But since we had written quite a lot during the Analysis part we hadno worries about falling behind.

Our final presentation was scheduled in late January and was held in two parts,one at ST-Ericsson and one at The Faculty of Engineering at Lund University, LTH.

2

CHAPTER 1. INTRODUCTION

The presentation included an introduction to DLNA, a description of the problemwith remote access, analysis of current solutions and an introduction to our solution.Following this presentation a demonstration of our solution where held using thetest network setup at Gustav’s apartment. Through this demonstration we provedthat our implementation does indeed solve the problem with remote access.

3

1.3. TERMINOLOGY

1.3 TerminologyAcronym MeaningCA Certificate AuthorityCDS Content Directory ServiceCMS Connection Manager ServiceDH Diffie-HellmanDLNA Digital Living Alliance NetworkDMC Digital Media ControllerDMP Digital Media PlayerDMPr Digital Media PrinterDMR Digital Media RendererDMS Digital Media ServerFTP File Transfer ProtocolGENA General Event Notification ArchitectureGUI Graphical User InterfaceHID Home Infrastructure DeviceHND Home Network DeviceHTTP Hypertext Transfer ProtocolIGD Internet Gateway DeviceIP Internet ProtocolLAN Local Area NetworkM-DMC Mobile Digital Media ControllerM-DMD Mobile Digital Media DownloaderM-DMP Mobile Digital Media PlayerM-DMS Mobile Digital Media ServerM-DMU Mobile Digital Media UploaderM-NCF Mobile Network Connectivity FunctionMHD Mobile Handheld DeviceMIU Media Interoperability UnitMoCA Multimedia over Coax AllianceMVC Model-View-ControllerP2P Peer-to-PeerRTOS Real-time Operating SystemRTP Real-time Transport ProtocolSOAP Simple Object Access ProtocolSSDP Simple Service Discovery ProtocolSSL Secure Socket LayerUI User InterfaceUDP User Datagram ProtocolUPnP Universal Plug and PlayVPN Virtual Private NetworkXML eXtensible Markup Language

4

Chapter 2

DLNA Overview

An overview of the DLNA standard will be given in this chapter. A brief intro-duction to the Digital Living Network Alliance is given in Section 2.1. Then, inSection 2.2, the past, present, and future of DLNA will be summarized. The DLNADevice Model is described in Section 2.3. The different Device Classes and DeviceCategories that DLNA uses to categorize its certified products are described in Sec-tion 2.4. Section 2.5 contains a description on how these devices interact with eachother. Finally, a small example of a typical home network is provided in Section2.6.

2.1 Introduction

In recent years digital media devices, e.g., digital recorders, music players and hi-tech televisions, have become common in every household. To avoid the tediousprocess of managing all digital content separately, several companies came togetherin 2003 to form the Digital Living Network Alliance in order to state a new standardfor device-to-device interaction. In doing so they assured that products developedaccording to this standard would be able to interact with each other in a unified way.More and more companies are now joining this alliance by following its requirementsfor interoperability. Today there are over 240 members including Microsoft, Nokia,Acer, AMD, Panasonic, Philips, Sony, and Ericsson to name a few [1]. Together,these member companies have got over 6000 devices DLNA certified.

DLNA is based on several building blocks, see Figure 2.1. The Data Link blockin the bottom allows wired Ethernet, wireless Ethernet, and Bluetooth. On top ofthat all DLNA devices must use the IPv4 protocol [17]. The media transport shouldbe done using the Hypertext Transfer Protocol (HTTP) or optionally Real-timeTransport Protocol (RTP) [18, 19]. DLNA uses UPnP Device Architecture 1.0 fordevice discovery and control, and UPnP AV Architecture 1.0 for media management[2, 3]. At the top special guidelines are defined in order to achieve interoperabilityin the home. These guidelines include Media Formats which describe how media isencoded and formatted. These so called media format profiles are very explicit to

5

2.2. EVOLUTION OF DLNA

Figure 2.1. The DLNA building blocks.

ensure interoperability between DLNA compliant devices.

2.2 Evolution of DLNA

The first set of guidelines was published in June 2004 and included only two setsof Device Classes, the Digital Media Server (DMS) and the Digital Media Player(DMP). In March 2006 version 1.5 of the guidelines were published and in October2006 it was expanded. This version included more Device Classes and specified LinkProtection to allow secure transmission. The expanded version 1.5 is the currentversion and the one considered in this Master’s Thesis.

The evolution of DLNA is an ongoing process and version 2.0 is planned to bereleased in 2010. Version 2.0 will, among many things, feature content synchroniza-tion, meaning support for keeping the content of home media servers up-to-datebetween each other. Online TV guide support and record scheduling will be fea-tured. New Data Link Layer support will also be added, including 802.11n, thenew faster Wi-Fi standard and Multimedia over Coax Alliance (MoCA) standard,which is IP traffic over coaxial cables [27]. But the most interesting aspect of the2.0 release of the DLNA guidelines is that the DLNA organization themselves aimsto solve the remote access problem. However, little information has been releasedconcerning this matter and therefore it will not be included in this Master’s Thesis.

6

CHAPTER 2. DLNA OVERVIEW

2.3 Device Model

The device model used by DLNA is taken from the UPnP Forum FundamentalDevice Model [2]. It consists of Devices, Services, and Control Points.

Devices are entities in the network that provides one or several services. Exam-ples of typical DLNA devices would be a TV or a DVD player. A physical deviceon the network is referred to as the root device which can have several embeddeddevices with their own services.

Services exist in all devices and provide actions for other devices to utilize.Examples of actions on a DVD player would generally be play, stop etc. A service isalso presented with a status, or run-time state, which is described by a set of statevariables which may change when certain actions are called on the service. Otherdevices usually subscribe to the status of services to keep themselves up-to-date tochanges in the services status, this is further described in Section 2.5.

Control Points are entities on the network that can discover and control otherdevices on the network. A control point does not provide any services and can notbe found by other devices during device discovery (See Section 2.5). The controldata is always handled directly between the control point and the device, so if acontrol point would control several devices there would be a communication pathbetween the controller and each of the devices independently. While control datais only being sent between the Control Point and the device, the devices transportdigital content between each other directly without passing it through the ControlPoint. Figure 2.2 shows a Control Point, the Digital Media Controller (DMC),accessing the services of two device entities on the network. It browses throughthe media content offered by the Digital Media Server (DMS) and specifies a givenfile for playback on the Digital Media Renderer (DMR). These entities are furtherdescribed in Section 2.4.

2.4 Device Classes and Categories

In order to better define the characteristics of devices in the DLNA network and theservices that they offer, the DLNA Interoperability Guidelines define three devicecategories which are in turn further divided into a set of device classes [4]. Inorder for a device to be classified in one of these categories the DLNA requirementsspecified for that class needs to be met. A device can belong to several devicecategories or classes. For example if an application developed as a media servermeets both the requirements for the Digital Media Server (DMS) class and theMobile-Digital Media Server (M-DMS) class, it will belong to both these classesand be included in two categories. The requirements for a device class include themedia formats the devices in this class should be able to handle and what formof connectivity they must provide. This means that it is not the physical, butthe technical characteristics of a device that decide what category, or categories,it belongs to. For example, a mobile phone can act as a M-DMS via Bluetooth,

7

2.4. DEVICE CLASSES AND CATEGORIES

Figure 2.2. Example of a Digital Media Conroller asking a Digital Media Server tosend media to a Digital Media Renderer.

categorizing it as a Mobile Handheld Device (MHD), and share the same mediacontent as a DMS by Wi-Fi, categorizing it as a Home Network Device (HND). Aphysical device can also be both controlling and service providing, i.e., a DigitalMedia Player (DMP) can also be certified as a Digital Media Renderer (DMR) thusmaking it both a service providing device, as a DMR, and a Control Point, as aDMP.

2.4.1 Home Network Device Category, HNDThe Home Network Device Category is made up of five different device classesthat can provide, and utilize, services in a local home network. The devices inthis category have the same requirements on what form of connectivity they mustprovide and the same requirements on which media formats that must be supported.

• Digital Media Server, DMSAcquires, records, stores, and shares digital media content throughout thenetwork. DMS devices often include user interfaces and media managementfunctions to handle the media it holds. Examples of possible DMS devicesinclude:- PC Server- Personal Video Recorder (PVR)- Digital Camera and Camcorder- Network-Attached Storage (NAS)

• Digital Media Renderer, DMRA DMR device can render or play content they receive from a DMS. The

8

CHAPTER 2. DLNA OVERVIEW

connection must be set up by either a DMC or an M-DMC. Examples ofDMR devices include:- Digital TVs- Stereos

• Digital Media Controller, DMCSearches for, and finds, media content offered by a DMS device on the networkand matches it to the rendering capabilities of a DMR. It then can set up theconnections between the DMS and the DMR. A DMC is itself not visible toother devices. Examples of DMC devices include:- Universal Remote Control

• Digital Media Player, DMPA DMP can be seen as a unit with combined functionality of a DMR and aDMC. It, searches for, and finds, media content offered by DMS devices on thenetwork, and also provides playback and rendering capabilities. DMP devicesare not visible to other devices on the network. A device certified as a DMPcan also be certified as DMR at the same time, and thus be visible on thenetwork. Examples of DMP devices include:- Digital TVs- Stereos- Game Consoles

• Digital Media Printer, DMPrProvides printing services to the DLNA home network, where photo printingis the primary usage. Example of DMPr devices include:- Network-Attached Photo Printer- PC exposing DMPr functionality of non-networked printer.

2.4.2 Mobile Handheld Device Category, MHD

The Mobile Handheld Device Category devices share the same usage models as theHND Device Category but with different requirements for media format supportand network connectivity. For example, unlike the HND, it is required to supportBluetooth.

• Mobile Digital Media Server, M-DMSOffers and distributes media content. Examples of M-DMS devices include:- Portable Music Players- Digital Camera

• Mobile Digital Media Player, M-DMPSearches for, and finds, media content offered by an M-DMS and providesplayback and rendering capabilities. Examples of M-DMP devices include:- Mobile Phone with Media Player Application

9

2.5. DEVICE INTERACTION

• Mobile Digital Media Controller, M-DMCSearches for, and finds, media content offered by an M-DMS and matches it tothe rendering capabilities of a DMR. It then sets up the connection betweenthe M-DMS and the DMR. Examples of M-DMC devices include:- PDA with Controller Application

• Mobile Digital Media Uploader, M-DMUCan upload content to an M-DMS with upload functionality. Examples ofM-DMU devices include:- Digital Camera

• Mobile Digital Media Downloader, M-DMDSearches for, and finds, media content offered by a M-DMS and download itin order to store in localy. Examples of M-DMD devices include:- Digital Music Player

2.4.3 Home Infrastructure Device Category, HIDThere are two device classes in the Home Infrastructure Device Category. Thepurpose of these devices is to translate the communication between devices withinthe MHD and the HND category, allowing them to communicate with each other.

• Mobile Network Connectivity Function, M-NCFEstablishes a bridging function between the MHD and HND to allow devicesin the different device categories to communicate.

• Media Interoperability Unit, MIUTransforms content between different media formats for the HND and theMHD to allow media content to flow between the device categories.

2.5 Device InteractionThe device interaction in DLNA is based on devices knowing of each others exis-tence, and the state of each others services. Devices that already have knowledgeof each others existence can keep themselves updated on the current status of a ser-vice in a device. This is done by subscribing to the state variables in that device’sservices. The subscribing device will then receive notifications on any changes tothese state variables via the General Event Notification Architecture (GENA) [20].

Whenever a device wants to interact with another device it has to go throughthe four steps (given that the device has connected to, and been given a IP addressby the network) discovery, description, control, and content transport.

• Step 1: DiscoveryWhen a new device is added to the home network, it advertises its presenceby the use of the UPnP discovery protocol, which is based on the SimpleService Discovery Protocol (SSDP) [21]. This is done by sending a HTTP

10

CHAPTER 2. DLNA OVERVIEW

Notify message to the SSDP standard multicast address 239.255.255.250 onport 1900 to which other devices are listening. This Notify message contains,among other things, the location of the eXtensible Markup Language (XML)document that describes the device, i.e., its device description [22]. If thenewly connected device is a control point, it therefore needs to know thepresence of other devices connected to the network. A HTTP M-SEARCHmessage is then sent over User Datagram Protocol (UDP) to the standardmulticast address which all DLNA devices are listening to. In response tosuch a message all other devices should, according to the UPnP standard,re-advertise themselves by sending a HTTP Notify to the multicast address.

• Step 2: DescriptionWhen, for example, a DMP has found a DMS, it still knows very little aboutit. The next step for the DMP is to download the device description, expressedin XML, from the DMS. This description contains, among many things, theservices the DMS provides, device name, device type, and a unique ID. Ser-vices provided by a DMS would typically be Content Directory Services (CDS)for content browsing and searching, and Connection Manager Service (CMS)for connection handling. In order for the DMP to use any of these services itneeds to know which actions are provided for each service. To get this infor-mation the DMP requests a service description. The service description, justlike the device description, is expressed in XML and contains all the actionsthat can be invoked on the service and what arguments they take.

• Step 3: ControlThe DMP now has the knowledge of what services are offered by the DMSand which actions can be invoked on these services. The control interactionbetween them can now commence. The DMP controls a service by sendingaction commands via the Simple Object Access Protocol (SOAP) to the DMS[23]. The DMS will then respond by changing its variables describing the stateof the service in question. A SOAP response is also generated and sent backto the DMP. The SOAP messages are encapsulated within a HTTP requestor response. With the state variables changed the DMS will announce thesechanges to other devices that are subscribing to the state of the DMS.

• Step 4: Content transportWhen the DMP is requesting a selected media file from the DMS, a con-tent transport is initiated. This transportation of content between the DMPand DMS is handled by HTTP or the optional Real-time Transport Protocol(RTP).

2.5.1 Interaction Examples

Further description of the interaction between devices on a network can be seenin the sequence diagrams illustrated in Figure 2.3 and Figure 2.4. These sequence

11

2.6. A TYPICAL HOME NETWORK

Figure 2.3. A DMC has just connected to the network and wants to know whichdevices are present on the network.

diagrams describes the interaction between a DMS, a DMC, and a DMR.Figure 2.3 describes the scenario where a DMC has just connected to the network

and wants to know which devices are present. It sends out an HTTP M-SEARCHmessage to the common multicast address. The DMS and DMR pick up this messageand responds to the DMC with a HTTP Notify. The DMC can now get informationabout the connected devices by downloading their device descriptions. By parsingthe device description the DMC can verify that the DMS and the DMR supportsall required services.

Figure 2.4 describes the scenario where a DMC initiates playback of a selectedfile on a connected DMR. In order to find the desired file the DMC browses theDMS for its content by sending an action request for Browse of container with ID0, which is the root folder of the DMS. The DMS responds by sending a contentdescription in the form of an XML document which contains all files and folderswithin the root. The DMC wants to browse further and selects the folder withID a01b2, in which the DMS respond with the content of a01b2. The desired fileis found, along with its URI and metadata, in the content description of a01b2.This information is then sent to the DMR through the action SetAVTransportURI.Finally the DMC invokes the action Play on the DMR in which the DMR startsplaying the selected file from its URI.

2.6 A Typical Home NetworkIn order to give a better picture of what a DLNA network is made up of, a smallexample is outlined in this section. Figure 2.5 describes the simplest form of a DLNAnetwork and is made up of a computer and a TV. In this network the computer

12

CHAPTER 2. DLNA OVERVIEW

Figure 2.4. A DMC initziate playback of a given file on a DMS through browsing.

acts as the DMS and shares some media content throughout the network. Thecomputer does this by announcing its presence with a multicast to the standardmulticast address. The TV acts as the DMP, listening for multicasts from potentialDMSs that share some media. Once it picks up the announcement from the DMS(i.e., the computer) it asks the computer for its device description. The computerreceives this request and responds with its device description which is the servicesthat it provides. The DMP wants to use the service for content browsing and requesta description for that service. The DMS respond with a list of actions that can beinvoked on the service for content browsing. From the TV, the user is now able tobrowse through the content offered by the DMS on the computer, select a desiredfile, and initiate the playback of the content on the TV.

13

2.6. A TYPICAL HOME NETWORK

Figure 2.5. A typical home network in its simplest form.

14

Chapter 3

Analysis

Already developed solutions, techniques and tools relating to the problem withremote access to home networks will be analyzed in this chapter. In Section 3.1numerous existing solutions will be analyzed. Some techniques that may be usefulin developing a solution to the remote access problem will be presented in Section3.2. Then, in Section 3.3, libraries that may be used during development of asolution will be analyzed. Finally, in Section 3.4, possible solution approaches willbe presented.

3.1 Related Work

The field of remote access to various systems is a productive area of research andsome work already conducted in this field relates somewhat to what this Master’sThesis aims to solve. In this section analysis of related approaches on the problemwith remote access to a home network will be presented.

3.1.1 DLNA Proxy System

The DLNA Proxy System architecture as proposed by [7] focuses on media sharingbetween remote devices, but provides little control over other DLNA devices. Itmakes use of, what in the article is referred to as a DLNA Media Proxy Server(DMPS), which is installed on a local device, preferably the home server, connectedto the home network and listens for multicasts from DMS on the standard multicastaddress (239.255.255.250:1900). When a DMS is found its device description isregistered by the DMPS. The DMPS also requests its archive of content, registerit, and merge it with (if any) information from other previously found DMSs. Bydoing so the DMPS is able to provide a complete list of available media contentto potentially remote DMPs. The home gateway is another part of the DMPSsolution which has the responsibility to establish and maintain IPSec Virtual PrivateNetwork (VPN) tunnels between the local and remote network or device [24].

15

3.1. RELATED WORK

The DMPS handles incoming connections from DMPs which could be hiddenbehind a DMPS of another home network or some other remote device like a mo-bile phone or a laptop. An IPSec Virtual Private Network (VPN) tunnel is thenestablished between the two devices. When a DMP connects to a DMPS it willbe provided with the content information on what media is offered by the networkbehind the DMPS. When some media content is requested by a DMP the DMPSconverts the registered URL to list its own IP address and port information whilesaving the original information and setting up an address mapping table. It canthen just forward the data flow using the established VPN tunnel.

The problem with this approach is that it is limited to the one scenario wherea remote DMP wants to access some media for playback, meaning that you areunable to push media from a DMS to a DMR. It is only possible to pull media.Furthermore, it provides no possibility for control over other DLNA devices, e.g., itis not possible for a remotely connecting DMC to access a DMR of the host networkin order to control it, and this is due to the fact that the DMC only will be givenaccess to the DMPS which provides no further controlling features. This approachalso includes the use of a home server that needs to be up and running all the timeand a home gateway that will need to be set up to support IPSec VPN tunnels.

3.1.2 W-DLNA

The Wide area DLNA or W-DLNA architecture as proposed by [5] consists of threecomponents; two forms of gateway software and a server with Session InitiationProtocol (SIP) [25]. The gateway software is installed both on a device which isdirectly connected to the home network, e.g., a router, and a remote device (e.g.a mobile phone or a laptop) outside the home network. These two gateways cannow be used to set up a SIP session between the two devices through which thecommunication can be handled.

One of the key features of the gateway software is to create virtual DMPs andDMSs. This is to bypass UPnPs limitations of not being able to work properlyoutside a LAN. A client that wants to access and view some media content withina home network from a remote location sets up a connection to the home gatewayfrom his remote DMP or M-DMP. The gateway creates a virtual DMP that interactswith the DMS within the network. By doing so the DMS can not know that it is nottalking to a real DMP, but a virtual one, and the communication between them canproceed as normal. The information is now being forwarded through the gatewayto the real DMP.

Another key feature of the gateway software is the dynamically reachable ad-dress mapping. This mapping of IP addresses is what allows remote devices tointeract with a DMS within a home network. When a virtual DMP receives aDLNA command from a remote client, it inspects the command. If a new pair ofan IP address and a port number is found it creates a new reachable address. Thevirtual DMP can now convert the address of the incoming DLNA commands to thereachable address.

16

CHAPTER 3. ANALYSIS

There are a few problems also with this solution. The whole system consistsof three different software implementations that all needs to be installed on thevarious devices, which could be very complex for the end user to handle. Just likethe DLNA Proxy System in the previous section this approach provides little controlfunctionality since the focus is media sharing.

3.1.3 xUPnP

The xUPnP architecture as proposed by [6] consists of an extension of the UPnPprotocol. In order to build large network of DLNA devices it organizes the devicesinto groups, where a group may involve a remote device or a group of devices ina local area. A group can then be extended when other devices or network peersconnect. For a group to be able to accept remote devices or peers a so called SuperPeer (SP) for that group is needed. A SP acts as the intelligent device of the groupand is visible remotely for other devices to connect to.

The architecture is divided into an Overlay Middleware (OM) part and a xUPnPapplication part. The xUPnP application and OM is installed on the peer devices,i.e., gateway computers and mobile phones. There is no need to change or installanything on the DLNA devices within the local network. The OM controls andprovides control path functions and data path function between the groups. It isnot aware of the UPnP protocol and just lets the xUPnP application use its APIfor joining groups and handle them. A device can belong to several groups as longas it has the credentials needed (password or certificate).

The xUPnP application implements service logic to extend the UPnP acrossmultiple subnets or groups. The xUPnP is, unlike the OM, aware of the UPnP pro-tocol. The xUPnP application discovers local UPnP devices and services and sendsthe information to its peer xUPnP applications. The receiving xUPnP applicationsthen re-advertise the information to the devices in its local subnet or group. Oncethe devices have discovered each other they can communicate directly through atunnel without involving the xUPnP application.

Local devices on a network require Network Address Translation (NAT), mean-ing that a router within the home network needs to remap the address field ofincoming packages in order for them to reach their destination. To solve this issuethe xUPnP application and OM is installed on a node in the network. This nodewill play the role of a xUPnP gateway. The issue here is that advertisements fromlocal devices will include their NATed IP so a remote device will not be able toaccess them. The solution to this is that when the xUPnP application finds a newdevice it looks at the “Location” field in the HTTP OK packet and compares it tothe source address of the IP packet. Since the location field will show the NATedIP of the device and the source IP field will show the xUPnP Gateways IP it cansee that is a NATed device. Once this is determined the xUPnP application callsthe OM to set up a path. The OM sets up a tunnel and adds host specific entriesin the routing tables. By doing so all future packages will go directly to the deviceand not through the xUPnP application.

17

3.1. RELATED WORK

One advantage with this solution is that it optimizes battery life of the connect-ing device by letting the xUPnP application in the home gateway handle the periodicadvertisements and only send the list of available devices to the remote device uponconnecting. This could also be a disadvantage if the local devices would change afterthe remote device has connected, thus leaving the remote device unaware of thesechanges. But the common case is that local devices remains present and unchangedon the network and the battery life advantage would therefore outweigh this smalldisadvantage.

The problem with this solution is that it’s limited to a single NATed domain,i.e., if there would be two NATed domains with the same IP range there could bedevices with the same IP. To be able to solve this problem one could use the xUPnPapplication to be a middleman and do address translations on the UPnP packages.

3.1.4 Web Based User Interface

The Web Based UI architecture as proposed by [8] makes use of a UI server thateither resides in the home network or on the Internet. The UI server, which is ableto discover home network devices, will provide a control page for connecting clients.The UI page provided by the server utilizes a scriptable-API mechanism whichenables a control JavaScript embedded in the page to selectively invoke functionson the controlled devices.

When a client opens the server UI control page the JavaScript is loaded into theclient web browser. A home network plug-in module installed on the client deviceprovides scriptable-APIs to discover and control devices in the home network. Sinceit’s basically a regular web server it can be accessed from outside the home network.

It is an interesting approach. However, it does not support remote media sharingand therefore it does not solve the remote access problem completely. Furthermore,operating ones devices through a mobile phone web browser can prove cumbersomefor the user.

3.1.5 Atom Architecture

The Atom architecture as proposed by [9] makes use of a UPnP Device Aggregatorand an Enhanced UPnP Device. The UPnP Device Aggregator is connected to thehome network, either as a stand-alone device or as a part of a router or a computer.The Aggregator collects information about the other devices within the networkit is connected to. It caches all the information collected in order to provide it toconnecting clients. The other main task of the Aggregator is to translate UDP SSDPmulticast packages into TCP unicasts because they cannot be relayed over the publicnetwork due to router limitations. To solve this problem the Aggregator listens forthese multicasts on the local network and when it receives one it translates it toa TCP unicast, using the Atom Publishing Protocol [10] and the Atom SyndicateFormat [11], and sends it to the remote devices and vice versa. The Enhanced UPnPDevice is modified in a way that it can read these Atom unicasts and translate them

18

CHAPTER 3. ANALYSIS

Figure 3.1. Generic Atom Architecture.

back to UDP so that the UPnP can understand them. The regular TCP unicastpackets in the UPnP architecture, i.e. SOAP, GENA and HTTP, is sent directlyto the device it is intended for without any involvement from the Aggregator. Anoverview of the architecture is found in Figure 3.1.

A client that wants to connect to a home network implements the EnhancedUPnP Device software. With the software enabled it can, whenever an Internetaccess point is found, act as if it were physically attached to the home network.It automatically connects to a predefined Aggregator, in which a tunnel betweenthe remote device and the home network is set up. The tunnel is a regular SSLVPN tunnel with HTTP authentication. This is to emulate the behavior of astandard UPnP device integrating itself into the network. When a new device hasconnected, the Aggregator sends an Atom feed containing all the available devicesand their services within the Aggregators network. The newly connected device canalso announce its own services to the Aggregator, in which the Aggregator turns theannouncements into UDP multicasts. These are then sent to the standard multicastaddress (239.255.255.250:1900) to which the other devices within the Aggregatorsnetwork are listening. The other devices within the network will now be aware ofthe new available remote device and its services in the same way as they are giveninformation about any DLNA device connected to the network. The Aggregator alsosubscribes to all devices (including any remote ones) in order for its informationcache to be up-to-date.

Devices within the home network receive normal SSDP announcements withservices offered by a remote device from the Aggregator but the URI within thebody of the message point to the remote device directly. This allows the rest of

19

3.2. RELATED TECHNIQUES

the UPnP communication to be handled directly between the home device and theremote device.

One big advantage with the Atom Architecture is that it allows the user todecide which devices the connecting client is allowed to see from outside. Thisincreases security in case the user would for example allow friends and guests toconnect. Another even bigger advantage is when the remote device is a batterypowered mobile device and power consumption is an important issue. Since theAggregator catches the local multicasts and caches all information about the localnetwork the connected device will not have to get all these announcements andwaste computational power to analyze them. The aggregator will only send updatedinformation to the connected device when needed. This can be compared to thesituation when the device would have received all the local UPnP traffic, in whichcase the amount of redundant data would be significantly higher.

Of all the solutions discussed in this chapter, the Atom Architecture might bethe one best suited for the problem at hand. However, using it directly in itscurrent form would be extending the scope of this Master’s Thesis. Although itsmain concepts are a good foundation for developing a final solution for the problem.

3.2 Related Techniques

In this section, techniques that can be utilized to solve the problem with remoteaccess will be analyzed.

3.2.1 DD-WRT and OpenVPN

DD-WRT [13] is a linux based third party firmware developed and released underthe GNU Public License (GPL) for routers based on the Broadcom or Atheros chipdesign. The DD-WRT firmware supports, among many things, OpenVPN [14] whichwill make it possible for a router running the firmware to set up a VPN bridge. AVPN bridge makes a single LAN span over several geographic locations and allowsthe devices to be located on the same subnet. Potential remote clients that alsoimplement OpenVPN are now able to connect to the bridge set up by the router.When doing so they will be given a new Ethernet interface with an IP addressin the same range as the the router’s LAN. While connected over the bridge theremote devices can act as though they were directly connected to the LAN behindthe router. This means that the client is also given access to the multicast addressof the LAN which is essential for a UPnP related devices.

This is a very interesting approach on solving the problem, but it requires arouter that either supports OpenVPN directly, or that the OpenVPN supportingfirmware from DD-WRT could be installed on the router. DD-WRT have a widearea of supported hardware.

20

CHAPTER 3. ANALYSIS

3.3 Developement Libraries for UPnPTo simplify the development process suitable development libraries had to be identi-fied. Since DLNA is based on UPnP and the resulting application is to be developedusing C++, focus will be on C and C++ libraries that simplify the developmentof UPnP related functionality. During the analysis four suitable open source de-velopment libraries were identified; Intel’s libupnp [31], Cyberlink for C++ [32],GUPnP [33] and Platinum [34]. Furthermore, Allegro has released a commercialdevelopment toolkit called Allegro RomPlug for UPnP and DLNA development [37].

It is quite hard to say which of them is the best, and this Master’s Thesis aimsnot to answer that question, but simply to outline the possible libraries that couldbe used for future development.

3.3.1 Intel’s libupnpIntel’s libupnp is by far the most well documented including detailed descriptionsof all methods that it provides. It also comes with its own thoroughly documentedXML parser and sample applications that one can study during development. Fur-thermore, libupnp is a C library and can therefore be a good choice when optimiza-tion might be needed. Mentionable is that libupnp is widely known and recognizedby developers. The libupnp library is released under the Berkeley Standard Distri-bution (BSD) license. This license states that redistribution of the library in sourcecode or in binary form, with or without modification, are permitted, provided thatsome conditions are met. These conditions include roughly that the redisributionshould contain the Intel copyright notice and that the name of the author may notbe used to endorse or promote the product developed using libupnp. Examples ofprojects using libupnp are MediaTomb UPnP media server, GeeXboX uShare A/Vmedia server, and eMule Morph.

3.3.2 Cyberlink for C++Cyberlink is also very well documented with sample programs and programmingguides. Being a C++ library Cyberlink provides more object oriented solutions.Cyberlink has for example predefined classes to represent UPnP devices and ser-vices, something that must be handled manually when using libupnp. There alsoexist Cyberlink libraries for C, Java, and Perl. The Cyberlink is, just like libupnp,released under the BSD license. The Cyberlink libraries are used in projects like theiMediaSuite for the iPhone.

3.3.3 GUPnPGUPnP is another well documented object-oriented C library. Just like Cyberlink, itprovides predefined classes for devices, services, etc. But unlike Cyberlink, GUPnPprovides a sophisticated API which can be accessed through its website. GUPnPalso comes with a few sample applications that can be studied. The license under

21

3.4. POSSIBLE SOLUTIONS

which GUPnP is released is GNU Lesser General Public License (LGPL). Thislicense states that GUPnP can be used in a non-open sourced product withoutbreaking the terms of the license. LGPL differ from the regular GPL in the sensethat it does not force an entire product to be open source if an element in thatproduct should be licensed under LGPL.

3.3.4 Platinum

Platinum however, has little to no documentation but comes with some sampleapplication that can be studied. Just like Cyberlink it is a C++ library. Platinumis released under the GNU GPL and states that commercially licensed software withPlatinum that do not wish to distribute the source code must enter into a commerciallicense agreement with Plutinosoft, LLC, the author of Platinum. Examples ofprojects using this tools are XBMC Media Center, Plex, Simplify Media, and Boxee.

3.3.5 Allegro RomPlug

Allegro RomPlug is a suite of software development toolkits to build UPnP andDLNA enabled consumer electronics and mobile devices. Unlike the other devel-opment tools mentioned Allegro RomPlug is not open source, it is a commercialproduct developed by Allegro Software Development Corporation. The tools aredelivered as ANSI-C source code and are built upon a highly portable abstractionlayer which enables it to work on any real-time operating system (RTOS) with aTCP/IP stack. The Allegro RomPlug is used in products like Microsoft Xbox 360,D-Link to enable UPnP Internet Gateway support in their devices, Yamahas neoHDDigital Media Player, and Philips Streamium HD Plasma TV just to mention a few.

3.4 Possible SolutionsFrom looking at what solutions are available the conclusion is that none of them,in their current form, are suited to fulfill the goal of this Master’s Thesis. But byanalyzing them, stripped down to their basic structure, it can be seen that mostof them are based on the client-to-server scenario. However, implementing thisscenario can be done in many different ways. The most important characteristicsof the solution are simplicity and expandability. It must be easy to install and usesince the end user might not be so familiar with all technical details. The solutionalso needs to be expandable to meet future demands that might arise. Furthermore,it should not require any changes to other DLNA devices already connected to thehome network.

When developing a solution to the remote access problem the focus will beon control since streaming would be extending the scope of this Master’s Thesis.Therefore, it is clear that the final solution must include a DMC in some way, and thefollowing sections will describe a few different ways of implementing such a solution.In Section 3.4.1, approaches where the server has an embedded DMC which can

22

CHAPTER 3. ANALYSIS

be controlled by a client connecting to the server will be described. Afterwards,in Section 3.4.2, a solution where the DMC is located on the client, which thenconnects to the remote network acting as a regular DMC, will be presented.

3.4.1 Client & Server ApplicationDividing the system into two parts, a server and a client side for remote access isessential in order to forward local traffic on the LAN to the remote device. Thisis due to the fact that DLNA devices uses UDP multicasts for device discoveryand this is generally blocked by most Internet routers. To get around this theserver is used to listen for discovery messages and forward these to potential clients.To implement the server some form of device on which external software could beinstalled is needed, like a PC, or a router. This device, which is visible from theoutside, is connected to the home network, and is running the server applicationto which potential clients can connect. Upon a client connecting, a Peer-to-Peer(P2P) communication link is set up. This would mean that both the server and theclient can take initiative to send data to one another. It is therefore possible forthe server to announce changes in the network to the client. One important aspectof the server is that it has an embedded DMC. A connected client granted accessto the server is also given control over the embedded DMC and thereby indirectlygiven control over the UPnP devices connected to the home network and all theservices they offer, thus solving the problem.

With this approach there are two questions that needs to be answered “Whereis the server application to be installed?”, and “How is the client interface imple-mented?”.

Server Side

Embedded within the server is a DMC which gathers information about the homenetwork, i.e., which services are available, and what actions can be invoked onthem. This data is then provided to any connecting clients. When answering thequestion “Where is the server application to be installed”, two main approachescould be identified, both with advantages and disadvantages. Running the serveron a home computer (Computer centered) or the home gateway, i.e., the router(Router centered).

• Computer centeredThe server is installed on a computer which has Internet access and is con-nected to the home network as illustrated in Figure 3.2. By making thesolution computer centered the goal of simplicity can be achieved since it canbe expected that the end user have the sufficient knowledge to install andconfigure an application. It is also possible to increase the portability of theserver with this approach. By making the server platform independent, thiscould be done by for example developing the server using Java. By doing soit would be possible to install and use the server on various platforms that

23

3.4. POSSIBLE SOLUTIONS

Figure 3.2. Computer centered. The remote device is connected to the computerrunning the server application through the router of the home network.

support Java. However, the main disadvantage is that users do not want theircomputers running constantly, thereby making noise and consuming electric-ity, just to support this service. Another disadvantage is that nowadays mostusers have some form of home gateway (i.e., a router) that acts as a gatewayto the Internet. This means that if the program is going to run on a com-puter, the router needs to be configured to forward traffic to the computer ona specific port. Configuring this can prove cumbersome for some users. To beable to circumvent the configuration of a router, support for Internet GatewayDevice (IGD) could be added in order to automatically control the port for-warding. IGD is an UPnP standardized device implemented by many homerouters and enabled with default settings on computers sharing an Internetconnection using Windows XP or later. What it does is to allow a local UPnPcontroller to perform different actions on the home router, i.e., adding andremoving port mappings, retrieve the external IP address, and detect existingport mappings. By implementing this, the server could automatically openup a port and forward it to the server and thus making it visible from outsideof the home network.

• Router centeredThe server is installed on a router connected to the home network to whichthe remote client can connect as illustrated in Figure 3.3. By making thesolution router centered the problem with having a computer on stand-by allthe time is solved. Since the router in a home network already is runningconstantly there would be no notable difference from the end users point ofview. However, there are not many routers available that support installationof external software. To install and configure the software a great deal oftechnical expertise is required, more than can be expected from an end user.

Client Side

For the remaining question “How is the client interface implemented?” two answershave been identified; either as a software on the client mobile phone or as a webbased control page.

24

CHAPTER 3. ANALYSIS

Figure 3.3. Router centered. The remote device is connected directly to the routerrunning the server application.

• Software interfaceA software GUI is installed on the target mobile phone. This GUI providesservices for connecting to a given server (i.e., a computer or a router) throughan IP address and a port number. Thus the target mobile phone is givencontrol over the server and the embedded DMC, presenting the devices, withits services and their actions, to the user which the server has collected fromthe home network.With this approach it is easier to make a user-friendly interface that is dedi-cated for mobile phone usage.

• Web based interfaceBy adding a web server feature to the server application it would be possiblefor the server to provide a control page containing all available actions thatcan be invoked on services and devices within the home network. The clientcan access this control page from any given web browser in order to invokecommands on the embedded DMC of the server.With this approach it is possible to increase the availability of the systemsince the control page can be accessed from any given web browser. However,handling a web page in the web browser of a mobile phone can prove to bevery tedious, and the usability of the system may suffer.

There is however one main disadvantage which is common for all of the client-to-server approaches. In the future new demands to expand the implementation withnew features will most likely arise, such as streaming audio and video from the homenetwork to the client (i.e., the mobile phone). With the client-to-server solution thisinvolves expanding both the client application, and the server application, since noneof them would be prepared to handle this scenario.

3.4.2 Ethernet Bridging using DD-WRT and OpenVPNAnother possible solution would be to use the DD-WRT firmware as described inSection 3.2.1. With this approach a router supporting the DD-WRT OpenVPN com-patible firmware needs to be set up. There are a wide variety of routers supporting

25

3.4. POSSIBLE SOLUTIONS

Figure 3.4. The mobile phone is connected to the bridge set up by the router, thusletting it act as though it were directly connected to the router itself.

DD-WRT, Linksys WRT54GL [28] being one of the most popular. By connectingthis router to the home network and configuring it to set up a VPN bridge, thehome network is made available to remote clients. A client that wants access to thehome network must support OpenVPN through which it can connect to the bridge,i.e., the IP address of the router. Upon connecting, the client will be given a newEthernet interface with an IP address in the same range as the routers LAN. Thiswould mean that if the client were to be a DLNA device and connected to a bridgeit would be able to act as a normal DLNA device directly connected to the LANbehind the router holding the bridge.

Realizing this, a solution to the problem would be to set up the device desiredfor remote control of the home network, with a DMC application and OpenVPNsupport. The remote device considered for this Master’s Thesis is a mobile phonerunning a Linux platform to which OpenVPN could easily be integrated. Once themobile phone is equipped with OpenVPN support, it is able to connect to the bridgesetup on a remote router. With the DMC application installed it will be able to actas a regular DMC connected to that routers LAN, controlling the devices withinthat network and partaking in the communication as any other DLNA device. Inother words with the bridge set up all LAN traffic, including multicasts, can nowtravel freely over it to the remote device as illustrated in Figure 3.4. The mainadvantage with this approach, compared to the client-to-server approach, is thepossibility for future expansion. It is most likely that the demand for new featureswill arise in the future. For example a demand for audio and video streaming tothe client would just enforce the client to implement a DMP application. Since thebridge allows the client to act as though it were in fact connected directly to the

26

CHAPTER 3. ANALYSIS

home network there is no need for further modifications.

3.5 Choosing an ApproachHaving analyzed these different solution possibilities, one main approach were de-cided upon. Since ST-Ericsson wants their future mobile phones to be able tosupport all kinds of DLNA device classes, not only DMC, it is clear that expand-ability is very important for the solution. Therefore, to support this demand thedecision to use the DD-WRT with OpenVPN approach was made.

Furthermore, a development library also needed to be picked out of the onespreviously identified in Section 3.3. Intel’s libupnp were decided upon mainly basedon its good documentation and reputation.

27

Chapter 4

Design and Implementation

In this chapter a more detailed description on how the DD-WRT solution wasimplemented, will be given. A short description of the tools and hardware used inthe implementation is provided in Section 4.1. It is followed by a description of theOpenVPN bridge setup in Section 4.2. Finally in Section 4.3 a short description ofthe DMC application developed, for the target mobile phone, during this Master’sThesis will be made.

4.1 Tools and Hardware

Linksys WRT54GLThe router used during the implementation which supports DD-WRT and is theacting server.

DD-WRT VPN Generic FirmwareThe firmware flashed into the Linksys WRT54GL router which will enable it to runOpenVPN.

Openmoko FreerunnerThe test phone used during the implementation. It runs on a Linux based platformand is the acting client.

Intel’s libupnp v1.6.6The library supplying UPnP related functionality.

GtkmmA C++ wrapper for GTK+ used when developing the Graphical User Interface(GUI) for the client application.

4.2 VPN Bridge Setup

In order to implement this solution, support for OpenVPN is required on both theserver (i.e., Linksys WRT54GL) and the client (i.e., the Openmoko Freerunner).

29

4.2. VPN BRIDGE SETUP

This section will, in short, describe how to integrate OpenVPN support on thesetwo devices.

Since the WRT54GL default firmware does not support OpenVPN it needs to beflashed with a new firmware. The firmware used in this Master’s Thesis is DD-WRTVPN Generic for WRT54GL v24 supplied by DD-WRT [13].

Adding OpenVPN support on the Freerunner is trivial and can be handled bythe common Linux command opkg install.

Before the bridge server can be started a new virtual TAP (as in network tap)interface needs to be added on the server. A TAP interface simulates an Ethernetdevice on a layer 2 level of the OSI-model and operates on Ethernet frames [30].When a remote device connects to the VPN bridge, OpenVPN creates a new TAPinterface on that device as well. It is through these TAP interfaces that the VPNbridge will route all traffic.

There is a difference between the TAP interface on the server and the client. Onthe server side the TAP interface is integrated with the local interface then bridgedtogether with the TAP interface on the connecting client’s side. By doing so andproperly configuring the routing table it is now possible for traffic to flow freelybetween the TAP interface and the local interface that it is being bridged with.The TAP interface is not given a separate IP address on the server side since it isconnected with the local interface.

On the client side the TAP interface is treated as a new Ethernet device and isassigned an IP address, which is on the same subnet as the local interface on theserver side, when the connection is established between the client and the server.

Figure 4.1 illustrates how traffic flows from the local network on the serverside into the eth0 interface. If the packages destination is a device on the samesubnet the router will check the address of the packages. If the address is to adevice remotely connected the packages will be forwarded into the tap0 interface.If the destination is a device connected to the router locally it is forwarded to itwithout going through the tap0 interface. If the packages destination is a deviceon the Internet they will forwarded into the eth1 interface and out on the Internetfrom there. When the packages destined for a remotely connected device enters thetap0 interface they will be handled by the OpenVPN software and encrypted usingOpenSSL [29]. After encryption, the packages are sent through the eth1 interfaceand over the Internet to the client. When the client receives the packages they aresent into the OpenVPN software where they are decoded and passed on to the tap0interface. As the packages arrive at tap0 they are handled by the client in the sameway as if they would come through a regular Ethernet interface. The flow fromserver to client, as described above, goes the same way in the opposite direction.

Since OpenVPN enforces Secure Socket Layer (SSL) Authentication [26] forsecure access the next step after configuring the network, is to create keys andcertificates for the server and the clients. OpenVPN comes with sample scripts andconfiguration files to help users configure it properly. Among these there are scriptsfor generating the Certificate Authority (CA) and its private key, the Diffie-Hellman(DH) key, and the server and clients certificates and its corresponding private keys.

30

CHAPTER 4. DESIGN AND IMPLEMENTATION

Figure 4.1. Illustration of the flow between interfaces in an OpenVPN environment.

Every client that later wants to connect to the bridge needs to have his own set ofkey and certificate.

Once the proper keys and certificates have been integrated on the involved de-vices and the pre-setup is complete, the server can be started. Starting the serveris done automatically in the WRT54GL upon start-up of the router, meaning, oncethe bridge has been configured it will always be available without further mainte-nance. The configuration file which is to be used by the server can be specifiedthrough the WRT54GL’s control page. The client is now able to connect using aclient-oriented configuration file. For the server, and client configuration used inthis Master’s Thesis and more details on VPN bridge setup please consult the usermanual, Appendix A.

4.3 Remote DMCWhen designing the DMC an early decision to utilize the Model-View-Controller(MVC) pattern was made, or rather a modified version of MVC more suited for thedevelopment of the DMC. By using this pattern the application can be divided intothe following three parts:

• The Model which stores the data.

• The View which presents the data.

• The Controller which modify the data.

The relations between these three parts, as implemented in this Master’s Thesis,is illustrated in Figure 4.2. The controller has a reference to the model in orderto add and modify data, and the view has references to both the model and the

31

4.3. REMOTE DMC

Figure 4.2. The Model-View-Control pattern used for the design of the DMC.

controller in order to present the data stored and to invoke changes on it throughthe controller. With these relations it is clear that the controller and the modelcould work fine without the view since they have no references to it. The goal ofthe pattern, to be able to switch view easily without affecting the core functionalityof the controller and the model, is thereby achieved. One can now pick an arbitraryway of presenting the data without needing to change the controller or the model.This would prove valuable for this Master’s Thesis since both a console based GUIand a traditional GUI were implemented.

The core functionality of the application is concentrated to five main classes.To avoid a too detailed description of the implementation the focus will be on theclass-level. This level of abstraction should be sufficient to create an understandableoverview of the application.

Main - DigitalMediaControllerContains the main-method which creates all classes and links them according to theMVC pattern. The main task of DigitalMediaController is to initiate the UPnPcontrol according to libupnps implementation. This involves specifying which inter-face the DMC should listen to, and to specify a callback-method which handles allincoming UPnP events. Once everything has been initiated it creates the view.

Model - ModelHandlerThis is the model which contains all data gathered by the DMC, i.e., essentially alist of devices which are connected to the network. A device in this list contains,among other things, a name, a unique UUID, the device type, and a URL for itsdevice description, from which services and actions can be extracted. By storinginformation about a device’s services and the related actions the ModelHandler al-ways knows, and can inform, about the functionality supported by the device. TheModelHandler also provides various methods to extract and manipulate the devicesstored in the list, but all changes to the data must be handled through the Model-Handler to ensure thread safety.

32

CHAPTER 4. DESIGN AND IMPLEMENTATION

View - ConsoleThe fist implementation of the View was a simple input/output console UI lettingthe user interact with it through numeric inputs to the terminal. But even thoughbeing so simple it still provides all functionality desired for a DMC, including M-SEARCH, Browsing, Searching, and Controlling. The DMC is designed to registerall UPnP devices, not only DLNA compatible ones, and it is possible to list themdown to their actions.

When browsing a selected DMS, the DMC sends a browse request for the root ofthe DMS. In response, the DMS send the content, consisting of files and folders, of itsroot to the DMC. Presented with this content further browsing is possible througha container ID associated with each folder. Searching works in a similar manner,but instead of browsing the root, a user searches for a phrase and is presented withall folders and files associated with this phrase. From there it is possible to furtherbrowse the found folders.

When initiating control of a given DMR, after selecting a file through browsingor searching, the URI of the file is sent to the given DMR along with the metadataof the file. Afterwards the UI goes into “play mode” in which the user can invokeplay, pause, stop, etc. It is also possible to control the playback of a given DMRwithout selecting a file, in which case the DMC asks the DMR for its active playbackand the associated metadata and then enters the “play mode”.

For a more detailed user description please consult User Manual in AppendixB.4.1.

View - DMCGUIA console based UI might not be the most user-friendly option to work with on amobile phone. Because of this a traditional GUI is more desirable and such a GUIwas therefore developed without modification to the controller and model, therebyproving that the MVC pattern is indeed very useful. The designing of the GUI wasdone with the help of Glade which is a drag-and-drop GUI editor for GTK+ [36].The created GUI was then easily imported into the DMC by functionality providedby libgtkmm [35].

The new GUI implements some, but not all, of the functionality of the consoleUI. Things that differ from the console UI include a modified M-SEARCH thatonly searches for DMSs and DMRs since they are the main target for the DMC.Furthermore, by only searching for DMSs and DMRs the UPnP traffic, which puts astrain on the mobile phone, is limited to some extent. The ability to search for fileshas not been implemented due to functionality that involves typing is preferablyavoided on a mobile phone. The only new functionality that has been added is atrack bar, informing the user of the position in the playback. This had to be doneby continuously asking the DMR “where are you now?”, so called polling, in whichit responds with the playback time. This is due to the possibility of another userseeking in the playback directly on the device, or from another controller. For amore detailed user description please consult User Manual in Appendix B.4.2.

33

4.3. REMOTE DMC

Control - UPnPEventHandlerThis is the class designed to handle all UPnP related traffic, both incoming andoutgoing. All incoming UPnP events are routed through a single callback-method,specified when initiating the UPnP control. Upon the arrival of such an event themethod first looks at the event type, which could be 1 out of 15, in order to identifyand handle the event accordingly. An example of an event could be a so calleddiscovery event, which is sent out by other devices upon connecting to, or leavingthe network. They will also be sent out as a response to an HTTP M-SEARCH. Inthe case of an incoming discovery event the related device information is extractedand stored, alternatively updated, in the ModelHandler.

The outgoing traffic from the application is made up of action requests aimed forregistered DMSs and DMRs since it is these two types of devices a DMC normally isused for controlling. UPnPEventHandler has implemented DMR related methodsto invoke, play, stop, pause, seek, change volume, mute, and record. It has alsoimplemeted DMS related methods for searching and browsing. These methods arethe basis for initiating and controlling an active playback on a given DMR. Althoughsupport for all this functionality is not required by the DLNA guidelines and mighttherefore not be implemented by the target device, the support can easily be verifiedthrough the ModelHandler which stores this information.

Furthermore, all outgoing action request is in the form of an XML documentwhich contains all arguments that the given action requires. Generating these ac-tion request is done with the help of libupnps predefined methods.

34

Chapter 5

Limitations

A few limitations with the proposed solutions can be identified. In Section 5.1 theissue of a weak router holding the VPN bridge will be analyzed. The problem ofhigh power consumption will be described in Section 5.2. Finally, a short descriptionof the multi-interface support limitation will be presented in Secion 5.3.

5.1 Router Bottleneck

In a LAN all communication passes through the local router. This means that thetraffic to, and from, devices extending the LAN have to pass through the router aswell. When extending the LAN through VPN bridging, with more than a singlemobile phone, the router holding the VPN bridge must be quite powerful to beable to handle all incoming VPN traffic since it need to be decrypted. Due to this,a weak router could introduce a bottleneck to the system and thereby limit thecommunication and playback possibilities.

A test was performed with the Linksys WRT54GL router to get an assessmenton how serious this bottleneck actually is. The test was made by first doing atransfer of a large file via FTP (File Transfer Protocol) from one computer on theinternet to another. When not routing the traffic through the OpenVPN bridge anaverage speed of 3.3 Mb/s was achieved. The same test was then repeated but nowthrough the VPN bridge where an average speed of 250 kb/s were reached, whichis a 92% decrease in speed.

The result here is not a static percentage based decrease in speed but a limitationby the routers CPU, thus if the speed of the connection would increase, the speedthrough the VPN bridge would still be capped around 250 kb/s. This is a seriousbottleneck in a use case where high definition video is suppose to be streamed to aconnected device. Also, if several clients are connected at the same time the speedwould decrease even more due to the CPU power needed to encrypt and decryptthe additional connections.

35

5.2. POWER CONSUMPTION

Figure 5.1. Illustration of how the network, used for the battery consumption tests,was set up.

5.2 Power Consumption

While connected to the bridge of a LAN, the mobile device is exposed to a lot oftraffic that occupies the processor, causing the battery to drain faster. Even more sowhen the DMC is running on the phone, because then all UPnP traffic originatingfrom the home network, is forwarded over the VPN bridge and has to be handledby the phone.

The power consumption depends on the actual use case, e.g., if the user connectsto a home network in order to invoke an action, or to check the status on a device,then immediately disconnects. That way the time spent actually connected will berelatively short and the amount of multicast traffic affecting the mobile device low.Being connected over longer periods of time would inevitably increase the batteryconsumption. Use cases of longer connection sessions would be streaming music ormovies to a mobile device. In these scenarios the broadcasts on the network willbe negligible in comparison to the actual data being transferred over the stream.Another future scenario that demands constant connectivity where the traffic ofthe LAN actually affects the mobile device would be when letting the mobile deviceact as a DMS. For example, running the mobile device as a DMS connected to thehome network would let family and friends view photos and video clips as soon asthey are taken.

To be able to estimate how much the multicast traffic actually affects the powerconsumption a test network were set up, using a computer running Windows 7and acting as both a DMR and a DMS, and with a separately installed DMS. Thismeans that the same computer was actually running one DMR and two DMSs. Thiscomputer was set up behind the Linksys WRT54GL router acting as the OpenVPNserver. The network setup used for the tests can be seen in Figure 5.1. A side notehere is that Windows 7 does a lot of broadcasts looking for UPnP enabled routersand these broadcasts will also be forwarded to the mobile device.

36

CHAPTER 5. LIMITATIONS

95% 90% 85% 80% 75% %/minIdle 14:35 34:13 49:48 62:47 80:33 0.3104Wi-Fi active 12:30 25:40 39:08 51:39 64:17 0.3889VPN Bridge 12:30 25:02 38:31 51:12 63:56 0.3910DMC active 12:43 24:54 37:16 48:51 60:13 0.4152

Table 5.1. Table showing battery drain in minutes.

To analyze the battery consumption, the test phone (Openmoko Freerunnerrunning Debian) was studied in four different environments. For each test thephone was charged to 100% and then discharged to 75% while timed in order tomeasure the relative battery consumption. The different environments taken intoaccount for this test were;

• IdleThe phone is exposed to no network activity or other demanding elements.

• Wi-Fi activeWi-Fi is activated and the phone is connected to an open network with notraffic.

• VPN BridgeWi-Fi is activated and the phone is connected a home network through aOpenVPN bridge thereby exposed to the broadcasts of the home network.

• DMC activeWi-Fi is activated and the phone is connected a home network through aOpenVPN bridge and the developed DMC is running. The phone is nowexposed to the broadcasts of the home network and must now also handle allincoming UPnP traffic.

The result of the tests performed are shown in Table 5.1. The measured times in thetable are represented in minutes. From the results in the table we can see that it isthe Wi-Fi that causes most battery to be drained. It shortens the battery life witharound 20%, which is not very surprising since the Wi-Fi requires extra hardwareto be active in the Openmoko Freerunner. The difference between just having theWi-Fi active and having the VPN bridge connected is, as seen in the table, verysmall. By being connected to the VPN bridge, the battery life is shortened with0.5% compared to having only the Wi-Fi activated.

The difference between having the phone running in idle mode and having theDMC application running on the Openmoko Freerunner, while it is connected to ahome network through an OpenVPN bridge, is a 25% drop in battery life. This isquite a noticeable difference. However, the majority of the battery consumption is,according to the test performed, due to the Wi-Fi connection.

37

5.3. MULTI-INTERFACE SUPPORT

The battery life of the Openmoko Freerunner is abysmal, in idle mode the life-time is around five to six hours. It would be interesting to see these tests beingperformed on a mobile phone with more power saving features and a lower overallpower consumption.

5.3 Multi-Interface SupportPicture the scenario where the mobile phone is connected to network: A) throughregular Wi-Fi and then tapped into the bridge of network, B) through OpenVPN.With the current implementation it is only possible to be active on one interface ata time, either A’s or B’s. Because of this it is not possible to set up a stream ofmedia from a DMS within network A to a DMR within network B, or vice versa forthat matter.

38

Chapter 6

Conclusions

First off, a few conclusion can be drawn about the DLNA standard. The standardis still fairly young and need more time to settle in, which soon became clear duringthe analysis part of this Master’s Thesis. For instance a device like a Full HD TVcan be certified by DLNA as a DMP even though it can not support HD videoformats. The fact that so few formats, or media profiles, need to be supported fora device to get certified is a big disadvantage since nowadays media is distributedin various formats and far from all home digital media is stored in these formats.Due to this a device can get DLNA certification even though it can do very little.

The results from the work conducted in this Master’s Thesis is a fairly simpleway to access a home network with the use of a VPN bridge. Using a VPN bridgeone can expand the span of a LAN to reach over a virtually wide area. The bridgewill allow a connecting client to act as though it was in fact connected to the networkdirectly, just like any other local device within that network. Therefore it can alsoact as a local device, thus eliminating all issues that the remote location of theconnecting device introduces.

The main idea is that the owner, or operator, of a home network containingDLNA devices, who wants to grant remote access to connecting clients, sets up theVPN bridge server on his local router. Clients can now connect to this router and setup a VPN bridge between the remote device and the router. Once this connectionis established the connecting remote device will be viewed as a local device on therouters LAN.

Based on this solution a DMC for a mobile phone was developed to demonstratethat it actually works. OpenVPN support was added to the mobile phone and itcould therefore connect to a VPN bridge set up on a test network. Once connected,the phone was able to act as a normal DMC controlling the devices within thatnetwork, as well as other remote devices also connected to the bridge. This wouldprove that by the use of VPN bridging between devices and home networks theproblem with remote access is now reduced to merely a local access problem.

39

Chapter 7

Future Work

The solution proposed in this Master’s Thesis does not limit the type of deviceclasses that can be implemented on the remote device. What can be implementedon a remote device, in the terms of UPnP functionality, is only limited to its supportfor OpenVPN and the definitions of the UPnP protocol. One can now, by utilizingthe solution proposed, develop a system on the local scale without worrying aboutthe issue of remote access. This will make it easy to, in the future, implement DMPsand DMSs on a target mobile phone which has remote access to the home network.

The future of DLNA is a bright one, but as explained in Chapter 6 the standardis still fairly young and needs more time to settle in. It is still under constantdevelopment and DLNA Guidelines v2.0 is planned to be released 2010. In this newversion the DLNA organization themselves aims to solve the problem with remoteaccess to ones home devices. Remote access is a hot topic for the future and theUPnP Forum is also working on their solution to the problem which is also plannedto be released later this year. A future task would therefore be to compare thesolution proposed in this Master’s Thesis with the ones proposed by DLNA andUPnP in order to use the one most suitable for further delevopment.

Another thing left for future work would be to look deeper into VPN techniquesand standards. One interesting part would be to analyse mVPN (mobile VirtualPrivate Network) which is a VPN technique more suited for mobile devices wherethe device might roam between different cellular networks or Wi-Fi access points.Conventional VPN cannot survive when the bridge gets disrupted and can causecrashes in the application due to the loss of connectivity and might even cause theentire device to crash.

As described in Section 5.3 the support for multi-interface connectivity is notimplemented. Letting a remote device be connected to several different networksat once would not be very hard, but having it link devices between those networkis more difficult. One approach would be to let the remote device act as a type ofgateway, pulling media of a device within one network in order to forward it to adevice within another network.

41

Appendix A

User manual - OpenVPN

In this appendix, detailed instructions on how to set up an VPN bridge for homenetwork access using a WRT54GL router is given. A description on what is required,and how to get started, is provided in Section A.1. It is followed by a descriptionon how certificates and keys are generated for OpenVPN in Section A.2. Then, inSection A.3, instructions on how to configure the server on the WRT54GL routercan be found. Finally, in Section A.4, instructions on how to configure a client isgiven.

A.1 Getting StartedAssuming that a connection to the router has been established, support for Open-VPN can now be added. Go to http://www.dd-wrt.com and navigate to the routerdatabase and search for WRT54GL. Once you found the download page be sure todownload both the Mini Generic and the VPN Generic firmware.

Access theWRT54GLWeb GUI through its default IP address, http://192.168.1.1.Go to Administration->Firmware Upgrade in order to flash it with the newfirmware. Initial flashing with the Mini Generic firmware is required to open upthe router for further flashing. First flash the router with Mini Generic then withVPN Generic to enable OpenVPN support. After this you are all set to proceed.

A.2 Generating Certificates and KeysThis section will describe how to generate the keys and certificates needed by theuse of a computer running on Linux system. The first order of business is to in-stall OpenVPN, which can be done with the common Linux command apt-get.apt-get install openvpn

Now with OpenVPN installed the first thing that needs to be done in order to setup a working OpenVPN bridge is to generate the SSL authentication certificatesand keys for the server and its clients.

43

A.2. GENERATING CERTIFICATES AND KEYS

All the scripts needed to generate these certificates and keys are provided byOpenVPN. Now access the default folder containing these scripts.

cd /usr/share/doc/openvpn/examples/easy-rsa/1.0

Next step is to set up the proper environment. You must have root privileges togenerate the keys and certificates and therefore you need to set up the environmentas root.

sudo -ssource ./vars./clean-all

It is also possible to modify the environment by rewriting vars. The vars file con-tains, among many things, the key size and certificate information such as CountryName etc. Having set up the proper environment you can move on to generatingthe CA.

./build-ca

You will be prompted with Country Name, State or Province Name etc. and giventhe option to modify this information, but can use the default values by leavingthese fields blank. By doing this you will create the CA certificate, ca.crt, and itscorresponding private key, ca.key, and put both of them in the keys folder. Thenext step would be to generate the DH key.

./build-dh

The resulting key, dh1024.pem, will also be placed in the keys folder. Now it istime to generate the server certificate.

./build-key-server server

Just like when generating the CA you will be prompted with the same modificationoptions. But keep in mind that the CA, server, and clients all need to have the sameCountry Name, State or Province Name, Locality Name, and Organization Name.You will also be prompted with a request for a Common Name, in which you needto specify a name for the server. Furthermore, you will be asked for a challengepassword, just leave this field blank. The server.crt and the server.key will alsobe placed in the keys folder. Now the key set up is almost done, the only thingremaining is the keys and certificates for the clients. To generate these use thefollowing script.

./build-key client_john

The certificate and key for the client John will now be placed in the keys folder in

44

APPENDIX A. USER MANUAL - OPENVPN

the form of client_john.crt and client_john.key. This script can be used togenerate keys and certificates for all clients that want access to the server. But itis also possible for all clients to use the same key and certificate pair.

A.3 Configure the Server

Before you start configuring the server make sure that the Linksys WRT54GL isflashed with the VPN generic image as described in Section A.1 and that you havegenerated the proper certificates and keys as described in Section A.2.

Enter the Linksys Web GUI by opening a web browser and enter its default IPaddress. Now go to section Services->VPN which became available after flashingthe router with the VPN Generic image.

Under OpenVPN Daemon make sure Start OpenVPN is set to Enabled andStart type is set to Wan Up, see Figure A.1. This is to make sure OpenVPN isstarted when the router starts. When these boxes are checked a number of boxeswill appear.

Figure A.1. The box to check on the DD-WRT OpenVPN configuration page.

In the box labeled Public Server Cert the CA certificate (ca.crt) should beinserted. Do this by opening the CA certificated generated earlier in a text editorand copy everything from

––-BEGIN CERTIFICATE––-

to

––-END CERTIFICATE––-

You should also include the actual begin and end lines from all certificates and keysin the boxes.

In the box labeled Public Client Cert the Server certificate (server.crt)should be inserted in the same way. In the Private Client Key box the server key(server.key) should be inserted. In the DH PEM box the DH key (dh1024.pem)should be inserted. In the OpenVPN Config box the following lines should beinserted (if you wish to disable something here you can either leave the line out or

45

A.3. CONFIGURE THE SERVER

insert a “;” in front of it to comment it out):

server-bridge 192.168.1.1 255.255.255.0 192.168.1.200 192.168.1.250

This will tells OpenVPN that it is an Ethernet bridge that is suppose to be set upand that the local IP of the router is 192.168.1.1 with netmask 255.255.255.0 andthat IP addresses from the range 192.168.1.200 to 192.168.1.250 should be usedwhen assigning IPs to connecting clients.

proto udp port 1194

This tells OpenVPN to use the UDP protocol on port 1194.

dev tap0

This line specifies which TAP interface to be used.

keepalive 15 120

This enables a heartbeat ping to be sent every 15 second back and forth to the con-necting clients to verify that the connection is still active. If no response is receivedfor 120 seconds the peer is assumed to have lost the connection.

verb 5mute 20

Logging options. The verb line enables logging to a log file and the number afterit specifies how detailed the logging should be. It can be between 0, which is com-pletely silent, and 9 which is very detailed. The mute makes sure a maximum of 20sequential messages of the same message category can be written to the log.

daemon

This line makes sure OpenVPN is started in daemon mode and is required whenrunning it on the WRT54GL.

comp-lzo

This enables compression on the link. This must be enabled on connecting clientsas well.

client-to-client

This line enables the connecting client to see each other just like if they were on thesame LAN. Not using this option will still enable the clients to see all the devicesconnected to the servers LAN, but not other clients.

46

APPENDIX A. USER MANUAL - OPENVPN

persist-tunpersist-key

The persist-tun line makes sure OpenVPN does not close and reopen the TAP/TUPinterface on ping-restarts and similar. The persist-key line makes sure the keysare not re-read on ping timeouts.

duplicate-cn

This will allow multiple clients with the same certificate/key or common names toconnect. This should only be used for testing and is not recommended.

tls-server

Enables SSL/TLS Server.

ca /tmp/openvpn/ca.crt

dh /tmp/openvpn/dh.pem

cert /tmp/openvpn/cert.pem

key /tmp/openvpn/key.pem

The certificates and keys inserted into the boxes will be saved to the following filesand these lines tell OpenVPN where to find them.

When every box is filled in make sure to press Apply Settings at the bottomof the page to save and apply the settings.

When this is done, a startup script should be added to setup the TAP interfacewhen the router is booted. To do this go to Administration->Commands andpaste the following into the Commands box:

openvpn –mktun –dev tap0

brctl addif br0 tap0

ifconfig tap0 0.0.0.0 promisc up

sleep 10

route add -net 192.168.1.0/24 dev br0

This will create the tap0 interface, bridge it with the local Ethernet interface, andadd the routing needed to make sure the packages is going the right way.

To save these settings as a startup script press the Save Startup button at thebottom of the page.

47

A.4. CONFIGURE THE CLIENT

Next we will need to configure the firewall. To do this paste the following intothe Commands box:

/usr/sbin/iptables -I INPUT -p udp –dport 1194 -j ACCEPT

/usr/sbin/iptables -I FORWARD -i br+ -o tap+ -j ACCEPT

/usr/sbin/iptables -I FORWARD -i tap+ -o br+ -j ACCEPT

This will open up the UDP port 1194 to allow clients to connect. It will alsomake sure the packages from the br0 interface (the interface already set up on theWRT54GL for bridging the Wired LAN with the Wireless LAN) flow to the tap0interface and vice versa.

To save these settings as a firewall script press the Save Firewall button at thebottom of the page.

A.4 Configure the Client

Having reached this stage you have now flashed the Linksys WRT54GL router withthe VPN Generic firmware to add OpenVPN support as described in Section A.1.You have also generated the proper keys and certificates as described in A.2. Finally,you have configured the server to set up the VPN bridge as described in SectionA.3. Having done all this you are now ready to connect to the bridge, but in orderto do this you need to configure the client.

This section will describe the configuration-file used by John on the client sidewhen connecting to the bridge set up on the WRT54GL router.

pico client_john.conf

The text editor pico, which is a common linux text editor, could be used to createthe configuration-file, but you may use any given text editor for this. Then insertthe following lines.

client

Tells the server that John is a client.

dev tap

Specifies that it is a bridge you are connecting to. This can be set to dev tun if itis a tunnel you are connecting to.

proto udp

Specifies that you are connecting to a UDP server (make sure that the server is set

48

APPENDIX A. USER MANUAL - OPENVPN

to UDP, see A.3). This can also be set to porto tcp if the server is a TCP server.

remote <address.to.bridge> 1194

Specifies the address and port to the server. Replace <address.to.bridge> withthe actual IP-address to the bridge. 1194 is the default port used but may bechanged.

resolv-retry infinite

Makes the client keep trying to connect upon connection lost. For example, thiscould be useful on a laptop that is not permanently connected. With this enabledthe laptop will automatically connect to the bridge when Internet access is provided.

nobind

Specifies that any local port on the client side can be used.

persist-keypersist-tun

The persist-tun line makes sure OpenVPN does not close and reopen the TAP/TUPinterface on ping-restarts and similar. The persist-key line makes sure the keysare not re-read on ping timeouts.

ca ca.crtcert client_john.crtkey client_john.key

Specifies the keys and certificates needed for the SSL/TLS handshake. The keysand certificates needs to be in the same folder as the configuration-file or given thefull search path in the configuration-file.

comp-lzo

Enables compression over the VPN link. In order for it work properly the servermust also have this functionality enabled.

verb 3

Specifies how detailed the logging should be. It can be between 0, which is com-pletely silent, and 9 which is very detailed.

Now save client_john.conf and you are ready to connect to the server usingthe following command:

openvpn client_john.conf

49

A.4. CONFIGURE THE CLIENT

Verify your connectivity with ifconfig to see that you are provided with a newinterface called tap0. This tap interface should be given an IP address within thesame range as the servers LAN.

50

Appendix B

User manual - RG DMC

This appendix describes how to install, and use the application developed duringthis Master’s Thesis. A description of what the prerequisites are, and how to installthem, is given in Section B.1. It is followed by instructions on how to install theDMC application in Section B.2. Then, in Section B.3, it is described how to startthe application. Finally, in Section B.4, instructions on how to use the program isfound.

B.1 Getting StartedBefore you can start using the application you need to make sure the libraries itdepends on are installed on the target system. The following libraries are required:

• libupnp [31]

• libgtkmm [35]

B.1.1 Installation on a Debian Based System (e.g. Ubuntu)Both libupnp and libgtkmm exists as a precompiled package and can be downloadedand installed very easily through the package manager. In Ubuntu it can be foundunder System->Administration->Synaptic Package Manager. Search for“libupnp” and you will find libupnp3 in the list and mark it for installation. Nowsearch for “libgtkmm” and you will find libgtkmm-2.4-XXX in the list. The XXXis a version number and will vary. Mark it for installation and click Apply andfollow the instructions.

In other Debian based systems without a graphical package manager, the con-sole based apt-get can be used. The following line will install both packages andtheir dependencies.

apt-get install libupnp3 libgtkmm-2.4

51

B.2. INSTALLATION

B.1.2 Installation on a Linux System.

To install it on a Linux based system that does not have a package system likeDebian you need to manually download the tarballs and compile the code yourself.Download libupnp from http://pupnp.sourceforge.net/ and untar it (make sure toreplace the X with the correct version number) using:

tar xvfj libupnp-X.X.X.tar.bz2

When this is done you enter the directory which was created during the untaringand then set up the variables and flags correctly using configure.

cd libupnp-X.X.X./configure

You are now ready to compile by issuing the following command:

make

If you encountered any errors here it is most likely due to libtool since the most re-cent version libtool 2.2.6a does not allow libupnp to be compiled correctly. Tocircumvent this problem downgrade to libtool 1.5.26 and it should work.

Now you have a compiled library ready to be used. There only thing that re-mains is to copy it into the system library folder which is where applications searchesfor needed libraries. To be able to do this you need to have root access to the com-puter. Do the following:

sudo make install

The libupnp library is now installed and ready to be used. Now this procedure canbe repeated for libgtkmm but with the difference that it has a few dependencies thatneeds to be installed in the same way. The tarball and which dependencies that areneeded can be found on their webpage http://www.gtkmm.org.

B.2 Installation

Once the dependencies have been installed on the system it is time to install theRG DMC application. This is done by untaring the tarball using:

tar xvfz rgdmc-X.X.X.tar.gz

This will extract the source files into a new folder called rgdmc-X.X.X. In this folderthere are two subfolders, one for compilation on the Neo Freerunner, and one fora regular linux system. Enter the folder which corresponds to the system your areusing and issue the make command.

52

APPENDIX B. USER MANUAL - RG DMC

cd rgdmc-X.X.Xcd Releasemake

This will start the compilation of the source code. When it is done a binary filecalled DigitalMediaController will appear in the directory.

B.3 Starting the Application

The application can be started in one of two modes; Console mode and GUI mode,where console mode is default. To start the application in default mode using thedefault interface on a random port use:

./DigitalMediaController

Start in GUI mode by using the -g flag.

./DigitalMediaController -g

To run on a different interface or port the -i and -p flags can be used, i.e., if wewant to run the application in GUI mode on the interface with the IP address192.168.1.201 and the port 12345 the following flags would be used:

./DigitalMediaController -g -i 192.168.1.201 -p 12345

To get a full list of available flags –-help can be used.

./DigitalMediaController –-help

B.4 Using the Application

The application can be started in one of two modes; Console mode or GUI mode.See Appendix B.3 for information on how to start them. The following sectionswill in short describe the scenario where a user selects a file for playback on a givenDigital Media Renderer, both using the console mode and the GUI mode.

B.4.1 Console View

When the application is started in console mode, see Section B.3, the followingmenu is shown.

53

B.4. USING THE APPLICATION

Using Interface: 192.168.1.203:49152======= RG DMC =======

1. List devices 4. Browser2. M-SEARCH 5. Search3. Control

Selected file:6. Play

0. Quit\ >

Here you are presented with a number of choices. The List devices option will giveyou information about found devices and what services and actions they provide.

The M-SEARCH option will send out an announcement asking devices on thenetwork to notify their existence and then registers them as they respond to theannouncement.

To initiate playback of a media file you will first have to choose a file to be played.This can be done in two different ways. The first way is to use the Browser option.When selected, you first have to pick a server to browse from a list of registeredDigital Media Servers.

\ >4==== Select server ====

1. PS3 Media Server [chiefi-PC]2. CHIEFI-PC: chiefi:3. XBMC Media Server

0. Quit\ >

When a Digital Media Server is selected you can browse through its shared content.The folders are presented with brackets in order to separate them from files. Youcan select a folder for further browsing or pick a file for rendering which will takeyou back to the main menu.

54

APPENDIX B. USER MANUAL - RG DMC

\ >2==== Browsing ====

[1.] Music [10 items][2.] Videos [8 items][3.] Pictures [7 items][4.] Playlists [2 items]5. Johnny Cash - Hurt

0. Go Back\ >5

The second way of choosing a file is to use the Search option where you enter asearch phrase and the application will automatically search through all Digital Me-dia Servers found in the network and present the result which you can then handlejust like if you were in Browser mode.

\ >5==== Search ====

Type in a search phrase

0. Go Back\ >Cash

\ >Cash

Now searching in PS3 Media Server [chiefi-PC]...Now searching in CHIEFI-PC: chiefi:...

==== Result from search ====[1.] Johnny Cash - American I [2 items]2. Johnny Cash - Hurt3. Johnny Cash - Solitary Man

0. Back to main menu\ >2

Once a file has been selected, through either browsing or searching, it will be shownin the main menu under Selected File:. To initiate playback of the selected fileyou use the Play option. When this option is selected you are prompted to selecta Digital Media Renderer. The selected Digital Media Renderer will handle anddisplay the playback.

55

B.4. USING THE APPLICATION

\ >6==== Select Renderer ====

1. XBMC Media Renderer2. gmediarenderer3. Sony Bravida

0. Back to main menu\ >3

Once a Digital Media Renderer has been selected the playback will initiate and youwill enter “play mode” in which you will be prompted with various choices for play-back controlling.

\ >3==== Active file: Johnny Cash - Hurt (STOPPED) ====

1. Play2. Pause3. Stop4. Record5. Forward +20 sec6. Backward -20 sec7. Increase volume8. Decrease volume9. Mute10. Get transport state

0. Back to main menu\ >1

B.4.2 GUI View

When the GUI mode is started the first thing you will see on the screen is the deviceselection frame. In the list at the top you will see registered Digital Media Serversand in the list at the bottom you will see registered Digital Media Renderers. Theselists will be populated when devices announce their existence on the network, whichthey often do for a given time interval. See Figure B.1.

You can also search for them by clicking the Search button at the top leftcorner of the window. This will send out a search on the network telling all devicesto announce their existence. To initiate playback you start by selecting a DigitalMedia Server and a Digital Media Renderer by clicking on their names presented inthe two lists. When a Digital Media Server and a Digital Media Renderer has been

56

APPENDIX B. USER MANUAL - RG DMC

Figure B.1. Device selection window of the application running in GUI mode.

selected the next step, for file selection, is to click the Browse button in the topwhich will open the browse frame.

In the browse frame you are presented with the shared content of the selectedDigital Media Server and are able to browse through it to select a media file forplayback, see Figure B.2. Once a desired file has been found you select it by clicking

Figure B.2. Browse window of the application running in GUI mode.

on it and move on to the next step, playback handling, by clicking on the Controlbutton which will open the control frame.

In this frame you can see which file has been initialized on the Digital MediaRenderer and its associated metadata, see Figure B.3. You will be able to start

57

B.4. USING THE APPLICATION

Figure B.3. Control window of the application running in GUI mode.

the playback by clicking Play and further control the playback by the use of thebuttons Stop, Pause, Record, etc.

58

Bibliography

[1] Allegro Software Development Corporation, "Networked Digital Me-dia Standards, A UPnP / DLNA Overview", 2006

[2] UPnP Forum, "UPnP Device Architecture v1.0", October 2008.http://www.upnp.org

[3] UPnP Forum, "UPnP AV Architecture v1.0", September 2008.http://www.upnp.org

[4] Digital Living Network Alliance, "DLNA Interoperability Guidelinesv1.0", 2004. http://www.dlna.org

[5] Shinji Motegi, Kazuyuki Tasaka, Akira Idoue, Hiroki Horiuchi, "Pro-posal on Wide Area DLNA Communication System", 5th IEEE Con-sumer Communications and Networking Conference. 2008. pp. 233-237.

[6] Narayanan Venkitaraman, "Wide-Area Media Sharing withUPnP/DLNA", 5th IEEE Consumer Communications and Net-working Conference. 2008. pp. 294-298.

[7] Jung-Tae Kim, Yeon-Joo Oh, Hoon-Ki Lee Eui-Hyun Paik andKwang-Roh Park, "Implementation of the DLNA Proxy System forSharing Home Media Contents", IEEE Transactions on ConsumerElectronics. 2007. pp. 139-144.

[8] YoungChul Sohn, Ho Jin, and JongWook Park, "Device Control withScriptable-API Using Web Based Framework", IEEE Transactions onConsumer Electronics. 2008.

[9] Petros Belimpasakis, Vlad Stirbu, "Remote Access to Universal Plugand Play (UPnP) Devices Utilizing the Atom Publishing Protocol",International Conference on Networking and Services (ICNS ’07).2007.

[10] J. Gregorio, et al, "The Atom Publishing Protocol", IETF DRAFT,IETF. December 2006.

59

[11] M. Nottingham, R. Sayre, "The Atom Syndication Format", RFC4287, IETF. December 2005.

[12] Openmoko and the Neo Freerunner. Available:http://wiki.openmoko.org/wiki/Main_Page

[13] DD-WRT. Linux based OpenSource firmware. Available:http://www.dd-wrt.com/dd-wrtv3/index.php

[14] OpenVPN. OpenSource VPN tool. Available:http://www.openvpn.net

[15] Andreas Fasbender, Martin Gerdes, Johan Hjelm, Bo Kvarnström,Justus Petersson and Robert Skog, "Virtually at home: High-performance access to personal media", Ericsson Review No.2. 2008.

[16] Concurrent Versions System, CVS. Available:http://www.nongnu.org/cvs/

[17] "Internet Protocol", RFC 791. September 1981.http://www.faqs.org/rfcs/rfc791.html

[18] "Hypertext Transfer Protocol", RFC 2616. June 1999.http://www.w3.org/Protocols/rfc2616/rfc2616.html

[19] "Real-time Transport Protocol", RFC 3550. July 2003.http://www.ietf.org/rfc/rfc3550.txt

[20] "General Event Notification Architecture", IETF draft, IETF. July1999.http://tools.ietf.org/html/draft-cohen-gena-p-base-01

[21] "Simple Service Discovery Protocol", IETF draft, IETF. February1999.http://ietfreport.isoc.org/all-ids/draft-cai-ssdp-v1-00.txt

[22] "Extensible Markup Language", W3C Recommendation, W3C.November 2008.http://www.w3.org/TR/REC-xml/

[23] "Simple Object Access Protocol", W3C Note, W3C. May 2000.http://www.w3.org/TR/2000/NOTE-SOAP-20000508/

[24] "Security Architecture for the Internet Protocol", RFC 3550, IETF.December 2005.http://tools.ietf.org/html/rfc4301

[25] "Session Initiation Protocol", RFC 3261, IETF. June 2002.http://www.ietf.org/rfc/rfc3261.txt

60

BIBLIOGRAPHY

[26] "Secure Socket Layer", internet-draft, IETF. November 1996.http://www.mozilla.org/projects/security/pki/nss/ssl/draft302.txt

[27] MoCA, The Multimedia over Coax Alliancehttp://www.mocalliance.org/

[28] Linksys WRT54GLhttp://www.linksysbycisco.com/US/en/products/WRT54GL

[29] The OpenSSL Projecthttp://www.openssl.org

[30] Behrouz A. Forouzan, Data Communications and Networking, 3rdedition, McGraw-Hill,ISBN 0-07-251584-8, pp. 873-877.

[31] Intel’s libupnphttp://sourceforge.net/projects/pupnp/

[32] Cyberlink for C++http://sourceforge.net/projects/clinkcc/

[33] GUPnPhttp://www.gupnp.org/

[34] Platinumhttp://sourceforge.net/projects/platinum/

[35] Gtkmm, C++ Interface for Gtk+http://www.gtkmm.org/

[36] Glade Interface Designer, A User Interface Designer for Gtk+http://glade.gnome.org/

[37] RomPlug. Allegro Software Development Corporationhttp://www.allegrosoft.com/romplug.html

61