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
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 [email protected].
>>
>
>
>> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
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 [email protected].
>
> >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
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 [email protected].
>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
On Mon, 18 May 2009 12:21:22 -0700
"Wilson, Scott" <[email protected]> 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 [email protected].
James
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
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 <[email protected]> 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 [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
--
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
-----Original Message-----
From: Johan Hedberg [mailto:[email protected]]
Sent: 17 June, 2009 11:13
To: John Frankish
Cc: [email protected]
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...
-----Original Message-----
From: Brad Midgley [mailto:[email protected]]
Sent: 17 June, 2009 10:28
To: John Frankish
Cc: [email protected]
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
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
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
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
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
-----Original Message-----
From: Artem Makhutov [mailto:[email protected]]
Sent: 16 June, 2009 23:22
To: John Frankish
Cc: [email protected]
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
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
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
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Brad Midgley
Sent: 14 May, 2009 08:46
To: Artem Makhutov
Cc: [email protected]
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 <[email protected]> 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 [email protected]
> 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