2.3.1. Management Console

If you don't have Bluetooth LAN/PAN client and you don't have the Access Server connected to your LAN or you don't know the IP address given to the Access Server, you can get the first shell prompt access using the management console.

To setup management console do the following:

1. Have a PC with a free COM port.

2. Power off the Access Server.

3. Configure your terminal application, like HyperTerminal in Windows, to use the settings in with the free COM port

   Table 2-1. The Management Console Port Settings

   Setting	Value
   Speed	115200bps
   Data Bits	8
   Parity	None
   Stop Bits	1
   Flow Control	None

4. Connect the serial cable shipped with the Access Server to your PC's free COM port.

5. Connect the null-modem adapter shipped with the Access Server to the serial cable

6. Connect the serial cable with the null-modem adapter to the management (user) port in the Access Server (see Figure 2-1).

7. Power on the Access Server.

8. Enter letter b in the terminal application during the first five seconds, while the blue LEDs in the Access Server turn on one by one.

9. The management console is now activated and you should see the boot log in your terminal window. Wait for the device to boot up and end with the prompt [root@wrap /]$.

10. You are ready to control the Access Server from the management console.

2.3.2. Accessing Remotely

When the WRAP Access Server is connected to a LAN it tries to get the IP address using DHCP and Zeroconf by default. You can then use the wrapfinder application to find the IP address (see Section 2.2).

If you cannot get the IP address using the wrapfinder, another way to see the IP address of the WRAP Access Server is to connect with a management console (see previous section), power on the board and, after the system is up and running, give the command ifconfig nap. The field inet addr for the interface nap contains the IP address of the WRAP Access Server board. For example, in the following capture from the management console, the IP address is 192.168.42.3.

        [root@wrap /]$ ifconfig nap
        nap      Link encap:Ethernet  HWaddr 00:07:80:00:BF:01
                 inet addr:192.168.42.3  Bcast:192.168.42.255  Mask:255.255.255.0
                 inet6 addr: fe80::207:80ff:fe00:bf01/64 Scope:Link
                 UP BROADCAST MULTICAST  MTU:1500  Metric:1
                 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)  TX bytes:1640 (1.6 KiB)
                 Interrupt:24 Base address:0xc000
      

You can use this address to connect the Access Server remotely via SSH, SCP or SFTP.

2.3.3. Transferring Files to/from the Access Server

You can transfer file to and from the Access Server by default 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 client of the Internet Explorer (type ftp://root:buffy@wrap-ip-address/ in the address bar)

• Bluetooth OBEX (Object Push and File Transfer Profiles) to/from directory /tmp/obex in WRAP Access Server

• NFS (mount a nfs-share from a remote device as a part of the file system of the Access Server)

• SSHFS (mount a WRAP Access Server directory over SSH as a part of the filesystem of any other Linux host)

  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 console)

For examples of file transferring, see Section 5.3.4.

3.2.1. iWRAP Password Protection

The access to the iWRAP can be password protected. By default it's buffy, but it can be unset or changed with the setup application (see Section 2.4). The password is case sensitive. The password must be typed in as the first command after the server has replied with "READY."

3.2.2. LAN Access Profile

This profile 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 6).

The Access Server board can also act as a LAN Access Client, but in this case it must be controlled manually using iWRAP commands, described in Chapter 6.

3.2.3. Serial Port Profile

The Serial Port Profile 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.

State A) in the figure 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 Profile connection between the two Access Server devices. These Access Server devices are then connected locally 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. Note: This handshaking is "local": it takes place between the user device and the Access Server board. 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 Profile 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.

3.2.4. Object Push and File Transfer Profile

Access Server has two OBEX profiles: Object Push Profile (ObjP) and File Transfer Profile (FTP). You can use these profiles to transfer files easily between different Access Server devices and other devices supporting ObjP/FTP.

These profiles are handled by forwarding incoming calls to obexserver program, which handles both profiles. The working directory is /tmp/obex, and users have full read and write access there. By default, the default contact card /etc/default.vcf is copied there at boot.

In ObjP mode obexserver will prefix received files with sender's Bluetooth address and iWRAP port number.

Two simple command line utilities, obexput and obexget, are provided. They can be used to send and retrieve files to and from another Bluetooth device supporting ObjP/FTP.

Usage: obexput [parameters] bdaddr channel file(s)

Enter either of these commands without parameters to get a short help for using the command.

A non-zero return value means error. Reason for this error is printed to terminal. See Section 6.10 for a list of OBEX Library's return codes.

3.2.5. PAN Profiles

The WRAP Access Server has support for all PAN profile modes: Personal Area Network User (PANU), Network Access Point (NAP) and Generic Networking (GN).

