Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

rfcomm_sppd(1) [freebsd man page]

RFCOMM_SPPD(1)						    BSD General Commands Manual 					    RFCOMM_SPPD(1)

NAME
rfcomm_sppd -- RFCOMM Serial Port Profile daemon SYNOPSIS
rfcomm_sppd [-bhtS] -a address -c channel DESCRIPTION
The rfcomm_sppd utility is a Serial Port Profile daemon. It can operate in two modes: client and server. In client mode, rfcomm_sppd opens RFCOMM connection to the specified address server and channel. Once connection is established, the rfcomm_sppd utility provides access to the server's remote serial port via stdin/stdout or via pts(4) interface if -t option was specified. If the -S option is specified, rfcomm_sppd will operate in server mode and act as RFCOMM server, listening on ANY address and advertising a virtual serial port via the sdpd(8) daemon. If -t options was specified, the server side of the virtual serial port is attached to a pseudo- terminal. Otherwise the virtual serial port is attached to the stdin/stdout. rfcomm_sppd should be run as root in order to communicate with sdpd(8) in this case. The rfcomm_sppd utility opens both master and slave pseudo terminals. This is done to ensure that RFCOMM connection stays open until rfcomm_sppd is terminated. The data received from the master pseudo terminal are sent over the RFCOMM connection. The data received from the RFCOMM connection are written into master pseudo terminal. The application in its turn opens the slave pseudo terminal and operates on it just like it would operate over the standard serial port. The options are as follows: -a address In client mode, this required option specifies the address of the remote RFCOMM server. If this option is specified in server mode, rfcomm_sppd will only accept connections from the Bluetooth device with address address. The address can be specified as BD_ADDR or name. If name was specified then rfcomm_sppd utility will attempt to resolve the name via bt_gethostbyname(3). -b Detach from the controlling terminal, i.e., run in background. -c channel In both client and server mode, this option specifies the RFCOMM channel to connect to or listen on. In server mode, the channel should be a number between 1 and 30. If not specified, rfcomm_sppd will try to bind to ``wildcard'' RFCOMM channel number. The actual RFCOMM channel will be obtained via getsockname(2) call and will be used to register Serial Port service with sdpd(8). In client mode, the channel could either be a number between 1 and 30 or a service name. Supported service names are: DUN (for DialUp Networking service), FAX (for Fax service), LAN (for LAN Access Using PPP service) and SP (for Serial Port service). If channel was not specified then rfcomm_sppd utility will try to obtain RFCOMM channel for Serial Port service via Service Discovery Protocol from the server. -h Display usage message and exit. -S Server mode; see DESCRIPTION. -t Use slave pseudo tty. If not set stdin/stdout will be used. This option is required if -b option was specified. FILES
/dev/pts/[num] slave pseudo terminals EXIT STATUS
The rfcomm_sppd utility exits 0 on success, and >0 if an error occurs. EXAMPLES
rfcomm_sppd -a 00:01:02:03:04:05 -c 1 -t Will start the rfcomm_sppd utility and open RFCOMM connection to the server at 00:01:02:03:04:05 and channel 1. Once the connection has been established, a pts(4) can be used to talk to the remote serial port on the server. rfcomm_sppd prints the name of the pts(4) to use on std- out. SEE ALSO
bluetooth(3), ng_btsocket(4), pts(4), rfcomm_pppd(8), sdpd(8) AUTHORS
Maksim Yevmenkin <m_evmenkin@yahoo.com> BUGS
Please report if found. BSD
April 21, 2008 BSD

Check Out this Related Man Page

SDPD(8) 						    BSD System Manager's Manual 						   SDPD(8)

NAME
sdpd -- Bluetooth Service Discovery Protocol daemon SYNOPSIS
sdpd [-dh] [-c path] [-g group] [-u user] DESCRIPTION
The sdpd daemon keeps track of the Bluetooth services registered on the host and responds to Service Discovery inquiries from the remote Bluetooth devices. In order to use any service remote Bluetooth device need to send Service Search and Service Attribute or Service Search Attribute request over Bluetooth L2CAP connection on SDP PSM (0x0001). The sdpd daemon will try to find matching Service Record in its Service Database and will send appropriate response back. The remote device then will process the response, extract all required information and will make a sep- arate connection in order to use the service. Bluetooth applications, running on the host, register services with the local sdpd daemon. Operation like service registration, service removal and service change are performed over the control socket. It is possible to query entire content of the sdpd Service Database with sdpcontrol(8) by issuing browse command on the control socket. The command line options are as follows: -d Do not detach from the controlling terminal. -c path Specify path to the control socket. The default path is /var/run/sdp. -g group Specifies the group the sdpd should run as after it initializes. The value specified may be either a group name or a numeric group ID. This only works if sdpd was started as root. The default group name is ``nobody''. -h Display usage message and exit. -u user Specifies the user the sdpd should run as after it initializes. The value specified may be either a user name or a numeric user ID. This only works if sdpd was started as root. The default user name is ``nobody''. CAVEAT
The sdpd daemon will listen for incoming L2CAP connections on a wildcard BD_ADDR. In case of multiple Bluetooth devices connected to the same host it is possible to specify which services should be ``bound'' to which Blue- tooth device. Such assignment should be done at service registration time. Requests to register, remove or change service can only be made via the control socket. The sdpd daemon will check peer's credentials and will only accept the request if the application has the same effective user ID as the ``root'' user ID. The sdpd daemon does not check for duplicated Service Records. It only performs minimal checking on the service data sent in the Service Register request. It is assumed that application must obtain all required resources such as RFCOMM channels etc., before registering the service. FILES
/var/run/sdp SEE ALSO
sdp(3), sdpcontrol(8) AUTHORS
Maksim Yevmenkin <m_evmenkin@yahoo.com> BUGS
Most likely. Please report if found. BSD
January 13, 2004 BSD
Man Page