Hi folks,
I am posting a new draft of D-Bus architecture and Interfaces.=20
If someone has comments regarding the design, interfaces or any kind
of question send us a feedback.
This last draft contains some changes based on Johan Hedberg feedback
and new services.
Major changes:
* Return "D-Bus error messages" instead of "method return" following
the Johan Hedberg suggestion
* Defined standard error messages
* Added "architecture" overview section.
* Using just one interface for request and signals instead of distinct
interfaces. The message type can be discovered using the message type
attribute embedded in the D-Bus message header.
Location:
The document (draft 00.05) can be found at: http://www.cin.ufpe.br/~ckt/blu=
ez
Next action:
* define SDP D-Bus services and architecture.
* Multi-level disconnection/connection signals. Is it really
necessary? eg: send disconnect signal at pan and hci D-Bus interfaces.
* Signal level. Is it possible check it? IS it really necessary?
* Unify rfcomm and dun D-Bus services. Is it feasible?
Suggestions a welcome!
Regards,
Claudio
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel,
Regarding the special HCI_DEV_NONE system socket with vendor packet type. Do
you
have a patch for it or it just ideas for BlueZ improvements? What are
exactly the events that
you want send in this socket?
BR,
Claudio.
On 8/30/05, Claudio Takahasi <[email protected]> wrote:
>
>
>
> On 8/29/05, Marcel Holtmann <[email protected]> wrote:
> >
> > Hi Claudio,
> >
> > > Sorry annoy you again, but would like received more suggestions and
> > > close this discussion.
> > >
> > > Marcel, I remember you comment something about improve the sdpd, could
> > > you be more clear?
> > >
> > > The core implementation (bluetoothd) and some hci functions are ready.
> > > I am just waiting finish the specification.
> >
> > sorry, I am totally behind my schedule and as you saw, I had to deal
> > with some weird D-Bus things in the current hcid in the last week. There
> >
> > is other stuff that needs my attention, before I can start looking at
> > bluetoothd again.
>
>
> [Claudio Takahasi]
> I understand your problem, Don't worry. Considering that D-Bus is
> under development, bugs are common :)
>
> However the basic idea is that bluetoothd should combine hcid and sdpd
> > and present an easier interface over D-Bus. This interface should no
> > longer be HCI or SDP protocol specific. It should be more profile
> > specific and define standard task. In conjunction with the new extended
> > inquiry response the bluetoothd must also take care to assemble the
> > correct data from the running services and the device name to fully
> > fulfil the requirements of extended inquiry response. If the complete
> > SDP handling is inside bluetoothd we can do full and easy caching of
> > service information of remote devices.
>
>
> [Claudio Takahasi]
> I didn't see the new extended inquiry response yet. I will try understand
> how it works.
> Do you have material about it? Is it related with interlaced inquiry?
> Regarding SDP, do you mean put everything inside bluetoothd? I am not
> understanding how
> it should work. As I could undertand you intend provide a complete SDP
> handling inside bluetoothd
> without interact with sdpd.
> Currently, applications(daemon) that want publish a service, they have to
> connect
> with the sdpd(sdp_connect) and register the services. If we move
> everything to bluetoothd we will lost
> the backward compatibility. Another approach is provide a D-Bus interface
> for sdp in the bluetoothd, but in
> this case the bluetoothd will continue connecting to sdpd to register
> services. The last approach is dupplicate
> the functionalities, sdpd and bluetoothd will do the same thing, but the
> last one will available for D-Bus enable
> systems only.
>
> Another comment about bluetoothd IMHO blutoothd should be modular enough
> to make possible
> develop/provide another profiles(pan,rfcomm, dun, hid, hsp, ...)
> Therefore, it should be more than
> a daemon to provide hci and sdp services. This is the reason that I
> comment about hierarchical
> paths.
> /org/bluez/bluetoothd
> /org/bluez/bluetoothd/sdp
> /org/bluez/bluetoothd/hci
> /org/bluez/bluetoothd/pan
>
> Using this approach is easier control permissions in the D-Bus
> configuration file and register/unregister
> D-Bus paths.
>
>
> On the other side we have that D-Bus API problem and if anyone can
> > convince the Debian guys to finally move to latest D-Bus release for the
> >
> > unstable distribution I would be really thankful. I simple wanna drop
> > these crappy workaround, because they make my testing before I can
> > release a new version a mess. I saw that Ubuntu even uses D-Bus 0.35 and
> > so there is no other distribution with such an old version.
>
>
> [Claudio Takahasi]
> I think you don't need worry about it. After 0.30 D-Bus is more stable and
> probably
> it will not change drastically. I didn't see functions name/signatures
> changes.
> The only think that we have to pay attention is the functions to
> extract/append arguments
> in the message with number of elements variable. I was informed that they
> should be avoided
> and they will be depreciated.
>
> The next thing is the kernel interface for bluetoothd. I basically don't
> > wanna have another daemon listening on the HCI socket and have to deal
> > with plug/unplug of devices. These task are already done inside the
> > kernel and so it should simply inform the userspace of such events. The
> > same applies to connection tracking etc. The kernel needs to know
> > everything and I must work on the new interface to tell the userspace
> > what is currently going on. For that I will use the special HCI_DEV_NONE
> > system socket and the vendor packets type 0xff. So we don't pollute the
> > HCI namespace with "stack internal" commands and events and still have
> > an easy interface. The other possibility would be to use netlink, but we
> > already have most parts of the infrastructure in place and so I don't
> > see and need to deal with netlink. And one of the first things that
> > bluetoothd must be capable of is to support the kernel internal security
> > manager. This means dealing with special events to handle pin code and
> > link key requests.
>
>
> [Claudio Takahasi]
> O my God, it will be fun! A lot of chalenges :)
> Could you provide more details about this section. Currenlty hcid is
> responsible for
> handle this events(security and devices). How should be the
> interaction/relation
> between hcid and bluetoothd? hcid is already listening for
> HCI_DEV_UP/DOWN/REG/UNREG ...
>
> I agree with provide security services, they are essential.
>
>
> As maybe some people saw, I already used hcid as a playground for some
> > more D-Bus signals. I still need to learn and understand the D-Bus much
> > better. So any patches from your specification to bring some of these
> > features to hcid would be happily accepted.
>
> [Claudio Takahasi]
> I saw a lot hcid D-Bus signals, but currently only signals are sent.
> Services requests are
> not being handled, they can be a good starting point. I will analyse
> better and send
> patches if possible.
>
> Regards
> >
> > Marcel
> >
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is Sponsored by the Better Software Conference & EXPO
> > September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> > Practices
> > Agile & Plan-Driven Development * Managing Projects & Teams * Testing &
> > QA
> > Security * Process Improvement & Measurement *
> > http://www.sqe.com/bsce5sf
> > _______________________________________________
> > Bluez-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/bluez-devel
> >
>
>
On 8/29/05, Marcel Holtmann <[email protected]> wrote:
>
> Hi Claudio,
>
> > Sorry annoy you again, but would like received more suggestions and
> > close this discussion.
> >
> > Marcel, I remember you comment something about improve the sdpd, could
> > you be more clear?
> >
> > The core implementation (bluetoothd) and some hci functions are ready.
> > I am just waiting finish the specification.
>
> sorry, I am totally behind my schedule and as you saw, I had to deal
> with some weird D-Bus things in the current hcid in the last week. There
> is other stuff that needs my attention, before I can start looking at
> bluetoothd again.
[Claudio Takahasi]
I understand your problem, Don't worry. Considering that D-Bus is
under development, bugs are common :)
However the basic idea is that bluetoothd should combine hcid and sdpd
> and present an easier interface over D-Bus. This interface should no
> longer be HCI or SDP protocol specific. It should be more profile
> specific and define standard task. In conjunction with the new extended
> inquiry response the bluetoothd must also take care to assemble the
> correct data from the running services and the device name to fully
> fulfil the requirements of extended inquiry response. If the complete
> SDP handling is inside bluetoothd we can do full and easy caching of
> service information of remote devices.
[Claudio Takahasi]
I didn't see the new extended inquiry response yet. I will try understand
how it works.
Do you have material about it? Is it related with interlaced inquiry?
Regarding SDP, do you mean put everything inside bluetoothd? I am not
understanding how
it should work. As I could undertand you intend provide a complete SDP
handling inside bluetoothd
without interact with sdpd.
Currently, applications(daemon) that want publish a service, they have to
connect
with the sdpd(sdp_connect) and register the services. If we move everything
to bluetoothd we will lost
the backward compatibility. Another approach is provide a D-Bus interface
for sdp in the bluetoothd, but in
this case the bluetoothd will continue connecting to sdpd to register
services. The last approach is dupplicate
the functionalities, sdpd and bluetoothd will do the same thing, but the
last one will available for D-Bus enable
systems only.
Another comment about bluetoothd IMHO blutoothd should be modular enough to
make possible
develop/provide another profiles(pan,rfcomm, dun, hid, hsp, ...) Therefore,
it should be more than
a daemon to provide hci and sdp services. This is the reason that I comment
about hierarchical
paths.
/org/bluez/bluetoothd
/org/bluez/bluetoothd/sdp
/org/bluez/bluetoothd/hci
/org/bluez/bluetoothd/pan
Using this approach is easier control permissions in the D-Bus configuration
file and register/unregister
D-Bus paths.
On the other side we have that D-Bus API problem and if anyone can
> convince the Debian guys to finally move to latest D-Bus release for the
> unstable distribution I would be really thankful. I simple wanna drop
> these crappy workaround, because they make my testing before I can
> release a new version a mess. I saw that Ubuntu even uses D-Bus 0.35 and
> so there is no other distribution with such an old version.
[Claudio Takahasi]
I think you don't need worry about it. After 0.30 D-Bus is more stable and
probably
it will not change drastically. I didn't see functions name/signatures
changes.
The only think that we have to pay attention is the functions to
extract/append arguments
in the message with number of elements variable. I was informed that they
should be avoided
and they will be depreciated.
The next thing is the kernel interface for bluetoothd. I basically don't
> wanna have another daemon listening on the HCI socket and have to deal
> with plug/unplug of devices. These task are already done inside the
> kernel and so it should simply inform the userspace of such events. The
> same applies to connection tracking etc. The kernel needs to know
> everything and I must work on the new interface to tell the userspace
> what is currently going on. For that I will use the special HCI_DEV_NONE
> system socket and the vendor packets type 0xff. So we don't pollute the
> HCI namespace with "stack internal" commands and events and still have
> an easy interface. The other possibility would be to use netlink, but we
> already have most parts of the infrastructure in place and so I don't
> see and need to deal with netlink. And one of the first things that
> bluetoothd must be capable of is to support the kernel internal security
> manager. This means dealing with special events to handle pin code and
> link key requests.
[Claudio Takahasi]
O my God, it will be fun! A lot of chalenges :)
Could you provide more details about this section. Currenlty hcid is
responsible for
handle this events(security and devices). How should be the
interaction/relation
between hcid and bluetoothd? hcid is already listening for
HCI_DEV_UP/DOWN/REG/UNREG ...
I agree with provide security services, they are essential.
As maybe some people saw, I already used hcid as a playground for some
> more D-Bus signals. I still need to learn and understand the D-Bus much
> better. So any patches from your specification to bring some of these
> features to hcid would be happily accepted.
[Claudio Takahasi]
I saw a lot hcid D-Bus signals, but currently only signals are sent.
Services requests are
not being handled, they can be a good starting point. I will analyse better
and send
patches if possible.
Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
I just looked and... dbus 0.36 is in experimental currently... so
hopefully should make it to unstable RSN.
--
Paul
On Mon, Aug 29, 2005 at 11:46:35PM +0200, Marcel Holtmann wrote:
> Hi Claudio,
>
> > Sorry annoy you again, but would like received more suggestions and
> > close this discussion.
> >
> > Marcel, I remember you comment something about improve the sdpd, could
> > you be more clear?
> >
> > The core implementation (bluetoothd) and some hci functions are ready.
> > I am just waiting finish the specification.
>
> sorry, I am totally behind my schedule and as you saw, I had to deal
> with some weird D-Bus things in the current hcid in the last week. There
> is other stuff that needs my attention, before I can start looking at
> bluetoothd again.
>
> However the basic idea is that bluetoothd should combine hcid and sdpd
> and present an easier interface over D-Bus. This interface should no
> longer be HCI or SDP protocol specific. It should be more profile
> specific and define standard task. In conjunction with the new extended
> inquiry response the bluetoothd must also take care to assemble the
> correct data from the running services and the device name to fully
> fulfil the requirements of extended inquiry response. If the complete
> SDP handling is inside bluetoothd we can do full and easy caching of
> service information of remote devices.
>
> On the other side we have that D-Bus API problem and if anyone can
> convince the Debian guys to finally move to latest D-Bus release for the
> unstable distribution I would be really thankful. I simple wanna drop
> these crappy workaround, because they make my testing before I can
> release a new version a mess. I saw that Ubuntu even uses D-Bus 0.35 and
> so there is no other distribution with such an old version.
>
> The next thing is the kernel interface for bluetoothd. I basically don't
> wanna have another daemon listening on the HCI socket and have to deal
> with plug/unplug of devices. These task are already done inside the
> kernel and so it should simply inform the userspace of such events. The
> same applies to connection tracking etc. The kernel needs to know
> everything and I must work on the new interface to tell the userspace
> what is currently going on. For that I will use the special HCI_DEV_NONE
> system socket and the vendor packets type 0xff. So we don't pollute the
> HCI namespace with "stack internal" commands and events and still have
> an easy interface. The other possibility would be to use netlink, but we
> already have most parts of the infrastructure in place and so I don't
> see and need to deal with netlink. And one of the first things that
> bluetoothd must be capable of is to support the kernel internal security
> manager. This means dealing with special events to handle pin code and
> link key requests.
>
> As maybe some people saw, I already used hcid as a playground for some
> more D-Bus signals. I still need to learn and understand the D-Bus much
> better. So any patches from your specification to bring some of these
> features to hcid would be happily accepted.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Claudio,
> Sorry annoy you again, but would like received more suggestions and
> close this discussion.
>
> Marcel, I remember you comment something about improve the sdpd, could
> you be more clear?
>
> The core implementation (bluetoothd) and some hci functions are ready.
> I am just waiting finish the specification.
sorry, I am totally behind my schedule and as you saw, I had to deal
with some weird D-Bus things in the current hcid in the last week. There
is other stuff that needs my attention, before I can start looking at
bluetoothd again.
However the basic idea is that bluetoothd should combine hcid and sdpd
and present an easier interface over D-Bus. This interface should no
longer be HCI or SDP protocol specific. It should be more profile
specific and define standard task. In conjunction with the new extended
inquiry response the bluetoothd must also take care to assemble the
correct data from the running services and the device name to fully
fulfil the requirements of extended inquiry response. If the complete
SDP handling is inside bluetoothd we can do full and easy caching of
service information of remote devices.
On the other side we have that D-Bus API problem and if anyone can
convince the Debian guys to finally move to latest D-Bus release for the
unstable distribution I would be really thankful. I simple wanna drop
these crappy workaround, because they make my testing before I can
release a new version a mess. I saw that Ubuntu even uses D-Bus 0.35 and
so there is no other distribution with such an old version.
The next thing is the kernel interface for bluetoothd. I basically don't
wanna have another daemon listening on the HCI socket and have to deal
with plug/unplug of devices. These task are already done inside the
kernel and so it should simply inform the userspace of such events. The
same applies to connection tracking etc. The kernel needs to know
everything and I must work on the new interface to tell the userspace
what is currently going on. For that I will use the special HCI_DEV_NONE
system socket and the vendor packets type 0xff. So we don't pollute the
HCI namespace with "stack internal" commands and events and still have
an easy interface. The other possibility would be to use netlink, but we
already have most parts of the infrastructure in place and so I don't
see and need to deal with netlink. And one of the first things that
bluetoothd must be capable of is to support the kernel internal security
manager. This means dealing with special events to handle pin code and
link key requests.
As maybe some people saw, I already used hcid as a playground for some
more D-Bus signals. I still need to learn and understand the D-Bus much
better. So any patches from your specification to bring some of these
features to hcid would be happily accepted.
Regards
Marcel
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi folks,
Sorry annoy you again, but would like received more suggestions and close
this discussion.
Marcel, I remember you comment something about improve the sdpd, could you
be more clear?
The core implementation (bluetoothd) and some hci functions are ready. I am
just waiting finish the specification.
http://www.cin.ufpe.br/~ckt/bluez
Regards,
Claudio.
On 8/22/05, Claudio Takahasi <[email protected]> wrote:
>
> Hi folks,
>
> The discussion focus moved to address multiple adapters. In the next
> BlueZ D-Bus specification I will handle only the default
> adapter(BDADDR_ANY).
>
> There are other points that I want feebacks.
> * Unify rfcomm and dun D-Bus interfaces/path?
> * Provide IP parameter setup. Is it necessary provide D-Bus services
> to configurate IP address, netmask, ...?
> * Provide services for automatic bridge creation(PAN context). Is really
> useful?
> * Where provide pair/authentication? Pair services does not belongs to
> a nice object path. Maybe should be "org.bluez.bluetoothd.security"
> * How SDP should work? How should be the interaction between SDP and
> the profiles in order to save memory, avoid code dupplication and use
> cache?
> * Multi level signals. For connection, disconnections and signal level
> would make sense to have both low level signals(eg: hci vs. pan). Is
> it really necessary?
> * Remove "Sig", "Req" from the method name. The type field in the
> header can be used to identify the message type(method call, method
> return, message error or signal), but in my opinion we must keep to
> make messages more clear.
>
> The latest specification (draft 00.05) can be found at:
> http://www.cin.ufpe.br/~ckt/bluez
>
> Regards,
> Claudio.
>
> On 8/22/05, Marcel Holtmann <[email protected]> wrote:
> > Hi Claudio,
> >
> > > After this long discussion I think control multiple apdaters
> > > will not be easy. If we register multiple paths will not be easy
> > > map device register/unregister to D-Bus paths. When the user
> > > remove the default dongle the D-Bus path should be unregistered and
> > > the default adapter should be changed.
> >
> > never was and never will be ;)
> >
> > > Considering that bluez daemons are using the BDADDR_ANY. The D-Bus
> > > services should use the same approach. I agree that the default
> > > adapter must go through the kernel.
> > >
> > > Is there a way/interface to change the default adapter in the kernel?
> >
> > No. It has a simple route heuristic and normally uses the first adapter
> > that is marked as up and is not a raw device. Unless the destination is
> > not itself.
> >
> > This means that the default adapter depends on the destination which is
> > not easy to configure.
> >
> > Regards
> >
> > Marcel
> >
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is Sponsored by the Better Software Conference & EXPO
> > September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> Practices
> > Agile & Plan-Driven Development * Managing Projects & Teams * Testing &
> QA
> > Security * Process Improvement & Measurement *
> http://www.sqe.com/bsce5sf
> > _______________________________________________
> > Bluez-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/bluez-devel
> >
>
Hi folks,
The discussion focus moved to address multiple adapters. In the next
BlueZ D-Bus specification I will handle only the default
adapter(BDADDR_ANY).
There are other points that I want feebacks.
* Unify rfcomm and dun D-Bus interfaces/path?=20
* Provide IP parameter setup. Is it necessary provide D-Bus services
to configurate IP address, netmask, ...?
* Provide services for automatic bridge creation(PAN context). Is really us=
eful?
* Where provide pair/authentication? Pair services does not belongs to
a nice object path. Maybe should be "org.bluez.bluetoothd.security"
* How SDP should work? How should be the interaction between SDP and
the profiles in order to save memory, avoid code dupplication and use
cache?
* Multi level signals. For connection, disconnections and signal level
would make sense to have both low level signals(eg: hci vs. pan). Is
it really necessary?
* Remove "Sig", "Req" from the method name. The type field in the
header can be used to identify the message type(method call, method
return, message error or signal), but in my opinion we must keep to
make messages more clear.
The latest specification (draft 00.05) can be found at:
http://www.cin.ufpe.br/~ckt/bluez
Regards,
Claudio.
On 8/22/05, Marcel Holtmann <[email protected]> wrote:
> Hi Claudio,
>=20
> > After this long discussion I think control multiple apdaters
> > will not be easy. If we register multiple paths will not be easy
> > map device register/unregister to D-Bus paths. When the user
> > remove the default dongle the D-Bus path should be unregistered and
> > the default adapter should be changed.
>=20
> never was and never will be ;)
>=20
> > Considering that bluez daemons are using the BDADDR_ANY. The D-Bus
> > services should use the same approach. I agree that the default
> > adapter must go through the kernel.
> >
> > Is there a way/interface to change the default adapter in the kernel?
>=20
> No. It has a simple route heuristic and normally uses the first adapter
> that is marked as up and is not a raw device. Unless the destination is
> not itself.
>=20
> This means that the default adapter depends on the destination which is
> not easy to configure.
>=20
> Regards
>=20
> Marcel
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic=
es
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q=
A
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Claudio,
> After this long discussion I think control multiple apdaters
> will not be easy. If we register multiple paths will not be easy
> map device register/unregister to D-Bus paths. When the user
> remove the default dongle the D-Bus path should be unregistered and
> the default adapter should be changed.
never was and never will be ;)
> Considering that bluez daemons are using the BDADDR_ANY. The D-Bus
> services should use the same approach. I agree that the default
> adapter must go through the kernel.
>
> Is there a way/interface to change the default adapter in the kernel?
No. It has a simple route heuristic and normally uses the first adapter
that is marked as up and is not a raw device. Unless the destination is
not itself.
This means that the default adapter depends on the destination which is
not easy to configure.
Regards
Marcel
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi folks,
After this long discussion I think control multiple apdaters
will not be easy. If we register multiple paths will not be easy=20
map device register/unregister to D-Bus paths. When the user=20
remove the default dongle the D-Bus path should be unregistered and=20
the default adapter should be changed.=20
Considering that bluez daemons are using the BDADDR_ANY. The D-Bus=20
services should use the same approach. I agree that the default=20
adapter must go through the kernel.
Is there a way/interface to change the default adapter in the kernel?=20
Regarding security issues. The bluetoothd will run with root right.
The security policy shall be controlled by D-Bus configuration
files. It's possible add rule based on method names and interfaces.
Regards,
Claudio.
On 8/22/05, Marcel Holtmann <[email protected]> wrote:
> Hi Paul,
>=20
> > Another big concern I'm having is about security, most hciconfig
> > commands require 'higher than normal' privileges to execute, should
> > the daemon allow certain requests only to the root user ? (luckily
> > dbus was conceived with security in mind, so adding such a policy
> > would not be difficult).
> > This would just make things more complicated and I don't think there's
> > any real gain in doing so, but maybe there are some security issues I
> > ignore at the moment, let me know your opinion.
> > (if for example, a program calls ListDevices to list the adapters, and
> > the user wants to use an interface which is not active, should the
> > program be allowed to bring it up?)
>=20
> the bluetoothd run with root (or chroot) rights and thus it needs to
> provide its own security policy.
>=20
> > What if two (or more) applications chose, for whatever reason, to set
> > a different default adapter? If you *really* want such a mechanism,
> > maybe you should make such a method callable only by authorized code
> > (hence my dilemma above) or simply select the default adapter
> > internally in the daemon and don't expose this method at all.
>=20
> as I said in the previous answers, the setting which is the default
> adapter must go through the kernel.
>=20
> Regards
>=20
> Marcel
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic=
es
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q=
A
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Paul,
> Another big concern I'm having is about security, most hciconfig
> commands require 'higher than normal' privileges to execute, should
> the daemon allow certain requests only to the root user ? (luckily
> dbus was conceived with security in mind, so adding such a policy
> would not be difficult).
> This would just make things more complicated and I don't think there's
> any real gain in doing so, but maybe there are some security issues I
> ignore at the moment, let me know your opinion.
> (if for example, a program calls ListDevices to list the adapters, and
> the user wants to use an interface which is not active, should the
> program be allowed to bring it up?)
the bluetoothd run with root (or chroot) rights and thus it needs to
provide its own security policy.
> What if two (or more) applications chose, for whatever reason, to set
> a different default adapter? If you *really* want such a mechanism,
> maybe you should make such a method callable only by authorized code
> (hence my dilemma above) or simply select the default adapter
> internally in the daemon and don't expose this method at all.
as I said in the previous answers, the setting which is the default
adapter must go through the kernel.
Regards
Marcel
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Peter,
> What happens if you want to use your second adapter as the default? EG
> if I have a BT2.0 and a BT1.2 adapter but the BT1.2 adapter is
> detected first but you want to use the BT2.0 adapter as the default as
> its faster.
this is somekind of a policy decision and must not be the correct one in
any circumstances. And as I said before, the kernel must know about it.
Regards
Marcel
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Claudio,
> It's possible register multiple D-Bus object paths. My suggestion
> for handle multiple adapters is register a default path and paths
> based on the device address.
> eg: suppose two adapters(11:22:33:44:55:66, 77:88:99:00:11:22)
>
> The possible paths are:
>
> /org/bluez/bluetoothd/hci (default path - first adapter)
> /org/bluez/bluetoothd/112233445566/hci (first adapter)
> /org/bluez/bluetoothd/778899001122/hci (second adapter)
>
> /org/bluez/bluetoothd/pan (default path - first adapter)
> /org/bluez/bluetoothd/112233445566/pan (first adapter)
> /org/bluez/bluetoothd/778899001122/pan (second adapter)
> ...
>
> The service to list the adapter must be moved to the main path
> (/org/bluez/bluetoothd) or to a new one /org/bluez/bluetoothd/devices.
>
> The message handle function will become more complex, but I don't
> see other solution.
the main problem is that I would like to do identification of the host
adapter by id (hci0), by address (11:22:33:44:55:66) and maybe by an
alias (bluecore-dongle) or by its name ("BlueZ dongle"). The only fully
unique identification across reboots/enumerations is the address. For
the kernel it is only the current id and this means bluetoothd has to
translate between them. If you look at the default adapter by the
address identification it is 00:00:00:00:00:00 (BDADDR_ANY) and I will
leave it this way.
When choosing a default adapter without any further configuration we
must do this unique and for this means this decision can only be done by
the kernel. This means that the kernel need to know about a change and
must also tell bluetoothd what it thinks is the default adapter.
Regards
Marcel
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On 8/22/05, Claudio Takahasi <[email protected]> wrote:
> Hi Peter,
>=20
> I am planning provide a D-Bus service for setup a default adapter. But
> the developer will
> have to call a service to discover all available adapters. The steps shal=
l be:
> 1. Call a method to discover the available adapters
> org.bluez.bluetoothd.getAdapters will return a array of the
> available devices
>=20
That's exactly what I do now in org.bluetool.manager.ListDevices.
I was thinking if it's worth returning, for each adapter, together
with the device path, a boolean value indicating if the device is up
or not, so that applications can immediately check what adapters a
effectively 'available'
ps: I also added signals which are broadcasted when an interface is
brought up/down
Another big concern I'm having is about security, most hciconfig
commands require 'higher than normal' privileges to execute, should
the daemon allow certain requests only to the root user ? (luckily
dbus was conceived with security in mind, so adding such a policy
would not be difficult).
This would just make things more complicated and I don't think there's
any real gain in doing so, but maybe there are some security issues I
ignore at the moment, let me know your opinion.
(if for example, a program calls ListDevices to list the adapters, and
the user wants to use an interface which is not active, should the
program be allowed to bring it up?)
> 2. Call a method to setup the default adapter.
> org.bluez.bluetoothd.setDefaultAdapter, passing the adapter id
>=20
What if two (or more) applications chose, for whatever reason, to set
a different default adapter? If you *really* want such a mechanism,
maybe you should make such a method callable only by authorized code
(hence my dilemma above) or simply select the default adapter
internally in the daemon and don't expose this method at all.
> After that you will be able call the services passing the default path
>=20
> In the future we can try discover the best adapter to use and set it as
> default.
>=20
> Regards,
> Claudio.
>=20
>=20
Regards,
Paul
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Elvis,
> this is a wrong argument. The case with only one adapter is
> the special
> case. Multiple adapters are default.
>
> You mean, e.g. a computer with multiple dongles?
the fully correct term would be "host with multiple adapters".
Regards
Marcel
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Peter,
I am planning provide a D-Bus service for setup a default adapter. But
the developer will
have to call a service to discover all available adapters. The steps shall =
be:
1. Call a method to discover the available adapters=20
org.bluez.bluetoothd.getAdapters will return a array of the
available devices
2. Call a method to setup the default adapter.
org.bluez.bluetoothd.setDefaultAdapter, passing the adapter id=20
After that you will be able call the services passing the default path
In the future we can try discover the best adapter to use and set it as
default.
Regards,
Claudio.
On 8/22/05, Peter Robinson <[email protected]> wrote:
> On 8/22/05, Claudio Takahasi <[email protected]> wrote:
> > Hi folks,
> >
> >
> > It's possible register multiple D-Bus object paths. My suggestion
> > for handle multiple adapters is register a default path and paths
> > based on the device address.
> > eg: suppose two adapters(11:22:33:44:55:66, 77:88:99:00:11:22)
> >
> > The possible paths are:
> >
> > /org/bluez/bluetoothd/hci (default path - first adapter)
> > /org/bluez/bluetoothd/112233445566/hci (first adapter)
> > /org/bluez/bluetoothd/778899001122/hci (second adapter)
> >
> > /org/bluez/bluetoothd/pan (default path - first adapter)
> > /org/bluez/bluetoothd/112233445566/pan (first adapter)
> > /org/bluez/bluetoothd/778899001122/pan (second adapter)
> > ...
> >
> > The service to list the adapter must be moved to the main path
> > (/org/bluez/bluetoothd) or to a new one /org/bluez/bluetoothd/devices.
> >
> > The message handle function will become more complex, but I don't
> > see other solution.
>=20
> What happens if you want to use your second adapter as the default? EG
> if I have a BT2.0 and a BT1.2 adapter but the BT1.2 adapter is
> detected first but you want to use the BT2.0 adapter as the default as
> its faster.
>=20
> Peter
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic=
es
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q=
A
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On 8/22/05, Claudio Takahasi <[email protected]> wrote:
> Hi folks,
>=20
>=20
> It's possible register multiple D-Bus object paths. My suggestion
> for handle multiple adapters is register a default path and paths
> based on the device address.
> eg: suppose two adapters(11:22:33:44:55:66, 77:88:99:00:11:22)
>=20
> The possible paths are:
>=20
> /org/bluez/bluetoothd/hci (default path - first adapter)
> /org/bluez/bluetoothd/112233445566/hci (first adapter)
> /org/bluez/bluetoothd/778899001122/hci (second adapter)
>=20
> /org/bluez/bluetoothd/pan (default path - first adapter)
> /org/bluez/bluetoothd/112233445566/pan (first adapter)
> /org/bluez/bluetoothd/778899001122/pan (second adapter)
> ...
>=20
> The service to list the adapter must be moved to the main path
> (/org/bluez/bluetoothd) or to a new one /org/bluez/bluetoothd/devices.
>=20
> The message handle function will become more complex, but I don't
> see other solution.
What happens if you want to use your second adapter as the default? EG
if I have a BT2.0 and a BT1.2 adapter but the BT1.2 adapter is
detected first but you want to use the BT2.0 adapter as the default as
its faster.
Peter
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi folks,
It's possible register multiple D-Bus object paths. My suggestion=20
for handle multiple adapters is register a default path and paths
based on the device address.=20
eg: suppose two adapters(11:22:33:44:55:66, 77:88:99:00:11:22)
The possible paths are:
/org/bluez/bluetoothd/hci (default path - first adapter)
/org/bluez/bluetoothd/112233445566/hci (first adapter)
/org/bluez/bluetoothd/778899001122/hci (second adapter)
/org/bluez/bluetoothd/pan (default path - first adapter)
/org/bluez/bluetoothd/112233445566/pan (first adapter)
/org/bluez/bluetoothd/778899001122/pan (second adapter)
...
The service to list the adapter must be moved to the main path
(/org/bluez/bluetoothd) or to a new one /org/bluez/bluetoothd/devices.
The message handle function will become more complex, but I don't
see other solution.
Regards,
Claudio.
On 8/22/05, Elvis Pf=FCtzenreuter <[email protected]> wrote:
>=20
> =20
> > this is a wrong argument. The case with only one adapter is the special
> > case. Multiple adapters are default.
>=20
> You mean, e.g. a computer with multiple dongles?=20
> =20
>=20
>
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
> this is a wrong argument. The case with only one adapter is the special
> case. Multiple adapters are default.
You mean, e.g. a computer with multiple dongles?
Hi Elvis,
> Probably my poor english caused some misunderstanding, the
> address
> *IS* part of the object path already, I can handle several
> adapters
> without any problems right now, and every adapter has a path
> like
> /org/bluetool/<BDADDR>/device
>
> Maybe even the "device" word in the path is unnecessary, since the
> address implies the notion of an adapter? Also, if you want to support
> multiple BT adapters, there could be a "default" path (independent of
> the address) so most applications would just use that instead of first
> finding the mac addresses of the adapters... How many machines in the
> world have more than 1 adapter? :)
this is a wrong argument. The case with only one adapter is the special
case. Multiple adapters are default.
Regards
Marcel
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
> Probably my poor english caused some misunderstanding, the address
> *IS* part of the object path already, I can handle several adapters
> without any problems right now, and every adapter has a path like
> /org/bluetool/<BDADDR>/device
Maybe even the "device" word in the path is unnecessary, since the address
implies the notion of an adapter? Also, if you want to support multiple BT
adapters, there could be a "default" path (independent of the address) so
most applications would just use that instead of first finding the mac
addresses of the adapters... How many machines in the world have more than 1
adapter? :)
if the property is not a string or the parameters are not bytes, an
> exception is thrown by the dbus wrapper (see the 'try' block at the
> beginning?) and I send an error message back to the caller explaining
> the error, otherwise everything goes on linearly
>
> What the "database" does (this database is not sdpd, it's an object
> created by the bluetool daemon), is simply to find what "helpers" are
> installed (ie: reading a list from a configuration file) and execute
> them, not much more actually :) every helper in turn registers its own
> object path and waits
So, as I could understand, you would use one process per profile, and the
main deamon would forward orders via DBUS to these 'slaves'?
Another thing, will all these deamons be integrated into bluez-utils? Or it
would be an independent BT deamon initiative? Which would be the dependency
relationship with bluez-utils, and other libraries like, possibly, glib?
A last comment (given that my DBUS knowledge is poor) would be that throwing
all interfaces on the same object turns more difficult to the clients to
identify which services are available (they would have to use some form of
interface introspection (which is probably more boring than just scanning
the object namespace?). Also, I don't know if it is possible to turn on/turn
off some interface on an object at will during runtime - registering and
unregistering an object I know it is quite easy :P
--
Elvis
Hi Claudio,
> In my opinion the bluetooth address should be part of the object path.
> The approach of use the bdaddr in the object path make possible
> address multiple adapters. By other hand, each adapter should export
> a distinct D-Bus path.
>=20
> org/bluetool/00_12_D4_05_70_BA/hci
> org/bluetool/00_12_D4_05_70_BA/sdp
> org/bluetool/00_12_D4_05_70_BA/rfcomm
>=20
Probably my poor english caused some misunderstanding, the address
*IS* part of the object path already, I can handle several adapters
without any problems right now, and every adapter has a path like
/org/bluetool/<BDADDR>/device
> But considering that the most common scenario is only one bluetooth
> adapter this
> approach is feasible.
>=20
> > Device objects are, of course, the most important, since their methods
> > allow to actually manipulate the device the way it's done nowadays
> > with the bluez-utils, but using dbus messages (which can be also
> > handled asynchronously, something the cli utils can't do), since I
> > said devices are objects, they're expected to implement interfaces,
> > and in fact there's a couple of them (as in many programming
> > languages, also in DBUS nothing prevents an object to implement more
> > than one interface), they're
> > org.bluetool.device.hci
> > org.bluetool.device.sdp
> > org.bluetool.device.rfcomm
> > and so on..
> [Claudio Takahasi]
> Two approachs can be done here. You can use one object with multiples
> interfaces or you can use fallback approach where each service will
> have a specific path in the hierarchy(D-Bus object fallback).
> In the first case you shall create only one D-Bus message handler functio=
n
> (a very huge function) to handle all interfaces. In the second option,
> you can develop using a more modular approach, each profile shall have
> their own D-Bus message handler.
>=20
I've gone for the first approach, a single device object implements
several interfaces, and despite what you think, there's no "huge
dispatch function" involved, every interface is a class on its own
(remember we're talking C++ and not C here) resides in a seperate file
and contains only the code necessary to handle the messages for its
interface, message routing happens automatically in the DBus wrapper
and I don't have to do much else
>=20
> > what they do is more or less what's in the bluez-utils already, the
> > hci interface (this expression is rendundant, I know :) is a bit
> > particular, since most of the functionalities previously contained in
> > the hci utils are now grouped in just two methods,
> > org.bluetool.hci.GetProperty and org.bluetool.hci.SetProperty, they
> > take the property name (as a string) as the first parameter, while the
> > others depend upon the property (of course DBUS allows to do some type
> > checking and to report to the caller an error if the parameters are of
> > the wrong type or number, and errors are obviously reported using
> > ErrorMessages which DBus provides natively) doing so simplified a lot
> > the interface.
> [Claudio Takahasi]
> This approach of use "GetProperty"and "SetProperty" for the functionaliti=
es
> provided by hciconfig is more attractive, but the coding for verify the m=
essage
> signature will be more complex.
>=20
do you think? here's the code to set the device class (takes three
bytes as input)
void HciDevice::SetProperty( const DBus::CallMessage& msg )
{
=09DBus::ReturnMessage *reply =3D new DBus::ReturnMessage(msg);
=09try
=09{
=09=09DBus::MessageIter i =3D msg.r_iter();
=09=09std::string property =3D i.get_string();
=09=09++i;
=09
// an if statement starts here.....
=09=09else
=09=09if( property =3D=3D "class" )
=09=09{
=09=09=09u8 major =3D i.get_byte(); ++i;
=09=09=09u8 minor =3D i.get_byte(); ++i;
=09=09=09u8 service =3D i.get_byte();
=09=09=09Hci::LocalDevice::set_class(major,minor,service,reply,HCI_TIMEOUT)=
;
=09=09=09//beware, set_class this is an inherited member function
=09=09=09//NOT a static method
=09=09}
if the property is not a string or the parameters are not bytes, an
exception is thrown by the dbus wrapper (see the 'try' block at the
beginning?) and I send an error message back to the caller explaining
the error, otherwise everything goes on linearly
> > another thing BluetoolDevice class instances (I'm using a C++ wrapper
> > for DBus I've written myself, so dbus objects map directly to C++
> > objects) do, is to listen for HCI events on a dedicated socket and
> > keep track of all the events received, this allows to handle method
> > invocations from the bus in an almost asynchronous way, allowing to
> > handle several simultaneous requests (this has a limitation, two
> > requests of the same type, for example two inquiry scans, cannot be
> > done at the same time and the last one is queued), this also allows to
> > receive inquiry_result and [dis]connection_complete events, so, for
> > example, inquiry results can be put in a cache which can be fastly
> > accessed by clients without issuing an inquiry every time.
> > remote devices are objects as well, they have a path (which is a
> > subpath of the local discovering device) and have methods to read
> > their remote name, to create ACL or SCO connections towards them, to
> > query their service database etc..
> > talking about service databases, there's also a local service database
> > which contains (guess..) services (keep in mind, the `sdpd` program is
> > yet another thing) ,every service implements the
> > 'org.bluetool.service' interface, with provides Start and Stop methods
> > (and go figure what they do :) and GetOption and SetOption methods,
> > the last two can automatically write the current settings on a
> > configuration file, allowing persistence across several start/stops of
> > the service, the real services (which are subclasses of the class
> > introduced before) add other specific methods, but under the hood they
> > don't do much more than fork the appropriate process (`pand` or `dund`
> > for example) with the saved options, and kill it when it's not needed
> > anymore.
> [Claudio Takahasi]
> Could you provide more information about service databases? I am not
> understanding exactly how it will works and how you intend to keep the
> backward compatibility with the bluez daemons(sdp, pand, dund, ...)
>=20
it's something I'm still working on, so I'll give you more news about
that soon, for now, just to explain a bit, the name "services" is
inappropriate (but I couldn't come up with a better one) they don't
provide the service (daemons do) they're just small helper programs
which sit on the bus waiting for orders, so you say "Start()" and it
starts the daemon, "Stop()" kills it, you say "ListConnections()" (for
example in pand) and it makes an ioctl() and returns the connection
list (nicely packed into a dbus message) to the caller.
What the "database" does (this database is not sdpd, it's an object
created by the bluetool daemon), is simply to find what "helpers" are
installed (ie: reading a list from a configuration file) and execute
them, not much more actually :) every helper in turn registers its own
object path and waits
> Regards,
> Claudio Takahasi
>=20
re,
Paul
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Paul,
On 8/16/05, P. Durante <[email protected]> wrote:
> On 8/16/05, Claudio Takahasi <[email protected]> wrote:
> > Hi folks,
> >
> > I am posting a new draft of D-Bus architecture and Interfaces.
> >
> > If someone has comments regarding the design, interfaces or any kind
> > of question send us a feedback.
> >
> > This last draft contains some changes based on Johan Hedberg feedback
> > and new services.
> >
> > Major changes:
> > * Return "D-Bus error messages" instead of "method return" following
> > the Johan Hedberg suggestion
> > * Defined standard error messages
> > * Added "architecture" overview section.
> > * Using just one interface for request and signals instead of distinct
> > interfaces. The message type can be discovered using the message type
> > attribute embedded in the D-Bus message header.
> >
> > Location:
> > The document (draft 00.05) can be found at: http://www.cin.ufpe.br/~ckt=
/bluez
> >
> > Next action:
> > * define SDP D-Bus services and architecture.
> > * Multi-level disconnection/connection signals. Is it really
> > necessary? eg: send disconnect signal at pan and hci D-Bus interfaces.
> > * Signal level. Is it possible check it? IS it really necessary?
> > * Unify rfcomm and dun D-Bus services. Is it feasible?
> >
> >
> > Suggestions a welcome!
> >
> > Regards,
> > Claudio
> >
> >
> > -------------------------------------------------------
> > SF.Net email is Sponsored by the Better Software Conference & EXPO
> > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Pract=
ices
> > Agile & Plan-Driven Development * Managing Projects & Teams * Testing &=
QA
> > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5=
sf
> > _______________________________________________
> > Bluez-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/bluez-devel
> >
>=20
> Hi Claudio,
> your project seems pretty interesting to me, mostly because I've been
> implementing something almost identical for the last weeks, I hope
> I've gained some experience and that I could be useful commenting the
> way I'm doing it:
> I've got a dbus service at the root, let's call it 'org.bluetool'
> (it's not going to be the definitive name tough :)
> as the dbus specification says, services provide objects, and the main
> object here is the 'manager', (at /org/bluetool/manager'), its main
> role is to track the lifecycle of the bluetooth devices on the
> computer, it's interface (called, surprisingly 'org.bluetool.manager')
> emits two signals, when a device is added/removed (more or less the
> way the HAL does) and contains one method, "ListDevices", which
> returns a list of strings, each one representing a Device object
> (identified by its unique BDADDR, paths have the form
> "/org/bluetool/devices/00_12_D4_05_70_BA".
[Claudio Takahasi]
Your implementation has the same objective of bluetoothd. The BlueZ daemon =
aims=20
provide a common way to user mode applications control bluetooth adapters a=
nd
connections. Read the emails posted some months ago regarding the
bluez daemon(bluetoothd).
In my opinion the bluetooth address should be part of the object path.=20
The approach of use the bdaddr in the object path make possible
address multiple adapters. By other hand, each adapter should export=20
a distinct D-Bus path.
org/bluetool/00_12_D4_05_70_BA/hci
org/bluetool/00_12_D4_05_70_BA/sdp
org/bluetool/00_12_D4_05_70_BA/rfcomm
But considering that the most common scenario is only one bluetooth
adapter this
approach is feasible.
> Device objects are, of course, the most important, since their methods
> allow to actually manipulate the device the way it's done nowadays
> with the bluez-utils, but using dbus messages (which can be also
> handled asynchronously, something the cli utils can't do), since I
> said devices are objects, they're expected to implement interfaces,
> and in fact there's a couple of them (as in many programming
> languages, also in DBUS nothing prevents an object to implement more
> than one interface), they're
> org.bluetool.device.hci
> org.bluetool.device.sdp
> org.bluetool.device.rfcomm
> and so on..
[Claudio Takahasi]
Two approachs can be done here. You can use one object with multiples
interfaces or you can use fallback approach where each service will
have a specific path in the hierarchy(D-Bus object fallback).
In the first case you shall create only one D-Bus message handler function
(a very huge function) to handle all interfaces. In the second option,
you can develop using a more modular approach, each profile shall have
their own D-Bus message handler.
> what they do is more or less what's in the bluez-utils already, the
> hci interface (this expression is rendundant, I know :) is a bit
> particular, since most of the functionalities previously contained in
> the hci utils are now grouped in just two methods,
> org.bluetool.hci.GetProperty and org.bluetool.hci.SetProperty, they
> take the property name (as a string) as the first parameter, while the
> others depend upon the property (of course DBUS allows to do some type
> checking and to report to the caller an error if the parameters are of
> the wrong type or number, and errors are obviously reported using
> ErrorMessages which DBus provides natively) doing so simplified a lot
> the interface.
[Claudio Takahasi]
This approach of use "GetProperty"and "SetProperty" for the functionalities=
=20
provided by hciconfig is more attractive, but the coding for verify the mes=
sage=20
signature will be more complex.
> another thing BluetoolDevice class instances (I'm using a C++ wrapper
> for DBus I've written myself, so dbus objects map directly to C++
> objects) do, is to listen for HCI events on a dedicated socket and
> keep track of all the events received, this allows to handle method
> invocations from the bus in an almost asynchronous way, allowing to
> handle several simultaneous requests (this has a limitation, two
> requests of the same type, for example two inquiry scans, cannot be
> done at the same time and the last one is queued), this also allows to
> receive inquiry_result and [dis]connection_complete events, so, for
> example, inquiry results can be put in a cache which can be fastly
> accessed by clients without issuing an inquiry every time.
> remote devices are objects as well, they have a path (which is a
> subpath of the local discovering device) and have methods to read
> their remote name, to create ACL or SCO connections towards them, to
> query their service database etc..
> talking about service databases, there's also a local service database
> which contains (guess..) services (keep in mind, the `sdpd` program is
> yet another thing) ,every service implements the
> 'org.bluetool.service' interface, with provides Start and Stop methods
> (and go figure what they do :) and GetOption and SetOption methods,
> the last two can automatically write the current settings on a
> configuration file, allowing persistence across several start/stops of
> the service, the real services (which are subclasses of the class
> introduced before) add other specific methods, but under the hood they
> don't do much more than fork the appropriate process (`pand` or `dund`
> for example) with the saved options, and kill it when it's not needed
> anymore.
[Claudio Takahasi]
Could you provide more information about service databases? I am not=20
understanding exactly how it will works and how you intend to keep the=20
backward compatibility with the bluez daemons(sdp, pand, dund, ...)
Regards,
Claudio Takahasi
> As you'll see my project is pretty huge, especially because I had to
> complete it in just a couple of weeks and the time is almost over,
> every critique/suggestion would be greatly appreciated,
>=20
> Regards,
> Paul
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic=
es
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q=
A
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On 8/16/05, Claudio Takahasi <[email protected]> wrote:
> Hi folks,
>=20
> I am posting a new draft of D-Bus architecture and Interfaces.
>=20
> If someone has comments regarding the design, interfaces or any kind
> of question send us a feedback.
>=20
> This last draft contains some changes based on Johan Hedberg feedback
> and new services.
>=20
> Major changes:
> * Return "D-Bus error messages" instead of "method return" following
> the Johan Hedberg suggestion
> * Defined standard error messages
> * Added "architecture" overview section.
> * Using just one interface for request and signals instead of distinct
> interfaces. The message type can be discovered using the message type
> attribute embedded in the D-Bus message header.
>=20
> Location:
> The document (draft 00.05) can be found at: http://www.cin.ufpe.br/~ckt/b=
luez
>=20
> Next action:
> * define SDP D-Bus services and architecture.
> * Multi-level disconnection/connection signals. Is it really
> necessary? eg: send disconnect signal at pan and hci D-Bus interfaces.
> * Signal level. Is it possible check it? IS it really necessary?
> * Unify rfcomm and dun D-Bus services. Is it feasible?
>=20
>=20
> Suggestions a welcome!
>=20
> Regards,
> Claudio
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic=
es
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q=
A
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>=20
Hi Claudio,
your project seems pretty interesting to me, mostly because I've been
implementing something almost identical for the last weeks, I hope
I've gained some experience and that I could be useful commenting the
way I'm doing it:
I've got a dbus service at the root, let's call it 'org.bluetool'
(it's not going to be the definitive name tough :)
as the dbus specification says, services provide objects, and the main
object here is the 'manager', (at /org/bluetool/manager'), its main
role is to track the lifecycle of the bluetooth devices on the
computer, it's interface (called, surprisingly 'org.bluetool.manager')
emits two signals, when a device is added/removed (more or less the
way the HAL does) and contains one method, "ListDevices", which
returns a list of strings, each one representing a Device object
(identified by its unique BDADDR, paths have the form
"/org/bluetool/devices/00_12_D4_05_70_BA".
Device objects are, of course, the most important, since their methods
allow to actually manipulate the device the way it's done nowadays
with the bluez-utils, but using dbus messages (which can be also
handled asynchronously, something the cli utils can't do), since I
said devices are objects, they're expected to implement interfaces,
and in fact there's a couple of them (as in many programming
languages, also in DBUS nothing prevents an object to implement more
than one interface), they're
org.bluetool.device.hci
org.bluetool.device.sdp
org.bluetool.device.rfcomm
and so on..
what they do is more or less what's in the bluez-utils already, the
hci interface (this expression is rendundant, I know :) is a bit
particular, since most of the functionalities previously contained in
the hci utils are now grouped in just two methods,
org.bluetool.hci.GetProperty and org.bluetool.hci.SetProperty, they
take the property name (as a string) as the first parameter, while the
others depend upon the property (of course DBUS allows to do some type
checking and to report to the caller an error if the parameters are of
the wrong type or number, and errors are obviously reported using
ErrorMessages which DBus provides natively) doing so simplified a lot
the interface.
another thing BluetoolDevice class instances (I'm using a C++ wrapper
for DBus I've written myself, so dbus objects map directly to C++
objects) do, is to listen for HCI events on a dedicated socket and
keep track of all the events received, this allows to handle method
invocations from the bus in an almost asynchronous way, allowing to
handle several simultaneous requests (this has a limitation, two
requests of the same type, for example two inquiry scans, cannot be
done at the same time and the last one is queued), this also allows to
receive inquiry_result and [dis]connection_complete events, so, for
example, inquiry results can be put in a cache which can be fastly
accessed by clients without issuing an inquiry every time.
remote devices are objects as well, they have a path (which is a
subpath of the local discovering device) and have methods to read
their remote name, to create ACL or SCO connections towards them, to
query their service database etc..
talking about service databases, there's also a local service database
which contains (guess..) services (keep in mind, the `sdpd` program is
yet another thing) ,every service implements the
'org.bluetool.service' interface, with provides Start and Stop methods
(and go figure what they do :) and GetOption and SetOption methods,
the last two can automatically write the current settings on a
configuration file, allowing persistence across several start/stops of
the service, the real services (which are subclasses of the class
introduced before) add other specific methods, but under the hood they
don't do much more than fork the appropriate process (`pand` or `dund`
for example) with the saved options, and kill it when it's not needed
anymore.
As you'll see my project is pretty huge, especially because I had to
complete it in just a couple of weeks and the time is almost over,
every critique/suggestion would be greatly appreciated,
Regards,
Paul
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Claudio,
> Regarding the special HCI_DEV_NONE system socket with vendor packet
> type. Do you
> have a patch for it or it just ideas for BlueZ improvements? What are
> exactly the events that
> you want send in this socket?
the latest hcidump has support for dumping these packets, but at the
moment the kernel is not sending any of them. I still have to implement
the kernel part for it. Only the basic frame format is defined at the
moment, but no actual message packets are defined.
The main messages would be notifying about added/removed adapters on the
system. Also the exchange of pin code and link keys between the kernel
and the userspace is what I have in mind. The other thing would be
notification of inquiry responses and name resolves. And then I am open
for suggestions.
Regards
Marcel
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel