BT Project Book

Piconet Manager over Bluetooth – Winter 2004 Eran PeriPriscu Robert

Piconet ManagerPiconet Manager over Bluetoothover Bluetooth

Project by:Project by:Peri Eran & Robert PriscuPeri Eran & Robert Priscu

Supervised By:Supervised By:Yoram YihyieYoram Yihyie

1Computer Networks Lab - Technion


Part 1: Introduction........................................................................................................31.1 Complete Bluetooth Overview.............................................................................3

1.1.1 Bluetooth Radio............................................................................................41.1.2 Bluetooth Baseband....................................................................................41.1.3 Host Controller Interface (HCI)....................................................................51.1.4 Logical Link Control and Adaptation Protocol.............................................71.1.5 RFCOMM Protocol.......................................................................................81.1.6 Service Discovery Protocol (SDP)................................................................81.1.7 Bluetooth - Profiles.....................................................................................10

1.2 Hardware and Software overview......................................................................151.2.1 Hardware – Desktop Computer...................................................................151.2.2 Hardware – Handhelds................................................................................151.2.3 Software – Linux.........................................................................................16

Part 2: Our work...........................................................................................................172.1 Our goals:...........................................................................................................17

2.1.1 Our vision....................................................................................................172.1.2 Project goals................................................................................................17

2.2 Previous projects................................................................................................172.2.1 Small overview............................................................................................182.2.2 Their Implementation..................................................................................192.2.3 Experimenting with their system................................................................19

2.3 Looking for a solution – finding a new approach..............................................192.3.1 Step 1 – Upgrading the system....................................................................202.3.2 Step 2 – Installing the BlueZ Bluetooth stack.............................................202.3.3 PAN profile overview.................................................................................212.3.4 Step 3 – PAN: general setup.......................................................................212.3.5 Step 3 – PAN: SDP.....................................................................................242.3.6 Step 3 – PAN: Search Functionality...........................................................242.3.7 Step 3 – PAN: Interfaces.............................................................................252.3.8 Finding a Solution – Take 1: The illusive Bridge.......................................262.3.9 Finding a Solution – Take 2: The routing tables.........................................282.3.10 Operations and problems...........................................................................30

2.4 Conclusion..........................................................................................................302.5 Continuing our work (what’s next?)..................................................................31

Appendix 1 – Installation and Running Guide.............................................................321.1 Installing the Linux OS......................................................................................321.2 Installing needed RPMs.....................................................................................321.3 Running the PAN – Master side.........................................................................331.4 Running the PAN – Slave side...........................................................................341.5 Configuration files.............................................................................................351.6 Useful commands...............................................................................................351.7 Scripts.................................................................................................................36

Appendix 2 – Bibliography (Links).............................................................................38Appendix 3 – System Scheme......................................................................................39



Part 1: Introduction

About this project book: the goal of this book is to help any person that would like to continue our work into various directions to do so as easily as possible. That’s why we decided to split it in to two parts. The first part is completely general and its purpose is to supply the reader with a thorough background about the technology involved and used throughout this project. The second part is the part that specifically describes our work progress, our various successes and difficulties we came across during our work. The "To-Do" list that summarized our work you can find in the Conclusion section (2.4). In the end of the second part you will find a few ideas regarding future directions our work can be used for.

1.1 Complete Bluetooth Overview

What is Bluetooth? Well you can get lots of different definitions, but essentially Bluetooth is the term used to describe the protocol of a short range (10 to 100 meter) frequency-hopping radio link between devices. These devices are then termed Bluetooth - enabled. Documentation on Bluetooth is split into two sections, the Bluetooth Specification and Bluetooth Profiles.

The Specification describes how the technology works (i.e the Bluetooth protocol architecture),

The Profiles describe how the technology is used (i.e how different parts of the specification can be used to fulfil a desired function for a Bluetooth device)

The Specification is examined first, then the Profiles. Bluetooth Specification Protocol Stack:



In more detail: Bluetooth is the name given to a relatively new technology using short-range radio links, intended to replace the cable(s) connecting portable and/or fixed electronic devices. It is envisaged that it will allow for the replacement of the many propriety cables that connect one device to another with one universal radio link. Its key features are robustness, low complexity, low power and low cost. Designed to operate in noisy frequency environments, the Bluetooth radio uses a fast acknowledgement and frequency hopping scheme to make the link robust. Bluetooth radio modules operate in the unlicensed ISM band at 2.4GHz, and avoid interference from other signals by hopping to a new frequency after transmitting or receiving a packet. Compared with other systems in the same frequency band, the Bluetooth radio hops faster and uses shorter packets.

1.1.1 Bluetooth Radio

The Bluetooth Radio (layer) is the lowest defined layer of the Bluetooth specification. It defines the requirements of the Bluetooth transceiver device operating in the 2.4GHz ISM band.Frequency Bands and Channel Arrangement The Bluetooth radio accomplishes spectrum spreading by frequency hopping in 79 hops displaced by 1 MHz, starting at 2.402GHz and finishing at 2.480GHz. In a few countries (i.e. France) this frequency band range is (temporarily) reduced, and a 23-hop system is used. In order to comply with out-of-band regulations in each country. In both systems a guard band is used at the lower and upper band edgeTransmitter CharacteristicsPower Classes: Each device is classified into 3 power classes, Power Class 1, 2 & 3.

Power Class 1: is designed for long range (~100m) devices, with a max output power of 20 dBm,

Power Class 2: for ordinary range devices (~10m) devices, with a max output power of 4 dBm,

Power Class 3: for short-range devices (~10cm) devices, with a max output power of 0 dBm.

The Bluetooth radio interface is based on a nominal antenna power of 0dBm. Each device can optionally vary its transmitted power. Equipment with power control capability optimizes the output power in a link with LMP commands (see Link Manager Protocol). That is done by measuring RSSI and report back if the power should be increased or decreased.

1.1.2 Bluetooth Baseband

The Baseband is the physical layer of the Bluetooth. It manages physical channels and links apart from other services like error correction, data whitening, hop selection and Bluetooth security. The Baseband layer lies on top of the Bluetooth radio layer in the Bluetooth stack. The baseband protocol is implemented as a Link Controller, which works with the link manager for carrying out link level routines like link connection and power control. The baseband also manages asynchronous and synchronous links, handles packets and does paging and inquiry to access and inquire Bluetooth devices in the area. The baseband transceiver applies a time-division duplex


http://www.palowireless.com/infotooth/tutorial/radio.asp

http://www.palowireless.com/infotooth/tutorial/radio.asp

http://www.palowireless.com/infotooth/glossary.asp#Frequency%20Hopping


(TDD) scheme (alternate transmit and receive). Therefore apart from different hopping frequency (frequency division), the time is also slotted.

Physical Channel Bluetooth operates in the 2.4 GHz ISM band. In the US and Europe, a band of 83.5 MHz width is available; in this band, 79 RF channels spaced 1 MHz apart are defined. In France, a smaller band is available; in this band, 23 RF channels spaced 1 MHz apart are defined. The channel is represented by a pseudo-random hopping sequence hopping through the 79 or 23 RF channels. Two or more Bluetooth devices using the same channel form a piconet. There is one master and one or more slave(s) in each piconet. The hopping sequence is unique for the piconet and is determined by the Bluetooth device address (BD_ADDR) of the master; the phase in the hopping sequence is determined by the Bluetooth clock of the master. The channel is divided into time slots where each slot corresponds to an RF hop frequency. Consecutive hops correspond to different RF hop frequencies.

*Diagram Source: Courtesy of Bluetooth SIG, Baseband Spec, Figure 1.2 , p 42

1.1.3 Host Controller Interface (HCI)

The HCI provides a command interface to the baseband controller and link manager, and access to hardware status and control registers. Essentially this interface provides a uniform method of accessing the Bluetooth baseband capabilities.The HCI exists across 3 sections, the Host - Transport Layer - Host Controller. Each of the sections has a different role to play in the HCI system.



HCI Functional Entities The HCI is functionally broken up into 3 separate parts:

*Diagram Source: Courtesy of Bluetooth SIG, HCI Specs, Fig 1.2 , p 544

HCI Firmware (location: Host Controller)HCI Firmware, is located on the Host Controller, (e.g. the actual Bluetooth hardware device). The HCI firmware implements the HCI Commands for the Bluetooth hardware by accessing baseband commands, link manager commands, hardware status registers, control registers, and event registers. The term Host Controller means the HCI-enabled Bluetooth device

HCI Driver (location: Host)HCI Driver, which is located on the Host (e.g. software entity). The Host will receive asynchronous notifications of HCI events, HCI events are used for notifying the Host when something occurs. When the Host discovers that an event has occurred it will then parse the received event packet to determine which event occurred. The term Host means the HCI-enabled Software Unit. Host Controller Transport Layer (location: Intermediate Layers)The HCI Driver and Firmware communicate via the Host Controller Transport Layer, i.e. a definition of the several layers that may exist between the HCI driver on the host system and the HCI firmware in the Bluetooth hardware. These intermediate layers, the Host Controller Transport Layer, should provide the ability to transfer data without intimate knowledge of the data being transferred. Several different Host Controller Layers can be used, of which 3 have been defined initially for Bluetooth: USB, UART and RS232. The Host should receive asynchronous notifications of HCI events independent of which Host Controller Transport Layer is used.


http://www.palowireless.com/infotooth/glossary.asp#baseband


1.1.4 Logical Link Control and Adaptation Protocol

The Logical Link Control and Adaptation Layer Protocol (L2CAP) is layered over the Baseband Protocol and resides in the data link layer. L2CAP provides connection-oriented and connectionless data services to upper layer protocols with protocol multiplexing capability, segmentation and reassembly operation, and group abstractions. L2CAP permits higher level protocols and applications to transmit and receive L2CAP data packets up to 64 kilobytes in length. Two link types are supported for the Baseband layer: Synchronous Connection-Oriented (SCO) links and Asynchronous Connection-Less (ACL) links. SCO links support real-time voice traffic using reserved bandwidth. ACL links support best effort traffic. The L2CAP Specification is defined for only ACL links and no support for SCO links is planned.

L2CAP State Machine This section describes the L2CAP connection-oriented channel state machine. The section defines the states, the events causing state transitions, and the actions to be performed in response to events. This state machine is only pertinent to bi-directional CIDs and is not representative of the signaling channel or the uni-directional channel.

*Diagram Source: Courtesy of Bluetooth SIG, L2CAP Specs, Fig 3.1 , p 258

The figure* above illustrates the events and actions performed by an implementation of the L2CAP layer. Client and Server simply represent the initiator of the request and the acceptor of the request respectively. An application-level Client would both initiate and accept requests. The naming convention is as follows.

The interface between two layers (vertical interface) uses the prefix of the lower layer offering the service to the higher layer, e.g., L2CA.

The interface between two entities of the same layer (horizontal interface) uses the prefix of the protocol (adding a P to the layer identification), e.g., L2CAP.

Events coming from above (starting above) are called Requests (Req) and the corresponding replies are called Confirms (Cfm).

Events coming from below (starting below) are called Indications (Ind) and the corresponding replies are called Responses (Rsp).

Responses requiring further processing are called Pending (Pnd). The notation for Confirms and Responses assumes positive replies. Negative replies are denoted by a ’Neg’ suffix such as L2CAP_ConnectCfmNeg.



1.1.5 RFCOMM Protocol

The RFCOMM protocol provides emulation of serial ports over the L2CAP protocol. The protocol is based on the ETSI standard TS 07.10. Only a subset of the TS 07.10 standard is used, and some adaptations of the protocol are specified in the Bluetooth RFCOMM specification.

RFCOMM Overview/Service RFCOMM is a simple transport protocol, which provides emulation of RS232 serial ports over the L2CAP protocol. The protocol is based on the ETSI standard TS 07.10. Only a subset of the TS 07.10 standard is used and an RFCOMM - specific extension is added, in the form of a mandatory credit based flow control scheme. The RFCOMM protocol supports up to 60 simultaneous connections between two BT devices. The number of connections that can be used simultaneously in a BT device is implementation-specific. For the purposes of RFCOMM, a complete communication path involves two applications running on different devices (the communication endpoints) with a communication segment between them.other, the DLCI value space is divided between the two communicating devices using the concept of RFCOMM server channels. If a BT device supports multiple emulated serial ports and the connections are allowed to have endpoints in different BT devices, then the RFCOMM entity must be able to run multiple TS 07.10 multiplexer sessions. Note that each multiplexer session is using its own L2CAP channel ID (CID). The ability to run multiple sessions of the TS 07.10 multiplexer is optional for RFCOMM.

1.1.6 Service Discovery Protocol (SDP)

The service discovery protocol (SDP) provides a means for applications to discover which services are available and to determine the characteristics of those available services. A specific Service Discovery protocol is needed in the Bluetooth environment, as the set of services that are available changes dynamically based on the RF proximity of devices in motion, qualitatively different from service discovery in traditional network-based environments. The service discovery protocol defined in the Bluetooth specification is intended to address the unique characteristics of the Bluetooth environment.

SDP Protocol overview SDP is a simple protocol with minimal requirements on the underlying transport. It can function over a reliable packet transport (or even unreliable, if the client implements timeouts and repeats requests as necessary). SDP uses a request/response model where each transaction consists of one request protocol data unit (PDU) and one response PDU. However, the requests may potentially be pipelined and responses may potentially be returned out of order. SDP uses a request/response model where each transaction consists of one request protocol data unit (PDU) and one response PDU. In the case where SDP is used with the Bluetooth L2CAP transport protocol, only one SDP request PDU per connection to a given SDP server may be outstanding at a given instant. In other words, a client


http://www.palowireless.com/infotooth/glossary.asp#SDP

http://www.palowireless.com/infotooth/glossary.asp#L2CAP

http://www.palowireless.com/infotooth/tutorial/l2cap.asp

http://www.palowireless.com/infotooth/tutorial/l2cap.asp


must receive a response to each request before issuing another request on the same L2CAP connection. Limiting SDP to sending one unacknowledged request PDU provides a simple form of flow control.

*Diagram Source: Courtesy of Bluetooth SIG, SDP Specs, Fig 2.1, p 330

SDP Services The following section, describe how the individual characteristics (services) of the different devices are stored.

Service Discovery The whole point of the SDP is to allow Bluetooth devices to discover what other Bluetooth devices can offer (what services). SDP allows this in various means. Searching means looking for specific service, while Browsing means looking to see what services are actually being offered.

Searching for Services The Service Search transaction allows a client to retrieve the service record handles for particular service records based on the values of attributes contained within those service records. The capability search for service records based on the values of arbitrary attributes is not provided. Rather, the capability is provided to search only for attributes whose values are Universally Unique Identifiers (UUIDs). Important attributes of services that can be used to search for a service are represented as UUIDs. Service search pattern are used to locate the desired service. A service search pattern is a list of UUIDs (service attributes) used to locate matching service records.

Browsing for Services This process of looking for any offered services is termed browsing. In SDP, the mechanism for browsing for services is based on an attribute shared by all service classes. This attribute is called the BrowseGroupList attribute. The value of this attribute contains a list of UUIDs. Each UUID represents a browse group with which a service may be associated for the purpose of browsing. When a client desires to browse an SDP server’s services, it creates a service search pattern containing the UUID that represents the root browse group. All services that



