The
obexapp
is a simple OBEX application.
In can operate in three modes:

interactive client mode;

non-interactive client mode;

server mode.

In the interactive client mode
obexapp
opens RFCOMM connection to the specified BD_ADDR and channel and starts
interactive OBEX session.

In the non-interactive client mode
obexapp
opens RFCOMM connection to the specified BD_ADDR and channel and performs
specified OBEX command with the specified parameters.
Only one OBEX command can be performed at a time.

The following OBEX commands are supported in the non-interactive client mode:

get remote-file [local-file]

Get
remote-file
from the remote OBEX server as save it as
local-file.
If the
local-file
parameter was omitted then it is constructed from the
remote-file.
The path component of the constructed local file name will be set to the
current directory unless
-r
option was specified.

getdefault local-file

Get the default vCard object from the remote OBEX server and save it as
local-file.

put local-file [remote-file]

Put one
local-file
to the remote OBEX server as
remote-file.
If the
remote-file
parameter was omitted the it is constructed from the
local-file.
The path component of the constructed remote file name will be removed.

In the server mode
obexapp
listens for incomming connections, on the specified BD_ADDR and channel
when given, from remote clients.
If no channel is given, the first unused RFCOMM channel will be allocated.
Once new connection is accepted
obexapp
forks and start new OBEX server for the client.
Note: if
-D
option was specified then OBEX server will not listen and fork.
In this case it is assumed that stdin/stdout was already connected to
the client.

When operating in server mode, the
"Class of Device"
setting of the Bluetooth controller should be changed to indicate that
"Object Transfer"
is supported, as some devices filter the inquiry results by device class.

The options are as follows:

-A BD_ADDR

Specify which local Bluetooth device should be used.
This option can be used when the host has multiple Bluetooth devices connected
at the same time.
If not specified, BDADDR_ANY will be used.

-a BD_ADDR

In the client mode this required option specifies the remote BD_ADDR of the
OBEX server.

-C channel

In both client and server modes this option specifies RFCOMM channel
to connect to or listen on.
In the server mode RFCOMM channel should be number between 1 and 30.
In the client mode RFCOMM channel could be either number between 1 and 30 or
service name. Supported service names are:
IrMC
for IrMC Sync service,
FTRN
for OBEX File Transfer service and
OPUSH
for OBEX Push service.
If service name was specified instead of numeric RFCOMM channel then
obexapp
utility will try to obtain RFCOMM channel for the service via Service
Discovery Protocol.

-c

Act as OBEX client.
This is the default mode.

-D

Use direct IO on stdin/stdout instead of listening on a L2CAP socket
(server mode only, and will not create any SDP service records).

-d

Do not detach from the controlling terminal, i.e. run in foreground (server
mode only).

-f

Connect to Folder Browsing Service on the remote OBEX server (client mode only).
By default client does not specify any service in OBEX connect request.

-h

Display usage message and exit.

-l priority

Set least severe log priority.
In other words,
log any message that has more severe or equal priority than given priority.
Priority should be specified by its name.
Supported priority names are:
alert,
crit,
debug,
emerg,
err,
error,
info,
none,
notice,
panic,
warn
and
warning.
Default log priority is
error.

Specify root folder.
Default root folder in the server mode is
/var/spool/obex
unless
-u
option was specified.
The
-u
option will set default root folder to the users home directory.
Current directory is the default root folder in the non-interactive client
mode.

-S

Run OBEX server in secure mode.
This only works if server was started as root.
In secure mode server will chroot to the root folder.

-s

Act as OBEX server.

-u user

Specifies the user the server should run as after it initializes.
The value specified may be either a username or a numeric user id.
This only works if server was started as root.

When accepting connections in server mode,
obexapp
will attempt to find an entry that would act as a virtual root
folder for the connecting device.
Virtual root folders must reside under default root folder which is set
with
-r
option.
The rules are as follows:

obexapp
will try to resolve connecting devices BD_ADDR using
bt_gethostbyaddr(3)
call and check for an entry that matches resolved name (if any);

obexapp
will check for an entry that matches connecting devices BD_ADDR;

obexapp
will check for an entry, named
"default";

If none of the above matches, then the connection to the client is terminated.
Otherwise,
obexapp
will try to change default root folder the the found entry.

If
-u
option was specified, the
obexapp
will try to change to the specified user.
Otherwise
obexapp
will try change to the user, that owns the found entry.
That is, if the found entry is a symlink, the
obexapp
will try change to the user, that owns symlink and not to the user, that
owns the entry symlink points to.

This allows the same system to intelligently distinguish different
client devices as belonging to different users.
An administrator can set up the subdirectories for
known devices under
/var/spool/obex
(or wherever, see
-r
option) for each user, or even as symlinks to each users home directory
(or a subdirectory thereof).

The
obexapp
utility uses
iconv(3)
library to convert characters between the local encoding and the UTF-16BE and
UTF-8 encodings.
In order to properly initialize
iconv(3)
library the
LANG
or
LC_CTYPE
environment variable must be set.
The local character encoding also must be supported by the
iconv(3)
library.
The
"ASCII",
"C",
"POSIX"
and
"US-ASCII"
locales are aliased to
"en_US.US-ASCII"
locale.

The first level involves the basic ability to put an object (such as a vCard)
from one device to another.
At this level, a device at least has the ability to push an object from one
device to another, which is useful at a minimal level.
The receiving device knows from the name of the object, which database
to store it in.

The second level requires the ability to read and write all entries in one
device from the other device.
For example, a device could obtain all of the vCards stored in another devices
phone book. With this level of support, mobile device databases such as the
phone book, message and calendar, can be backed-up and updated using a host
device.

The third level requires the ability to index the objects on the target device,
such that a hierarchy of objects can be formed.
With this capability, a device may more efficiently update the database objects
on the mobile device.

The fourth level requires that the two devices be fully able to synchronize
their objects one with another.
At this level of support, two devices support database modification logging
and other features that provide tremendous power to synchronize the databases
in very intelligent ways.

In server mode
obexapp
will try to register OBEX Object Push service with the local SDP daemon.
This means that
obexapp
requires root privileges to start in server mode.
Use
-u
option to set user name the server should run as after it initializes.