Passkey-Agent for bluez 4.xx

Passkey-Agent for bluez 4.xx

[Wilson, Scott]

All,

>Hello,

>Brad Midgley schrieb:
>> Artem,
>>
>> It may not be the best way, but I modified simple-agent from tests
>> with a hardcoded pin, then I run it in the background at startup.
>> Replace 5555 with your pin.

>Thanks for your reply.

>I have tired this. It works only with the 1st bluetooth device in the
>system. It does not work with my 2nd bluetooth device. So it is not
>useable for me.

>Are there any other passkey-agents available?

>Thanks, Artem

I also have a similar issue, only mine involves Linux embedded on a
device. I have no agent running on the device at this time and therefore
pairing isn't working (which makes it hard for anything else to work).

At this point, I can either put Python on the device and use the
simple-agent python script to start the agent (which may be a job in
itself), or I can try and fix the test/agent.c program to suit my needs.

My question is, how hard would it be to fix the agent.c code myself?  It
seems that it is self contained and therefore not impossible to fix
myself.  But, could it be that since I am new to dbus and agents, I am
not seeing the entire picture?  Could someone lend me some assistance
and then I could submit my work back to the group?

My background is EE/Computer Eng. and I have been programming in
C/C++/Java for almost 20 years now.

Naturally, the problem for me is that I have a deadline looming
(beginning of June) so I need to have something working sooner rather
than later.

Any and all comments are welcome.

Thank you,

Scott Wilson

Re: Passkey-Agent for bluez 4.xx

[James Le Cuirot]

On Mon, 18 May 2009 12:21:22 -0700
"Wilson, Scott" <SCOTT.WILSON@CUBIC.COM> wrote:

> My question is, how hard would it be to fix the agent.c code myself?

Most of the work has been done, I believe. You should speak to Alan
Carvalho de Assis at acassis@gmail.com.

James

RE: Passkey-Agent for bluez 4.xx

[Wilson, Scott]

All,

Regarding my earlier post and the reply by James Le Cuirot:

>> My question is, how hard would it be to fix the agent.c code myself?

>Most of the work has been done, I believe. You should speak to Alan
>Carvalho de Assis at acassis@gmail.com.

>James

I have some additional questions:

While on the "full" Linux operating system (on a PC), some type of agent
is installed and executed for me in that environment.  Where is this
agent coming from?  How is it being executed for me? To my knowledge, I
have never installed an agent or configured one.

I can't seem to find many agent interactions in the Bluez code -
although I find references to it.  Not surprisingly, the main agent
reference is in test/agent.c.

When I go to execute my project on my embedded device, there is no
agent.  From all other aspects that I am aware of, the other things
(dbus, bluez, etc) seem to be similar (my team has already tackled those
challenges - although some may still remain).

Is it possible that this agent is not included with the dbus that runs
on the embedded device, but is on the PC?  Does Gnome include this
agent?  Does it come from the bluetooth-applet?

Any and all comments welcome.  Thank you in advance.

Regards,

Scott Wilson

RE: Passkey-Agent for bluez 4.xx

[Marcel Holtmann]

Hi Scott,

> >> My question is, how hard would it be to fix the agent.c code myself?
> 
> >Most of the work has been done, I believe. You should speak to Alan
> >Carvalho de Assis at acassis@gmail.com.
> 
> >James
> 
> I have some additional questions:
> 
> While on the "full" Linux operating system (on a PC), some type of agent
> is installed and executed for me in that environment.  Where is this
> agent coming from?  How is it being executed for me? To my knowledge, I
> have never installed an agent or configured one.
> 
> I can't seem to find many agent interactions in the Bluez code -
> although I find references to it.  Not surprisingly, the main agent
> reference is in test/agent.c.
> 
> When I go to execute my project on my embedded device, there is no
> agent.  From all other aspects that I am aware of, the other things
> (dbus, bluez, etc) seem to be similar (my team has already tackled those
> challenges - although some may still remain).
> 
> Is it possible that this agent is not included with the dbus that runs
> on the embedded device, but is on the PC?  Does Gnome include this
> agent?  Does it come from the bluetooth-applet?

the simple answer is yes. The agent is part of bluetooth-applet. Either
from bluez-gnome package or nowadays from gnome-bluetooth.

The agent is running in a userspace session, while bluetoothd running at
system level as root.

Other example agents are test/agent.c or simple-agent. Also KDE has its
own agent and so does the Maemo based devices.

Regards

Marcel

