From owner-freebsd-bluetooth@FreeBSD.ORG Mon May 19 23:56:23 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 C6EB3106564A for ; Mon, 19 May 2008 23:56:23 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by mx1.freebsd.org (Postfix) with ESMTP id 4CEC88FC1E for ; Mon, 19 May 2008 23:56:23 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by nf-out-0910.google.com with SMTP id h3so1034549nfh.33 for ; Mon, 19 May 2008 16:56:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Nwa/uld+bnIENkNuHiptkDUU4P7NfU1V01P3mALIvUQ=; b=uDaIe7On+O/A/LN5Mlwla8MVGLhuGDKoMDmv5oYWDIxJhYv8mk9x+KYXfsVVREs6pLdjGLZujaUDppv4Fe2vLNUyxZ52AsVWF+D3UXd4s3lKgEbSH+ADyxz/HMe+L6Qi+ztgVTyMgQHxK4nLidz67Ky8Y9JRU+2ZUZ3/QKXb840= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=x53uwhKcEdbVAI//dmZCU52/7W3vD4YlcG5cqnT9/zwjiLnwOB0vFW5bMiwcKT8wOuGqNdkp1gjRmPuMmih6jUWqTgJqQBDo/9Fe4bIFGZawfT+WgMD7gSbuTwoA4jd4lc8MXmMMNUwZtrVyrKF7YC2FwRFRrb+ObCwGvG2qmqI= Received: by 10.125.100.8 with SMTP id c8mr630306mkm.144.1211241381739; Mon, 19 May 2008 16:56:21 -0700 (PDT) Received: by 10.86.66.5 with HTTP; Mon, 19 May 2008 16:56:21 -0700 (PDT) Message-ID: Date: Mon, 19 May 2008 16:56:21 -0700 From: "Maksim Yevmenkin" To: "Daniel O'Connor" In-Reply-To: <200805200845.57007.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200805141647.m4EGlUP1021019@repoman.freebsd.org> <200805181952.00112.doconnor@gsoft.com.au> <200805200845.57007.doconnor@gsoft.com.au> Cc: "freebsd-bluetooth@freebsd.org" Subject: Re: cvs commit: src/usr.bin/bluetooth/rfcomm_sppd rfcomm_sppd.1 rfcomm_sppd.c 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: Mon, 19 May 2008 23:56:23 -0000 On Mon, May 19, 2008 at 4:15 PM, Daniel O'Connor wrote: > On Tue, 20 May 2008, Maksim Yevmenkin wrote: >> > I am thinking of an operating mode where a script or daemon runs >> > when a device associates and sets up channels the user has >> > configured. So the script runs rfcomm_sppd and groks the output to >> > find what PTY has been allocated and creates a symlink to a human >> > understandable name (eg /dev/gps0 or whatever) >> >> right, that is what i initially wanted to do. the idea was to have >> complicated configuration file which describes what what >> rfcomm_sppd(1) should do when a device with a given bd_addr connects > > Shouldn't be that complex ;) well, yes :) >> on a certain rfcomm channel. then i realized that serial port service >> is not really good candidate for multiplexing. it all boils down to >> the fact that only one client can use virtual serial port at a time. > > Why would you be multiplexing it? It's a virtual serial port, pty sounds > like a pretty good match. ie I think I am misunderstanding what you are > trying to say. ok, i will give you an example. lets say i have a couple of bluetooth devices. lets say device #1 is a handheld and device #2 is some other client device that wants to use serial port service on the pc. say, its a bluetooth scanner/keyboard/etc. type device that proactively connects to the host computer and sends stream of data. with virtual serial port there is no real need to register two (or more) serial port services on the host pc. one could argue that rfcomm_sppd(1) should have a configuration file that says if connected to device #1 { execute sync application } if connected to device #2 { dump data } technically, both devices could use the same serial port service registered on the same rfcomm channel on the same host pc. the data coming from two different rfcomm connections from two different devices. the server bluetooth endpoint just happens to be the same, but the server will have two connections and two separate pty's for both clients. this is the soft of multiplexing i'm talking about. the same will work in client mode too. >> > I have attached a patch which uses openpty() and seems to work fine >> > (tested quickly against my BT GPS unit & phone). If the patch >> > doesn't make it you can get it from >> > http://www.gsoft.com.au/~doconnor/rfcomm_sppd-pty.diff >> >> i do not see how slave pty name is being passed back to >> rfcomm_sppd(1) invoker in _server_ mode. are you suggesting to parse >> syslog messages? or are you suggesting to have other process that is > > Mmm good point :( > I was thinking that in server mode it opened the PTY then waited for a > connection but that isn't the case.. this is the case. it opens pty first then it does listen/accept/etc. > I guess it could be (although it mangles up the code) > >> actively looking for "known" bluetooth devices in range (i.e. perform >> discovery or ping) and, when found, proactively start rfcomm_sppd(1) >> in _client_ mode to connect to found devices? > > I was thinking basically of only using client mode - I haven't used > server mode so it didn't really enter my thoughts :) > > As you say I was thinking that you poll for known devices (that the user > has entered into a config file) and run rfcomm_sppd in client mode to > connect to them. > > I am not sure how/why server mode is actually used - I only have > experience with devices that are basically using BT as an RS232 > replacement. right, there aren't many examples of server mode usage, but i was thinking about "serial console" over bluetooth type thing. of course it will never be a real serial console, just another out-of-band access. could be useful to somebody. thanks, max