The device creating the PAN connection decides, which of these modes are to be used. Incoming connections are handled automatically by the Access Server. The Access Server board can also act as a PAN client, but in this case it must be controlled manually using the iWRAP interface, described in the Chapter 6.

3.2.6. Bluetooth Range Changing

The transmit power of the WRAP Access Server is configurable. By default, class 1 (100 meter range) settings are used. The settings can be changed down to "class 2" settings (10 meter range) with b2b_class2 command or even less with b2b_class3 command. The class 1 settings can be restored with b2b_class1 command.

After b2b_class# is given, it is recommended to reboot the Access Server once to restart ObexSender and other applications connected to the iWRAP server(s).

3.2.7. BTCLI - iWRAP Command Line Interface Utility

You can send commands to a iWRAP server using the btcli application.

Usage: btcli [options] command

To see the options, enter the command btcli --help.

The specified command is sent to a Access Server iWRAP server (default: first server at port 10101) and all replies are echoed to the standard output. The application waits and prints the replies for a certain amount of time (default: 10 seconds) and exits.

The iWRAP commands are described in Chapter 6.

3.2.8. serialbluetooth

It is also possible to control the first iWRAP server (at port 10101) via RS-232 with the serialbluetooth application. Note: When you want to use this application, you must first disable the Bluetooth Serial Port Profile and the WRAP SMS Gateway Server with the setup application, as described in Section 2.4.

Usage: serialbluetooth [options]

To see the options, enter the command serialbluetooth --help.

Basically, serialbluetooth takes commands from a serial port and forwards them to the iWRAP server. All the commands available via iWRAP are also available via 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 the control socket. To close the data socket, you have to write +++ with a 200ms pause before each character. There is no way 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.2.9. Resetting Bluetooth Basebands

In case of rare failures in the Bluetooth baseband level, it is possible to give hardware reset for the basebands while the other system services are running with the following command sequence at the command line interface of WRAP Access Server:

        [root@wrap /]$ /etc/init.d/bluetooth stop
        [root@wrap /]$ echo ABCD > /dev/bbreset
        [root@wrap /]$ sleep 1
        [root@wrap /]$ echo abcd > /dev/bbreset
        [root@wrap /]$ sleep 2
        [root@wrap /]$ /etc/init.d/bluetooth start
      

3.3.1. Compact Flash GPRS Cards

The Compact Flash GPRS card is identified automatically by the operating system when inserted. The WRAP 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).

The GPRS mode is enabled and settings like SIM card's PIN code are configured using the setup application or its WWW interface, see Section 2.4 and documentation for Setup → Network settings → Enable GPRS interface in Appendix B.

Using the WRAP SMS Gateway Server is documented in Section 3.5.3.

If needed for special use, the Compact Flash GPRS card can also be accessed directly from /dev/ttyS0, a device file which exists when the GPRS card is successfully initialized.

3.3.2. Compact Flash GPS Card

The Compact Flash GPS card is identified automatically by the operating system when inserted. At that time, the device file /dev/ttyS0 is created and the GPS card can be accessed using that device with the serial port settings in use by the GPS card.

The supported compact flash cards are listed in Appendix D.

3.3.3. Compact Flash WiFi Cards

WRAP Access Server has support for Prism II/III based CF WiFi cards. The supported compact flash cards are listed in Appendix D.

Depending on the firmware version, two different drivers must be used. The firmware version can be seen after the insertion of the card in the system log file /var/log/messages, which can be viewed with the WWW Setup interface at Setup → Advanced settings → Show system log file.

You need to use the Hostap driver, if you can see the following line in the log:

          eth1: Looks like an Intersil firmware version 1.7.4
      

If the firmware version is below 1.7.4, you must use the Hermes driver.

Selection of the driver and configuration is done with the setup application or its WWW interface at Setup → Network settings.

Standard set of wireless utilities are provided to fine-tune your WiFi configuration:

• iwconfig

• iwlist

• iwpriv

For more info see: http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html

3.5.1. Finder

The Finder service is a small service, which listens for UDP broadcast queries from the WRAP Access Server Finder applications and responses to those queries with identification information (IP address, model, serial number, etc.) about the Access Server.

3.5.2. ObexSender

The ObexSender application is started automatically in the WRAP Access Server. Its purpose is to receive business cards (vCards), images or other files, and analyze their content and send files back selecting them based on configured keywords found.

ObexSender can also inquiry for bluetooth devices, and automatically send one or more files to all new devices found.

3.5.3. SMS Gateway Server

The 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 SMS messages. By default the Compact Flash card is used. The PIN code query of the SIM-card at power-up must be disabled.

