Date: Tue, 13 May 2008 21:44:40 +0200 (CEST) From: freebsd-bluetooth@oldach.net (Helge Oldach) To: maksim.yevmenkin@gmail.com (Maksim Yevmenkin) Cc: freebsd-bluetooth@freebsd.org, rizzo@iet.unipi.it Subject: Re: any reason to require -t dev in rfcomm_sppd -S ? Message-ID: <200805131944.m4DJieQL002589@sep.oldach.net> In-Reply-To: <bb4a86c70805130948x54fa4ea8tbc170196ff4eeaec@mail.gmail.com> from Maksim Yevmenkin at "13 May 2008 09:48:06"
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200805131944.m4DJieQL002589>