HCID D-Bus

Bluez-devel Claudio Takahasi 4 participants 17 messages Sep 8, 2005 – Sep 15, 2005 Bluetooth drivers

Share & tools

Claudio Takahasi

author

2005-09-08 19:50 UTC #0 lore raw

Hi Marcel,

In the last email about bluetoothd, you suggested send patches to enhance hcid. I studied the hcid code and I would like align our ideas before start coding. My suggestions are:

1. Develop a common code addressing all D-Bus versions
2. Send signals to connection complete and disconnection
3. Register a D-Bus hci object path as a initial point for bluetoothd and provide basic services(inquiry, auth, ...).

Do you agree? Do you have suggestions/comments?

I am sending a patch to solve the problem of D-Bus versions. Sorry, byte array is not being handled yet, but I will fix it. This is just a idea of how solve the problem of several D-Bus versions. Get the dbus major/minor version in the "configure" is a better approach, instead of check if the function dbus_message_iter_get_basic belongs to the dbus-1 library. If you allow change the makefiles(acinclude.m4, configure.in <http://configure.in>,
config.h.in <http://config.h.in> ) I can modify it.

Regards,
Claudio.

Marcel Holtmann

maintainer

2005-09-08 23:07 UTC #1 lore raw

Hi Claudio,

Quoted 5 lines

In the last email about bluetoothd, you suggested send patches to enhance hcid. I studied the hcid code and I would like align our ideas before start coding. My suggestions are:
1. Develop a common code addressing all D-Bus versions

not needed, because my plan is to drop support for anything below D-Bus version 0.5 (which should be compatible with D-Bus 0.3x) starting with bluez-utils-0.22. My original plan was to do it in next release, but there are some memory leak fixes and I want to get out a new version as soon as possible. However maybe it is a good idea to drop support for older D-Bus versions now.

It seems the only problematic distribution is Debian unstable. Every other distribution (including Ubuntu) uses at least D-Bus 0.35.

Quoted 1 line

2. Send signals to connection complete and disconnection

While I was adding the signals for the inquiry responses, I thought about doing this, too. I added the needed functions for it and open the filter for these messages. The only problem is that the disconnect uses the ACL handle and not the device address. This means you have to keep track of all handles. Normally the kernel does this all for us. This is one reason for a good/new interface between the kernel and bluetoothd. Coding everything twice is stupid.

Quoted 2 lines

3. Register a D-Bus hci object path as a initial point for bluetoothd and provide basic services(inquiry, auth, ...).

Go ahead. I would really welcome it.

I need a job where I can fulltime work on bluetoothd and add all the cool things we talked about. If anyone know one or has one, let me know.

Quoted 7 lines

I am sending a patch to solve the problem of D-Bus versions. Sorry, byte array is not being handled yet, but I will fix it. This is just a idea of how solve the problem of several D-Bus versions. Get the dbus major/minor version in the "configure" is a better approach, instead of check if the function dbus_message_iter_get_basic belongs to the dbus-1 library. If you allow change the makefiles(acinclude.m4, configure.in, config.h.in ) I can modify it.

I like to drop support for older D-Bus versions. After a private talk with J5 it seems the only sane way to do.

Regards

Marcel

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Peter Robinson

2005-09-09 08:25 UTC #2 lore raw

Quoted 9 lines

Quoted 2 lines
1. Develop a common code addressing all D-Bus versions
not needed, because my plan is to drop support for anything below D-Bus version 0.5 (which should be compatible with D-Bus 0.3x) starting with bluez-utils-0.22. My original plan was to do it in next release, but there are some memory leak fixes and I want to get out a new version as soon as possible. However maybe it is a good idea to drop support for older D-Bus versions now.

I think 0.5 is compatible with >0.35. The current FC4 only uses 0.33 and I don't think its compatible with >0.35. I think this is similar for a number of the current releases (I think most with gnome 2.10) but obviously isn't the case for the development streams that aren't releases yet.

Pete

Marcel Holtmann

maintainer

2005-09-09 09:37 UTC #3 lore raw

Hi Pete,

Quoted 5 lines

I think 0.5 is compatible with >0.35. The current FC4 only uses 0.33 and I don't think its compatible with > 0.35. I think this is similar for a number of the current releases (I think most with gnome 2.10) but obviously isn't the case for the development streams that aren't releases yet.

having 0.33 is better than 0.23 and this is what Debian unstable still uses. However lets make a list of the distributions:

	SuSE Linux 10.0		D-Bus 0.35
	Fedora Core 4		D-Bus 0.33
	Ubuntu Breezy		D-Bus 0.36
	Debian unstable		D-Bus 0.23

The only bad guy is Debian unstable and I don't care anymore. They use Xorg finally and have GCC 4.0 etc., but they can't move over to the next D-Bus generation. I think that is their problem now and the release of bluez-utils-0.22 will definitely drop the support for the old D-Bus 0.23 version.

I like to base everything around the current D-Bus 0.50 release, because the C API should be quite stable now. I will accept small workarounds to make D-Bus 0.3x work, but as soon as the distributions update their D-Bus libraries I will drop them.

This is not a nice thing to do, I know, but a wrong usage of D-Bus lets hcid segfault and this is not what I want.

Regards

Marcel

Sjoerd Simons

2005-09-09 13:29 UTC #4 lore raw

Quoted 8 lines · Marcel Holtmann

Hi Pete,
Quoted 5 lines
I think 0.5 is compatible with >0.35. The current FC4 only uses 0.33 and I don't think its compatible with > 0.35. I think this is similar for a number of the current releases (I think most with gnome 2.10) but obviously isn't the case for the development streams that aren't releases yet.

Quoted 7 lines

having 0.33 is better than 0.23 and this is what Debian unstable still uses. However lets make a list of the distributions:
	SuSE Linux 10.0		D-Bus 0.35
	Fedora Core 4		D-Bus 0.33
	Ubuntu Breezy		D-Bus 0.36
	Debian unstable		D-Bus 0.23

Debian experimental D-Bus 0.50

Quoted 6 lines

The only bad guy is Debian unstable and I don't care anymore. They use Xorg finally and have GCC 4.0 etc., but they can't move over to the next D-Bus generation. I think that is their problem now and the release of bluez-utils-0.22 will definitely drop the support for the old D-Bus 0.23 version.

D-bus >= 0.3x has been in debian experimental for quite some time. There are various transitions going on in debian unstable currently which makes it inappropriate to do a dbus transition now too.

Quoted 7 lines

I like to base everything around the current D-Bus 0.50 release, because the C API should be quite stable now. I will accept small workarounds to make D-Bus 0.3x work, but as soon as the distributions update their D-Bus libraries I will drop them.
This is not a nice thing to do, I know, but a wrong usage of D-Bus lets hcid segfault and this is not what I want.

As one of debian's dbus maintainers i would advise to indeed base everything on dbus >= 0.50. Hopefully it won't take too long before we can move the new dbus from experimental to unstable, so the workarounds for old dbus release are just not worth it.

Sjoerd

Signature · 12 lines

He keeps differentiating, flying off on a tangent.


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Marcel Holtmann

maintainer

2005-09-09 13:40 UTC #5 lore raw

Hi Sjoerd,

Quoted 8 lines

Quoted 7 lines
having 0.33 is better than 0.23 and this is what Debian unstable still uses. However lets make a list of the distributions:
	SuSE Linux 10.0		D-Bus 0.35
	Fedora Core 4		D-Bus 0.33
	Ubuntu Breezy		D-Bus 0.36
	Debian unstable		D-Bus 0.23
Debian experimental D-Bus 0.50

this is good.

Quoted 9 lines

Quoted 5 lines
The only bad guy is Debian unstable and I don't care anymore. They use Xorg finally and have GCC 4.0 etc., but they can't move over to the next D-Bus generation. I think that is their problem now and the release of bluez-utils-0.22 will definitely drop the support for the old D-Bus 0.23 version.
D-bus >= 0.3x has been in debian experimental for quite some time. There are various transitions going on in debian unstable currently which makes it inappropriate to do a dbus transition now too.

Last time I looked at it, the complete KDE part was broken and full of wrong dependencies. So breaking D-Bus wouldn't even be notified ;)

Quoted 5 lines

Quoted 5 lines
I like to base everything around the current D-Bus 0.50 release, because the C API should be quite stable now. I will accept small workarounds to make D-Bus 0.3x work, but as soon as the distributions update their D-Bus libraries I will drop them.

Quoted 7 lines

Quoted 2 lines
This is not a nice thing to do, I know, but a wrong usage of D-Bus lets hcid segfault and this is not what I want.
As one of debian's dbus maintainers i would advise to indeed base everything on dbus >= 0.50. Hopefully it won't take too long before we can move the new dbus from experimental to unstable, so the workarounds for old dbus release are just not worth it.

This means I will release bluez-utils-2.21 on the weekend, because of some memory leak fixes and then I will drop D-Bus 0.23 support. So if any patches need to go in before, please send them now.

Regards

Marcel

Claudio Takahasi

author

2005-09-12 21:07 UTC #6 lore raw

Re: [Bluez-devel] HCID D-Bus (Sig Fault)

Hi Marcel,

I am sending a new patch that contains the following enhancements:
1. Support multiple D-Bus versions(0.23, 0.30...)
2. Fixed error handling ServiceDoesNotExist, NoReply, UnknownService, ... This condition is causing sig fault due the wrong pin value. Scenario: D-Bus pin helper enabled
and an error different than wrong argument triggered.

Regards,
Claudio.

Quoted 60 lines · Marcel Holtmann

Hi Sjoerd,
Quoted 8 lines
Quoted 7 lines
having 0.33 is better than 0.23 and this is what Debian unstable still uses. However lets make a list of the distributions:
SuSE Linux 10.0 D-Bus 0.35
Fedora Core 4 D-Bus 0.33
Ubuntu Breezy D-Bus 0.36
Debian unstable D-Bus 0.23
Debian experimental D-Bus 0.50
this is good.
Quoted 2 lines
Quoted 2 lines
The only bad guy is Debian unstable and I don't care anymore. They use Xorg finally and have GCC 4.0 etc., but they can't move over to the
next
Quoted 2 lines
Quoted 2 lines
D-Bus generation. I think that is their problem now and the release of bluez-utils-0.22 will definitely drop the support for the old D-Bus
0.23
Quoted 3 lines
Quoted 1 line
version.
D-bus >= 0.3x has been in debian experimental for quite some time. There
are
Quoted 2 lines
various transitions going on in debian unstable currently which makes it inappropriate to do a dbus transition now too.
Last time I looked at it, the complete KDE part was broken and full of wrong dependencies. So breaking D-Bus wouldn't even be notified ;)
Quoted 1 line
Quoted 1 line
I like to base everything around the current D-Bus 0.50 release,
because
Quoted 1 line
Quoted 1 line
the C API should be quite stable now. I will accept small workarounds
to
Quoted 4 lines
Quoted 4 lines
make D-Bus 0.3x work, but as soon as the distributions update their D-Bus libraries I will drop them.
This is not a nice thing to do, I know, but a wrong usage of D-Bus
lets
Quoted 3 lines
Quoted 1 line
hcid segfault and this is not what I want.
As one of debian's dbus maintainers i would advise to indeed base
everything on
Quoted 1 line
dbus >= 0.50. Hopefully it won't take too long before we can move the
new dbus
Quoted 1 line
from experimental to unstable, so the workarounds for old dbus release
are just
Quoted 1 line
not worth it.
This means I will release bluez-utils-2.21 on the weekend, because of some memory leak fixes and then I will drop D-Bus 0.23 support. So if any patches need to go in before, please send them now.
Regards
Marcel

Quoted 11 lines

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

hcid/dbus-compat.h +114 -0

@@ -0,0 +1,114 @@
+/*
+ *
+ *  BlueZ - Bluetooth protocol stack for Linux
+ *
+ *  Copyright (C) 2000-2001  Qualcomm Incorporated
+ *  Copyright (C) 2002-2003  Maxim Krasnyansky <[email protected]>
+ *  Copyright (C) 2002-2005  Marcel Holtmann <[email protected]>
+ *
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation;
+ *
+ *  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ *  OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ *  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS.
+ *  IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) AND AUTHOR(S) BE LIABLE FOR ANY
+ *  CLAIM, OR ANY SPECIAL INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES 
+ *  WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN 
+ *  ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF 
+ *  OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ *
+ *  ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF ANY PATENTS, 
+ *  COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS, RELATING TO USE OF THIS 
+ *  SOFTWARE IS DISCLAIMED.
+ *
+ *
+ *  $Id: dbus-compat.h,v 1.24 2005/09/08 18:32:41 holtmann Exp $
+ */
+
+#ifndef __H_DBUS_COMPAT_H__
+#define __H_DBUS_COMPAT_H__
+
+#ifdef HAVE_CONFIG_H
+#include <config.h>
+#endif
+
+#define CHECK_DBUS_VERSION(major, minor) \
+		(DBUS_MAJOR_VER > (major) || \
+		 	(DBUS_MAJOR_VER == (major) && DBUS_MINOR_VER >= (minor)))
+	
+#if CHECK_DBUS_VERSION(0, 30)
+	/* For D-Bus version >= 0.30 */
+	/****** pending, requires chnages in the makefile  *****/
+#else /* < 0.30 */
+	/* For D-Bus version older than 0.30 */
+	
+#endif
+
+#if  HAVE_DBUS_MESSAGE_ITER_GET_BASIC
+	#warning "D-Bus > 0.30"
+	
+	/* Get iterators */
+	#define DBUS_MSG_ITER_GET_STR(iter, retvar) \
+			dbus_message_iter_get_basic((iter), &(retvar))
+	#define DBUS_MSG_ITER_GET_BYTE(iter, retvar) \
+			dbus_message_iter_get_basic((iter), &(retvar))
+			
+	/* Append iterators */
+	#define DBUS_MSG_APPEND_ITER_INIT(a, b) \
+			dbus_message_iter_init_append(a, b)	
+	#define DBUS_MSG_ITER_APPEND_BYTE(iter, val) \
+			dbus_message_iter_append_basic((iter), DBUS_TYPE_BYTE, &(val))
+	#define DBUS_MSG_ITER_APPEND_STR(iter, val) \
+			dbus_message_iter_append_basic((iter), DBUS_TYPE_STRING, &(val))
+	#define DBUS_MSG_ITER_APPEND_BOOL(iter, val) \
+			dbus_message_iter_append_basic((iter), DBUS_TYPE_BOOLEAN, &(val))
+	#define DBUS_MSG_ITER_APPEND_INT32(iter, val) \
+			dbus_message_iter_append_basic((iter), DBUS_TYPE_INT32, &(val))
+	#define DBUS_MSG_ITER_APPEND_UINT32(iter, val) \
+			dbus_message_iter_append_basic((iter), DBUS_TYPE_UINT32, &(val))
+
+	inline void DBUS_MSG_ITER_APPEND_BYTE_ARRAY(DBusMessageIter *iter, uint8_t *ptr, uint8_t size) 
+	{
+		DBusMessageIter array_iter;
+		const char array_sig[] = DBUS_TYPE_BYTE_AS_STRING;
+		int i;
+		
+		dbus_message_iter_open_container(iter, DBUS_TYPE_ARRAY, array_sig, &array_iter);
+		for ( i = 0; i < size; i++ ) {
+			DBUS_MSG_ITER_APPEND_BYTE(&array_iter, ptr);
+		}
+		dbus_message_iter_close_container(iter, &array_iter);
+	}
+#else
+	#warning "D-Bus < 0.30"
+	
+	/* Get iterators */
+	#define DBUS_MSG_ITER_GET_STR(iter, retvar) \
+			retvar = dbus_message_iter_get_string(iter)
+	#define DBUS_MSG_ITER_GET_BYTE(iter, retvar) \
+			retvar = dbus_message_iter_get_byte(iter)
+			
+	/* Append iterators */
+	#define DBUS_MSG_APPEND_ITER_INIT(a, b) \
+			dbus_message_append_iter_init(a, b)
+	#define DBUS_MSG_ITER_APPEND_BYTE(iter, val) \
+			dbus_message_iter_append_byte((iter), (val))
+	#define DBUS_MSG_ITER_APPEND_STR(iter, val) \
+			dbus_message_iter_append_string((iter), (val))
+	#define DBUS_MSG_ITER_APPEND_BOOL(iter, val) \
+			dbus_message_iter_append_boolean((iter), (val))
+	#define DBUS_MSG_ITER_APPEND_INT32(iter, val) \
+			dbus_message_iter_append_int32((iter), (val))
+	#define DBUS_MSG_ITER_APPEND_UINT32(iter, val) \
+			dbus_message_iter_append_uint32((iter), (val))
+	#define DBUS_MSG_ITER_APPEND_BYTE_ARRAY(iter, val, size) \
+		dbus_message_iter_append_byte_array(iter, val, size)
+
+#endif
+
+
+
+#endif /*__H_DBUS_COMPAT_H__*/

hcid/dbus.c +59 ~~-101~~

280 lines not on this page · raw message

Claudio Takahasi

author

2005-09-12 21:14 UTC #7 lore raw

Re: [Bluez-devel] HCID D-Bus (Seg Fault)

Sorry,

segmentation fault :)

This problem happens because the pin will contains the long error message string instead of a short pin number.

Quoted 95 lines · Claudio Takahasi

Hi Marcel,
I am sending a new patch that contains the following enhancements:
1. Support multiple D-Bus versions(0.23, 0.30...)
2. Fixed error handling ServiceDoesNotExist, NoReply, UnknownService, ... This condition is causing sig fault due the wrong pin value. Scenario:
D-Bus pin helper enabled
and an error different than wrong argument triggered.
Regards,
Claudio.
Quoted 77 lines · Marcel Holtmann
Hi Sjoerd,
Quoted 1 line
Quoted 1 line
having 0.33 is better than 0.23 and this is what Debian unstable
still
Quoted 7 lines
Quoted 6 lines
uses. However lets make a list of the distributions:
SuSE Linux 10.0 D-Bus 0.35
Fedora Core 4 D-Bus 0.33
Ubuntu Breezy D-Bus 0.36
Debian unstable D-Bus 0.23
Debian experimental D-Bus 0.50
this is good.
Quoted 1 line
Quoted 1 line
The only bad guy is Debian unstable and I don't care anymore. They
use
Quoted 1 line
Quoted 1 line
Xorg finally and have GCC 4.0 etc., but they can't move over to the
next
Quoted 1 line
Quoted 1 line
D-Bus generation. I think that is their problem now and the release
of
Quoted 1 line
Quoted 1 line
bluez-utils-0.22 will definitely drop the support for the old D-Bus
0.23
Quoted 3 lines
Quoted 1 line
version.
D-bus >= 0.3x has been in debian experimental for quite some time.
There are
Quoted 1 line
various transitions going on in debian unstable currently which makes
it
Quoted 1 line
inappropriate to do a dbus transition now too.
Last time I looked at it, the complete KDE part was broken and full of wrong dependencies. So breaking D-Bus wouldn't even be notified ;)
Quoted 1 line
Quoted 1 line
I like to base everything around the current D-Bus 0.50 release,
because
Quoted 1 line
Quoted 1 line
the C API should be quite stable now. I will accept small
workarounds to
Quoted 4 lines
Quoted 4 lines
make D-Bus 0.3x work, but as soon as the distributions update their D-Bus libraries I will drop them.
This is not a nice thing to do, I know, but a wrong usage of D-Bus
lets
Quoted 3 lines
Quoted 1 line
hcid segfault and this is not what I want.
As one of debian's dbus maintainers i would advise to indeed base
everything on
Quoted 1 line
dbus >= 0.50. Hopefully it won't take too long before we can move the
new dbus
Quoted 1 line
from experimental to unstable, so the workarounds for old dbus release
are just
Quoted 1 line
not worth it.
This means I will release bluez-utils-2.21 on the weekend, because of some memory leak fixes and then I will drop D-Bus 0.23 support. So if any patches need to go in before, please send them now.
Regards
Marcel
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Marcel Holtmann

