Date: Mon, 19 May 2008 13:07:11 -0700 From: "Maksim Yevmenkin" <maksim.yevmenkin@gmail.com> To: "Daniel O'Connor" <doconnor@gsoft.com.au> Cc: "freebsd-bluetooth@freebsd.org" <freebsd-bluetooth@freebsd.org> Subject: Re: cvs commit: src/usr.bin/bluetooth/rfcomm_sppd rfcomm_sppd.1 rfcomm_sppd.c Message-ID: <bb4a86c70805191307t2db86a09n95208de9ea4524ad@mail.gmail.com> In-Reply-To: <200805181952.00112.doconnor@gsoft.com.au> References: <200805141647.m4EGlUP1021019@repoman.freebsd.org> <200805151814.14386.doconnor@gsoft.com.au> <bb4a86c70805150657m23d90dcdp681f454b45c72ea@mail.gmail.com> <200805181952.00112.doconnor@gsoft.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, May 18, 2008 at 3:21 AM, Daniel O'Connor <doconnor@gsoft.com.au> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bb4a86c70805191307t2db86a09n95208de9ea4524ad>