[Bluez-devel] [DBUS] remote name patch

[Bluez-devel] [DBUS] remote name patch

[Claudio Takahasi]

[-- Attachment #1: Type: text/plain, Size: 840 bytes --]

Hi Marcel,

The attached patch improves the remote name request. It's the same
approach of "hcitool name", I am using the textfile library. Maybe we
should move the function "get_device_name" to a common place, like
"libtextfile.a" or create a new utility library(ie: "libbluezutil.a").

Another point is an option to "force" send HCI remote name instead of
use the stored value. If you want I can add an extra argument(boolean)
to indicate the type(use cache/no cache), but keeping the backward
compatibility, where the default request signature is use the cache.

1. RemoteName("AA:BB:CC:DD:EE:FF")  == RemoteName("AA:BB:CC:DD:EE:FF", TRUE)
2. RemoteName("AA:BB:CC:DD:EE:FF", FALSE)

Regards,
Claudio.
--
---------------------------------------------------------
Claudio Takahasi
Instituto Nokia de Tecnologia - INdT

[-- Attachment #2: remote_name_cache01.patch --]
[-- Type: text/x-patch, Size: 4063 bytes --]

--- bluez-utils-cvs.orig/hcid/dbus.c	2006-01-03 11:28:58.000000000 -0200
+++ bluez-utils-cvs/hcid/dbus.c	2006-01-20 12:54:29.000000000 -0200
@@ -45,6 +45,7 @@
 
 #include "hcid.h"
 #include "dbus.h"
+#include "textfile.h"
 
 #ifndef DBUS_NAME_FLAG_PROHIBIT_REPLACEMENT
 #define DBUS_NAME_FLAG_PROHIBIT_REPLACEMENT	0x00
@@ -98,6 +99,19 @@
 	unregister_function_t	*unreg_func;
 	get_svc_table_func_t	*get_svc_table;	/* return the service table */
 };
+/*
+ * Utility functions
+ */
+static char *get_device_name(const bdaddr_t *local, const bdaddr_t *peer)
+{
+	char filename[PATH_MAX + 1], addr[18];
+
+	ba2str(local, addr);
+	snprintf(filename, PATH_MAX, "%s/%s/names", STORAGEDIR, addr);
+
+	ba2str(peer, addr);
+	return textfile_get(filename, addr);
+}
 
 /*
  * D-Bus error messages functions and declarations.
@@ -1709,13 +1723,17 @@
 static DBusMessage* handle_remote_name_req(DBusMessage *msg, void *data)
 {
 	DBusMessage *reply = NULL;
+	DBusMessage *signal = NULL;
 	struct hci_dbus_data *dbus_data = data;
-	int dd = -1;
 	const char *str_bdaddr;
+	char *name;
+	char path[MAX_PATH_LENGTH];
 	bdaddr_t bdaddr;
+	struct hci_dev_info di;
 	struct hci_request rq;
 	remote_name_req_cp cp;
 	evt_cmd_status rp;
+	int dd = -1;
 
 	dbus_message_get_args(msg, NULL,
 					DBUS_TYPE_STRING, &str_bdaddr,
@@ -1723,36 +1741,72 @@
 
 	str2ba(str_bdaddr, &bdaddr);
 
-	dd = hci_open_dev(dbus_data->dev_id);
-	if (dd < 0) {
-		syslog(LOG_ERR, "Unable to open device %d: %s (%d)",
-					dbus_data->dev_id, strerror(errno), errno);
-		reply = bluez_new_failure_msg(msg, BLUEZ_ESYSTEM_OFFSET + errno);
+	if (hci_devinfo(dbus_data->dev_id, &di) < 0) {
+		syslog(LOG_ERR, "Can't get device info");
+		reply = bluez_new_failure_msg(msg, BLUEZ_ESYSTEM_ENODEV);
 		goto failed;
 	}
 
-	memset(&cp, 0, sizeof(cp));
-	cp.bdaddr = bdaddr;
-	cp.pscan_rep_mode = 0x01;
+	/* Try retrieve from local cache */
+	name = get_device_name(&di.bdaddr, &bdaddr);
+	if (name) {
+		reply = dbus_message_new_method_return(msg);
 
-	memset(&rq, 0, sizeof(rq));
-	rq.ogf    = OGF_LINK_CTL;
-	rq.ocf    = OCF_REMOTE_NAME_REQ;
-	rq.cparam = &cp;
-	rq.clen   = REMOTE_NAME_REQ_CP_SIZE;
-	rq.rparam = &rp;
-	rq.rlen   = EVT_CMD_STATUS_SIZE;
-	rq.event  = EVT_CMD_STATUS;
+		snprintf(path, sizeof(path), "%s/hci%d/%s", DEVICE_PATH, dbus_data->dev_id, BLUEZ_HCI);
 
-	if (hci_send_req(dd, &rq, 100) < 0) {
-		syslog(LOG_ERR, "Unable to send remote name request: %s (%d)",
-							strerror(errno), errno);
-		reply = bluez_new_failure_msg(msg, BLUEZ_ESYSTEM_OFFSET + errno);
-		goto failed;
+		signal = dbus_message_new_signal(path, DEV_HCI_INTERFACE,
+						 BLUEZ_HCI_REMOTE_NAME);
+
+		dbus_message_append_args(signal,
+					 DBUS_TYPE_STRING, &str_bdaddr,
+					 DBUS_TYPE_STRING, &name,
+					 DBUS_TYPE_INVALID);
+
+		if (dbus_connection_send(connection, signal, NULL) == FALSE) {
+			syslog(LOG_ERR, "Can't send D-BUS remote name signal message");
+			goto failed;
+		}
+
+		dbus_message_unref(signal);
+
+		reply = dbus_message_new_method_return(msg);
+		free(name);
+
+	} else {
+
+		/* Send HCI command */
+		dd = hci_open_dev(dbus_data->dev_id);
+		if (dd < 0) {
+			syslog(LOG_ERR, "Unable to open device %d: %s (%d)",
+						dbus_data->dev_id, strerror(errno), errno);
+			reply = bluez_new_failure_msg(msg, BLUEZ_ESYSTEM_OFFSET + errno);
+			goto failed;
+		}
+
+		memset(&cp, 0, sizeof(cp));
+		cp.bdaddr = bdaddr;
+		cp.pscan_rep_mode = 0x01;
+
+		memset(&rq, 0, sizeof(rq));
+		rq.ogf    = OGF_LINK_CTL;
+		rq.ocf    = OCF_REMOTE_NAME_REQ;
+		rq.cparam = &cp;
+		rq.clen   = REMOTE_NAME_REQ_CP_SIZE;
+		rq.rparam = &rp;
+		rq.rlen   = EVT_CMD_STATUS_SIZE;
+		rq.event  = EVT_CMD_STATUS;
+
+		if (hci_send_req(dd, &rq, 100) < 0) {
+			syslog(LOG_ERR, "Unable to send remote name request: %s (%d)",
+						strerror(errno), errno);
+			reply = bluez_new_failure_msg(msg, BLUEZ_ESYSTEM_OFFSET + errno);
+			goto failed;
+		}
+
+		reply = dbus_message_new_method_return(msg);
 	}
 
 	reply = dbus_message_new_method_return(msg);
-
 failed:
 	if (dd >= 0)
 		hci_close_dev(dd);

Re: [Bluez-devel] [DBUS] remote name patch

[Marcel Holtmann]

Hi Claudio,

> The attached patch improves the remote name request. It's the same
> approach of "hcitool name", I am using the textfile library. Maybe we
> should move the function "get_device_name" to a common place, like
> "libtextfile.a" or create a new utility library(ie: "libbluezutil.a").

before I pick up this patch, we might wanna discuss the three different
kinds of device names we will have in the future. The full remote name
of a device, the local cached name and then the name (shorted or full)
from the extended inquiry. How do we deal with them? Do we wanna give
the user of the D-Bus API any chance to distinguish between them?

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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] [DBUS] remote name patch

[Claudio Takahasi]

Hi Marcel,


I has just read some parts of "Specification Change Request". What is
the current status of the BlueZ Kernel? I figure out that there is a
function to parse the extended inquiry result event, however in the
code I have the 240 bytes are being ignored.

I prefer use just one signal instead of add a new signal to represent
the extended inquiry response. My suggestion is unify the standard and
the extended inquiry. If the user wants to know some response
properties, we can add an extra signal field to indicate the
type(Standard, with RSSI or EIR) and the remote name property(shorted,
full, cached).

Regarding the shorted/full name, in my opinion applications generally
will not want to distinguish the name type. The others UUIDs(service,
manufacturer, ...) included in the EIR packet can be ignore for now.
If required, we add extra fields in the inquiry cache to store these
UUIDs and add an D-Bus services to retrieve these data later.

Inquiry Result signal format proposal:

/* type flags */
#define STD_INQUIRY_RESPONSE   0x00010000
#define RSSI_INQUIRY_RESPONSE  0x00010000  /* RSSI included*/
#define EIR_INQUIRY_RESPONSE   0x01000000  /* */

/* name flags */
#define SHORTED_NAME           0x00000001
#define FULL_NAME              0x00000010
#define CACHED_NAME            0x00000100

Signal arguments:
UINT32: type (STD_INQUIRY_RESPONSE/RSSI_INQUIRY_RESPONSE/EIR_INQUIRY_RESPON=
SE
| FLAGS
String: BDADDR
String: name /* "n/a", cached value, shorted or full name */
UINT32: Device class
INT32: RSSI

"n/a" in the name field will be applied to standard inquiry, where the
remote name should be retrieved later or for EIR, when the local name
length is zero.

What do you think?  Do you have another suggestion or comments?

Regards,
Claudio.

On 1/20/06, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Claudio,
>
> > The attached patch improves the remote name request. It's the same
> > approach of "hcitool name", I am using the textfile library. Maybe we
> > should move the function "get_device_name" to a common place, like
> > "libtextfile.a" or create a new utility library(ie: "libbluezutil.a").
>
> before I pick up this patch, we might wanna discuss the three different
> kinds of device names we will have in the future. The full remote name
> of a device, the local cached name and then the name (shorted or full)
> from the extended inquiry. How do we deal with them? Do we wanna give
> the user of the D-Bus API any chance to distinguish between them?
>
> 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://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> 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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] [DBUS] remote name patch

[Marcel Holtmann]

Hi Claudio,

> I has just read some parts of "Specification Change Request". What is
> the current status of the BlueZ Kernel? I figure out that there is a
> function to parse the extended inquiry result event, however in the
> code I have the 240 bytes are being ignored.

the code inside the kernel only keeps the inquiry cache up-to-date,
because you need this for the connection establishment.

> I prefer use just one signal instead of add a new signal to represent
> the extended inquiry response. My suggestion is unify the standard and
> the extended inquiry. If the user wants to know some response
> properties, we can add an extra signal field to indicate the
> type(Standard, with RSSI or EIR) and the remote name property(shorted,
> full, cached).
> 
> Regarding the shorted/full name, in my opinion applications generally
> will not want to distinguish the name type. The others UUIDs(service,
> manufacturer, ...) included in the EIR packet can be ignore for now.
> If required, we add extra fields in the inquiry cache to store these
> UUIDs and add an D-Bus services to retrieve these data later.
> 
> Inquiry Result signal format proposal:
> 
> /* type flags */
> #define STD_INQUIRY_RESPONSE   0x00010000
> #define RSSI_INQUIRY_RESPONSE  0x00010000  /* RSSI included*/
> #define EIR_INQUIRY_RESPONSE   0x01000000  /* */
> 
> /* name flags */
> #define SHORTED_NAME           0x00000001
> #define FULL_NAME              0x00000010
> #define CACHED_NAME            0x00000100
> 
> Signal arguments:
> UINT32: type (STD_INQUIRY_RESPONSE/RSSI_INQUIRY_RESPONSE/EIR_INQUIRY_RESPONSE
> | FLAGS
> String: BDADDR
> String: name /* "n/a", cached value, shorted or full name */
> UINT32: Device class
> INT32: RSSI
> 
> "n/a" in the name field will be applied to standard inquiry, where the
> remote name should be retrieved later or for EIR, when the local name
> length is zero.
> 
> What do you think?  Do you have another suggestion or comments?

Don't try to distinguish the different inquiry modes on the D-Bus
interface. All of them are only an implementation detail.

Regarding the name, we might simply say the hcid/bluetoothd always sends
a remote name signal if something changes. So it might get the short
name from the extended inquiry first and after that it receives the full
remote name. We can also always send the cached name and we update that
name on every service discovery, because then it is at zero cost.

So we have one device name. This maybe a cached, a remote or a shortened
name. The application doesn't really have to care and it gets updates as
soon as hcid/bluetoothd knows them.

Besides the device name, we should implement an alias name. This name is
associated with the BD_ADDR and can be changed by the user if he/she
doesn't like the device name. Implementing this alias through the D-Bus
interface makes it available for all applications and we can store the
aliases in /var/lib/bluetooth/<bdaddr>/aliases.

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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] [DBUS] remote name patch

[Claudio Takahasi]

Hi Marcel,

On 1/23/06, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Claudio,
>
> > I has just read some parts of "Specification Change Request". What is
> > the current status of the BlueZ Kernel? I figure out that there is a
> > function to parse the extended inquiry result event, however in the
> > code I have the 240 bytes are being ignored.
>
> the code inside the kernel only keeps the inquiry cache up-to-date,
> because you need this for the connection establishment.
>
> > I prefer use just one signal instead of add a new signal to represent
> > the extended inquiry response. My suggestion is unify the standard and
> > the extended inquiry. If the user wants to know some response
> > properties, we can add an extra signal field to indicate the
> > type(Standard, with RSSI or EIR) and the remote name property(shorted,
> > full, cached).
> >
> > Regarding the shorted/full name, in my opinion applications generally
> > will not want to distinguish the name type. The others UUIDs(service,
> > manufacturer, ...) included in the EIR packet can be ignore for now.
> > If required, we add extra fields in the inquiry cache to store these
> > UUIDs and add an D-Bus services to retrieve these data later.
> >
> > Inquiry Result signal format proposal:
> >
> > /* type flags */
> > #define STD_INQUIRY_RESPONSE   0x00010000
> > #define RSSI_INQUIRY_RESPONSE  0x00010000  /* RSSI included*/
> > #define EIR_INQUIRY_RESPONSE   0x01000000  /* */
> >
> > /* name flags */
> > #define SHORTED_NAME           0x00000001
> > #define FULL_NAME              0x00000010
> > #define CACHED_NAME            0x00000100
> >
> > Signal arguments:
> > UINT32: type (STD_INQUIRY_RESPONSE/RSSI_INQUIRY_RESPONSE/EIR_INQUIRY_RE=
SPONSE
> > | FLAGS
> > String: BDADDR
> > String: name /* "n/a", cached value, shorted or full name */
> > UINT32: Device class
> > INT32: RSSI
> >
> > "n/a" in the name field will be applied to standard inquiry, where the
> > remote name should be retrieved later or for EIR, when the local name
> > length is zero.
> >
> > What do you think?  Do you have another suggestion or comments?
>
> Don't try to distinguish the different inquiry modes on the D-Bus
> interface. All of them are only an implementation detail.
[Claudio Takahasi]
ok. let's keep the same "InquiryResult" signature.

>
> Regarding the name, we might simply say the hcid/bluetoothd always sends
> a remote name signal if something changes. So it might get the short
> name from the extended inquiry first and after that it receives the full
> remote name. We can also always send the cached name and we update that
> name on every service discovery, because then it is at zero cost.
[Claudio Takahasi]
The remote name is triggered by D-Bus clients. hcid/bluetoothd doesn't
request the remote when the inquiry finishes. For EIR, are you
suggesting send the "InquiryResult" signal followed by a "RemoteName"?

If we send the "RemoteName" with the short name, probably D-Bus
clients will not request the RemoteName to retrieve the complete name.
D-Bus clients should not distinguish short/complete name.

Regarding the RemoteName request service signature. Do you agree with
my initial proprosal? (see the first e-mail sent: have an alternative
to force send the HCI remote name and another using the cache)

>
> So we have one device name. This maybe a cached, a remote or a shortened
> name. The application doesn't really have to care and it gets updates as
> soon as hcid/bluetoothd knows them.
>
> Besides the device name, we should implement an alias name. This name is
> associated with the BD_ADDR and can be changed by the user if he/she
> doesn't like the device name. Implementing this alias through the D-Bus
> interface makes it available for all applications and we can store the
> aliases in /var/lib/bluetooth/<bdaddr>/aliases.
[Claudio Takahasi]
When a client requests a RemoteName, which value should be returned?
The value stored in the aliases file or the value stored in the names
file? Or are you suggesting create a property=20
"GetProperty("alias")/SetProperty("alias", "value")?

Regards,
Claudio.

>
> 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://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> 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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] [DBUS] remote name patch

[Marcel Holtmann]

Hi Claudio,

> > Regarding the name, we might simply say the hcid/bluetoothd always sends
> > a remote name signal if something changes. So it might get the short
> > name from the extended inquiry first and after that it receives the full
> > remote name. We can also always send the cached name and we update that
> > name on every service discovery, because then it is at zero cost.
> 
> The remote name is triggered by D-Bus clients. hcid/bluetoothd doesn't
> request the remote when the inquiry finishes. For EIR, are you
> suggesting send the "InquiryResult" signal followed by a "RemoteName"?

this sounds like a sane and backward compatible way of doing this.

> If we send the "RemoteName" with the short name, probably D-Bus
> clients will not request the RemoteName to retrieve the complete name.
> D-Bus clients should not distinguish short/complete name.

It is up to hcid/bluetoothd to update the remote when the client
requests a service discovery.

> Regarding the RemoteName request service signature. Do you agree with
> my initial proprosal? (see the first e-mail sent: have an alternative
> to force send the HCI remote name and another using the cache)

No. We don't need any extra stuff. The client asks for a name and we
give them a name. That's it and all the rest is implementation specific
to hcid/bluetoothd.

> > So we have one device name. This maybe a cached, a remote or a shortened
> > name. The application doesn't really have to care and it gets updates as
> > soon as hcid/bluetoothd knows them.
> >
> > Besides the device name, we should implement an alias name. This name is
> > associated with the BD_ADDR and can be changed by the user if he/she
> > doesn't like the device name. Implementing this alias through the D-Bus
> > interface makes it available for all applications and we can store the
> > aliases in /var/lib/bluetooth/<bdaddr>/aliases.
> 
> When a client requests a RemoteName, which value should be returned?
> The value stored in the aliases file or the value stored in the names
> file? Or are you suggesting create a property 
> "GetProperty("alias")/SetProperty("alias", "value")?

When they request the remote name or device name, then they get the
device name that is valid at the moment. This will maybe a cached name,
but that doesn't matter. If hcid/bluetoothd knows better they will send
out a remote name signal to tell them.

The alias name is totally different and independent. It is application
choice to use the alias name or not. If the alias name is empty they can
use the remote/device name.

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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] [DBUS] remote name patch

[Claudio Takahasi]

Hi Marcel,

On 1/23/06, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Claudio,
>
> > > Regarding the name, we might simply say the hcid/bluetoothd always se=
nds
> > > a remote name signal if something changes. So it might get the short
> > > name from the extended inquiry first and after that it receives the f=
ull
> > > remote name. We can also always send the cached name and we update th=
at
> > > name on every service discovery, because then it is at zero cost.
> >
> > The remote name is triggered by D-Bus clients. hcid/bluetoothd doesn't
> > request the remote when the inquiry finishes. For EIR, are you
> > suggesting send the "InquiryResult" signal followed by a "RemoteName"?
>
> this sounds like a sane and backward compatible way of doing this.
[Claudio Takahasi]
I did some tests and discovered that if we add extra fields at the
ending we can keep the
backward compatibility if applications check the signature partially.
The functions dbus_message_get_args and dbus_message_get_basic can be
used to extract the first three signal fields(bdaddr, class, rssi)
without broke. For python applications add an extra signal handler
function with the new signature is enough.

Therefore, we have another option: Add the name at the ending of the
"InquiryResult" signal arguments.

>
> > If we send the "RemoteName" with the short name, probably D-Bus
> > clients will not request the RemoteName to retrieve the complete name.
> > D-Bus clients should not distinguish short/complete name.
>
> It is up to hcid/bluetoothd to update the remote when the client
> requests a service discovery.
>
> > Regarding the RemoteName request service signature. Do you agree with
> > my initial proprosal? (see the first e-mail sent: have an alternative
> > to force send the HCI remote name and another using the cache)
>
> No. We don't need any extra stuff. The client asks for a name and we
> give them a name. That's it and all the rest is implementation specific
> to hcid/bluetoothd.
[Claudio Takahasi]
Sorry I didn't understand your proposal. Which logic do you want?
When the hcid/bluetoothd receives the RemoteName(bdaddr) request,
which steps should be done?

This is the patch approach:
name =3D get_device_name(local, bdaddr); /* retrieving from names file */
if (name =3D=3D NULL) {
   /* send HCI remote name request */
}
...
Which modifications must be done on this patch?

>
> > > So we have one device name. This maybe a cached, a remote or a shorte=
ned
> > > name. The application doesn't really have to care and it gets updates=
 as
> > > soon as hcid/bluetoothd knows them.
> > >
> > > Besides the device name, we should implement an alias name. This name=
 is
> > > associated with the BD_ADDR and can be changed by the user if he/she
> > > doesn't like the device name. Implementing this alias through the D-B=
us
> > > interface makes it available for all applications and we can store th=
e
> > > aliases in /var/lib/bluetooth/<bdaddr>/aliases.
> >
> > When a client requests a RemoteName, which value should be returned?
> > The value stored in the aliases file or the value stored in the names
> > file? Or are you suggesting create a property
> > "GetProperty("alias")/SetProperty("alias", "value")?
>
> When they request the remote name or device name, then they get the
> device name that is valid at the moment. This will maybe a cached name,
> but that doesn't matter. If hcid/bluetoothd knows better they will send
> out a remote name signal to tell them.
>
> The alias name is totally different and independent. It is application
> choice to use the alias name or not. If the alias name is empty they can
> use the remote/device name.
[Claudio Takahasi]
Is there someone working on this stuff?

Regards,
Claudio.

>
> 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://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D103432&bid=3D230486&dat=
=3D121642
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> 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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] [DBUS] remote name patch

[Marcel Holtmann]

Hi Claudio,

> > > > Regarding the name, we might simply say the hcid/bluetoothd always sends
> > > > a remote name signal if something changes. So it might get the short
> > > > name from the extended inquiry first and after that it receives the full
> > > > remote name. We can also always send the cached name and we update that
> > > > name on every service discovery, because then it is at zero cost.
> > >
> > > The remote name is triggered by D-Bus clients. hcid/bluetoothd doesn't
> > > request the remote when the inquiry finishes. For EIR, are you
> > > suggesting send the "InquiryResult" signal followed by a "RemoteName"?
> >
> > this sounds like a sane and backward compatible way of doing this.
> 
> I did some tests and discovered that if we add extra fields at the
> ending we can keep the
> backward compatibility if applications check the signature partially.
> The functions dbus_message_get_args and dbus_message_get_basic can be
> used to extract the first three signal fields(bdaddr, class, rssi)
> without broke. For python applications add an extra signal handler
> function with the new signature is enough.
> 
> Therefore, we have another option: Add the name at the ending of the
> "InquiryResult" signal arguments.

even if I wrote a backward compatibility, I actually don't care, because
I mentioned sometimes that I don't consider the D-Bus stable unless we
at least have D-Bus 1.0 finally released.

> > > If we send the "RemoteName" with the short name, probably D-Bus
> > > clients will not request the RemoteName to retrieve the complete name.
> > > D-Bus clients should not distinguish short/complete name.
> >
> > It is up to hcid/bluetoothd to update the remote when the client
> > requests a service discovery.
> >
> > > Regarding the RemoteName request service signature. Do you agree with
> > > my initial proprosal? (see the first e-mail sent: have an alternative
> > > to force send the HCI remote name and another using the cache)
> >
> > No. We don't need any extra stuff. The client asks for a name and we
> > give them a name. That's it and all the rest is implementation specific
> > to hcid/bluetoothd.
> 
> Sorry I didn't understand your proposal. Which logic do you want?
> When the hcid/bluetoothd receives the RemoteName(bdaddr) request,
> which steps should be done?
> 
> This is the patch approach:
> name = get_device_name(local, bdaddr); /* retrieving from names file */
> if (name == NULL) {
>    /* send HCI remote name request */
> }
> ...
> Which modifications must be done on this patch?

If the client ask for a name and we have a cached one, it gets the
cached name. If we don't have a cached name hcid/bluetoothd will take
care of filling the cache.

The same applies to the device discovery. If we don't get any EIR
information it is the job of hcid/bluetoothd to fill the name cache.

> > > > So we have one device name. This maybe a cached, a remote or a shortened
> > > > name. The application doesn't really have to care and it gets updates as
> > > > soon as hcid/bluetoothd knows them.
> > > >
> > > > Besides the device name, we should implement an alias name. This name is
> > > > associated with the BD_ADDR and can be changed by the user if he/she
> > > > doesn't like the device name. Implementing this alias through the D-Bus
> > > > interface makes it available for all applications and we can store the
> > > > aliases in /var/lib/bluetooth/<bdaddr>/aliases.
> > >
> > > When a client requests a RemoteName, which value should be returned?
> > > The value stored in the aliases file or the value stored in the names
> > > file? Or are you suggesting create a property
> > > "GetProperty("alias")/SetProperty("alias", "value")?
> >
> > When they request the remote name or device name, then they get the
> > device name that is valid at the moment. This will maybe a cached name,
> > but that doesn't matter. If hcid/bluetoothd knows better they will send
> > out a remote name signal to tell them.
> >
> > The alias name is totally different and independent. It is application
> > choice to use the alias name or not. If the alias name is empty they can
> > use the remote/device name.
> 
> Is there someone working on this stuff?

Not that I know of.

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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] [DBUS] remote name patch

