From: Rainer Dorsch <rdorsch@web.de>
To: bluez-users@lists.sourceforge.net
Subject: Re: [Bluez-users] pand seem to ignore any pin configurations
Date: Sun, 8 May 2005 17:27:28 +0200 [thread overview]
Message-ID: <200505081727.29246.rdorsch@web.de> (raw)
In-Reply-To: <1115559373.9031.60.camel@pegasus>
Hi Marcel,
Am Sonntag, 8. Mai 2005 15:36 schrieb Marcel Holtmann:
> > > if you use "security user" then the PIN is provided through the PIN
> > > helper script.
> >
> > and auto just uses the pin in
> >
> > /etc/bluetooth/pin ?
>
> for incoming connection, yes.
>
> > Then all the helper scripts in the net which print out
> >
> > PIN: <content of /etc/bluetooth/pin>
> >
> > are nonsense?
>
> No. Why should they. The script got called and then it reads the pin and
> writes it to standard out. Think about it ;)
Wouldn't be
security auto
the same as
security user
# PIN helper
# pin_helper /usr/bin/bluez-pin;
pin_helper /usr/local/sbin/mypin
and /usr/local/sbin/mypin, containing
#!/bin/sh
PIN=`cat /etc/bluetooth/pin`
echo "PIN:$PIN"
?
> > Hmm....is pairing persistent over rebooting one or both systems (NAP:
> > security auto and PANU: security user)? At least that is what I did and I
> > did not enter a password. pin_helper is bluez-pin on the PANU, so I
> > expect that PANU should have querried for a password in any case.
>
> The pairing itself is persistent over reboots and also unplugging. The
> link keys are also cached inside the chip and so Authentication
> Requested must not always result in asking for the link key or pin code.
>
> > Replugging the usb bt dongle restarts bluez-utils. Is pairing persistent
> > over restarting bluez-utils?
> >
> > Is it ok that pand on the PANU dies after connection establishment?
> >
> > root 4296 0.0 0.2 1548 492 ? S< 14:48 0:00
> > /usr/bin/pand --nodetach --role PANU --search --encrypt
> > root 4303 0.0 0.2 1548 472 pts/2 S+ 14:49 0:00 grep pand
> > topsi:~# ps uaxwww|grep pand
> > root 4397 0.0 0.2 1548 472 pts/2 S+ 14:50 0:00 grep pand
> > topsi:~#
> >
> >
> > I did an hcidump after replugging the bt usb dongle on PANU, hcidump is
> > also
> >
> > on PANU:
> > > HCI Event: Link Key Request (0x17) plen 6
> >
> > 0000: 9f 24 82 61 04 00 .$.a..
> > < HCI Command: Link Key Request Reply (0x01|0x000b) plen 22
> > 0000: 9f 24 82 61 04 00 bf 9c 53 9d f1 8e fb 60 50 c7
> > .$.a....S....`P. 0010: 11 26 ac e3 16 06
> > .&....
> >
> > > HCI Event: Command Complete (0x0e) plen 10
> >
> > Link Key Request Reply (0x01|0x000b) ncmd 1
> > 0000: 00 9f 24 82 61 04 00 ..$.a..
>
> It asks for the link key and so you are pairing. To always be asked for
> the PIN code I think you need to change hcid to allow a mode where you
> always have to redo the pairing. In this case the Link Key Request must
> be answered with a Link Key Request Negative Reply. This effect can also
> be reached by deleted the link key from the local storage.
Not asking for a PIN each time is actually fine (persisten pairing is a nice
invention;-). I just want to check that the system really wants to see a PIN
when a new device comes in.
Are you saying when I delete
/etc/bluetooth/link_key
on both NAP and PANU I should be askef for a password?
Thanks,
Rainer
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: NEC IT Guy Games.
> Get your fingers limbered up and give it your best shot. 4 great events, 4
> opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
> win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
> _______________________________________________
> Bluez-users mailing list
> Bluez-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-users
--
Rainer Dorsch
Alzentalstr. 28
D-71083 Herrenberg
07032-919495
Icq: 32550367
-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users
next prev parent reply other threads:[~2005-05-08 15:27 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-07 20:03 [Bluez-users] pand seem to ignore any pin configurations Rainer Dorsch
2005-05-07 20:35 ` Marcel Holtmann
2005-05-07 21:39 ` Rainer Dorsch
2005-05-07 22:02 ` Marcel Holtmann
2005-05-08 13:08 ` Rainer Dorsch
2005-05-08 13:36 ` Marcel Holtmann
2005-05-08 15:27 ` Rainer Dorsch [this message]
2005-05-08 15:46 ` Marcel Holtmann
2005-05-08 16:24 ` Rainer Dorsch
2005-05-08 16:31 ` 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=200505081727.29246.rdorsch@web.de \
--to=rdorsch@web.de \
--cc=bluez-users@lists.sourceforge.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox