any reason to require -t dev in rfcomm_sppd -S ?
Luigi Rizzo
rizzo at iet.unipi.it
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 iet.unipi.it> 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
AT+ZV SPPConnect XXX
...
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.
cheers
luigi
More information about the freebsd-bluetooth
mailing list