From owner-freebsd-bluetooth@FreeBSD.ORG Tue May 13 16:25:12 2008 Return-Path: Delivered-To: freebsd-bluetooth@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D6ECB106566C for ; Tue, 13 May 2008 16:25:12 +0000 (UTC) (envelope-from freebsd-bluetooth@oldach.net) Received: from rigel.oldach.net (rigel.oldach.net [194.8.96.250]) by mx1.freebsd.org (Postfix) with ESMTP id 443FD8FC22 for ; Tue, 13 May 2008 16:25:11 +0000 (UTC) (envelope-from freebsd-bluetooth@oldach.net) Received: from sep.oldach.net (hmo.in-dsl.de [217.197.85.210]) by rigel.oldach.net (8.14.2/8.14.2/hmo30jul04) with ESMTP id m4DFqSR9063632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 May 2008 17:52:29 +0200 (CEST) (envelope-from freebsd-bluetooth@oldach.net) Received: from sep.oldach.net (localhost [127.0.0.1]) by sep.oldach.net (8.14.2/8.14.2/hmo26jun05) with ESMTP id m4DFqSXQ031045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 May 2008 17:52:28 +0200 (CEST) (envelope-from freebsd-bluetooth@oldach.net) Received: (from hmo@localhost) by sep.oldach.net (8.14.2/8.14.2/Submit/hmo26jun05) id m4DFqQOW031043; Tue, 13 May 2008 17:52:27 +0200 (CEST) (envelope-from freebsd-bluetooth@oldach.net) Message-Id: <200805131552.m4DFqQOW031043@sep.oldach.net> In-Reply-To: from Maksim Yevmenkin at "21 Apr 2008 11:51:55" To: maksim.yevmenkin@gmail.com (Maksim Yevmenkin) Date: Tue, 13 May 2008 17:52:26 +0200 (CEST) From: freebsd-bluetooth@oldach.net (Helge Oldach) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-bluetooth@freebsd.org, rizzo@iet.unipi.it Subject: Re: any reason to require -t dev in rfcomm_sppd -S ? X-BeenThere: freebsd-bluetooth@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Using Bluetooth in FreeBSD environments List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2008 16:25:13 -0000 Maksim Yevmenkin wrote on Mon, 21 Apr 2008 20:51:55 +0200 (CEST): > On Thu, Apr 17, 2008 at 11:06 AM, Luigi Rizzo 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 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