Re: Passkey-Agent for bluez 4.xx

[tmm]

Wilson, Scott wrote:
> All,
>
> Regarding my earlier post and the reply by James Le Cuirot:
>
>   
>>> My question is, how hard would it be to fix the agent.c code myself?
>>>       
>
>   
>> Most of the work has been done, I believe. You should speak to Alan
>> Carvalho de Assis at acassis@gmail.com.
>>     
>
>   
>> James
>>     
>
> I have some additional questions:
>
> While on the "full" Linux operating system (on a PC), some type of agent
> is installed and executed for me in that environment.  Where is this
> agent coming from?  How is it being executed for me? To my knowledge, I
> have never installed an agent or configured one.
>   
I'm not an expert on this, but I'll try to answer.

Both Gnome and KDE have their own agents, as part of their bluetooth 
management software.

The dbus and bluez on your embedded platform are probably the same as on 
a desktop distro, but this depends on which embedded platform/distro you 
are using.  There is no agent included with dbus or with a standard 
installation of bluez.  Bluez does contain the sample agents that you 
have already found, but they are not installed as part of bluez - they 
are just samples.  So, it's not that the dbus agent gets installed on 
desktop PC and not on embedded - it's that the dbus based agents are not 
really part of dbus, they are part of Gnome or KDE and you are not 
installing those.

Earlier in this thread it was mentioned that someone is already working 
on upgrading the v3 'C' sample agent to v4.  If you don't want to use 
Python then I think that that is what you want.

Tom.

> I can't seem to find many agent interactions in the Bluez code -
> although I find references to it.  Not surprisingly, the main agent
> reference is in test/agent.c.
>
> When I go to execute my project on my embedded device, there is no
> agent.  From all other aspects that I am aware of, the other things
> (dbus, bluez, etc) seem to be similar (my team has already tackled those
> challenges - although some may still remain).
>
> Is it possible that this agent is not included with the dbus that runs
> on the embedded device, but is on the PC?  Does Gnome include this
> agent?  Does it come from the bluetooth-applet?
>
> Any and all comments welcome.  Thank you in advance.
>
> Regards,
>
> Scott Wilson
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>   

Passkey-Agent for bluez 4.xx

[Artem Makhutov]

Hello,

I would like to use bluez 4.39.

What I am missing is a passkey-agant for the console.
Something like the old passkey-agent application in bluez 3.xx.

Since I have 2 bluetooth dongles, I need a passkey-agent that registers
it self as a default passkey-agent. And where I can enter a default pin,
that is used for all authentications.

The "passkey-agent" application from bluez 3.xx was pretty fine
(passkey-agent --default 1234).

How can I do the same with bluez 4.xx?

Thanks, Artem

Passkey-Agent for bluez 4.xx

[Artem Makhutov]

Hello,

I would like to use bluez 4.39.

What I am missing is a passkey-agant for the console.
Something like the old passkey-agent application in bluez 3.xx.

Since I have 2 bluetooth dongles, I need a passkey-agent that registers
it self as a default passkey-agent. And where I can enter a default pin,
that is used for all authentications.

The "passkey-agent" application from bluez 3.xx was pretty fine
(passkey-agent --default 1234).

How can I do the same with bluez 4.xx?

Thanks, Artem

Re: Passkey-Agent for bluez 4.xx

[Brad Midgley]

Artem,

It may not be the best way, but I modified simple-agent from tests
with a hardcoded pin, then I run it in the background at startup.
Replace 5555 with your pin.

#!/usr/bin/python

import gobject

import sys
import dbus
import dbus.service
import dbus.mainloop.glib

class Rejected(dbus.DBusException):
	_dbus_error_name = "org.bluez.Error.Rejected"

class Agent(dbus.service.Object):
	exit_on_release = True

	def set_exit_on_release(self, exit_on_release):
		self.exit_on_release = exit_on_release

	@dbus.service.method("org.bluez.Agent",
					in_signature="", out_signature="")
	def Release(self):
		print "Release"
		if self.exit_on_release:
			mainloop.quit()

	@dbus.service.method("org.bluez.Agent",
					in_signature="os", out_signature="")
	def Authorize(self, device, uuid):
		print "Authorize (%s, %s)" % (device, uuid)

	@dbus.service.method("org.bluez.Agent",
					in_signature="o", out_signature="s")
	def RequestPinCode(self, device):
		print "RequestPinCode (%s)" % (device)
		return "5555"

	@dbus.service.method("org.bluez.Agent",
					in_signature="o", out_signature="u")
	def RequestPasskey(self, device):
		print "RequestPasskey (%s)" % (device)
		passkey = raw_input("Enter passkey: ")
		return dbus.UInt32(passkey)

	@dbus.service.method("org.bluez.Agent",
					in_signature="ou", out_signature="")
	def DisplayPasskey(self, device, passkey):
		print "DisplayPasskey (%s, %d)" % (device, passkey)

	@dbus.service.method("org.bluez.Agent",
					in_signature="ou", out_signature="")
	def RequestConfirmation(self, device, passkey):
		print "RequestConfirmation (%s, %d)" % (device, passkey)
		confirm = raw_input("Confirm passkey (yes/no): ")
		if (confirm == "yes"):
			return
		raise Rejected("Passkey doesn't match")

	@dbus.service.method("org.bluez.Agent",
					in_signature="s", out_signature="")
	def ConfirmModeChange(self, mode):
		print "ConfirmModeChange (%s)" % (mode)

	@dbus.service.method("org.bluez.Agent",
					in_signature="", out_signature="")
	def Cancel(self):
		print "Cancel"

def create_device_reply(device):
	print "New device (%s)" % (device)
	mainloop.quit()

def create_device_error(error):
	print "Creating device failed: %s" % (error)
	mainloop.quit()

if __name__ == '__main__':
	dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)

	bus = dbus.SystemBus()
	manager = dbus.Interface(bus.get_object("org.bluez", "/"),
							"org.bluez.Manager")

	if len(sys.argv) > 1:
		path = manager.FindAdapter(sys.argv[1])
	else:
		path = manager.DefaultAdapter()

	adapter = dbus.Interface(bus.get_object("org.bluez", path),
							"org.bluez.Adapter")

	path = "/test/agent"
	agent = Agent(bus, path)

	mainloop = gobject.MainLoop()

	if len(sys.argv) > 2:
		if len(sys.argv) > 3:
			device = adapter.FindDevice(sys.argv[2])
			adapter.RemoveDevice(device)

		agent.set_exit_on_release(False)
		adapter.CreatePairedDevice(sys.argv[2], path, "DisplayYesNo",
					reply_handler=create_device_reply,
					error_handler=create_device_error)
	else:
		adapter.RegisterAgent(path, "DisplayYesNo")
		print "Agent registered"

	mainloop.run()

	#adapter.UnregisterAgent(path)
	#print "Agent unregistered"


On Wed, May 13, 2009 at 9:48 AM, Artem Makhutov <artem@makhutov.org> wrote:
> Hello,
>
> I would like to use bluez 4.39.
>
> What I am missing is a passkey-agant for the console.
> Something like the old passkey-agent application in bluez 3.xx.
>
> Since I have 2 bluetooth dongles, I need a passkey-agent that registers
> it self as a default passkey-agent. And where I can enter a default pin,
> that is used for all authentications.
>
> The "passkey-agent" application from bluez 3.xx was pretty fine
> (passkey-agent --default 1234).
>
> How can I do the same with bluez 4.xx?
>
> Thanks, Artem
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Brad Midgley

Re: Passkey-Agent for bluez 4.xx

[Artem Makhutov]

Hello,

Brad Midgley schrieb:
> Artem,
> 
> It may not be the best way, but I modified simple-agent from tests
> with a hardcoded pin, then I run it in the background at startup.
> Replace 5555 with your pin.

Thanks for your reply.

I have tired this. It works only with the 1st bluetooth device in the 
system. It does not work with my 2nd bluetooth device. So it is not 
useable for me.

Are there any other passkey-agents available?

Thanks, Artem

RE: Passkey-Agent for bluez 4.xx

[John Frankish]

-----Original Message-----
From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of Brad Midgley
Sent: 14 May, 2009 08:46
To: Artem Makhutov
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: Passkey-Agent for bluez 4.xx

Artem,

It may not be the best way, but I modified simple-agent from tests
with a hardcoded pin, then I run it in the background at startup.
Replace 5555 with your pin.

#!/usr/bin/python

import gobject

import sys
import dbus
import dbus.service
import dbus.mainloop.glib

class Rejected(dbus.DBusException):
        _dbus_error_name = "org.bluez.Error.Rejected"

class Agent(dbus.service.Object):
        exit_on_release = True

        def set_exit_on_release(self, exit_on_release):
                self.exit_on_release = exit_on_release

        @dbus.service.method("org.bluez.Agent",
                                        in_signature="", out_signature="")
        def Release(self):
                print "Release"
                if self.exit_on_release:
                        mainloop.quit()

        @dbus.service.method("org.bluez.Agent",
                                        in_signature="os", out_signature="")
        def Authorize(self, device, uuid):
                print "Authorize (%s, %s)" % (device, uuid)

        @dbus.service.method("org.bluez.Agent",
                                        in_signature="o", out_signature="s")
        def RequestPinCode(self, device):
                print "RequestPinCode (%s)" % (device)
                return "5555"

        @dbus.service.method("org.bluez.Agent",
                                        in_signature="o", out_signature="u")
        def RequestPasskey(self, device):
                print "RequestPasskey (%s)" % (device)
                passkey = raw_input("Enter passkey: ")
                return dbus.UInt32(passkey)

        @dbus.service.method("org.bluez.Agent",
                                        in_signature="ou", out_signature="")
        def DisplayPasskey(self, device, passkey):
                print "DisplayPasskey (%s, %d)" % (device, passkey)

        @dbus.service.method("org.bluez.Agent",
                                        in_signature="ou", out_signature="")
        def RequestConfirmation(self, device, passkey):
                print "RequestConfirmation (%s, %d)" % (device, passkey)
                confirm = raw_input("Confirm passkey (yes/no): ")
                if (confirm == "yes"):
                        return
                raise Rejected("Passkey doesn't match")

        @dbus.service.method("org.bluez.Agent",
                                        in_signature="s", out_signature="")
        def ConfirmModeChange(self, mode):
                print "ConfirmModeChange (%s)" % (mode)

        @dbus.service.method("org.bluez.Agent",
                                        in_signature="", out_signature="")
        def Cancel(self):
                print "Cancel"

def create_device_reply(device):
        print "New device (%s)" % (device)
        mainloop.quit()

def create_device_error(error):
        print "Creating device failed: %s" % (error)
        mainloop.quit()

if __name__ == '__main__':
        dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)

        bus = dbus.SystemBus()
        manager = dbus.Interface(bus.get_object("org.bluez", "/"),
                                                        "org.bluez.Manager")

        if len(sys.argv) > 1:
                path = manager.FindAdapter(sys.argv[1])
        else:
                path = manager.DefaultAdapter()

        adapter = dbus.Interface(bus.get_object("org.bluez", path),
                                                        "org.bluez.Adapter")

        path = "/test/agent"
        agent = Agent(bus, path)

        mainloop = gobject.MainLoop()

        if len(sys.argv) > 2:
                if len(sys.argv) > 3:
                        device = adapter.FindDevice(sys.argv[2])
                        adapter.RemoveDevice(device)

                agent.set_exit_on_release(False)
                adapter.CreatePairedDevice(sys.argv[2], path, "DisplayYesNo",
                                        reply_handler=create_device_reply,
                                        error_handler=create_device_error)
        else:
                adapter.RegisterAgent(path, "DisplayYesNo")
                print "Agent registered"

        mainloop.run()

        #adapter.UnregisterAgent(path)
        #print "Agent unregistered"


On Wed, May 13, 2009 at 9:48 AM, Artem Makhutov <artem@makhutov.org> wrote:
> Hello,
>
> I would like to use bluez 4.39.
>
> What I am missing is a passkey-agant for the console.
> Something like the old passkey-agent application in bluez 3.xx.
>
> Since I have 2 bluetooth dongles, I need a passkey-agent that registers
> it self as a default passkey-agent. And where I can enter a default pin,
> that is used for all authentications.
>
> The "passkey-agent" application from bluez 3.xx was pretty fine
> (passkey-agent --default 1234).
>
> How can I do the same with bluez 4.xx?
>
> Thanks, Artem
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

I tried out the modified simple-agent:

$ sudo passkey-agent_mod
Agent registered
[in separate terminal]
# bluetoothd -dn
...
bluetoothd[10350]: Agent registered for hci0 at :1.7:/test/agent

..but what next - do I specify the bt address of the device I would like to pair with PIN 5555, or?

Thanks, John

Re: Passkey-Agent for bluez 4.xx

[Timothy Murphy]

On Tuesday 16 June 2009 14:07:12 John Frankish wrote:

> It may not be the best way, but I modified simple-agent from tests
> with a hardcoded pin, then I run it in the background at startup.
> Replace 5555 with your pin.

1. I didn't understand exactly how to use your program.
Do you run it in the background?

2. How exactly is one meant to pair devices in Bluez
if one is running KDE (under Fedora)?

Kdebluetooth 4 (or kbluetooth4) seems to be intended for this purpose
(what other purpose could it have?) but it does not work
as far as I can see.

3. I don't understand why one cannot put the Bluetooth PIN
in a file, as one used to be able to do.

4. It seems to me a great pity that I have to run Windows
in order to pair with my Sony-Ericsson phone.

-- 
Timothy Murphy  
e-mail: gayleard /at/ eircom.net
tel: +353-86-2336090, +353-1-2842366
s-mail: School of Mathematics, Trinity College Dublin 

Re: Passkey-Agent for bluez 4.xx

[Johan Hedberg]

Hi,

On Tue, Jun 16, 2009, Timothy Murphy wrote:
> 3. I don't understand why one cannot put the Bluetooth PIN
> in a file, as one used to be able to do.

Most of the times I've heard people requesting this feature it has turned
out that they didn't understand what pairing is and what role the PIN
plays in it. The purpose of pairing is to create a common link key between
two devices. The link key can also be reused in later connections to avoid
pairing again. The purpose of the pin is to act as a one-time input in
this pairing process to create the common link key. It is the link key
that you want permanently stored so you don't need to repair when
connecting later, and bluez already does this for you.

So, the value of having a fixed PIN somewhere in the system is in most
cases rather low since pairing is an infrequent event after which the
generated link key is used to establish secure connections between the
devices. Having a fixed PIN has also the security implication that anyone
who knows your address can create a pairing with you without any knowledge
of the local user. However, bluez doesn't want to define or enforce rules
for where the PIN comes from. Instead, bluez externalizes the whole
process using the agent concept so you are free to have whatever kind of
mechanism you want (e.g. reading the PIN from the filesystem) for replying
to PIN requests.

Johan

Re: Passkey-Agent for bluez 4.xx

[Simon Kenyon]

Johan Hedberg wrote:
> Most of the times I've heard people requesting this feature it has turned
> out that they didn't understand what pairing is and what role the PIN
> plays in it. The purpose of pairing is to create a common link key between
> two devices. The link key can also be reused in later connections to avoid
> pairing again. The purpose of the pin is to act as a one-time input in
> this pairing process to create the common link key. It is the link key
> that you want permanently stored so you don't need to repair when
> connecting later, and bluez already does this for you.
>
> So, the value of having a fixed PIN somewhere in the system is in most
> cases rather low since pairing is an infrequent event after which the
> generated link key is used to establish secure connections between the
> devices. Having a fixed PIN has also the security implication that anyone
> who knows your address can create a pairing with you without any knowledge
> of the local user. However, bluez doesn't want to define or enforce rules
> for where the PIN comes from. Instead, bluez externalizes the whole
> process using the agent concept so you are free to have whatever kind of
> mechanism you want (e.g. reading the PIN from the filesystem) for replying
> to PIN requests.
>   
maybe it is because the documentation is a little, how can i put it, light
--
simon

Re: Passkey-Agent for bluez 4.xx

[Artem Makhutov]

Hi,

> [...]
> I tried out the modified simple-agent:
> 
> $ sudo passkey-agent_mod
> Agent registered
> [in separate terminal]
> # bluetoothd -dn
> ...
> bluetoothd[10350]: Agent registered for hci0 at :1.7:/test/agent
> 
> ..but what next - do I specify the bt address of the device I would like to pair with PIN 5555, or?

You should issue the pairing from your mobile phone. I don't know how to start pairing from the console.

Regards, Artem

RE: Passkey-Agent for bluez 4.xx

[John Frankish]

-----Original Message-----
From: Artem Makhutov [mailto:artem@makhutov.org]
Sent: 16 June, 2009 23:22
To: John Frankish
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: Passkey-Agent for bluez 4.xx

Hi,

> [...]
> I tried out the modified simple-agent:
>
> $ sudo passkey-agent_mod
> Agent registered
> [in separate terminal]
> # bluetoothd -dn
> ...
> bluetoothd[10350]: Agent registered for hci0 at :1.7:/test/agent
>
> ..but what next - do I specify the bt address of the device I would like to pair with PIN 5555, or?

You should issue the pairing from your mobile phone. I don't know how to start pairing from the console.

Regards, Artem
---------------
Thanks - I was afraid you were going to say that...

For some reason, my laptop does not appear to be discoverable from my mobile phone (even though everything seems to be set correctly in /etc/bluetooth/main.conf) - is there a trick to this?

Regards, John

Re: Passkey-Agent for bluez 4.xx

[Johan Hedberg]

Hi,

On Wed, Jun 17, 2009, John Frankish wrote:
> You should issue the pairing from your mobile phone. I don't know how to
> start pairing from the console.

The very same script you're discussing here (both the modified with the
'5555' and the unmodified version) acts as an passive acceptor for pairing
when you run it without arguments and as an initiator for pairing when you
give it two arguments.  So something like

./simple-agent hci0 <remote address>

should initiate a pairing from the command line to the remote device. This
has btw been discussed a few times on the mailing lists and you'd probably
also have found the answer by googling "bluez simple-agent" or something
similar.

Johan

RE: Passkey-Agent for bluez 4.xx

[John Frankish]

-----Original Message-----
From: Johan Hedberg [mailto:johan.hedberg@gmail.com]
Sent: 17 June, 2009 11:13
To: John Frankish
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: Passkey-Agent for bluez 4.xx

Hi,

On Wed, Jun 17, 2009, John Frankish wrote:
> You should issue the pairing from your mobile phone. I don't know how to
> start pairing from the console.

The very same script you're discussing here (both the modified with the
'5555' and the unmodified version) acts as an passive acceptor for pairing
when you run it without arguments and as an initiator for pairing when you
give it two arguments.  So something like

./simple-agent hci0 <remote address>

should initiate a pairing from the command line to the remote device. This
has btw been discussed a few times on the mailing lists and you'd probably
also have found the answer by googling "bluez simple-agent" or something
similar.

Johan

----
Thanks - ./simple-agent hci0 <remote address> does indeed work and the terminal window feedback (as opposed to bluez-gnome) also enabled me to find that the reason I could not pair using the more recent /etc/dbus-1/system.d/bluetooth.conf was that you need to be root to do so, which wasn't the case circa bluez-4.17

As for google etc, believe me I passed several hours trying to find enlightenment on this subject

Now to see if I can get a bt headset working with bluez-4.41...

Re: Passkey-Agent for bluez 4.xx

[Brad Midgley]

John,

> Thanks - ./simple-agent hci0 <remote address> does indeed work and the terminal window feedback (as opposed to bluez-gnome) also enabled me to find that the reason I could not pair using the more recent /etc/dbus-1/system.d/bluetooth.conf was that you need to be root to do so, which wasn't the case circa bluez-4.17

if bluez-gnome is silently failing or issuing an error that doesn't
help, it would help if you make sure there's a ticket. It looks like
the list to check is
http://bugzilla.gnome.org/buglist.cgi?query=product%3Agnome-bluetooth+

-- 
Brad Midgley

Re: Passkey-Agent for bluez 4.xx

[Brad Midgley]

John,

> ..but what next - do I specify the bt address of the device I would like to pair with PIN 5555, or?

make your laptop discoverable and connect to it from the other device.
That was the purpose of this script, to set the pin for incoming
connections.

To make it discoverable, use the kde or gnome applet for bluetooth or
have a look at bluez-4.26/test/test-discovery for a headless machine.

-- 
Brad Midgley

RE: Passkey-Agent for bluez 4.xx

[John Frankish]

-----Original Message-----
From: Brad Midgley [mailto:bmidgley@gmail.com]
Sent: 17 June, 2009 10:28
To: John Frankish
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: Passkey-Agent for bluez 4.xx

John,

> ..but what next - do I specify the bt address of the device I would like to pair with PIN 5555, or?

make your laptop discoverable and connect to it from the other device.
That was the purpose of this script, to set the pin for incoming
connections.

To make it discoverable, use the kde or gnome applet for bluetooth or
have a look at bluez-4.26/test/test-discovery for a headless machine.

--
Brad Midgley

----

Thanks, but I'm confused here - using ./simple-agent hci0 <remote address> wakes up the remote device and prompts the user to enter a PIN on the remote device.

What I don't understand is why, when using this:

# bluetoothd -dn
bluetoothd[6044]: Bluetooth daemon 4.41
bluetoothd[6044]: Enabling debug information
bluetoothd[6044]: parsing main.conf
bluetoothd[6044]: discovto=0
bluetoothd[6044]: pairto=0
bluetoothd[6044]: pageto=8192
bluetoothd[6044]: name=box
bluetoothd[6044]: class=0x000100
bluetoothd[6044]: discov_interval=0

..that the remote device cannot see "box" when it can see every other device in the vicinity

Regards, John