From: Eugene Crosser <crosser@average.org>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: Dave Henriksen <dhenriksen@optibrand.com>,
BlueZ Mailing List <bluez-devel@lists.sourceforge.net>
Subject: Re: [Bluez-devel] Device specific pins
Date: Tue, 27 Jan 2004 10:05:39 +0300 [thread overview]
Message-ID: <1075187139.9727.29.camel@pccross.average.org> (raw)
In-Reply-To: <1075151423.25442.135.camel@pegasus>
[-- Attachment #1: Type: text/plain, Size: 1430 bytes --]
On Tue, 2004-01-27 at 00:10, Marcel Holtmann wrote:
> > Just wondering if there is any way to have pins that vary depending upon
> > what device you are connecting to. Currently, I just use
> > /etb/bluetooth/givepin to supply a pin, but this pin must be the same
> > for every device that my Linux laptop connects to.
>
> this is a planned future for the new security manager which also
> includes one-time PIN codes.
>
> For the current version you must do it by yourself in a pin-helper
> script. The BD_ADDR of the remote device is one of the parameters.
Do you think it might be right to leave "low level" PIN management as it
is now, via an executable helper? It is very much the same way as
kernel "hotplug" works. So it can stay the same even if hcid eventually
becomes a kernel thread.
The "real" PIN management, with the database, GUI prompt boxes etc.
could be isolated from the BT stack, helper executable being the only
interface.
E.g., a Gnome or KDE applet could listen on a unix domain socket. The
helper, when invoked, would try to talk over this socket, and if the
latter is not present or nobody listens on it, default to preexisting
database. This way, both fancy GUI dialogues and unattended operation
could be implemented rather easily.
Sorry if I say stupid or trivial things, I did not really try to learn
how these things are currently done in Blues..
Eugene
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2004-01-27 7:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-26 21:44 [Bluez-devel] Device specific pins Dave Henriksen
2004-01-26 21:10 ` Marcel Holtmann
[not found] ` <1075157711.3751.1.camel@linux.local>
2004-01-26 23:26 ` Marcel Holtmann
2004-01-27 7:05 ` Eugene Crosser [this message]
2004-01-27 14:10 ` Marcel Holtmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1075187139.9727.29.camel@pccross.average.org \
--to=crosser@average.org \
--cc=bluez-devel@lists.sourceforge.net \
--cc=dhenriksen@optibrand.com \
--cc=marcel@holtmann.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.