may be browsed at the top level are made members of the root browse group by having the root browse group’s UUID as a value within the BrowseGroupList attribute.

1.1.7 Bluetooth - Profiles

The profiles have been developed in order to describe how implementations of user models are to be accomplished. The user models describe a number of user scenarios where Bluetooth performs the radio transmission. A profile can be described as a vertical slice through the protocol stack. It defines options in each protocol that are mandatory for the profile. It also defines parameter ranges for each protocol. The profile concept is used to decrease the risk of interoperability problems between different manufacturers' products. Bluetooth Profile Dependencies:

The Bluetooth profile structure and the dependencies of the profiles are depicted above. A profile is dependent upon another profile if it re-uses parts of that profile, by implicitly or explicitly referencing it. Dependency is illustrated in the figure: a profile has dependencies on the profile(s) in which it is contained – directly and indirectly. For example, the Object Push profile is dependent on Generic Object Exchange, Serial Port, and Generic Access profiles.

There are 13 "profiles" described in version 1.1 of the specification. These profiles are general behaviors through which Bluetooth units communicate with other units. The



13 profiles described here constitute the basis for the user models and their profiles. The profiles also provide the foundation for future user models and profiles.

K1: Generic Access Profile (GAP)

GAP defines how two Bluetooth units discover and establish a connection with each other. GAP handles discovery and establishment between units that are unconnected. The profile defines operations that are generic and can be used by profiles referring to GAP and by devices implementing multiple profiles. GAP ensures that any two Bluetooth units, regardless of manufacturer and application, can exchange information via Bluetooth in order to discover what type of applications the units support. Bluetooth units not conforming to any other Bluetooth profile must conform to GAP to ensure basic interoperability and co-existence. It also handles security. The Protocol Stack is illustrated in figure 2:1 below.

Comments to figure 2:1:

The main purpose of this profile is to describe the use of the lower layers of the Bluetooth protocol stack (LC and LMP). To describe security related alternatives, also higher layers (L2CAP, RFCOMM and OBEX) are included.

L2CAP = Logical Link Control and Adaptiation ProtocolLC = Baseband (Link Controller)LMP = Link Manager ProtocolOBEX = Object Exchange ProtocolSDP = Service Discovery ProtocolTCS = Telephony Control Protocol

K2: Service Discovery Application Profile (SDAP)

SDAP defines the investigation of services available to a Bluetooth unit. This profile handles the search for known and specific services as well as a general service search. SDAP involves an application, the Service Discovery User Application, which is required in a Bluetooth unit for locating services. This application interfaces the Service Discovery Protocol that sends and receives service inquiries to and from other Bluetooth units. Hence, SDAP describes an application that interfaces with a specific Bluetooth protocol to take full advantage of it for the direct benefit of the end-user.The SDAP is dependent on the GAP, i.e. SDAP re-uses parts of the GAP. The Protocol Stack is illustrated in figure 2:2 below.




The service discovery user application (SrvDscApp) in a local device (LocDev) interfaces with the Bluetooth SDP client to send service inquiries and receive service inquiry responses from the SDP servers of remote devices (RemDevs). SDP uses the connection-oriented (CO) transport service in L2CAP, which in turn uses the baseband asynchronous connectionless (ACL) links to ultimately carry the SDP PDUs over the air.

Service discovery is tightly related to discovering devices, and discovering devices is tightly related to performing inquiries and pages. Thus, the SrvDscApp interfaces with the baseband via the BT_module_Cntrl entity that instructs the Bluetooth module when to enter various search modes of operation.

K3: Cordless Telephony Profile

Defines how Bluetooth can be used as wireless phone. Also describes how a Bluetooth-adapted cellular phone should switch to Bluetooth wireless phone-function when it comes within reach of a Bluetooth base station.



K4: Intercom Profile

This profile connects with K3. It defines how two Bluetooth-equipped cellular phones in the same network should be able to communicate directly with each other, without using the public telephone network. This function enables for instance interconnecting phones within an office.

K5: Serial Port Profile

The Serial Port Profile defines how to set-up virtual serial ports on two devices and connecting these with Bluetooth. Using this profile provides the Bluetooth units with an emulation of a serial cable using RS232 control signalling (RS232 is a common interface standard for data communications equipment; it is the standard used on the serial port of an ordinary PC). This profile ensures that data rates up to 128 kbit/sec. can be used. The Serial Port Profile is dependent on the GAP, i.e. just as SDAP, Serial Port Profile re-uses parts of the GAP.

K6: Headset Profile

Defines how a Bluetooth-headset should communicate with headsets or computers.

K7: Dial-up Networking Profile

Defines how a modem-connection over the public telephone network can be linked to a Bluetooth-equipped terminal, such as a laptop, Bluetooth-equipped modem or Bluetooth-equipped cellular phone.

K8: Fax Profile

Similar to K7, except that it interfaces a fax. K9: LAN Access Profile

Defines interconnections between Bluetooth-equipped terminals and LANs (and on to Internet). The Bluetooth base station would be connected to the LAN as an ordinary LAN-station, and the transmission would use the PPP (Point-to-Point Protocol). The Protocol Stack and how it interfaces a LAN is illustrated in figure 2:9 below.




PPP is the IETF Point-to-Point Protocol. PPP-Networking is the means of taking IP packets to/from the PPP layer and placing them onto the LAN. This mechanism is not defined by this profile but is a well-understood feature of Remote Access Server products.

The Baseband, LMP and L2CAP are OSI layers 1 and 2 Bluetooth protocols. RFCOMM is the Bluetooth adaptation of GSM TS 07.10.SDP is the Bluetooth Service Discovery Protocol.ME is the Management Entity which coordinates procedures during initialization, configuration and connection management.

K10: Generic Object Exchange Profile (GOEP)

GOEP defines the set of protocols and procedures to be used by applications handling object exchanges. Several usage models are based on this profile, e.g. File Transfer and Synchronization. Typical Bluetooth units using this profile are notebook PCs, PDAs, mobile phones and smart phones.

Applications using the GOEP assume that links and channels are established, as defined by the GAP. The GOEP describes the procedure for pushing data from one Bluetooth unit to another. The profile also describes how to pull data between units. The GOEP is dependent on the Serial Port Profile. The OBEX-standard is used.

K11: Object Push Profile

This profile is used in conjunction with K10 to send and receive small objects. Example would be the exchange of electronic calling cards. K12: File Transfer Profile

This profile is used in conjunction with K10 to transfer files between two Bluetooth units.



K13: Synchronization Profile

This profile is used in conjunction with K10 to enable synchronization of calendar- and address-information between computers.

1.2 Hardware and Software overview

1.2.1 Hardware – Desktop Computer

The desktop computers we used in the Computer Networks Lab were Inter Pentium ™ 4 based running at 2 GHz with 512 MB of ram. All the machines were double boot machines preinstalled with both Windows XP Professional and various versions of the Red Hat Linux Operating System (details below).

1.2.2 Hardware – Handhelds

In our various testing we used a couple of iPAQ's 3870. Those machines feature a StrongArm CPU running at 206 MHz, 64 MB of RAM memory, SD memory expansion slot and built-in Bluetooth transceiver. The iPAQ Pocket PC H3800 is not much bigger than a calculator and comes standard with applications like Microsoft® Pocket Word™, Excel™, Outlook™, Internet Explorer™, and Windows Media™ Player.

This model is equipped with the older Microsoft 2002 Pocket PC Operating System.

In a few of our testing we used the newer iPAQ 4150. This machine is equipped with a newer Intel XScale CPU running at 400 MHz, 64 MB of internal RAM memory, SDIO expansion slot and both Bluetooth and WiFi capability built-in. This Model is also equipped with the newer Microsoft Operating system Windows Mobile 2003, which features an improved Bluetooth Manager.