The WRAP SMS Gateway Server is disabled by default. To enable it, use the setup application's WWW interface, as described in section Section 2.4. Enabling is done at Setup → Applications → Default bootup applications → smsgw.

To use Nokia terminals the device must be connected to the user serial port when the server starts up and the terminal must be configured to operate in RS-232/AT-command. The Nokia terminals are configured with the N20 or N30 Configurator application.

The WRAP SMS Gateway is configured to use the terminal connected to the user serial port with the setup application or its WWW interface by changing the setting at Setup → Applications → SMS gateway settings → Comport device to /dev/ttyAT1 from the default /dev/ttyS0.

For further information on using smsgw, see the makesms example in Section 5.3.1.

3.5.4. User Level Watchdog

The 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 watchdog dies and the WRAP Access Server is rebooted by the kernel watchdog.

The watchdog command can be used to send messages to the watchdog daemon. This is done via command watchdog id timeout, for example watchdog test 5.

3.5.5. Remote Management

The WRAP Access Server contains simple tools that provide base for full and secure remote management of the device.

The basic remote management can be performed using the WWW Setup interface, SSH command line access and SCP and SFTP file transfer protocols.

In addition to them, the Access Server contains the WRAP Remote Management System for transferring management packets over different medium to the Access Server and automatically sending response packets back.

The management packets (*.wpk) are processed automatically when they are transferred to the autoinstall directory in the WRAP Access Server (/tmp/obex by default, configurable with setup application or WWW interface at Setup → Applications → wpkgd settings). 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.

          %wpkg-version: 2
          %wpkg-prepare:
          echo Hello world
        

          %wpkg-version: 2
          %wpkg-prepare:
          FOO=`pwd`
          cd /
          tar xzf ${FOO}/files.tar.gz
          echo Done.
        

          %wpkg-version: 2
          %wpkg-format:  vcf
          %wpkg-prepare:
          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"
        

3.5.6. FTP

If you enable FTP server then users can use it to log in in anonymously to /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 the Access Server with setup application or by editing /etc/ftpd.conf file (see Section 2.4).

3.5.7. Web Server

The integrated web server in the 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 the Access Server file system.

The web server is configured to protect the WWW Setup interface with username and password. The default username and password can be changed as instructed in Section 2.4. For further information about using the web server for your own applications, see the web examples in Section 5.3.1.

3.5.8. SNMP

