[Bluez-devel] [DBUS PATCH] scan mode

[Bluez-devel] [DBUS PATCH] scan mode

[Claudio Takahasi]

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

Hi guys,


This patch add/fix the following services:
1. Changed GetMode/SetMode arguments to string, instead of use byte
2. Added IsConnectable
3. Added IsDiscoverable

Next action:
- Discoverable timout functions.

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

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

--- bluez-utils-cvs.orig/hcid/dbus.h	2006-02-12 05:27:40.000000000 -0200
+++ bluez-utils-cvs-scan/hcid/dbus.h	2006-02-13 11:53:24.000000000 -0200
@@ -206,17 +206,18 @@
 #define DEV_SIG_DISCOVER_COMPLETE	"DiscoverComplete"
 #define DEV_SIG_DISCOVER_RESULT		"DiscoverResult"
 
-/* FIXME: Change to string
+/*
  * Scanning modes, used by DEV_SET_MODE
  * off: remote devices are not allowed to find or connect to this device
  * connectable: remote devices are allowed to connect, but they are not
  *              allowed to find it.
  * discoverable: remote devices are allowed to connect and find this device
+ * unknown: reserved to not allowed/future modes
  */
-#define MODE_OFF		0x00	
-#define MODE_CONNECTABLE	0x01	
-#define MODE_DISCOVERABLE	0x02	
-
+#define MODE_OFF		"off"
+#define MODE_CONNECTABLE	"connectable"
+#define MODE_DISCOVERABLE	"discoverable"
+#define MODE_UNKNOWN		"unknown"
 
 /* BLUEZ_DBUS_ERROR 
  * EFailed error messages signature is : su
--- bluez-utils-cvs.orig/hcid/dbus-device.c	2006-02-12 04:33:18.000000000 -0200
+++ bluez-utils-cvs-scan/hcid/dbus-device.c	2006-02-13 12:42:26.000000000 -0200
@@ -41,6 +41,7 @@
 
 #include "textfile.h"
 
+
 static char *get_peer_name(const bdaddr_t *local, const bdaddr_t *peer)
 {
 	char filename[PATH_MAX + 1], addr[18];
@@ -257,7 +258,7 @@
 	const struct hci_dbus_data *dbus_data = data;
 	DBusMessage *reply = NULL;
 	const uint8_t hci_mode = dbus_data->path_data;
-	uint8_t scan_mode;
+	const char *scan_mode;
 
 	switch (hci_mode) {
 	case SCAN_DISABLED:
@@ -270,16 +271,16 @@
 		scan_mode = MODE_DISCOVERABLE;
 		break;
 	case SCAN_INQUIRY:
-	/* inquiry scan mode is not handled, return 0xff */
+	/* inquiry scan mode is not handled, return unknown */
 	default:
 		/* reserved */
-		scan_mode = 0xff;
+		scan_mode = MODE_UNKNOWN;
 	}
 
 	reply = dbus_message_new_method_return(msg);
 
 	dbus_message_append_args(reply,
-					DBUS_TYPE_BYTE, &scan_mode,
+					DBUS_TYPE_STRING, &scan_mode,
 					DBUS_TYPE_INVALID);
 
 	return reply;
@@ -287,14 +288,40 @@
 
 static DBusMessage* handle_dev_is_connectable_req(DBusMessage *msg, void *data)
 {
-	/*FIXME: */
-	return bluez_new_failure_msg(msg, BLUEZ_EDBUS_NOT_IMPLEMENTED);
+	const struct hci_dbus_data *dbus_data = data;
+	DBusMessage *reply = NULL;
+	const uint8_t hci_mode = dbus_data->path_data;
+	dbus_bool_t connectable = FALSE;
+
+	if (hci_mode & SCAN_PAGE)
+		connectable = TRUE;
+
+	reply = dbus_message_new_method_return(msg);
+
+	dbus_message_append_args(reply,
+					DBUS_TYPE_BOOLEAN, &connectable,
+					DBUS_TYPE_INVALID);
+
+	return reply;
 }
 
 static DBusMessage* handle_dev_is_discoverable_req(DBusMessage *msg, void *data)
 {
-	/*FIXME: */
-	return bluez_new_failure_msg(msg, BLUEZ_EDBUS_NOT_IMPLEMENTED);
+	const struct hci_dbus_data *dbus_data = data;
+	DBusMessage *reply = NULL;
+	const uint8_t hci_mode = dbus_data->path_data;
+	dbus_bool_t discoverable = FALSE;
+
+	if (hci_mode & SCAN_INQUIRY)
+		discoverable = TRUE;
+	
+	reply = dbus_message_new_method_return(msg);
+
+	dbus_message_append_args(reply,
+					DBUS_TYPE_BOOLEAN, &discoverable,
+					DBUS_TYPE_INVALID);
+
+	return reply;
 }
 
 static DBusMessage* handle_dev_set_class_req(DBusMessage *msg, void *data)
@@ -315,36 +342,31 @@
 	DBusMessage *reply = NULL;
 	struct hci_request rq;
 	int dd = -1;
-	const uint8_t scan_mode;
+	const char* scan_mode;
 	uint8_t hci_mode;
 	uint8_t status = 0;
 	const uint8_t current_mode = dbus_data->path_data;
 
 	dbus_message_get_args(msg, NULL,
-					DBUS_TYPE_BYTE, &scan_mode,
+					DBUS_TYPE_STRING, &scan_mode,
 					DBUS_TYPE_INVALID);
 
