Dear friends,
I have installed bluez-4.52 with linux-2.6.30 on my arm board. I m
trying to connect to headset but because of unavailability of linkkey
I can't obtain connection.
Is there any provision for linkkey generation for pairing in
bluez-4.52? Any tool available that can be run on arm-linux board? I
can't go for bluez-gnome else I need to install all its dependencies
which will add more load in terms of memory.
--
Kartikey Parmar
R&D Software Engg
Matrix Telecom Pvt Ltd
Baroda, Gujarat (India)
Hi,
On Wed, Sep 16, 2009 at 3:39 PM, Florian Philipp <[email protected]> wrote:
> Well, I'm pretty sure some other guys came up with the exact same
> question which was the start of this thread at various occasions last
> year or so (i.e. wanting to have a simple daemon-like pin helper). From
> your post I read that you acknowledge that this functionality which
> those other guys and me miss in bluez is something you'd like to have
> back in, right?
>
> So, if any solution, maybe heavily based on those two test programs
> would really make it back into upstream and would not be dropped because
> it somehow does not fit in the current design or whatever (that's what
> my original question was because the functionality _was already there_
> in 2.x), then why is the answer to those requests always "Do it
> yourself" and not at least "Do it yourself and maybe send it to us so we
> can merge it into upstream"?
>
> That's exactly what I wanted to know in the first place: Why you would
> not want this functionality in bluez but rather put people requesting it
> down with "Do it yourself (and leave us alone)". At least that was my
> impression.
Actually I think agent.c can be used for what seems to be your use
case, you need a pincode helper which handle pincode requests with a
predefined pincode which is what agent will do if you pass a pincode
e.g. agent 1234. Also you are free to suggest improvements, we are
very happy to accept patches from anyone as you can see from the
commit logs.
--
Luiz Augusto von Dentz
Engenheiro de Computa??o
Johan Hedberg schrieb:
> Hi,
>
> On Wed, Sep 16, 2009, Florian Philipp wrote:
>> Of course I can't force you to do the programming but removing
>> functionality which worked - more or less - out of the box with an older
>> release and not providing any working alternative except of a
>> do-it-yourself solution ... well ... just sounds wrong.
>
> I think part of the explanation is lack of knowledge about exactly in
> which ways people use BlueZ and how popular these use cases are. To be
> honest, I'm not sure I still understand exactly what kind of behavior or
> feature you're after.
>
Okay, it's easy to explain it. What I originally set up in late 2007
resembles what is commonly called a "wlan router" just with bluetooth
instead of IEEE-802.11. It's a bluetooth GN with a pre-shared key. The
GN connects to an ethernet bridge with DHCP and DNS servers, NAT and
firewall for internet access. All built on a Gentoo Linux laptop.
It sure isn't one of the most common usages for bluetooth but it was
well supported at that time with lots of howtos and an easy setup. You
basically just had to put up some config files, a one line long script
for expanding the ethernet bridge for every connection and start the
daemon with the right parameters.
>> Okay, so without some significant work, you could only support legacy
>> pairing for those old deamons and I suppose that's all those test apps
>> can, right?
>
> Exactly which old daemons are you talking about? I don't see how any old
> software that isn't aware of the current pairing/agent interface could be
> made to work "without some significant work".
>
Apologies when I mix up some things here. It's not like I'm working with
bluez right now. I've left my current solution alone for at least 5
months and cared about other things.
As far as I remember, at least bluez-3.x had support for a legacy
interface which more or less resembled the old 2.x daemons. For some
reason that stopped to work for me (or maybe it never worked and I just
didn't notice until I needed the network again some months after the
update). Although I can't fully remember I'm pretty sure I never found
out why. When I searched help on this list, someone told me that 3.x was
too old for him to look into that problem and that I should move forward
to 4.x
Well, 4.x never worked for me so I went back to 2.x and here I am now.
>> a) Create and maintain the missing parts myself.
>
> If the functionality makes sense and the implementation follows the usual
> coding standards that we have I don't see why you would be stuck
> maintaining it yourself. Surely it should be possibe to merge the work
> with upstream.
>
Well, I'm pretty sure some other guys came up with the exact same
question which was the start of this thread at various occasions last
year or so (i.e. wanting to have a simple daemon-like pin helper). From
your post I read that you acknowledge that this functionality which
those other guys and me miss in bluez is something you'd like to have
back in, right?
So, if any solution, maybe heavily based on those two test programs
would really make it back into upstream and would not be dropped because
it somehow does not fit in the current design or whatever (that's what
my original question was because the functionality _was already there_
in 2.x), then why is the answer to those requests always "Do it
yourself" and not at least "Do it yourself and maybe send it to us so we
can merge it into upstream"?
That's exactly what I wanted to know in the first place: Why you would
not want this functionality in bluez but rather put people requesting it
down with "Do it yourself (and leave us alone)". At least that was my
impression.
Hi,
On Wed, Sep 16, 2009, Florian Philipp wrote:
> Of course I can't force you to do the programming but removing
> functionality which worked - more or less - out of the box with an older
> release and not providing any working alternative except of a
> do-it-yourself solution ... well ... just sounds wrong.
I think part of the explanation is lack of knowledge about exactly in
which ways people use BlueZ and how popular these use cases are. To be
honest, I'm not sure I still understand exactly what kind of behavior or
feature you're after.
> Okay, so without some significant work, you could only support legacy
> pairing for those old deamons and I suppose that's all those test apps
> can, right?
Exactly which old daemons are you talking about? I don't see how any old
software that isn't aware of the current pairing/agent interface could be
made to work "without some significant work".
> a) Create and maintain the missing parts myself.
If the functionality makes sense and the implementation follows the usual
coding standards that we have I don't see why you would be stuck
maintaining it yourself. Surely it should be possibe to merge the work
with upstream.
Johan
Johan Hedberg schrieb:
> Hi,
>
> On Tue, Sep 15, 2009, Florian Philipp wrote:
>> Just out of curiosity: Why does Bluez no longer provide any kind of
>> deamon as a pin helper any more?
>
> Isn't that exactly what the two command line based agents are if you run
> them in the background and modify them to always accept pairing requests?
> Or am I misunderstanding your question?
I suppose these two programs would suit my needs just fine - if I modify
them as you suggested. I just don't understand the reasons why an
arbitrary number of users (including me) should be bothered to
write/modify/fork their own pin helper. If it is something so simple
that every user can do it himself, sure enough the official bluez devs
can do it too. The latter option would have some advantages:
- programming it one time instead of programming it n times
- me as a user can (to some degree) be confident that the app will still
work with the next release whereas a 'test program' might just be
dropped without any warning
- linux distributions could provide packages for it. Therefore me as a
user wouldn't have to maintain it, compile it against the newest bluez
libs after every automatic update, test it, etc.
Of course I can't force you to do the programming but removing
functionality which worked - more or less - out of the box with an older
release and not providing any working alternative except of a
do-it-yourself solution ... well ... just sounds wrong.
> Note that we can't anymore have
> interfaces which just deal with a simple PIN. Bluetooth 2.1 SSP brings
> along it's own set of callbacks that need handling and any interface that
> we define (be it a config file, D-Bus or something else) needs to take
> that into account.
>
Okay, so without some significant work, you could only support legacy
pairing for those old deamons and I suppose that's all those test apps
can, right?
>> I mean, it's not like Bluetooth itself is limited to interactive systems
>> which rightly demand graphical interfaces nowadays. Stuff like NAP is a
>> classic client-server situation in which you don't want to use Gnome or
>> KDE apps on the server side and maybe not even on the client side.
>
> The current agent interface design doesn't restrict you in any way to
> interactive systems. It merely exports the pairing callbacks from
> bluetoothd to an external process. bluetoothd doesn't care if that process
> does some interactive stuff or not.
>
I already understood that. It's just that the only programs which are
currently available (precompiled and ready to go) for me as a user are
interactive apps with dependencies on Gnome or KDE.
Do you understand what's my problem here? Bluetooth itself suits my
current needs just fine: Wireless network with less range, less
bandwidth and less power consumption than WLAN. That's why I adopted
bluetooth for this project of mine. Now with bluez-3.x or 4.x, Bluetooth
still suits my needs, it's just that the only available implementation
doesn't suit them any longer.
Now I have three options:
a) Create and maintain the missing parts myself.
b) Switch to WLAN which is far inferior for my use case but which will
work out-of-the-box with deamons like wpa_supplicant.
c) Stick with bluez-2.x until the situation becomes unbearable, then
think again.
Currently I'm with c)
Hi,
On Tue, Sep 15, 2009, Florian Philipp wrote:
> Just out of curiosity: Why does Bluez no longer provide any kind of
> deamon as a pin helper any more?
Isn't that exactly what the two command line based agents are if you run
them in the background and modify them to always accept pairing requests?
Or am I misunderstanding your question? Note that we can't anymore have
interfaces which just deal with a simple PIN. Bluetooth 2.1 SSP brings
along it's own set of callbacks that need handling and any interface that
we define (be it a config file, D-Bus or something else) needs to take
that into account.
> I mean, it's not like Bluetooth itself is limited to interactive systems
> which rightly demand graphical interfaces nowadays. Stuff like NAP is a
> classic client-server situation in which you don't want to use Gnome or
> KDE apps on the server side and maybe not even on the client side.
The current agent interface design doesn't restrict you in any way to
interactive systems. It merely exports the pairing callbacks from
bluetoothd to an external process. bluetoothd doesn't care if that process
does some interactive stuff or not.
Johan
Johan Hedberg schrieb:
> Hi,
>
> On Tue, Sep 15, 2009, Kartikey Parmar wrote:
>> I have installed bluez-4.52 with linux-2.6.30 on my arm board. I m
>> trying to connect to headset but because of unavailability of linkkey
>> I can't obtain connection.
>>
>> Is there any provision for linkkey generation for pairing in
>> bluez-4.52? Any tool available that can be run on arm-linux board? I
>> can't go for bluez-gnome else I need to install all its dependencies
>> which will add more load in terms of memory.
>
> You could try one of the sample agents that come with BlueZ, i.e.
> test/simple-agent or test/agent.c. Or then just write your own agent to
> suite your needs.
>
Just out of curiosity: Why does Bluez no longer provide any kind of
deamon as a pin helper any more?
I mean, it's not like Bluetooth itself is limited to interactive systems
which rightly demand graphical interfaces nowadays. Stuff like NAP is a
classic client-server situation in which you don't want to use Gnome or
KDE apps on the server side and maybe not even on the client side.
The lack of such functionality is one of the reasons which still keep me
on bluez-2.25. (lack of user documentation and howtos for >=3.x is the
other reason, by the way).
Just my two cents,
Florian Philipp
Hi,
On Tue, Sep 15, 2009, Kartikey Parmar wrote:
> I have installed bluez-4.52 with linux-2.6.30 on my arm board. I m
> trying to connect to headset but because of unavailability of linkkey
> I can't obtain connection.
>
> Is there any provision for linkkey generation for pairing in
> bluez-4.52? Any tool available that can be run on arm-linux board? I
> can't go for bluez-gnome else I need to install all its dependencies
> which will add more load in terms of memory.
You could try one of the sample agents that come with BlueZ, i.e.
test/simple-agent or test/agent.c. Or then just write your own agent to
suite your needs.
Johan