maintainer

2005-09-12 21:40 UTC #8 lore raw

Re: [Bluez-devel] HCID D-Bus (Sig Fault)

In reply to Claudio Takahasi

Hi Claudio,

Quoted 7 lines

I am sending a new patch that contains the following enhancements:
1. Support multiple D-Bus versions(0.23, 0.30...)
2. Fixed error handling ServiceDoesNotExist, NoReply, UnknownService, ...
This condition is causing sig fault due the wrong pin value.
Scenario: D-Bus pin helper enabled
and an error different than wrong argument triggered.

since bluez-utils-2.21 is out, I am going do remove the support for the old D-Bus 0.23 API now. So there is no need for any compat code.

Regards

Marcel

Claudio Takahasi

author

2005-09-12 23:09 UTC #9 lore raw

Re: [Bluez-devel] HCID D-Bus (Sig Fault)

Hi Marcel,

Regarding the reply_handler_function, please check if it is relevant. I you want I can send only the changes for handle the error messages.

Regards,
Claudio.

Quoted 32 lines · Marcel Holtmann

Hi Claudio,
Quoted 7 lines
I am sending a new patch that contains the following enhancements:
1. Support multiple D-Bus versions(0.23, 0.30...)
2. Fixed error handling ServiceDoesNotExist, NoReply, UnknownService, ...
This condition is causing sig fault due the wrong pin value.
Scenario: D-Bus pin helper enabled
and an error different than wrong argument triggered.
since bluez-utils-2.21 is out, I am going do remove the support for the old D-Bus 0.23 API now. So there is no need for any compat code.
Regards
Marcel
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Marcel Holtmann

maintainer

2005-09-12 23:21 UTC #10 lore raw

Re: [Bluez-devel] HCID D-Bus (Sig Fault)

Hi Claudio,

Quoted 2 lines

Regarding the reply_handler_function, please check if it is relevant. I you want I can send only the changes for handle the error messages.

please do so.

Regards

Marcel

Claudio Takahasi

author

2005-09-13 13:03 UTC #11 lore raw

Re: [Bluez-devel] HCID D-Bus (Seg Fault)

Hi Marcel,

The patch for reply_handler_function is attached.

Regards,
Claudio.

Quoted 15 lines · Marcel Holtmann

Hi Claudio,
Quoted 2 lines
Regarding the reply_handler_function, please check if it is relevant. I you want I can send only the changes for handle the error messages.
please do so.
Regards
Marcel

Quoted 11 lines

-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

hcid/dbus.c +27 ~~-14~~

@@ -68,27 +68,43 @@
 	pin_code_reply_cp pr;
 	DBusMessage *message;
 	DBusMessageIter iter;
-	int type;
+	int arg_type;
+	int msg_type;
 	size_t len;
 	char *pin;
+	const char *error_msg;
 
 	message = dbus_pending_call_steal_reply(call);
 
-	if (dbus_message_is_error(message, WRONG_ARGS_ERROR))
-		goto error;
-
+	if (message) {
+		msg_type = dbus_message_get_type(message);
 	dbus_message_iter_init(message, &iter);
 
-	type = dbus_message_iter_get_arg_type(&iter);
-	if (type != DBUS_TYPE_STRING)
-		goto error;
+		if (msg_type == DBUS_MESSAGE_TYPE_ERROR) {
+#ifdef HAVE_DBUS_MESSAGE_ITER_GET_BASIC
+		        dbus_message_iter_get_basic(&iter, &error_msg);
+#else
+		        erro_msg = dbus_message_iter_get_string(&iter);
+#endif
+			/* handling WRONG_ARGS_ERROR, DBUS_ERROR_NO_REPLY, DBUS_ERROR_SERVICE_UNKNOWN */
+			syslog(LOG_ERR, "%s: %s", dbus_message_get_error_name(message), error_msg);
 
+			hci_send_cmd(req->dev, OGF_LINK_CTL,
+				OCF_PIN_CODE_NEG_REPLY, 6, &req->bda);
+		} else {
+			/* check signature */
+			arg_type = dbus_message_iter_get_arg_type(&iter);	
+			if (arg_type != DBUS_TYPE_STRING) {
+				syslog(LOG_ERR, "Wrong reply signature: expected PIN");
+			
+				hci_send_cmd(req->dev, OGF_LINK_CTL,
+				     OCF_PIN_CODE_NEG_REPLY, 6, &req->bda);
+			} else {
 #ifdef HAVE_DBUS_MESSAGE_ITER_GET_BASIC
 	dbus_message_iter_get_basic(&iter, &pin);
 #else
 	pin = dbus_message_iter_get_string(&iter);
 #endif
-
 	len = strlen(pin);
 
 	memset(&pr, 0, sizeof(pr));

@@ -97,15 +113,12 @@
 	pr.pin_len = len;
 	hci_send_cmd(req->dev, OGF_LINK_CTL, OCF_PIN_CODE_REPLY,
 						PIN_CODE_REPLY_CP_SIZE, &pr);
+			}
 
+		}
 	dbus_message_unref(message);
+	}
 	dbus_pending_call_unref(call);