[Claudio Takahasi]

[-- Attachment #1: Type: text/plain, Size: 5541 bytes --]

Hi Marcel,

According with your request, I am sending the patch again.
The function get_device_name should be moved to a common library.

Basically, this patch try retrieve the remote name from the
cache(names file) instead of send the HCI command everytime.

Regards,
Claudio.

On 1/26/06, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Claudio,
>
> > > > > Regarding the name, we might simply say the hcid/bluetoothd always sends
> > > > > a remote name signal if something changes. So it might get the short
> > > > > name from the extended inquiry first and after that it receives the full
> > > > > remote name. We can also always send the cached name and we update that
> > > > > name on every service discovery, because then it is at zero cost.
> > > >
> > > > The remote name is triggered by D-Bus clients. hcid/bluetoothd doesn't
> > > > request the remote when the inquiry finishes. For EIR, are you
> > > > suggesting send the "InquiryResult" signal followed by a "RemoteName"?
> > >
> > > this sounds like a sane and backward compatible way of doing this.
> >
> > I did some tests and discovered that if we add extra fields at the
> > ending we can keep the
> > backward compatibility if applications check the signature partially.
> > The functions dbus_message_get_args and dbus_message_get_basic can be
> > used to extract the first three signal fields(bdaddr, class, rssi)
> > without broke. For python applications add an extra signal handler
> > function with the new signature is enough.
> >
> > Therefore, we have another option: Add the name at the ending of the
> > "InquiryResult" signal arguments.
>
> even if I wrote a backward compatibility, I actually don't care, because
> I mentioned sometimes that I don't consider the D-Bus stable unless we
> at least have D-Bus 1.0 finally released.
>
> > > > If we send the "RemoteName" with the short name, probably D-Bus
> > > > clients will not request the RemoteName to retrieve the complete name.
> > > > D-Bus clients should not distinguish short/complete name.
> > >
> > > It is up to hcid/bluetoothd to update the remote when the client
> > > requests a service discovery.
> > >
> > > > Regarding the RemoteName request service signature. Do you agree with
> > > > my initial proprosal? (see the first e-mail sent: have an alternative
> > > > to force send the HCI remote name and another using the cache)
> > >
> > > No. We don't need any extra stuff. The client asks for a name and we
> > > give them a name. That's it and all the rest is implementation specific
> > > to hcid/bluetoothd.
> >
> > Sorry I didn't understand your proposal. Which logic do you want?
> > When the hcid/bluetoothd receives the RemoteName(bdaddr) request,
> > which steps should be done?
> >
> > This is the patch approach:
> > name = get_device_name(local, bdaddr); /* retrieving from names file */
> > if (name == NULL) {
> >    /* send HCI remote name request */
> > }
> > ...
> > Which modifications must be done on this patch?
>
> If the client ask for a name and we have a cached one, it gets the
> cached name. If we don't have a cached name hcid/bluetoothd will take
> care of filling the cache.
>
> The same applies to the device discovery. If we don't get any EIR
> information it is the job of hcid/bluetoothd to fill the name cache.
>
> > > > > So we have one device name. This maybe a cached, a remote or a shortened
> > > > > name. The application doesn't really have to care and it gets updates as
> > > > > soon as hcid/bluetoothd knows them.
> > > > >
> > > > > Besides the device name, we should implement an alias name. This name is
> > > > > associated with the BD_ADDR and can be changed by the user if he/she
> > > > > doesn't like the device name. Implementing this alias through the D-Bus
> > > > > interface makes it available for all applications and we can store the
> > > > > aliases in /var/lib/bluetooth/<bdaddr>/aliases.
> > > >
> > > > When a client requests a RemoteName, which value should be returned?
> > > > The value stored in the aliases file or the value stored in the names
> > > > file? Or are you suggesting create a property
> > > > "GetProperty("alias")/SetProperty("alias", "value")?
> > >
> > > When they request the remote name or device name, then they get the
> > > device name that is valid at the moment. This will maybe a cached name,
> > > but that doesn't matter. If hcid/bluetoothd knows better they will send
> > > out a remote name signal to tell them.
> > >
> > > The alias name is totally different and independent. It is application
> > > choice to use the alias name or not. If the alias name is empty they can
> > > use the remote/device name.
> >
> > Is there someone working on this stuff?
>
> Not that I know of.
>
> 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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>


--
---------------------------------------------------------
Claudio Takahasi
Instituto Nokia de Tecnologia - INdT

[-- Attachment #2: remote_name_cache02.patch --]
[-- Type: text/x-patch, Size: 4132 bytes --]

--- bluez-utils-cvs.orig/hcid/dbus.c	2006-02-07 23:22:31.000000000 -0200
+++ bluez-utils-cvs-remotename/hcid/dbus.c	2006-02-09 08:43:46.000000000 -0200
@@ -45,6 +45,7 @@
 
 #include "hcid.h"
 #include "dbus.h"
+#include "textfile.h"
 
 #ifndef DBUS_NAME_FLAG_PROHIBIT_REPLACEMENT
 #define DBUS_NAME_FLAG_PROHIBIT_REPLACEMENT	0x00
@@ -98,6 +99,19 @@
 	unregister_function_t	*unreg_func;
 	get_svc_table_func_t	*get_svc_table;	/* return the service table */
 };
+/*
+ * Utility functions
+ */
+static char *get_device_name(const bdaddr_t *local, const bdaddr_t *peer)
+{
+	char filename[PATH_MAX + 1], addr[18];
+
+	ba2str(local, addr);
+	snprintf(filename, PATH_MAX, "%s/%s/names", STORAGEDIR, addr);
+
+	ba2str(peer, addr);
+	return textfile_get(filename, addr);
+}
 
 /*
  * D-Bus error messages functions and declarations.
@@ -1707,50 +1721,92 @@
 static DBusMessage* handle_remote_name_req(DBusMessage *msg, void *data)
 {
 	DBusMessage *reply = NULL;
+	DBusMessage *signal = NULL;
 	struct hci_dbus_data *dbus_data = data;
-	int dd = -1;
 	const char *str_bdaddr;
+	char *name;
+	char path[MAX_PATH_LENGTH];
 	bdaddr_t bdaddr;
+	struct hci_dev_info di;
 	struct hci_request rq;
 	remote_name_req_cp cp;
 	evt_cmd_status rp;
+	int dd = -1;
 
 	dbus_message_get_args(msg, NULL,
 					DBUS_TYPE_STRING, &str_bdaddr,
 					DBUS_TYPE_INVALID);
 
 	str2ba(str_bdaddr, &bdaddr);
-
-	dd = hci_open_dev(dbus_data->dev_id);
-	if (dd < 0) {
-		syslog(LOG_ERR, "Unable to open device %d: %s (%d)",
-					dbus_data->dev_id, strerror(errno), errno);
-		reply = bluez_new_failure_msg(msg, BLUEZ_ESYSTEM_OFFSET + errno);
+	if (hci_devinfo(dbus_data->dev_id, &di) < 0) {
+		syslog(LOG_ERR, "Can't get device info");
+		reply = bluez_new_failure_msg(msg, BLUEZ_ESYSTEM_ENODEV);
 		goto failed;
 	}
 
-	memset(&cp, 0, sizeof(cp));
-	cp.bdaddr = bdaddr;
-	cp.pscan_rep_mode = 0x01;
+	/* Try retrieve from local cache */
+	name = get_device_name(&di.bdaddr, &bdaddr);
+	if (name) {
 
-	memset(&rq, 0, sizeof(rq));
-	rq.ogf    = OGF_LINK_CTL;
-	rq.ocf    = OCF_REMOTE_NAME_REQ;
-	rq.cparam = &cp;
-	rq.clen   = REMOTE_NAME_REQ_CP_SIZE;
-	rq.rparam = &rp;
-	rq.rlen   = EVT_CMD_STATUS_SIZE;
-	rq.event  = EVT_CMD_STATUS;
+		reply = dbus_message_new_method_return(msg);
 
-	if (hci_send_req(dd, &rq, 100) < 0) {
-		syslog(LOG_ERR, "Unable to send remote name request: %s (%d)",
-							strerror(errno), errno);
-		reply = bluez_new_failure_msg(msg, BLUEZ_ESYSTEM_OFFSET + errno);
-		goto failed;
+		snprintf(path, sizeof(path), "%s/hci%d/%s", DEVICE_PATH, dbus_data->dev_id, BLUEZ_HCI);
+
+		signal = dbus_message_new_signal(path, DEV_HCI_INTERFACE,
+						 BLUEZ_HCI_REMOTE_NAME);
+
+		dbus_message_append_args(signal,
+					 DBUS_TYPE_STRING, &str_bdaddr,
+					 DBUS_TYPE_STRING, &name,
+					 DBUS_TYPE_INVALID);
+
+		if (dbus_connection_send(connection, signal, NULL) == FALSE) {
+			syslog(LOG_ERR, "Can't send D-BUS remote name signal message");
+			goto failed;
+		}
+
+		dbus_message_unref(signal);
+		free(name);
+
+	} else {
+
+		/* Send HCI command */
+		dd = hci_open_dev(dbus_data->dev_id);
+		if (dd < 0) {
+			syslog(LOG_ERR, "Unable to open device %d: %s (%d)",
+						dbus_data->dev_id, strerror(errno), errno);
+			reply = bluez_new_failure_msg(msg, BLUEZ_ESYSTEM_OFFSET + errno);
+			goto failed;
+		}
+
+		memset(&cp, 0, sizeof(cp));
+		cp.bdaddr = bdaddr;
+		cp.pscan_rep_mode = 0x01;
+
+		memset(&rq, 0, sizeof(rq));
+		rq.ogf    = OGF_LINK_CTL;
+		rq.ocf    = OCF_REMOTE_NAME_REQ;
+		rq.cparam = &cp;
+		rq.clen   = REMOTE_NAME_REQ_CP_SIZE;
+		rq.rparam = &rp;
+		rq.rlen   = EVT_CMD_STATUS_SIZE;
+		rq.event  = EVT_CMD_STATUS;
+
+		if (hci_send_req(dd, &rq, 100) < 0) {
+			syslog(LOG_ERR, "Unable to send remote name request: %s (%d)",
+						strerror(errno), errno);
+			reply = bluez_new_failure_msg(msg, BLUEZ_ESYSTEM_OFFSET | errno);
+			goto failed;
+		}
+
+		if (rp.status) {
+			syslog(LOG_ERR, "Remote name request failed");
+			reply = bluez_new_failure_msg(msg, BLUEZ_EBT_OFFSET | rp.status);
+			goto failed;
+		}
 	}
 
 	reply = dbus_message_new_method_return(msg);
-
 failed:
 	if (dd >= 0)
 		hci_close_dev(dd);

Re: [Bluez-devel] [DBUS] remote name patch

[Marcel Holtmann]

Hi Claudio,

> According with your request, I am sending the patch again.
> The function get_device_name should be moved to a common library.

we maybe need to create a storage plugin which can be replaced very
easily, but for now it is fine.

> Basically, this patch try retrieve the remote name from the
> cache(names file) instead of send the HCI command everytime.

The pscan_rep_mode must be 0x02 if you don't have any cached value from
an inquiry result. I fixed it and committed it to the CVS.

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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel