WRAPAS229X Bluetooth Access Server Manual

 

Access Server Users and Developers Guide Bluegiga Technologies Access Server: Users and Developers Guide by Bluegiga Technologies Published 2007-01-22 (3.1) Copyright 2001, 2002, 2003, 2004, 2005, 2006, 2007 Bluegiga Technologies Bluegiga Technologies reserves the right to alter the hardware, software, and/or specications detailed herein at any time without notice, and does not make any commitment to update the information contained herein. Bluegiga Technologies assumes no responsibility for any errors which may appear in this manual. Bluegiga Technologies products are not authorized for use as critical components in life support devices or systems. The WRAP is a registered trademark of Bluegiga Technologies. iWRAP, WRAP THOR and WRAP Access Server are trademarks of Bluegiga Technologies. The Bluetooth trademark is owned by the Bluetooth SIG Inc., USA, and is licensed to Bluegiga Technologies. ARM and ARM9 are trademarks of ARM Ltd. Linux is a trademark of Linus Torvalds. All other trademarks listed herein belong to their respective owners. Table of Contents 1. Introduction to Access Server............................................................................................................1 1.1. Licenses and Warranty ............................................................................................................2 1.2. Bluegiga Technologies Contact Information ........................................................................2 2. Getting Started with Access Server..................................................................................................3 2.1. Powering Up .............................................................................................................................3 2.2. WWW Interface ........................................................................................................................4 2.3. Shell Prompt Access.................................................................................................................7 2.3.1. Management Console .................................................................................................7 2.3.2. Accessing Remotely.....................................................................................................8 2.3.3. Transferring Files to/from Access Server ................................................................9 2.4. Introduction to Conguration................................................................................................9 2.5. Using the Setup WWW Interface .........................................................................................10 2.6. Using the setup Command Line Application ....................................................................17 2.7. Resetting a Conguration .....................................................................................................18 2.8. Exporting and Importing Congurations...........................................................................18 3. Using the System ...............................................................................................................................19 3.1. Network Interfaces.................................................................................................................19 3.2. Bluetooth .................................................................................................................................19 3.2.1. iWRAP Password Protection ...................................................................................19 3.2.2. LAN Access Prole....................................................................................................20 3.2.3. Serial Port Prole .......................................................................................................20 3.2.4. Object Push and File Transfer Prole......................................................................21 3.2.5. PAN Proles ...............................................................................................................22 3.2.6. Changing the Bluetooth Range................................................................................22 3.2.7. BTCLI - iWRAP Command Line Interface Utility ................................................22 3.2.8. serialbluetooth............................................................................................................22 3.3. Compact Flash Cards.............................................................................................................23 3.3.1. Compact Flash GPRS Cards.....................................................................................23 3.3.2. Compact Flash GPS Card .........................................................................................23 3.3.3. Compact Flash Wi-Fi Cards......................................................................................24 3.4. USB Memory Dongles and Compact Flash Memory Cards ............................................24 3.5. Servers......................................................................................................................................25 3.5.1. Finder ..........................................................................................................................26 3.5.2. ObexSender ................................................................................................................26 3.5.3. SMS Gateway Server.................................................................................................26 3.5.4. User Level Watchdog ................................................................................................27 3.5.5. Remote Management ................................................................................................27 3.5.5.1. Overview........................................................................................................27 3.5.5.2. Management Packet Format........................................................................28 3.5.5.3. Management Packet Information File Format..........................................28 3.5.5.4. Management Operation Example: Hello World.......................................29 3.5.5.5. Management Operation Example: Software Update...............................30 3.5.5.6. Management Operation Example: IPQUERY...........................................30 3.5.5.7. Management with USB Memory Dongle or Compact Flash Memory Card ....................................................................................................................30 iii 3.5.6. FTP ...............................................................................................................................31 3.5.7. Web Server..................................................................................................................31 3.5.8. SNMP ..........................................................................................................................31 3.5.9. OpenVPN....................................................................................................................31 3.5.10. SSH.............................................................................................................................32 3.5.11. Telnet .........................................................................................................................32 3.5.12. NTP............................................................................................................................32 3.6. Utilities.....................................................................................................................................32 3.7. Real Time Clock......................................................................................................................36 3.8. Time Zone................................................................................................................................37 3.9. System Re-Install and Upgrade............................................................................................37 4. SPP-over-IP .........................................................................................................................................38 4.1. How SPP-over-IP Works .......................................................................................................38 4.1.1. Standard Operation...................................................................................................38 4.1.2. Repeater Operation ...................................................................................................39 4.1.3. SPP-over-IP over GPRS.............................................................................................39 4.1.4. Opening Connections from Access Server.............................................................40 4.1.5. SPP-over-IP and COM Ports ....................................................................................41 4.2. Conguring SPP-over-IP.......................................................................................................41 4.2.1. Preparations................................................................................................................41 4.2.2. Preparations................................................................................................................44 4.2.3. Repeater Conguration ............................................................................................45 4.2.4. Wi-Fi Conguration ..................................................................................................46 4.2.5. GPRS Conguration..................................................................................................46 5. Obexsender .........................................................................................................................................47 5.1. Key Features............................................................................................................................47 5.2. Use Cases.................................................................................................................................47 5.2.1. Content Push ..............................................................................................................48 5.2.2. Content Pull................................................................................................................48 5.3. Conguration..........................................................................................................................49 5.3.1. Getting Started ...........................................................................................................49 5.3.2. Updating Obexsender...............................................................................................51 5.3.3. Ensuring Obexsender is Enabled ............................................................................52 5.3.4. Basic Obexsender Conguration.............................................................................53 5.3.5. Uploading Files..........................................................................................................53 5.3.6. Advanced Obexsender Conguration....................................................................54 5.3.7. How to Store Files Sent to Access Server ...............................................................56 5.4. Monitoring Obexsender ........................................................................................................57 5.5. Troubleshooting and Known Issues ....................................................................................58 6. Software Development Kit ..............................................................................................................60 6.1. Introduction to SDK...............................................................................................................60 6.2. Installing SDK.........................................................................................................................60 6.2.1. Access Server Software Development Environment System Requirements ....60 6.2.2. Questions Asked by the Install Script.....................................................................61 6.3. Creating Applications............................................................................................................62 6.3.1. Application Examples...............................................................................................62 6.3.1.1. Installing Examples.......................................................................................62 iv 6.3.1.2. Running Examples........................................................................................62 6.3.2. Creating a New Project .............................................................................................63 6.3.3. Building from the Command Line..........................................................................64 6.3.4. Transferring an Application to Access Server .......................................................64 6.3.4.1. Transferring an Application Using SCP or SFTP......................................64 6.3.4.2. Using SSHFS ..................................................................................................65 6.3.4.3. Transferring an Application Using Terminal Software ...........................65 6.3.4.4. Using NFS Mount .........................................................................................65 6.3.5. Running an Application Transferred to Access Server ........................................66 6.3.6. Using Debugger (GDB/DDD) .................................................................................66 6.3.7. Native SDK .................................................................................................................67 7. iWRAP - Bluetooth Interface...........................................................................................................68 7.1. Terms........................................................................................................................................68 7.2. Starting the iWRAP Servers..................................................................................................68 7.3. Writing iWRAP Applications ...............................................................................................68 7.3.1. Forklistener.................................................................................................................69 7.3.2. iWRAP Client .............................................................................................................69 7.4. Commands Controlling iWRAP ..........................................................................................69 INFO ......................................................................................................................................70 QUIT ......................................................................................................................................71 SET .........................................................................................................................................72 SAVE ......................................................................................................................................82 LOAD ....................................................................................................................................83 PING......................................................................................................................................84 PONG ....................................................................................................................................85 ECHO ....................................................................................................................................86 LOCK.....................................................................................................................................87 UNLOCK ..............................................................................................................................88 SHUTDOWN........................................................................................................................89 SLEEP ....................................................................................................................................90 7.5. Finding Bluetooth Devices....................................................................................................91 INQUIRY...............................................................................................................................91 NAME ...................................................................................................................................93 7.6. Making a Bluetooth Connection ..........................................................................................94 CALL .....................................................................................................................................94 CONNECT............................................................................................................................96 NO CARRIER.......................................................................................................................98 RING......................................................................................................................................99 RINGING............................................................................................................................100 CLOSE .................................................................................................................................101 LIST......................................................................................................................................102 STATUS ...............................................................................................................................104 7.7. Service Discovery .................................................................................................................105 SDPSEARCH ......................................................................................................................105 SDPATTR ............................................................................................................................107 SDPQUERY.........................................................................................................................109 SDP bdaddr ........................................................................................................................110 v SDP ADD ............................................................................................................................111 SDP DEL..............................................................................................................................112 SDP LIST .............................................................................................................................113 7.8. Example Sessions .................................................................................................................114 7.9. Error Codes ...........................................................................................................................114 8. I/O API ...............................................................................................................................................118 8.1. Led and Buzzer API.............................................................................................................118 8.2. GPIO API...............................................................................................................................118 9. Advanced Use Cases for Access Server .......................................................................................119 9.1. Making Access Server Secure .............................................................................................119 9.2. Saving Bluetooth Pairing Information Permanently.......................................................119 9.3. Digital Pen.............................................................................................................................119 9.4. OpenVPN ..............................................................................................................................120 9.4.1. Prerequisites .............................................................................................................120 9.4.2. Installing OpenVPN................................................................................................120 9.4.3. Creating Certicates and Keys ..............................................................................121 9.4.4. Creating Conguration Files..................................................................................123 9.4.4.1. Server Conguration File...........................................................................123 9.4.4.2. Client Conguration File ...........................................................................126 9.4.5. Starting up VPN.......................................................................................................128 9.4.5.1. Starting up the Server.................................................................................128 9.4.5.2. Starting up the Client .................................................................................129 10. Certication Information and WEEE Compliance ..................................................................130 A. Directory Structure.........................................................................................................................133 B. Setup Options ..................................................................................................................................135 B.1. Security settings ...................................................................................................................135 B.2. Generic settings....................................................................................................................136 B.3. Network settings..................................................................................................................137 B.3.1. Default interface settings .......................................................................................138 B.3.2. Ethernet cable settings............................................................................................138 B.3.3. Wi-Fi settings ...........................................................................................................139 B.3.4. GPRS settings...........................................................................................................139 B.4. Applications..........................................................................................................................140 B.4.1. wpkgd settings ........................................................................................................141 B.4.2. FTP server settings..................................................................................................142 B.4.3. ObexSender settings ...............................................................................................143 B.4.3.1. Delete log (conrm)....................................................................................145 B.4.4. SMS gateway settings .............................................................................................145 B.5. Bluetooth settings ................................................................................................................146 B.5.1. Bluetooth proles ....................................................................................................148 B.5.1.1. Lan access prole settings .........................................................................148 B.5.1.2. PAN user prole settings...........................................................................149 B.5.1.3. PAN generic networking prole settings................................................149 B.5.1.4. PAN network access point prole settings .............................................150 B.5.1.5. Serial port prole settings .........................................................................150 B.5.1.6. Object push prole settings.......................................................................151 vi B.5.1.7. File tranfer prole settings ........................................................................151 B.6. Advanced settings ...............................................................................................................151 B.6.1. System information.................................................................................................153 B.6.2. Reboot system (conrm) ........................................................................................153 B.7. Summary of Setup Options ................................................................................................153 C. Open Source Software Licenses...................................................................................................158 D. Supported Hardware .....................................................................................................................162 vii List of Tables 2-1. The Management Console Port Settings ........................................................................................8 3-1. Access Server Network Interfaces.................................................................................................19 3-2. Access Server Servers......................................................................................................................25 3-3. Access Server Utilities.....................................................................................................................32 6-1. Examples, Their Usage and Purpose............................................................................................62 7-1. Supported Parameters for iWRAP SET Command....................................................................72 7-1. SAVE parameters.............................................................................................................................82 7-3. Supported Keywords for Replacing SDP UUIDs or Attributes..............................................105 7-1. SDP Response Formatting Characters........................................................................................107 7-5. iWRAP Errors.................................................................................................................................114 7-6. Errors Masks...................................................................................................................................115 7-7. HCI Error Codes ............................................................................................................................115 7-8. L2CAP Error Codes.......................................................................................................................116 7-9. SDP Error Codes............................................................................................................................117 7-10. RFCOMM Error Codes ...............................................................................................................117 10-1. Excerpt of Table 1B of 47 CFR 1.1310........................................................................................131 C-1. Open Source Licenses in Access Server Software Components ............................................158 C-2. Access Server Open Source Software Components and Their Licences...............................158 D-1. Supported Hardware by Access Server ....................................................................................162 viii Chapter 1. Introduction to Access Server Bluegigas WRAP product family offers for device manufacturers, integrators, companies and developers a simple and fast way to set-up wireless communication systems between standard or proprietary devices, networks, machines and instruments. Access Server is a cutting edge wireless Bluetooth router. It supports multiple communication standards including Ethernet, WiFi, and GSM/GPRS enabling full media-independent TCP/IP connectivity. Access Server is easy to deploy and manage in existing wired and wireless net-

works without compromising speed or security. For rapid deployment, Access Server cong-

urations can easily be copied from one device to another by using USB memory dongles. The device can be conveniently managed and upgraded remotely over SSH secured links. By using Simple Network Management Protocol (SNMP), Access Servers can also be connected to the customers management and monitoring systems. Access Server usage scenarios and applications:

Point-of-sales systems Logistics and transportation systems Telemetry and machine-to-machine systems Medical and healthcare systems Fitness and sport telemetry systems Cable replacement Content and application distribution to mobile phones and PDAs Access Server key features:

Enables Bluetooth networking between multiple devices and networks Serves up to 21 simultaneous Bluetooth connections Offers an open platform for adding local applications Acts as a transparent router or bridge Supports all key communication medias:

Bluetooth Ethernet WiFi, GSM and GPRS with a Compact Flash card USB and RS232 Incorporates a packet ltering rewall Is fast and easy to install Supports all relevant Bluetooth proles and APIs 100 meter range / Software congurable to support 10 meter range DHCP support for plug-and-play installation Uncompromised security: SSH, rewall, and 128 bit Bluetooth encryption 1 Chapter 1. Introduction to Access Server Simple and secure mounting accessory available Bluetooth, CE, and FCC certied Compliant with Bluetooth 1.1, 1.2 and 2.0 Specication 1.1. Licenses and Warranty Warning Bluegiga Technologies is hereby willing to license the enclosed WRAP product and its documentation under the condition that the terms and conditions described in the License Agreement are understood and accepted. The License Agreement is supplied within every WRAP product both in hard copy. It is also available on-line at http://bluegiga.com/as/current/doc/eula.pdf. The use of the WRAP product will indicate your assent to the terms. If you do not agree to these terms, Bluegiga Technologies will not license the software and documentation to you, in which event you should return this complete package with all original materials, equip-

ment, and media. Some software components are licensed under the terms and conditions of an open source li-

cense. Details can be found in Appendix C. Upon request, Bluegiga will distribute a complete machine-readable copy of the source of the aforementioned open source software components during a period of three (3) years from the release date of the software. Delivery costs of the source code will be charged from the party requesting the source code. The Bluegiga WRAP Product Limited Warranty Statement http://bluegiga.com/as/current/doc/warranty.pdf. is available on-line at 1.2. Bluegiga Technologies Contact Information Please see http://www.bluegiga.com/ for news and latest product offers. For more information, contact <sales@bluegiga.com>. Please check http://bluegiga.com/as/ for software and documentation updates. Please contact <support@bluegiga.com> if you need more technical support. To speed up the processing of your support request, please include as detailed information on your product and your problem situation as possible. Please begin your email with the following details:

Access Server product type Access Server product serial number Access Server software version End customer name Date of purchase 2 Chapter 2. Getting Started with Access Server Access Server can be controlled in three ways:

by using the WWW interface by entering commands and using applications at the Access Server shell prompt by sending and/or retrieving les to/from Access Server. Note: The default username is root and the default password is buffy. 2.1. Powering Up To get started with Access Server, connect it to your local area network (LAN) by using an Ethernet cable, and connect the power adapter. Access Server will power up and retrieve the network settings from your networks DHCP server. Access Server will also use Zeroconf (also known as Zero Conguration Networking or Au-

tomatic Private IP Addressing) to get an unique IP address in the 169.254.x.x network. Most operating systems also support this. In other words, you can connect your controlling laptop with a cross-over Ethernet cable to Access Server, then power up Access Server, and the devices will automatically have unique IP addresses in the 169.254.x.x network. Note: If you need to congure the network settings manually and cannot connect rst by using Zero-

conf, you can do it by using the management console. For more information, see Section 2.3.1. The physical interface locations of Access Server are described in Figure 2-1 and Figure 2-2. Figure 2-1. Access Server Connectors Note: There is no power switch in Access Server. The adapter is the disconnection device; the socket-

outlet shall be installed near the equipment and shall be easily accessible. Unplug and plug the power adapter to switch the power on and off. The power led in Figure 2-2 is on when the power adapter is connected. 3 Chapter 2. Getting Started with Access Server Figure 2-2. Access Server LEDs All the blue status LEDs are turned off when the boot procedure is nished and Access Server is ready to be connected. 2.2. WWW Interface Most Access Server functionality can be controlled through the WWW interface by using any standard WWW browser. The wrapnder application (see Figure 2-3), available for the Windows operating system from Bluegiga Techforum (http://www.bluegiga.com/techforum/) provides an easy-to-use interface for nding Access Servers (with SW version 2.1.0 or later) in the local area network. Figure 2-3. Access Server Finder Application The wrapnder automatically identies the broadcast address of the network it runs in, and shows the IP addresses, serial numbers, and Access Server device types it could nd by using 4 Chapter 2. Getting Started with Access Server UDP broadcast when it was launched. Note: Normally, there are two entries for each Access Server. Use the one with the IP address in your local area network. Use the one with the 169.254.x.x, the Zeroconf network address, when it is the only one shown. You can change the broadcast address used for nding Access Servers. A new scan can be done by clicking Rescan. Select an Access Server by clicking its IP address, and click Details to see more information (such as the Bluetooth addresses and friendly names) on Access Server. See Figure 2-4 for details. Figure 2-4. Details Dialog of Access Server Finder Click Connect or double-click an IP address to connect to the selected Access Server by using a WWW browser. Click Exit to close the program. Note: To nd Access Servers IP address without wrapnder, see Section 2.3.2. To access the WWW interface, enter the IP address of Access Server to the browsers address eld and press Enter (see Figure 2-5). 5 Chapter 2. Getting Started with Access Server Figure 2-5. Access Server WWW Interface From the top-level page, click Setup to log in to the conguration interface. The default user-

name is root and the default password is buffy (see Figure 2-6). Figure 2-6. WWW Login Prompt for Access Server Setup After logging in, you can congure several Access Server settings (see Figure 2-7). These are discussed in detail in Section 2.4. 6 Chapter 2. Getting Started with Access Server Figure 2-7. The WWW Conguration Interface of Access Server 2.3. Shell Prompt Access Shell prompt access may be needed for advanced controlling operations that cannot be per-

formed by using the WWW interface. You can get to the shell prompt by using either SSH or the management console. The manage-

ment console is only needed to change the network conguration settings if you cannot cong-

ure the network by using DHCP or Zeroconf. The management console is connected to Access Server with a serial cable. All further controlling activities can be performed remotely using SSH sessions over Ethernet or Bluetooth LAN/PAN connection. If you can establish an SSH connection from a device that has Bluetooth LAN Access or PAN pro-

le support, you do not need the management console. Just connect to Access Server by using LAN Access or PAN prole. Access Server can be seen in Bluetooth inquiries as "Wserialno_n", where "serialno" is the serial number of the device and "n" is the number of the Bluetooth base-

band in question (model 2293 has three Bluetooth basebands, any of which can be connected). After you have connected to the server (no PIN code, username or password needed), establish an SSH connection to the device at the other end of the connection, typically 192.168.160.1. You can also use the wrapnder application to nd the IP address (see Section 2.2 for details). Note: Bluetooth LAN Access and PAN proles are disabled by default. Use the WWW interface to enable them, if needed. The PAN prole can also be enabled by sending the enable-pan.wpk le

(available on-line at http://bluegiga.com/as/current/enable-pan.wpk) to Access Server by using Bluetooth Object Push prole or by inserting a USB memory dongle with the le in its root direc-

tory to Access Servers USB port. Note: The default username is root and the default password is buffy. 7 Chapter 2. Getting Started with Access Server 2.3.1. Management Console If you do not have a Bluetooth LAN/PAN client and if Access Server is not connected to your LAN, or if you do not know the IP address given to Access Server, you can get the rst shell prompt access by using the management console. To setup the management console, proceed as follows:

1. Have a PC with a free COM port. 2. Power off Access Server. 3. Congure your terminal application, such as HyperTerminal in Windows, to use the settings below for your computers free COM port Value Setting 115200bps Speed 8 Data Bits None Parity 1 Stop Bits Flow Control None Table 2-1. The Management Console Port Settings 4. Connect the serial cable shipped with Access Server to your PCs free COM port. 5. Connect the serial cable to the management (user) port in Access Server (see Figure 2-1). 6. Power on Access Server. 7. Enter letter b in the terminal application during the rst ve seconds, while the blue LEDs in Access Server turn on one by one. 8. The management console is now activated and you can see the boot log in your terminal window. Note: The boot process may stop at the following U-Boot prompt:

Hit any key to stop autoboot:

U-Boot>

0 If this happens, enter command boot to continue to boot Linux. 9. Wait for the device to boot up and end with the following prompt:

Please press Enter to activate this console. 10. Press Enter to activate the console. You will be logged in as root in directory /root:

[root@wrap root]

11. You can now control Access Server from the management console. 2.3.2. Accessing Remotely When Access Server is connected to a LAN, it tries to get the IP address by using DHCP and Zeroconf by default. You can then use the wrapnder application to nd the IP address (see 8 Chapter 2. Getting Started with Access Server Section 2.2). If you cannot get the IP address by using the wrapnder, another way to see the IP address of Access Server is to connect with a management console (see previous section), power on the unit and, after the system is up and running, give the ifcong nap command. The inet addr eld for the nap interface contains the IP address of Access Server. For example, in the following capture from the management console, the IP address is 192.168.42.3.

[root@wrap /]$ ifconfig nap nap Bcast:192.168.42.255 HWaddr 00:07:80:00:BF:01 Link encap:Ethernet inet addr:192.168.42.3 inet6 addr: fe80::207:80ff:fe00:bf01/64 Scope:Link UP BROADCAST MULTICAST RX packets:12635 errors:0 dropped:0 overruns:0 frame:0 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:1686246 (1.6 MiB) Interrupt:24 Base address:0xc000 TX bytes:1640 (1.6 KiB) MTU:1500 Metric:1 Mask:255.255.255.0 You can use this address to connect to Access Server remotely over SSH, SCP or SFTP. Note: The default username is root and the default password is buffy. 2.3.3. Transferring Files to/from Access Server You can transfer les to and from Access Server by using, for example:

SCP (secure copy over SSH) SFTP (secure FTP connection over SSH) FTP (plain FTP connection) Note: FTP is disabled by default for security reasons. Use SFTP instead. Tip: If enabled, use the integrated FTP client on the Internet Explorer (type ftp://root:buffy@wrap-

ip-address/ in the address bar) Bluetooth OBEX (Object Push and File Transfer Proles) to/from directory /tmp/obex in Ac-

cess Server NFS (mount an NFS share from a remote device as a part of Access Servers le system) SSHFS (mount an Access Server directory over SSH as a part of any other Linux host le system) To download and install SSHFS, visit http://fuse.sourceforge.net/sshfs.html. USB memory dongle (see Section 3.4 for more information). Xmodem/Ymodem/Zmodem (use rz/rx/rb/sz/sx/sb commands from the management con-

sole) For examples of transferring les, see Section 6.3.4. 9 2.4. Introduction to Conguration Chapter 2. Getting Started with Access Server When Access Server is installed and powered up for the rst time, the default conguration settings are being used. With these settings, Access Server automatically congures its network settings assuming that it is connected to a LAN network with a DHCP server running. Addition-

ally, Access Server also uses Zero Conguration Networking (also known as Automatic Private IP Addressing) to connect to the 169.254.x.x network, which can be used if the network has no DHCP server. After booting up, the only Bluetooth proles enabled are the Object Push and File Transfer Pro-

les, used to send les to/from Access Server. More Bluetooth proles can be enabled, and most of Access Server settings can be congured by using the setup application. It has a WWW interface at http://wrap-ip/setup but it can also be run at the command line. All congurable settings in the setup application are listed in Appendix B with short help texts. Note: The default username is root and the default password is buffy. 2.5. Using the Setup WWW Interface The easiest way to change Access Server settings is to use the WWW interface. Accessing the WWW interface is instructed in Section 2.2. A typical WWW conguration page is shown in Figure 2-8 (This page can be found at Setup Security settings) Figure 2-8. Example WWW Setup Page 10 Chapter 2. Getting Started with Access Server The different parts of the WWW Setup page are discussed in the following list:

Status area The status area serves two purposes:

It indicates that the changes are permanently saved when the user clicks the Save button

(or when the user clicks a toggling Yes/No link). If invalid values were entered in one or more elds, an error message is shown in this area

(see Figure 2-9). Figure 2-9. Trying to Save an Invalid Input Note: It is typically necessary to reboot Access Server for the changes to take effect. This can be done through the WWW interface (Advanced settings menu). Number or text entry elds Most of the congurable settings are text (or number) entry elds. For some elds, such as the IP address or netmask, there are restrictions on the input format. Setup validates the input at save time and accepts valid data only. The elds with errors are shown to the user so that mistakes can be xed (see Figure 2-9). Help -link Click the Help link to retrieve the setup page again with requested help information displayed. For an example, see Figure 2-10. 11 Chapter 2. Getting Started with Access Server Figure 2-10. Help Links in WWW Setup Warning If you have made changes to the settings on the page before clicking Help and not saved them yet, they are lost. Yes and No radio buttons These buttons are typically used to congure a setting that can be either enabled or disabled, and this setting has no effect on the visibility of other settings. Link to a conguration le the congurable settings are actually editable conguration les, such as Some of

/etc/httpd.conf for WWW passwords. Clicking the link will retrieve the le for editing in the browser window, or create a new le, if it does not exist. See Figure 2-11. 12 Chapter 2. Getting Started with Access Server Figure 2-11. Editing Files in WWW Setup Note: You can edit any le through the WWW Setup. to edit les, navigate to Setup Advanced setting Edit other conguration les. Reset button Reset button resets the elds to the values currently in use at Access Server. In other words, the Reset button discards unsaved changes. Note: The Reset button does not make a "factory reset". Save button Save button sends the WWW page to the setup application for validation. If the values in the elds are valid, they are permanently saved and the page is refreshed with the Changes have been saved. message at the top. The accepted values are shown in the page elds. If there were errors in the elds, these are shown as in Figure 2-9. Note: It is typically necessary to reboot Access Server for the changes to take effect. This can be done through the WWW interface (Advanced settings menu). Back link Press the Back link to return to the previous level of the Setup menu hierarchy. Note: Pressing the Back link does not save changes in the elds on the current page. 13 Chapter 2. Getting Started with Access Server Exit link Exit link quits the setup application and returns to the Access Servers main WWW page. Note: Pressing the Exit link does not save changes in the elds on the current page. Toggling Yes/No and on/off links Clicking the Yes/No link (see Figure 2-12) immediately changes the setting and saves the change. Typically these links are used display or hide further settings. Figure 2-12. Yes / No links in WWW Setup The on/off links in Setup Applications Default bootup applications behave in a same way, making and saving the change immediately (see Figure 2-13). 14 Chapter 2. Getting Started with Access Server Figure 2-13. Selecting Default Bootup Applications in WWW Setup Note: To congure the default bootup applications from the command line, use the chkcong command. Upload links The WWW Setup has settings that allow user to upload les to Access Server, for example Setup Advanced Upload a software update (see Figure 2-14). 15 Chapter 2. Getting Started with Access Server Figure 2-14. Uploading les via WWW Setup Use the Browse... button to select the le to be uploaded, and send it to Access Server by clicking Upload. Browsing les Some WWW Setup pages allow users to browse the Access Server le system or part of it, such as Setup Advanced Browse les (see Figure 2-15). 16 Chapter 2. Getting Started with Access Server Figure 2-15. Browsing les via WWW Setup Click the directory names to navigate in the le system. Click del to delete a le or an empty directory. Deletion is not conrmed. Warning The WWW Setup also has menu items that run commands in Access Server, and show the output in the browser window. Some commands, such as rebooting Access Server, are conrmed before execution. 2.6. Using the setup Command Line Application The basic conguration settings can also be changed by using the setup application at the com-

mand line interface. The setup application displays the settings in a hierarchical menu (see Figure 2-16). Navigating the menu is accomplished by entering the number or letter corresponding to the setting to be viewed and/or changed and pressing Enter. Pressing only Enter either accepts the previous value of the setting or returns to the previous level in the menu hierarchy. 17 Chapter 2. Getting Started with Access Server Figure 2-16. Using the setup Command Line Application Note: Ensure that your terminal application does not send line ends with line feeds. If your terminal sends both CR and LF when you press Enter, you cannot navigate in the setup application. 2.7. Resetting a Conguration You can reset the default conguration with the setup -r command. The command requires rebooting of Access Server. When the system starts up, the default conguration settings are re-

stored. If you have only changed the conguration by using the setup application, the following commands at the Access Servers command prompt will sufce:

[root@wrap /]$ setup -r

[root@wrap /]$ reboot Note: This does not reset the edited les to factory defaults; it only affects only the settings changed through the WWW Setup or the setup command line application. 2.8. Exporting and Importing Congurations You can export conguration settings (expect for passwords and the list of default bootup ap-

plications) with the following command:

[root@wrap /root]$ setup -o > settings.txt The saved settings can later be restored with the following commands:

[root@wrap /root]$ setup -m settings.txt

[root@wrap /root]$ reboot 18 Chapter 3. Using the System This chapter describes the basic features of a Bluegiga Access Server. This includes information on using Access Server as a Bluetooth LAN/PAN Access Point or a Bluetooth Serial Port Cable Replacer, using the Web Server, ObexSender, and WRAP Package Management System. The various ways of uploading content for browsing and/or downloading are also included, as well as getting familiar with the utility applications. Using the features described in this chapter does not require Access Server Software Develop-

ment Environment to be installed. Note: The default username is root and the default password is buffy. Note: Most of the conguration les are in Linux text le format, where the lines end with a sin-

gle Line Feed (LF, "\n") character. Some applications will not work if the conguration le format is changed to MS-DOS format (this happens, for example, if you transfer the les to Windows for edit-

ing with Notepad), where the lines end with both Carriage Return and Line Feed (CR+LF, "\r\n") characters. 3.1. Network Interfaces The Access Server network interfaces are described in Table 3-1. Interface nap eth0 wlan0 wi0 gn bnep#

ppp#

Description Dynamic virtual Ethernet ("cable") device. This is the device having an IP address. All the programs should use this device instead of eth0. Real Ethernet device, which is dynamically linked to the nap device. Do not use this device, use nap instead. Wi-Fi device. In the client mode (default), this device has its own IP address. In the access point mode, it is dynamically linked to the nap device (the default interface). Virtual control device for wlan0. Do not use this device. Virtual device for PAN-GN connections. These devices are used for incoming and outgoing PAN connections. These devices are created, deleted and linked (to nap or gn) dynamically. These devices are used for incoming and outgoing LAP connections. These devices are created and deleted dynamically. By default, data coming from ppp# is masqueraded to the nap device. Table 3-1. Access Server Network Interfaces 3.2. Bluetooth The iWRAP servers (one server in Access Server 2291, three in Access Server 2293) are automat-

ically started at power-up. By default, the Object Push and File Transfer Proles are activated. The iWRAP servers can be accessed and controlled (by applications or even interactively with a telnet client) through the iWRAP interface, described in Chapter 7. Currently, there can be up to 14 simultaneous Bluetooth connections between a single master iWRAP server and up to seven simultaneous slaves. 19 Chapter 3. Using the System 3.2.1. iWRAP Password Protection The access to iWRAP can be password protected. The default password is buffy, but it can be set off or changed with the setup application (see Section 2.4). The password is case sensitive. The password must be typed in as the rst command after the server has replied with "READY."

3.2.2. LAN Access Prole This prole is not automatically started at boot. The default settings can be changed with the setup application (see section Section 2.4), or runtime with the iWRAP interface (see Chapter 7). Access Server can also act as a LAN Access Client, but in this case it must be controlled manually using iWRAP commands, as described in Chapter 7. Note: Since Bluetooth specication 1.2, LAN Access Prole has been deprecated. 3.2.3. Serial Port Prole This prole is not automatically started at boot. The default settings can be changed with the setup application (see section Section 2.4). The Serial Port Prole is used to replace an RS-232 serial cable between two devices with a Bluetooth connection. The physical setup is shown in Figure 3-1. Figure 3-1. Serial Cable Replacement Physical Setup State A) in the gure is the starting situation with a serial cable connecting the devices. This cable is to be replaced with a Bluetooth connection. In state B) the long serial connection is replaced with a Bluetooth Serial Port Prole connection between the two Access Server devices. These Access Server devices are then locally connected 20 Chapter 3. Using the System to the user devices with (short) serial cables. The cable between user device A and Access Server device A must be a cross-over cable. The cable between user device B and Access Server device B must be similar (direct or cross-over) to the one used in state A). If RTS/CTS handshaking is used to ensure correct data transfer, the serial cables must have these pins connected. Notice that this handshaking is "local": it takes place between the user device and Access Server. No handshaking between user device A and user device B on the other end of the Bluetooth connection is provided. If RTS/CTS handshaking is not used, CTS must be connected to DTR. DCD, DTR, and DSR signals are not supported. This also means that user devices A and B will not be able to tell whether or not the Bluetooth connection is up. When the physical setup is ready, you can create the Bluetooth connection. By default, the Serial Port Prole is started up at boot with the default settings. That is, listening in DevB mode, at 115200 bps, 8 data bits, no parity, 1 stop bit, and RTS/CTS enabled. To change these settings, use the setup application or the WWW Setup interface, as described in Section 2.4. Note: To enable Serial Port Prole, navigate to Setup Applications Default bootup applications in the WWW Setup interface, and switch serialport application to off. Enabling can also be done from command prompt with command chkcong serialport on. 3.2.4. Object Push and File Transfer Prole Access Server has two OBEX proles: Object Push Prole (ObjP) and File Transfer Prole (FTP). You can use these proles to transfer les easily between different Access Server devices and other devices supporting ObjP/FTP. The OBEX proles are handled by forwarding incoming calls to the obexserver program, which handles both proles. The working directory is /tmp/obex, and users have full read and write access to that directory. By default, the default contact card /etc/default.vcf is copied to that directory at boot. In the ObjP mode, obexserver will prex received les with the senders Bluetooth address and iWRAP port number. Two simple command line utilities, obexput and obexget, are provided. They can be used to send and retrieve les to and from another Bluetooth device supporting ObjP/FTP. Usage:

obexput [parameters] bdaddr channel file(s) Note: You can use the friendly name instead of Bluetooth address as the "bdaddr" parameter and keywords "OBJP" and "FTP" as the "channel" parameter for automatic service discovery. Enter either of these commands without parameters to view a short help text for using the command. A non-zero return value indicates an error. The reason for this error is printed to the terminal. Tip: Special parameters and the iWRAP interface (see Chapter 7) obexput command can be easily used from the user application as follows:

CALL bdaddr OBJP FORK \"/usr/bin/obexput - 1 filename\"

21 Chapter 3. Using the System

- as bdaddr and 1 as channel tells obexput that it will be launched by the iWRAP server, and that data connection is bound to standard input and output. 3.2.5. PAN Proles Access Server has support for all PAN prole modes: Personal Area Network User (PANU), Net-

work Access Point (NAP) and Generic Networking (GN). Accepting incoming PAN connections to any of these modes is disabled by default for security reasons. Access Server can be congured to accept incoming PAN connections and the default settings can be changed by using the setup application (see section Section 2.4). The Network Access Point mode is the most useful PAN prole mode. You can enable it by sending the enable-pan.wpk le (available on-line at http://bluegiga.com/as/current/enable-

pan.wpk) to Access Server by using the Bluetooth Object Push prole. Alternatively, you can copy the le to the root of a USB memory dongle and insert the dongle to Access Servers USB port. The device creating the PAN connection decides upon the modes to be used. Access Server automatically handles incoming connections. Access Server can also act as a PAN client, but in this case it must be controlled manually by using the iWRAP interface, described in Chapter 7. 3.2.6. Changing the Bluetooth Range The transmit power of Access Server is congurable. By default, class 1 (100 meter range) set-

tings are used. The settings can be changed down to "class 2" (10 meter range) settings with the b2b_class2 command, or even lower with the b2b_class3 command. Class 1 settings can be restored with the b2b_class1 command. After b2b_class# is given, it is recommended to reboot Access Server once to restart ObexSender and other applications connected to the iWRAP server(s). Note: If the operation is successful, you get one Cant open baseband message with Access Server model 2293 and three messages with the 2291 model. 3.2.7. BTCLI - iWRAP Command Line Interface Utility You can send commands to an iWRAP server by using the btcli application. Usage:

btcli [options] command To see the command options, enter the btcli --help command. The specied command is sent to an Access Server iWRAP server (the rst server at port 10101 by default) and all replies are echoed to the standard output. The application waits and prints the replies for a certain amount of time (10 seconds by default) and exits. The iWRAP commands are described in Chapter 7. 3.2.8. serialbluetooth It is also possible to control the rst iWRAP server (at port 10101) through RS-232 with the serialbluetooth application. 22 Chapter 3. Using the System Usage:

serialbluetooth [options]

To see the command options, enter the serialbluetooth --help command. Basically, serialbluetooth takes commands from a serial port and forwards them to the iWRAP server. All the commands available through iWRAP are also available through serial port. There are two exceptions:

1. After making an outgoing RFCOMM data call, all input from the serial port is forwarded to the data socket, not to the control socket. To close the data socket, you have to write

+++ with a 200ms pause before each character. It is not possible to have two concurrent RFCOMM calls. 2. All incoming RFCOMM calls are answered automatically. Again, to close the data socket, write +++ as with the outgoing call. 3.3. Compact Flash Cards Access Server functionality can be extended by using GSM/GPRS, Wi-Fi and GPS Compact Flash cards. The supported Compact Flash cards are listed in Appendix D. 3.3.1. Compact Flash GPRS Cards The operating system automatically identies the Compact Flash GPRS card when it is inserted. Access Server can use the GPRS card to connect to the GPRS network, or to act as an SMS gateway to send and receive SMS messages. You can enable the GPRS mode and congure its settings, such as the SIM cards PIN code, by using the setup application or its WWW interface. For more information, see Section 2.4 and documentation for Setup Network settings Enable GPRS interface in Appendix B. GPRS, when enabled, is by default only turned on when needed. If Access Server can access the Internet (or any desired address) by using the default interface nap, it does not activate and use the GPRS (ppp0) interface. The simplest way to test the GPRS interface is to congure the default interface nap to use dynamic network conguration (the default) and enable GPRS through the setup application, then to disconnect the Ethernet cable, reboot the device with the management console enabled. After the boot, ping an IP address in the Internet, such as 194.100.31.45 (bluegiga.com). The rst ve or so packets are lost, but after that the GPRS connection should be up. To enable the interface automatically, just enter ping -c 20 ip-in-internet to /etc/rc.d/rc.local. Note: If you also want to use the Ethernet connection, you must remove it from the default inter-

face (nap) bridge and congure its network settings individually using the setup application while keeping the default interface network settings in their default (dynamic) state. Using WRAP SMS Gateway Server is documented in Section 3.5.3. If needed for some special use, the Compact Flash GPRS card can also be accessed directly from

/dev/ttyS0, a device le which exists if the GPRS card is successfully initialized. 23 Chapter 3. Using the System 3.3.2. Compact Flash GPS Card The operating system automatically identies the Compact Flash GPS card when it is inserted. At that time, the device le /dev/ttyS0 is created and the GPS card can be accessed by using that device with the serial port settings the GPS card uses. The supported Compact Flash cards are listed in Appendix D. 3.3.3. Compact Flash Wi-Fi Cards Access Server supports Prism II/III based CF Wi-Fi cards. The supported Compact Flash cards are listed in Appendix D. By default, Access Server notices when a supported Wi-Fi card is inserted and tries to use it in the client mode, without encryption. So, if there is an open Wi-Fi Access Point in range, Access Server will automatically connect to it. To congure Wi-Fi to the Access Point mode, or to change other Wi-Fi settings, use the setup application or its WWW interface at Setup Network settings Wi-Fi. Note: Older Compact Flash cards with rmware version 1.4.2 do not work in the Access Point mode. Instead, you will see an error message in the system log (/var/log/messages, viewable at Setup Advanced System Information Show system log le). A standard set of command line wireless utilities is provided to ne-tune your Wi-Fi congura-

tion:

iwcong iwlist iwpriv For more information on these utilities, see: http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html 3.4. USB Memory Dongles and Compact Flash Memory Cards Access Servers persistent memory storage can be extended by using an USB memory dongle or a Compact Flash memory card. These are also used by the Access Server Remote Management System (see Section 3.5.5) - each time a dongle or memory card is inserted, it is automatically mounted, and scanned for management packets, which are processed and unmounted. To use the USB dongle or Compact Flash memory card for your own applications, the memory must be mounted manually by using command:

[root@wrap /]$ mount -t vfat device /mnt/usb The device parameter is a path to the USB dongle or Compact Flash memory card lesystem device. For the rst dongle inserted after a reboot, it is /dev/sda1 if the dongle is partitioned

(which often is the case) and /dev/sda if the dongle has no partition table. The rst Compact Flash memory card is typically at /dev/hda1, correspondingly. If you have used several dongles after reboot, new device le names are created: /dev/sdb1 for the second one, /dev/sdc1 for the third one, and so on. In the case of memory cards, naming is similar, that is, the second one gets device le name /dev/hdb1. 24 Note: Always remember to unmount the memory dongle or memory card with command:

[root@wrap /]$ umount /mnt/usb Chapter 3. Using the System 3.5. Servers Access Server server applications are started automatically at system power-up or when an iWRAP server or the Internet services daemon needs them. The servers and their purposes are described in Table 3-2. Server bluetooth nder obexsender smsgw watchdog wpkgd crond ftpd udhcpd udhcpcd inetd httpd pppd snmpd sshd syslogd Description Access Server iWRAP Server, which is described in detail in Chapter 7. WRAP Finder Service. WRAP ObexSender server. WRAP SMS gateway server, which is described in detail in Section 3.5.3. Notice that this server is disabled by default. Use the setup application or the chkcong smsgw on command to enable it. WRAP user level watchdog. WRAP remote management system daemon. A daemon to execute scheduled commands. This server is congurable through the /var/spool/cron/crontabs/root le or the crontab command in the same way as any Linux crond. Internet File Transfer Protocol Server. You can congure this server with the setup application. Notice that this server is disabled by default. Use the WWW interface of the setup application or the chkcong ftpd on command to enable it. This server is a DHCP daemon for providing automatic network conguration for clients in the network. Notice that, by default, this server is only enabled for the gn interface, used by Bluetooth PAN Generic Networking prole. DHCP client daemon for automatic network conguration. Internet services daemon. Notice that this server is disabled by default. Use the setup application or the chkcong inetd on command to enable it. Web server, which is described in detail in Section 3.5.7. Point to Point Protocol daemon. iWRAP server uses this server. This server can be used manually over the user serial port (/dev/ttyAT1). SNMP daemon. This server is available as a separate installation packet. SSH daemon. System logging daemon. This server can be congured by using the setup application. 25 Chapter 3. Using the System Server telnetd zcip ntpd Table 3-2. Access Server Servers Description Telnet protocol server. Notice that this server is disabled by default. Use the setup application or the chkcong telnetd on command to enable it. Zero conguration networking service. Network Time Protocol (NTP) daemon. 3.5.1. Finder The Finder service is a small service, which listens for UDP broadcast queries from Access Server Finder applications and responses to those queries with identication information (IP address, model, serial number, etc.) about Access Server. The nder command can be used to query Finder service information from Access Servers in the network. With no parameters, nder sends the query using the broadcast address of the default interface (nap). Broadcasting to networks of other interfaces can be done with --interface parameter, such as the zero conguration interface nap:9in the following example:

[root@wrap root]$ finder --interface nap:9 Access Server 2291 (S/N: 0402110112) (build: 3.1)

- Hostname: wrap.localdomain

- IP: 169.254.30.233 (nap:9), 192.168.161.1 (gn)

- Ethernet MAC: 00:07:80:00:03:ed

- iWRAP: 10101 00:07:80:80:0b:c3 bt1.2 (W0402110112_1) Access Server 2291 (S/N: 0606221029) (build: 3.1)

- Hostname: wrap.localdomain

- IP: 169.254.36.138 (nap:9), 192.168.161.1 (gn)

- Ethernet MAC: 00:07:80:00:0d:44

- iWRAP: 10101 00:07:80:80:0b:c4 bt1.2 (W0606221029_1)

[root@wrap root]$

3.5.2. ObexSender The ObexSender application is automatically started in Access Server. Its purpose is to receive business cards (vCards), images, or other les, and analyze their content and send les back selecting them based on congured keywords found. ObexSender can also make an inquiry for bluetooth devices, and automatically send one or more les to all new devices found. ObexSender

/etc/obexsender.conf le (see Section 2.4). For detailed instructions on using ObexSender, see Chapter 5. setup application or by editing the congured with the can be 3.5.3. SMS Gateway Server WRAP SMS Gateway Server supports Nokia 20, Nokia 30, or Wavecom WMOD2 compatible GSM terminals and the supported GSM/GPRS Compact Flash cards for sending and receiving 26 Chapter 3. Using the System SMS messages. By default, the Compact Flash card is used. The PIN code query of the SIM card at power-up must be disabled. WRAP SMS Gateway Server is disabled by default. To enable it, use the setup applications WWW interface, as described in section Section 2.4. Enabling is done at Setup Applications Default bootup applications smsgw. WRAP SMS Gateway Server can be congured to use a modem connected to the user serial port with the setup application or its WWW interface by changing the setting at Setup Applications SMS gateway settings Modem device to /dev/ttyAT1 from the default

/dev/ttyS0. Note: If you are using the user serial port, ensure you have Bluetooth Serial Port Prole disabled, as they share the same physical user serial port. Note: To use Nokia terminals, the device must be connected to the user serial port when the server starts up. Also, the terminal must be congured to operate in RS-232/AT command. Nokia terminals are congured with the N20 or N30 Congurator application. For further information on using smsgw, see the makesms example in Section 6.3.1. 3.5.4. User Level Watchdog WRAP User Level Watchdog daemon listens on UDP port 4266 for "id timeout" messages. "id"

is an ASCII string, without spaces. If "timeout" equals to 0 (zero), the "id" is removed from the list of processes to wait. If "timeout" is greater than 0 (zero), the "id" is added or updated. When there is no message for "id" received within the "timeout" seconds, the user level watch-

dog dies and the kernel watchdog reboots Access Server. The watchdog command can be used to send messages to the watchdog daemon. This is done through command watchdog id timeout. For example, watchdog test 5. 3.5.5. Remote Management Access Server contains simple tools that provide means for full and secure remote management of the device. The basic remote management can be performed using the WWW Setup interface, SSH com-

mand line access, and SCP and SFTP le transfer protocols. In addition to those, Access Server contains WRAP Remote Management System for transferring management packets over different media to Access Server and automatically sending response packets back. The management packets (*.wpk) are automatically processed when they are transferred to the autoinstall directory in Access Server (/tmp/obex by default, but congurable with the setup application or WWW interface at Setup Applications wpkgd settings). The easiest way to transfer a management packet to this directory is to upload it from WWW Setup at Setup Advanced settings Upload a software update. 3.5.5.1. Overview WRAP Remote Management System top level architecture is shown in Figure 3-2. 27 Chapter 3. Using the System Figure 3-2. WRAP Remote Management Architecture A management action is performed using the following procedure:

1. A customer system prepares the management packet (*.wpk). 2. The management packet is delivered to Access Server, to the packaging daemons inbox di-

rectory. You can currently use Bluetooth, SCP, SFTP and plain FTP to do this. The packet can also be transmitted using a USB memory dongle, Compact Flash memory card or through the WWW Setup interface. 3. The Access Server packaging daemon processes the management packet, possibly generat-

ing a reply packet. 4. (Optional) The reply packet is delivered to the customer system. 3.5.5.2. Management Packet Format The package name must be of format name.wpk, where "name" can be user dened. Package must be a tar archive that is compressed with gzip (such as les named *.tar.gz or

*.tgz). The package must contain a package information le called wpkg.pif in the package root (the le contents are described later), otherwise the built-in defaults for wpkg.pif are used. All other les, if any exist, should be data les, scripts or executables required for the man-

agement operation. 28 Chapter 3. Using the System 3.5.5.3. Management Packet Information File Format The management packet information le (wpkg.pif) consists of tags and their data, described here:

%wpkg-version: 2 Contains information for version checking. 2 is currently the only supported version. It is also the default value.

%wpkg-prepare: [command line[s]]

One or more commands (all commands are lines until the next tag is interpreted as a command line) to execute. Commands may contain parameters, redirections and job control as well. The built-in default value for this is /usr/bin/dpkg -i *.deb || echo ERROR: Installation failed.. This enables the special case of creating .wpk packets from .deb packets simply with tar czf foo.wpk foo.deb. (wpkg.pif is not needed in this special case).

%wpkg-reply: method This value indicates where the generated reply packet is sent. By default, it is sent to where it came from. Possible values are:

default le:///path/lename scp://remote:le objp://bdaddr/

none

%wpkg-format: type This value indicates what kind of a reply packet will be generated. Possible values are:

ascii (this is the default value, everything echoed by the prepare-section will be sent). tgz (all les in the current directory will be sent). vcf (same as ascii, but assume it is a vCard). vmg (same as ascii, but assume it is a vMessage). vnt (same as ascii, but assume it is a vNote). vcs (same as ascii, but assume it is a vCalendar). html (same as ascii, but assume it is HTML).

%wpkg-auth: auth Optional authentication string required by wpkgd. 3.5.5.4. Management Operation Example: Hello World See below for the simplest example of wpkg.pif:

%wpkg-version: 2

%wpkg-prepare:

29 echo Hello world Chapter 3. Using the System This will generate a reply packet containing text "Hello world". You can generate the wpk le simply by giving the command tar czf hello.wpk wpkg.pif. 3.5.5.5. Management Operation Example: Software Update See below for a more complex example of wpkg.pif:

%wpkg-version: 2

%wpkg-prepare:

FOO=pwd cd /

tar xzf ${FOO}/files.tar.gz echo Done. This example will extract les from the included files.tar.gz le. You can generate the wpk le with command tar czf update.wpk wpkg.pif les.tar.gz. 3.5.5.6. Management Operation Example: IPQUERY In this example, we build a simple packet that can be used with a Bluetooth enabled phone to retrieve the IP address of an Access Server. File wpkg.pif reads:

%wpkg-version: 2

%wpkg-format:

%wpkg-prepare:

vcf ipaddr() {

echo ifconfig nap | grep "inet addr" | awk -F [:] \

\\{print\\$2\\} | awk \\{print\\$1\\}

}

serialno() {

echo wrapid | grep Hardware | awk \\{print\\$5\\}

}

echo -e "BEGIN:VCARD\r"

echo -e "VERSION:2.1\r"

echo -e "N:serialno\r"

echo -e "TEL:ipaddr\r"

echo -e "URL:hostname\r"

echo -e "END:VCARD\r"

This example will send the reply back as a vCard (contact card). Please note that you have to include all required vCard formatting by yourself. You can generate the wpk le simply giving the command tar czf ipquery.wpk wpkg.pif. To use this example, send the le ipquery.wpk to the inbox of your Bluetooth phone. Check that you have Bluetooth enabled in the phone. Then, from the phones inbox, send the le ipquery.wpk over Bluetooth to Access Server. 30 Chapter 3. Using the System 3.5.5.7. Management with USB Memory Dongle or Compact Flash Memory Card When an USB memory dongle or Compact Flash memory card is inserted, Access Server auto-

matically tries to mount it (using VFAT type). If the mount is successful, Access Server scans the root for *.wpk packets. If a packet is found, the WRAP Package daemon handles it. Optional reply packets are saved back to the root folder (unless otherwise stated in the %wpkg-reply tag). 3.5.6. FTP If you enable the FTP server, users can use it to log in anonymously to the /tmp/obex directory with download access or as root with password buffy to the root directory with full access. The password and other settings can be changed on Access Server with the setup application or by editing the /etc/ftpd.conf le (see Section 2.4). Note: Do not enable FTP because it is insecure. Use SSH (SCP or SFTP) instead. A commonly used client with a graphical user interface is, for example, WinSCP (http://winscp.net/). 3.5.7. Web Server The integrated web server in Access Server supports HTTP/1.0 methods GET and POST, and has light user authentication capabilities. The content can be either static or dynamic - the WWW server is CGI/1.1 compatible. The web server is always running and the content (http://wrap-ip-address/) is located in the

/var/www/html/ directory in Access Servers le system. The web server is congured to protect the WWW Setup interface with a username and pass-

word. The default username and password can be changed as instructed in Section 2.4. For fur-

ther information about using the web server for your own applications, see the web examples in Section 6.3.1. is update package software available 3.5.8. SNMP Techforum A separate

(http://www.bluegiga.com/techforum/). This update adds the Net-SNMP suite of applications to Access Server. The current Net-SNMP implementation for Access Server is limited and will be extended in the future. However, it can be used to poll the basic status of Access Server. Conguration details can be found and altered in conguration le /etc/snmp/snmpd.conf, which is accessible as described in Section 2.4. For more information about the Net-SNMP suite, see http://net-snmp.sourceforge.net/

from Bluegiga software 3.5.9. OpenVPN Techforum A separate

(http://www.bluegiga.com/techforum/). This update adds the OpenVPN, a full-featured SSL VPN solution, to Access Server. For detailed instructions on using OpenVPN with Access Server, see Section 9.4. For more information about the OpenVPN, see http://openvpn.net/. from Bluegiga available package update is 31 Chapter 3. Using the System 3.5.10. SSH By default, users can use SSH to log in (or SCP and SFTP to transfer les) as user root with password buffy. The password can be changed on Access Server by using command passwd or with the setup application. 3.5.11. Telnet If you enable telnet, users can log in over telnet as user root with password buffy. The pass-

word can be changed on Access Server using the command passwd or with the setup applica-

tion. Note: Do not enable telnet because it is insecure. Use SSH instead. 3.5.12. NTP The ntpd service uses the standard Network Time Protocol (NTP) to keep Access Server system time automatically in sync using a random selection of eight public stratum 2 (NTP secondary) time servers. The service is also congured to answer NTP requests from other devices. The NTP server conguration can be altered by editing its conguration le /etc/ntpd.conf. 3.6. Utilities Access Server is basically a small Linux system. Whether logged in from the management con-

sole or with SSH, your shell session starts as the root user in the root directory. After that, you have the option to use most of the standard Linux utilities, briey listed and described in Table 3-3. Most of the commands have a small built-in usage help that can be seen by executing the command with the -h or --help parameter. Application adduser arping awk b2b_class1 b2b_class2 b2b_class3 basename bash btcli btproxy bunzip2 bzcat cardctl cat Description This command add user to the system. This command pings hosts by ARP requests/replies. Pattern scanning and processing language. WRAP baseband module control script (set basebands to class 1). WRAP baseband module control script (set basebands to class 2). WRAP baseband module control script (set basebands to shortest possible range). Strip directory and sufx from le names. Bourne-Again SHell. WRAP iWRAP Server Command Line Interface utility. WRAP iWRAP Proxy for Access Servers (test revision). Decompress bzip2-compressed les. Decompress bzip2-compressed les to stdout. Monitor and control the state of PCMCIA sockets. Concatenate les and print on the standard output. 32 Application chat chgrp chkcong chmod chown chroot clear cmp cp cpio crontab cut date dd deluser df dfu dialup dirname dmesg dpkg dpkg-deb du dump_cis dun egrep encode_keychange env expr false fgrep nd free ftp gdbserver Chapter 3. Using the System Description Automated conversational script with a modem. Change group ownership. Updates and queries runlevel information for system services. Change le access permissions. Change le owner and group. Run command or interactive shell with special root directory. Clear the terminal screen. Compare two les. Copy les and directories. Copy les to and from archives. Maintain crontab les for individual users. Remove sections from each line of les. Print or set the system date and time. Notice that the date command does not store the date into the battery powered real time clock. Use the hwclock application instead. Convert and copy a le. Delete a user from the system. Report le system disk space usage. WRAP baseband module rmware upgrade tool. WRAP iWRAP helper application. Strip non-directory sufx from le name. Prints or controls the kernel ring buffer. A medium-level package manager for (.deb) packages. Debian package archive (.deb) manipulation tool. Estimate le space usage. Retrieves and parses the Card Information Structures for inserted PCMCIA devices, or optionally, parses CIS information from a le. WRAP iWRAP helper application. Print lines matching a pattern. Produce the KeyChange string for SNMPv3. Run a command in a modied environment. Evaluate expressions. Do nothing, unsuccessfully. Print lines matching pattern. Search for les in a directory hierarchy. Display the amount of free and used memory in the system. Internet le transfer program. Remote server for GDB debugger. Available in a separate software package. 33 Application getty grep gunzip gzip head hexdump hostid hostname hwclock id ide_info ifcong ifport ifuser insmod ip iptables, ip6tables kill killall ln logger login ls lsmod md5sum mkdir mknod mktemp modprobe more mount mv net-snmp-cong nslookup ntpd Chapter 3. Using the System Description Opens a tty, prompts for a login name, then invokes /bin/login. Print lines matching a pattern. Expand gzip compressed les. Compress les into gzip format. Output the rst part of les. A lter which displays the specied les, or the standard input, if no les are specied, in a user specied format. Print out a unique 32-bit identier for the machine (not yet implemented). Show or set the systems host name. Query and set the hardware clock. Print information for username or current user. IDE device information. Congure a network interface. Select the transceiver type for a network interface. Checks to see if any of the listed hosts or network addresses are routed through the specied interface. Loads the specied kernel modules into the kernel. TCP/IP interface conguration and routing utility. IP packet lter administration. Terminate a program. Kill processes by name. Make links between les. Make entries into the system log. Sign on. List directory contents. List loaded modules. Compute and check MD5 message digest. Make directories. Make block or character special les. Make a temporary le name (unique). High level handling of loadable modules. File perusal lter for crt viewing. Mount a le system. Move (rename) les. Net-SNMP tool. Queries the nameserver for IP address of given host. Network Time Protocol NTP daemon. 34 Application obexbrowser obexget obexput pack_cis passwd picocom pidof ping, ping6 ps pwd rb, rx, rz, sb, sx, sz rdate reboot renice reset rm rmdir rmmod route scp scsi_info sed setup sftp sleep snmp*

sort ssh, slogin ssh-keygen strace strings stty su sulogin Chapter 3. Using the System Description The WRAP obexbrowser. A command line OBEX client interface. The WRAP OBEX tool for retrieving a le from a remote device with ObjP/FTP support. The WRAP OBEX tool for sending a le to a remote device with ObjP/FTP support. Convert a text description of a PCMCIA Card Information Structure

(CIS) to its packed binary representation. Update a users authentication token(s). Minimal dumb-terminal emulation program. Available in a separate software package. Find a process ID of a running program. Send ICMP ECHO_REQUEST packets to network hosts. Report process status. Print the name of the current/working directory. Xmodem, Ymodem, Zmodem le receive and send. Get and possibly set the system date and time from a remote HOST. Reboot the system. Alter the priority of running processes. Resets the screen. Remove les or directories. Remove empty directories. Unload loadable modules. Show / manipulate the IP routing table. Secure copy (remote le copy program). SCSI device description tool. A Stream EDitor. The WRAP Setup Application. See Section 2.4. Secure le transfer program. Delay for a specied amount of time. Set of standard SNMP command line applications. Sort lines of text les. OpenSSH SSH client (remote login program). SSH authentication key generation, management and conversion. Utility to trace system calls and signals. Available in a separate software package. Display printable strings in binary le. Change and print terminal line settings. Run a shell with substitute user and group IDs. Single-user login. 35 Application supportinfo sync tail tar tcpdump telnet test time top touch tr traceroute true tty uartmode umount uname uniq unzip uptime usleep uudecode uuencode wc vi wget wrapnder wrapid which whoami zcat zcip xargs Table 3-3. Access Server Utilities Chapter 3. Using the System Description Output collectively all the system status and conguration information. Flush lesystem buffers. Output the last part of les. Tar archiving utility. Utility for dumping trafc on a network. Available in a separate software package. User interface to the TELNET protocol. Check le types and compare values. Run command and display its resource usage information when nished. Provides a view to processor activity in real time. Change le timestamps. Translate or delete characters. Trace the route that IP packets take on their way to the host. Do nothing, successfully. Print the le name of the terminal connected to standard input. WRAP Uartmode: Change the mode of the user serial port (DTE or DCE). Unmount le systems. Print system information. Remove duplicate lines from sorted lines. List, test, and extract compressed les in a ZIP archive. Tell how long the system has been running. Sleep some number of microseconds. Decode a le create by uuencode. Encode a binary le. Print the number of bytes, words, and lines in les. A text editor. A utility to retrieve les from the World Wide Web. Finds other Access Servers in the network. Access Server identication program. Shows build and hardware conguration information. Shows the full path of (shell) commands. Prints the user name associated with the current effective user id. Expand gzip compressed les to the standard output. Zero Conguration Networking application. Build and execute command lines from the standard input. 36 Chapter 3. Using the System 3.7. Real Time Clock The system clock is read from the battery operated real time clock during boot. The time be-

tween the system time and the real time clock is automatically synchronized when the system is rebooted using the reboot command. Synchronizing can also be done using the hwclock -

-systohc --utc command. Give command hwclock --help for more information about the hw-

clock utility. 3.8. Time Zone The default time zone in Access Server is UTC. You can change the timezone by replacing the le /etc/localtime with the correct le from your desktop Linux system (using your

/etc/localtime or a desired zone from /usr/share/zoneinfo). 3.9. System Re-Install and Upgrade Access Server can be re-installed with the latest software version. The latest software updates and instructions are available at http://www.bluegiga.com/techforum/. Most of the software updates are delivered as a wpk le. The easiest way to install the latest software version is:

1. Start Access Server. 2. Copy the wpk le or les to an empty USB memory dongle. 3. Insert the dongle in Access Server 4. One or several LEDs will turn on, and after 10-60 seconds they will all turn off. 5. Remove the dongle and reboot Access Server. 6. You have now successfully upgraded Access Server. See Section 3.5.5 for detailed descriptions of other options and how to create your own wpk les. 37 Chapter 4. SPP-over-IP SPP-over-IP is a special functionality of iWRAP Bluetooth servers running in Access Servers. It offers a transparent way to transmit data from Bluetooth Serial Port Prole (SPP) enabled devices to server computers or PCs. Several transport medium are supported, such as Ethernet, Wi-Fi or and GPRS. 4.1. How SPP-over-IP Works The SPP-over-IP application enables transparent data transfer between any Bluetooth Serial Port Prole (SPP) complaint device and a server, laptop or desktop connected to the same network. This enables plug n play connectivity from a Bluetooth network to any standard TCP/IP based network. See Figure 4-1 for an overview of the application and a brief introduction to its func-

tionality. Features of SPP-over-IP are:

Access Server 2291 supports 7 incoming SPP connections. Access Server 2293 supports 21 incoming SPP connections. SPP-over-IP can be used over Ethernet, Wi-Fi or GRPS networks. SPP-over-IP also works over Bluetooth Personal Area Networking (PAN) connections, so not all Access Servers need to be physically (cable) connected to the TCP/IP network, but some Access Servers can linked using the Bluetooth PAN connection. This is referred to as repeater operation. If SPP-over-IP application cannot open the TCP connection to dened IP address and port, the SPP connection will not be accepted. If the TCP server on PC is closed, all SPP connections will be closed as well. When Access Server is in its default conguration, it tries to enable sniff power saving mode on all idle Bluetooth connections to minimize power consumption. SPP-over-IP can also be used to opposite direction, i.e. Access Server opens the Bluetooth connections to dedicated Bluetooth devices. See Section 4.1.4 for more details. SPP-over-IP can also be combined with the Tactical Softwares Serial/IP software. Serial/IP software converts automatically TCP connections to virtual COM ports on the host PC, so legacy applications utilizing COM-ports instead of TCP/IP can also be used. 4.1.1. Standard Operation With the standard conguration, SPP-over-IP works as described below:

Listens for incoming Serial Port Prole (SPP) connections Takes control of all incoming connections Opens a TCP connection to the dened IP address and TCP port Forwards all incoming data from the SPP device to the established TCP connection and vice versa 38 Chapter 4. SPP-over-IP Figure 4-1. SPP-over-IP Network Architecture All the server computer needs to do is to listen for incoming TCP connections from Access Server to a specied TCP port and receive/send the application data. 4.1.2. Repeater Operation The SPP-over-IP application can also be used in a so-called repeater mode. This feature is useful when all Access Servers can not be directly connected to the TCP/IP network, but they can be connected to other Access Servers by using Bluetooth PAN-connection. PAN enables transmit-

ting TCP/IP packets wirelessly over Bluetooth. The gure below illustrates this conguration:

Figure 4-2. Repeater Mode in SPP-over-IP 4.1.3. SPP-over-IP over GPRS SPP-over-IP software can also be used over GPRS instead of wired Ethernet connection. This 39 requires that Access Server is equipped with a working GSM/GPRS compact ash card. See Appendix D for supported cards. Chapter 4. SPP-over-IP Figure 4-3. SPP-over-IP over GPRS Notice when using GPRS:

Data upload rate is around 8-12kbps (depending on GPRS card) Data download rate is around 32-48kbps (depending on GPRS card) Data transmission delays can be very high, sometimes even seconds GPRS connection may be unreliable and break easily. This should be taken account when designing the system. If GPRS connection breaks, all the TCP and Bluetooth connections will also be closed. 4.1.4. Opening Connections from Access Server In the basic SPP-over-IP use case, Access Server is in passive mode and only accepts incom-

ing connections. It is however possible to implement a system where Access Server opens the Bluetooth connections to the dened static Bluetooth devices or, alternatively, on ad-hoc basis. In this case, special software must be developed for Access Server, which handles the outgoing connections and decides where they are opened to. This software can be developed with the Access Server Software Development Kit (SDK). The software can be written with C, C++ or standard Linux scripts. 40 Chapter 4. SPP-over-IP Figure 4-4. Access Server Opening the Connections 4.1.5. SPP-over-IP and COM Ports SPP-over-IP can also be used together with Tactical Softwares Serial/IP software. Serial/IP software simply converts the TCP connections into virtual COM ports on the host computer. This is very useful in applications, which do not have support for TCP/IP but support COM ports instead. Figure 4-5. SPP-over-IP with Serial/IP An of http://www.tacticalsoftware.com/products/serialip.htm evaluation Serial/IP version can be downloaded from:

4.2. Conguring SPP-over-IP This chapter briey instructs you to congure SPP-over-IP to work in different network setups or use cases. 41 Chapter 4. SPP-over-IP 4.2.1. Preparations SPP-over-IP is easiest to congure through WWW setup, which allows you to access all the necessary congurations. First, you must gure out Access Servers IP address (if it is connected to a TCP/IP network). This is easiest to do with the WRAPFinder software:

Start the WRAPFinder software Scan your network for available Access Servers 1. 2. 3. Choose the correct Access Server 4. Press the Connect button Your web browser opens the WWW setup of the selected Access Server. Figure 4-6. WRAPFinder 5. Once the browser window has opened, click the Setup link 42 Chapter 4. SPP-over-IP Figure 4-7. WWW Setup Login Type in you user name and password and you get access to the main view of the setup:

6. Figure 4-8. WWW Setup Main View Note: The "basic" Bluetooth Serial Port Prole must be disabled for SPP-over-IP to work. By default, this is the case. You can verify it by checking that serialport service (which implements the prole) is off in WWW Setup Applications Default startup Applications (see Figure 4-9). 43 Chapter 4. SPP-over-IP Figure 4-9. Checking that Bluetooth Serial Port Prole is disabled. 4.2.2. Preparations le settings SPP-over-IP are modied

/etc/bluetooth.confwhich can be edited by navigating in WWW Setup to Setup Bluetooth settings Edit startup script. To enable SPP-over-IP, add lines similar to following to the end of that le (lines starting with #

are comments which can be left out):

conguration servers iWRAP in

# Forward incoming connection to IP 192.168.42.99 socket 7444 SET BLUETOOTH LISTEN 1 192.168.42.99:7444

# Add SDP record for Serial Port Profile SDP ADD SPP 1 "SPP-over-IP"

In the example conguration above, RFCOMM channel 1 is used by the SPP-over-IP service. You can, however, use any other free channel as well. The RFCOMM channel must be same in both SDP ADD (see SDP ADD for details of command syntax) and SET BLUETOOTH LISTEN

(see Table 7-1 for details of command syntax) conguration commands. 44 Chapter 4. SPP-over-IP The text "SPP-over-IP" is the name of the service shown in Bluetooth service discovery. Nor-

mally, there should be no need to specify a different name, but nobody forces you to use "SPP-

over-IP". In the example, connections are forwarded to a server listening for incoming connections to TCP port 7444 in host with IP address 192.168.42.99. You must change these to match your system. See Figure 4-10 for WWW Setup example of conguration. Figure 4-10. SPP-over-IP Conguration Made over WWW Setup Once you have done your conguration, press the Save button and restart the server so that the settings take place. 4.2.3. Repeater Conguration If you want to congure Access Server also to act as a repeater (see Figure 4-2) you must make some additional congurations. Add the line below to your Bluetooth startup script (line start-

ing with # is comment which can be left out):

# Automatically connect to Access Server with PAN-NAP enabled SET CONTROL AUTOEXEC CALL 00:07:80:bf:01 PAN-NAP 45 Chapter 4. SPP-over-IP You must replace the Bluetooth address used in the example (00:07:80:80:bf:01) with the Blue-

tooth address of the Access Server, on which you want to receive the PAN connection. Note: The server receiving the PAN connection must have the PAN-NAP prole enabled. This is by default not the case, so in setup or its WWW interface, ensure that the setting at Bluetooth settings Bluetooth proles Enable PAN network access point prole says yes. No other conguration is needed. See Section 3.2.5 for more information on PAN proles. The Bluetooth PIN codes must be the same in both Access Servers. Figure 4-11. Repeater Conguration 4.2.4. Wi-Fi Conguration If Access Servers must be connected to Wi-FI (WLAN) instead of physical Ethernet connection, you also need to make additional congurations through the WWW setup. See Section 3.3.3 for more information. 4.2.5. GPRS Conguration If Access Servers must be connected to GPRS network instead of physical Ethernet or Wi-Fi connection, you also need to make additional congurations through the WWW setup. See Section 3.3.1 for more information. 46 Chapter 5. Obexsender Obexsender is one of the built-in applications in Access Server. It is dedicated to Bluetooth prox-

imity marketing, content distribution, location based services, and much more. Access Server plus Obexsender provide the user with a ready platform to start content distribution including all the necessary Bluetooth functions from discovering the devices to transmitting the content. The user needs to only focus on what, when, and to whom to send the content - rest is taken care of by Access Server and Obexsender. The gure below illustrates a simplied Obexsender network:

Figure 5-1. Simplied Obexsender network 5.1. Key Features Automatic device discovery and content push over a Bluetooth connection 18 simultaneous Bluetooth connections with one Access Server Upload speed even up to 75KB/sec with Bluetooth 2.0+EDR Content can be stored locally - with external memory even up to 2GB space Wide networking support: Bluetooth, Ethernet, Wi-Fi, GPRS and EDGE Secure remote connections over a Virtual Private Networking Remote le system support Lots of ltering options, such as device type, or distance from access server Extensive logging Interaction between several Access Servers Content time stamping 47 5.2. Use Cases This chapter describes some possible Obexsender use cases. Chapter 5. Obexsender 5.2.1. Content Push This is the standard functionality in Obexsender. In content push mode, Obexsender is scanning for devices and pushing it to clients who belong to the target group (not opted out by ltering). Figure 5-2. Obexsender Use Case: Content Push 5.2.2. Content Pull Obexsender can also be congured into a content pull mode. In this mode, the transaction is initiated by the user. The user can send any le to the server or alternatively a le containing some specic string such as "MP3" or "NOKIA N73". The server parses the received le and as a response pushes a corresponding le to the user if such exists. 48 Chapter 5. Obexsender Figure 5-3. Obexsender Use Case: Content Pull 5.3. Conguration This chapter contains instructions from the most basic Obexsender conguration to the more advanced use cases. 5.3.1. Getting Started The easiest and fastest way to congure Obexsender is through the WWW setup. To do this, your Access Server must be connected to the same network as your PC or, alternatively, you can also use a direct Ethernet cross cable or a Bluetooth PAN connection (see Section 3.2.5 for instructions on how to enable PAN). By default, Access Server uses DHCP, so if you connect it to your LAN, it must support DHCP as well. 1. Once you have successfully connected Access Server, start the "WRAPFinder" software. WRAPFinder lists all the Access servers in the same network as your PC. If Access Server does not show immediately, you may need to push the Rescan button a couple of times. 49 Chapter 5. Obexsender Figure 5-4. WRAPFinder 2. Next, select the correct Access Server and press the Connect button in the WRAPFinder user interface. An internet browser window opens with the Access Server IP address in the address bar. Figure 5-5. Access Server WWW Setup 3. Click the Setup link. A login screen is opened. Enter a correct user name and password. 50 Chapter 5. Obexsender Figure 5-6. WWW Setup Main Page 4. After a successful login, you get access to the WWW setup main page. Note: At this point, you should check your access server software version. Obexsender works only with software version 2.2.0 and newer. At the bottom of the screen you should see a line saying:

Access Server, S/N 0511170051 (wrap-2-2) -

Copyright Bluegiga Technologies Inc, 2001-2006 If the version is older than "wrap-2-2", you must rst update your Access Server. Latest software releases and instructions can be found from www.bluegiga.com/techforum/

5.3.2. Updating Obexsender If you have software version 2.2.0 in your Access server, you need to update Obexsender to the latest version. It offers many new, useful and necessary features that include:

Retry delay, scan delay and reply delay Dump delay Possibility to save incoming les, i.e. remote requests Watchdog support Regexp and Unicode support Other minor bug xes and improvements The rest of the manual concentrates on the latest Obexsender, but it also covers all the features offered by previous Obexsender. The main menu of latest (at the time of writing) Obexsender is shown in Figure 5-7 51 Chapter 5. Obexsender Figure 5-7. Latest Obexsender Main Menu 5.3.3. Ensuring Obexsender is Enabled By default, the Obexsender application is enabled, so as a rst task you should of course enable it if. This is quite simply done from the following page in the WWW setup (Figure 5-8): Access Server - Setup - Applications - Default bootup applications Obexsender is enabled after a reboot. However, if you have not completed rest of the congura-

tion, do not reboot Access Server yet. 52 Chapter 5. Obexsender Figure 5-8. Default Boot-up Applications Note: For Obexsender to start at all, you must dene at least one le to be pushed to remote devices. You can do this in:

Access Server - Setup - Applications - ObexSender settings - Edit conguration le For more information, see Section 5.3.6, chapter "Send these les in this order". 5.3.4. Basic Obexsender Conguration conguration. As a rst step please go the to the WWW setup page in Setup Applications Obexsender settings. On this page (Figure 5-7) you can congure the basic Obexsender settings. See Section B.4.3 for default values and detailed descriptions of the settings. 5.3.5. Uploading Files You can easily upload new content (les) for Obexsender by selecting Upload a new le in the Obexsender main menu. All you need to do is browse for the le you want to upload and 53 Chapter 5. Obexsender click Upload. You will see a conrmation note, for example "File /usr/local/obexsender/Bike.jpg uploaded" . At the moment, you can only upload to /usr/local/obexsender directory using WWW setup. If you would like to upload to another directory, you must use secure FTP to accomplish that.

(Normal FTP is disabled by default in Access Server for security reasons). For example WinSCP, available from http://www.winscp.org, is a good application that for secure FTP le transmis-

sions. 5.3.6. Advanced Obexsender Conguration Specifying the content is done by editing the

/etc/obexsender.conf le. The le also contains all congurable ObexSender settings (the settings covered earlier and some advanced settings). In this section, we will only go through the settings that can not be congured using the WWW interface. to be sent by ObexSender

(les) Note: Lines beginning with the hash character "#" are comments and ObexSender will ignore them. Advanced Conguration Directives baseband Specify which iWRAPs are used for sending/inquiry. By default all basebands in this Access Server are in use. Syntax: baseband <ip> <port> [password]

Example:

baseband 127.0.0.1 10101 ignore Dont send to these Bluetooth devices. The default setting ignore 00:07:80: is recom-

mended. It disables sending les to other Bluegiga Access Servers. Syntax: ignore <bdaddr-prefix>

Example:

ignore 00:07:80:

tester Always send to these devices when found (60s interval). Other timeout settings are ignored with these devices. Syntax: tester <bdaddr>

Example:

tester 00:07:80:80:00:bf scandir Obexservers directory (for remote requests). This is the directory which ObexSender searches for remote requests. It should match the directory congured for Obexserver

(/tmp/obex/ in default conguration. Syntax: scandir <directory>

54 Chapter 5. Obexsender Example:

scandir /tmp/obex le Specify full pathname(s) of le(s) to be sent, possibly at given time. If there are no les specied, ObexSender does not do inquiry. The les specied are sent in listed order. Syntax: file <filename> [timestamp]

Example for sending tp1.gif rst, then tp2.gif:

file /usr/local/obexsender/tp1.gif file /usr/local/obexsender/tp2.gif Timestamp can be specied as Weekday (Mon/Tue/Wed/Thu/Fri/Sat/Sun), Starthour-

Endhour or WeekdayStarthour-Endhour:

Example for sending image.jpg on Fridays, image2.jpg every day between 8am and 2pm and image3 only on Tuesdays between 8am and 2pm:

file /usr/local/obexsender/image1.jpg Fri file /usr/local/obexsender/image2.jpg 8-14 file /usr/local/obexsender/image2.jpg Tue8-14 reply This feature allows you to request specic content from ObexSender. Basic operation is that you send a le with needed information to Access Server and you will receive a correspond-

ing le in return. The keyword specied is matched for "<content of le from user> + <bd-ad-dr-es-ss>". Keyword is extended regular expression (regex) and case-non-sensitive. Syntax: reply <keyword> <filename>

Example for replying with pic.gif if a GIF image is sent to Access Server (in fact this matches for the string "GIF" found in the image headers; you could use "VCF" for vCards,

"JFIF" for JPEG images and so on):

reply GIF /usr/local/obexsender/pic.gif Example for replying only to a certain device (its Bluetooth address is already known), ignoring le content (pic.gif is sent back after device sends anything to Access Server):

reply 00:07:80:80:00:bf /usr/local/obexsender/pic.gif delnomatch This setting applies if youre using REPLY-feature of ObexSender and you send a le to Ac-

cess Server to receive specic content. Now, if the le you sent doesnt match to ObexSender conguration, the le will be deleted if this settings is set to "Yes". Otherwise the le is saved. Matching les are always deleted. Disable this if you have some other program do-

ing ObjP/FTP. By default, this is enabled. Syntax: delnomatch Yes|No Example of disabling the functionality:

delnomatch No 55 verbose Determines the verbosity level of ObexSender logging. The Level can be from 0 to 4, dened by the count of lines with uncommented term verbose. Level 0 means that there will be minimal logging and level 4 that there will be maximum amount of logging. Chapter 5. Obexsender Warning Full verbose logging (4) should be used only for debugging purposes, since it creates a lot of logs and the ash memory can be lled rather quickly. Syntax: verbose Example of setting maximum level of ObexSender logging:

verbose verbose verbose verbose dumple You can choose to save the information about already served devices, so you can form a so-called "block list". If this block list is saved in ash memory, it will be preserved even if Access Server is rebooted. This basically ensures that remote devices dont receive the same content even if Access Server is rebooted. Syntax: dumpfile <filename>

Example of dumple in default location:

dumpfile /usr/local/obexsender/ignore.dump dumpdelay Determines how often (in seconds) a dump le is updated. "0" disables this feature. We recommend to use a rather big value, for example 15min = 900s. Using a small value here can physically burn the ash memory over time. Warning Syntax: dumpdelay <seconds>

Example of setting dumpdelay with recommended value:

dumpdelay 900 broadcast This settings tells ObexSender to broadcast already served devices to other ObexSenders

(specied using unicast IP address, broadcast IP address or interface name). Syntax: broadcast <unicast-ip>|<broadcast-ip>|<interface>

Example of broadcasting to all ObexSender in the same network with the default interface

(nap):

broadcast nap 56 Chapter 5. Obexsender 5.3.7. How to Store Files Sent to Access Server By default, all les sent over Object Push to Access Server are stored to the /tmp/obex folder and deleted after they have been processed. It is however possible to save the les to another directory. The following procedure shows how to automatically copy these les to an example folder /usr/local/remote_request. (NOTE: you must rst create this folder!):

1. Create a copier script /usr/local/bin/copier. You can do it for example in the WWW setup -> Advanced settings -> Edit other conguration les and typing here

/usr/local/bin/copier. Put the following script into the le:

#!/bin/sh

# to be called from obexsender: --fork /usr/local/bin/copier

# This directory must exist:

SAVEDIR="/usr/local/remote_request"

/bin/cp "$1" "${SAVEDIR}/$3/bin/date "+%s"-echo $1 | /usr/bin/cut -f 2 -d-"

2. Make the script executable by giving command chmod a+rx /usr/local/bin/copier at the 3. command line interface. Edit /etc/bluetooth.conf and append to the end of the le the following line (below the line is in two parts, combine these in the conguration le):

SET BLUETOOTH LISTEN 3 "/usr/sbin/obexserver --bdaddr $b --prefix $b-$P-

--fork /usr/local/bin/copier" 110 Save changes and restart Access Server. 4. Now all incoming les are copied to the /usr/local/remote_request directory. The format of the les is bdaddr-btserverport-timestamp-filename.ext. 5.4. Monitoring Obexsender Obexsender creates log about its operation to a specied log le. By default, no log le is speci-

ed, so you should do this rst with instructions provided in Section 5.3.4. When you choose View log in the Obexsender menu, you can only see the summary of Obexsender action, i.e how many successes, failures and retries have occurred. When you select the date or Total in the summary view, you will see more details. You will see to which Bluetooth address the content was sent and if the transmission was a failure or success, or if transmission will be retried later. See some example logging in the gure below:

57 Chapter 5. Obexsender Figure 5-9. Detailed Obexsender Log View If you want to see even more details about how Obexsender is performing, you can increase the verbosity level of logging. See Section 5.3.6, chapter "Be verbose (0-4)". Full verbose logging is usually needed in problem solving only. 5.5. Troubleshooting and Known Issues Troubleshooting:

Obexsender is not sending anything?

Make sure you have at

(obexsender.conf). See Section 5.3.6, topic "Send these les in this order". Also check that Obexsender is activated, see Section 5.3.3. least one content le specied in the conguration le Mobiles receive les only to 10-20 meters. Isn t Obexsender supposed to work up to 100 meters?

Almost all mobile phones are so-called "Class 2" devices, which means that their maximum range is about 10 meters. In good conditions they can achieve even 30 meters. If you know there are "Class 1" devices (range up to 100 meters) in the area, you can check the RSSI value you have set, which determines the operational range of Obexsender. See section Section 5.3.4. 58 Chapter 5. Obexsender Known issues:

If you enter a non-existing path in "Log le name" conguration, Obexsender will fail to start. If you have entered a password for the iWRAP (Bluetooth) interface and the same password is not set in the Obexsender conguration, Obexsender will fail to start. If several log les are dened in obexsender.conf, Obexsender will fail to start 59 Chapter 6. Software Development Kit 6.1. Introduction to SDK This manual describes how to create and use applications by using Access Servers Software Development Environment. The relationships between the applications in the Access Server Software Platform are shown in Figure 6-1. Figure 6-1. Relationship Between Customer Applications and Access Server Software 6.2. Installing SDK Note: The Software Development Environment can only be installed on a Personal Computer (PC) running the Linux operating system. 6.2.1. Access Server Software Development Environment System Requirements The following hardware and software are required to run the Access Server Development Envi-

ronment:

60 Chapter 6. Software Development Kit A PC with:

CD-ROM drive The Linux operating system (the SDK has been tested with RedHat Enterprise Linux 3 and above, Fedora Core 2 and above; Suse and Ubuntu are reported to work too) make and gawk must be installed Devel libraries (especially zlib-devel, e2fsprogs-devel and ncurses-devel) must be in-

stalled modutils-2.4.26 or newer must be installed 300MB of available hard disk space An Ethernet connection to a Local Area Network (also connected to Access Server) is highly recommended. Mount the Access Server SDK CD-ROM or ISO image, change the current working directory to where it is mounted, and run the install script. If the user running install does not have privileges to create the directory for the toolchain, normally /usr/local/arm, the install script prompts for roots password. Example (user input is printed like this):

$ mount /dev/cdrom /mnt/cdrom

$ (or mount -o loop /path/to/sdk2.iso /mnt/cdrom)

$ cd /mnt/cdrom

$ sh install During the installation, the system will prompt you with some questions (described below) regarding the components to install and the paths to install them to. If you are not familiar with Linux, just press enter to these questions to accept the default values. The default values are suitable for most users and systems. 6.2.2. Questions Asked by the Install Script Access Server toolchain directory (default: /usr/local/arm) This is the path where you want

(arm-linux-gcc, etc.) to be installed. the Access Server Software Development tools Note: If you change this value, the Access Server tools and libc must be recompiled. The recompila-

tion process is complicated and lengthy, and it can also fail, depending on your system. Recompilation is automatically done by the install script, if necessary. Development directory (default: [home_of_current_user]/asdk) This is the path where you want the Access Server Software Development Environment to be installed. Development directory owner (default: [current_user])

(Asked only if run as root.) This is the development directory owners username. 61 Chapter 6. Software Development Kit Note: If this is not the username of the developer for whom the Software Development Environment is being installed, the user will not have rights to use the development les and therefore can not develop any Access Server software. Install toolchain sources (default: no - unless the tools directory was changed) This value indicates whether the toolchain sources will be installed. The sources are only re-

quired if the Access Server tools directory was changed from the default target location in step 1. Compile image after installation (default: yes) If set to yes, the install script will compile the Access Server lesystem image to test that the installation was successful and that the Development Environment is working correctly. 6.3. Creating Applications The fastest way to start developing Access Server applications is to study, change, and recompile the example les in the asdk/examples directory. 6.3.1. Application Examples To demonstrate the software development features of Access Server, the Access Server Software Development Environment comes with several example applications. 6.3.1.1. Installing Examples The compiled example les are located in WPK packets on the Access Server SDK tree in subdi-

rectories of directory asdk/examples. The examples can be manually uploaded and installed on Access Server by sending them to the /tmp/obex directory. The wpkgd server automatically installs them. Uploading can be done over Bluetooth, SCP, SFTP or WWW Setup Advanced Upload a software update (see Figure 2-14). 6.3.1.2. Running Examples The examples, with their usage and purpose, are described in Table 6-1. Example helloworld serial Usage

/usr/bin/helloworld

/usr/bin/serial /dev/ttyAT1 Purpose The "Hello, world!" application.

"Hello, world!" to the serial port. Notice that /dev/ttyAT1 must be free (no WRAP SMS Gateway or Bluetooth Serial Port Prole is using it). 62 Chapter 6. Software Development Kit Purpose This is the simplest Bluetooth RFCOMM server example. Use, for example, btserver as a client to test this example. This example waits for a full line from the client, echoes is back and then exits. This is a simple Bluetooth RFCOMM server example, which logs lines received from the connected client, and answers with

"ACK". Use, for example, btserver as a client to test this example. This is an advanced iWRAP client example, which can run both as an RFCOMM server, when it works as forkserver, or as a client, when it sends "YooHoo" to remote server, waits, displays the response, and quits). I/O: LED example. This is a Machine-2-Network (M2N) example. System Logger (syslogd) conguration is needed for actual remote connection. Without it, the example simulates it locally. Demonstration of the web server capabilities. This example demonstrates WRAP SMS Gateway by sending SMS messages with it. Example forkserver Usage SET BLUETOOTH LISTEN 11

/usr/bin/forkserver btlogger SET BLUETOOTH LISTEN 11

/usr/bin/btlogger /tmp/logle btserver

/usr/bin/btserver - for server mode

(if no forkserver is running),

/usr/bin/btserver <bdaddr of btserver in server mode or forkserver> 11 for client mode ledtest m2n

/usr/bin/ledtest echo testmessage | /usr/bin/m2n www makesms Browse to http://wrap-ip-

address/example.html Browse to http://wrap-ip-address/send.html. Notice that this example assumes that WRAP SMS Gateway is up and running (see Section 3.5.3). setup-helloworld This example demonstrates how to add a new helloworld submenu to the WWW Setup, with two menu items that change the variables in

/etc/sysconfig/helloworld le. Table 6-1. Examples, Their Usage and Purpose 6.3.2. Creating a New Project To start a new project, you must create a new subdirectory in your Development Environments directory (asdk/) and add your application source les and Makefile to that directory. A project skeleton can be automatically created by using the Access Server Project AppWizard. 63 Chapter 6. Software Development Kit Just give the make appwiz APP=dir/to/newapp command in the Development Environments top level directory (asdk/). A "hello world" example ANSI C project is then created. To use C++ compiler, replace $(do_link) with $(do_link_cc) in Makefile. The details of the compile process and variables you may need to modify before compiling your application, such as CFLAGS, LDFLAGS and CXXFLAGS, can be seen in le asdk/Rules.mak. Now you have a new project waiting for coding. To compile the project, run make in the asdk/dir/to/newapp directory. The build system also creates the installation packet (hello-timestamp.wpk), which can be transferred to the /tmp/obex directory of Access Server from where it is installed automatically. 6.3.3. Building from the Command Line The Access Server Development Environment uses the ARM port of the GNU bintools and compilers to build applications. If you are not familiar with Linux development, use the method explained in the previous section instead of writing your own makeles. If you still want to use your own development environment, there are two minor issues to re-

member:

1. Tools are prexed with arm-linux-, so for calling the gcc C-compiler, you must call arm-

linux-gcc, and so on. 2. Tools are located in /usr/local/arm/3.4.5/bin/ directory, which is not in PATH by de-

fault. 6.3.4. Transferring an Application to Access Server To run an application on Access Server, it must rst be transferred to it. There are several ways of doing this (see Section 2.3.3). The most convenient ways in conjunction with software devel-

opment are discussed in the following subsections. 6.3.4.1. Transferring an Application Using SCP or SFTP An SCP transfer is done with a single command. In the following example, myapp is transferred to the /tmp directory in Access Server:

$ scp myapp root@<wrap-ip-address>:/tmp root@<wrap-ip-address>s password: buffy (not echoed back)

/path/to/myapp/myapp

$

20.0KB/s 00:00 100%

20KB An SFTP transfer is almost similar, but the command procedure resembles an FTP session (FTP can also be used if the FTP server is enabled):

$ sftp root@<wrap-ip-address>

Connecting to <wrap-ip-address>... root@<wrap-ip-address>s password: buffy (not echoed back) sftp> cd /tmp sftp> put myapp Uploading myapp to /dev/shm/tmp/myapp 64 Chapter 6. Software Development Kit

/path/to/myapp/myapp sftp> quit

$

100%

20KB 20.0KB/s 00:00 6.3.4.2. Using SSHFS With SSHFS, the Access Server lesystem can be securely mounted to be a part of the develop-

ment hosts lesystem. To download and install SSHFS, visit http://fuse.sourceforge.net/sshfs.html. After installation you can mount the whole lesystem and copy the myapp application to the /tmp directory in Access Server by using the following commands:

$ mkdir mnt

$ sshfs root@<wrap-ip-address>: mnt root@<wrap-ip-address>s password: buffy (not echoed back)

$ cp myapp mnt/tmp

$ fusermount -u mnt

$

6.3.4.3. Transferring an Application Using Terminal Software If your Access Server is not connected to a LAN, you can use terminal software of your choice to transfer data to Access Server. Access Server contains an X/Y/Zmodem protocol application, which allows you to transfer data over the console using almost any terminal software available:

1. Connect your computer to the Access Server management UART using a cross-over serial cable, and start your terminal software (use settings: 115 200bps, 8 data bits, no parity, 1 stop bit). 2. Change your working directory to where you want to upload your application, and run the Xmodem application with your application name as a parameter. 3. Start Xmodem send from your terminal software. Example 6-1. Transfering Files with Xmodem

[root@wrap /] cd /tmp

[root@wrap /tmp] rx testapp rx: ready to receive testapp. now start xmodem (checksum, not CRC) send from your terminal

[root@wrap /tmp]

If you want to save the application to /usr/local/bin (on the ash le system), you will have to replace cd /tmp with cd /usr/local/bin (and possibly create the directory, if it does not exist). To examine Access Server directory structure, please see Appendix A. 65 Chapter 6. Software Development Kit 6.3.4.4. Using NFS Mount To use NFS mount, have a NFS share prepared in your development PC and mount the directory by using command mount -o nolock <dev-pc-ipaddress>:/nfsshare /mnt/nfs. After this, you can access the share in directory /mnt/nfs. 6.3.5. Running an Application Transferred to Access Server To run the application you just transferred to Access Server, you need access to the Access Server console, either using terminal software connected to the Access Server management UART or using the SSH connection (log in as user root and the root password, which is buffy by default). Having established a connection to Access Server, change the directory to where your applica-

tion is located and change le permissions so that it can be executed, then run it. Example 6-2. Running an Application

[root@wrap /] cd /tmp

[root@wrap /tmp] chmod 755 testapp

[root@wrap /tmp] ./testapp 6.3.6. Using Debugger (GDB/DDD) You can use GNU debugger GDB and a graphical user interface, such as DDD, for debugging applications in Access Server. This requires that you install gdbserver to Access Server. It can be installed from a software package located in directory asdk/arch/arm/gpl/gdbserver/

You have to compile with debug options and without symbol stripping to make debugging work. This can be done by overriding the default CFLAGS variable set in asdk/Rules.mak. You can do this by adding line CFLAGS = -Wall -Os -ggdb -I$(SDKBASE)/include after line include /home/user/asdk/Rules.mak in Makefile After you have compiled your application with these options and transferred your application to Access Server, you can start debugging the application as follows:

1. Start gdbserver on Access Server Usage:

gdbserver :<port> <your application>

Example: gdbserver :6789 ./hello 2. Start debugger on the host PC. (This example is for the DDD) Example: ddd --debugger /usr/local/arm/3.4.5/bin/arm-linux-gdb hello 3. Create a connection to Access Server. Usage:

66 Chapter 6. Software Development Kit target remote <node IP>:<port>

Example: target remote 192.168.42.3:6789 4. Run the program by using command continue. 6.3.7. Native SDK It is also possible compile applications for Access Server using native toolchain. To use it, copy les sdk.iso and sdkmount.wpk from directory lib in the Access Server SDK CD-ROM (or ISO image) to the root directory of an USB memory dongle, and insert it to Access Servers USB port.

(You can also use Compact Flash memory card for this purpose in similar manner). The native SDK is automatically mounted and you can start using the compiler (gcc) in Access Server. All tools now available can be found in directory /usr/sdk/bin. 67 Chapter 7. iWRAP - Bluetooth Interface The Bluetooth service in Access Server is controlled through the TCP socket interface called iWRAP. The rst iWRAP server is listening on port 10101. In the case of Access Server 2293, the second iWRAP server is listening on port 10102, and the third one is listening on port 10103. All commands to an iWRAP server and replies from the server are plain ASCII strings ending in CR+LF ("\r\n"). Commands and replies are not case sensitive. When connecting to a server, you must rst wait for the READY. prompt. Do not send any com-

mands prior to this. Some replies are broadcast to all clients of the server. If you see something that you have not requested or that is not intended for your client (identied by the link identi-

er), simply ignore the reply. Normally, the iWRAP is protected with the buffy password. The password can be disabled or changed. For more information, see the SET command. If the password is enabled, it must be sent rst, immediately following the READY. prompt, to the iWRAP server. Otherwise, all commands will fail. For an example of using the iWRAP, please see the asdk/examples/btsend le in the SDK directory. In the following examples, bold lines are commands sent by the client to the iWRAP server and normal lines are replies received from the iWRAP server by the client. 7.1. Terms Bluetooth address (bdaddr) consists of six hex digits separated by a colon. For example,

"00:07:80:80:bf:01". With commands requiring a Bluetooth address, you can also use the Bluetooth friendly name instead. Bluetooth channels are numbered from 1 to 30. In Access Server, the Serial Port Prole is as-

signed to channel number two, the Object Push Prole and File Transfer Prole to channel num-

ber three, and the LAN Access Prole is on channel number four. The other channels are free for user applications. Link Identier (link_id) is a number from 0 to 99. It is used to identify established Bluetooth connections. 7.2. Starting the iWRAP Servers Normally, the iWRAP servers are started automatically upon power-up. You can restart the servers manually (for example, to apply the changes made to the iWRAP settings with the setup application without rebooting the system). To restart the servers manually, execute the startup script with option restart:

[root@wrap /] /etc/init.d/bluetooth restart When the iWRAP servers start up, they use the settings congured with the setup application. You can put additional iWRAP commands to the /etc/bluetooth.conf le. The commands in that le are processed as the last task every time the iWRAP server is started. 68 7.3. Writing iWRAP Applications There are two approaches when writing a iWRAP server program (a program accepting incom-

ing calls) for Access Server, both having different pros and cons:

1. Forklistener 2. iWRAP Client Note: When writing a client program (that is, a program making an outgoing call), you have to use iWRAP. 7.3.1. Forklistener This is a standard program reading data from standard input and writing output to standard output. See the SDK directory examples/forkserver/ for an example of this kind of program. Pros:

Easy to write. Very robust for simple services. You do not have to understand Bluetooth or iWRAP. Cons:

Your program is started and stopped for every incoming connection. If there are multiple connections, it is not possible to communicate to an external program through one socket. You cannot use stdout for debugging; you must use syslog or a log le. iWRAPs advanced features are not available: powermodes, MSC, SDP, inquiry, ... To setup a forklistener, see the SET command. 7.3.2. iWRAP Client iWRAP client is a program communicating with the iWRAP server through control and data sockets. See the SDK directory examples/btserver/ for an example of this kind of program. Pros:

The cons with forklistener do not apply. Cons:

More complex than forklistener. You must have basic knowledge about Bluetooth and iWRAP. For documentation about iWRAP, read this chapter carefully. 69 INFO 7.4. Commands Controlling iWRAP INFO INFO Get basic info Synopsis INFO Description INFO is used to retrieve version information on the iWRAP server, in the same format as pre-

sented by the READY. prompt when the iWRAP connection is opened. Reply READY. (wrap-2-1-0 $Revision: 1.28 $ bt1.2) 70 QUIT QUIT Close iWRAP connection Synopsis QUIT Description To close the connection to the iWRAP server, use the QUIT command. Reply There is no reply. Example READY. QUIT 71 SET SET Change parameters Synopsis SET [variable [value] ]

Description The SET command allows you to alter various Bluetooth and iWRAP parameters. The sup-

ported variables are listed in Table 7-1. Issuing a SET command without parameters lists the current settings. Variable BLUETOOTH BDADDR bdaddr BLUETOOTH NAME friendly_name You can set your Bluetooth friendly name with this Description Our bdaddr. This is a read-only value. command. Others can request this name with the NAME command. You can use the following meta characters:

$S: Hardware serial number, all ten digits

$s: Hardware serial number, last three digits

$P: Server port

$p: Server port, last digit

$H: FQDN

$h: hostname

$$: $

The default value is $S_$p. BLUETOOTH READABLE mode If enabled, some SDP result codes will have literal values instead of numeric values. 0: No (always use numeric values) 1: Yes (literal values) BLUETOOTH CLASS value You can set the class-of-device value with this command. 72 Variable BLUETOOTH LAP value BLUETOOTH ROLE role {policy

{timeout}}

BLUETOOTH ENCRYPT value SET Description You can set the IAC LAP value with this command. The default value is 9e8b33 You can set the master/slave role switch preference with this command. Optionally, you can also set the link policy and link supervision timeout. The possible values for "role" are:

0: allow calling, do not request when answering 1: allow calling, request when answering 2: do not allow calling, request when answering The default link policy is 000f and the default link su-

pervision timeout is 7d00. See Bluetooth Specication for more information on these parameters. This command denes whether to use Bluetooth encryption. To actually enable Bluetooth encryption, the connection must be authenticated. 0: No 1: Yes BLUETOOTH LAP value You can set the IAC LAP value with this command. The default value is 9e8b33 73 Variable BLUETOOTH PAGEMODE mode

{page_timeout

{page_repetition_mode

{scan_activity_interval scan_activity_window

{inquiry_activity_interval inquiry_activity_window}}}}

SET Description Pagemode denes whether other devices can nd and call you. There are four different modes:

0: No inquiry, no paging 1: Inquiry, no paging 2: No inquiry, paging 3: Inquiry and paging The page timeout is given in hex and the default value is 2000. The default page repetition mode is 2 (R2). The default scan activity is interval 0800 and window 0012

(R1). The default inquiry activity is interval 0800 and window 0012 (R1). See the Bluetooth Specication for more information on these parameters. BLUETOOTH AUTOHIDE physical logical This command automatically hides the baseband (sets pagemode to 0) if there are more physical ACL links or logical connections than dened. Value 0 means

"dont care". Default values: 7 0 BLUETOOTH AUTH * {authags}

BLUETOOTH AUTH * pin

{authags}

BLUETOOTH AUTH bdaddr

{authags}

This command removes the default PIN code. If you are making an outgoing connection and the remote end asks for the PIN, "1234" will be sent. This command sets the default PIN code. This command removes the PIN code for bdaddr. 74 Variable BLUETOOTH AUTH bdaddr pin

{authags}

Description This command sets the PIN code for bdaddr. Authags are:

SET

--NEWPAIR Only if we do not have linkkey yet

--REQUEST Request this PIN from remote, do not re-

ply with this one

--REPLY Reply to remote requests with this PIN

--CALL Only if making an outgoing call

--ANSWER Only when answering to an incoming call

--RFCOMM Call FORK/PPP/...) type is RFCOMM (includes

--BNEP Call type is BNEP

--L2CAP Call type is L2CAP Default authags are all enabled, except NEWPAIR. for

--

There are three special PINs:

- Reject without asking PIN.

-- Reject on the connection open, do not check for call types.

+ Accept without asking PIN. BLUETOOTH PAIR bdaddr linkkey With this command, you can manually set the linkkey for bdaddr. Note: SET BLUETOOTH AUTH must also be set for a value to enable encrypted connections with previously stored link keys. BLUETOOTH PAIR bdaddr With this command, you can manually delete the linkkey for bdaddr. BLUETOOTH PAIREXPIRE seconds With this command, you can set the expiration time, in seconds, for pairing information. 75 Variable BLUETOOTH LISTEN channel cmd

{mem {delay}}

SET Description This command adds a fork-listener for the channel. When there is an incoming RFCOMM connection to the channel, the iWRAP server handles the connection by itself by forking "cmd". At least "mem" kilobytes of free memory must be available, or the connection will be rejected. After forking, the iWRAP server waits for

"delay" timerticks (50ms) before transmitting any data. The client application must modify both the stdout and stdin pipes and set NOECHO, 8BIT and all other nec-

essary modes at the very beginning. The purpose of the "delay" parameter is to give the application enough time to do this. BLUETOOTH LISTEN channel host:port BLUETOOTH LISTEN psm L2CAP BLUETOOTH LISTEN channel This command adds a forward-listener for the channel. When there is an incoming RFCOMM connection to the channel, the iWRAP server will forward it to host:port by using a raw TCP/IP socket. This command adds an L2CAP listener for the psm. This command removes a fork/forward/L2CAP listener from the channel/psm. 76 Variable BLUETOOTH LINK mode params With this command, you can modify the slaves Description SET powermode according to the "mode". "params" are optional and mode-dependent. The possible values for "mode" are:

0: Active. Params: None. 1: Park: Round-robin. Params: max_beacon min_beacon sleep_after_unpark sleep_after_round Defaults: 254 160 5 30 Sleeps are specied by timerticks (50ms). 2: Park: Idle. Params: max_beacon min_beacon max_active Defaults: 512 384 6 max_active is the maximum number of active slaves. 3: Sniff: All. Params: max_interval min_interval attempt timeout Defaults: 640 426 1 8 4: Sniff: Idle. Params: idle_timeout max_interval min_interval at-

tempt timeout Defaults: 400 640 426 1 32 idle_timeout is in timerticks (50ms). See Bluetooth Specication for more information on params. 77 Variable BLUETOOTH QOS service_type token_rate peak_bandwidth latency delay_variation Description This command sets default QoS values for a new connection. The parameters are in hex. See Bluetooth Specication for more information on params. Defaults: 01 00000000 00000000 000061a8 ffffffff SET L2CAP TIMEOUT ushto linkto With this command, you can dene the FlushTimeout and LinkTimeout for L2CAP connections. See Bluetooth Specication for more information on params. PPP AUTH PPP AUTH username password PPP CHANNEL channel PPP DEFAULTROUTE value Defaults: 65535 40000 Do not require any PPP authentication on incoming connections. Require specied username:password on incoming PPP connections. Our PPP (LAN Access Prole) channel. The iWRAP server handles this channel internally. If you change this, remember to modify the SDP record as well. Use zero value to disable the LAN Access Prole. This setting controls whether the iWRAP server should modify the defaultroute setting. There are four different modes:

0: Do no alter defaultroute 1: Set defaultroute according to the outgoing PPP 2: Set defaultroute according to the incoming PPP 3: Set defaultroute according to all PPP calls PPP WINHANDSHAKE seconds PPP IP ipaddr/mask Timeout to wait for the Windows RAS handshake. This command sets the network IP range for PPP clients. 78 Variable PAN ENABLE bitmap CONTROL AUTOEXEC cmd CONTROL PASSWORD CONTROL PASSWORD pass

{--LOCAL}

CONTROL PING seconds CONTROL WRITETIMEOUT timeticks CONTROL AUTOSAVE what lename link_id MSC value link_id ACTIVE SET Description This command controls incoming PAN connections. Bitmap:

1: Allow incoming PAN-PANU connections. 2: Allow incoming PAN-GN connections. 4: Allow incoming PAN-NAP connections. 8: Enable zeroconf for incoming PAN-PANU connec-

tions. 16: Enable zeroconf for outgoing PAN-PANU connec-

tions. The default value "6" is recommended for most cases. Run the CALL command, and rerun it when the call is disconnected. Example: SET CONTROL AUTOEXEC CALL bdaddr PAN-NAP PAN-NAP Do not require a password from iWRAP clients. Enable password. iWRAP clients must send this password before giving any other command. The password is case sensitive. With an optional --LOCAL parameter, clients connect-

ing from localhost are accepted without a password. If this setting is enabled (seconds > 0), the iWRAP server sends a PING reply to all iWRAP clients. You have to reply to it with PONG or the connection will be closed. With this command, you can set in timeticks (1/20s) how long iWRAP tries to write to the datasocket if its blocked before giving up and closing the connections. If this setting is enabled, the system automatically saves settings to a le when they change. See the SAVE command for possible "what" values. Set MSC for link_id to value. See ETSI TS 101 369

(GSM 07.10) for more information. With this command, you can set the powermode for a link_id to active. 79 Variable link_id PARK params link_id HOLD params SET Description With this command, you can set the powermode for link_id park. Required "params" are:

avg_beacon or max_beacon min_beacon See Bluetooth Specication for more information on params. With this command, you can set the links powermode to hold. Required "params" are:

avg max min See Bluetooth Specication for more information on params. link_id SNIFF params With this command, you can set the powermode for a link_id to sniff. Required "params" are:

avg_interval or max_interval min_interval or max_interval min_interval attempt or max_interval min_interval attempt timeout The default attempt is 1, the default timeout is 8. See Bluetooth Specication for more information on params. link_id QOS service_type token_rate peak_bandwidth latency delay_variation With this command, you can set the links QoS values. The parameters are in hex. See Bluetooth Specication for more information on params. link_id MASTER link_id SLAVE Table 7-1. Supported Parameters for iWRAP SET Command With this command, you can switch the role to master. With this command, you can switch the role to slave. 80 Reply When there are parameters, there is no reply. Example READY. SET BLUETOOTH NAME Buffy SET BLUETOOTH PAGEMODE 3 SET BLUETOOTH READABLE 1 SET BLUETOOTH CLASS 020300 SET BLUETOOTH ROLE 0 SET BLUETOOTH ENCRYPT 0 SET BLUETOOTH PAGEMODE 3 SET BLUETOOTH AUTH * 1234 SET BLUETOOTH AUTH 00:07:80:80:bf:01 4242 SET BLUETOOTH AUTH *

SET BLUETOOTH PAIREXPIRE 600 SET BLUETOOTH LISTEN 1 /bin/login 200 SET BLUETOOTH LISTEN 2 "my/own/command with parameters" 100 5 SET BLUETOOTH LISTEN 3 SET PPP DEFAULTROUTE 0 SET PPP AUTH buffy willow SET PPP AUTH SET PPP CHANNEL 4 SET PPP WINHANDSHAKE 10 SET PPP IP 192.168.166.0/24 SET 0 MSC 8d SET CONTROL PING 60 PING PONG SET CONTROL PASSWORD SET CONTROL PASSWORD buffy

<client reconnects>

READY. SET ERROR PASSWORD NEEDED.

<client reconnects>

READY. buffy SET SET BLUETOOTH BDADDR 00:07:80:80:bf:01 SET BLUETOOTH NAME Buffy SET PPP AUTH SET CONTROL PASSWORD buffy SET SET 81 SAVE SAVE Save iWRAP settings Synopsis SAVE {what} {lename}

Description The SAVE command writes the current settings to a le. What AUTH PAIR BTSET OTHERSET ALL Table 7-1. SAVE parameters Settings SET BLUETOOTH AUTH ... SET BLUETOOTH PAIR ... SET BLUETOOTH ..., but not AUTH or PAIR All but SET BLUETOOTH Everything Reply There is no reply. Example READY. SAVE PAIR /etc/bluetooth.pair SAVE AUTH,PAIR /etc/bluetooth.security 82 LOAD LOAD Run iWRAP command script Synopsis LOAD {lename}

Description The LOAD command runs commands from a le. This command is usually used with SAVE or SET CONTROL AUTOSAVE commands. Reply There is no reply. Example READY. LOAD /etc/bluetooth.security SET CONTROL AUTOSAVE AUTH,PAIR /etc/bluetooth.security 83 PING PING Ask if the connection is alive Synopsis PING Description The PING command can be used to check that the connection to the iWRAP server is alive. The iWRAP can also send the PING to the client application. In that case, you must reply with the PONG command. Reply PONG Example READY. PING PONG PING PONG 84 PONG PONG Connection is alive Synopsis PONG Description The PONG command has to be sent back if you see a PING reply from the server. If you do not answer, the connection will be closed after a few seconds. Reply There is no reply. Example READY. PING PONG 85 ECHO ECHO Send a message to other iWRAP clients Synopsis ECHO {data}

Description This command broadcasts its parameters to all iWRAP connections, including the one that sent the command. Reply ECHO data Example READY. ECHO Hello world!

ECHO Hello world!

86 LOCK LOCK Lock other iWRAP clients Synopsis LOCK Description This command locks all other iWRAP connections, allowing commands only from this one. This includes all the PINGs and PONGs too. Be polite and do not lock it for a long time. Reply There is no reply. Example READY. LOCK UNLOCK 87 UNLOCK UNLOCK Unlock other iWRAP clients Synopsis UNLOCK Description This command opens the lock created by using the LOCK command. Reply There is no reply. Example READY. LOCK UNLOCK 88 SHUTDOWN SHUTDOWN Close iWRAP server Synopsis SHUTDOWN Description To close the iWRAP server, you can use the SHUTDOWN command. This also immediately closes all active connections. Reply There is no reply. Example READY. SHUTDOWN 89 SLEEP SLEEP Wait a second Synopsis SLEEP {seconds}

Description The SLEEP command waits for a specied number of seconds before processing further com-

mands. SLEEP is only usable in rc scripts (/etc/bluetooth.conf). Reply There is no reply. Example READY. SLEEP 4 90 7.5. Finding Bluetooth Devices INQUIRY INQUIRY Search for other devices Synopsis INQUIRY [timeout] [NAME] [LAP {lap}]

Description The INQUIRY command is used to search for other Bluetooth devices. The timeout is dened in units of 1.25 seconds. The default timeout is 4 units. If an optional NAME parameter is provided, the NAME command will be automatically sent to all found devices. The LAP option species the used IAC LAP; the default value is 9e8b33 (GIAC). During the inquiry, all devices are listed as soon as they are found by using INQUIRY_PARTIAL replies. If the iWRAP server has cached the friendly name of the device found, it is also dis-

played. When the inquiry times out, a summary is displayed indicating how many devices were found. The summary also repeats the device information. Warning Do not use the NAME parameter in your program. It is for manual testing only. Use separate NAME commands instead. Reply INQUIRY_PARTIAL bdaddr_of_dev_1 class_of_dev_1 "friendly name" rssi INQUIRY_PARTIAL bdaddr_of_dev_2 class_of_dev_2 "friendly name" rssi

... INQUIRY_PARTIAL bdaddr_of_dev_n class_of_dev_n "friendly name" rssi INQUIRY number_of_devices_found INQUIRY bdaddr_of_dev_1 class_of_dev_1 "friendly name"

INQUIRY bdaddr_of_dev_2 class_of_dev_2 "friendly name"

... INQUIRY bdaddr_of_dev_n class_of_dev_n "friendly name"

Example READY. INQUIRY 10 INQUIRY 0 INQUIRY INQUIRY_PARTIAL 00:07:80:80:bf:01 120300 "willow" 255 INQUIRY_PARTIAL 00:07:80:80:bf:02 520204 "" 255 INQUIRY 2 INQUIRY 00:07:80:80:bf:01 120300 "willow"

INQUIRY 00:07:80:80:bf:02 520204 ""

91 INQUIRY 92 NAME NAME Find a friendly name Synopsis NAME {bdaddr}

Description You can ask for the friendly name of another Bluetooth device with the NAME command. Reply NAME bdaddr "friendly name"

NAME ERROR bdaddr reason_code more_info Example READY. NAME 00:07:80:80:bf:02 NAME 00:07:80:80:bf:02 "buffy"

NAME 00:07:80:80:bf:01 NAME ERROR 00:07:80:80:bf:01 108 HCI_ERR_PAGE_TIMEOUT 93 7.6. Making a Bluetooth Connection CALL CALL Connect to other device Synopsis CALL {bdaddr} SDP CALL {bdaddr} {psm} L2CAP CALL {bdaddr} {channel} RFCOMM CALL {bdaddr} {uuid} RFCOMM CALL {bdaddr} {channel} PPP [username password]

CALL {bdaddr} {uuid} PPP [username password]

CALL {bdaddr} {channel} WINPPP [username password]

CALL {bdaddr} {uuid} WINPPP [username password]

CALL {bdaddr} {channel} FORK {"/full/path/to/command and parameters"}

CALL {bdaddr} {uuid} FORK {"/full/path/to/command and parameters"}

CALL {bdaddr} {channel} FORK {host:port}

CALL {bdaddr} {uuid} FORK {host:port}

CALL {bdaddr} {PAN-destUUID} [PAN-srcUUID]

Description The CALL command is used to make a connection to other Bluetooth devices. It returns the link identier (with an immediate reply), which will be used in subsequent commands and replies. Note: Always check for a correct link_id before processing replies further. You can use the special FORK call type to create an RFCOMM connection and automatically launch an application, which gets the RFCOMM connection bound to its standard input and output. The client application should modify both the stdout and stdin pipes and set NOECHO, 8BIT and all other necessary modes at the very beginning. Note: There can only be one pending CALL at a time. You have to wait for the RINGING event before issuing another CALL. The RINGING event comes almost immediately after the CALL. You get the ERROR 008 error if you try to establish another call too quickly. In that case, wait for some tens of milliseconds and retry. Receiving the CONNECT or NO CARRIER reply may take some time, for example, when the user is keying in the PIN code. Note: PPP is "raw" PPP without any special handshaking. WINPPP is a Windows RAS handshake followed by raw PPP. If you are unsure, use WINPPP. Reply CALL link_id RINGING link_id 94 Example READY. CALL 00:07:80:80:bf:01 SDP CALL 0 RINGING 0 CONNECT 0 SDP CALL 00:07:80:80:bf:01 4 PPP CALL 1 RINGING 1 CONNECT 1 PPP CALL NameOfOtherDevice LAN PPP CALL 1 RINGING 1 CONNECT 1 PPP CALL 00:07:80:80:bf:02 4 WINPPP buffy willow CALL 2 RINGING 2 CONNECT 2 PPP CALL 00:07:80:80:bf:01 1 RFCOMM CALL 3 RINGING 3 CONNECT 3 RFCOMM 1042 CALL 00:07:80:80:bf:01 2 FORK /bin/login CALL 4 RINGING 4 CONNECT 4 FORK CALL 00:07:80:80:bf:01 PAN-NAP CALL 5 RINGING 5 CONNECT 5 PAN-NAP CALL 00:07:80:80:bf:02 PAN-NAP PAN-NAP CALL 6 RINGING 6 CONNECT 6 PAN-NAP CALL 00:07:80:80:bf:02 2 FORK 127.0.0.1:23 CALL 7 RINGING 7 CONNECT 7 FORK CALL 95 CONNECT CONNECT Connected to other device Synopsis This is not a command. Description CONNECT is not a command, but rather a reply broadcast to you when CALL successfully estab-

lishes the connection. Remember to check that the link_id matches your CALL. On RFCOMM/L2CAP connections, there is an additional parameter called port. Port refers to the TCP socket port number, which is used to send and receive data to and from the remote device. Connect to the port just like you connected to the iWRAP server. The connection is

"raw", which means that no processing of incoming or outgoing data is made. Note: In the case of L2CAP connections, the data is handled as packets. Therefore, both the incoming and outgoing data must follow the "HDR+L2CAPDATA" format, where HDR is two bytes; rst the low byte, and then the high byte of the L2CAPDATA packet length. L2CAPDATA contains the actual L2CAP packet. Reply CONNECT link_id SDP CONNECT link_id RFCOMM port CONNECT link_id L2CAP port CONNECT link_id PPP CONNECT link_id FORK CONNECT link_id PAN-PANU CONNECT link_id PAN-GN CONNECT link_id PAN-NAP Example READY. CALL 00:07:80:80:bf:01 SDP CALL 0 RINGING 0 CONNECT 0 SDP CALL 00:07:80:80:bf:01 LAN PPP CALL 1 RINGING 1 CONNECT 1 PPP CALL 00:07:80:80:bf:01 1 RFCOMM CALL 2 RINGING 2 CONNECT 2 RFCOMM 1042

<Client can open socket connection to port 1042>

96 CONNECT CALL 00:07:80:80:bf:01 2 FORK /bin/login CALL 3 RINGING 3 CONNECT 3 FORK CALL 00:07:80:80:bf:01 PAN-NAP CALL 5 RINGING 5 CONNECT 5 PAN-NAP CALL 00:07:80:80:bf:02 PAN-NAP PAN-NAP CALL 6 RINGING 6 CONNECT 6 PAN-NAP 97 NO CARRIER NO CARRIER Disconnected from other device Synopsis This is not a command. Description The NO CARRIER reply indicates that you or the remote device closed the active connection, or that your CALL failed for some reason. See Section 7.9 for the list of error codes. Field "more_info" is optional. If present, it gives you a human readable error code or some statistics about the closed connection. Reply NO CARRIER link_id ERROR reason NO CARRIER link_id Example READY. CALL 00:07:80:80:bf:01 4 PPP CALL 0 RINGING 0 NO CARRIER 0 ERROR 104 HCI_ERR_PAGE_TIMEOUT CALL 00:07:80:80:bf:01 1 RFCOMM CALL 1 RINGING 0 CONNECT 1 RFCOMM 1042 NO CARRIER 1 ERROR 000 IN=42,OUT=66,ELAPSED=69 98 RING RING Another device is calling you Synopsis This is not a command. Description The RING reply indicates an incoming call from a remote device. As with CONNECT, on RF-

COMM/L2CAP calls there is an additional "port" parameter. Open a socket to the port, if you want to serve this call. PPP and PAN calls are handled internally, which means that you do not have to do anything on them. The iWRAP server closes the connection if nobody grabs the call within 30 seconds. Special call type REJECTED is used for information only. It is used if somebody tried to call you but was rejected, usually because of failing authentication. Reply RING link_id bdaddr channel PPP RING link_id bdaddr channel RFCOMM port RING link_id bdaddr psm L2CAP port RING link_id bdaddr PAN-PANU RING link_id bdaddr PAN-GN RING link_id bdaddr PAN-NAP RING link_id bdaddr REJECTED Example READY. RING 0 00:07:80:80:bf:01 4 PPP RING 1 00:07:80:80:bf:01 1 RFCOMM 1042

<Client can open socket connection to port 1042>

RING 2 00:07:80:80:bf:01 PAN-GN 99 RINGING RINGING Call in progress Synopsis This is not a command. Description The RINGING reply indicates that a previously initiated outgoing CALL is in the state where a new outgoing CALL can be made. Reply RINGING link_id Example READY. CALL 1 00:07:80:80:bf:01 1 RFCOMM

<Making new CALL is not allowed but generates BUSY error>

CALL 1

<Making new CALL is not allowed but generates BUSY error>

RINGING 1

<Making new CALL is allowed>

CALL 2 00:07:80:80:bf:02 2 RFCOMM

<Making new CALL is not allowed but generates BUSY error>

CALL 2

<Making new CALL is not allowed but generates BUSY error>

RINGING 2

<Making new CALL is allowed>

CONNECT 1 RFCOMM 1042

<Client can open socket connection to port 1042>

CONNECT 2 RFCOMM 1043

<Client can open socket connection to port 1043>

100 CLOSE CLOSE Disconnect Synopsis CLOSE {link_id}

Description The CLOSE command closes an active connection started with a CONNECT or RING. Note that closing the RFCOMM data socket connection also closes the Bluetooth connection. Reply There is no direct reply. NO CARRIER is replied when the connection actually closes. Example READY. CALL 00:07:80:80:bf:01 4 PPP CALL 1 RINGING 1 CONNECT 1 PPP CLOSE 1 NO CARRIER 1 ERROR 000 101 LIST LIST List connections Synopsis LIST Description The LIST command reports active connections and some statistics. Reply LIST number_of_connections LIST link_id status type blocksize bytes_in bytes_out elapsed_time our_msc remote_msc bdaddr channel direction powermode role crypt child_pid hcihandle LIST link_id status type blocksize bytes_in bytes_out elapsed_time our_msc remote_msc bdaddr channel direction powermode role crypt child_pid hcihandle

... LIST link_id status type blocksize bytes_in bytes_out elapsed_time our_msc remote_mscbdaddr channel direction powermode role crypt child_pid hcihandle Reply Values Status values are:

WAITING. The iWRAP server is waiting for someone to connect to the datasocket created with the RFCOMM CONNECT or RING event. CONNECTED. The data connection is up and running. CLOSING. The datasocket has been closed, and the Bluetooth connection shutdown is in progress. Type is SDP, RFCOMM, PPP, PAN-PANU, PAN-GN, PAN-NAP, FORK or L2CAP. Blocksize is the maximum transfer unit of the Bluetooth link; used for statistics only. Bytes_in and bytes_out refer to the numbers of bytes transferred. Elapsed_time is the number of seconds the connection has been up. Msc is the links MSC value for both ends. Bdaddr is the Bluetooth address of the connected device. Channel is the service channel of the connection. Direction is either OUTGOING or INCOMING. Powermode is ACTIVE, SNIFF, PARK or HOLD. Role is MASTER or SLAVE. Crypt is PLAIN or ENCRYPTED. Child_pid is the child process ID for types PPP and FORK. The PID is zero for others. 102 LIST Hcihandle is the HCI handle for this connection. Example READY. LIST LIST 1 LIST 0 CONNECTED RFCOMM 666 4242 100 30 8d 8d 00:07:80:80:bf:01 4 OUTGOING ACTIVE MASTER PLAIN 0 2a 103 STATUS STATUS Status of a connection Synopsis This is not a command. Description The STATUS reply is used to inform you about changes in connection status. See also the SET command. Reply STATUS link_id MSC value Example READY. STATUS 0 MSC 8d 104 7.7. Service Discovery This section describes the commands used for Bluetooth service discovery and local SDP record manipulation. The commands and their replies use SDP UUID and attribute values, which are listed in the Bluetooth Assigned Numbers documentation. In the commands below, the most useful UUID and attribute values can, however, be replaced with keywords listed in Table 7-3. The same keywords are used in the command replies instead of numeric values, if the parameter SET BLUETOOTH READABLE is set to 1. Keyword(s) SDP RFCOMM OBEX BNEP L2CAP PUBLICBROWSEGROUP, BROWSE, ROOT SERIALPORT, SPP LANACCESS, LAN DIALUPNETWORKING, DUN OBEXOBJECTPUSH, OBJP, OPP OBEXFILETRANSFER, FTP PAN-PANU, PANU PAN-NAP, NAP PAN-GN, GN PROTOCOLDESCRIPTORLIST, DESCLIST, DESC SERVICENAME, NAME Value UUID_SDP UUID_RFCOMM UUID_OBEX UUID_BNEP UUID_L2CAP UUID_PUBLIC_BROWSE_GROUP Hex Value 0001 0003 0008 000F 0100 1002 1101 UUID_SERIALPORT 1102 UUID_LANACCESS 1103 UUID_DIALUPNETWORKING 1105 UUID_OBEXOBJECTPUSH 1106 UUID_OBEXFILETRANSFER 1115 UUID_PANU 1116 UUID_NAP 1117 UUID_GN ATTR_PROTOCOLDESCRIPTORLIST 0004 ATTR_SERVICENAME +

BASE_LANG_OFFSET SECURITYDESCRIPTION ATTR_SECURITYDESCRIPTION NETACCESSTYPE ATTR_ NETACCESSTYPE MAXNETACCESSRATE ATTR_ MAXNETACCESSRATE Table 7-3. Supported Keywords for Replacing SDP UUIDs or Attributes 0000 +

0100 030A 030B 030C SDPSEARCH SDPSEARCH Browse SDP Records Synopsis SDPSEARCH {link_id} {uuid}

Description The SDPSEARCH command is used to send a Service Search Request to a connected SDP server, 105 identied with link_id. The command only supports searching for one UUID at a time (specied with the uuid parameter, 4 hex digits, or with a keyword), but several requests can be sent during the same SDP connection. However, you must wait for the reply to the previous reply before issuing a new SDPSEARCH command. SDPSEARCH Reply SDPSEARCH link_id number_of_handles SDPSEARCH link_id handle_1 SDPSEARCH link_id handle_2

... SDPSEARCH link_id handle_n Example READY. CALL 00:07:80:80:bf:01 SDP CALL 0 RINGING 0 CONNECT 0 SDP SDPSEARCH 0 LANACCESS SDPSEARCH 0 1 SDPSEARCH 0 00010000 CLOSE 0 NO CARRIER 0 ERROR 000 106 SDPATTR SDPATTR Browse SDP Records Synopsis SDPATTR {link_id} {handle} {attribute}

Description The SDPATTR command is used to send a Service Attribute Request to a connected SDP server, identied with the link_id. The command supports requesting for one attribute value (specied with the attribute parameter, 4 hex digits, or a keyword) in one previously retrieved service entry (specied with the handle parameter, 8 hex digits), but several requests can be sent during the same SDP connection. However, you must wait for the reply to the previous reply before issuing a new SDPATTR command. The reply contains the response from the SDP server in encoded form. The code characters are described in Table 7-1. Char I I U Description Unsigned integer (2, 4, or 8 hexadecimal digits) follows. This is often a handle, attribute, or attribute value. Attribute values are shown as text if BLUETOOTH READABLE is set to 1. Signed integer byte (2 hexadecimal digits) follows. UUID (4 or 8 hexadecimal digits) follows. Shown as text if BLUETOOTH READABLE is set to 1. String follows. Boolean follows. Start of sequence. End of sequence. Alternative follows. Universal Resource Locator follows. S B

<

>

A R Table 7-1. SDP Response Formatting Characters Reply SDPATTR link_id info Example READY. CALL 00:07:80:80:bf:01 SDP CALL 0 CONNECT 0 SDP SDPSEARCH 0 LAN SDPSEARCH 0 1 SDPSEARCH 0 00010000 SDPATTR 0 00010000 DESCLIST 107 SDPATTR 0 < I 0004 < < U 0100 > < U 0003 I 04 > > >

CLOSE 0 NO CARRIER 0 ERROR 000 SDPATTR 108 SDPQUERY SDPQUERY Browse SDP Records Synopsis SDPQUERY {link_id} {uuid} {attribute}

Description The SDPQUERY command is used to send a Service Search Attribute Request to a connected SDP server, identied with the link_id. The command supports requesting for one attribute value (specied with the attribute parameter, 4 hex digits, or a keyword) in all service entries containing one UUID (specied with the uuid parameter, 4 hex digits, or a keyword), but several requests can be sent during the same SDP connection. However, you must wait for the reply to the previous reply before issuing a new SDPQUERY command. Reply SDPQUERY link_id info Example READY. CALL 00:07:80:80:bf:01 SDP CALL 0 RINGING 0 CONNECT 0 SDP SDPQUERY 0 LAN DESCLIST SDPQUERY 0 < < I 0004 < < U 0100 > < U 0003 I 04 > > > >

SDPQUERY 0 1102 0100 SDPQUERY 0 < < I 0100 S "Lan Access using PPP" > >

CLOSE 0 NO CARRIER 0 ERROR 000 109 SDP bdaddr SDP bdaddr Check devices SDP Synopsis SDP {bdaddr} {uuid}

Description The SDP bddaddr command is the most useful command for retrieving SDP information from the remote device. The command opens the SDP connection, makes the SDP query, closes the connection and replies to the client in encrypted form. The format is described with the SD-

PATTR command. Reply SDP bdaddr 0 ERROR reason SDP bdaddr number_of_entries SDP bdaddr info SDP bdaddr info

... SDP bdaddr info Example READY. SDP 00:07:80:80:bf:01 SERIALPORT SDP 00:07:80:80:bf:01 1 SDP 00:07:80:80:bf:01 < I SERVICENAME S "Serial Port" >

< I PROTOCOLDESCRIPTORLIST < < U 0100 > < U RFCOMM I 0b > > >

110 SDP ADD SDP ADD Add entry to local SDP Synopsis SDP ADD {uuid [:uuid2]} {channel} {description}

Description This command adds a new entry to Access Servers SDP record. Reply SDP handle SDP handle ERROR reason Example READY. SDP ADD LANACCESS 4 "Lan access"

SDP 65536 SDP ADD SERIALPORT 10 "Serial port"

SDP 65537 SDP ADD PAN-NAP 0 "PAN Network Access Point"

SDP 65538 SDP ADD L2CAP:1201 4099 "Private L2CAP for networking"

SDP 65539 111 SDP DEL SDP DEL Delete entry for local SDP Synopsis SDP DEL {handle}

Description This command deletes one entry from Access Servers SDP record. Reply There is no reply. Example READY. SDP DEL 65537 112 SDP LIST SDP LIST List local SDP Synopsis SDP LIST Description This command lists Access Servers SDP record entries. Reply SDP number_of_entries SDP handle uuid channel description SDP handle uuid channel description

... SDP handle uuid channel description Example READY. SDP LIST SDP 1 SDP 65536 LANACCESS 4 "Lan access"

113 7.8. Example Sessions Outgoing RFCOMM Call:

Chapter 7. iWRAP - Bluetooth Interface READY. CALL 00:07:80:80:bf:01 1 RFCOMM CALL 2 RINGING 2 CONNECT 2 RFCOMM 1042 STATUS 2 MSC 8d

<Client opens socket connection to port 1042 and transfers data>

CLOSE 2 NO CARRIER 2 ERROR 000 Incoming RFCOMM Call:

READY. RING 2 00:07:80:80:bf:01 1 RFCOMM 1042 STATUS 2 MSC 8d

<Client opens socket connection to port 1042 and transfers data>

NO CARRIER 2 ERROR 000 7.9. Error Codes Some commands may reply with an error code. The human-readable name of the error is dis-

played, if the SET BLUETOOTH READABLE setting has value 1. Error code 8 indicates that the iWRAP server is busy executing a number of commands; there can be several client applications using the stack. Just wait a few seconds and try again. Other error codes indicate unexpected, but often only temporary, communication problems. You can analyze the error from the numeric code. Values bigger than or equal to 900 are iWRAP errors, described in Table 7-5. Code 900 Textual Form SERVICE_NOT_FOUND 901 902 903 904 905 ALREADY_CONNECTED OUT_OF_HANDLES INVALID_ADDRESS_<addr>

REJECTED BUSY Reason Tried to CALL a device whose SDP records do not include the requested service. Tried to CALL a device and a service channel that is already connected. Tried to CALL, but there are too many open connections. Tried to CALL a device with a friendly name that could not be found with the inquiry. An incoming call was rejected by the iWRAP server. Tried to issue SDPATTR, but another SDP request was in progress. 114 Code 906 Textual Form BUSY 907 908 909 90a NOT_CONNECTED BUSY INVALID_ADDRESS BUSY Chapter 7. iWRAP - Bluetooth Interface Reason Tried to issue SDPQUERY, but another SDP request was in progress. Tried to CLOSE a connection handle that is not active. Tried to issue SDPSEARCH, but another SDP request was in progress. Tried to NAME a device with a friendly name that cannot be found with the inquiry. Tried to issue NAME, but another NAME was in progress. Table 7-5. iWRAP Errors Other error codes can be analyzed as follows. For example, NO CARRIER ERROR 465: The num-

ber 465 is hexadecimal, the sum of 0x400 and 0x65, where 0x400 is a mask, which means that this is an RFCOMM level error. 0x65 (decimal 101) means that the RFCOMM error was a connection timeout. Mask 0x100 0x200 0x300 0x400 Table 7-6. Errors Masks The error codes for each mask are listed in the following tables. Error level HCI L2CAP SDP RFCOMM HCI Error HCI_SUCCESS HCI_ERR_UNKNOWN_COMMAND HCI_ERR_NOCONNECTION HCI_ERR_HARDWARE_FAIL HCI_ERR_PAGE_TIMEOUT HCI_ERR_AUTHENTICATION_FAILED HCI_ERR_KEY_MISSING HCI_ERR_MEMORY_FULL HCI_ERR_CONNECTION_TIMEOUT HCI_ERR_MAX_NUM_CONNECTIONS HCI_ERR_MAX_NUM_SCO_CONNECTIONS HCI_ERR_ACL_CONN_ALREADY_EXISTS HCI_ERR_COMMAND_DISALLOWED Code 0 1 2 3 4 5 6 7 8 9 10 11 12 115 HCI Error HCI_ERR_HOST_REJECTED_0D HCI_ERR_HOST_REJECTED_0E HCI_ERR_HOST_REJECTED_0F HCI_ERR_HOST_TIMEOUT HCI_ERR_UNSUPPORTED_PARAM_VALUE HCI_ERR_INVALID_HCI_PARAMETER_VALUE HCI_ERR_OTHER_END_TERMINATE_13 HCI_ERR_OTHER_END_TERMINATE_14 HCI_ERR_OTHER_END_TERMINATE_15 HCI_ERR_CONNECTION_TERMINATE_LOCALLY HCI_ERR_REPEATED_ATTEMPTS HCI_ERR_PARING_NOT_ALLOWED HCI_ERR_UNKNOWN_LMP_PDU HCI_ERR_UNSUPPORTED_REMOTE_FEATURE HCI_ERR_SCO_OFFSET_REJECTED HCI_ERR_SCO_INTERVAL_REJECTED HCI_ERR_SCO_AIR_MODE_REJECTED HCI_ERR_INVALID_LMP_PARAMETERS HCI_ERR_UNSPECIFIED_ERROR HCI_ERR_UNSUPPORTED_LMP_PARAMETER_VAL HCI_ERR_ROLE_CHANGE_NOT_ALLOWED HCI_ERR_LMP_RESPONSE_TIMEOUT HCI_ERR_LMP_ERROR_TRANSACTION_COLLISION HCI_ERR_LMP_PDU_NOT_ALLOWED HCI_ERR_ENCRYPTION_MODE_NOT_ACCEPTABLE HCI_ERR_UNIT_KEY_USED HCI_ERR_QOS_NOT_SUPPORTED HCI_ERR_INSTANT_PASSED HCI_ERR_PAIRING_WITH_UNIT_KEY_NOT_SUPP HCI_ERR_ILLEGAL_HANDLE HCI_ERR_TIMEOUT HCI_ERR_OUTOFSYNC HCI_ERR_NO_DESCRIPTOR Table 7-7. HCI Error Codes L2CAP Error L2CAP_NO_CAUSE L2CAP_ERR_PENDING L2CAP_ERR_REFUS_INV_PSM Chapter 7. iWRAP - Bluetooth Interface Code 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 100 101 102 103 Code 0 1 2 116 Chapter 7. iWRAP - Bluetooth Interface Code 3 4 0xee L2CAP Error L2CAP_ERR_REFUS_SEC_BLOCK L2CAP_ERR_REFUS_NO_RESOURCE L2CAP_ERR_TIMEOUT_EXTERNAL Table 7-8. L2CAP Error Codes SDP Error SDP_ERR_RESERVED SDP_ERR_UNSUPPORTED_SDP_VERSION SDP_INVALID_SERVICE_RECORD_HANDLE SDP_INVALID_REQUEST_SYNTAX SDP_INVALID_PDU_SIZE SDP_INVALID_CONTINUATION_STATE SDP_INSUFFICIENT_RESOURCES SDP_ERR_UNHANDLED_CODE SDP_ERR_TIMEOUT SDP_ERR_NOTFOUND SDP_INVALID_RESPONSE_SYNTAX SDP_NOT_FOUND (not really an error) Table 7-9. SDP Error Codes RFCOMM Error RFCOMM_SUCCESS RFCOMM_ERR_NORESOURCES RFCOMM_ERR_ILL_PARAMETER RFCOMM_ERR_REJECTED (Connection setup was rejected by remote side) RFCOMM_ERR_TIMEOUT (Connection timed out) RFCOMM_ERR_NSC (Non supported command received) RFCOMM_ERR_ILLPARAMETER Table 7-10. RFCOMM Error Codes If the problems persist after restarting the communication parties, please contact Bluegiga Tech-

nologies as instructed in Section 1.2. Code 0 1 2 3 4 5 6 100 101 102 103 200 Code 0 1 2 100 101 102 103 117 Chapter 8. I/O API The Bluegiga I/O API denes how to access Access Servers LEDs, buzzer, and general purpose I/O. 8.1. Led and Buzzer API Access Servers LEDs and buzzer can be accessed through the /dev/led device. You can check the status of the LEDs and the buzzer with the cat /dev/led command and set LEDs or the buzzer with the echo abcde > /dev/led command. An upper case letter means that the LED or buzzer is ON, a lower case letter means that the LED or buzzer is OFF. Letter "a" is the buzzer, letters

"b".."e" are LEDs 1..4. Example:

[root@wrap /] echo abCDe > /dev/led 8.2. GPIO API The Digital I/O pins of Access Server can be controlled write-only by using the /dev/io device in the same way as the /dev/led device for LEDs and buzzer described above. The letter-to-I/O mapping of the 16 pins is as follows, when looking at the connector:

hgfedcba Xijklmno X is the ground pin (and cannot be set). o is the voltage sense pin (user can use any voltage from 3.3V to 5.0V). The I/O must rst be enabled by using the echo Z > /dev/io command. After that, pins can be driven up by echoing the corresponding upper case letter (A-N) or down by echoing a lower case letter (a-n) to the /dev/io device. Example:

[root@wrap /] echo ZaBcD > /dev/io 118 Chapter 9. Advanced Use Cases for Access Server This chapter will give you advanced use cases for Access Server. The cases listed here are not so trivial, the simple cases are already listed mostly in Chapter 7. 9.1. Making Access Server Secure TBA 9.2. Saving Bluetooth Pairing Information Permanently By default, Access Server discards pairing information after 30 minutes and does not store pair-

ing data permanently. Therefore, rebooting of Access Server removes all pairing information. To increase the pairing data timeout and to automatically store the pairing data to the per-

manent storage and to automatically reload the information at reboot, append the following iWRAP commands to the end of /etc/bluetooth.conf le (Setup Bluetooth settings Edit startup script in WWW Setup):

# Set pairing data timeout to ~370 days (in seconds)

# Note: timeout counter is restarted at reboot SET BLUETOOTH PAIREXPIRE 32000000

# Automatically load the pairing data LOAD /etc/bluetooth.security$p

# Automatically save the pairing data SET CONTROL AUTOSAVE AUTH,PAIR /etc/bluetooth.security$p Note: Do not forget $p from the lename. It is replaced with the Bluetooth baseband number. On a multiradio Access Server, forgetting it will make the security data to be overwritten by the other Bluetooth processes. Note: Pairing must be done between each Bluetooth device pairs. There is no way of making a single pairing between a device and all three basebands of the WRAP 2293 Access Server. 9.3. Digital Pen Access Server will support most of the digital pens. The examples below are for Nokia Digital Pen SU-1B but they should apply to other pens too. To setup Access Server for digital pens you have to give following iWRAP commands. The best way to do this is to append the following line to /etc/bluetooth.conf le (Setup Bluetooth settings Edit startup script in WWW Setup):

# Load Digital Pen emulation commands LOAD /etc/bluetooth.pen The /etc/bluetooth.pen must then be created (in WWW Setup, you can do it at Setup Advanced settings Edit other conguration les). It should contain the lines following the example below:

# Emulate a phone SET BLUETOOTH CLASS 500204 119 Chapter 9. Advanced Use Cases for Access Server SET BLUETOOTH LISTEN 1 "*/usr/sbin/dun"

SDP ADD DUN 1 "Digital Pen DUN"

# Add two pens and their pin codes SET BLUETOOTH AUTH 00:07:cf:51:f6:8e 9079 --REPLY SET BLUETOOTH AUTH 00:07:cf:51:d5:2b 6603 --REPLY

# Note: See pens manual for correct bluetooth address and pin code

# Optionally reject all other incoming connections SET BLUETOOTH AUTH * - --NEWPAIR After these settings you can pair and use the digital pen with Access Server just like you would use it with a phone. Both modes, receiving pictures to Access Server, and external server via dialup, are supported. 9.4. OpenVPN This chapter explains how to create a secure network between your Access Server and a PC running Windows OS. This is done using Virtual Private Networking (VPN) and the particular software in use is OpenVPN, which is open source software and is available for everyone with-

out charge. VPN creates a secure tunnel between Access Server and a PC, which enables you, for example, to control a GPRS connected Access Server in a remote location. 9.4.1. Prerequisites First, download OpenVPN from http://openvpn.se. A normal OpenVPN version using plain command line interface is available in http://openvpn.net/download.html. The basic instruc-

tions naturally apply for both versions, since the actual software is the same. OpenVPN GUI is only available for Windows OS. For Access Server, you must download the OpenVPN installation packet from www.bluegiga.com/techforum. If you do not have access to the Tech forum, you can apply for access in the same site. In the Tech forum, go to Access Server -> Downloads, where you can nd the installation packet called openvpn-2.0.8-1.wpk. Access Server is a Linux system, and only command line interface is provided at this point. This guide relies on material provided in http://openvpn.net/. If you want more specic information on features described here or other features OpenVPN provides, please visit http://openvpn.net/howto.html. 9.4.2. Installing OpenVPN In Windows, execute the installation le and wait until it is complete. There should be no need for reboot. After this, the OpenVPN icon appears in the system tray. Right-click the icon and you can see the available options 120 Chapter 9. Advanced Use Cases for Access Server Figure 9-1. OpenVPN GUI Options Menu In Access Server, the easiest way to install OpenVPN is through the WWW setup. Just enter the server IP address in you web browser and log in. If you do not know the IP address, you can use the WRAPnder application to nd out the IP address. WRAPnder is located in the CD provided with the server. When in WWW setup, go to Advanced settings -> Upload a software update. There you can choose the openvpn-2.0.8-1.wpk installation packet and upload it to the server. After this you can go back to the Advanced settings page and choose List installed software components. If you can see openvpn in this list, the installation is complete. 9.4.3. Creating Certicates and Keys In this chapter, we create the necessary les to ensure privacy in the VPN, i.e. we will establish a Public Key Infrastructure (PKI). The PKI consists of:

A master Certicate Authority (CA) certicate and key which is used to sign each of the server and client certicates. A separate certicate (also known as a public key) and private key for the server and each client. OpenVPN uses bi-directional authentication, which means that both server and client will au-

thenticate each other using certicates before connection is considered safe. To create the les we will use a set of scripts bundled with OpenVPN for Windows. To see how the same thing is done in Linux, see http://openvpn.net/howto.html#pki. In Windows,

\Program Files\OpenVPN\easy-rsa. Run the following batch le to copy conguration les into place

(this will overwrite any existing vars.bat and openssl.cnf les):

open up a Command Prompt window and go to init-config Now, edit the vars le (called vars.bat on Windows) and set the KEY_COUNTRY, KEY_PROVINCE, KEY_CITY, KEY_ORG, and KEY_EMAIL parameters. Do not leave any of these parameters blank. vars clean-all build-ca 121 The build-ca builds the certicate authority (CA) certicate and key by invoking the interactive openssl command:

Chapter 9. Advanced Use Cases for Access Server ai:easy-rsa # ./build-ca Generating a 1024 bit RSA private key

............++++++

...........++++++

writing new private key to ca.key

-----

You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter ., the field will be left blank.

-----

Country Name (2 letter code) [FI]:

State or Province Name (full name) [NA]:

Locality Name (eg, city) [ESPOO]:

Organization Name (eg, company) [OpenVPN-TEST]:

Organizational Unit Name (eg, section) []:

Common Name (eg, your name or your servers hostname) []:OpenVPN-CA Email Address [me@myhost.mydomain]:

Note: In the above sequence, the most queried parameters were defaulted to the values set in the vars or vars.bat les. The only parameter which must be explicitly entered is the Common Name. In the example above, we have used "OpenVPN-CA". Next, we will generate a certicate and private key for the server:

build-key-server server As in the previous step, most parameters can be defaulted. When the Common Name is queried, enter "server". Two other queries require positive responses, "Sign the certicate? [y/n]" and "1 out of 1 certicate requests certied, commit? [y/n]". Generating client certicates is very similar to the previous step:

build-key client If you want to use many clients, then you could use, for example, the following commands:

build-key client1 build-key client2 build-key client3 In this case, remember that for each client, make sure to type the appropriate Common Name when prompted, i.e. "client1", "client2", or "client3". Always use a unique common name for each client. Next well create Dife Hellman parameters that must be generated for the OpenVPN server:

122 Chapter 9. Advanced Use Cases for Access Server build-dh The output is as follows:

ai:easy-rsa # ./build-dh Generating DH parameters, 1024 bit long safe prime, generator 2 This is going to take a long time

.................+........................................... ..................+.............+.................+......... ..................................... Now you can nd the generated keys and certicates in the keys subdirectory. The nal step in the key generation process is to copy all les to the machines which need them, taking care to copy secret les (server.key and client.key) over a secure channel. 9.4.4. Creating Conguration Files Both the server and client devices must have certain conguration les for OpenVPN to deter-

mine, for example, which IP addresses to use. In this chapter, we will create a basic conguration le for OpenVPN server and client. Well make the PC as server and Access Server as the client. An example conguration les can be found here: http://openvpn.net/howto.html#examples. In our example, we use most of the setting described in these les. Note: The conguration les can be named, for example, server.conf and client.conf in a Linux system. On Windows they would be named server.ovpn and client.ovpn, where the le extension is different. 9.4.4.1. Server Conguration File There are lots of conguration options that can be used with OpenVPN, but this guide only covers the basic approach to set up a working VPN with minimal effort. The lines needed in the server conguration le are listed below. After each line, an explanation follows, see Figure 9-2:

port 1194 Determines the TCP or UDP port that OpenVPN should listen to. For multiple OpenVPN instances on the same machine, youll need to use a different port for each one. Make sure your rewall allows trafc through these ports. proto udp Determines whether to use TCP or UDP. We have chosen UDP in our application. dev tun 123 Chapter 9. Advanced Use Cases for Access Server Determines whether to use routed IP channel (tun) or an Ethernet tunnel, i.e. Ethernet bridg-

ing (tap). tap creates a virtual Ethernet adapter, while tun device is a virtual point-to-point IP link. We have chosen tun because of its better efciency and scalability. ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"

This is a so-called master Certicate Authority (CA) certicate. This will be placed in both the server and client devices, its the same for all devices. Since the server is a Windows machine, we need to use double backslashes ( \\ ) in pathnames. In Linux system one slash ( / ) is used. cert "C:\\Program Files\\OpenVPN\\config\\server.crt"

This is the certicate (a.k.a public key) for the server device. key "C:\\Program Files\\OpenVPN\\config\\server.key"

This is the private key for the server device and it should be kept secret. dh "C:\\Program Files\\OpenVPN\\config\\dh1024.pem"

This le refers to Dife-Hellman key exchange, which is a cryptographic protocol that allows two devices that have no prior knowledge of each other to establish a shared secret key over an insecure connection. server 172.30.203.0 255.255.255.0 Here we create the VPN subnet. In this example, the server will take 172.30.203.1 for itself, the rest will be left for clients to use. Each client will be able to reach the server on 172.30.203.1. ifconfig-pool-persist C:\\Program Files\\OpenVPN\\config\\Logs\\ipp.txt This le maintains a record of client <-> virtual IP address associations. If OpenVPN goes down or is restarted, reconnecting clients can be assigned the same virtual IP address that was previously assigned. keepalive 10 120 This feature causes ping-like messages to be sent back and forth over the link so that each side knows when the other side has gone down. The default parameter "10 120" makes ping occur every 10 seconds and remote peer is assumed down if no ping is received within 120 seconds. 124 persist-key Chapter 9. Advanced Use Cases for Access Server Persist features try to avoid accessing certain resources on restart that may no longer be ac-

cessible. persist-tun See above. status C:\\Program Files\\OpenVPN\\config\\Logs\\openvpn-status.log OpenVPN outputs a short status description to this le showing current connections. This le is truncated and rewritten every minute. verb 3 This sets the verbosity level of the log le. 0 is silent, except for fatal errors 4 is reasonable for general use 5 and 6 can help to debug connection problems 9 is extremely verbose tls-timeout 4 Packet retransmit timeout on TLS control channel if no acknowledgment from remote end within n seconds (n = 4 in this example). 125 Chapter 9. Advanced Use Cases for Access Server Figure 9-2. Server Conguration File 9.4.4.2. Client Conguration File Just like with the server conguration le, well describe here the basic client settings needed in our example setup, see Figure 9-3:

client Here we specify that we are a client and that we will be pulling certain cong le directives from the server. dev tun This setting is the same as in the server conguration le. Use the same setting youre using in the server. proto udp This setting is the same as in the server conguration le. Use the same setting youre using in the server. remote 10.1.1.35 1194 126 This setting congures the hostname/IP and port of the server. resolv-retry infinite Chapter 9. Advanced Use Cases for Access Server Keep trying indenitely to resolve the host name of the OpenVPN server. Very useful on machines which are not permanently connected to the internet, such as laptops. nobind Most clients dont need to bind to a specic local port number. persist-key This setting is the same as in the server conguration le. Use the same setting youre using in the server. persist-tun This setting is the same as in the server conguration le. Use the same setting youre using in the server. ca /usr/local/openvpn/conf/ca.crt This is the same ca.crt le as in the server. See server cong le descriptions for more infor-

mation. cert /usr/local/openvpn/conf/client.crt This is the certicate (a.k.a public key) for the client device. key /usr/local/openvpn/conf/client.key This is the private key for the client device. verb 3 Sets the verbosity level of the log le. 127 Chapter 9. Advanced Use Cases for Access Server Figure 9-3. Client Conguration File 9.4.5. Starting up VPN First, place the conguration les in the client and server. Like in the examples, the location for these les can be, for example, C:\Program Files\OpenVPN\config in Windows and

/usr/local/openvpn/config in Linux. Next, copy the authentication les ( ca.crt, server.crt, server.key, client.crt and client.key) into the same directories. 9.4.5.1. Starting up the Server The OpenVPN server must be accessible from the internet:

open UDP port 1194 on the rewall (or the TCP/UDP port youve congured), or set up a port forward rule to forward UDP port 1194 from the rewall/gateway to the machine running the OpenVPN server make sure TUN/TAP device is allowed access through rewalls To start the OpenVPN server right-click on the .ovpn le on Windows and choose "Start Open-

VPN on this cong le" or by right-clicking the GUI icon on taskbar and start correct cong le from there. Its also possible to start from command line:

openvpn [server_config_file]

Where "server_cong_le" is in our Windows examples is server.ovpn. 128 Chapter 9. Advanced Use Cases for Access Server A normal server startup should look like this (output will vary across platforms):

Sun Feb Sun Feb Sun Feb Sun Feb Sun Feb Sun Feb Sun Feb Sun Feb Sun Feb Sun Feb Sun Feb Sun Feb Sun Feb 6 20:46:38 2005 OpenVPN 2.0_rc12 i686-suse-linux [SSL] [LZO] [EPOLL] built on Feb 6 20:46:38 2005 Diffie-Hellman initialized with 1024 bit key 6 20:46:38 2005 TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]

6 20:46:38 2005 TUN/TAP device tun1 opened 6 20:46:38 2005 /sbin/ifconfig tun1 10.8.0.1 pointopoint 10.8.0.2 mtu 1500 6 20:46:38 2005 /sbin/route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.8.0.2 6 20:46:38 2005 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:23 ET:0 EL:0 AF:3/1 ]

6 20:46:38 2005 UDPv4 link local (bound): [undef]:1194 6 20:46:38 2005 UDPv4 link remote: [undef]

6 20:46:38 2005 MULTI: multi_init called, r=256 v=256 6 20:46:38 2005 IFCONFIG POOL: base=10.8.0.4 size=62 6 20:46:38 2005 IFCONFIG POOL LIST 6 20:46:38 2005 Initialization Sequence Completed 9.4.5.2. Starting up the Client Well start the client from Linux command line:

openvpn [client_config_file]

Where "client_cong_le" is in our examples client.conf. A normal client startup looks similar to the server output and should end with the "Initialization Sequence Completed" message. Now, try a ping across the VPN from the client:

ping 10.8.0.1 If the ping succeeds, you have a functioning VPN. 129 Chapter 10. Certication Information and WEEE Compliance Access Server is CE approved and Bluetooth qualied v. 2.0 + EDR. It has been measured against the following specication standards: ETSI EN 300 328 v1.6.1 / EN 301 489-1/17 / EN 60950-1

/ FCC parts 15.247, 15.209, 15.207, 15.109 and 15.107. Supported Bluetooth proles are: GAP, SDAP, LAN client and server, SPP A and B, FTP client and server, ObjP client and server, PAN-

PANU, PAN-GN and PAN-NAP. Hereby, Bluegiga Technologies declares that this Access Server is in compliance with the essen-

tial requirements and other relevant provisions of Directive 1999/5/EC. This device complies with Part 15 of the FCC Rules. The device operation is subject to the following two conditions:

1. This device may not cause harmful interference, and 2. This device must accept any interference received, including interference that may cause undesired operation. This equipment has been tested and found to comply with the limits for a Class B digital device, pursuant to Part 15 of the FCC Rules. These limits are designed to provide reasonable protec-

tion against harmful interference in a residential installation. This equipment generates, uses, and can radiate radio frequency energy and, if not installed and used in accordance with the instructions, may cause harmful interference to radio communications. However, there is no guarantee that interference will not occur in a particular installation. If this equipment does cause harmful interference to radio or television reception, which can be determined by turning the equipment off and on, the user is encouraged to try to correct the interference by one or more of the following measures:

Reorient or relocate the receiving antenna Increase the distance between the equipment and receiver Connect the equipment into an outlet on a circuit different from that to which the receiver is connected Consult the dealer or an experienced radio or television technician for help Warning Changes or modications made to this equipment not expressly approved by Bluegiga Technologies Inc. may void the FCC authorization to operate this equipment. The radiated output power of Access Server is far below the FCC radio frequency exposure limits. Nevertheless, Access Server should be used in such a manner that the potential for human contact during normal operation is minimized. To meet the FCCs exposure rules and regulations:

The antenna(s) used for this transmitter must be installed to provide a separation distance of at least 20 cm from all the persons. 130 Chapter 10. Certication Information and WEEE Compliance Any transmitter installed in the CF card slot must not exceed 4 W of e.i.r.p. To check if a particular equipment complies with this restriction, you need to know its FCC ID number and visit the searching engine in the FCC web site in the following Internet address, where you can nd the output power by the equipment in the grant of equipment:

https://gullfoss2.fcc.gov/prod/oet/cf/eas/reports/GenericSearch.cfm If this link does not work properly, please visit the FCC website (http://www.fcc.gov/) and follow the following steps to nd the searching engine:

FCC website Ofce of Engineering Technology Equipment Authorization Electronic Filing Generic Search Please notice that the output power listed in the grant uses different units depending on the type of the equipment, e.g.:

1. The output power for 802.11a/b/g/h equipment or similar equipment approved under 15.247 or 15.407 is listed as Conducted RF power. 15.247 or 15.407 limit the e.i.r.p. to 4 W, so this restriction is fullled. 2. The output power for Part 22 cellular equipment is listed as e.r.p. The relationship between e.r.p. and e.i.r.p. is the following one:

e.i.r.p. = 1.64 x e.r.p. 3. The output power for Part 24 PCS equipment is listed as e.i.r.p. 4. For other type of equipment, please consult the distributor in order to assure the restriction is fullled. Note: Denitions:

Effective Radiated Power (e.r.p.) (in a given direction): The product of the power supplied to the antenna and its gain relative to half-wave dipole in a given direction. Equivalent Isotropically Radiated Power (e.i.r.p.) (in a given direction): The product of the power supplied to the antenna and its gain relative to an isotropic antenna. The table below is excerpted from Table 1B of 47 CFR 1.1310 titled Limits for Maximum Permis-

sible Exposure (MPE), Limits for General Population/Uncontrolled Exposure:

Power Density (mW/cm2) f/1500 1.0 Frequency Range (MHz) 300 - 1500 1500 - 100000 Table 10-1. Excerpt of Table 1B of 47 CFR 1.1310 The equipment WRAP Access Server equipment transmits in the 2400 - 2483.5 MHz frequency range, so the applicable MPE limit is 1 mW/cm2. The equipment can be provided with up to 4 Bluetooth modules WT11# (FCC ID: QOQWT11):

Under the conditions stated above MPE limits can be guaranteed as the calculation below shows:

Example 10-1. 15.247 or 15.407 Compact Flash Card with maximum allowed e.i.r.p. of 4 W Using Equation from page 18 of OET Bulletin 65, Edition 97-01:

S Compact Flash card = Prad (e.i.r.p.) Compact Flash card / 4R2 = 4000 mW/4(20 cm)2 131 Chapter 10. Certication Information and WEEE Compliance S Compact Flash card = 0.795774 mW/cm2 S Total = S Bluetooth + S Compact Flash card = 0.003481 mW/cm2 + 0.795774 mW/cm2 S Total = 0.799255 mW/cm2 < 1 mW/cm2 Example 10-2. Part 22 Compact Flash Card with maximum e.r.p. of 1.5 W (Category excluded of MPE evaluation according to 2.1091) Using Equation from page 18 of OET Bulletin 65, Edition 97-01 and considering that e.i.r.p. =

1.64 x e.r.p.:

S Compact Flash card = Prad (e.i.r.p.) Compact Flash card /4R2 = 1500 x 1.64 mW/4(20 cm)2 S Compact Flash card = 0.489401 mW/cm2 S Total = S Bluetooth + S Compact Flash card = 0.003481 mW/cm2 + 0.489401 mW/cm2 S Total = 0.492882 mW/cm2 < 1 mW/cm2 Example 10-3. Part 24 Compact Flash Card with maximum e.r.p. of 3 W (Category excluded of MPE evaluation according to 2.1091) Using Equation from page 18 of OET Bulletin 65, Edition 97-01 and considering that e.i.r.p. =

1.64 x e.r.p.:

S Compact Flash card = Prad (e.i.r.p.) Compact Flash card /4R2 = 3000 x 1.64 mW / 4(20cm)2 S Compact Flash card = 0.978803 mW/cm2 S Total = S Bluetooth + S Compact Flash card = 0.003481 mW/cm2 + 0.978803 mW/cm2 S Total = 0.982284 mW/cm2 < 1 mW/cm2 WEEE Compliance The crossed-out wheeled bin means that within the European Union the product must be taken to separate collection at the product end-of-life. Do not dispose of these products as unsorted municipal waste. 132 Appendix A. Directory Structure

-- subsys

-- peers

|-- init.d -> rc.d/init.d

|-- ppp

|

|-- rc.d

|

|

|-- rc3.d -> rc.d/rc3.d

|-- ssh

-- sysconfig

|-- init.d

-- rc3.d

-- shm

|-- obex

|-- etc

|-- tmp

|

-- var

|-- lock

|

|-- log

|-- run

-- empty Directory Tree

==============

/

|-- bin

|-- boot

|-- dev

|

|

|

|

|

|

|

|

|

|

|-- etc

|

|

|

|

|

|

|

|

|

|-- lib

|

|

|

|

|-- mnt

|

|

|-- proc

|-- root

|-- sbin

|-- sys

|-- tmp -> dev/shm/tmp

|-- usr

|

|

|

|

|

|

|

|

|

|

|-- bin

|-- lib

|

|-- libexec

|-- local

|-- sbin

-- share

|-- iptables

|-- pppd

-- modules

|-- tabset

-- terminfo

|-- nfs

-- usb

-- gconv

|-- a

-- [module directories]

Type Note

==== ====

f f f r r r r r r r r r r r f l f f f f f l f f f f f f f f f f p f f p l f f f f f f f f f f f whole filesystem is root writable ramdisk resolv.conf

/tmp obexserver dir ramdisk part of /var system config and init scripts system libraries mount points empty mount point empty mount point proc filesystem home directory of root sys filesystem temporary data (ramdisk) mount point for second flash 133

|

|

|

-- var

|-- l

|-- v

-- x

-- info

-- setup

|-- b2b

|-- dpkg

|-- empty -> ../dev/shm/var/empty

|-- lib

|

|

|

|

|-- lock -> ../dev/shm/var/lock

|-- log -> ../dev/shm/var/log

|-- run -> ../dev/shm/var/run

|-- spool

|

|

|-- tmp -> ../dev/shm/var/tmp

-- www

-- crontabs

-- cron

|-- cgi-bin

-- html Types

=====

Appendix A. Directory Structure f f f f f f f f f f l l l f f f l f f f log files WWW pages f = FLASH filesystem, read/write, files will be saved on power-down r = RAM filesystem, read/write, files will be lost on power-down l = symbolic link p = proc/sys filesystem, can be used to configure Linux 134 Appendix B. Setup Options B.1. Security settings Submenu containing most important security settings, like passwords. 1. Root password [$1$rUj/KWS1$v3FZcBP.6HiN4f5PaATMq1]

Password of "root" user, shown in encrypted form. The default is "buffy". To change the password, clear the field, enter a new password and click Save. Saving an empty field keeps the old password. Please note that the new password is shown in plain text only right after you have saved it. Later it is only shown encrypted, and there is no way to decrypt it. You must either remember it or change it again to something you do remember. 2. iWRAP password [buffy]

The password required to be entered before any commands when communicating with iWRAP (the Bluetooth server). The default is "buffy". To change the password, clear the field, enter a new password and click Save. Saving an empty field keeps the old password. Please note that the new password is shown in plain text only right after you have saved it. Later it is only shown encrypted, and there is no way to decrypt it. You must either remember it or change it again to something you do remember. Use "-" to disable iWRAP password. 3. Do not require iWRAP password from local clients [Yes]

Ask iWRAP password only from remote clients, not from local (127.0.0.1). 4. Bluetooth PIN code []

This PIN code used when establishing connections. Up to 16 characters are significant. If there is no default PIN code set, Access Server does not require a PIN code when establishing connections. However, if there is no default PIN code set, but the other device requests a PIN code, "1234" is replied. 5. wpkgd autoinstall password []

This is optional password to authenticate wpk autoinstall packets (wpk packets sent to the autoinstall directory, /tmp/obex by default). The password is shown encrypted here, if set. By default, it is not set. To change the password, clear the field, enter a new password and click Save. Please note that the new password is shown in plain text only right after 135 Appendix B. Setup Options you have saved it. Later it is only shown encrypted, and there is no way to decrypt it. You must either remember it or change it again to something you do remember. Use "-" do disable the password. The password must match the authentication parameter in the "wpkg.pif"

file in the wpk packet. Otherwise the packet is not processed. Syntax in the "wpkg.pif" file:

%wpkg-auth: auth 6. wpkgd hotplug password []

This is optional password to authenticate wpk installation packets automatically run from USB memory dongles or Compact Flash memory cards. The password is shown encrypted here, if set. By default, it is not set. To change the password, clear the field, enter a new password and click Save. Please note that the new password is shown in plain text only right after you have saved it. Later it is only shown encrypted, and there is no way to decrypt it. You must either remember it or change it again to something you do remember. Use "-" to disable the password. The password must match the authentication parameter in the "wpkg.pif"

file in the wpk packet. Otherwise the packet is not processed. Syntax in the "wpkg.pif" file:

%wpkg-auth: auth 7. Root user password for FTP [buffy]

Password of the "root" user for FTP connections. 8. Allow anonymous FTP login [Yes]

Whether "anonymous" FTP login is allowed or not. 9. WWW passwords [/etc/httpd.conf]

Access to WWW pages served by Access Server can be restricted using the configuration file "httpd.conf", editable from here. The file consists of lines in format "/dir:username:password". This specifies that to view the WWW page at address "http://as-ip/dir", you must enter username "username" and password "password". More than one username can be defined for the same "/dir"

by adding multiple lines. By default, this file specifies that only user "root" with password

"buffy" is allowed to access the WWW Setup. 136 B.2. Generic settings Submenu containing generic settings. 1. Root password [$1$rUj/KWS1$v3FZcBP.6HiN4f5PaATMq1]

Appendix B. Setup Options Password of "root" user, shown in encrypted form. The default is "buffy". To change the password, clear the field, enter a new password and click Save. Saving an empty field keeps the old password. Please note that the new password is shown in plain text only right after you have saved it. Later it is only shown encrypted, and there is no way to decrypt it. You must either remember it or change it again to something you do remember. 2. Use local syslog service [Yes]

This option determines whether the System Logger (syslogd) logs locally to /var/log/messages or not. Set this to No if you want to log to a remote syslog server. 3. IP address of the remote syslog server [192.168.42.1]

The IP address of the device in the network to which the System Logger should log to. The remote device must be configured to accept syslogd connections from this Access Server. See the system logger documentation on the remote device for more information on how to configure that. B.3. Network settings Submenu containing network settings. 1. Hostname of the unit [wrap]

The hostname of Access Server. Local applications will see this name. This name may be changed by dynamic network configuration. 2. Domain of the unit [localdomain]

The domain name of Access Server. Local applications will see this name. This name may be changed by dynamic network configuration. 3. Enable Ethernet cable interface [Yes]

Set this option to Yes if you want to have the Ethernet cable interface enabled. If you dont use this interface, you may disable it to slightly increase security and system boot speed. 4. Enable Wi-Fi interface [Yes]

Set this option to Yes if you want to have the Wi-Fi interface enabled

(you can use the Wi-Fi interface with a supported Compact Flash Wi-Fi card or USB Wi-Fi dongle). If you dont use this interface, you may disable it to slightly increase 137 Appendix B. Setup Options security and system boot speed. 5. Enable GPRS interface [No]

Set this option to Yes if you want to have the GPRS interface enabled. To use the interface, a supported Compact Flash GPRS card or a serial GPRS modem must be attached to Access Server. 6. Time server (rdate) []

Hostname or IP address of the time server to be connected at system boot to retrieve correct time using the Time Protocol (RFC 868). NTP client is running by default, so rdate should not be needed at all. 7. Zeroconf interface [nap]

Defines the interface in which Zeroconf is running. Possible interface names are "nap", "gn" and "none". B.3.1. Default interface settings Default interface settings. By default, Ethernet and Bluetooth PAN-NAP interfaces are assigned to this interface. 1. Use dynamic network conguration [Yes]

This option determines whether or not automatic configuration of the default network interface (nap) using DHCP should be attempted at boot. If set to no, you have to manually enter IP address and other network settings. 2. IP address [192.168.42.3]

The IP address of Access Server. 3. Subnet mask [255.255.255.0]

The network mask of Access Server. 4. IP address of the default gateway [192.168.42.254]

The IP address of the default gateway in the LAN to which Access Server is connected. 5. List of name server IPs [192.168.42.1 192.168.42.2]

The IP address(es) of the name servers, separated by space. B.3.2. Ethernet cable settings Ethernet cable settings. 1. Assign to default interface [Yes]

Assigns Ethernet (eth0) to default interface (nap) with settings specified in Default interface settings. Do NOT set this to No if you dont know what you are doing. There is a high risk that you end up with invalid network settings if you do so. If you need to set a static IP address to Access Server, do it in the Default interface settings. 138 Appendix B. Setup Options 2. Use dynamic network conguration [Yes]

Use dynamic network configuration (DHCP) on Ethernet interface when it is not assigned to the default interface. 3. IP address [192.168.43.3]

IP address of the Ethernet interface when it is not assigned to the default interface and dynamic network configuration is not in use. 4. Subnet mask [255.255.255.0]

Network mask of the Ethernet interface when it is not assigned to the default interface and dynamic network configuration is not in use. B.3.3. Wi-Fi settings Wi-Fi settings. 1. Act as a Wi-Fi Access Point [No]

This option defines whether Access Server acts as a Wi-Fi Access Point when Wi-Fi is enabled. 2. ESSID []

Access point network name (Service Set ID). 3. Nickname []

The nickname, or station name. 4. WEP encryption key []

WEP encryption key for Wi-Fi. Examples:

10 hex digits:

26 hex digits:

or 5 ASCII characters:

13 ASCII characters: "s:abcdefghijklm"

"abcdef1234"

"1234567890abcdef1234567890"

"1234-5678-90ab-cdef-1234-5678-90"

"s:abcde"

5. Extra commands for Access Point mode [/etc/syscong/ifup-wlan0]

Extra commands for Access Point mode. 6. Assign to default interface [No]

Assigns Wi-Fi to default interface with settings specified in Default interface settings. 7. Use dynamic network conguration [Yes]

Use dynamic network configuration (DHCP) for Wi-Fi interface. 8. IP address [192.168.44.3]

IP address of Wi-Fi interface. 9. Subnet mask [255.255.255.0]

Subnet mask of Wi-Fi interface. 139 Appendix B. Setup Options B.3.4. GPRS settings GPRS settings. 1. Dial on demand [Yes]

If this option is set to Yes, the GPRS link is not opened at boot time but when there is data to be transferred. 2. SIM card PIN code []

PIN code of the SIM card in the GPRS modem. 3. Username [blue]

Username for GPRS network. Contact your GSM operator for correct value. Some examples:

blue Elisa/Finland:

Sonera/Finland:

blue Wataniya/Kuwait: blue Mnet Etisalat/UAE:

See also: http://www.kh-gps.de/gprsset.htm 4. Password [giga]

Password for GPRS network. Contact your GSM operator for correct value. Some examples:

giga Elisa/Finland:

Sonera/Finland:

giga Wataniya/Kuwait: giga Etisalat/UAE:

Mnet See also: http://www.kh-gps.de/gprsset.htm 5. Internet APN [internet]

Internet APN for GPRS network. Contact your GSM operator for correct value. Some examples:

Elisa/Finland:

Sonera/Finland:

Wataniya/Kuwait: action.wataniya.com Etisalat/UAE:

internet internet mnet See also: http://www.kh-gps.de/gprsset.htm 6. Extra parameters for pppd []

Optional extra parameters for pppd. Use only if you know what you are doing. 140 B.4. Applications Appendix B. Setup Options Submenu containing settings of various applications. 1. Default startup applications []

Change which applications are to be started at startup and which dont. B.4.1. wpkgd settings Submenu containing settings for wpkgd application. 1. wpkgds autoinstall directory [/tmp/obex]

wpkgd will automatically check this directory for wpk files containing software update packets. Use "/tmp/obex" if you want to allow updates via Bluetooth Object Push. Use empty to disable autoinstall. 2. Password for autoinstall packages []

This is optional password to authenticate wpk autoinstall packets (wpk packets sent to the autoinstall directory, /tmp/obex by default). The password is shown encrypted here, if set. By default, it is not set. To change the password, clear the field, enter a new password and click Save. Please note that the new password is shown in plain text only right after you have saved it. Later it is only shown encrypted, and there is no way to decrypt it. You must either remember it or change it again to something you do remember. Use "-" do disable the password. The password must match the authentication parameter in the "wpkg.pif"

file in the wpk packet. Otherwise the packet is not processed. Syntax in the "wpkg.pif" file:

%wpkg-auth: auth 3. Delete processed autoinstall packages [Yes]

If this option is set Yes, the wpk autoinstall packets are deleted after they have been processed. 4. Process hotplug packages [Yes]

If this option is set to Yes, wpk packets are automatically processed from USB memory sticks or Compact Flash memory cards when they are plugged into Access Server. 5. Password for hotplug packages []

This is optional password to authenticate wpk installation packets automatically run from USB memory dongles or Compact Flash memory cards. The password is shown encrypted here, if set. By default, it is not set. To change the password, clear the field, enter a new password and click Save. 141 Appendix B. Setup Options Please note that the new password is shown in plain text only right after you have saved it. Later it is only shown encrypted, and there is no way to decrypt it. You must either remember it or change it again to something you do remember. Use "-" to disable the password. The password must match the authentication parameter in the "wpkg.pif"

file in the wpk packet. Otherwise the packet is not processed. Syntax in the "wpkg.pif" file:

%wpkg-auth: auth 6. Delete processed hotplug packages [No]

If this option is set Yes, the wpk packets are deleted after they have been processed. 7. Extra parameters for wpkgd []

Optional extra command line parameters for wpkgd. Please see wpkgd --help for detailed information on the options. B.4.2. FTP server settings Submenu containing settings for FTP server application. 1. Root user password [buffy]

Password of the "root" user for FTP connections. 2. Root user directory [/]

Root directory of the "root" user for FTP connections. 3. Root user instances [5]

Maximum number of simultaneous logins of the "root" user for FTP connections. 4. Allow anonymous login [Yes]

Whether "anonymous" FTP login is allowed or not. 5. Anonymous user password [*]

Password of the "anonymous" user for FTP connections. Use "*" to allow everything (aka anonymous login). 6. Anonymous user directory [/tmp/obex]

Root directory of the "anonymous" user for FTP connections. 7. Anonymous user instances [5]

Maximum number of simultaneous logins of the "anonymous" user for FTP connections. 8. Allow anonymous user to do everything [No]

Whether "anonymous" user is allowed to do everything (all below) or not. 142 Appendix B. Setup Options 9. Allow anonymous user to download [Yes]

Whether "anonymous" user is allowed to download files or not. 10. Allow anonymous user to upload [No]

Whether "anonymous" user is allowed to upload files and make directories or not. 11. Allow anonymous user to overwrite [No]

Whether "anonymous" user is allowed to overwrite existing files or not. 12. Allow anonymous user to multiple login [No]

Whether "anonymous" user is allowed to multiple logins or not. 13. Allow anonymous user to erase [No]

Whether "anonymous" user is allowed to erase files and directories or not. 14. Edit conguration le [/etc/ftpd.conf]

Edit the self documented configuration file of the FTP server. Here you can change more advanced settings. B.4.3. ObexSender settings Submenu containing settings for ObexSender application. 1. Bluetooth friendly name [W$S_$p]

The name shown when this device is found when inquired about by other Bluetooth devices. Following meta tags are available:

$S : Hardware serial number, all ten digits

$s : Hardware serial number, last three digits

$P : Server port

$p : Server port, last digit

$H : Fully Qualified Domain Name (FQDN)

$h : hostname

$$ : $

For example, "Server_$p" would set the Bluetooth friendly name as

"Server_1" for 1st baseband, "Server_2" for 2nd baseband and

"Server_3" for 3rd baseband. 2. Delay between inquiries [10]

Delay between inquiries (Bluetooth device discoveries) in seconds. 3. Delay between reply scans [10]

Determines how often (in seconds) OBEX incoming directory (/tmp/obex) is scanned for remote requests. A low value increases CPU usage. 4. If previous was ok, timeout before sending again [36000]

If a file has been successfully sent to a device, this timeout

(in seconds) defines when content can be sent again to the same device. 5. If previous was reject, timeout before trying again [86400]

If a file transmission to a device has failed or user has declined 143 Appendix B. Setup Options the file, this timeout (in seconds) defines when ObexSender can send content to the same device again. 6. Delay between retrying call [120]

When user doesnt accept or reject the file, ObexSender will try to send the file again. This setting determines the timeout (in seconds) before resend occurs. Default value is 120 seconds. If you wish to disable this feature you can use the same value as in

"ok delay" or "reject delay", i.e. the two previous settings. 7. Delay after scanning [5]

When a remote request from user has been received, this setting determines how long (in seconds) ObexSender will wait until the response file is sent back to the user. Default value is 5 seconds, because some mobile phones are not able to receive files over Bluetooth until at least 5 seconds has passed from sending. 8. Delay between multiple les [40]

If ObexSender has been configured to send multiple files, this configuration sets the delay (in seconds) between the file transmissions. 9. Minimum RSSI value before sending [-65]

The working range of ObexSender can be configured or limited with this setting. When ObexSender searches for devices, the RSSI

(Receiver Signal Strength Indicator) value is also measured. This value ranges from -128 to -1.

-128 means the signal strength is very weak. A connection attempt would very likely fail.

-65 means the signal strength is ok. Connection can be created. With Class 2 devices, like most mobile phones, this means the phone is 10-20 meters away. A Class 1 device can be even more than 100 meters away.

-30 to -1 means the signal is very strong. The devices are most likely very close to each other (less than a meter away). 10. Logle name [-]

Defines the path and name of the ObexSender log file

(for example "/usr/local/obexsender/obexsender.log"). Log file contains information about successful and unsuccessful transmissions, timestamps and information about sent files. You can also use an IP address of a log server, which must be another Access Server running ObexSender. Type "-" to use syslog. 11. Log prex [-]

144 Appendix B. Setup Options This prefix is put in front of every event in the log file. Type "-" for none (default). 12. If sending was failure, log it too [Yes]

If this is enabled failed transmissions will be logged too. 13. Register to watchdog daemon [Yes]

If this is enabled, ObexSender will reboot Access Server automatically if Bluetooth basebands have stopped responding. 14. iWRAP password [-]

iWRAP password. "-" for none (default). 15. Edit conguration le [/etc/obexsender.conf]

This link opens ObexSender configuration file

(/etc/obexsender.conf) and allows you to edit it manually. It also allows you to change the settings that are not configurable with Setup application. 16. Upload a new le [/usr/local/obexsender]

This link allows you to upload files into the ObexSender file directory. 17. List les [/usr/local/obexsender]

This link allows you to browse files on the ObexSender file system. 18. View log [-]

This link allows you to view ObexSender log file if it exists. By default a summary of the logged events is displayed. Detailed information is available by clicking the date links. B.4.3.1. Delete log (conrm) This link will delete the current log file after confirmation. 1. Delete log now! [/bin/true]

Delete ObexSender log file immediately!

WARNING: There is no confirmation for this!

B.4.4. SMS gateway settings Submenu containing settings for SMS gateway application. 1. Modem device [/dev/ttyS0]

Modem device for SMS gateway.

/dev/ttyAT1 for user uart

/dev/ttyS0 for CF slot 2. Log le name [-]

The file to which the SMS gateway (smsgw) logs all traffic. Use /dev/null for none, - for syslog, /var/log/smsgw.log if you want to save this information. Be careful, however, not to fill the RAM file system (use a 145 Appendix B. Setup Options cron job to free disk space from time to time). 3. SMSC number [+358405202000]

SMSC number. Contact your local GSM operator if you dont know the correct value.

+358405202000 for Sonera/Finland

+358508771010 for Elisa/Finland 4. Edit conguration le [/etc/smsgw.conf]

Edit the self documented configuration file of the SMS gateway. B.5. Bluetooth settings Submenu containing all Bluetooth related settings. 1. iWRAP password [buffy]

The password required to be entered before any commands when communicating with iWRAP (the Bluetooth server). The default is "buffy". To change the password, clear the field, enter a new password and click Save. Saving an empty field keeps the old password. Please note that the new password is shown in plain text only right after you have saved it. Later it is only shown encrypted, and there is no way to decrypt it. You must either remember it or change it again to something you do remember. Use "-" to disable iWRAP password. 2. Do not require iWRAP password from local clients [Yes]

Ask iWRAP password only from remote clients, not from local (127.0.0.1). 3. Friendly name [W$S_$p]

The name shown when this device is found when inquired about by other Bluetooth devices. Following meta tags are available:

$S : Hardware serial number, all ten digits

$s : Hardware serial number, last three digits

$P : Server port

$p : Server port, last digit

$H : Fully Qualified Domain Name (FQDN)

$h : hostname

$$ : $

For example, "Server_$p" would set the Bluetooth friendly name as

"Server_1" for 1st baseband, "Server_2" for 2nd baseband and

"Server_3" for 3rd baseband. 4. Connectable and discoverable mode [3]

This setting specifies whether this device is connectable and/or discoverable or not by other Bluetooth devices. 146 Appendix B. Setup Options When a device is connectable, other Bluetooth devices can make a Bluetooth connection to it. Before making a connection, the calling device must know the Bluetooth address of the device it is connecting to. The Bluetooth addresses can be found by making an inquiry. When a device is discoverable, it shows up in inquiries. Possible values for all combinations of these settings are:

0 : Not connectable, not discoverable 1 : Not connectable, discoverable 2 : Connectable, not discoverable 3 : Connectable and discoverable (default) 5. Master/slave role switch policy [1]

This setting specifies how local Bluetooth device should decide its role. When a Bluetooth device calls another Bluetooth device, it is master by default and the answering device is slave. When the connection is being built, a role switch can be made. Normally, access point devices need to be the master, and therefore they require a master-slave switch when a new device is connecting. This is also how Access Server is configured by default. Otherwise Access server couldnt host the maximum number of slaves (7). Other possible combinations are:

0 : Allow switch when calling, dont request it when answering 1 : Allow switch when calling, request it when answering (default) 2 : Dont allow switch when calling, request it when answering If you have problems with connecting to Access Server, it might be because your client device does not support the master/slave switch. In this case, set this setting to 0. 6. Default PIN code []

This PIN code used when establishing connections. Up to 16 characters are significant. If there is no default PIN code set, Access Server does not require a PIN code when establishing connections. However, if there is no default PIN code set, but the other device requests a PIN code, "1234" is replied. 7. Power save mode and parameters [4]

The power save mode used by default for all connections. Possible settings are:

0 : Active. 1 : Park: Round-robin. 2 : Park: Idle. 3 : Sniff: All 4 : Sniff: Idle (default).

"Active" means that no power saving is in use.

"Sniff: All" means that the connections are kept in sniff mode always. 147 Appendix B. Setup Options

"Sniff: Idle" means that a connection is switched to sniff mode after it has not transmitted data for some time (2 seconds by default). When data transmission resumes, switch to active mode is made. Park modes are generally not useful. See Users and Developers Guide and Bluetooth specification for more information. 8. Use literal replies in SDP [Yes]

If enabled, some SDP result codes will have literal values instead of numeric values. 9. Optional command line parameters []

Optional extra command line startup parameters for the iWRAP servers. 10. Edit startup script [/etc/bluetooth.conf]

Opens iWRAP configuration file (/etc/bluetooth.conf) for editing. You can append extra iWRAP commands to that file. iWRAP servers process the file each time they start. See the Users and Developers Guide for iWRAP command reference. B.5.1. Bluetooth proles Submenu for the settings of all supported Bluetooth profiles. 1. Enable lan access prole [No]

Whether or not the LAN Access Profile is enabled. 2. Enable PAN user prole [No]

Whether or not the PAN User Profile is enabled. 3. Enable PAN generic networking prole [No]

Whether or not the PAN Generic Networking Profile is enabled. 4. Enable PAN network access point prole [No]

Whether or not the PAN Network Access Point Profile is enabled. 5. Enable object push prole [Yes]

Whether or not the Object Push Profile is enabled. 6. Enable le transfer prole [Yes]

Whether or not the File Transfer Profile is enabled. B.5.1.1. Lan access prole settings Submenu containing LAN Access Profile settings. 1. Login name and password []

The login name and password required from LAN access clients. Must be entered as a single string, separated with a space. For example: guest buffy If empty (default), no login is required. 2. Service name (shown in SDP) [Lan Access]

148 Appendix B. Setup Options The name of the LAN Access Profile service shown in the Service Discovery. 3. Defaultroute modication policy [0]

How the LAN Access Profile should modify the defaultroute in routing tables:

0: Do not alter defaultroute (default) 1: When acting as a LAP client, set defaultroute according to the LAP server 2: When acting as a LAP server, set defaultroute according to the LAP client 3: Set defaultroute according to the LAP server/client connected 4. First IP for LAP clients [192.168.160.0]

This defines the C-class of IP addresses to be used in point-to-point connections between Access Server and LAP clients. Full C-class is required: use "x.y.z.0". B.5.1.2. PAN user prole settings Submenu containing Personal Area Network User Profile settings. 1. Service name (shown in SDP) [PAN User]

The name of the PAN User Profile service shown in the Service Discovery. 2. Enable zeroconf when calling [No]

Enable ZeroConf protocol for outgoing PANU connections. 3. Enable zeroconf when answering [No]

Enable ZeroConf protocol for incoming PANU connections. B.5.1.3. PAN generic networking prole settings Submenu containing Personal Area Network Generic Networking Profile settings. 1. Service name (shown in SDP) [Generic Networking]

The name of the PAN Generic Networking Profile service shown in the Service Discovery. 2. Use dynamic network conguration for local IP address [No]

Whether or not DHCP is used for configuring local IP Address. Enable only if you are connecting this PAN-GN to another PAN-GN that will provide the IP configuration. 3. Local GN interface IP address [192.168.161.1]

The IP address for the local GN interface. 4. Local GN interface subnet mask [255.255.255.0]

The netmask for the local GN interface. 5. Start DHCP server for remote users [Yes]

Whether or not this device should start DHCP for remote devices connecting to this PAN-GN. Disabled if "Use dynamic network configuration for local IP address" is used. 6. First IP for lease block [192.168.161.2]

149 Appendix B. Setup Options First IP address of the lease block. 7. Last IP for lease block [192.168.161.254]

Last IP address of the lease block. 8. Subnet of lease block [255.255.255.0]

Subnet mask of the lease block. 9. Lease time [86400]

Lease time in seconds. B.5.1.4. PAN network access point prole settings Submenu containing Personal Area Network Network Access Point Profile settings. 1. Service name (shown in SDP) [Network Access]

The name of the Bluetooth PAN Network Access Point Profile service shown in the Service Discovery. B.5.1.5. Serial port prole settings Submenu containing the Bluetooth Serial Port Profile settings. The profile itself is enabled and disabled by switching "serialport"

application "on" or "off" from the menu:

Setup -> Applications -> Default bootup applications. 1. Act as the calling device [No]

Whether this device should act as the calling device (DevA) or the answering device (DevB). 2. BPS rate [115200]

The bits-per-second rate of the connection. Possible values are:

300, 1200, 2400, 4800, 9600, 19200, 38400, 57600, 115200, 230400, and 460800. 3. Data bits [8]

The number of data bits in the connection. Possible values are:

5, 6, 7, and 8. 4. Parity [0]

The parity bit setting of the connection. Possible values are:

0: No Parity (default) 1: Odd Parity 2: Even Parity 5. Stop bits [1]

The number of stop bits in the connection. Possible values are 1 and 2. 6. Hardware ow control (RTS/CTS) [Yes]

Whether or not the hardware flow control is used. 7. Software ow control (XON/XOFF) [No]

Whether or not the software flow control is used. 150 Appendix B. Setup Options 8. Bluetooth address of the remote device [00:07:80:80:bf:01]

The Bluetooth address of the device to be contacted. If the local device is configured as DevA, this is the DevB it tries to connect. 9. Service channel [2]

In DevA (call) mode:

The Bluetooth RFCOMM channel of the remote device. In DevB (answer) mode: The Bluetooth RFCOMM channel of the local device. 10. Service name (shown in SDP) [Serial Port]

The name of the Bluetooth Serial Port Profile service shown in the Service Discovery. 11. Optional command line parameters []

Optional extra parameters for the Access Server Serial Port profile application. Currently the supported parameters are:

--device dev

--msc

--nobuffer Device, if not the user port (/dev/ttyS0 for CF Card) Enables transmitting of DCD/DSR Modem Status Control signals. Discard data if no Bluetooth connection, do not buffer it. B.5.1.6. Object push prole settings This submenu contains Bluetooth Object Push Profile settings. 1. Service name (shown in SDP) [Object Push]

The name of the Object Push Profile service shown in the Service Discovery. B.5.1.7. File tranfer prole settings This submenu contains Bluetooth File Transfer Profile settings. 1. Service name (shown in SDP) [File Transfer]

The name of the File Transfer Profile shown in the Service Discovery. B.6. Advanced settings Submenu containing advanced settings of Access Server. 1. System startup script [/etc/rc.d/rc.local]

This is the last initialization script executed at system startup. By default, the script /etc/rc.d/rc.local just turns off all LEDs to indicate the startup has finished. If you want to initialize something automatically at every boot, or start up your own applications, you should add the required commands to this file. Remember to start your programs to the background. Example:

/usr/local/bin/myapp &

If you do not start the programs to the backgroud, you will not able to access the management console using a serial cable. 2. Default user prole [/etc/prole]

151 Appendix B. Setup Options Edit the file containing the default user profile settings. 3. WWW passwords [/etc/httpd.conf]

Access to WWW pages served by Access Server can be restricted using the configuration file "httpd.conf", editable from here. The file consists of lines in format "/dir:username:password". This specifies that to view the WWW page at address "http://as-ip/dir", you must enter username "username" and password "password". More than one username can be defined for the same "/dir"

by adding multiple lines. By default, this file specifies that only user "root" with password

"buffy" is allowed to access the WWW Setup. 4. Setup access [/etc/setup.conf]

The "/etc/setup.conf" file can be used to give different access rights to different users of the WWW Setup. The file consist of lines in following format:

example.tag +user1 +user2 -user3 -user4 This will allow (+) access to tag "example.tag" for "user1" and "user2"

and denies (-) access from "user3" and "user4". You can find the tags from the output of Setup -> Advanced -> System Information -> Collect info for support request For example, the tag of this setting is advanced.setupconf. If you have created another user "guest" in /etc/httpd.conf that can access

"/setup", you can deny that user from changing the Setup access settings with following line in this file:

advanced.setupconf -guest 5. Edit other conguration les []

From this menu you can edit any files located in Access Server file system. You can for example create "/var/spool/cron/crontabs/root" file for configuring the cron daemon. 6. Browse les []

Browse files stored in Access Server. 7. Find other Access Servers [/usr/sbin/nder]

Find other Access Servers. 8. Inquiry for Bluetooth devices [/usr/bin/btcli inquiry]

Inquiry for other Bluetooth devices. 9. Upload a software update [/tmp/obex]

Upload a software update file (*.wpk). Access Server supports a special management packet format (wpk), which 152 Appendix B. Setup Options can be used to update Access Server software components or to install custom software and configuration files. Please consult Users and Developers Guide for more information. B.6.1. System information This submenu contains tools to retrieve system status information. 1. Hardware information Displays hardware and software identification information (output of command "wrapid"). 2. List installed software components [/usr/bin/dpkg -l]

Lists currenty installed software components and their version numbers. 3. List running processes [/bin/ps ww]

Lists running processes. 4. List memory status [/usr/bin/free]

Lists memory status. 5. List free disk space [/bin/df -h]

Lists free disk space. 6. Show system log le [/var/log/messages]

Shows system log file. 7. Show system boot log le [/var/log/dmesg]

Shows system boot log. 8. Collect info for support request [/usr/sbin/supportinfo]

This page contains collectively all the system status and configuration information. Include this information when sending a support request to support@bluegiga.com WARNING: All classified information, like passwords, should be automatically excluded. It is still recommended to manually check that all such information is really removed. B.6.2. Reboot system (conrm) Reboot Access Server. Confirmation will be asked. 1. Reboot now! [/sbin/reboot]

Reboot Access Server immediately!

WARNING: There is no confirmation for this!

B.7. Summary of Setup Options Security settings Root password

[$1$rUj/KWS1$v3FZcBP.6HiN4f5PaATMq1]

153 Appendix B. Setup Options

[Yes]

[buffy]

iWRAP password Do not require iWRAP password from local clients Bluetooth PIN code wpkgd autoinstall password wpkgd hotplug password Root user password for FTP Allow anonymous FTP login WWW passwords

[]

[]

[]

[buffy]

[Yes]

[/etc/httpd.conf]

Generic settings Root password Use local syslog service IP address of the remote syslog server

[$1$rUj/KWS1$v3FZcBP.6HiN4f5PaATMq1]

[Yes]

[192.168.42.1]

Network settings Hostname of the unit Domain of the unit Default interface settings Use dynamic network configuration IP address Subnet mask IP address of the default gateway List of name server IPs Enable Ethernet cable interface Ethernet cable settings Assign to default interface Use dynamic network configuration IP address Subnet mask Enable Wi-Fi interface Wi-Fi settings

[wrap]

[localdomain]

[Yes]

[192.168.42.3]

[255.255.255.0]

[192.168.42.254]

[192.168.42.1 192.168.42.2]

[Yes]

[Yes]

[Yes]

[192.168.43.3]

[255.255.255.0]

[Yes]

[/etc/sysconfig/ifup-wlan0]

[Yes]

[No]

Act as a Wi-Fi Access Point

[]

ESSID

[]

Nickname

[]

WEP encryption key Extra commands for Access Point mode Assign to default interface Use dynamic network configuration IP address Subnet mask

[No]

Enable GPRS interface GPRS settings Dial on demand SIM card PIN code Username Password Internet APN Extra parameters for pppd Time server (rdate) Zeroconf interface

[192.168.44.3]

[255.255.255.0]

[No]

[Yes]

[]

[blue]

[giga]

[internet]

[]

[]

[nap]

Applications Default startup applications

[]

154 wpkgd settings Appendix B. Setup Options

[/tmp/obex]

wpkgds autoinstall directory Password for autoinstall packages Delete processed autoinstall packages Process hotplug packages Password for hotplug packages Delete processed hotplug packages Extra parameters for wpkgd

[]

[Yes]

[]

[]

[Yes]

[No]

FTP server settings

[buffy]

Root user password

[/]

Root user directory

[5]

Root user instances

[Yes]

Allow anonymous login

[*]

Anonymous user password

[/tmp/obex]

Anonymous user directory Anonymous user instances

[5]

Allow anonymous user to do everything Allow anonymous user to download [Yes]

Allow anonymous user to upload Allow anonymous user to overwrite Allow anonymous user to multiple login

[No]

Allow anonymous user to erase Edit configuration file

[/etc/ftpd.conf]

[No]

[No]

[No]

[No]

ObexSender settings

[36000]

[86400]

[120]

[5]

[40]

[W$S_$p]

[10]

[10]

Bluetooth friendly name Delay between inquiries Delay between reply scans If previous was ok, timeout before sending again If previous was reject, timeout before trying again Delay between retrying call Delay after scanning Delay between multiple files Minimum RSSI value before sending Logfile name Log prefix If sending was failure, log it too Register to watchdog daemon iWRAP password Edit configuration file Upload a new file List files View log Delete log (confirm)

[Yes]

[-]

[/etc/obexsender.conf]

[/usr/local/obexsender]

[/usr/local/obexsender]

[-]

[-]

[-]

[-65]

[Yes]

Delete log now!

[/bin/true]

SMS gateway settings Modem device Log file name SMSC number Edit configuration file

[/dev/ttyS0]

[-]

[+358405202000]

[/etc/smsgw.conf]

Bluetooth settings iWRAP password Do not require iWRAP password from local clients

[buffy]

[Yes]

155 Appendix B. Setup Options Friendly name Connectable and discoverable mode Master/slave role switch policy Default PIN code Power save mode and parameters Use literal replies in SDP Optional command line parameters Edit startup script Bluetooth profiles

[W$S_$p]

[3]

[1]

[]

[4]

[Yes]

[]

[/etc/bluetooth.conf]

Enable lan access profile Lan access profile settings Login name and password Service name (shown in SDP) Defaultroute modification policy First IP for LAP clients

[No]

Enable PAN user profile PAN user profile settings

[]

[Lan Access]

[0]

[192.168.160.0]

[No]

Service name (shown in SDP) Enable zeroconf when calling Enable zeroconf when answering

[PAN User]

[No]

Enable PAN generic networking profile PAN generic networking profile settings

[No]

[No]

[Generic Networking]

Service name (shown in SDP) Use dynamic network configuration for local IP address Local GN interface IP address Local GN interface subnet mask Start DHCP server for remote users First IP for lease block Last IP for lease block Subnet of lease block Lease time

[192.168.161.1]

[255.255.255.0]

[Yes]

[192.168.161.2]

[192.168.161.254]

[255.255.255.0]

[86400]

Enable PAN network access point profile PAN network access point profile settings

[No]

Service name (shown in SDP)

[Network Access]

Serial port profile settings

[No]

[115200]

[8]

[0]

[1]

Act as the calling device BPS rate Data bits Parity Stop bits Hardware flow control (RTS/CTS) Software flow control (XON/XOFF) Bluetooth address of the remote device Service channel Service name (shown in SDP) Optional command line parameters

[2]

[Serial Port]

[]

[Yes]

[No]

[00:07:80:80:bf:01]

Enable object push profile Object push profile settings Service name (shown in SDP) Enable file transfer profile File tranfer profile settings

[Yes]

[Object Push]

[Yes]

Service name (shown in SDP)

[File Transfer]

[No]

156 Appendix B. Setup Options Advanced settings System startup script Default user profile WWW passwords Setup access Edit other configuration files Browse files Find other Access Servers Inquiry for Bluetooth devices Upload a software update System information

[/etc/rc.d/rc.local]

[/etc/profile]

[/etc/httpd.conf]

[/etc/setup.conf]

[]

[]

[/usr/sbin/finder]

[/usr/bin/btcli inquiry]

[/tmp/obex]

Hardware information List installed software components List running processes List memory status List free disk space Show system log file Show system boot log file Collect info for support request [/usr/sbin/supportinfo]

[/bin/ps ww]

[/usr/bin/free]

[/bin/df -h]

[/var/log/messages]

[/var/log/dmesg]

[/usr/bin/dpkg -l]

Reboot system (confirm) Reboot now!

[/sbin/reboot]

157 Appendix C. Open Source Software Licenses Some Access Server software components are licensed under the terms and conditions of one or more open source licenses, listed in Table C-1 below. Description URL License Appreviation CMU/UCD GPL1 GPL2 GPL2+

LGPL2 LGPL2.1 BSD BSDorig MIT Carnegie Mellon University & Regents of the University of Californias BSD style license (in net-snmp) GNU General Public License Version 1, February 1989 GNU General Public License Version 2, June 1991 GNU General Public License Version 2 or later GNU Library General Public License Version 2, June 1991 GNU Lesser General Public License Version 2.1, February 1999 Revised BSD License (without the advertising clause) Original BSD License (with the advertising clause) MIT License (only one version exist, also known as X11 style license) Mozilla Public License Version 1.1 OpenSSL License (similar to BSDorig) http://www.fsf.org/licenses/

info/GPLv1.html http://www.opensource.org/

licenses/gpl-license.php http://www.opensource.org/

licenses/gpl-license.php http://www.gnu.org/copyleft/

lgpl.html http://www.opensource.org/

licenses/lgpl-license.php http://www.opensource.org/

licenses/bsd-license.php http://www.fsf.org/licenses/

info/BSD_4Clause.html SSLeay MPL1.1 OpenSSL SSLeay License (similar to BSDorig) http://www.mozilla.org/MPL/

http://www.openssl.org/source/

license.html http://www.openssl.org/source/

license.html http://www.gzip.org/zlib/

zlib_license.html Table C-1. Open Source Licenses in Access Server Software Components The details of the open source software components and the license under which they are distributed are listed below in Table C-2. Software components not listed are licensed under Bluegigas License Agreement. ZLIB License (only one version exist) ZLIB Software Component Version 1.0.0 and Das U-Boot git-060720 License GPL2 Source URL http://sourceforge.net/projects/u-boot/

The bootloader. Initialized system, holds system conguration, loads and launches the Linux kernel. 158 Appendix C. Open Source Software Licenses GPL2 2.6.17 License Source URL Software Component Version Kernel Linux kernel The Access Server kernel, responsible for resource allocation, low-level hardware interfaces, security etc. kernel at91 patches ARM-Linux patches for the Linux kernel. Userland bash http://maxim.org.za/AT91RM9200/2.6/

http://www.kernel.org/

2.6.17 GPL2 2.05b GPL1 &

GPL2 http://www.gnu.org/software/bash/

bash.html GNU Projects Bourne Again SHell, interactive shell with Bourne shell syntax. binutils http://www.gnu.org/software/binutils/

2.15 GPL2 &

LGPL2 1.2.1 0.9.6 GPL2 http://bridge.sourceforge.net/

GNU Binutils, collection of binary tools, like GNU linker and GNU assembler. bridge-utils Linux Ethernet bridging utilities, needed to manage bridging for WRAP Bluetooth PAN proles and WLAN Access Point functionality. busybox GPL2+

Provides tens of general userland utilities. bzip2 Compression library. crosstool GCC build script. e3 GPL2 Small text editor with different keybindings. ed GPL2 http://www.sax.de/~adlibit/

http://kegel.com/crosstool/

http://www.busybox.net/

http://www.bzip.org/

GPLorig GPL2 1.0.3 2.6.2 0.42 0.2 http://www.gnu.org/software/ed/

ed.html An 8-bit clean, POSIX-compliant line editor. gcc 3.4.5 GPL2 &

LGPL2 GNU C/C++ compiler and related tools. gdb 6.4 GPL2 &

LGPL2 http://gcc.gnu.org/

http://www.gnu.org/software/gdb/

gdb.html GNU debugger. glibc 2.3.6 GPL2 &

LGPL2.1 http://www.gnu.org/software/libc/

libc.html GNU C Library. hostap-utils GPL2 Utility programs for managing hostap-driver. iptables GPL2 0.3.7 1.3.4 http://hostap.epitest./

http://www.netlter.org/

159 Appendix C. Open Source Software Licenses 3.81 GPL2 License Source URL Software Component Version Administration tool for the Linux kernel IP packet lter. make The Make. maradns DNS server. libpcap Provides portable framework for low-level network monitoring. Needed by tcpdump. lrzsz http://www.tcpdump.org/

http://www.maradns.org/

1.2.0.07.6 0.12.20 GPL2 0.9.4 BSD BSD http://www.gnu.org/software/make/

http://www.ohse.de/uwe/software/

lrzsz.html Provides X/Y/Zmodem download/upload tools. ncurses MIT 5.3 http://www.gnu.org/software/

ncurses/ncurses.html Library for displaying and updating text on text-only terminals. netkit-ftp BSDorig 0.17 ftp://ftp.uk.linux.org/pub/linux/

Networking/netkit/

FTP client application. net-snmp 5.2.rc4 CMU/USD

& BSD http://www.net-snmp.org/

Suite of applications used to implement SNMP v1, SNMP v2c and SNMP v3 using both IPv4 and IPv6. ntpclient NTP (RFC-1305) client. openssl http://doolittle.faludi.com/ntpclient/

http://www.openssl.org/

2003_194 0.9.8a GPL2 OpenSSL

& SSLeay 4.5p1 Toolkit implementing SSL v2/v3, TLS v1 and general purpose cryptography library. openssh OpenSSH suite; server and client utilities. openvpn 2.0.5 An Open Source VPN daemon. pcmciautils http://www.openssh.com/

http://openvpn.net/

GPL2 GPL2 BSD 012 http://kernel.org/pub/linux/utils/

kernel/pcmcia/pcmcia.html http://www.perl.org/

5.8.8 GPL2 A suite of userspace tools for PCMCIA support in the Linux 2.6 kernel. perl A programming language. picocom GPL2 Minimal dumb-terminal emulation program. BSD &

ppp BSDorig &

GPL2 &

ZLIB 2.4.3 1.4 http://ppp.samba.org/

http://efault.net/npat/hacks/picocom/

160 Software Component Version Point-to-Point Protocol userland driver. ppp-dhcpc GPL2 License for pppd 2.4.2 Appendix C. Open Source Software Licenses Source URL ben at netservers.co.uk DHCP plugin for PPP. readline 4.3 GPL2 http://cnswww.cns.cwru.edu/php/

chet/readline/rltop.html GNU Readline library, providing set of functions for use by applications that allow users to edit command lines as they are typed in. strace System call trace, i.e. a debugging tool. stupid-ftpd Simple FTP server. sysfsutils http://www.liacs.nl/~wichert/strace/

http://stupid-ftpd.sourceforge.net/

1.4beta 4.5.14 GPL2 GPL2 GPL2 2.0.0 http://linux-

diag.sourceforge.net/Sysfsutils.html These are a set of utilites built upon sysfs, a new virtual lesystem in Linux kernel versions 2.5+ that exposes a systems device tree. termcap Basic system library needed to access the termcap database. tftp-hpa https://www.redhat.com/fedora/

GPL2 2.0.8 BSD 0.42 http://www.kernel.org/pub/software/

network/tftp/

TFTP client and server. tcpdump Utility to monitor network trafc. wireless_tools 3.9.4 28 BSD http://www.tcpdump.org/

GPL2 http://www.hpl.hp.com/personal/

Jean_Tourrilhes/Linux/Tools.html Package containing utilities to manage Wireless LAN specic parameters. zlib General purpose compression library. Table C-2. Access Server Open Source Software Components and Their Licences http://www.gzip.org/zlib/

ZLIB 1.2.3 161 Appendix D. Supported Hardware Connector CF CF CF CF CF CF CF CF CF CF USB USB Type GPRS GPRS GPRS GPRS GPS WiFi WiFi WiFi WiFi Memory Card Enfora GSM/GPRS Compact Flash Card (GSM 0110) Anycom GS-320 Tri-Band GPRS CF Card AudioVox RTM 8000 Fujitsu Siemens Connect2Air 3GSM Pretec CompactGPS Ambicom Wireless CompactFlash Card

(WL1100C-CF) D-Link Air Wireless Network DCF-660W Linksys Instant Wireless WCF-12 SMC Networks WLAN EZ Connect Any vendor EDGE/GPRS/GSMFalcom Samba 75 Memory Any vendor Note Multislot class 8. Multislot class 10. Multislot class 8, "same" HW as Fujitsu. Multislot class 8, "same" HW as Audiovox. Supports both client and access point modes Seen shipping with 1.7.4 rmware (can be access point without upgrade) Does not support rmware upgrade If you nd a card that does not work, please contact

<support@bluegiga.com>. Seen as modem device

/dev/ttyACM0 If you nd a dongle that does not work, please contact

<support@bluegiga.com>. Table D-1. Supported Hardware by Access Server 162