-
-	return;
-
-error:
-	hci_send_cmd(req->dev, OGF_LINK_CTL,
-				OCF_PIN_CODE_NEG_REPLY, 6, &req->bda);
 }
 
 static void free_pin_req(void *req)

Marcel Holtmann

maintainer

2005-09-13 18:54 UTC #12 lore raw

Re: [Bluez-devel] HCID D-Bus (Seg Fault)

Hi Claudio,

Quoted 1 line

The patch for reply_handler_function is attached.

please redo it against the latest CVS, because I already dropped the D-Bus 0.23 support.

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

Claudio Takahasi

author

2005-09-14 12:00 UTC #13 lore raw

Re: [Bluez-devel] HCID D-Bus (Seg Fault)

Hi Marcel,

It's done! The changes was based on the dbus.c revision 1.15.

Regards,
Claudio.

Quoted 15 lines · Marcel Holtmann

Hi Claudio,
Quoted 1 line
The patch for reply_handler_function is attached.
please redo it against the latest CVS, because I already dropped the D-Bus 0.23 support.
Regards
Marcel

Quoted 10 lines

-------------------------------------------------------
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

hcid/dbus.c +48 ~~-37~~

@@ -64,43 +64,54 @@
 
 static void reply_handler_function(DBusPendingCall *call, void *user_data)
 {
-	struct pin_request *req = (struct pin_request *) user_data;
-	pin_code_reply_cp pr;
-	DBusMessage *message;
-	DBusMessageIter iter;
-	int type;
-	size_t len;
-	char *pin;
-
-	message = dbus_pending_call_steal_reply(call);
-
-	if (dbus_message_is_error(message, WRONG_ARGS_ERROR))
-		goto error;
-
-	dbus_message_iter_init(message, &iter);
-
-	type = dbus_message_iter_get_arg_type(&iter);
-	if (type != DBUS_TYPE_STRING)
-		goto error;
-
-	dbus_message_iter_get_basic(&iter, &pin);
-	len = strlen(pin);
-
-	memset(&pr, 0, sizeof(pr));
-	bacpy(&pr.bdaddr, &req->bda);
-	memcpy(pr.pin_code, pin, len);
-	pr.pin_len = len;
-	hci_send_cmd(req->dev, OGF_LINK_CTL, OCF_PIN_CODE_REPLY,
-						PIN_CODE_REPLY_CP_SIZE, &pr);
-
-	dbus_message_unref(message);
-	dbus_pending_call_unref(call);
-
-	return;
-
-error:
-	hci_send_cmd(req->dev, OGF_LINK_CTL,
-				OCF_PIN_CODE_NEG_REPLY, 6, &req->bda);
+        struct pin_request *req = (struct pin_request *) user_data;
+        pin_code_reply_cp pr;
+        DBusMessage *message;
+        DBusMessageIter iter;
+        int arg_type;
+        int msg_type;
+        size_t len;
+        char *pin;
+        const char *error_msg;
+
+        message = dbus_pending_call_steal_reply(call);
+
+        if (message) {
+                msg_type = dbus_message_get_type(message);
+                dbus_message_iter_init(message, &iter);
+
+                if (msg_type == DBUS_MESSAGE_TYPE_ERROR) {
+                        dbus_message_iter_get_basic(&iter, &error_msg);
+                        /* handling WRONG_ARGS_ERROR, DBUS_ERROR_NO_REPLY, DBUS_ERROR_SERVICE_UNKNOWN */
+                        syslog(LOG_ERR, "%s: %s", dbus_message_get_error_name(message), error_msg);
+
+                        hci_send_cmd(req->dev, OGF_LINK_CTL,
+                                OCF_PIN_CODE_NEG_REPLY, 6, &req->bda);
+                } else {
+                        /* check signature */
+                        arg_type = dbus_message_iter_get_arg_type(&iter);
+                        if (arg_type != DBUS_TYPE_STRING) {
+                                syslog(LOG_ERR, "Wrong reply signature: expected PIN");
+
+                                hci_send_cmd(req->dev, OGF_LINK_CTL,
+                                     OCF_PIN_CODE_NEG_REPLY, 6, &req->bda);
+                        } else {
+                                dbus_message_iter_get_basic(&iter, &pin);
+
+                                len = strlen(pin);
+
+                                memset(&pr, 0, sizeof(pr));
+                                bacpy(&pr.bdaddr, &req->bda);
+                                memcpy(pr.pin_code, pin, len);
+                                pr.pin_len = len;
+                                hci_send_cmd(req->dev, OGF_LINK_CTL, OCF_PIN_CODE_REPLY,
+                                        PIN_CODE_REPLY_CP_SIZE, &pr);
+                        }
+
+                }
+                dbus_message_unref(message);
+        }
+        dbus_pending_call_unref(call);
 }
 
 static void free_pin_req(void *req)

