Hello,
I am sorry I post here, but there is no user mailing list specified at [1] while
both links at [2] refer to this list. I will appreciate if you forward me to the
right place.
I try to figure out how to create bnep interface. It looks like one should have
vast knowledge in dbus and/or python in order to achieve this goal.
All the examples I found in the wiki [3] are for version 3.
Does anyone has a sample without python dependency (shell script) that
can create bnep interface on both ends for hidden (explicit mac) devices?
Alternatively, can anyone please tell me what is the uuid parameter
for org.bluez::org.bluez.Network::Connect?
The only place I see this is in org.bluez::org.bluez.Device::CreateNode,
but it specify that this is persistence object, and I don't want to use
persistence object. Or maybe dbus persistence is not stored between
bus initialization.
Anyway... I think the requirement for people to use dbus is truly
unusable... Providing simple solutions/scripts for common tasks
is required.
Thank you ,
Alon Bar-Lev.
[1] http://www.bluez.org/development/lists/
[2] http://www.bluez.org/contact/
[3] http://wiki.bluez.org/
Hi,
On Sat, Feb 28, 2009, Alon Bar-Lev wrote:
> I am sorry I post here, but there is no user mailing list specified at
> [1] while both links at [2] refer to this list. I will appreciate if
> you forward me to the right place.
Nope, as far as I understand this list is intended for both developer
and user issues.
> I try to figure out how to create bnep interface. It looks like one
> should have vast knowledge in dbus
If you're a developer, then yes. If you're a user the interface has already
failed at the point where it requires you to know what "bnep" is :)
As a user, you should ultimately be using some *user* interface (either
graphical or command line) which hides any complexities of the D-Bus
interface. The big fault from the BlueZ project's side is that it hasn't
provided proper command-line user tools for its D-Bus interface. I think
one of the reasons for this is that the existing tools like hcitool and
hciconfig along with the python scripts that come with the source have
been regarded as "good enough".
In the long run we're planing on doing a tool to replace exiting ones
like sdptool, hcitool and hciconfig. However, all that exists of that at
the moment is an empty client directory in the source tree and the
progress of it is simply dependent on developer free time and
motivation.
> and/or python in order to achieve this goal.
Why especially python? There's a plethora of different language bindings
available for D-Bus. You can find a list of them here:
http://www.freedesktop.org/wiki/Software/DBusBindings
> All the examples I found in the wiki [3] are for version 3.
That's right. Almost none of the info in the wiki has been updated since
3.x times. The most reliable 4.x API information are the doc/*-api.txt
files that come with bluez. Again, fixing of this depends completely on
peoples free time and motivation. In the long run the plan is to have
most documentation generated directly from the source tree. GTK-Doc
support is already there so all that's missing now is the content ;)
> Does anyone has a sample without python dependency (shell script) that
> can create bnep interface on both ends for hidden (explicit mac) devices?
I'm not aware of any D-Bus binding for shell languages (like bash).
There's the generic dbus-send command line tool provided by D-Bus but it
won't get you very far with the more complex interfaces. Just out of
curiosity, what kind of system are you using that doesn't have python
available? Some embedded device perhaps? (in which case the border
between a user and developer starts to get quite blurred).
> Alternatively, can anyone please tell me what is the uuid parameter
> for org.bluez::org.bluez.Network::Connect?
That's the Bluetooth UUID of the service you want to use. However the
interface will also accept "friendly" strings such as "nap" and "panu".
Admittedly doc/network-api.txt should be updated to list all of these
possibilities. It's much terse right now.
> Anyway... I think the requirement for people to use dbus is truly
> unusable...
I'll assume you mean "user" when you say "people". You're right of
course. The D-Bus interface was never intended for users. It was created
for developers to build user interfaces and while GUI's are out of scope
for the BlueZ project at least a command-line tool should be available
for users not wanting or being able to deal with GUI's.
> Providing simple solutions/scripts for common tasks is required.
Agreed. Right now for many tasks you can use the legacy command line
tools and even the old daemons like pand if you wish. For the D-Bus
interface there are the python scripts within the source tree and in the
long run we should hopefully have a proper command line user tool for
the D-Bus interface.
Johan
Thank you for your help!
On Sun, Mar 1, 2009 at 10:23 PM, Jelle de Jong
<[email protected]> wrote:
> Alon Bar-Lev wrote:
>> On Sat, Feb 28, 2009 at 10:03 PM, Johan Hedberg <[email protected]> wrote:
>>> Hi,
>>>
>>> On Sat, Feb 28, 2009, Alon Bar-Lev wrote:
>>>> I am sorry I post here, but there is no user mailing list specified at
>>>> [1] while both links at [2] refer to this list. I will appreciate if
>>>> you forward me to the right place.
>>> Nope, as far as I understand this list is intended for both developer
>>> and user issues.
>>
>> Oh..
>> """linux-bluetooth
>> This mailing list is for the kernel developer."""
>>
>> Needs an update :)
>>
>>
>>>> I try to figure out how to create bnep interface. It looks like one
>>>> should have vast knowledge in dbus
>>> If you're a developer, then yes. If you're a user the interface has already
>>> failed at the point where it requires you to know what "bnep" is :)
>>
>> I think that you have incorrect view of users/integrators/sysadmins.
>> There are many levels of complexity... One is to write something like
>> bluz, and the other is to create a single working entity out of many
>> components.
>> So developer of one solution can be a user of the other, and
>> sysadmin can be a user of many etc...
>>
>> Imagin you are a sysadmin or a user of all solutions but bluez,
>> and need to setup a working machine, if you don't have simple
>> utilities you end up in being an expert in each of the components,
>> or ends up with incomplete solution as you don't have enough time.
>>
>> Back in the CORBA time, at least we had decent command-line interface
>> so that I could enumerate, create and call methods. dbus failed
>> to provide such interface for automation.
>>
>> All I wanted is to connect two devices using bluez, using command-line.
>> Using the basic layout, automation and no UI...
>>
>> tun, ppp, bridge are all working great, providing decent command-line
>> interface and no extra dependencies (dbus).
>>
>>> As a user, you should ultimately be using some *user* interface (either
>>> graphical or command line) which hides any complexities of the D-Bus
>>> interface.
>>
>> All I know is dbus-send, do you have any other tool?
>>
>>> The big fault from the BlueZ project's side is that it hasn't
>>> provided proper command-line user tools for its D-Bus interface. I think
>>> one of the reasons for this is that the existing tools like hcitool and
>>> hciconfig along with the python scripts that come with the source have
>>> been regarded as "good enough".
>>
>> Can you please point me to a script in source tarball to created bnep
>> interface?
>>
>>>> and/or python in order to achieve this goal.
>>> Why especially python? There's a plethora of different language bindings
>>> available for D-Bus. You can find a list of them here:
>>> http://www.freedesktop.org/wiki/Software/DBusBindings
>>
>> Again, there is a major difference between a simple script and starting
>> dbus development. Why do I need to know dbus if I want to USE
>> bluez? Well... I understand I need to start learning or just use
>> PPP over rfcomm... At least I know how to set this up without
>> dbus knowledge.
>>
>>>> Does anyone has a sample without python dependency (shell script) that
>>>> can create bnep interface on both ends for hidden (explicit mac) devices?
>>> I'm not aware of any D-Bus binding for shell languages (like bash).
>>> There's the generic dbus-send command line tool provided by D-Bus but it
>>> won't get you very far with the more complex interfaces. Just out of
>>> curiosity, what kind of system are you using that doesn't have python
>>> available? Some embedded device perhaps? (in which case the border
>>> between a user and developer starts to get quite blurred).
>>
>> A user is a user of a component, he can be a developer of other software.
>> Nothing blurred. I just wanted to know that I understand correctly and
>> I need to develop my own software in order to use basic functionality.
>>
>> I thought that like iproute2 support tan/tap it can support bnep and
>> then all be happy :) But adding dbus dependency to core is not
>> wise.
>>
>>>> Alternatively, can anyone please tell me what is the uuid parameter
>>>> for org.bluez::org.bluez.Network::Connect?
>>> That's the Bluetooth UUID of the service you want to use. However the
>>> interface will also accept "friendly" strings such as "nap" and "panu".
>>> Admittedly doc/network-api.txt should be updated to list all of these
>>> possibilities. It's much terse right now.
>>
>> Can you please tell me what is the friendly string to set up bnep interface
>> to a specific device?
>>
>>>> Anyway... I think the requirement for people to use dbus is truly
>>>> unusable...
>>> I'll assume you mean "user" when you say "people". You're right of
>>> course. The D-Bus interface was never intended for users. It was created
>>> for developers to build user interfaces and while GUI's are out of scope
>>> for the BlueZ project at least a command-line tool should be available
>>> for users not wanting or being able to deal with GUI's.
>>
>> Great... Need a sample... :)
>>
>>>> Providing simple solutions/scripts for common tasks is required.
>>> Agreed. Right now for many tasks you can use the legacy command line
>>> tools and even the old daemons like pand if you wish. For the D-Bus
>>> interface there are the python scripts within the source tree and in the
>>> long run we should hopefully have a proper command line user tool for
>>> the D-Bus interface.
>>
>> I don't understand, I thought the pand is not needed anymore, no daemon
>> is needed, right? Or I miss something. Anyway, most distribution do not
>> install pand anymore...
>>
>> Thank you,
>> Alon.
>
> Hi Alon,
>
> Maybe this tool can help you for the gui side of your problems, yes I
> know its no command-line tool but its the best I can do for you.
>
> It's about the blueman tool:
> http://lists.debian.org/debian-mentors/2009/02/msg00277.html
>
> I provide the link to the archive, because I sent some mail to the
> thread. Maybe the bluez-gnome bluetooth-applet developers can read the
> thread too and provide there opinion about the issues?
>
> Best regards,
>
> Jelle de Jong
>
Alon Bar-Lev wrote:
> On Sat, Feb 28, 2009 at 10:03 PM, Johan Hedberg <[email protected]> wrote:
>> Hi,
>>
>> On Sat, Feb 28, 2009, Alon Bar-Lev wrote:
>>> I am sorry I post here, but there is no user mailing list specified at
>>> [1] while both links at [2] refer to this list. I will appreciate if
>>> you forward me to the right place.
>> Nope, as far as I understand this list is intended for both developer
>> and user issues.
>
> Oh..
> """linux-bluetooth
> This mailing list is for the kernel developer."""
>
> Needs an update :)
>
>
>>> I try to figure out how to create bnep interface. It looks like one
>>> should have vast knowledge in dbus
>> If you're a developer, then yes. If you're a user the interface has already
>> failed at the point where it requires you to know what "bnep" is :)
>
> I think that you have incorrect view of users/integrators/sysadmins.
> There are many levels of complexity... One is to write something like
> bluz, and the other is to create a single working entity out of many
> components.
> So developer of one solution can be a user of the other, and
> sysadmin can be a user of many etc...
>
> Imagin you are a sysadmin or a user of all solutions but bluez,
> and need to setup a working machine, if you don't have simple
> utilities you end up in being an expert in each of the components,
> or ends up with incomplete solution as you don't have enough time.
>
> Back in the CORBA time, at least we had decent command-line interface
> so that I could enumerate, create and call methods. dbus failed
> to provide such interface for automation.
>
> All I wanted is to connect two devices using bluez, using command-line.
> Using the basic layout, automation and no UI...
>
> tun, ppp, bridge are all working great, providing decent command-line
> interface and no extra dependencies (dbus).
>
>> As a user, you should ultimately be using some *user* interface (either
>> graphical or command line) which hides any complexities of the D-Bus
>> interface.
>
> All I know is dbus-send, do you have any other tool?
>
>> The big fault from the BlueZ project's side is that it hasn't
>> provided proper command-line user tools for its D-Bus interface. I think
>> one of the reasons for this is that the existing tools like hcitool and
>> hciconfig along with the python scripts that come with the source have
>> been regarded as "good enough".
>
> Can you please point me to a script in source tarball to created bnep
> interface?
>
>>> and/or python in order to achieve this goal.
>> Why especially python? There's a plethora of different language bindings
>> available for D-Bus. You can find a list of them here:
>> http://www.freedesktop.org/wiki/Software/DBusBindings
>
> Again, there is a major difference between a simple script and starting
> dbus development. Why do I need to know dbus if I want to USE
> bluez? Well... I understand I need to start learning or just use
> PPP over rfcomm... At least I know how to set this up without
> dbus knowledge.
>
>>> Does anyone has a sample without python dependency (shell script) that
>>> can create bnep interface on both ends for hidden (explicit mac) devices?
>> I'm not aware of any D-Bus binding for shell languages (like bash).
>> There's the generic dbus-send command line tool provided by D-Bus but it
>> won't get you very far with the more complex interfaces. Just out of
>> curiosity, what kind of system are you using that doesn't have python
>> available? Some embedded device perhaps? (in which case the border
>> between a user and developer starts to get quite blurred).
>
> A user is a user of a component, he can be a developer of other software.
> Nothing blurred. I just wanted to know that I understand correctly and
> I need to develop my own software in order to use basic functionality.
>
> I thought that like iproute2 support tan/tap it can support bnep and
> then all be happy :) But adding dbus dependency to core is not
> wise.
>
>>> Alternatively, can anyone please tell me what is the uuid parameter
>>> for org.bluez::org.bluez.Network::Connect?
>> That's the Bluetooth UUID of the service you want to use. However the
>> interface will also accept "friendly" strings such as "nap" and "panu".
>> Admittedly doc/network-api.txt should be updated to list all of these
>> possibilities. It's much terse right now.
>
> Can you please tell me what is the friendly string to set up bnep interface
> to a specific device?
>
>>> Anyway... I think the requirement for people to use dbus is truly
>>> unusable...
>> I'll assume you mean "user" when you say "people". You're right of
>> course. The D-Bus interface was never intended for users. It was created
>> for developers to build user interfaces and while GUI's are out of scope
>> for the BlueZ project at least a command-line tool should be available
>> for users not wanting or being able to deal with GUI's.
>
> Great... Need a sample... :)
>
>>> Providing simple solutions/scripts for common tasks is required.
>> Agreed. Right now for many tasks you can use the legacy command line
>> tools and even the old daemons like pand if you wish. For the D-Bus
>> interface there are the python scripts within the source tree and in the
>> long run we should hopefully have a proper command line user tool for
>> the D-Bus interface.
>
> I don't understand, I thought the pand is not needed anymore, no daemon
> is needed, right? Or I miss something. Anyway, most distribution do not
> install pand anymore...
>
> Thank you,
> Alon.
Hi Alon,
Maybe this tool can help you for the gui side of your problems, yes I
know its no command-line tool but its the best I can do for you.
It's about the blueman tool:
http://lists.debian.org/debian-mentors/2009/02/msg00277.html
http://lists.debian.org/debian-mentors/2009/03/msg00004.html
I provide the link to the archive, because I sent some mail to the
thread. Maybe the bluez-gnome bluetooth-applet developers can read the
thread too and provide there opinion about the issues?
Best regards,
Jelle de Jong
Alon Bar-Lev wrote:
> On Sat, Feb 28, 2009 at 10:03 PM, Johan Hedberg <[email protected]> wrote:
>> Hi,
>>
>> On Sat, Feb 28, 2009, Alon Bar-Lev wrote:
>>> I am sorry I post here, but there is no user mailing list specified at
>>> [1] while both links at [2] refer to this list. I will appreciate if
>>> you forward me to the right place.
>> Nope, as far as I understand this list is intended for both developer
>> and user issues.
>
> Oh..
> """linux-bluetooth
> This mailing list is for the kernel developer."""
>
> Needs an update :)
>
>
>>> I try to figure out how to create bnep interface. It looks like one
>>> should have vast knowledge in dbus
>> If you're a developer, then yes. If you're a user the interface has already
>> failed at the point where it requires you to know what "bnep" is :)
>
> I think that you have incorrect view of users/integrators/sysadmins.
> There are many levels of complexity... One is to write something like
> bluz, and the other is to create a single working entity out of many
> components.
> So developer of one solution can be a user of the other, and
> sysadmin can be a user of many etc...
>
> Imagin you are a sysadmin or a user of all solutions but bluez,
> and need to setup a working machine, if you don't have simple
> utilities you end up in being an expert in each of the components,
> or ends up with incomplete solution as you don't have enough time.
>
> Back in the CORBA time, at least we had decent command-line interface
> so that I could enumerate, create and call methods. dbus failed
> to provide such interface for automation.
>
> All I wanted is to connect two devices using bluez, using command-line.
> Using the basic layout, automation and no UI...
>
> tun, ppp, bridge are all working great, providing decent command-line
> interface and no extra dependencies (dbus).
>
>> As a user, you should ultimately be using some *user* interface (either
>> graphical or command line) which hides any complexities of the D-Bus
>> interface.
>
> All I know is dbus-send, do you have any other tool?
>
>> The big fault from the BlueZ project's side is that it hasn't
>> provided proper command-line user tools for its D-Bus interface. I think
>> one of the reasons for this is that the existing tools like hcitool and
>> hciconfig along with the python scripts that come with the source have
>> been regarded as "good enough".
>
> Can you please point me to a script in source tarball to created bnep
> interface?
>
>>> and/or python in order to achieve this goal.
>> Why especially python? There's a plethora of different language bindings
>> available for D-Bus. You can find a list of them here:
>> http://www.freedesktop.org/wiki/Software/DBusBindings
>
> Again, there is a major difference between a simple script and starting
> dbus development. Why do I need to know dbus if I want to USE
> bluez? Well... I understand I need to start learning or just use
> PPP over rfcomm... At least I know how to set this up without
> dbus knowledge.
>
>>> Does anyone has a sample without python dependency (shell script) that
>>> can create bnep interface on both ends for hidden (explicit mac) devices?
>> I'm not aware of any D-Bus binding for shell languages (like bash).
>> There's the generic dbus-send command line tool provided by D-Bus but it
>> won't get you very far with the more complex interfaces. Just out of
>> curiosity, what kind of system are you using that doesn't have python
>> available? Some embedded device perhaps? (in which case the border
>> between a user and developer starts to get quite blurred).
>
> A user is a user of a component, he can be a developer of other software.
> Nothing blurred. I just wanted to know that I understand correctly and
> I need to develop my own software in order to use basic functionality.
>
> I thought that like iproute2 support tan/tap it can support bnep and
> then all be happy :) But adding dbus dependency to core is not
> wise.
>
>>> Alternatively, can anyone please tell me what is the uuid parameter
>>> for org.bluez::org.bluez.Network::Connect?
>> That's the Bluetooth UUID of the service you want to use. However the
>> interface will also accept "friendly" strings such as "nap" and "panu".
>> Admittedly doc/network-api.txt should be updated to list all of these
>> possibilities. It's much terse right now.
>
> Can you please tell me what is the friendly string to set up bnep interface
> to a specific device?
>
>>> Anyway... I think the requirement for people to use dbus is truly
>>> unusable...
>> I'll assume you mean "user" when you say "people". You're right of
>> course. The D-Bus interface was never intended for users. It was created
>> for developers to build user interfaces and while GUI's are out of scope
>> for the BlueZ project at least a command-line tool should be available
>> for users not wanting or being able to deal with GUI's.
>
> Great... Need a sample... :)
>
>>> Providing simple solutions/scripts for common tasks is required.
>> Agreed. Right now for many tasks you can use the legacy command line
>> tools and even the old daemons like pand if you wish. For the D-Bus
>> interface there are the python scripts within the source tree and in the
>> long run we should hopefully have a proper command line user tool for
>> the D-Bus interface.
>
> I don't understand, I thought the pand is not needed anymore, no daemon
> is needed, right? Or I miss something. Anyway, most distribution do not
> install pand anymore...
>
> Thank you,
> Alon.
Hi Alon,
Maybe this tool can help you for the gui side of your problems, yes I
know its no command-line tool but its the best I can do for you.
It's about the blueman tool:
http://lists.debian.org/debian-mentors/2009/02/msg00277.html
I provide the link to the archive, because I sent some mail to the
thread. Maybe the bluez-gnome bluetooth-applet developers can read the
thread too and provide there opinion about the issues?
Best regards,
Jelle de Jong
On Sat, Feb 28, 2009 at 10:03 PM, Johan Hedberg <[email protected]> wrote:
> Hi,
>
> On Sat, Feb 28, 2009, Alon Bar-Lev wrote:
>> I am sorry I post here, but there is no user mailing list specified at
>> [1] while both links at [2] refer to this list. I will appreciate if
>> you forward me to the right place.
>
> Nope, as far as I understand this list is intended for both developer
> and user issues.
Oh..
"""linux-bluetooth
This mailing list is for the kernel developer."""
Needs an update :)
>> I try to figure out how to create bnep interface. It looks like one
>> should have vast knowledge in dbus
>
> If you're a developer, then yes. If you're a user the interface has already
> failed at the point where it requires you to know what "bnep" is :)
I think that you have incorrect view of users/integrators/sysadmins.
There are many levels of complexity... One is to write something like
bluz, and the other is to create a single working entity out of many
components.
So developer of one solution can be a user of the other, and
sysadmin can be a user of many etc...
Imagin you are a sysadmin or a user of all solutions but bluez,
and need to setup a working machine, if you don't have simple
utilities you end up in being an expert in each of the components,
or ends up with incomplete solution as you don't have enough time.
Back in the CORBA time, at least we had decent command-line interface
so that I could enumerate, create and call methods. dbus failed
to provide such interface for automation.
All I wanted is to connect two devices using bluez, using command-line.
Using the basic layout, automation and no UI...
tun, ppp, bridge are all working great, providing decent command-line
interface and no extra dependencies (dbus).
> As a user, you should ultimately be using some *user* interface (either
> graphical or command line) which hides any complexities of the D-Bus
> interface.
All I know is dbus-send, do you have any other tool?
> The big fault from the BlueZ project's side is that it hasn't
> provided proper command-line user tools for its D-Bus interface. I think
> one of the reasons for this is that the existing tools like hcitool and
> hciconfig along with the python scripts that come with the source have
> been regarded as "good enough".
Can you please point me to a script in source tarball to created bnep
interface?
>> and/or python in order to achieve this goal.
>
> Why especially python? There's a plethora of different language bindings
> available for D-Bus. You can find a list of them here:
> http://www.freedesktop.org/wiki/Software/DBusBindings
Again, there is a major difference between a simple script and starting
dbus development. Why do I need to know dbus if I want to USE
bluez? Well... I understand I need to start learning or just use
PPP over rfcomm... At least I know how to set this up without
dbus knowledge.
>> Does anyone has a sample without python dependency (shell script) that
>> can create bnep interface on both ends for hidden (explicit mac) devices?
>
> I'm not aware of any D-Bus binding for shell languages (like bash).
> There's the generic dbus-send command line tool provided by D-Bus but it
> won't get you very far with the more complex interfaces. Just out of
> curiosity, what kind of system are you using that doesn't have python
> available? Some embedded device perhaps? (in which case the border
> between a user and developer starts to get quite blurred).
A user is a user of a component, he can be a developer of other software.
Nothing blurred. I just wanted to know that I understand correctly and
I need to develop my own software in order to use basic functionality.
I thought that like iproute2 support tan/tap it can support bnep and
then all be happy :) But adding dbus dependency to core is not
wise.
>> Alternatively, can anyone please tell me what is the uuid parameter
>> for org.bluez::org.bluez.Network::Connect?
>
> That's the Bluetooth UUID of the service you want to use. However the
> interface will also accept "friendly" strings such as "nap" and "panu".
> Admittedly doc/network-api.txt should be updated to list all of these
> possibilities. It's much terse right now.
Can you please tell me what is the friendly string to set up bnep interface
to a specific device?
>> Anyway... I think the requirement for people to use dbus is truly
>> unusable...
>
> I'll assume you mean "user" when you say "people". You're right of
> course. The D-Bus interface was never intended for users. It was created
> for developers to build user interfaces and while GUI's are out of scope
> for the BlueZ project at least a command-line tool should be available
> for users not wanting or being able to deal with GUI's.
Great... Need a sample... :)
>> Providing simple solutions/scripts for common tasks is required.
>
> Agreed. Right now for many tasks you can use the legacy command line
> tools and even the old daemons like pand if you wish. For the D-Bus
> interface there are the python scripts within the source tree and in the
> long run we should hopefully have a proper command line user tool for
> the D-Bus interface.
I don't understand, I thought the pand is not needed anymore, no daemon
is needed, right? Or I miss something. Anyway, most distribution do not
install pand anymore...
Thank you,
Alon.