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

[Helge Oldach]

Maksim Yevmenkin wrote on Mon, 21 Apr 2008 20:51:55 +0200 (CEST):
> On Thu, Apr 17, 2008 at 11:06 AM, Luigi Rizzo <rizzo at iet.unipi.it> wrote:
> >
> > 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.
> 
> ok, please try the attached patch and see if it works for you. i
> basically removed the check for tty name in server mode, bind to
> "wildcard" channel instead of generating one based on pid (if channel
> was not specified) and fixed a possible problem with service
> registration in server mode (i.e. always register serial port
> service).

Your patch applies cleanly, but I just get

# rfcomm_sppd -S
rfcomm_sppd: Could not get socket name
# 

It seems that getsockbyname fails. What is the reason for that anyway?

BTW, Luigi's pipe application is interesting, but what about true
two-way communcation? For instance, I would like to have something like

# rfcomm_sppd -S -c sp -a myPalm -x "coldsync -t serial -s -md"

...meaning: Upon receipt of a SP connection request from myPalm we would
fork coldsync to synchronize the Palm (just like USB or serial sync, but
now bluetooth).

This could even go into /etc/ttys, forking a fresh rfcomm_sppd after the
request terminates.

I'm currently doing this in two separate steps, first starting
rfcomm_sppd with some arbitrary pty, then coldsync talking to that pty.
So yes, this definitely works.

Regards,
Helge