Marcel Holtmann

maintainer

2005-09-14 15:16 UTC #14 lore raw

Re: [Bluez-devel] HCID D-Bus (Seg Fault)

Hi Claudio,

Quoted 1 line

It's done! The changes was based on the dbus.c revision 1.15.

you used spaces instead of tabs. Please redo it again.

Regards

Marcel

Claudio Takahasi

author

2005-09-14 16:06 UTC #15 lore raw

Re: [Bluez-devel] HCID D-Bus (Seg Fault)

sorry. It's done!

Regards,
Claudio.

Quoted 14 lines · Marcel Holtmann

Hi Claudio,
Quoted 1 line
It's done! The changes was based on the dbus.c revision 1.15.
you used spaces instead of tabs. Please redo it again.
Regards
Marcel

Quoted 10 lines

-------------------------------------------------------
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

hcid/dbus.c +37 ~~-29~~

@@ -68,39 +68,47 @@
 	pin_code_reply_cp pr;
 	DBusMessage *message;
 	DBusMessageIter iter;
-	int type;
+	int arg_type;
+	int msg_type;
 	size_t len;
 	char *pin;
-
+	const char *error_msg;
+        
 	message = dbus_pending_call_steal_reply(call);
-
-	if (dbus_message_is_error(message, WRONG_ARGS_ERROR))
-		goto error;
-
-	dbus_message_iter_init(message, &iter);
-
-	type = dbus_message_iter_get_arg_type(&iter);
-	if (type != DBUS_TYPE_STRING)
-		goto error;
-
-	dbus_message_iter_get_basic(&iter, &pin);
-	len = strlen(pin);
-
-	memset(&pr, 0, sizeof(pr));
-	bacpy(&pr.bdaddr, &req->bda);
-	memcpy(pr.pin_code, pin, len);
-	pr.pin_len = len;
-	hci_send_cmd(req->dev, OGF_LINK_CTL, OCF_PIN_CODE_REPLY,
-						PIN_CODE_REPLY_CP_SIZE, &pr);
-
-	dbus_message_unref(message);
+        
+	if (message) {
+		msg_type = dbus_message_get_type(message);
+		dbus_message_iter_init(message, &iter);
+		
+		if (msg_type == DBUS_MESSAGE_TYPE_ERROR) {
+			dbus_message_iter_get_basic(&iter, &error_msg);
+			/* handling WRONG_ARGS_ERROR, DBUS_ERROR_NO_REPLY, DBUS_ERROR_SERVICE_UNKNOWN */
+			syslog(LOG_ERR, "%s: %s", dbus_message_get_error_name(message), error_msg);
+			hci_send_cmd(req->dev, OGF_LINK_CTL,
+				     OCF_PIN_CODE_NEG_REPLY, 6, &req->bda);
+		} else {
+			/* check signature */
+			arg_type = dbus_message_iter_get_arg_type(&iter);
+			if (arg_type != DBUS_TYPE_STRING) {
+				syslog(LOG_ERR, "Wrong reply signature: expected PIN");
+				hci_send_cmd(req->dev, OGF_LINK_CTL,
+					     OCF_PIN_CODE_NEG_REPLY, 6, &req->bda);
+			} else {
+				dbus_message_iter_get_basic(&iter, &pin);
+				
+				len = strlen(pin);
+				
+				memset(&pr, 0, sizeof(pr));
+				bacpy(&pr.bdaddr, &req->bda);
+				memcpy(pr.pin_code, pin, len);
+				pr.pin_len = len;
+				hci_send_cmd(req->dev, OGF_LINK_CTL, OCF_PIN_CODE_REPLY,
+					     PIN_CODE_REPLY_CP_SIZE, &pr);
+			}
+                }
+		dbus_message_unref(message);
+	}
 	dbus_pending_call_unref(call);
-
-	return;
-
-error:
-	hci_send_cmd(req->dev, OGF_LINK_CTL,
-				OCF_PIN_CODE_NEG_REPLY, 6, &req->bda);
 }
 
 static void free_pin_req(void *req)

Marcel Holtmann

maintainer

2005-09-15 08:11 UTC #16 lore raw

Re: [Bluez-devel] HCID D-Bus (Seg Fault)

Hi Claudio,

Quoted 1 line

sorry. It's done!

patch is in, but next time also use tabs for the second line of this:

	hci_send_cmd(req->dev, OGF_LINK_CTL,
	             OCF_PIN_CODE_NEG_REPLY, 6, &req->bda);

No spaces for indentation at all.

Regards

Marcel