8.4.1.1. Standard Operation

With the standard configuration, SPP-over-IP works as described below:

• Listens for incoming Serial Port Profile (SPP) connections

• Takes control of all incoming connections

• Opens a TCP connection to the defined IP address and TCP port

• Forwards all incoming data from the SPP device to the established TCP connection and vice versa

All the server computer needs to do is to listen for incoming TCP connections from Access Server to a specified TCP port and receive/send the application data.

8.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 transmitting TCP/IP packets wirelessly over Bluetooth. The figure below illustrates this configuration:

8.4.1.3. SPP-over-IP over GPRS

SPP-over-IP software can also be used over GPRS instead of wired Ethernet connection. This requires that Access Server is equipped with a working GSM/GPRS compact flash card. See Access Server manual for supported cards.

Notice when using GPRS:

• Data upload rate is around 8-12kbps (depending on GPRS card)

• Data download rate is around 32-40bbps (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.

8.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 incoming connections. It is however possible to implement a system where Access Server opens the Bluetooth connections to the defined 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.

8.4.1.5. SPP-over-IP and COM Ports

SPP-over-IP can also be used together with Tactical Software' s 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.

An evaluation version of Serial/IP can be downloaded from:

http://www.tacticalsoftware.com/products/serialip.htm

8.4.2.1. Preparations

SPP-over-IP is easiest to configure through the WWW setup, which allows you to access all the necessary configurations.

First, you must figure out the Access Server IP address (if it is connected to a TCP/IP network). This is easiest to do with the WRAPFinder software:

Serialport must be off for SPP-over-IP to work. In software version 3.0, serialport application has been disabled by default.

8.4.2.2. Preparations

SPP-over-IP settings are modified through Bluetooth settings -> Edit startup script

You must add the following lines manually:

• Enable Bluetooth Serial Port Profile: SDP ADD SERIALPORT 2 "SPP-over-IP"

  Syntax:

  SDP ADD [service] [channel] ["NAME"]

• Enable SPP-over-IP: SET BLUETOOTH LISTEN 2 10.1.1.60:5000

  Syntax:

  SET BLUETOOTH LISTEN [channel] [IP-address]:[port]

In the example configuration above, RFCOMM channel 2 is used with the SPP service. You can, however, use any other free channel as well. Notice however that the RFCOMM channel must be same in both SDP ADD and SET BLUETOOTH LISTEN configurations.

In the second configuration, the IP address is 10.1.1.60 and the TCP-port is 5000. You must change these to match your system, that is, the IP address must be the address of the listening server.

Once you have done your configuration, press the Save button and restart the server so that the settings take place.

8.4.2.3. Repeater Configuration

If you want to configure Access Server also to act as a repeater (see Figure 8-2) you must make some additional configurations. Add the line below to your Bluetooth start-up script:

Enable repeater: SET CONTROL AUTOEXEC CALL 00:07:80:80:31:C9 PAN-NAP

Syntax:

 
            SET CONTROL AUTOEXEC [command]
          

You must replace the Bluetooth address used in the example (00:07:80:80:31:C9) with the Bluetooth address of the Access Server, on which you want to receive the PAN connection.

The Bluetooth PIN codes must match between the repeater and the master Access Server.

8.4.2.4. Wi-Fi Configuration

If Access Servers must be connected to Wi-FI (WLAN) instead of physical Ethernet connection, you also need to make additional configurations through the WWW setup.

Please refer to latest Access Server User' s and Developer's Guide to see how this is done.

8.4.2.5. GPRS Configuration

If Access Servers must be connected to GPRS network instead of physical Ethernet or Wi-Fi connection, you also need to make additional configurations through the WWW setup.

Please refer to latest Access Server User' s and Developer's Guide to see how this is done.

8.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 filtering).

8.5.2.2. Content Pull

Obexsender can also be configured into a content pull mode. In this mode, the transaction is initiated by the user. The user can send any file to the server or alternatively a file containing some specific string such as "MP3" or "NOKIA N73". The server parses the received file and as a response tries to push a corresponding file to the user if such exists.

8.5.2.3. Scan

In the scan mode, Access Server simply scans for nearby Bluetooth devices and logs the number of devices found as well some basic information about them. The scan mode is useful if one just want to discover how many devices there are in the vicinity of an Access Server.

Scan mode is actually not part of Obexsender, but a different application running on Access Server.

8.5.3.1. Getting Started

The easiest and fastest way to configure 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. By default, Access Server uses DHCP, so if you connect it to your LAN, it must support DHCP as well.

8.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 files, i.e. remote requests

• Watchdog support

• Regexp and Unicode support

• Other minor bug fixes 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 8-19

8.5.3.3. Activating Obexsender

By default, the Obexsender application is disabled, so as a first task you should of course enable it if. This is quite simply done from the following page in the WWW setup (Figure 8-20): Access Server - Setup - Applications - Default bootup applications

Obexsender is enabled after a reboot. However, if you have not completed rest of the configuration, do not reboot Access Server yet.

8.5.3.4. Basic Obexsender Configuration

Next, you can move on to the basic Obexsender configuration. As a first step please go the to the WWW setup page in Access Server - Setup - Applications - ObexSender settings.

On this page (Figure 8-19) you can configure the basic Obexsender settings. Use the Help links to get some basic information about each configuration. More detailed descriptions you can find below:

• Bluetooth friendly name - [string]

  This name is the Bluetooth friendly name shown to other Bluetooth devices. For example, when Obexsender is used in push mode, this name is shown as a sender in a mobile phone screen.

  With meta tags, you can for example include the radio number in the name. Please click Help for more information about tags.

• Delay between inquiries - [seconds]

  Obexsender uses a standard Bluetooth inquiry (device discovery) to find nearby Bluetooth devices. This configuration defines the time interval between inquiries i.e. how frequently new devices are being searched for.

• Delay between reply scans - [seconds]

  This value determines how often OBEX in-folder (/tmp/obex) is scanned for remote requests. A low value increases CPU usage.

• If previous was ok, timeout before sending again - [seconds]

  If a file has been successfully sent to a device, this timeout defines when content can be sent again to the same device.

• If previous was reject, timeout before trying again - [seconds]

  If a file transmission to a device has failed or user has declined the file, this timeout defines when Obexsender can send content to the same device again.

• Delay between retrying call - [seconds]

  When the user does not accept or reject the file, Obexsender will try to send the file again. This setting determines the timeout before the resend occurs. This is useful in case the user does not notice the incoming Bluetooth transmission. The default value is 120 seconds, because many mobile phones tend to keep the Bluetooth link open for 120 seconds before closing it.

  If you want to disable this feature, you can use the same value as in "ok delay" or "reject delay", i.e. the two previous settings.

• Delay after scanning - [seconds]

  When a remote request from user has been received, this setting determines how long Obexsender will wait until the response file is sent back to the user. The 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.

• Delay between multiple files - [integer]

  The working range of Obexsender can be configured or limited with this setting. RSSI, or "Receiver Signal Strength Indicator" defines the distance to the receiving device in dBm. This value ranges from 128 to 0.

  • -128 = maximum rang

  • -65 = medium range

  • -30 = minimum range

  Most of the Bluetooth devices, especially mobile phones are so-called "Class 2" devices, meaning that their range is approximately 10-20 meters. So even if Access Sever is a "Class 1" device (100-200 meters) RSSI value -128 does not mean that it can serve all devices within 100-200 meter range, but it rather means that it can serve all devices within 10-20 meter range.

• Log file name - [string or IP-address]

  This configuration 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 as a parameter. Type "-" to use syslog.

• Log prefix - [string]

  This prefix is put in front of every event in the log file. Type "-" for none (default).

  Tip: If syslog is used for logging, the prefix is an easy way to separate Obexsender from other application logs.

• If sending was failure, log it too - [selection]

  If this is enabled, failed transmissions will be logged too.

• Register to watchdog daemon - [selection]

  If this is enabled, Obexsender will make Access Server reboot automatically if Bluetooth radios have stopped responding.

• iWRAP password - [string]

  If you have defined a password for the iWRAP (Bluetooth) interface you must have the same password configured here.

  Type "-" for none (default).

• Edit configuration file - [link]

  This link opens the raw Obexsender configuration file (/etc/obexsender.conf by default) and allows you to edit it manually. It also allows you to change some advanced settings that are not included in the basic configuration. Please see Section 8.5.3.6 for more information.

• Upload a new file - [link]

  This link allows you to upload files into the Obexsender file system.

• List files - [link]

  This link allows you to browse files on the Obexsender file system.

• View log - [link]

  This link allows you to view the 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.

• Delete log - [link]

  This link will delete the current log file.

8.5.3.5. Uploading Files

You can easily upload new content (files) for Obexsender by selecting Upload a new file in the Obexsender main menu. All you need to do is browse for the file you want to upload and click "Upload". You will see a confirmation note, for example "File /usr/local/obexsender/Bike.jpg uploaded" .

At the moment, you can only upload to /mnt/mtd directory from WWW setup. If you would like to upload to some other directory, you must use secure FTP to accomplish that. This is because normal FTP is disabled by default in Access Server. One good software for secure file transmission in Windows is WinSCP.

8.5.3.6. Advanced Obexsender Configuration

