any reason to require -t dev in rfcomm_sppd -S ?

Luigi Rizzo rizzo at
Thu Apr 17 18:03:57 UTC 2008

On Thu, Apr 17, 2008 at 10:39:16AM -0700, Maksim Yevmenkin wrote:
> On Thu, Apr 17, 2008 at 4:56 AM, Luigi Rizzo <rizzo at> wrote:
> > hi, is there any compelling reason to require
> >  the '-t device' option in rfcomm_sppd when used in server mode ?
> technically, no. just need to be careful who is going to setup tty
> properly, for example make it 'raw' as rfcomm_sppd(1) does with pty.
> rfcomm_sppd(1) already can be used inside ppp(8), i.e. one can do
> something like
> set device '!/usr/bin/rfcomm_sppd -a mobile -c sp'
> in /etc/ppp.conf and it will work just fine. rfcomm_sppd(1) does not
> do anything to tty when running using stdin/stdout in client mode. the
> assumption here is that whatever calls rfcomm_sppd(1) will setup
> tty/fd properly.
> >  I tried to disable the one-line that checks it in the code, and
> >  things seem to work - and this makes the program very convenient
> >  to use in a pipeline, e.g.  to receive data from a remote bluetooth
> >  device.
> right. can you please provide usage example? i certainly would not
> object to making the change you are requesting.

sure - i need to listen to a portable ElectroCardioGram (ECG) device
which talks to the external world through bluetooth. The device
must have some kind of modem inside - its console port says it is
issuing commands such as


where XXX is the (manually configured) address of the bluetooth
dongle on the PC. On the FreeBSD side, running
"rfcom_sppd -a YYY" (without the -S option, YYY is the ECG address)
sometimes connects, but most of the times doesnt.

With a patched rfcomm_sppp i can just do

	rfcomm_sppd -S -a YYY | my_data_logger

rather than having to manually select an available tty/pty pair

Don't know how many devices behave in this way, but a
search for "AT+ZV SPPConnect" gives several matches with
documentation for embedded hardware.


More information about the freebsd-bluetooth mailing list