A separate software update package is available from Bluegiga Techforum (https://www.bluegiga.com/techforum/), which adds the Net-SNMP suite of applications to the WRAP Access Server. Current implementation for the Access Server is limited and will be extended in the future. However, it can be used to poll the basic status of the Access Server.

Configuration details can be found and altered in the configuration file /etc/snmp/snmpd.conf accessible as described in Section 2.4.

For more information about the Net-SNMP suite, see http://net-snmp.sourceforge.net/

3.5.9. OpenVPN

A separate software update package is available from Bluegiga Techforum (https://www.bluegiga.com/techforum/), which adds the OpenVPN™, a full-featured SSL VPN solution to the WRAP Access Server.

For more information about the OpenVPN™, see http://openvpn.net/.

3.5.10. SSH

By default, users can use SSH to log in (or SCP and SFTP to transfer files) as user root with password buffy. The password can be changed on the Access Server using the command passwd or with the setup application.

3.5.11. Telnet

If you enable telnet then users can use it to log in as user root with password buffy. The password can be changed on the Access Server using the command passwd or with the setup application.

5.2.1. WRAP Access Server Software Development Environment System Requirements

The following hardware and software is required to run the WRAP Access Server Development Environment:

PC with

• CD-ROM drive

• Linux (tested with RedHat Enterprise Linux 3 and above, Fedora Core 2 and above)

  Devel libraries (especially zlib-devel and ncurses-devel) must be installed

  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 the Access Server board) is highly recommended.

Mount the WRAP 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 scripts prompts for root password.

Example (things you need to type are printed like this):

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

Install will ask you some questions (described below) regarding which components to install and the paths to install them to. If you are not very familiar with Linux, just press enter to these questions (the default values are suitable for most users and systems).

5.2.2. Questions Asked by the Install Script

Access Server toolchain directory � (default: /usr/local/arm)

This is the path where you want the WRAP Access Server Software Development tools (arm-linux-gcc, etc.) to be installed.

Development directory � (default: [home_of_current_user]/asdk)

This is the path where you want the WRAP Access Server Software Development Environment to be installed.

Development directory owner � (default: [current_user])

(Asked only if run as root) This is the username of the owner of the development directory.

Install toolchain sources � (default: no - unless the tools directory was changed)

Whether or not the toolchain sources will be installed. These are required only if the WRAP Access Server tools directory was changed from the default target location in step 1.

Install linux headers (default: no - unless libc sources are selected)

Whether or not the Linux header files will be installed. These are required only if the libc sources are being installed (chosen in step 5).

Install example applications � (default: yes)

Whether or not the WRAP Access Server example applications and their sources will be installed.

Compile image after installation � (default: yes)

If set to yes, install will compile the WRAP Access Server filesystem image to test that the installation was successful and that the Development Environment is working correctly.

5.3.1. Application Examples

To demonstrate the software development features of the Access Server, the WRAP Access Server Software Development Environment comes with several example applications.

5.3.2. Creating a New Project

To start a new project, you need to create a new subdirectory in your Development Environment's directory (asdk/) and add your application source files and Makefile to that directory.

A project skeleton can be done automatically using WRAP Access Server Project AppWizard. Just give the command make appwiz APP=dir/to/newapp in the Development Environments top level directory (asdk/). A "hello world" example ANSI C project is then created.

To create C++ project, give the command make appwiz APP=dir/to/newcppapp CPP=y.

You can add your directory to the compile queue by inserting it in the file asdk/DIRECTORIES if you want to compile the whole source tree at once from the top level asdk-directory.

You may need to modify the variables in the Makefile for your project. You can see the defaults and their description in the default Makefile created by the AppWizard (asdk/dir/to/newapp/Makefile in our example above).

Makefile variables are:

• TOPLEVEL

  This should point to the Development Environment source directory, i.e. asdk/.

• APPNAME

  This is the name of the executable file of the application. In our example, this line should be APPNAME = testapp

• APP_DIR

  This is the location of the application executable, when installed with the .wpk packet. By default, this is /usr/local/bin

• SRC

  This variable defines the files to be compiled and linked into APPNAME. In our example, this line could be SRC = testapp.c. Several files are separated with space, like SRC = testapp.c extraobj.c

• APP_STRIP

  Optional variable. The application symbols are removed by default to reduce application size. For debugging, these are needed, which can be done by APP_STRIP = false.

• CFLAGS

  Optional extra flags for C compiler. Set CFLAGS = -ggdb if you want to debug application.

• CXXFLAGS

  Optional extra flags for C++ compiler. Set CXXFLAGS = -ggdb if you want to debug application.

• LIBS

  Optional additional libraries needed by application. Multihreaded application needs libpthread with LIBS = pthread.

Now you have a new project just waiting for coding. To compile the project, you simply need to run make in the testapp directory.

The build system also creates the installation packet (testapp-timestamp.wpk), which can be transferred to /tmp/obex directory of the Access Server from where it is installed automatically.

5.3.3. Building From the Command Line

The WRAP Access Server Development Environment uses the ARM port of the GNU bintools and compilers to build applications. If you are not very familiar with Linux development, you should use the method explained in the previous section instead of writing your own makefiles.

If you still want to use your very own development environment, there are two minor issues to remember:

1. Tools are prefixed with arm-linux-, so for calling gcc C-compiler you need to call arm-linux-gcc, etc.

2. Tools are located in /usr/local/arm/2.95.3/bin/ directory, which is not in PATH by default.

5.3.4. Transferring an Application to the WRAP Access Server

To run an application on the Access Server, it must first be transferred into it. There are several ways of doing this (see Section 2.3.3). The most usable ways while doing software development are discussed in the following subsections.

          $ scp myapp root@<wrap-ip-address>:/tmp
          root@<wrap-ip-address>'s password: buffy (not echoed back)
          /path/to/myapp/myapp  100%    20KB    20.0KB/s    00:00
          $
        

          $ 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
          /path/to/myapp/myapp  100%    20KB    20.0KB/s    00:00
          sftp> quit
          $
        

          $ 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
          $
        

            [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]
          

5.3.5. Running an Application Transferred to Access Server

To run the application you just transferred to the 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 remember the password, which is buffy by default).

After establishing a connection to the Access Server, change the directory to where your application is located and change file permissions so that it can be executed, then run it.

          [root@wrap /] cd /tmp
          [root@wrap /tmp] chmod 755 testapp
          [root@wrap /tmp] ./testapp
        

5.3.6. Using Debugger (GDB/DDD)

It is possible to use GNU debugger GDB and a graphical user interface, like DDD, for debugging applications in the WRAP Access Server.

You have to compile with debug options and without symbol stripping to make debugging work. As mentioned above, this can be done by adding lines "APP_STRIP=false" and "CFLAGS=-ggdb" to the Makefile below SRC line.

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 the WRAP Access Server

   Usage: gdbserver :<port> <your application>

   Example: gdbserver :6789 ./hello