Here you can alter all the settings available for Obexsender. It includes all the settings covered in last chapter and more. Here we will go through only the settings that can be configured only from the obexsender.conf file, since basic configuration is already covered in previous chapters.

• # Use these iWRAPs for sending/inquiry

  Here you can choose which radios you want to use to send files. By default all radios are in use, but for example if you would like to use just the first radio, you can disable other radios like this:

  baseband 127.0.0.1 10101 #baseband 127.0.0.1 10102 #baseband 127.0.0.1 10103 #baseband 127.0.0.1 10104

  Baseband 10104 is used for testing purposes only.

• # Don't send to these bluetooth devices

  With this setting, you can define Bluetooth addresses you do not want to serve. The default setting is:

  ignore 00:07:80:

  This is the manufacturer ID for Bluegiga Technologies, so Obexsender can avoid sending to its own radios and to other Access Servers in the same area.

• # Always send to these test devices when found (60s interval)

  Devices defined here will be sent files every 60 seconds. Other timeout settings are ignored when these devices are in Access Server' s range. Usually used for testing purposes only.

• # Obexserver's directory (for remote requests)

  This option defines the destination directory for files users send to Access Server, i.e. it' s the OBEX in-folder for remote requests.

• # Automatically reboot Access Server if all iWRAPs fail

  Obexsender will make Access Server reboot if all Bluetooth radios stop responding for some reason. By default watchdog service is enabled (recommended).

• # Send these files in this order. If none listed then do not inquiry

  Files will be sent to remote devices in the order they are listed here. For example if you want to transmit first tp1.gif and then tp2.gif, you can enter it like this:

  file /usr/local/obexsender/tp1.gif file /usr/local/obexsender/tp2.gif

  If no files are specified, Obexsender will not start at all.

• # Timestamp is Weekday, Starthour-Endhour or WeekdayStarthour-Endhour

  Timestamps allow files to be sent only on specific days and/or times. Examples:

  file /usr/local/obexsender/image1.jpg Fri (file is sent only on Fridays) file /usr/local/obexsender/image2.jpg 8-14 (file is sent every day between 8am and 2pm) file /usr/local/obexsender/image3.jpg Tue8-14 (file is sent only on Tuesdays between 8am and 2pm)

• # Parse remote requests, send file back

  With this setting, you can configure Obexsender to send a file to a user only if this file is specifically requested. Requesting for file can be done, for example, by sending a calling card with specified keyword. Keyword is extended regular expression (regex) and case-non-sensitive. Keyword is matched for actual content in the file (for example text strings, but also header information is taken into account) and bdaddress (Bluetooth address of the user' s device, format is "00-00-00-00-00-00"). Examples:

  1. Only keyword is specified:

     reply GIF /usr/local/obexsender/pic.gif

     When a user sends a GIF image to Access Server, he will then receive pic.gif in return. Keyword "GIF" actually matches to the header information of the file, which contains "GIF" string. This way you can match to other know file formats too, like "VCF", i.e. electronic calling card.

  2. Only bdaddress is specified as keyword:

     reply 00:17:d5:5a:99:1d /usr/local/obexsender/pic.gif

     In this case, it does not matter what file user sends to Access Server, since the Bluetooth address of his mobile is recognized directly.

• # Delete non-matching remote requests

  If non-matching remote request are received, they will be immediately deleted. This option is enabled by default, but you can disable it, for example, if you have some other usage for Object Push and FTP profiles.

• # Be verbose (0-4)

  With this option, you can configure the detail level in the Obexsender log file. By default "verbose" is written only once in the configuration file, which means level 1 is in use. If you want more detailed logging, "verbose" can be written more than once, like this:

  verbose verbose

  Now you would have level 2 in use. Level 4 is the maximum.

• # Filename for saving ignore-list for reboots

  You can choose to save the information on already served devices, so you can form a so-called "ignore list". If this ignore list is saved in flash memory, it will be preserved even if Access Server is rebooted. By default, this option is disabled, but you can enable it by adding the time interval, which defines how often the ignore list is updated. We recommend you use a rather big value, like 900 seconds (15 minutes) because a really small value will cause constant stress on the flash memory and could physically burn it as time passes.

• # Broadcast processed basebands to other senders

  If there are many Access Servers running Obexsender in the same network, they can exchange information about remote devices they have already served. This way other servers won' t push content to users that already have received files from some other server.

  You can send this information to all Access Servers (broadcast-ip) in the network or just to a single server (unicast-ip). You can also define the interface name for this, but basically "nap" (network access point) is the only choice. It will automatically check the broadcast address in the "nap" interface in Access Server and use it for information exchange.

8.5.3.7. How to Store Remote Requests

By default, all remote requests are stored to the /tmp/obex folder and deleted after they have been processed. It is however possible to save the remote request files to a safe location. The following procedure shows how to automatically copy these files to an example folder /mnt/remote_request. (NOTE: you must first create this folder!):

Now all incoming files are copied to the /mnt/remote_request directory. The format of the files is bdaddr-btserverport-timestamp-filename.ext.

8.6.4.1. Server Configuration File

There are lots of configuration 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 configuration file are listed below. After each line, an explanation follows, see Figure 8-23:

port 1194
    

• Determines the TCP or UDP port that OpenVPN should listen to. For multiple OpenVPN instances on the same machine, you'll need to use a different port for each one. Make sure your firewall allows traffic through these ports.

proto udp
    

• Determines whether to use TCP or UDP. We have chosen UDP in our application.

dev tun
    

• Determines whether to use routed IP channel (tun) or an Ethernet tunnel, i.e. Ethernet bridging (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 efficiency and scalability.

ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"
    

• This is a so-called master Certificate Authority (CA) certificate. This will be placed in both the server and client devices, it's 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 certificate (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 file refers to Diffie-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 file 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.

persist-key
    

• Persist features try to avoid accessing certain resources on restart that may no longer be accessible.

persist-tun
    

• See above.

status C:\\Program Files\\OpenVPN\\config\\Logs\\openvpn-status.log
    

• OpenVPN outputs a short status description to this file showing current connections. This file is truncated and rewritten every minute.

verb 3
    

• This sets the verbosity level of the log file.

  • 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).

8.6.4.2. Client Configuration File

Just like with the server configuration file, we'll describe here the basic client settings needed in our example setup, see Figure 8-24:

client
    

• Here we specify that we are a client and that we will be pulling certain config file directives from the server.

dev tun
    

• This setting is the same as in the server configuration file. Use the same setting you're using in the server.

proto udp
    

• This setting is the same as in the server configuration file. Use the same setting you're using in the server.

remote 10.1.1.35 1194
    

• This setting configures the hostname/IP and port of the server.

resolv-retry infinite
    

• Keep trying indefinitely 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 don't need to bind to a specific local port number.

persist-key
    

• This setting is the same as in the server configuration file. Use the same setting you're using in the server.

persist-tun
    

• This setting is the same as in the server configuration file. Use the same setting you're using in the server.

ca /usr/local/openvpn/conf/ca.crt
    

• This is the same ca.crt file as in the server. See server config file descriptions for more information.

cert /usr/local/openvpn/conf/client.crt
    

• This is the certificate (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 file.

8.6.5.1. Starting up the Server

The OpenVPN server must be accessible from the internet:

• open UDP port 1194 on the firewall (or the TCP/UDP port you've configured), or

• set up a port forward rule to forward UDP port 1194 from the firewall/gateway to the machine running the OpenVPN server

• make sure TUN/TAP device is allowed access through firewalls

To start the OpenVPN server right-click on the .ovpn file on Windows and choose "Start OpenVPN on this config file" or by right-clicking the GUI icon on taskbar and start correct config file from there. It's also possible to start from command line:

openvpn [server_config_file]
    

Where "server_config_file" is in our Windows examples is server.ovpn.

A normal server startup should look like this (output will vary across platforms):

Sun Feb  6 20:46:38 2005 OpenVPN 2.0_rc12 i686-suse-linux [SSL] [LZO] [EPOLL] built on Feb  5 2005
Sun Feb  6 20:46:38 2005 Diffie-Hellman initialized with 1024 bit key
Sun Feb  6 20:46:38 2005 TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Sun Feb  6 20:46:38 2005 TUN/TAP device tun1 opened
Sun Feb  6 20:46:38 2005 /sbin/ifconfig tun1 10.8.0.1 pointopoint 10.8.0.2 mtu 1500
Sun Feb  6 20:46:38 2005 /sbin/route add -net 10.8.0.0 netmask 255.255.255.0 gw 10.8.0.2
Sun Feb  6 20:46:38 2005 Data Channel MTU parms [ L:1542 D:1450 EF:42 EB:23 ET:0 EL:0 AF:3/1 ]
Sun Feb  6 20:46:38 2005 UDPv4 link local (bound): [undef]:1194
Sun Feb  6 20:46:38 2005 UDPv4 link remote: [undef]
Sun Feb  6 20:46:38 2005 MULTI: multi_init called, r=256 v=256
Sun Feb  6 20:46:38 2005 IFCONFIG POOL: base=10.8.0.4 size=62
Sun Feb  6 20:46:38 2005 IFCONFIG POOL LIST
Sun Feb  6 20:46:38 2005 Initialization Sequence Completed
    

8.6.5.2. Starting up the Client

We'll start the client from Linux command line:

openvpn [client_config_file] 
    

Where "client_config_file" 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.