From owner-freebsd-bluetooth@FreeBSD.ORG Mon May 19 20:07:13 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 8E48210656C0 for ; Mon, 19 May 2008 20:07:13 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mx1.freebsd.org (Postfix) with ESMTP id 865D38FC1E for ; Mon, 19 May 2008 20:07:12 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by ug-out-1314.google.com with SMTP id q2so705029uge.37 for ; Mon, 19 May 2008 13:07:11 -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=ml9AyuQVmKtPU5u/ZumRDfiL7UCIcMlE+HclpQJgOls=; b=ejQwnFGwpYffVMzDYs/lb/g9oM1Zj/ggsWwITVF/sXmlTYFh1YcuAUaGhD13BDTkugaCLH01HLquR82S482G8kQijmr3/ho9VtVJCkq8hfWRxsYSvHNMt1Iu1dFWB4tCQ1m3qC8bI+c1fnTdrJp7qWngYVuJPVQe4xZqcI7lpks= 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=AWDrQ8EijOMnBAQcdRXNcU/Rag/m/SQSXeA8T4R6IrofxldgPnekJiCAr4G5UhsksQnQ2sANjwF6LrPTq3+rygZLl3S83uqcD6JxXMiresm1J1mWnL0O00Ni04QXRuT72+RVe6puE5YV0awQoATemNPMI4iTTSl6VRJy8WuZ+/M= Received: by 10.125.164.9 with SMTP id r9mr6401351mko.121.1211227631151; Mon, 19 May 2008 13:07:11 -0700 (PDT) Received: by 10.86.66.5 with HTTP; Mon, 19 May 2008 13:07:11 -0700 (PDT) Message-ID: Date: Mon, 19 May 2008 13:07:11 -0700 From: "Maksim Yevmenkin" To: "Daniel O'Connor" In-Reply-To: <200805181952.00112.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> <200805151814.14386.doconnor@gsoft.com.au> <200805181952.00112.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 20:07:13 -0000 On Sun, May 18, 2008 at 3:21 AM, Daniel O'Connor wrote: > On Thu, 15 May 2008, Maksim Yevmenkin wrote: >> > How hard would it be to have a '-t auto' and have it print out the >> > pty it just allocated? It would make it much easier for scripts to >> > work if that was possible. >> > >> > (Maybe just call openpty()?) >> >> not hard at all. however, how would rfcomm_sppd(1) print tty name if, >> say, it was asked to run in background? perhaps it would be better to >> teach rfcomm_sppd(1) to work with nmdm(4)? > > I don't think nmdm would make a difference in this respect. it depends on usage scenario, imo. please read below. > 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 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. i chose pty(4) over nmdm(4) initially to be able to a) call openpty() b) fork() c) redirect child's stdin/out to pty d) exec() something in child. that is similar to how rfcomm_pppd(8) wrapper works (without doing pty part). as i thought about it a bit more, i convinced myself that it probably would be much easier to run multiple instances of rfcomm_sppd(1) on different channels. each instance would then do something different. i still need to write the part where rfcomm_sppd(1) executes something external when client connects. > 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 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? > On a related note I find I have to 'kill -9' rfcomm_sppd sometimes if I > have connected to the PTY and then disconnected, eg.. hmm... interesting... i will take a look. just need to find my old bluetooth gps unit. thanks, max