2. Start debugger on the host PC. (example is for DDD)

   Example: ddd --debugger /usr/local/arm/2.95.3/bin/arm-linux-gdb hello

3. Create connection to the WRAP Access Server.

   Usage: target remote <node IP>:<port>

   Example: target remote 192.168.42.3:6789

4. Run the program with command continue.

6.3.1. Forklistener

This is a standard program reading data from standard input and writing output to standard output. See SDK's directory examples/forkserver/ for an example of this kind of program.

Pros:

• Easy to write.

• Very robust for simple services.

• You don't have to know anything about 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 external program via one socket.

• You can't use stdout for debugging, you have to use syslog or a log file.

• iWRAP's advanced features are not available: powermodes, MSC, SDP, inquiry, ...

To setup a forklistener see SET command.

6.3.2. iWRAP Client

iWRAP client is a program communicating with the iWRAP server via control and data sockets. See SDK's 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.

6.10.1. libobex

Initialize the OBEX library. Must be the first function called. s_in and s_out are data handles for reading and writing.

Deinitialize the OBEX library. Must be the last function called.

Receive one OBEX packet. You have to free() the received packet! If NULL is returned, you have to disconnect next (timeout, dead socket, ...). If timeout is zero, wait forever. If timeout is nonzero, wait up to timeout seconds.

Send one packet. Does not call free().

Initialize an OBEX packet to empty command type packet.

Add byte/long/unicode-string/binary/ascii data to an OBEX packet.

Find header data from an OBEX packet. Returns -1 if not found, otherwise the length of the data.

Return mime type for filename.

6.10.2. libobexclient

Connect to target UUID. Target can be NULL (Object Push connect). Returns 0 if no errors, -1 if timeout, -2 if broken socket, >0 if OBEX error (see IrDA Object Exchange Protocol by Infrared Data Association for OBEX response codes).

Disconnect. Returns 0 if no errors, -1 if timeout, -2 if broken socket, >0 if OBEX error (see IrDA Object Exchange Protocol by Infrared Data Association for OBEX response codes).

Put local file / data block to remote.

name is remote file name. Can be NULL.

type is remote MIME type. Can be NULL.

data/length are pointer to data block and length. Can be NULL/0.

fdata is file handle for local file, if data was NULL.

progress is a function to be called after each data block. Can be NULL. progressarg will be passed as parameter.

Returns 0 if no errors, -1 if timeout, -2 if broken socket, >0 the OBEX error code (see IrDA Object Exchange Protocol by Infrared Data Association for OBEX response codes).

Get remote file to local.

name is remote file name. Can be NULL.

type remote MIME type. Can be NULL.

data/max_length are pointer to data block and length. Can be NULL/0.

fdata is file handle for local file, if data was NULL.

progress is a function to be called after each data block. Can be NULL. progressarg will be passed as parameter.

Returns >=0 (number of bytes received) if no errors, -1 if timeout, -2 if broken socket, <0 if OBEX error (see IrDA Object Exchange Protocol by Infrared Data Association for OBEX response codes).

Setpath to name with flags. Returns 0 if no errors, -1 if timeout, -2 if broken socket, >0 if OBEX error (see IrDA Object Exchange Protocol by Infrared Data Association for OBEX response codes).

6.10.3. obexbrowser

The application obexbrowser is an Object Push Profile (ObjP) and File Transfer Profile (FTP) client, and is shipped with Access Server in both binary form (as it is part of the Access Server platform) and in source form (at it is a good example of using the OBEX libraries).

For an outgoing ObjP/FTP call you need to:

1. Make the outgoing RFCOMM call from iWRAP.

   For example: CALL 00:07:80:80:bf:01 FTP RFCOMM

2. Run obexbrowser from the command line. It takes two parameters: hostname and port number. Hostname is usually localhost and port number can be read from the iWRAP server's CONNECT reply.

   For example: obexbrowser localhost 1024

obexbrowser itself supports all the OBEX commands. See the source code and the IrDA Object Exchange Protocol by Infrared Data Association. The commands obexbrowser accepts are described in Table 6-11.

Example:

          iWRAP server:
          READY.
          CALL 00:07:80:80:bf:01 3 RFCOMM
          CALL 0
          RINGING 0
          CONNECT 0 RFCOMM 1024
          Command line:
          obexbrowser localhost 1024
          connect
          connect=00
          get remote.vcf -
          get=143
          put default.vcf
          put=00
          disconnect
          disconnect=00
          Ctrl-D
          iWARP server:
          NO CARRIER 0 ERROR 000