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

[Helge Oldach]

Maksim Yevmenkin wrote on Tue, 13 May 2008 18:48:06 +0200 (CEST):
> On Tue, May 13, 2008 at 8:52 AM, Helge Oldach <freebsd-bluetooth at oldach.net> wrote:
> > 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 ?
> >> >  >
> >> >  > 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?
> 
> well, there is a problem with my previous patch. please try the
> attached updated patch.

Oops, the case is pretty clear. I should have seen that myself.

All is fine with this patch.

Helge