* [Bluez-users] pairing on x86_64 @ 2004-02-21 11:52 Volker Fritzsch 2004-02-21 12:09 ` Marcel Holtmann 0 siblings, 1 reply; 11+ messages in thread From: Volker Fritzsch @ 2004-02-21 11:52 UTC (permalink / raw) To: bluez-users Hi. I've got an athlon64, a pda and a bluetooth usb dongle. Pairing under debian unstable (32bit) works fine, but under suse 9.0 (amd64) or the debian pure64 port it doesn't work. I've tried selfcompiled kernels (2.4's up to 2.6.3), suse's kernels; i've tried selfcompiled bluez libraries (and utils) as well as those shipped with the above mentioned distributions. When working in 64bit mode, pairing always seems to 'time out'. hcidump: HCIDump - HCI packet analyzer ver 1.5 device: hci0 snap_len: 1028 filter: 0xffffffffffffffff > HCI Event: Connect Request(0x04) plen 10 < HCI Command: Accept Connection Request(0x01|0x0009) plen 7 > HCI Event: Command Status(0x0f) plen 4 > HCI Event: Connect Complete(0x03) plen 11 < HCI Command: Write Link Policy Settings(0x02|0x000d) plen 4 > HCI Event: Page Scan Repetition Mode Change(0x20) plen 7 > HCI Event: Max Slots Change(0x1b) plen 3 > HCI Event: Command Complete(0x0e) plen 6 < HCI Command: Change Connection Packet Type(0x01|0x000f) plen 4 > HCI Event: Command Status(0x0f) plen 4 > HCI Event: Connection Packet Type Changed(0x1d) plen 5 > HCI Event: PIN Code Request(0x16) plen 6 and that's where it stops - and some time after that my pda aborts the connection. has anyone managed to get pairing working under x86_64? thanks in advance, Volker ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Bluez-users mailing list Bluez-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-users ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Bluez-users] pairing on x86_64 2004-02-21 11:52 [Bluez-users] pairing on x86_64 Volker Fritzsch @ 2004-02-21 12:09 ` Marcel Holtmann 2004-02-21 13:34 ` Volker 0 siblings, 1 reply; 11+ messages in thread From: Marcel Holtmann @ 2004-02-21 12:09 UTC (permalink / raw) To: Volker Fritzsch; +Cc: BlueZ Mailing List Hi Volker, > I've got an athlon64, a pda and a bluetooth usb dongle. > Pairing under debian unstable (32bit) works fine, > but under suse 9.0 (amd64) or the debian pure64 port it doesn't work. > > I've tried selfcompiled kernels (2.4's up to 2.6.3), suse's kernels; > i've tried selfcompiled bluez libraries (and utils) as well as those shipped > with the above mentioned distributions. > > When working in 64bit mode, pairing always seems to 'time out'. > > hcidump: > > HCIDump - HCI packet analyzer ver 1.5 > device: hci0 snap_len: 1028 filter: 0xffffffffffffffff > > HCI Event: Connect Request(0x04) plen 10 > < HCI Command: Accept Connection Request(0x01|0x0009) plen 7 > > HCI Event: Command Status(0x0f) plen 4 > > HCI Event: Connect Complete(0x03) plen 11 > < HCI Command: Write Link Policy Settings(0x02|0x000d) plen 4 > > HCI Event: Page Scan Repetition Mode Change(0x20) plen 7 > > HCI Event: Max Slots Change(0x1b) plen 3 > > HCI Event: Command Complete(0x0e) plen 6 > < HCI Command: Change Connection Packet Type(0x01|0x000f) plen 4 > > HCI Event: Command Status(0x0f) plen 4 > > HCI Event: Connection Packet Type Changed(0x1d) plen 5 > > HCI Event: PIN Code Request(0x16) plen 6 > > and that's where it stops - and some time after that my pda aborts the > connection. what does your syslog say? Put some syslog() debugging messages in utils/hcid/security.c to see where it stops. Regards Marcel ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Bluez-users mailing list Bluez-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-users ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Bluez-users] pairing on x86_64 2004-02-21 12:09 ` Marcel Holtmann @ 2004-02-21 13:34 ` Volker 2004-02-21 13:56 ` Marcel Holtmann 0 siblings, 1 reply; 11+ messages in thread From: Volker @ 2004-02-21 13:34 UTC (permalink / raw) To: Marcel Holtmann; +Cc: BlueZ Mailing List On Saturday 21 February 2004 13:09, Marcel Holtmann wrote: > what does your syslog say? Put some syslog() debugging messages in > utils/hcid/security.c to see where it stops. security.c loads the right pin at startup. during pairing, it enters gboolean io_security_event(GIOChannel *chan, GIOCondition cond, gpointer data) and leaves the method at this point: if (type != HCI_EVENT_PKT) { syslog(LOG_INFO, "** type not HCI_EVENT_PKT"); return TRUE; } any more points, where I should've a look at? Volker ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Bluez-users] pairing on x86_64 2004-02-21 13:34 ` Volker @ 2004-02-21 13:56 ` Marcel Holtmann 2004-02-21 14:08 ` Volker Fritzsch 0 siblings, 1 reply; 11+ messages in thread From: Marcel Holtmann @ 2004-02-21 13:56 UTC (permalink / raw) To: Volker; +Cc: BlueZ Mailing List [-- Attachment #1: Type: text/plain, Size: 456 bytes --] Hi Volker, > security.c loads the right pin at startup. > during pairing, it enters > > gboolean io_security_event(GIOChannel *chan, GIOCondition cond, gpointer data) > > and leaves the method at this point: > > if (type != HCI_EVENT_PKT) { > syslog(LOG_INFO, "** type not HCI_EVENT_PKT"); > return TRUE; > } > > any more points, where I should've a look at? try the attached patch. Regards Marcel [-- Attachment #2: patch --] [-- Type: text/x-patch, Size: 393 bytes --] diff -urN utils/hcid/security.c utils-mh/hcid/security.c --- utils/hcid/security.c 2004-02-17 19:34:30.000000000 +0100 +++ utils-mh/hcid/security.c 2004-02-21 14:54:37.000000000 +0100 @@ -367,7 +367,8 @@ { char buf[HCI_MAX_EVENT_SIZE], *ptr = buf; struct hci_dev_info *di = (void *) data; - int len, type, dev; + unsigned char type; + int len, dev; hci_event_hdr *eh; GIOError err; ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Bluez-users] pairing on x86_64 2004-02-21 13:56 ` Marcel Holtmann @ 2004-02-21 14:08 ` Volker Fritzsch 2004-02-21 14:18 ` Marcel Holtmann 0 siblings, 1 reply; 11+ messages in thread From: Volker Fritzsch @ 2004-02-21 14:08 UTC (permalink / raw) To: Marcel Holtmann; +Cc: BlueZ Mailing List Hi Marcel, > try the attached patch. unfortunatly, the patch didn't fix it. I've added some more syslog() calls to security.c: type = *ptr++; syslog(LOG_INFO, "** type is %s", type); if (type == HCI_EVENT_PKT) { syslog(LOG_INFO, "** type is HCI_EVENT_PKT"); } if (type == HCI_COMMAND_PKT) { syslog(LOG_INFO, "** type is HCI_COMMAND_PKT"); } if (type == HCI_ACLDATA_PKT) { syslog(LOG_INFO, "** type is HCI_ACLDATA_PKT"); } if (type == HCI_SCODATA_PKT) { syslog(LOG_INFO, "** type is HCI_SCODATA_PKT"); } if (type == HCI_UNKNOWN_PKT) { syslog(LOG_INFO, "** type is HCI_UNKNOWN_PKT"); } if (type != HCI_EVENT_PKT) { syslog(LOG_INFO, "** type not HCI_EVENT_PKT"); return TRUE; } now it says: '** type is (null)' (without your patch and with syslog(LOG_INFO, "** type is %d", type); it was '** type is 0' ) thanks, Volker ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Bluez-users] pairing on x86_64 2004-02-21 14:08 ` Volker Fritzsch @ 2004-02-21 14:18 ` Marcel Holtmann 2004-02-21 15:48 ` Volker Fritzsch 0 siblings, 1 reply; 11+ messages in thread From: Marcel Holtmann @ 2004-02-21 14:18 UTC (permalink / raw) To: Volker Fritzsch; +Cc: BlueZ Mailing List [-- Attachment #1: Type: text/plain, Size: 94 bytes --] Hi Volker, > unfortunatly, the patch didn't fix it. maybe this one helps. Regards Marcel [-- Attachment #2: patch --] [-- Type: text/x-patch, Size: 720 bytes --] diff -urN utils/hcid/security.c utils-mh/hcid/security.c --- utils/hcid/security.c 2004-02-17 19:34:30.000000000 +0100 +++ utils-mh/hcid/security.c 2004-02-21 15:15:53.000000000 +0100 @@ -365,9 +365,9 @@ gboolean io_security_event(GIOChannel *chan, GIOCondition cond, gpointer data) { - char buf[HCI_MAX_EVENT_SIZE], *ptr = buf; + unsigned char buf[HCI_MAX_EVENT_SIZE], *ptr = buf; struct hci_dev_info *di = (void *) data; - int len, type, dev; + int len, dev; hci_event_hdr *eh; GIOError err; @@ -385,11 +385,11 @@ return FALSE; } - type = *ptr++; - - if (type != HCI_EVENT_PKT) + if (buf[0] != HCI_EVENT_PKT) return TRUE; + ptr++; + eh = (hci_event_hdr *) ptr; ptr += HCI_EVENT_HDR_SIZE; ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Bluez-users] pairing on x86_64 2004-02-21 14:18 ` Marcel Holtmann @ 2004-02-21 15:48 ` Volker Fritzsch 2004-02-21 16:11 ` Marcel Holtmann 0 siblings, 1 reply; 11+ messages in thread From: Volker Fritzsch @ 2004-02-21 15:48 UTC (permalink / raw) To: Marcel Holtmann; +Cc: BlueZ Mailing List [-- Attachment #1: Type: text/plain, Size: 2574 bytes --] Hi Marcel, > maybe this one helps. neither did this :( so I had a deeper look into it myself. It seemed, as if the first four chars of buf get blanked after leaving g_io_channel_read. have a look at my syslog below: Feb 21 16:13:57 dionysos hcid[5088]: ** io_security_event Feb 21 16:13:57 dionysos hcid[5088]: glib-ectomy * buf[0]: 4 Feb 21 16:13:57 dionysos hcid[5088]: glib-ectomy * buf[1]: 22 Feb 21 16:13:57 dionysos hcid[5088]: glib-ectomy * buf[2]: 6 Feb 21 16:13:57 dionysos hcid[5088]: glib-ectomy * buf[3]: 121 Feb 21 16:13:57 dionysos hcid[5088]: glib-ectomy * buf[4]: -109 Feb 21 16:13:57 dionysos hcid[5088]: glib-ectomy * buf[5]: 50 Feb 21 16:13:57 dionysos hcid[5088]: glib-ectomy * buf[6]: -32 Feb 21 16:13:57 dionysos hcid[5088]: glib-ectomy * buf[7]: 7 Feb 21 16:13:57 dionysos hcid[5088]: glib-ectomy * buf[8]: 0 Feb 21 16:13:57 dionysos hcid[5088]: glib-ectomy * buf points to: -1073745232 Feb 21 16:13:57 dionysos hcid[5088]: security * buf[0] = 0 Feb 21 16:13:57 dionysos hcid[5088]: security * buf[1] = 0 Feb 21 16:13:57 dionysos hcid[5088]: security * buf[2] = 0 Feb 21 16:13:57 dionysos hcid[5088]: security * buf[3] = 0 Feb 21 16:13:57 dionysos hcid[5088]: security * buf[4] = -109 Feb 21 16:13:57 dionysos hcid[5088]: security * buf[5] = 50 Feb 21 16:13:57 dionysos hcid[5088]: security * buf[6] = -32 Feb 21 16:13:57 dionysos hcid[5088]: security * buf[7] = 7 Feb 21 16:13:57 dionysos hcid[5088]: security * buf[8] = 0 Feb 21 16:13:57 dionysos hcid[5088]: security * buf points to -1073745232 Feb 21 16:13:57 dionysos hcid[5088]: ** type not HCI_EVENT_PKT the appended patch does work for me - at least at this point, because now I get the following from hcidump: HCIDump - HCI packet analyzer ver 1.5 device: hci0 snap_len: 1028 filter: 0xffffffffffffffff > HCI Event: Connect Request(0x04) plen 10 < HCI Command: Accept Connection Request(0x01|0x0009) plen 7 > HCI Event: Command Status(0x0f) plen 4 > HCI Event: Connect Complete(0x03) plen 11 < HCI Command: Write Link Policy Settings(0x02|0x000d) plen 4 > HCI Event: Page Scan Repetition Mode Change(0x20) plen 7 > HCI Event: Max Slots Change(0x1b) plen 3 > HCI Event: Command Complete(0x0e) plen 6 < HCI Command: Change Connection Packet Type(0x01|0x000f) plen 4 > HCI Event: Command Status(0x0f) plen 4 > HCI Event: Connection Packet Type Changed(0x1d) plen 5 > HCI Event: PIN Code Request(0x16) plen 6 < HCI Command: PIN Code Request Negative Reply(0x01|0x000e) plen 6 > HCI Event: Command Complete(0x0e) plen 10 I'll have a deeper look into that issue later today. Yours, Volker [-- Attachment #2: patch --] [-- Type: text/x-diff, Size: 447 bytes --] --- ../orig/bluez-utils-2.4/hcid/security.c 2003-07-24 19:34:34.000000000 +0200 +++ hcid/security.c 2004-02-21 16:22:01.278360248 +0100 @@ -354,7 +354,8 @@ gboolean io_security_event(GIOChannel *chan, GIOCondition cond, gpointer data) { - char buf[HCI_MAX_EVENT_SIZE], *ptr = buf; + char *buf = malloc(sizeof(char) * HCI_MAX_EVENT_SIZE); + char *ptr = buf; struct hci_dev_info *di = (void *) data; int len, type, dev; hci_event_hdr *eh; ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Bluez-users] pairing on x86_64 2004-02-21 15:48 ` Volker Fritzsch @ 2004-02-21 16:11 ` Marcel Holtmann 2004-02-21 20:00 ` Volker Fritzsch 0 siblings, 1 reply; 11+ messages in thread From: Marcel Holtmann @ 2004-02-21 16:11 UTC (permalink / raw) To: Volker Fritzsch; +Cc: BlueZ Mailing List Hi Volker, > so I had a deeper look into it myself. > It seemed, as if the first four chars of buf get blanked after leaving > g_io_channel_read. what is the sizeof(unsigned char) and sizeof(char) on x86_64? > Feb 21 16:13:57 dionysos hcid[5088]: ** io_security_event > Feb 21 16:13:57 dionysos hcid[5088]: glib-ectomy * buf[0]: 4 > Feb 21 16:13:57 dionysos hcid[5088]: glib-ectomy * buf[1]: 22 > Feb 21 16:13:57 dionysos hcid[5088]: glib-ectomy * buf[2]: 6 > Feb 21 16:13:57 dionysos hcid[5088]: glib-ectomy * buf[3]: 121 > Feb 21 16:13:57 dionysos hcid[5088]: glib-ectomy * buf[4]: -109 > Feb 21 16:13:57 dionysos hcid[5088]: glib-ectomy * buf[5]: 50 > Feb 21 16:13:57 dionysos hcid[5088]: glib-ectomy * buf[6]: -32 > Feb 21 16:13:57 dionysos hcid[5088]: glib-ectomy * buf[7]: 7 > Feb 21 16:13:57 dionysos hcid[5088]: glib-ectomy * buf[8]: 0 > Feb 21 16:13:57 dionysos hcid[5088]: glib-ectomy * buf points to: -1073745232 > Feb 21 16:13:57 dionysos hcid[5088]: security * buf[0] = 0 > Feb 21 16:13:57 dionysos hcid[5088]: security * buf[1] = 0 > Feb 21 16:13:57 dionysos hcid[5088]: security * buf[2] = 0 > Feb 21 16:13:57 dionysos hcid[5088]: security * buf[3] = 0 > Feb 21 16:13:57 dionysos hcid[5088]: security * buf[4] = -109 > Feb 21 16:13:57 dionysos hcid[5088]: security * buf[5] = 50 > Feb 21 16:13:57 dionysos hcid[5088]: security * buf[6] = -32 > Feb 21 16:13:57 dionysos hcid[5088]: security * buf[7] = 7 > Feb 21 16:13:57 dionysos hcid[5088]: security * buf[8] = 0 > Feb 21 16:13:57 dionysos hcid[5088]: security * buf points to -1073745232 > Feb 21 16:13:57 dionysos hcid[5088]: ** type not HCI_EVENT_PKT I don't know why this happens. > the appended patch does work for me - at least at this point, > because now I get the following from hcidump: We should use a static buffer and it should be unsigned char. > HCIDump - HCI packet analyzer ver 1.5 > device: hci0 snap_len: 1028 filter: 0xffffffffffffffff > > HCI Event: Connect Request(0x04) plen 10 > < HCI Command: Accept Connection Request(0x01|0x0009) plen 7 > > HCI Event: Command Status(0x0f) plen 4 > > HCI Event: Connect Complete(0x03) plen 11 > < HCI Command: Write Link Policy Settings(0x02|0x000d) plen 4 > > HCI Event: Page Scan Repetition Mode Change(0x20) plen 7 > > HCI Event: Max Slots Change(0x1b) plen 3 > > HCI Event: Command Complete(0x0e) plen 6 > < HCI Command: Change Connection Packet Type(0x01|0x000f) plen 4 > > HCI Event: Command Status(0x0f) plen 4 > > HCI Event: Connection Packet Type Changed(0x1d) plen 5 > > HCI Event: PIN Code Request(0x16) plen 6 > < HCI Command: PIN Code Request Negative Reply(0x01|0x000e) plen 6 > > HCI Event: Command Complete(0x0e) plen 10 This can be a problem that the call of the PIN helper program fails. Regards Marcel ------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click _______________________________________________ Bluez-users mailing list Bluez-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-users ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Bluez-users] pairing on x86_64 2004-02-21 16:11 ` Marcel Holtmann @ 2004-02-21 20:00 ` Volker Fritzsch 2004-02-22 2:15 ` Marcel Holtmann 0 siblings, 1 reply; 11+ messages in thread From: Volker Fritzsch @ 2004-02-21 20:00 UTC (permalink / raw) To: Marcel Holtmann; +Cc: BlueZ Mailing List [-- Attachment #1: Type: text/plain, Size: 2184 bytes --] Hi Marcel. > what is the sizeof(unsigned char) and sizeof(char) on x86_64? printf says 1 (for both). > > Feb 21 16:13:57 dionysos hcid[5088]: ** io_security_event > > Feb 21 16:13:57 dionysos hcid[5088]: glib-ectomy * buf[0]: 4 > > Feb 21 16:13:57 dionysos hcid[5088]: glib-ectomy * buf[1]: 22 > > Feb 21 16:13:57 dionysos hcid[5088]: glib-ectomy * buf[2]: 6 > > Feb 21 16:13:57 dionysos hcid[5088]: glib-ectomy * buf[3]: 121 > > Feb 21 16:13:57 dionysos hcid[5088]: glib-ectomy * buf[4]: -109 > > Feb 21 16:13:57 dionysos hcid[5088]: glib-ectomy * buf[5]: 50 > > Feb 21 16:13:57 dionysos hcid[5088]: glib-ectomy * buf[6]: -32 > > Feb 21 16:13:57 dionysos hcid[5088]: glib-ectomy * buf[7]: 7 > > Feb 21 16:13:57 dionysos hcid[5088]: glib-ectomy * buf[8]: 0 > > Feb 21 16:13:57 dionysos hcid[5088]: glib-ectomy * buf points to: > > -1073745232 Feb 21 16:13:57 dionysos hcid[5088]: security * buf[0] = 0 > > Feb 21 16:13:57 dionysos hcid[5088]: security * buf[1] = 0 > > Feb 21 16:13:57 dionysos hcid[5088]: security * buf[2] = 0 > > Feb 21 16:13:57 dionysos hcid[5088]: security * buf[3] = 0 > > Feb 21 16:13:57 dionysos hcid[5088]: security * buf[4] = -109 > > Feb 21 16:13:57 dionysos hcid[5088]: security * buf[5] = 50 > > Feb 21 16:13:57 dionysos hcid[5088]: security * buf[6] = -32 > > Feb 21 16:13:57 dionysos hcid[5088]: security * buf[7] = 7 > > Feb 21 16:13:57 dionysos hcid[5088]: security * buf[8] = 0 > > Feb 21 16:13:57 dionysos hcid[5088]: security * buf points to -1073745232 > > Feb 21 16:13:57 dionysos hcid[5088]: ** type not HCI_EVENT_PKT > > I don't know why this happens. I couldn't understand too, but with your sizeof(char) question you made me curious. On x86_64, int has a size of 4 and size_t takes 8 (while on x86 both have a size of 4). By passing &len to g_io_channel_read (which takes a size_t *buffer_read as argument), we blank out the first four bytes of buf - which sits directly after len in memory ('oh wonderful world...'). > This can be a problem that the call of the PIN helper program fails. This problem is also solved with the change from int len to size_t len. So, please trash my first patch and take this instead. Regards Volker [-- Attachment #2: patch --] [-- Type: text/x-diff, Size: 338 bytes --] --- ../orig/bluez-utils-2.4/hcid/security.c 2003-07-24 19:34:34.000000000 +0200 +++ hcid/security.c 2004-02-21 20:47:35.000000000 +0100 @@ -356,7 +356,8 @@ { char buf[HCI_MAX_EVENT_SIZE], *ptr = buf; struct hci_dev_info *di = (void *) data; - int len, type, dev; + int type, dev; + size_t len; hci_event_hdr *eh; GIOError err; ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Bluez-users] pairing on x86_64 2004-02-21 20:00 ` Volker Fritzsch @ 2004-02-22 2:15 ` Marcel Holtmann 2004-02-22 13:24 ` Volker Fritzsch 0 siblings, 1 reply; 11+ messages in thread From: Marcel Holtmann @ 2004-02-22 2:15 UTC (permalink / raw) To: Volker Fritzsch; +Cc: BlueZ Mailing List [-- Attachment #1: Type: text/plain, Size: 689 bytes --] Hi Volker, > I couldn't understand too, but with your sizeof(char) question you made me > curious. > > On x86_64, int has a size of 4 and size_t takes 8 (while on x86 both have a > size of 4). > By passing &len to g_io_channel_read (which takes a size_t *buffer_read as > argument), we blank out the first four bytes of buf - which sits directly > after len in memory ('oh wonderful world...'). > > > This can be a problem that the call of the PIN helper program fails. > This problem is also solved with the change from int len to size_t len. > > So, please trash my first patch and take this instead. and here is the patch I am going to apply. Please test it. Regards Marcel [-- Attachment #2: patch --] [-- Type: text/x-patch, Size: 1206 bytes --] Index: hcid/main.c =================================================================== RCS file: /cvsroot/bluez/utils/hcid/main.c,v retrieving revision 1.11 diff -u -r1.11 main.c --- hcid/main.c 17 Feb 2004 18:04:03 -0000 1.11 +++ hcid/main.c 22 Feb 2004 02:09:29 -0000 @@ -397,10 +397,11 @@ gboolean io_stack_event(GIOChannel *chan, GIOCondition cond, gpointer data) { - char buf[HCI_MAX_FRAME_SIZE], *ptr; + unsigned char buf[HCI_MAX_FRAME_SIZE], *ptr; evt_stack_internal *si; hci_event_hdr *eh; - int len, type; + int type; + size_t len; GIOError err; ptr = buf; Index: hcid/security.c =================================================================== RCS file: /cvsroot/bluez/utils/hcid/security.c,v retrieving revision 1.9 diff -u -r1.9 security.c --- hcid/security.c 17 Feb 2004 18:04:03 -0000 1.9 +++ hcid/security.c 22 Feb 2004 02:09:29 -0000 @@ -365,9 +365,10 @@ gboolean io_security_event(GIOChannel *chan, GIOCondition cond, gpointer data) { - char buf[HCI_MAX_EVENT_SIZE], *ptr = buf; + unsigned char buf[HCI_MAX_EVENT_SIZE], *ptr = buf; struct hci_dev_info *di = (void *) data; - int len, type, dev; + int type, dev; + size_t len; hci_event_hdr *eh; GIOError err; ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Bluez-users] pairing on x86_64 2004-02-22 2:15 ` Marcel Holtmann @ 2004-02-22 13:24 ` Volker Fritzsch 0 siblings, 0 replies; 11+ messages in thread From: Volker Fritzsch @ 2004-02-22 13:24 UTC (permalink / raw) To: Marcel Holtmann; +Cc: BlueZ Mailing List Hi Marcel, > and here is the patch I am going to apply. Please test it. It works ;) Yours, Volker ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2004-02-22 13:24 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2004-02-21 11:52 [Bluez-users] pairing on x86_64 Volker Fritzsch 2004-02-21 12:09 ` Marcel Holtmann 2004-02-21 13:34 ` Volker 2004-02-21 13:56 ` Marcel Holtmann 2004-02-21 14:08 ` Volker Fritzsch 2004-02-21 14:18 ` Marcel Holtmann 2004-02-21 15:48 ` Volker Fritzsch 2004-02-21 16:11 ` Marcel Holtmann 2004-02-21 20:00 ` Volker Fritzsch 2004-02-22 2:15 ` Marcel Holtmann 2004-02-22 13:24 ` Volker Fritzsch
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox