Hi Marcel,
here is the patch with the initial development of setproperty and
getproperty for /org/bluez/Device/hciX. As this is only the fundation,
I didn't update the python script.
BR,
Eduardo.
--
Eduardo Rocha
Instituto Nokia de Tecnologia - INdT
Hi Claudio,
> I think we are confusing some D-Bus concepts.
>
> Currently, hcid is connected to the "system" bus, because the
> Bluetooth adapter is a shared resource and it can be used by any
> logged-in user or remote users. As long as I known the "system bus"
> should be used for notification from the system to user sessions(it's
> accessible to all applications on the system). The "session bus"
> should be used to implement desktop environments communication. The
> address of the per-session bus daemon is automatically discovered by
> reading an environment variable. A login session message bus is
> started each time a user logs in.
this is my understanding, too.
> If we choose use the session bus, probably it will required huge code
> modification in order to support multiple bus session connection or
> start a new BlueZ D-Bus daemon for each user session. In my opinion,
> this approach is not feasible.
This will simply not work, because there can be only one daemon at a
time and it must run all the time.
> If you want provide BlueZ D-Bus services only for the logged-in user,
> we can try analise the modifications required to control the D-Bus
> connections and its drawbacks.
The D-Bus services are available in general, but I wanna restrict the
methods that are actually modifying settings to the root user and/or the
currently logged in user. The hal.conf uses "<policy at_console="true">"
to provide this (if I am not mistaken).
Remember that we are talking about the default configuration. We don't
need to provide the best security model, but at least a decent one. For
me this means that the root user and the currently logged in user have
full control over the device. All other users are restricted.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi,
I think we are confusing some D-Bus concepts.
Currently, hcid is connected to the "system" bus, because the
Bluetooth adapter is a shared resource and it can be used by any
logged-in user or remote users. As long as I known the "system bus"
should be used for notification from the system to user sessions(it's
accessible to all applications on the system). The "session bus"
should be used to implement desktop environments communication. The
address of the per-session bus daemon is automatically discovered by
reading an environment variable. A login session message bus is
started each time a user logs in.
If we choose use the session bus, probably it will required huge code
modification in order to support multiple bus session connection or
start a new BlueZ D-Bus daemon for each user session. In my opinion,
this approach is not feasible.
If you want provide BlueZ D-Bus services only for the logged-in user,
we can try analise the modifications required to control the D-Bus
connections and its drawbacks.
Regards,
Claudio.
On 11/25/05, Marcel Holtmann <[email protected]> wrote:
> Hi Eduardo,
>
> > > For what do we need a special bluezadmin group? I think that the user
> > > should enter the root password for configuration or it should be cons=
ole
> > > or session user.
> >
> > a group is needed for better dbus client security. If only root is
> > allowed, the client will have to be run as root (by sudo or suid). In
> > this case the machine security can be compromised by a buffer overflow
> > in the client. If we use a group, users that can change bluetooth
> > props should be added to that group, and the client application can be
> > run as a normal user. So if the dbus client app has a flaw, it will
> > not compromise the whole machine.
>
> I would prefer not to add a new group and use the at_console identify of
> D-Bus (if possible) instead. We need to identify the session user.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
--
---------------------------------------------------------
Claudio Takahasi
Instituto Nokia de Tecnologia - INdT
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Eduardo,
> > For what do we need a special bluezadmin group? I think that the user
> > should enter the root password for configuration or it should be console
> > or session user.
>
> a group is needed for better dbus client security. If only root is
> allowed, the client will have to be run as root (by sudo or suid). In
> this case the machine security can be compromised by a buffer overflow
> in the client. If we use a group, users that can change bluetooth
> props should be added to that group, and the client application can be
> run as a normal user. So if the dbus client app has a flaw, it will
> not compromise the whole machine.
I would prefer not to add a new group and use the at_console identify of
D-Bus (if possible) instead. We need to identify the session user.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
On 11/25/05, Marcel Holtmann <[email protected]> wrote:
> For what do we need a special bluezadmin group? I think that the user
> should enter the root password for configuration or it should be console
> or session user.
a group is needed for better dbus client security. If only root is
allowed, the client will have to be run as root (by sudo or suid). In
this case the machine security can be compromised by a buffer overflow
in the client. If we use a group, users that can change bluetooth
props should be added to that group, and the client application can be
run as a normal user. So if the dbus client app has a flaw, it will
not compromise the whole machine.
Of course the dbus server need to be executed as root.
BR,
Eduardo.
> Hi Claudio,
>
> > IMHO, it's enough two level of security. My suggestion is create a
> > bluezadmin group to
> > allow the device setup operations(write operations). Read operations
> > can be allowed to
> > bluezusers and bluezadmin. Another point is only the root can own the
> > service, I mean,
> > Only the root can run the hcid daemon.
>
> I don't see any need of having a bluezusers group. There are tasks that
> everybody can execute and I don't see any problem with it.
>
> For what do we need a special bluezadmin group? I think that the user
> should enter the root password for configuration or it should be console
> or session user.
>
> And yes, hcid will always need to be run as root.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
--
Eduardo Rocha
Instituto Nokia de Tecnologia - INdT
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Johan,
> > come up with some proposals. I have real clue, but we should have some
> > special rights for the current session user.
>
> What do you mean by "current session user"?
the currently logged in user can modify settings etc. I think the D-Bus
speaks about at_console or something like that. The idea behind this is
that a local user can use the Bluetooth device, but a remote user can't.
For me that is enough for a default security.
> I'd propose essentially a two level system where you have a level which
> is allowed to do everything, and another one which only allows "normal
> user" operations. root and users belonging to the "bluetooth" (or
> "btadmin" or whatever) group would be on the "everyting allowed" level,
> while everyone else would be on the other.
>
> Of course this doesn't mean that distributions couldn't replace the
> policy with a more flexible (and complex) one to suit their needs. I'm
> just proposing this to be the default that comes with bluez-utils.
>
> Also, I don't think it makes sense for the default D-BUS policy (which
> comes with upstream with bluez-utils) to deny a normal user things that
> can anyway be done using libbluetooth directly (e.g. using the command
> line tools).
This will be done by the security settings inside the kernel. The
general rule was to allow all reads, but no writes to normal users.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Claudio,
> IMHO, it's enough two level of security. My suggestion is create a
> bluezadmin group to
> allow the device setup operations(write operations). Read operations
> can be allowed to
> bluezusers and bluezadmin. Another point is only the root can own the
> service, I mean,
> Only the root can run the hcid daemon.
I don't see any need of having a bluezusers group. There are tasks that
everybody can execute and I don't see any problem with it.
For what do we need a special bluezadmin group? I think that the user
should enter the root password for configuration or it should be console
or session user.
And yes, hcid will always need to be run as root.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
On Thu, Nov 24, 2005, Marcel Holtmann wrote:
> come up with some proposals. I have real clue, but we should have some
> special rights for the current session user.
What do you mean by "current session user"?
I'd propose essentially a two level system where you have a level which
is allowed to do everything, and another one which only allows "normal
user" operations. root and users belonging to the "bluetooth" (or
"btadmin" or whatever) group would be on the "everyting allowed" level,
while everyone else would be on the other.
Of course this doesn't mean that distributions couldn't replace the
policy with a more flexible (and complex) one to suit their needs. I'm
just proposing this to be the default that comes with bluez-utils.
Also, I don't think it makes sense for the default D-BUS policy (which
comes with upstream with bluez-utils) to deny a normal user things that
can anyway be done using libbluetooth directly (e.g. using the command
line tools).
Johan
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Claudio,
in the last email you mean 3 levels of security (bluezadmin,
bluezusers, and default). I think is a good idea for the client to
have local user id and not root (not use setuid for root). Making one
or more groups I think is more flexibe. With the current operations, I
only don't see the poit to have a Manager path. I think this
operations can be mapped by Device path.
BR,
Eduardo.
On 11/25/05, Claudio Takahasi <[email protected]> wrote:
> Hi,
>
> IMHO, it's enough two level of security. My suggestion is create a
> bluezadmin group to
> allow the device setup operations(write operations). Read operations
> can be allowed to
> bluezusers and bluezadmin. Another point is only the root can own the
> service, I mean,
> Only the root can run the hcid daemon.
>
> /org/bluez/Manager
> - get default device
> - list adapters
> /org/bluez/Device/hciX
> - UP (*)
> - Down (*)
> - SetProperty (*)
> - GetProperty
> /org/bluez/Device/hciX/Controller
> /org/bluez/Device/hciX/Network
> /org/bluez/Device/hciX/Serial
>
> Configuration file suggestion:
> <!DOCTYPE busconfig PUBLIC
> "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
> "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
> <busconfig>
>
> <!-- This configuration file specifies the required security policies
> for the BlueZ to work. -->
>
> <!-- Only root can own the BlueZ service -->
> <policy user=3D"root">
> <allow own=3D"org.bluez"/>
> </policy>
>
> <policy group=3D"bluezadmin">
> <allow receive_interface=3D"org.bluez.Manager"/>
> <allow receive_interface=3D"org.bluez.Device"/>
> <allow send_interface=3D"org.bluez.Manager"/>
> <allow send_interface=3D"org.bluez.Device"/>
> </policy>
>
> <policy group=3D"bluezusers">
> <allow receive_interface=3D"org.bluez.Manager"/>
> <allow receive_interface=3D"org.bluez.Device"/>
> <allow send_interface=3D"org.bluez.Manager"/>
> <allow send_interface=3D"org.bluez.Device"/>
> <deny send_interface=3D"org.bluez.Device" send_member=3D"Up"/>
> <deny send_interface=3D"org.bluez.Device" send_member=3D"Down"/>
> <deny send_interface=3D"org.bluez.Device" send_member=3D"SetProperty"=
/>
> </policy>
>
> <!-- Deny anyone to invoke methods on the Manager and Device interfaces=
-->
> <policy context=3D"default">
> <deny own=3D"org.bluez"/>
> <deny send_interface=3D"org.bluez.Manager"/>
> <deny send_interface=3D"org.bluez.Device"/>
> <deny receive_interface=3D"org.bluez.Manager"/>
> <deny receive_interface=3D"org.bluez.Device"/>
> </policy>
>
> </busconfig>
>
> Regards,
> Claudio
>
> On 11/24/05, Marcel Holtmann <[email protected]> wrote:
> > Hi Eduardo,
> >
> > > maybe we should create a bluetooth group and only allow users of that
> > > group to make write operations. I'll also check eht dbus auth to see
> > > if that can help. Do you have in mind any operation->"security level"
> > > map?
> >
> > come up with some proposals. I have real clue, but we should have some
> > special rights for the current session user.
> >
> > Regards
> >
> > Marcel
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log =
files
> > for problems? Stop! Download the new AJAX search engine that makes
> > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> > _______________________________________________
> > Bluez-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/bluez-devel
> >
>
>
> --
> ---------------------------------------------------------
> Claudio Takahasi
> Instituto Nokia de Tecnologia - INdT
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_idv37&alloc_id=16865&opclick
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
--
Eduardo Rocha
Instituto Nokia de Tecnologia - INdT
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi,
IMHO, it's enough two level of security. My suggestion is create a
bluezadmin group to
allow the device setup operations(write operations). Read operations
can be allowed to
bluezusers and bluezadmin. Another point is only the root can own the
service, I mean,
Only the root can run the hcid daemon.
/org/bluez/Manager
- get default device
- list adapters
/org/bluez/Device/hciX
- UP (*)
- Down (*)
- SetProperty (*)
- GetProperty
/org/bluez/Device/hciX/Controller
/org/bluez/Device/hciX/Network
/org/bluez/Device/hciX/Serial
Configuration file suggestion:
<!DOCTYPE busconfig PUBLIC
"-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
<!-- This configuration file specifies the required security policies
for the BlueZ to work. -->
<!-- Only root can own the BlueZ service -->
<policy user=3D"root">
<allow own=3D"org.bluez"/>
</policy>
<policy group=3D"bluezadmin">
<allow receive_interface=3D"org.bluez.Manager"/>
<allow receive_interface=3D"org.bluez.Device"/>
<allow send_interface=3D"org.bluez.Manager"/>
<allow send_interface=3D"org.bluez.Device"/>
</policy>
<policy group=3D"bluezusers">
<allow receive_interface=3D"org.bluez.Manager"/>
<allow receive_interface=3D"org.bluez.Device"/>
<allow send_interface=3D"org.bluez.Manager"/>
<allow send_interface=3D"org.bluez.Device"/>
<deny send_interface=3D"org.bluez.Device" send_member=3D"Up"/>
<deny send_interface=3D"org.bluez.Device" send_member=3D"Down"/>
<deny send_interface=3D"org.bluez.Device" send_member=3D"SetProperty"/>
</policy>
<!-- Deny anyone to invoke methods on the Manager and Device interfaces -=
->
<policy context=3D"default">
<deny own=3D"org.bluez"/>
<deny send_interface=3D"org.bluez.Manager"/>
<deny send_interface=3D"org.bluez.Device"/>
<deny receive_interface=3D"org.bluez.Manager"/>
<deny receive_interface=3D"org.bluez.Device"/>
</policy>
</busconfig>
Regards,
Claudio
On 11/24/05, Marcel Holtmann <[email protected]> wrote:
> Hi Eduardo,
>
> > maybe we should create a bluetooth group and only allow users of that
> > group to make write operations. I'll also check eht dbus auth to see
> > if that can help. Do you have in mind any operation->"security level"
> > map?
>
> come up with some proposals. I have real clue, but we should have some
> special rights for the current session user.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
--
---------------------------------------------------------
Claudio Takahasi
Instituto Nokia de Tecnologia - INdT
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Eduardo,
> maybe we should create a bluetooth group and only allow users of that
> group to make write operations. I'll also check eht dbus auth to see
> if that can help. Do you have in mind any operation->"security level"
> map?
come up with some proposals. I have real clue, but we should have some
special rights for the current session user.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
maybe we should create a bluetooth group and only allow users of that
group to make write operations. I'll also check eht dbus auth to see
if that can help. Do you have in mind any operation->"security level"
map?
BR,
Eduardo.
On 11/24/05, Marcel Holtmann <[email protected]> wrote:
> Hi Eduardo,
>
> > here is the new patch. I've removed the spaces (I hope so). I've also
> > included the code for the dbus signal for the local name change event.
> > One thing that remainded open was the timeout for hci_send_req for
> > name write and name read ops. In the hciconfig this was 2s and 1s. Is
> > there a reason for this big number?
>
> you missed one whitespace/tab clash, but I fixed it. Opening a patch
> inside an editor with whitespace visualization helps a lot.
>
> The patch has been applied to the CVS and we should talk about some
> serious security setting for the D-Bus interface. Question is what a
> session user should be able to change?
>
> The timeout is not really crucial for most local configuration settings
> and I think it was a bad idea to have it in the API anyhow. However the
> change local name command is tricky. Some older CSR chips for example
> are storing the name in the PS keys, which results writing it to flash
> or EEPROM. This simply can take time.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
--
Eduardo Rocha
Instituto Nokia de Tecnologia - INdT
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Eduardo,
> here is the new patch. I've removed the spaces (I hope so). I've also
> included the code for the dbus signal for the local name change event.
> One thing that remainded open was the timeout for hci_send_req for
> name write and name read ops. In the hciconfig this was 2s and 1s. Is
> there a reason for this big number?
you missed one whitespace/tab clash, but I fixed it. Opening a patch
inside an editor with whitespace visualization helps a lot.
The patch has been applied to the CVS and we should talk about some
serious security setting for the D-Bus interface. Question is what a
session user should be able to change?
The timeout is not really crucial for most local configuration settings
and I think it was a bad idea to have it in the API anyhow. However the
change local name command is tricky. Some older CSR chips for example
are storing the name in the PS keys, which results writing it to flash
or EEPROM. This simply can take time.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
here is the new patch. I've removed the spaces (I hope so). I've also
included the code for the dbus signal for the local name change event.
One thing that remainded open was the timeout for hci_send_req for
name write and name read ops. In the hciconfig this was 2s and 1s. Is
there a reason for this big number?
BR,
Eduardo
On 11/22/05, Marcel Holtmann <[email protected]> wrote:
> Hi Eduardo,
>
> > here is the patch with a better implementation of dbus-test
> > SetProperty. I've also changed the "pscan" to "connectable" and
> > "iscan" to "discoverable".
>
> I basically missed this thread, but from a first look at the attached
> patch, I can tell that the coding style is wrong. Fix it and re-send it.
>
> Turn the whitespace visualization of editor on ;)
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
> Register for a JBoss Training Course. Free Certification Exam
> for All Training Attendees Through End of 2005. For more info visit:
> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
--
Eduardo Rocha
Instituto Nokia de Tecnologia - INdT
Hi Eduardo,
> here is the patch with a better implementation of dbus-test
> SetProperty. I've also changed the "pscan" to "connectable" and
> "iscan" to "discoverable".
I basically missed this thread, but from a first look at the attached
patch, I can tell that the coding style is wrong. Fix it and re-send it.
Turn the whitespace visualization of editor on ;)
Regards
Marcel
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi all,
here is the patch with a better implementation of dbus-test
SetProperty. I've also changed the "pscan" to "connectable" and
"iscan" to "discoverable".
BR,
Eduardo
On 11/18/05, Johan Hedberg <[email protected]> wrote:
> On Fri, Nov 18, 2005, Eduardo Rocha wrote:
> > Could you give any comments about the hci_send_req timeout (maybe is
> > too high)
>
> I'd guess that the command should take max. 100ms, so 2s timeout is
> probably unnecessarely big. However, Marcel might have had a good reason
> to use the current timeout in hciconfig.
>
> > and the extended inquire parameters that is set cmd_name function in
> > hciconfig app (is that needed here?).
>
> If it's not there, then we should at least provide a D-BUS method to set
> the extended inquiry parameters (which is probably a good thing as the
> user might want to have other informantion there besides the name, e.g.
> SDP UUID list).
>
> > About the parameters, I've done an if to detect each property name so
> > we can treat the parameter diferently.
>
> Yeah, you're right, that works also. However, I was thinking of
> solutions where dbus-send wouldn't need to know the property name -
> property type mapping.
>
> Johan
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
> Register for a JBoss Training Course. Free Certification Exam
> for All Training Attendees Through End of 2005. For more info visit:
> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
--
Eduardo Rocha
Instituto Nokia de Tecnologia - INdT
On Fri, Nov 18, 2005, Eduardo Rocha wrote:
> Could you give any comments about the hci_send_req timeout (maybe is
> too high)
I'd guess that the command should take max. 100ms, so 2s timeout is
probably unnecessarely big. However, Marcel might have had a good reason
to use the current timeout in hciconfig.
> and the extended inquire parameters that is set cmd_name function in
> hciconfig app (is that needed here?).
If it's not there, then we should at least provide a D-BUS method to set
the extended inquiry parameters (which is probably a good thing as the
user might want to have other informantion there besides the name, e.g.
SDP UUID list).
> About the parameters, I've done an if to detect each property name so
> we can treat the parameter diferently.
Yeah, you're right, that works also. However, I was thinking of
solutions where dbus-send wouldn't need to know the property name -
property type mapping.
Johan
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Johan,
sorry about the tabs. Here is the new patch. Could you give any
comments about the hci_send_req timeout (maybe is too high) and the
extended inquire parameters that is set cmd_name function in hciconfig
app (is that needed here?).
About the parameters, I've done an if to detect each property name so
we can treat the parameter diferently.
BR,
Eduardo.
On 11/18/05, Johan Hedberg <[email protected]> wrote:
> Hi Eduardo,
>
> Your patch looks ok in general, however there are a couple of issues I'd
> like to comment on:
>
> 1. The string given to the syslog call in the "if (status)" part of the
> handle_device_set_propety_req_name function is wrong (just a simple
> copy-paste mistake).
>
> 2. The list assigned to the dev_cmds variable in the dbus-test app could
> be reformated to be max 80 chars wide.
>
> 3. There are several places in dbus-test where the indentation is wrong:
> some places there are extra spaces, others have too few. You have also
> mixed tabs and spaces in a couple of places (the indentation should, at
> least for now, use 4 spaces).
>
> 4. You don't need to use dbus.String(var) when giving a string variable
> to a method call using the python bindings.
>
> 5. We should think of how to allow giving different types (bool, byte,
> string) to the SetProperty method using dbus-test. One way to do it
> would be to give four parameters in the command line (e.g. "SetProperty
> connectable b true" or "SetProperty name s MyName"). Another option is
> to change to the HAL way of doing properties (by having
> SetPropertyString, SetPropertyBoolean, etc).
>
> Johan
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
> Register for a JBoss Training Course. Free Certification Exam
> for All Training Attendees Through End of 2005. For more info visit:
> http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
--
Eduardo Rocha
Instituto Nokia de Tecnologia - INdT
Hi Eduardo,
Your patch looks ok in general, however there are a couple of issues I'd
like to comment on:
1. The string given to the syslog call in the "if (status)" part of the
handle_device_set_propety_req_name function is wrong (just a simple
copy-paste mistake).
2. The list assigned to the dev_cmds variable in the dbus-test app could
be reformated to be max 80 chars wide.
3. There are several places in dbus-test where the indentation is wrong:
some places there are extra spaces, others have too few. You have also
mixed tabs and spaces in a couple of places (the indentation should, at
least for now, use 4 spaces).
4. You don't need to use dbus.String(var) when giving a string variable
to a method call using the python bindings.
5. We should think of how to allow giving different types (bool, byte,
string) to the SetProperty method using dbus-test. One way to do it
would be to give four parameters in the command line (e.g. "SetProperty
connectable b true" or "SetProperty name s MyName"). Another option is
to change to the HAL way of doing properties (by having
SetPropertyString, SetPropertyBoolean, etc).
Johan
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
sorry about my last patch. I've left some syslog entries. Here is a new patch.
br,
Eduardo.
On 11/17/05, Eduardo Rocha <[email protected]> wrote:
> Hi all,
>
> here is a patch with SetProperty and GetProperty for Name. I've also
> updated the dbus-test.
> Marcel, in the hciconfig you set the ext inquire parameter in the
> cmd_name function. Is this needed here?
> The "local name changed" signal is still missing. I'll do that for
> the next patch.
>
> BR,
> Eduardo.
>
> --
> Eduardo Rocha
> Instituto Nokia de Tecnologia - INdT
>
>
> On 11/8/05, Marcel Holtmann <[email protected]> wrote:
> > Hi Johan,
> >
> > > > name [name] Get/Set local name
> > >
> > > This is good to have. A "local name changed" signal might also be useful
> > > so that other applications can update their UI. Actually now that I
> > > think about it, maybe thare should be a generic "property changed"
> > > signal for all properties.
> >
> > sounds like a good idea and easy to extend in the future.
> >
> > > > auth Enable/Disable Authentication
> > > > encrypt Enable/Disable Encryption
> > > > secmgr Enable/Disable Security Manager
> > > > piscan Enable/Disable Page and Inquiry scan
> > > > iscan Enable/Disable Inquiry scan
> > > > pscan Enable/Disable Page scan
> > >
> > > I think the piscan can be dropped so that we have two boolean
> > > properties: iscan and pscan.
> > >
> > > Also, I think it would be good to have the possibility to set the
> > > inquiry mode (standard, with RSSI, RSSI + extended inq. result).
> > > Currently the mode is always set inquiry with rssi when PeriodicInquiry
> > > is called (I'm thinking of sending a patch to remove it), but it should
> > > probably be set once at device initialization and then changed only by
> > > the SetProperty method call.
> >
> > Totally agree.
> >
> > Regards
> >
> > Marcel
> >
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by:
> > Tame your development challenges with Apache's Geronimo App Server. Download
> > it for free - -and be entered to win a 42" plasma tv or your very own
> > Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> > _______________________________________________
> > Bluez-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/bluez-devel
> >
>
>
>
--
Eduardo Rocha
Instituto Nokia de Tecnologia - INdT
Hi all,
here is a patch with SetProperty and GetProperty for Name. I've also
updated the dbus-test.
Marcel, in the hciconfig you set the ext inquire parameter in the
cmd_name function. Is this needed here?
The "local name changed" signal is still missing. I'll do that for
the next patch.
BR,
Eduardo.
--
Eduardo Rocha
Instituto Nokia de Tecnologia - INdT
On 11/8/05, Marcel Holtmann <[email protected]> wrote:
> Hi Johan,
>
> > > name [name] Get/Set local name
> >
> > This is good to have. A "local name changed" signal might also be useful
> > so that other applications can update their UI. Actually now that I
> > think about it, maybe thare should be a generic "property changed"
> > signal for all properties.
>
> sounds like a good idea and easy to extend in the future.
>
> > > auth Enable/Disable Authentication
> > > encrypt Enable/Disable Encryption
> > > secmgr Enable/Disable Security Manager
> > > piscan Enable/Disable Page and Inquiry scan
> > > iscan Enable/Disable Inquiry scan
> > > pscan Enable/Disable Page scan
> >
> > I think the piscan can be dropped so that we have two boolean
> > properties: iscan and pscan.
> >
> > Also, I think it would be good to have the possibility to set the
> > inquiry mode (standard, with RSSI, RSSI + extended inq. result).
> > Currently the mode is always set inquiry with rssi when PeriodicInquiry
> > is called (I'm thinking of sending a patch to remove it), but it should
> > probably be set once at device initialization and then changed only by
> > the SetProperty method call.
>
> Totally agree.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
Hi Johan,
> > name [name] Get/Set local name
>
> This is good to have. A "local name changed" signal might also be useful
> so that other applications can update their UI. Actually now that I
> think about it, maybe thare should be a generic "property changed"
> signal for all properties.
sounds like a good idea and easy to extend in the future.
> > auth Enable/Disable Authentication
> > encrypt Enable/Disable Encryption
> > secmgr Enable/Disable Security Manager
> > piscan Enable/Disable Page and Inquiry scan
> > iscan Enable/Disable Inquiry scan
> > pscan Enable/Disable Page scan
>
> I think the piscan can be dropped so that we have two boolean
> properties: iscan and pscan.
>
> Also, I think it would be good to have the possibility to set the
> inquiry mode (standard, with RSSI, RSSI + extended inq. result).
> Currently the mode is always set inquiry with rssi when PeriodicInquiry
> is called (I'm thinking of sending a patch to remove it), but it should
> probably be set once at device initialization and then changed only by
> the SetProperty method call.
Totally agree.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Tue, Nov 08, 2005, Claudio Takahasi wrote:
> In my opinion we can start playing with the feature below:
>
> up Open and initialize HCI device
> down Close HCI device
These we already have (through the Up and Down methods).
> name [name] Get/Set local name
This is good to have. A "local name changed" signal might also be useful
so that other applications can update their UI. Actually now that I
think about it, maybe thare should be a generic "property changed"
signal for all properties.
> auth Enable/Disable Authentication
> encrypt Enable/Disable Encryption
> secmgr Enable/Disable Security Manager
> piscan Enable/Disable Page and Inquiry scan
> iscan Enable/Disable Inquiry scan
> pscan Enable/Disable Page scan
I think the piscan can be dropped so that we have two boolean
properties: iscan and pscan.
Also, I think it would be good to have the possibility to set the
inquiry mode (standard, with RSSI, RSSI + extended inq. result).
Currently the mode is always set inquiry with rssi when PeriodicInquiry
is called (I'm thinking of sending a patch to remove it), but it should
probably be set once at device initialization and then changed only by
the SetProperty method call.
Johan
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Claudio,
> In my opinion we can start playing with the feature below:
>
> up Open and initialize HCI device
> down Close HCI device
leave this for some other time. It is not that easy to do the up and
down properly.
> name [name] Get/Set local name
And include the inquiry mode. We need to configure the name and the
inquiry mode. I also wanna remove the inquiry mode setting inside the
periodic inquiry call.
> auth Enable/Disable Authentication
> encrypt Enable/Disable Encryption
> secmgr Enable/Disable Security Manager
This is a no. We don't need to configure it. I am not going to support
security mode 3 over the D-Bus interface. People are already doing
enough mistakes right now with it.
> piscan Enable/Disable Page and Inquiry scan
> iscan Enable/Disable Inquiry scan
> pscan Enable/Disable Page scan
This is all the same setting and the correct names for it are
"connectable" and "discoverable". There is no need to expose the
Bluetooth crappy names over the D-Bus interface.
> Maybe we could analise the possibility of make the configuration
> permanent updating these values in the 'hcid.conf' configuration file.
Maybe or maybe not. Convince me that you can do it in sane way.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi,
In my opinion we can start playing with the feature below:
up Open and initialize HCI device
down Close HCI device
name [name] Get/Set local name
auth Enable/Disable Authentication
encrypt Enable/Disable Encryption
secmgr Enable/Disable Security Manager
piscan Enable/Disable Page and Inquiry scan
iscan Enable/Disable Inquiry scan
pscan Enable/Disable Page scan
Maybe we could analise the possibility of make the configuration
permanent updating these values in the 'hcid.conf' configuration file.
Regards,
Claudio.
On 11/4/05, Marcel Holtmann <[email protected]> wrote:
> Hi Eduardo,
>
> > here is the patch with the initial development of setproperty and
> > getproperty for /org/bluez/Device/hciX. As this is only the fundation,
>
> I applied the patch to the CVS, but I don't wanna have a simply
> hciconfig replacement. We need to think about the functions that we
> wanna support over D-Bus.
>
> > I didn't update the python script.
>
> Please do so.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. Downl=
oad
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
--
---------------------------------------------------------
Claudio Takahasi
Instituto Nokia de Tecnologia - INdT
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Eduardo,
> here is the patch with the initial development of setproperty and
> getproperty for /org/bluez/Device/hciX. As this is only the fundation,
I applied the patch to the CVS, but I don't wanna have a simply
hciconfig replacement. We need to think about the functions that we
wanna support over D-Bus.
> I didn't update the python script.
Please do so.
Regards
Marcel
-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Eduardo,
> here is the patch for set auth enable. This patch should be applied
> after the last scan patch. Let me know if there is any problem.
we don't need to set auth or encrypt at all, because the support for
setting a device into Security Mode 3 from within the D-Bus interface is
useless.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
here is the patch for set auth enable. This patch should be applied
after the last scan patch. Let me know if there is any problem.
BR,
Eduardo
On 12/14/05, Eduardo Rocha <[email protected]> wrote:
> Hi Marcel,
>
> here is the new patch.
>
> BR,
> Eduardo.
>
>
> On 12/13/05, Marcel Holtmann <[email protected]> wrote:
> > Hi Eduardo,
> >
> > > here is the patch with the send_property_changed_signal function included.
> >
> > nice, but please follow the coding style. I don't wanna correct the
> > whitespaces in all patches. Some examples what should be changed:
> >
> > (void*)&pdata ==> (void *) &pdata
> > = SCAN_PAGE|SCAN_INQUIRY; ==> = SCAN_PAGE | SCAN_INQUIRY;
> > se = (rp.enable & SCAN_PAGE)?1:0; se = (rp.enable & SCAN_PAGE) ? 1 : 0;
> >
> > This is also bad coding style:
> >
> > if (dd < 0) {
> > syslog(LOG_ERR, "HCI device open failed: hci%d", id);
> > goto failed;
> > } else {
> >
> > We don't need the else branch. I results in an needless indentation.
> >
> > I also think that we need some more newlines in your code, but I am
> > going to fix it when applying the patch.
> >
> > This part might work, but I don't like it:
> >
> > if (ispscan) {
> > if (scan && !(rp.enable & SCAN_PAGE))
> > enable = (rp.enable & SCAN_INQUIRY) | SCAN_PAGE;
> > else if (!scan && (rp.enable & SCAN_PAGE))
> > enable = (rp.enable & SCAN_INQUIRY);
> > else {
> > reply = dbus_message_new_method_return(msg);
> > goto failed;
> > }
> > } else {
> > if (scan && !(rp.enable & SCAN_INQUIRY))
> > enable = (rp.enable & SCAN_PAGE) | SCAN_INQUIRY;
> > else if (!scan && (rp.enable & SCAN_INQUIRY))
> > enable = (rp.enable & SCAN_PAGE);
> > else {
> > reply = dbus_message_new_method_return(msg);
> > goto failed;
> > }
> > }
> >
> > And this includes this:
> >
> > if((rp.enable & SCAN_PAGE) != (old_data & SCAN_PAGE)) {
> > se = (rp.enable & SCAN_PAGE)?1:0;
> > send_property_changed_signal(id, DEV_PROPERTY_PSCAN, DBUS_TYPE_BOOLEAN, &se);
> > }
> > if ((rp.enable & SCAN_INQUIRY) != (old_data & SCAN_INQUIRY)) {
> > se = (rp.enable & SCAN_INQUIRY)?1:0;
> > send_property_changed_signal(id, DEV_PROPERTY_ISCAN, DBUS_TYPE_BOOLEAN, &se);
> > }
> > dbus_connection_flush(connection);
> >
> > I don't have any better idea to solve this at the moment, but if you
> > read this code it takes too much time too understand what it is actually
> > doing. And normally this is not a good idea. However we might fix it
> > later and get the patch in now for further testing. So please correct
> > the other parts and resend it.
> >
> > Regards
> >
> > Marcel
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> > for problems? Stop! Download the new AJAX search engine that makes
> > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> > _______________________________________________
> > Bluez-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/bluez-devel
> >
>
>
> --
> Eduardo Rocha
> Instituto Nokia de Tecnologia - INdT
>
>
>
--
Eduardo Rocha
Instituto Nokia de Tecnologia - INdT
Hi Marcel,
here is the new patch.
BR,
Eduardo.
On 12/13/05, Marcel Holtmann <[email protected]> wrote:
> Hi Eduardo,
>
> > here is the patch with the send_property_changed_signal function included.
>
> nice, but please follow the coding style. I don't wanna correct the
> whitespaces in all patches. Some examples what should be changed:
>
> (void*)&pdata ==> (void *) &pdata
> = SCAN_PAGE|SCAN_INQUIRY; ==> = SCAN_PAGE | SCAN_INQUIRY;
> se = (rp.enable & SCAN_PAGE)?1:0; se = (rp.enable & SCAN_PAGE) ? 1 : 0;
>
> This is also bad coding style:
>
> if (dd < 0) {
> syslog(LOG_ERR, "HCI device open failed: hci%d", id);
> goto failed;
> } else {
>
> We don't need the else branch. I results in an needless indentation.
>
> I also think that we need some more newlines in your code, but I am
> going to fix it when applying the patch.
>
> This part might work, but I don't like it:
>
> if (ispscan) {
> if (scan && !(rp.enable & SCAN_PAGE))
> enable = (rp.enable & SCAN_INQUIRY) | SCAN_PAGE;
> else if (!scan && (rp.enable & SCAN_PAGE))
> enable = (rp.enable & SCAN_INQUIRY);
> else {
> reply = dbus_message_new_method_return(msg);
> goto failed;
> }
> } else {
> if (scan && !(rp.enable & SCAN_INQUIRY))
> enable = (rp.enable & SCAN_PAGE) | SCAN_INQUIRY;
> else if (!scan && (rp.enable & SCAN_INQUIRY))
> enable = (rp.enable & SCAN_PAGE);
> else {
> reply = dbus_message_new_method_return(msg);
> goto failed;
> }
> }
>
> And this includes this:
>
> if((rp.enable & SCAN_PAGE) != (old_data & SCAN_PAGE)) {
> se = (rp.enable & SCAN_PAGE)?1:0;
> send_property_changed_signal(id, DEV_PROPERTY_PSCAN, DBUS_TYPE_BOOLEAN, &se);
> }
> if ((rp.enable & SCAN_INQUIRY) != (old_data & SCAN_INQUIRY)) {
> se = (rp.enable & SCAN_INQUIRY)?1:0;
> send_property_changed_signal(id, DEV_PROPERTY_ISCAN, DBUS_TYPE_BOOLEAN, &se);
> }
> dbus_connection_flush(connection);
>
> I don't have any better idea to solve this at the moment, but if you
> read this code it takes too much time too understand what it is actually
> doing. And normally this is not a good idea. However we might fix it
> later and get the patch in now for further testing. So please correct
> the other parts and resend it.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
--
Eduardo Rocha
Instituto Nokia de Tecnologia - INdT
Hi Eduardo,
> here is the patch with the send_property_changed_signal function included.
nice, but please follow the coding style. I don't wanna correct the
whitespaces in all patches. Some examples what should be changed:
(void*)&pdata ==> (void *) &pdata
= SCAN_PAGE|SCAN_INQUIRY; ==> = SCAN_PAGE | SCAN_INQUIRY;
se = (rp.enable & SCAN_PAGE)?1:0; se = (rp.enable & SCAN_PAGE) ? 1 : 0;
This is also bad coding style:
if (dd < 0) {
syslog(LOG_ERR, "HCI device open failed: hci%d", id);
goto failed;
} else {
We don't need the else branch. I results in an needless indentation.
I also think that we need some more newlines in your code, but I am
going to fix it when applying the patch.
This part might work, but I don't like it:
if (ispscan) {
if (scan && !(rp.enable & SCAN_PAGE))
enable = (rp.enable & SCAN_INQUIRY) | SCAN_PAGE;
else if (!scan && (rp.enable & SCAN_PAGE))
enable = (rp.enable & SCAN_INQUIRY);
else {
reply = dbus_message_new_method_return(msg);
goto failed;
}
} else {
if (scan && !(rp.enable & SCAN_INQUIRY))
enable = (rp.enable & SCAN_PAGE) | SCAN_INQUIRY;
else if (!scan && (rp.enable & SCAN_INQUIRY))
enable = (rp.enable & SCAN_PAGE);
else {
reply = dbus_message_new_method_return(msg);
goto failed;
}
}
And this includes this:
if((rp.enable & SCAN_PAGE) != (old_data & SCAN_PAGE)) {
se = (rp.enable & SCAN_PAGE)?1:0;
send_property_changed_signal(id, DEV_PROPERTY_PSCAN, DBUS_TYPE_BOOLEAN, &se);
}
if ((rp.enable & SCAN_INQUIRY) != (old_data & SCAN_INQUIRY)) {
se = (rp.enable & SCAN_INQUIRY)?1:0;
send_property_changed_signal(id, DEV_PROPERTY_ISCAN, DBUS_TYPE_BOOLEAN, &se);
}
dbus_connection_flush(connection);
I don't have any better idea to solve this at the moment, but if you
read this code it takes too much time too understand what it is actually
doing. And normally this is not a good idea. However we might fix it
later and get the patch in now for further testing. So please correct
the other parts and resend it.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
here is the patch with the send_property_changed_signal function included.
BR,
Eduardo.
> On 12/7/05, Marcel Holtmann <[email protected]> wrote:
> > Hi Johan,
> >
> > > Your patch looks ok, except that you seem to append the arguments in
> > > the wrong order to the "name" property changed signal:
> > >
> > > On Wed, Dec 07, 2005, Eduardo Rocha wrote:
> > > > dbus_message_append_args(message,
> > > > DBUS_TYPE_STRING, &pname,
> > > > + DBUS_TYPE_STRING, &pprop_name,
> >
> > and some coding style issues :(
> >
> > > Btw, maybe we should have a common function for sending property changed
> > > signals, e.g:
> > > send_property_changed(const char *prop_name, int prop_type, void *value);
> >
> > Sounds like a good idea to me. Please integrate this and if needed split
> > the patch into two separate patches.
> >
> > Regards
> >
> > Marcel
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> > for problems? Stop! Download the new AJAX search engine that makes
> > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> > _______________________________________________
> > Bluez-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/bluez-devel
> >
>
>
> --
> Eduardo Rocha
> Instituto Nokia de Tecnologia - INdT
>
--
Eduardo Rocha
Instituto Nokia de Tecnologia - INdT
Hi Johan and Marcel,
I'll do that. Maybe should be a good idea to think how to split dbus.c
into 2 or 3 files.
Also, we should improve the debug messages.
BR,
Eduardo.
On 12/7/05, Marcel Holtmann <[email protected]> wrote:
> Hi Johan,
>
> > Your patch looks ok, except that you seem to append the arguments in
> > the wrong order to the "name" property changed signal:
> >
> > On Wed, Dec 07, 2005, Eduardo Rocha wrote:
> > > dbus_message_append_args(message,
> > > DBUS_TYPE_STRING, &pname,
> > > + DBUS_TYPE_STRING, &pprop_name,
>
> and some coding style issues :(
>
> > Btw, maybe we should have a common function for sending property change=
d
> > signals, e.g:
> > send_property_changed(const char *prop_name, int prop_type, void *value=
);
>
> Sounds like a good idea to me. Please integrate this and if needed split
> the patch into two separate patches.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
--
Eduardo Rocha
Instituto Nokia de Tecnologia - INdT
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Johan,
> Your patch looks ok, except that you seem to append the arguments in
> the wrong order to the "name" property changed signal:
>
> On Wed, Dec 07, 2005, Eduardo Rocha wrote:
> > dbus_message_append_args(message,
> > DBUS_TYPE_STRING, &pname,
> > + DBUS_TYPE_STRING, &pprop_name,
and some coding style issues :(
> Btw, maybe we should have a common function for sending property changed
> signals, e.g:
> send_property_changed(const char *prop_name, int prop_type, void *value);
Sounds like a good idea to me. Please integrate this and if needed split
the patch into two separate patches.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Eduardo,
Your patch looks ok, except that you seem to append the arguments in
the wrong order to the "name" property changed signal:
On Wed, Dec 07, 2005, Eduardo Rocha wrote:
> dbus_message_append_args(message,
> DBUS_TYPE_STRING, &pname,
> + DBUS_TYPE_STRING, &pprop_name,
Btw, maybe we should have a common function for sending property changed
signals, e.g:
send_property_changed(const char *prop_name, int prop_type, void *value);
Johan
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
here is the patch with the scan property change. Maybe we should
consider improving the syslog error messages to include some more info
to give some clue of where it happened.
BR,
Eduardo.
On 12/1/05, Marcel Holtmann <[email protected]> wrote:
> Hi Eduardo,
>
> > Johan said on an early email that would be nice to have each changed
> > property to send a "PropertyChanged" signal with "Property name" and
> > "property specific info" params. But for "discoverable" and
> > "connectable" properties, how can we know what changed as both of them
> > trigger a command_complete event with HCI_write_scan_enable OCF? Or
> > should we trigger a unique signal for pscan and iscan, sending the new
> > scan status?
>
> you need to track the HCI write scan enable command. You issue it with
> specific values and you need to keep this transition state until you
> receive the HCI command complete event. This is how the kernel is doing
> it for some of the commands.
>
> And I like the idea of a PropertyChanged signal.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
--
Eduardo Rocha
Instituto Nokia de Tecnologia - INdT
Hi Eduardo,
> Johan said on an early email that would be nice to have each changed
> property to send a "PropertyChanged" signal with "Property name" and
> "property specific info" params. But for "discoverable" and
> "connectable" properties, how can we know what changed as both of them
> trigger a command_complete event with HCI_write_scan_enable OCF? Or
> should we trigger a unique signal for pscan and iscan, sending the new
> scan status?
you need to track the HCI write scan enable command. You issue it with
specific values and you need to keep this transition state until you
receive the HCI command complete event. This is how the kernel is doing
it for some of the commands.
And I like the idea of a PropertyChanged signal.
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
here is a patch for scan SetProperty of /org/bluez/Device/hciX and to
correct some function names.
Johan said on an early email that would be nice to have each changed
property to send a "PropertyChanged" signal with "Property name" and
"property specific info" params. But for "discoverable" and
"connectable" properties, how can we know what changed as both of them
trigger a command_complete event with HCI_write_scan_enable OCF? Or
should we trigger a unique signal for pscan and iscan, sending the new
scan status?
BR,
Eduardo.
On 11/25/05, Marcel Holtmann <[email protected]> wrote:
> Hi Claudio,
>
> > I think we are confusing some D-Bus concepts.
> >
> > Currently, hcid is connected to the "system" bus, because the
> > Bluetooth adapter is a shared resource and it can be used by any
> > logged-in user or remote users. As long as I known the "system bus"
> > should be used for notification from the system to user sessions(it's
> > accessible to all applications on the system). The "session bus"
> > should be used to implement desktop environments communication. The
> > address of the per-session bus daemon is automatically discovered by
> > reading an environment variable. A login session message bus is
> > started each time a user logs in.
>
> this is my understanding, too.
>
> > If we choose use the session bus, probably it will required huge code
> > modification in order to support multiple bus session connection or
> > start a new BlueZ D-Bus daemon for each user session. In my opinion,
> > this approach is not feasible.
>
> This will simply not work, because there can be only one daemon at a
> time and it must run all the time.
>
> > If you want provide BlueZ D-Bus services only for the logged-in user,
> > we can try analise the modifications required to control the D-Bus
> > connections and its drawbacks.
>
> The D-Bus services are available in general, but I wanna restrict the
> methods that are actually modifying settings to the root user and/or the
> currently logged in user. The hal.conf uses "<policy at_console="true">"
> to provide this (if I am not mistaken).
>
> Remember that we are talking about the default configuration. We don't
> need to provide the best security model, but at least a decent one. For
> me this means that the root user and the currently logged in user have
> full control over the device. All other users are restricted.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
--
Eduardo Rocha
Instituto Nokia de Tecnologia - INdT