1.2.3 Software – Linux



All the project is based on linux OS, basically because the facts that many more internals modules are accessible and available to use and to configure. All of the work we did, could not be done on Windows™ OS, because it is “closed” to the user. We needed to be close to the kernel and drivers.

We used several linux editions. We began with the project we were based on – which was running on RedHat 7. One of our goals was to move the project to RedHat 9 because the RedHat 7 was old and the newer versions have better BT support. After some progress in the RedHat 9 machines that was installed in the Lab, we had problems of “freezing” (the computer freezes when we tried to run one of the utils). We believed that the problem was with the relatively old kernel version (2.4.19), so we installed the newest kernel (2.6.4). Some of the problems were solved, but still there were problems with the configuration. Finally, we just installed a new linux box as a whole – Mandrake 10. As the time pass, the new editions of linux have better and better BT support, and we (the BT users) need to do less work to install and operate it. On the linux machines, we used the best available Bluetooth stack that there is (in our opinion) for linux enviorment, the BlueZ, further details in the next section.



Part 2: Our work

2.1 Our goals:

2.1.1 Our vision

Our vision was to set up a communication platform in order to make it possible to control, manipulate and exchange messages between various clients (i.e. PDA's, Laptops, and even computerized robots). We wanted to provide with a smoothly running IP distribution system to various devices (PDA's, Laptops and nearby desktop computers). We wanted to enable internet browsing and messages transfer over Bluetooth wireless communication technology.

2.1.2 Project goals

Originally, we had 4 goals, we present them here with their status:

1. We wanted to set up the project we based on (or at leased, thought we will be based on…), and try to run it on RedHat 9 (instead of RedHat 7). This goal was achieved fully, and the system runs seamlessly, except for two things: 1) it worked only with the previous Bluetooth stack (BlueZ) version (BlueZ utilities 2.2). 2) Despite the statements in the project documentation, we found that the system indeed communicate seamlessly and reliably, but with one device at a time only.

2. Automation of all the resources distribution of the piconet (IP handling, automated login and logoff ect.). This goal was not fully achieved. We have, however, managed to provide with a semi-automated IP distributing system.

3. Build an automated/semi-automated pairing mechanism on a Linux machine. Already implemented in the hardcore of the utility we used (BlueZ-pan).

4. Transferring messages from the Master to the Slave and form Slave to Slave via the Master (Demo) – this goal was not achieved because we had to rebuild the whole network, so this goal got out of our scope.

2.2 Previous projects

In the beginning, before we knew what was ahead of us, we thought that our project will start where the previous project was finished. But as we moved along the road, we saw that the previous project is leading us to a dead end.


http://comnet.technion.ac.il/~cn16s02/


2.2.1 Small overview

Their project objectives were: Design a Bluetooth based Personl Information Kiosk System (PIKS) on a wireless network of PDA’s, and then implement it using Compaq iPaq 3870 with integrated Bluetooth and point to multipoint Bluetooth devices.Implement a PIKS using the BlueZ stack on a PC (with Eriksson's devices) and the iPaqs.Linux based server will use the BlueZ stack to discover clients and communicate.

They've learned the Bluetooth and PIKS theory and experimented with the iPaq 3870 – checking its capabilities. They used a PDA emulator which provided a PALM like environment to the client application. After finishing learning and experimenting with the emulator, they started working with the iPaq PDAs which didn’t support applications they used so far. Seeking a suitable programming environment, they came across the Visual Embedded Tools – which allowed them to develop several applications for iPaq, but it didn’t supply them with a way to use the Bluetooth capabilities of the iPaq. They run some simulations over virtual COM port over RFCOMM, supplied by the iPaq’s Bluetooth Manager.

The end of the first part presented several future goals – there were some issues they couldn’t solve mainly due to difficulties they had. Find a way to overcome the SDP problem between iPaq and Ericsson devices - the iPaq devices couldn’t discover the Ericsson devices.Implement a system based on the principle of service proposals without polling mechanisms, e.g., a client is provided with the information automatically when passing near a PIKS AP. Implement a system based on wireless LAN and compare it with the one implemented with Bluetooth.They came into a crossroad – Find the best way to connect the clients to the Access Point. The Ericsson devices which supported multipoint connections had to communicate with the CSR chips installed in the iPaqs and they didn’t have a suitable stack at hand. At this point they searched for a Bluetooth stack implementation with an open source which will allow them to develop their server application and adapt the stack configuration to fit both hardwares.

The solution was using Bluetooth with the BlueZ stack implementation. The main reason for choosing this technology was that it is more innovative and there are no known implementations of projects of this kind. The disadvantage is that there is no guarantee that it would work: BlueZ is developed as freeware, it has poor documentation and examples.



2.2.2 Their Implementation

Their implementation of BT IP connectivity was by using BlueZ Bluetooth stack on a Linux machine, which will be the access point (LAP), and running PPP over RFCOMM(built in the iPAQ operating system), so by using PPP over RFCOMM they could easily create the connection they wanted. After, they gave IP address by proxyarp which enabled using IP of privet subnetwork (like 10.0.0.x or 192.168.x.x), so there was no using of the LAN native IP addresses.This implementation worked fine, and was suitable for communicating with the iPAQ device. However, RFCOMM is an emulation of the physical serial connection, and not suitable, by nature, for building Private Area Networks that include several devices. Further more, the implementation they used was based on RFCOMMd (RFCOMM deamon) which was incorporatrd into the RFCOMM module, and was no longer available as a stand-alone deamon. All this led to the conclusion that their script was no longer suitable for newer versions of BlueZ.

2.2.3 Experimenting with their system

After setting up the system we began a series of testing on their system. We were successful in connecting the iPAQ 3870 or the other linux machine, but we could not connect them both simultaneously, nor could we connect two iPAQ's (we tried connecting two similar (3870) devices and even tried connecting a 3870 and a 4150 which has a newer OS – Windows mobile 2003) again, with no success, it seemed that the system could not establish more then one IP connection, that point became a clear fact after examining their scripts, in which we found the following line:

ppp "noauth 192.168.0.1:192.168.0.2";

It was not before long that we understood that the single connection problem was in fact a part of their implementation, and there wasn't much we could do about it.

2.3 Looking for a solution – finding a new approach

While we were studding the problem and looking for a way to establish multilink

PPP connection using the basic agenda of our predecessors, we found an article witch explains thoroughly how to implement a PAN (Private Area Network) over BlueZ, implementing this system fitted our project goals nicely. Implementing the new found solution meant, however, to concede the use of the iPAQ, the reason was the iPAQ's Windows OS inability in communicating with the Linux's Bluetooth BlueZ stack, specifically the iPAQ Bluetooth Manager lacked support for the "PAN" profile we needed to implement our solution, we even checked if the Windows Mobile 2003 OS solved this problem with new profiles supported, but it didn't. Although we searched thoroughly for a solution across the web, no solution was found for this problem. We had an idea to install a Linux operating system on the iPAQ, but that was a stand-



alone project, so, finally, we conceded the use of the iPAQ's in our project. We would like to mention, that PAN connection is possible if an iPAQ that is installed with a Linux OS. Lately, such a project was completed in the Network Laboratory at the Technion, and maybe someone will continue our work in that direction.

2.3.1 Step 1 – Upgrading the system

As a basic step in our work, we decided that all work will be done on the latest available Linux Red Hat Version, which at this point, was version 9. We didn't have to install the OS since it was preinstalled on the computers in the Computer Networks Lab.

2.3.2 Step 2 – Installing the BlueZ Bluetooth stack.

BlueZ package can be installed during the installation of latest Linux Versions, coming as a part of the latest Kernels, and linux boxes. You should read the “Installation and running guide" appendix 1. However, the process we went throe was longer…At first, knowing that BlueZ is a part of the newer kernels, we explored installing it with the kernel configuration application. The principle is using:

>> make menuconfig

or >> make xconfig

command in order to choose the specific configuration parameters for each installation. The working directory for this procedure should be the Kernel directory, usually found at "/user/src/linux…". Further information regarding Linux installation configuration and build can be found following this excellent link. As we mentioned before, we worked on an Operating System that was preinstalled so we downloaded and installed the latest BlueZ components from this site. In the beginning we downloaded the zipped source packages, we then unzipped them, complied and installed them. Further information regarding installing the package in this manner can be found here. After running into some installation problems (probably due to compilation errors and installation problems), we abandoned this installation mode for the much quicker, reliable and easier method of installing RPM's. RPM is a powerful command line driven package management system capable of installing, uninstalling, verifying, querying, and updating computer software packages. The command is:

>>rpm –i package_name.rpm

Further information regarding RPM's can be found here.The Relevant packages for the BlueZ Bluetooth stack installation can be found in this page. We recommend the excellent documentation that can be found in the BlueZ web site, detailed information about the various packages and all installation information can be there. Here is the link.


http://www.bluez.org/

http://bluez.sourceforge.net/download/redhat/

http://bluez.sourceforge.net/download/redhat/

http://www.rpm.org/

http://www.grinta.net/howto/bluez-ipaq.html

http://www.bluez.org/

http://www.digitalhermit.com/linux/Kernel-Build-HOWTO.html#CONFIGURATION


At this point we began experimenting with the previous system. At first, our goal was to make it run on RedHat 9. We thought that newer BlueZ components will provide us with better performance and reliability. Not only that the newer versions didn't provided better performance and reliability, the system did not even run on the upgraded system… after a few more hours of testing, playing with every possible parameter and reading lots of documentation from various sources, we came to the conclusion that the reason that the system didn't work is the fact that the BlueZ developers dropped the RFCOMMd from the newer version and incorporated it into the system, so the script we had could no longer run on the upgraded system. It was during the quest for a solution for these problems it was when we found a much better solution for implementing our project goal. The new method, which seemed perfect for our goals, was to build a Private Area Network using the BlueZ PAN Bluetooth profile rather then the PPP over an emulated serial port used by the previous implementation. The PAN solution provides us with a much more intuitive implementation of a network, and seems to fit our goals perfectly.

2.3.3 PAN profile overview

The Bluetooth PAN feature offers (amongst other features) IP support over Bluetooth (i.e. L2CAP), comparable to Wireless LAN on a PC more or less.Participants in a BlueZ PAN can take on the following roles:

PAN user (PANU): Client of a NAP or client-type member of a GN Group ad-hoc Network (GN) controller:

-Forwarding node in a peer-to-peer style network (Bluetooth Piconet). -Interconnects up to 7 (active) PANUs to a real peer-to-peer network.

- Network Access Point (NAP):Acts as proxy, router or bridge between an existing network infrastructure (typically LAN) and (up to 7 active) wireless clients (PANUs).

2.3.4 Step 3 – PAN: general setup


WAN

Lan interface

NAP

Panu Panu Panu Panu

WAN WAN – Wide Area Network.– Wide Area Network. LANLAN – Local Area Network. – Local Area Network. NAPNAP – Network access point. – Network access point. PANPAN - - Personal Area NetworkPersonal Area Network PANUPANU – Personal Area Network – Personal Area Network Unit.Unit.

SLAVESSLAVES

MASTERMASTER


To make use of the PAN functionality of BlueZ, it is necessary to install or build the following BlueZ packages: "BlueZ-Kernel 2.3", "BlueZ-Libs 2.5", "Bluez-Utils 2.4", "BlueZ-SDP 1.5" and "BlueZ-PAN 1.1rc2" (These are the versions we used, you should use any of the respective follow-up packages). To build BlueZ packages in general, please refer to the README files of the individual packages, anyway refer to the "Installation and running guide" appendix1. Be careful if you encounter the README and INSTALL files from BlueZ-PAN 1.0. They refer to an outdated version of PAN ("BlueNIC"), hence don't apply anymore.

Notice – (only if you use an old installed linux box)In older linuxs you may have to add this lines to /etc/modules.conf (if I remember right, in kernel 2.6.X and newer it should be added to modprobe.conf):

alias net-pf-31 bluezalias bt-proto-0 l2capalias bt-proto-2 scoalias bt-proto-4 bnepalias tty-ldisc-15 hci_uartalias bt-proto-3 rfcomm

and if you want you can set up a PAN node now, but you have to load the module bnep.o first:

> modprobe bnep

still, to avoid problems, REBOOT NOW.

Once everything is built successfully (please refer to “Installation and running guide" – appendix 1, and section 2.3.2 regarding specific installation instructions), make sure that the HCI daemon ('hcid') is running (Below) and the respective BlueZ device is "up" (i.e., 'hciconfig' shows you device number, address etc. of the respective device).

In order to verify the right working of the Bluetooth hardware we will use the hciconfig utility. This small utility does what ifconfig does for Ethernet devices and what iwconfig does for wireless devices. The command to use to see if our Bluetooth devise is active is:

> hciconfig

A list of all initialized devices must be returned. Something like:

hci0: Type: USB BD Address: 00:03:C9:23:04:23 ACL MTU: 377:10 SCO MTU: 16:0 UP RUNNING PSCAN ISCAN RX bytes:69 acl:0 sco:0 events:8 errors:0 TX bytes:30 acl:0 sco:0 commands:8 errors:0

It is possible that the default state for your hardware will not be "UP RUNNING" but "DOWN" in this case you must activate it with:



> hciconfig hci0 up

Important: after numerous slow, multi-command startups, we discovered that there is one wonderful command that starts all the Bluetooth devices after start-up, here it is:

> service Bluetooth start

respectively, you can use:

> service Bluetooth stop

in order to stop the service, and:

> service Bluetooth restart

in order to restart the service.

Now (after you activated the Bluetooth) you have to start the PAN daemon process ('pand') on one node. The idea behind 'pand' is that you start it on one side in a server (daemon) fashion, using the '--listen' parameter.

> pand --listen --role <PANU | GN | NAP>

Note that on the GN and NAP side, the BlueZ device has to be able to act as Bluetooth master. Therefore, the master/slave switch has to be enabled in the BlueZ configuration file '/etc/bluetooth/hcid.conf':

> lm accept, master

(You have to uncomment this in the default version of'/etc/bluetooth/hcid.conf'.)Alternatively, you can make a BlueZ PAN node BT master with:

# pand --master

Now you can establish an explicit connection between PANU and GN or NAP, respectively, from the other node:

# pand --connect <destination BT device address>

Here's an example:

To connect a PANU node (00:37:5C:67:D3:01) with a GN (00:37:5C:67:D3:02), BlueZ must be operational on both sides. The GN must be able to run as Bluetooth master (see above).

> pand --listen --role GN

on the GN side. After that, you you can connect from the PANU side:



> pand --connect 00:37:5C:67:D3:02

In case of problems, the system log files under /var/log/ (i.e. 'messages' and 'warn') may give you further information about the cause of failure.

Note that it is a good idea to start 'pand' as server on the GN (or NAP, respectively) rather than the PANU, since then you have a consistent access scheme from any possible PANU. When you do so, 'pand' permanently listens for connection attempts from other nodes, thus becomes resident. In case you have only one PANU, however, you may also swap roles and start 'pand' as server (i.e. using the '--listen' parameter) on the PANU side, and connect from the GN (or NAP) side.

2.3.5 Step 3 – PAN: SDP

Optionally, the Bluetooth 'Service Discovery Protocol' (SDP, see [2]) may be used within 'pand' to register GN or NAP as SDP-searchable services. To use SDP, make sure that the SDP daemon ('sdpd') is running. SDP is activated with 'pand' when 'pand' is started as GN or NAP:

> pand --listen --role <GN | NAP> --sdp

In this case, an explicit connection between PANU and GN or NAP, respectively, is established as follows:

> pand --connect <destination BT device address> --service <GN | NAP>

with GN/NAP being the desired service at the destination host. Again, the connection may also be established from the NAP/GN side, so that roles are swapped.

2.3.6 Step 3 – PAN: Search Functionality

To make life easier in case you don't know the device address of your desired communication partner, the optional parameter '--search' allows you to search for PAN communication partners, e.g.:

> pand --role PANU --search [duration]

performs Bluetooth inquiry for PAN devices in the vicinity and tries to connect to any discovered device. The search continues for no longer than 'duration' units of 1.28 seconds.

Using SDP, the search can pe performed selectively. E.g.:

> pand --role PANU --search --service NAP --sdp

will search and connect to NAP nodes only.

In case of problems, you can find the results of 'pand's search results in '/var/log/messages'. You may also want to double-check the expected search results



with 'hcitool scan'. Tip: you can open the '/var/log/messages' in a different terminal window and keep it on your desktop when monitoring connectivity activity.

2.3.7 Step 3 – PAN: Interfaces

During connection establishment (this may take a few seconds), a virtual network interface 'bnep0' is created on both nodes. This interface can be configured (just like every other regular network interface) using 'ifconfig'.

E.g.:

> ifconfig bnep0 10.0.0.1

on the GN, and

> ifconfig bnep0 10.0.0.2

on the PANU creates a private IP network in the 10.x.x.x address range. Now it should be possible that the nodes ping each other.At this point a major goal is achieved, because the meaning is that we have build an IP network over Bluetooth, which was our greatest goal since the previous implementation didn't work on the upgraded system. Further more, this network can now hold more then one IP connection each with its individual IP address.

Normally, however, it is not necessary to configure 'bnep0' manually. The Linux "hotplug" mechanism that claims responsible for IP address assignment (static address or DHCP) for classic Ethernet adapters can do the same job for our PAN as well. Therefore, it is necessary to place a config file named'ifcfg-bnep0' in /etc/sysconfig/network-scripts/ (reportedly for Redhat).

For static addresses, 'ifcfg-bnep0' could look like follows:DEVICE=bnep0BOOTPROTO=staticIPADDR=10.0.0.1NETMASK=255.0.0.0ONBOOT=no

For DHCP, 'ifcfg-bnep0' could look like follows:

DEVICE=bnep0BOOTPROTO=DHCPONBOOT=no

For other distributions as well as further configuration details do a 'man hotplug' and/or 'man ifup'. In case of problems, also check the system log files.

The file 'ifcfg-bnep0' itself is processed whenever 'bnep0' is created. The 'bnepX' network interfaces ('bnep0' is the first of them) are created (and deleted) in a fully



dynamic way, i.e. one interface is created per PAN connection, named 'bnep0', 'bnep1' etc.

At this point, we have a Bluetooth connection active between too computers, we have IP address and ping capabilities, now what?Now we wanted to connect one of the computers to the Ethernet via the Bluetooth connection, that is, one machine is connected to the Ethernet and has an active Bluetooth connection; the other machine can browse the Internet through the first computer using its Ethernet connection. Basically, we needed to install a bridge on the master computer (the one with both Ethernet and Bluetooth capabilities) that will connect between the eth0 and the bnepX interfaces.

2.3.8 Finding a Solution – Take 1: The illusive Bridge

This was one of the most time consuming and frustrating parts of our project. For the reasons mentioned before, we began installing the bridge according to a reference we found on the net.

Well, this is where "802.1d Ethernet Bridging" came into play."802.1d Ethernet Bridging" is a component of the 2.4.x (or newer) Linux kernel. The initial idea of this feature is to tie separate layer 2 networks together into one new network. For BlueZ PANs, however, we "only" make use of its ability to combine separate network interfaces into a (one) new one.

When having an already installed Linux, in order to activate "802.1d Ethernet Bridging", make sure that it is actually built:

> make menuconfig

Select "Networking options" "802.1d Ethernet Bridging" (as part of the kernel or compiled as a module). If you had to change the setting in this dialog, don't forget to subsequently call

> make modules> make modules_install

to really build the new kernel modules. Reboot.

Note that this process is not needed when installing a new version Linux, refer to the appendix1 – Installation and running. We had a pervious installed machine so we did all this kernel compilation process.

The bridge kernel module, however, requires an additional control SW package, called "bridge utils", which most likely is not part of your Linux distribution. If not, you can download it from http://bridge.sf.net, or look for an RMP file for your distribution. With most distributions, the binary RPM should install. If not, you may want to download the "bridge utils" source package and build it.


http://bridge.sf.net/


Finally you should have a working 'brctl' program. To create a PAN bridge on the GN, enter:

> brctl addbr pan0> ifconfig pan0 10.0.0.1

The 'pan0' interface now is the unique interface to proxy any subsequently created 'bnepX' interface. In case you are not going to connect complex layer 2 networks, where loops could occur, you should now also disable some of the smarter features of "802.1d Ethernet Bridging" (namely the "Spanning Tree Protocol" - STP and the "Listening and Learning States") by typing:

> brctl setfd pan0 0> brctl stp pan0 disable

As a result, the bridge will be functional instantly after a new 'bnepX' interface has been created. If you don't make these calls, bridge establishment may take up to ~ 30 seconds (depending on the complexity of the bridged networks).Normally (unless you connect your PAN to a complex network) you should make these 2 calls.

In order to check the current status of the bridge, you may call:

> brctl show

Which gives you a list of affected interfaces, and

> brctl showmacs

to give you a list of connections (per interface) forwarded over the bridge so far.

In case you want to create a NAP, simply add the interface of the"infrastructure" network (typically 'eth0') to the bridge:

> brctl addif pan0 eth0

Once the bridge port 'bnep0' (or any further port 'bnepX') has been created on the GN, just add it:

> brctl addif pan0 bnep0> ifconfig bnep0 0.0.0.0

Here is where our problems began. Time after time our computer froze, that is stuck, after typing the last 'brctl' command. We tried switching to a different computer, but it didn't help, we also found another reference as to how to install the bridge, but it also froze our system at some point. We tried to find other versions, both newer and older for out bridge, but every option we came up with just didn't seem to work. After many hours and endless attempts we decided to make one more effort and upgrade the Linux Kernel to the newest available version, in hope that it will solve our problem. After a long and frustrating procedure that included a lot of migration work, we had a running 2.6.4 Kernel on one of the Linux machine, however, it didn't work seamlessly. We had some unexplained problems with various network interfaces and ip table. After a conversation with our supervisor, we gave up the bridge and began



working on a simpler solution: managing the routing table in order to achieve the same effect we wanted to achieve from the bridge.

It was only towards the end of our project that a break trough was found. After examining various installation parameters and enabling a few more systems, finally, it worked. Here is the list of the services that must be enabled on the Linux kernel:

Hotplugin USB IPTables 802.1d Ethernet Bridging NAT filtering IP forwording

For Further Information regarding various Linux Kernel configurations follow this link. If you encounter problems, study those setting well, because we got stuck a lot on this point.

2.3.9 Finding a Solution – Take 2: The routing tables

Here is the main idea: change (manually) the machines routing table in order to direct the packages to and from the correct machine. After configuring the 'bnepX' network interfaces on the different machines, we have established a private network over the 10.0.0.x IP address range.In order to view the current routing settings you use the route command:>route

This should give an output that looks like this:

Kernel IP routing tableDestination Gateway Genmask Flags Metric Ref Use Iface132.68.52.0 * 255.255.255.0 U 0 0 0 eth0169.254.0.0 * 255.255.0.0 U 0 0 0 eth0127.0.0.0 * 255.0.0.0 U 0 0 0 lodefault 132.68.52.254 0.0.0.0 UG 0 0 0 eth0


http://www.digitalhermit.com/linux/Kernel-Build-HOWTO.html



Here is a scheme:

In order to establish an Internet gateway we need to configure a few additional things: first we have to set up a Network Address Translation (NAT) for all the packages leaving eth0 on the master Linux machine. The NAT masquerading replace the local 10.0.0.X addresses when a package go out, to the master’s eth0 IP address. When a package come in the eth0 of the master, and is directed to one of the slave there will be translation in the second direction. Activating NAT masquerading, with the following command:

>iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

now we need to enable IP forwarding on the master:

>echo 1 > /proc/sys/net/ipv4/ip_forward

That's it, now the master is configured to act as a NAT for the private network we established. On the client side (slaves) we have to delete the default gateway (if defined – you can check it with the route command), the command is:

>route del default

and now set up the new default gateway route as follows:

>route add default gw 10.0.0.1

and that's it! Now we have an operating Private Area Network with individual IP addresses over the Bluetooth infrastructure.


10.0.0.110.0.0.2

10.0.0.3

10.0.0.4

Master

Slave

Slave

Slave


Here is a scheme of the full system:

2.3.10 Operations and problems

When we first built the system, it worked seamlessly allowing us to browse the net from our new slave, but when we booted the system we saw that we can not browse anymore. After some testing we came to the conclusion that we don't have access to a DNS (Domain Name Server), so the address we type can't find the proper IP address. After some more configurations we managed to build the bridge and overcame this problem. When working with the bridge, the NAT masquerading works fine, and DNS requests are passing o.k.Even when working with the bridge solution, things are sometimes getting stucked. Apparently there are many things that should be improved before we can say that the system run seamlessly, but it do work. We surfed the internet on the slave with no Ethernet connection (only BT).Other Problems comes when trying to contact more than one slave to the master. From unknown reason, many times, the second slave tries to contact the first slave, but not the master. Sometimes it takes a lot of time till the second slave find the master. This point should be checked more deeply.

2.4 Conclusion

The subject of Bluetooth support in the Linux environment is still far from perfection, during our work we came across many incompatibility and lack of support for various


10.0.0.110.0.0.2

10.0.0.3

10.0.0.4

Master

Slave

Slave

Slave

External Lan gateway - 132.68.52.59


versions of some component or another issues. It is evident that this technology is still in its early stages of adoption in the Linux environment. Although a lot of material can be found on the web, there is no centralized authority that can standardize and give coherent documentation and support for Bluetooth.Even when working by the book, there are a lot of things that don't work as they should or don’t work seamlessly, for example: the Bluetooth modules that we used had to be hard rested after every connection loss cause otherwise the connection could not be reestablished, in outer cases we experienced spontaneous connection loss without any reason. Is spite all of the above, our conclusion is that creating an IP network using Bluetooth piconet is possible and feasible with today's means although we think it will not operate seamlessly. It is in our opinion that a Bluetooth based network will not have any advantages over the very common and fast developing wireless networks based on the "WiFi" standard. Bluetooth networks can't compete with either the speed or the range of these networks. This does not mean that there is no use for such a network, in some places, a Bluetooth based network will have advantages over WiFi, for example: in an environment already equipped with Bluetooth devises it could save the cost of deploying a second wireless network. Another example: it is possible to transform information based on IP between devices that are equipped with a Bluetooth transceiver but not with WiFi like some phones or PDA's. We have learned a grate deal about the new and fascinating Bluetooth technology and various aspects of the Linux OS through this project.

2.5 Continuing our work (what’s next?)

We strongly encourage other teams to continue our work and make the system more stable, developing various applications over our platform, connecting various devices to the piconet (other then Linux machines that is). We saw that one of the recent project in the network lab was to set up a Linux OS on a IPAQ PDA, we feel that is only natural to experiment on connecting the PDA to a PC using our platform.Another possibility is to develop a client-server application over IP for controlling robots for example, or give some peripherals control over the web. We are convinced that the lab staff will find endless possibilities to continue our work.



Appendix 1 – Installation and Running Guide

In this appendix we will describe the process of installing, and running a personal area network (PAN), for Linux machines, as we have done in our project.

1.1 Installing the Linux OS.

In the final stage, we installed the Mandrake 10 Linux OS, as one of the new available Linux packages.During the installation you should pay attention and choose some packages that are needed for the PAN. Some of those packages may be chosen during the Linux installation – depended on the Linux vendor you choose. Here is the list:

BlueZ Network (install your Linux as a network client) Hotplugin USB IP Tables 802.1d Ethernet Bridging NAT filtering IP forwording

Note that many of those packages will be installed anyway (with the general installation) and shouldn't be specially marked.

1.2 Installing needed RPMs.

After installing the Linux OS, there are still packages that may be needed to be downloaded and installed. After installing Mandrake 10, we found that we should install:

BlueZ latest version RPMs ( http://bluez.sourceforge.net/download/redhat ) Mandrake Bridge Utils. (search in the internet – for eample:

http://rpm.pbone.net/index.php3/stat/4/idpl/1393695/com/bridge-utils-0.9.7-2mdk.i586.rpm.html)

bluez-bluefw-1.0-1.i386.rpmbluez-hcidump-1.9-1.i386.rpmbluez-libs-2.8-1.i386.rpmbluez-pan-1.1rc2-1.i386.rpmbluez-sdp-1.5-1.i386.rpmbluez-utils-2.8-1.i386.rpmbridge-utils-0.9.6-2mdk.i586.rpm

For installing the rpm use command (from the library they are in):

>su (in order to login as root – if you have insufficient privileges)>rpm –Uvh *.rpm

or:


http://rpm.pbone.net/index.php3/stat/4/idpl/1393695/com/bridge-utils-0.9.7-2mdk.i586.rpm.html

http://rpm.pbone.net/index.php3/stat/4/idpl/1393695/com/bridge-utils-0.9.7-2mdk.i586.rpm.html

http://bluez.sourceforge.net/download/redhat


>rpm –Uvh --force --replacefiles *.rpm see the note.

Note that there may be files that exists in more than one RPM in that case use the --force option and --replacefiles option, or search help about using RPM (for example: man rpm).

Now we are ready to operate the system (this will be a good time to reboot – just in case…)!

1.3 Running The PAN – Master side.

Now we will activate the BlueZ stack and PAN util.

>su (in order to login as root – if you have insufficient privileges)>xterm -e tail -f /var/log/messages&

This command will open a new terminal with the log shown, it is very helpful, and you can see all the progress of running.

Now, start Bluetooth services (look at the log and see BT getting up…):

>service bluetooth start>pand --role NAP --listen

In this stage the master can get bnepX connections. For bridge construction:

>brctl addbr pan0>ifconfig pan0 10.0.0.1>brctl setfd pan0 0>brctl stp pan0 disable

We created Pan0 Bridge with IP 10.0.0.1, Now we will add eth0 to the bridge:

>brctl addif pan0 eth0

Important note – in this stage it is very advised to check if the communication with outer world is o.k – try ping to an outer computer (for example ping t2.technion.ac.il), many times after adding eth0 to the bridge – communication stops. The solution is to delete and add eth0 again by delif/addif subcommands:>brctl delif pan0 eth0>brctl addif pan0 eth0

until the connection is o.k. It is advised to wait a few seconds after adding and before checking the communication.

Now we need to activate NAT masquerading and IP forwarding by:

>echo "1" > /proc/sys/net/ipv4/ip_forward>iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE



In this stage the master is ready for slave's connections as a gateway to the outer world too.When such a connection is coming, bnep0 (or bnep1 for second etc.) interface is showing up. You can see it in the log terminal, or by using ifconfig command. Now, we want to add bnepX (replace X with the number) to the bridge:

>ifconfig bnepX 0.0.0.0>brctl addif pan0 bnepX

Important note – in this stage it is very advised to check if the communication with outer world is o.k – try ping to an outer computer (for example ping t2.technion.ac.il), many times after adding components to the bridge – communication stops. The solution is to del and add bnepX/eth0 again by delif/addif subcommands – till the connection is o.k.

In this stage the slave can communicate, throe the master as a gateway, in the piconet or to the outer world.

1.4 Running the PAN – Slave side.

As in the master, we will activate the BlueZ stack and PAN util.

>su -> for login as root – if you have insufficient privileges>xterm -e tail -f /var/log/messages&

This command will open a new terminal with the log shown, it is very helpful, and you can see all the progress of running.

Now, start Bluetooth services (look at the log and see BT getting up…):

>service bluetooth start

This time, the pan demon operation is as PANU – pan user.

>pand --role PANU –search –persist

In order to make all the ip transformation from the slave machin to the outer world (internet for example) we should change routing definitions, and make our 10.0.0.1 master to be the default gateway:

>route del default>route add default gw 10.0.0.1

Now, When a bnep0 connection will be created we need to assign it an appropriate IP address in our network 10.0.0.X, by:

>ifconfig bnep0 10.0.0.X

(X should be replaced by a different number for each slave – starting with 2 because 10.0.0.1 is the master)



In this stage the slave can communicate, throe the master as a gateway, in the piconet or to the outer world.

1.5 Configuration files

In order to make the process easier we can use network configuration files. Both in the master, and in each slave, it can save us the need to do the ifconfig bnepX 10.0.0.x assignment.The Linux "hotplug" mechanism that claims responsible for IP address assignment (static address or DHCP) for classic Ethernet adapters can do the same job for our PAN as well. Therefore, it is necessary to place a config file named'ifcfg-bnep0' in: /etc/sysconfig/network-scripts/

For static addresses, 'ifcfg-bnep0' could look like follows:

DEVICE=bnep0BOOTPROTO=staticIPADDR=10.0.0.X -> replace X with a numberNETMASK=255.0.0.0ONBOOT=no

Another option is to use DHCP which is an automated IP addresses assignment mechanism. This way, you don't need to manage who will be 10.0.0.2, 10.0.0.3,… and every slave will get it's IP from the master as a DHCP server. Note that we didn't installed DHCP, because we didn't have time for this improvement. However, the idea, is to install DHCP server package in the master, and configure it properly.

For DHCP, 'ifcfg-bnep0' could look like follows:

DEVICE=bnep0BOOTPROTO=DHCPONBOOT=no

Note that in the master (both if using DHCP or not using it) you need an 'ifcfg-bnepX' file for every connections, that’s mean that you need up to 7 files. However, if you don't expect more then 2 connections (in a current time) you need only 2 files.

1.6 Useful commands

This is a list of interesting useful commands, with no detailed information. For further detailed information use the man command, or write the command with --help (for example: >ifconfig --help) . You can always find help in the internet too…

service service_name [start, stop, restart] -> for services like Bluetoothhcid -> run hci demon pand -> run pan demonhciconfig -> configuring hci devices



hcitool -> tools for using hci brctl -> bridges control commands

modprobe -> tools to load modules to memoryinsmod

ifconfig -> configure network interfacesrpm -> compiled packages installer

commands for kernel configuration and compilation:

make menuconfigmake xconfigmake installmake modules_install

1.7 Scripts

To make life even more easy, we wrote scripts for running the PAN,one for the master side, and one for the slave side. This scripts assume the using of configuration files mentioned above. Note that even when running the script, after a bnepX connection is created, you need manually add bnepX to the bridge, as before (we are sure, that an automate solution to this, can be found too). In order to run the scripts remember to give it executing privileges (by: chmod +x script_name).For running a script:

> ./script_name

Master's script:

#!/bin/sh

eval 'xterm -e tail -f /var/log/messages&'

service bluetooth stopservice bluetooth start

#### start pand listening ####pand --role NAP --listen

#### start bridge ####brctl addbr pan0ifconfig pan0 10.0.0.1brctl setfd pan0 0brctl stp pan0 disable

sleep 30

brctl addif pan0 eth0



#Enable IP forwarding since it is disabled by default.echo "1" > /proc/sys/net/ipv4/ip_forward

#Activate NAT masqueradeiptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Slave's script:

#!/bin/sh

eval 'xterm -e tail -f /var/log/messages&'

route del defaultsleep 10

# restart bluetoothservice bluetooth stopservice bluetooth start

#start searching masterpand --role PANU --search --persist

sleep 30

route add default gw 10.0.0.1

echo "script ended"



Appendix 2 – Bibliography (Links)

PAN: http://affix.sourceforge.net/affix-doc/c1051.html Set up PAN network: http://bluez.sourceforge.net/contrib/HOWTO-PAN How to use BlueZ: http://web.inter.nl.net/users/hanscees/bluezhowto.html Bluetooth and Linux:

http://www.hpl.hp.com/personal/Jean_Tourrilhes/bt/Brainboxes.html Technion network lab: http://www-comnet.technion.ac.il/ How to build Linux Kernel: http://www.digitalhermit.com/linux/Kernel-Build-

HOWTO.html Bluetooth background: http://electronics.howstuffworks.com/bluetooth2.htm Bluez and Ipaq: http://www.grinta.net/howto/bluez-ipaq.html Some more Bluez how to:

http://www.jeremythompson.uklinux.net/RH8-0/bluezhowto.pdf Intro to Bluetooth:

http://www.kjhole.com/Standards/BT/BT-PDF/Bluetooth10.pdf PPP over BT on Linux: http://julian.coccia.com/article-7.html Linux hot plugging: http://julian.coccia.com/article-7.html This Project: http://comnet.technion.ac.il/~cn12w04/ The project we started from: http://comnet.technion.ac.il/~cn16s02/ Radio stations guide (Hay, a guy needs some music when he works, no?):

http://windowsmedia.com/radiotuner/MyRadio.asp NAP, PAND and Bridging:

http://www.cs.ucla.edu/~cclljj/interest/notes/bluez/pand_bridge_nap.html Bluetooth and Linux: http://www.holtmann.org/linux/bluetooth/ NAP and Bluetooth: http://www.breakfree.web.id/notes/nap-bluetooth.html BT and Linux: http://quozl.netrek.org/bluetooth/ IPtables: http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html


http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html

http://quozl.netrek.org/bluetooth/

http://www.breakfree.web.id/notes/nap-bluetooth.html

http://www.holtmann.org/linux/bluetooth/

http://www.cs.ucla.edu/~cclljj/interest/notes/bluez/pand_bridge_nap.html

http://windowsmedia.com/radiotuner/MyRadio.asp

http://comnet.technion.ac.il/~cn16s02/

http://comnet.technion.ac.il/~cn12w04/

http://julian.coccia.com/article-7.html

http://julian.coccia.com/article-7.html

http://www.kjhole.com/Standards/BT/BT-PDF/Bluetooth10.pdf

http://www.jeremythompson.uklinux.net/RH8-0/bluezhowto.pdf

http://www.grinta.net/howto/bluez-ipaq.html

http://electronics.howstuffworks.com/bluetooth2.htm



http://www-comnet.technion.ac.il/

http://www.hpl.hp.com/personal/Jean_Tourrilhes/bt/Brainboxes.html

http://web.inter.nl.net/users/hanscees/bluezhowto.html

http://bluez.sourceforge.net/contrib/HOWTO-PAN

http://affix.sourceforge.net/affix-doc/c1051.html


Appendix 3 – System Scheme


Documents

BT Project Book