From owner-freebsd-bluetooth@FreeBSD.ORG Tue May 13 17:42:32 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 A00A3106570F for ; Tue, 13 May 2008 17:42:32 +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 0E3378FC49 for ; Tue, 13 May 2008 17:42:31 +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 m4DHgSnP077086 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 May 2008 19:42: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 m4DHgRWO039970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 May 2008 19:42: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 m4DHgRUD039969; Tue, 13 May 2008 19:42:27 +0200 (CEST) (envelope-from freebsd-bluetooth@oldach.net) Message-Id: <200805131742.m4DHgRUD039969@sep.oldach.net> In-Reply-To: from Maksim Yevmenkin at "13 May 2008 10:05:20" To: maksim.yevmenkin@gmail.com (Maksim Yevmenkin) Date: Tue, 13 May 2008 19:42:27 +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 Subject: Re: rfcomm_sppd -S as generic wrapper 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 17:42:32 -0000 Maksim Yevmenkin wrote on Tue, 13 May 2008 19:05:20 +0200 (CEST): > > 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. > > well, i thought about this, but not really sure how to do it cleanly. > here is what i mean. with rfcomm_pppd(8) (lan service wrapper) we > only need to start one server and register one lan service with local > sdpd(8). as soon as client connects to rfcomm_pppd(8) it forks and > starts separate ppp(8) instance that handles this particular client. > this model works well (imo) here. > > i'm not sure what rfcomm_sppd(8) wrapper behavior should be. what you > seems to be suggesting is that a single rfcomm_sppd(8) instance can > only handle single client at a time. this could be a reasonable > assumption. Good point. However rfcomm_sppd can distinguish different BT peers already, wouldn't that work by starting a separate rfcomm_sppd for each BT peer? > > 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. > > also your idea about putting rfcomm_sppd(8) entries into /etc/ttys > should work as it is, no? did you try to put rfcomm_sppd(8) into > /etc/tty entry for the pseudo terminal (slave) part and run coldsync > on mater pty? Yes, it works. But I'd also have coldsync in /etc/ttys, similar to palm "/usr/local/bin/coldsync -t serial -s -md" unknown on Hmm. Thinking about it, indeed in my case coldsync is the "getty replacement". Putting rfcomm_sppd into /etc/ttys is merely a hack, working around the fact that it terminates after each session. So rfcomm_sppd should probably have some "service selection" mechanism, similar to what pppd does. I know I could do my Palm sync task running network sync via TCP via PPP, however that's a fair bit of overhead. PalmOS can talk serial natively, so why not use that straight away? Actually "network sync" is essentially a 1:1 copy of serial sync (which was invented first), as is USB sync. Regards, Helge