Date: Mon, 19 May 2008 16:56:21 -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: <bb4a86c70805191656m46af1eafo310bb3782459e23d@mail.gmail.com> In-Reply-To: <200805200845.57007.doconnor@gsoft.com.au> References: <200805141647.m4EGlUP1021019@repoman.freebsd.org> <200805181952.00112.doconnor@gsoft.com.au> <bb4a86c70805191307t2db86a09n95208de9ea4524ad@mail.gmail.com> <200805200845.57007.doconnor@gsoft.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, May 19, 2008 at 4:15 PM, Daniel O'Connor <doconnor@gsoft.com.au> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bb4a86c70805191656m46af1eafo310bb3782459e23d>