-	switch (scan_mode) {
-	case MODE_OFF:
+	if (!scan_mode)
+		return bluez_new_failure_msg(msg, BLUEZ_EDBUS_WRONG_PARAM);
+
+	if (strcasecmp(MODE_OFF, scan_mode) == 0)
 		hci_mode = SCAN_DISABLED;
-		break;
-	case MODE_CONNECTABLE:
+	else if (strcasecmp(MODE_CONNECTABLE, scan_mode) == 0)
 		hci_mode = SCAN_PAGE;
-		break;
-	case MODE_DISCOVERABLE:
+	else if (strcasecmp(MODE_DISCOVERABLE, scan_mode) == 0)
 		hci_mode = (SCAN_PAGE | SCAN_INQUIRY);
-		break;
-	default:
-		/* invalid mode */
-		reply = bluez_new_failure_msg(msg, BLUEZ_EDBUS_WRONG_PARAM);
-		goto failed;
-	}
+	else
+		return bluez_new_failure_msg(msg, BLUEZ_EDBUS_WRONG_PARAM);
 
 	dd = hci_open_dev(dbus_data->dev_id);
 	if (dd < 0) {
 		syslog(LOG_ERR, "HCI device open failed: hci%d", dbus_data->dev_id);
-		reply = bluez_new_failure_msg(msg, BLUEZ_ESYSTEM_ENODEV);
-		goto failed;
+		return bluez_new_failure_msg(msg, BLUEZ_ESYSTEM_ENODEV);
 	}
 
 	/* Check if the new requested mode is different from the current */
--- bluez-utils-cvs.orig/hcid/dbus.c	2006-02-12 03:49:17.000000000 -0200
+++ bluez-utils-cvs-scan/hcid/dbus.c	2006-02-13 12:42:27.000000000 -0200
@@ -1054,7 +1054,7 @@
 	struct hci_request rq;
 	int id;
 	int dd = -1;
-	uint8_t scan_mode;
+	const char *scan_mode;
 
 	baswap(&tmp, local); local_addr = batostr(&tmp);
 	id = hci_devid(local_addr);
@@ -1123,7 +1123,7 @@
 	}
 
 	dbus_message_append_args(message,
-					DBUS_TYPE_BYTE, &scan_mode,
+					DBUS_TYPE_STRING, &scan_mode,
 					DBUS_TYPE_INVALID);
 
 	if (dbus_connection_send(connection, message, NULL) == FALSE) {

Re: [Bluez-devel] [DBUS PATCH] scan mode

[Marcel Holtmann]

Hi Claudio,

> This patch add/fix the following services:
> 1. Changed GetMode/SetMode arguments to string, instead of use byte
> 2. Added IsConnectable
> 3. Added IsDiscoverable

I applied the patch to keep it going, but we need to rework the data
object associated with the device path. Using it like this

	const uint8_t hci_mode = dbus_data->path_data;

won't work forever and actually it is bad coding.

> Next action:
> - Discoverable timout functions.

Go ahead. I really like to see this in action.

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 PATCH] scan mode

[Claudio Takahasi]

Hi Marcel,

On 2/14/06, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Claudio,
>
> > This patch add/fix the following services:
> > 1. Changed GetMode/SetMode arguments to string, instead of use byte
> > 2. Added IsConnectable
> > 3. Added IsDiscoverable
>
> I applied the patch to keep it going, but we need to rework the data
> object associated with the device path. Using it like this
>
>         const uint8_t hci_mode =3D dbus_data->path_data;
>
> won't work forever and actually it is bad coding.
[Claudio Takahasi]
I don't know exactly what is problem, but I guess it should be related
to uint32 to uint8 casting.

I will change the path_data to a device settings structure, where I
want store the scan mode and the discoverable timeout. In my opinion
the discoverable timeout should be unique for each local adapter. Do
you have any comments or suggestion?


 struct device_settings {
         uint32_t discoverable_to;
         uint8_t  scan_mode;
 };

 struct hci_dbus_data {
         uint16_t dev_id;
         uint16_t path_id;
         struct device_settings dev_settings;
 };

>
> > Next action:
> > - Discoverable timout functions.
>
> Go ahead. I really like to see this in action.
[Claudio Takahasi]
I am planning use the SIGALARM. Another option is integrate inside the
main loop, using a poll timeout. However it is a little bit more
complicated.
Do you agree with this approach?

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 PATCH] scan mode

[Marcel Holtmann]

Hi Claudio,

> > I applied the patch to keep it going, but we need to rework the data
> > object associated with the device path. Using it like this
> >
> >         const uint8_t hci_mode = dbus_data->path_data;
> >
> > won't work forever and actually it is bad coding.
> 
> I don't know exactly what is problem, but I guess it should be related
> to uint32 to uint8 casting.

the casting is not that big problem. It is a misuse of the variable,
because the name is not clear. In other code paths you might use the
path_data variable too and then it clashes. These things are really hard
to debug.

> I will change the path_data to a device settings structure, where I
> want store the scan mode and the discoverable timeout. In my opinion
> the discoverable timeout should be unique for each local adapter. Do
> you have any comments or suggestion?
> 
> 
>  struct device_settings {
>          uint32_t discoverable_to;
>          uint8_t  scan_mode;
>  };
> 
>  struct hci_dbus_data {
>          uint16_t dev_id;
>          uint16_t path_id;
>          struct device_settings dev_settings;
>  };

I don't see any need for another nested structure. Actually I would
prefer using something like this:

	struct hci_dbus_data {
		uint16_t dev_id;
		uint16_t path_id;
		uint8_t mode;
		uint32_t discoverable_timeout;
	}

> I am planning use the SIGALARM. Another option is integrate inside the
> main loop, using a poll timeout. However it is a little bit more
> complicated.

In the end we might need to integrate it into the main loop, because
this looks like the cleanest approach to me. However for now it might be
enough to use SIGALARM.

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