* Re: [PATCH 5/5]bluetooth:hci_bcsp Fix operation on 'bcsp->msgq_txseq' may be undefined
From: Bernd Petrovitsch @ 2010-06-28 13:02 UTC (permalink / raw)
To: David Howells
Cc: Justin P. Mattock, Gustavo F. Padovan, linux-kernel, sds, lenb,
linux-bluetooth
In-Reply-To: <7323.1277729576@redhat.com>
On Mon, 2010-06-28 at 13:52 +0100, David Howells wrote:
> Justin P. Mattock <justinmattock@gmail.com> wrote:
>
> > - BT_DBG("Sending packet with seqno %u", bcsp->msgq_txseq);
> > - bcsp->msgq_txseq = ++(bcsp->msgq_txseq) & 0x07;
> > + BT_DBG("Sending packet with seqno %u", bcsp->msgq_txseq | ret);
> > + ret = ++(bcsp->msgq_txseq) & 0x07;
>
> I don't know what you're trying to do here, but you seem to be trying to send
> the computed value back in time.
>
> The problem is that the compiler is confused about why a '++' operator makes
It's even worse as that expression is explicitly undefined (and should
be fixed anyways and unconditionally).
> any sense here. It doesn't. It should be a '+ 1' instead. I think what you
> want is:
>
> - bcsp->msgq_txseq = ++(bcsp->msgq_txseq) & 0x07;
> + bcsp->msgq_txseq = (bcsp->msgq_txseq + 1) & 0x07;
Yes, that's looks like the most probable intention of it - at least for
one who doesn't know the bluetooth code.
Bernd
--
Bernd Petrovitsch Email : bernd@petrovitsch.priv.at
LUGA : http://www.luga.at
^ permalink raw reply
* [PATCH] Bluetooth: Fix abuse of the preincrement operator
From: David Howells @ 2010-06-28 12:57 UTC (permalink / raw)
To: linux-bluetooth; +Cc: justinmattock, dhowells, linux-kernel, gustavo
In-Reply-To: <1277621246-10960-6-git-send-email-justinmattock@gmail.com>
Fix abuse of the preincrement operator as detected when building with gcc
4.6.0:
CC [M] drivers/bluetooth/hci_bcsp.o
drivers/bluetooth/hci_bcsp.c: In function 'bcsp_prepare_pkt':
drivers/bluetooth/hci_bcsp.c:247:20: warning: operation on 'bcsp->msgq_txseq' may be undefined
Reported-by: Justin P. Mattock <justinmattock@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
---
drivers/bluetooth/hci_bcsp.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/bluetooth/hci_bcsp.c b/drivers/bluetooth/hci_bcsp.c
index 40aec0f..42d69d4 100644
--- a/drivers/bluetooth/hci_bcsp.c
+++ b/drivers/bluetooth/hci_bcsp.c
@@ -244,7 +244,7 @@ static struct sk_buff *bcsp_prepare_pkt(struct bcsp_struct *bcsp, u8 *data,
if (rel) {
hdr[0] |= 0x80 + bcsp->msgq_txseq;
BT_DBG("Sending packet with seqno %u", bcsp->msgq_txseq);
- bcsp->msgq_txseq = ++(bcsp->msgq_txseq) & 0x07;
+ bcsp->msgq_txseq = (bcsp->msgq_txseq + 1) & 0x07;
}
if (bcsp->use_crc)
^ permalink raw reply related
* Re: [PATCH 5/5]bluetooth:hci_bcsp Fix operation on 'bcsp->msgq_txseq' may be undefined
From: David Howells @ 2010-06-28 12:52 UTC (permalink / raw)
To: Justin P. Mattock, Gustavo F. Padovan
Cc: dhowells, linux-kernel, sds, lenb, linux-bluetooth
In-Reply-To: <1277621246-10960-6-git-send-email-justinmattock@gmail.com>
Justin P. Mattock <justinmattock@gmail.com> wrote:
> - BT_DBG("Sending packet with seqno %u", bcsp->msgq_txseq);
> - bcsp->msgq_txseq = ++(bcsp->msgq_txseq) & 0x07;
> + BT_DBG("Sending packet with seqno %u", bcsp->msgq_txseq | ret);
> + ret = ++(bcsp->msgq_txseq) & 0x07;
I don't know what you're trying to do here, but you seem to be trying to send
the computed value back in time.
The problem is that the compiler is confused about why a '++' operator makes
any sense here. It doesn't. It should be a '+ 1' instead. I think what you
want is:
- bcsp->msgq_txseq = ++(bcsp->msgq_txseq) & 0x07;
+ bcsp->msgq_txseq = (bcsp->msgq_txseq + 1) & 0x07;
David
^ permalink raw reply
* Re: [PATCH 1/1] Bluetooth: hidp: Add support for hidraw HIDIOCGFEATURE and HIDIOCSFEATURE
From: Antonio Ospite @ 2010-06-28 11:14 UTC (permalink / raw)
To: Alan Ott
Cc: Marcel Holtmann, David S Miller, Jiri Kosina, Michael Poole,
Bastien Nocera, Eric Dumazet, linux-bluetooth, linux-kernel,
netdev
In-Reply-To: <1276467601-9066-1-git-send-email-alan@signal11.us>
[-- Attachment #1: Type: text/plain, Size: 8758 bytes --]
On Sun, 13 Jun 2010 18:20:01 -0400
Alan Ott <alan@signal11.us> wrote:
> This patch adds support or getting and setting feature reports for bluetooth
> HID devices from HIDRAW.
>
> Signed-off-by: Alan Ott <alan@signal11.us>
> ---
Ping.
> net/bluetooth/hidp/core.c | 121 +++++++++++++++++++++++++++++++++++++++++++--
> net/bluetooth/hidp/hidp.h | 8 +++
> 2 files changed, 125 insertions(+), 4 deletions(-)
>
> diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c
> index bfe641b..0f068a0 100644
> --- a/net/bluetooth/hidp/core.c
> +++ b/net/bluetooth/hidp/core.c
> @@ -36,6 +36,7 @@
> #include <linux/file.h>
> #include <linux/init.h>
> #include <linux/wait.h>
> +#include <linux/mutex.h>
> #include <net/sock.h>
>
> #include <linux/input.h>
> @@ -313,6 +314,93 @@ static int hidp_send_report(struct hidp_session *session, struct hid_report *rep
> return hidp_queue_report(session, buf, rsize);
> }
>
> +static int hidp_get_raw_report(struct hid_device *hid,
> + unsigned char report_number,
> + unsigned char *data, size_t count,
> + unsigned char report_type)
> +{
> + struct hidp_session *session = hid->driver_data;
> + struct sk_buff *skb;
> + size_t len;
> + int numbered_reports = hid->report_enum[report_type].numbered;
> +
> + switch (report_type) {
> + case HID_FEATURE_REPORT:
> + report_type = HIDP_TRANS_GET_REPORT | HIDP_DATA_RTYPE_FEATURE;
> + break;
> + case HID_INPUT_REPORT:
> + report_type = HIDP_TRANS_GET_REPORT | HIDP_DATA_RTYPE_INPUT;
> + break;
> + case HID_OUTPUT_REPORT:
> + report_type = HIDP_TRANS_GET_REPORT | HIDP_DATA_RTYPE_OUPUT;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + if (mutex_lock_interruptible(&session->report_mutex))
> + return -ERESTARTSYS;
> +
> + /* Set up our wait, and send the report request to the device. */
> + session->waiting_report_type = report_type & HIDP_DATA_RTYPE_MASK;
> + session->waiting_report_number = numbered_reports ? report_number : -1;
> + set_bit(HIDP_WAITING_FOR_RETURN, &session->flags);
> + data[0] = report_number;
> + if (hidp_send_ctrl_message(hid->driver_data, report_type, data, 1))
> + goto err_eio;
> +
> + /* Wait for the return of the report. The returned report
> + gets put in session->report_return. */
> + while (test_bit(HIDP_WAITING_FOR_RETURN, &session->flags)) {
> + int res;
> +
> + res = wait_event_interruptible_timeout(session->report_queue,
> + !test_bit(HIDP_WAITING_FOR_RETURN, &session->flags),
> + 5*HZ);
> + if (res == 0) {
> + /* timeout */
> + goto err_eio;
> + }
> + if (res < 0) {
> + /* signal */
> + goto err_restartsys;
> + }
> + }
> +
> + skb = session->report_return;
> + if (skb) {
> + if (numbered_reports) {
> + /* Strip off the report number. */
> + size_t rpt_len = skb->len-1;
> + len = rpt_len < count ? rpt_len : count;
> + memcpy(data, skb->data+1, len);
> + } else {
> + len = skb->len < count ? skb->len : count;
> + memcpy(data, skb->data, len);
> + }
> +
> + kfree_skb(skb);
> + session->report_return = NULL;
> + } else {
> + /* Device returned a HANDSHAKE, indicating protocol error. */
> + len = -EIO;
> + }
> +
> + clear_bit(HIDP_WAITING_FOR_RETURN, &session->flags);
> + mutex_unlock(&session->report_mutex);
> +
> + return len;
> +
> +err_restartsys:
> + clear_bit(HIDP_WAITING_FOR_RETURN, &session->flags);
> + mutex_unlock(&session->report_mutex);
> + return -ERESTARTSYS;
> +err_eio:
> + clear_bit(HIDP_WAITING_FOR_RETURN, &session->flags);
> + mutex_unlock(&session->report_mutex);
> + return -EIO;
> +}
> +
> static int hidp_output_raw_report(struct hid_device *hid, unsigned char *data, size_t count,
> unsigned char report_type)
> {
> @@ -367,6 +455,10 @@ static void hidp_process_handshake(struct hidp_session *session,
> case HIDP_HSHK_ERR_INVALID_REPORT_ID:
> case HIDP_HSHK_ERR_UNSUPPORTED_REQUEST:
> case HIDP_HSHK_ERR_INVALID_PARAMETER:
> + if (test_bit(HIDP_WAITING_FOR_RETURN, &session->flags)) {
> + clear_bit(HIDP_WAITING_FOR_RETURN, &session->flags);
> + wake_up_interruptible(&session->report_queue);
> + }
> /* FIXME: Call into SET_ GET_ handlers here */
> break;
>
> @@ -403,9 +495,11 @@ static void hidp_process_hid_control(struct hidp_session *session,
> }
> }
>
> -static void hidp_process_data(struct hidp_session *session, struct sk_buff *skb,
> +/* Returns true if the passed-in skb should be freed by the caller. */
> +static int hidp_process_data(struct hidp_session *session, struct sk_buff *skb,
> unsigned char param)
> {
> + int done_with_skb = 1;
> BT_DBG("session %p skb %p len %d param 0x%02x", session, skb, skb->len, param);
>
> switch (param) {
> @@ -417,7 +511,6 @@ static void hidp_process_data(struct hidp_session *session, struct sk_buff *skb,
>
> if (session->hid)
> hid_input_report(session->hid, HID_INPUT_REPORT, skb->data, skb->len, 0);
> -
> break;
>
> case HIDP_DATA_RTYPE_OTHER:
> @@ -429,12 +522,27 @@ static void hidp_process_data(struct hidp_session *session, struct sk_buff *skb,
> __hidp_send_ctrl_message(session,
> HIDP_TRANS_HANDSHAKE | HIDP_HSHK_ERR_INVALID_PARAMETER, NULL, 0);
> }
> +
> + if (test_bit(HIDP_WAITING_FOR_RETURN, &session->flags) &&
> + param == session->waiting_report_type) {
> + if (session->waiting_report_number < 0 ||
> + session->waiting_report_number == skb->data[0]) {
> + /* hidp_get_raw_report() is waiting on this report. */
> + session->report_return = skb;
> + done_with_skb = 0;
> + clear_bit(HIDP_WAITING_FOR_RETURN, &session->flags);
> + wake_up_interruptible(&session->report_queue);
> + }
> + }
> +
> + return done_with_skb;
> }
>
> static void hidp_recv_ctrl_frame(struct hidp_session *session,
> struct sk_buff *skb)
> {
> unsigned char hdr, type, param;
> + int free_skb = 1;
>
> BT_DBG("session %p skb %p len %d", session, skb, skb->len);
>
> @@ -454,7 +562,7 @@ static void hidp_recv_ctrl_frame(struct hidp_session *session,
> break;
>
> case HIDP_TRANS_DATA:
> - hidp_process_data(session, skb, param);
> + free_skb = hidp_process_data(session, skb, param);
> break;
>
> default:
> @@ -463,7 +571,8 @@ static void hidp_recv_ctrl_frame(struct hidp_session *session,
> break;
> }
>
> - kfree_skb(skb);
> + if (free_skb)
> + kfree_skb(skb);
> }
>
> static void hidp_recv_intr_frame(struct hidp_session *session,
> @@ -797,6 +906,7 @@ static int hidp_setup_hid(struct hidp_session *session,
> hid->dev.parent = hidp_get_device(session);
> hid->ll_driver = &hidp_hid_driver;
>
> + hid->hid_get_raw_report = hidp_get_raw_report;
> hid->hid_output_raw_report = hidp_output_raw_report;
>
> err = hid_add_device(hid);
> @@ -857,6 +967,9 @@ int hidp_add_connection(struct hidp_connadd_req *req, struct socket *ctrl_sock,
> skb_queue_head_init(&session->ctrl_transmit);
> skb_queue_head_init(&session->intr_transmit);
>
> + mutex_init(&session->report_mutex);
> + init_waitqueue_head(&session->report_queue);
> +
> session->flags = req->flags & (1 << HIDP_BLUETOOTH_VENDOR_ID);
> session->idle_to = req->idle_to;
>
> diff --git a/net/bluetooth/hidp/hidp.h b/net/bluetooth/hidp/hidp.h
> index 8d934a1..00e71dd 100644
> --- a/net/bluetooth/hidp/hidp.h
> +++ b/net/bluetooth/hidp/hidp.h
> @@ -80,6 +80,7 @@
> #define HIDP_VIRTUAL_CABLE_UNPLUG 0
> #define HIDP_BOOT_PROTOCOL_MODE 1
> #define HIDP_BLUETOOTH_VENDOR_ID 9
> +#define HIDP_WAITING_FOR_RETURN 10
>
> struct hidp_connadd_req {
> int ctrl_sock; // Connected control socket
> @@ -154,6 +155,13 @@ struct hidp_session {
> struct sk_buff_head ctrl_transmit;
> struct sk_buff_head intr_transmit;
>
> + /* Used in hidp_get_raw_report() */
> + int waiting_report_type; /* HIDP_DATA_RTYPE_* */
> + int waiting_report_number; /* -1 for not numbered */
> + struct mutex report_mutex;
> + struct sk_buff *report_return;
> + wait_queue_head_t report_queue;
> +
> /* Report descriptor */
> __u8 *rd_data;
> uint rd_size;
> --
> 1.7.0.4
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Antonio Ospite
http://ao2.it
PGP public key ID: 0x4553B001
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH] Fix unblock removed device
From: Daniel Örstadius @ 2010-06-28 11:00 UTC (permalink / raw)
To: linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 242 bytes --]
This patch unblocks a device when removing it. Adds boolean argument
to function device_unblock to only emit property changed signal and
probe drivers when unblocking a device if the device is not unblocked
as part of being removed.
/Daniel
[-- Attachment #2: 0001-Fix-unblock-removed-device.patch --]
[-- Type: text/x-patch, Size: 2366 bytes --]
From 5da37821d8bcf47d0734e7d7aaa27d81c9102380 Mon Sep 17 00:00:00 2001
From: Daniel Orstadius <daniel.orstadius@gmail.com>
Date: Mon, 28 Jun 2010 13:45:37 +0300
Subject: [PATCH] Fix unblock removed device
Unblocks a device when removing it. Adds boolean argument to
function device_unblock to only emit property changed signal and
probe drivers when unblocking a device if the device is not
unblocked as part of being removed.
---
src/device.c | 16 +++++++++++-----
1 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/src/device.c b/src/device.c
index 11b1fd2..6deb4a2 100644
--- a/src/device.c
+++ b/src/device.c
@@ -513,7 +513,7 @@ static int device_block(DBusConnection *conn, struct btd_device *device)
return 0;
}
-static int device_unblock(DBusConnection *conn, struct btd_device *device)
+static int device_unblock(DBusConnection *conn, struct btd_device *device, gboolean silent)
{
int dev_id, dd, err;
bdaddr_t src;
@@ -543,10 +543,12 @@ static int device_unblock(DBusConnection *conn, struct btd_device *device)
if (err < 0)
error("write_blocked(): %s (%d)", strerror(-err), -err);
- emit_property_changed(conn, device->path, DEVICE_INTERFACE, "Blocked",
- DBUS_TYPE_BOOLEAN, &device->blocked);
+ if (!silent) {
+ emit_property_changed(conn, device->path, DEVICE_INTERFACE, "Blocked",
+ DBUS_TYPE_BOOLEAN, &device->blocked);
- device_probe_drivers(device, device->uuids);
+ device_probe_drivers(device, device->uuids);
+ }
return 0;
}
@@ -560,7 +562,7 @@ static DBusMessage *set_blocked(DBusConnection *conn, DBusMessage *msg,
if (value)
err = device_block(conn, device);
else
- err = device_unblock(conn, device);
+ err = device_unblock(conn, device, FALSE);
switch (-err) {
case 0:
@@ -1100,6 +1102,7 @@ static void device_remove_stored(struct btd_device *device)
{
bdaddr_t src;
char addr[18];
+ DBusConnection *conn = get_dbus_connection();
adapter_get_address(device->adapter, &src);
ba2str(&device->bdaddr, addr);
@@ -1109,6 +1112,9 @@ static void device_remove_stored(struct btd_device *device)
delete_entry(&src, "profiles", addr);
delete_entry(&src, "trusts", addr);
delete_all_records(&src, &device->bdaddr);
+
+ if (device->blocked)
+ device_unblock(conn, device, TRUE);
}
void device_remove(struct btd_device *device, gboolean remove_stored)
--
1.6.0.4
^ permalink raw reply related
* Re: obexd: cannot object-push certain files (large, w/ logs)
From: Luiz Augusto von Dentz @ 2010-06-28 7:52 UTC (permalink / raw)
To: clemens fischer; +Cc: linux-bluetooth
In-Reply-To: <20100627151712.GA4427@spotteswoode.de.eu.org>
Hi,
On Sun, Jun 27, 2010 at 6:17 PM, clemens fischer <ino-news@spott.ath.cx> wrote:
> 'uname -rims' -> Linux 2.6.34-spott i686 AuthenticAMD, obexd-0.28
>
> I cannot send certain files from my nokia-3650 cell phone to the linux
> PC. I first thought they were too big with a bit less than 200kB, but
> bigger files transfer fine. The problem is reproducable. The file in
> question is Contacts.cdb, 171.8kB in size. I have the feeling that it
> has to do with the type of file sent, but I have no idea what and where
> to check. The files that work can be sent over and over without
> problems, the ones that don't never do.
>
> Here's the debug output from obexd:
>
> 0 3 # /l/libexec/obexd -nd -r /home/toor/mobile/nokia-niels/obex/ -a -o
> obexd[8159]: Enabling debug information
> obexd[8159]: manager_init:
> obexd[8159]: Loading builtin plugins
> obexd[8159]: driver 0x805f554 transport bluetooth registered
> obexd[8159]: Plugin bluetooth loaded
> obexd[8159]: driver 0x805f570 transport usb registered
> obexd[8159]: Plugin usb loaded
> obexd[8159]: driver 0x805f5a0 mimetype x-obex/folder-listing registered
> obexd[8159]: driver 0x805f5e0 mimetype x-obex/capability registered
> obexd[8159]: driver 0x805f660 mimetype x-obex/folder-listing registered
> obexd[8159]: driver 0x805f620 mimetype (null) registered
> obexd[8159]: Plugin filesystem loaded
> obexd[8159]: driver 0x805f6c0 mimetype application/vnd.nokia-backup registered
> obexd[8159]: Plugin backup loaded
> obexd[8159]: driver 0x805f720 service Object Push server registered
> obexd[8159]: Plugin opp loaded
> obexd[8159]: driver 0x805f780 service File Transfer server registered
> obexd[8159]: driver 0x805f7c0 service Nokia OBEX PC Suite Services registered
> obexd[8159]: Plugin ftp loaded
> obexd[8159]: driver 0x805f860 mimetype x-bt/phonebook registered
> obexd[8159]: driver 0x805f8a0 mimetype x-bt/vcard-listing registered
> obexd[8159]: driver 0x805f8e0 mimetype x-bt/vcard registered
> obexd[8159]: driver 0x805f820 service Phonebook Access server registered
> obexd[8159]: Plugin pbap loaded
> obexd[8159]: driver 0x805f980 mimetype (null) registered
> obexd[8159]: driver 0x805f940 service OBEX server for SyncML, using SyncEvolution registered
> obexd[8159]: Plugin syncevolution loaded
> obexd[8159]: Loading plugins /opt/obexd/0.28/lib/obex/plugins
> obexd[8159]: bluetooth: listening on channel 9
> obexd[8159]: bluetooth: FindAdapter(any)
> obexd[8159]: bluetooth: Registered: Object Push server, handle: 0x10009
> obexd[8159]: bluetooth: New connection from: 00:60:57:77:21:E1, channel 9
> obexd[8159]: REQHINT(0x1), CONNECT(0x0), (null)(0x0)
> obexd[8159]: REQ(0x2), CONNECT(0x0), (null)(0x0)
> obexd[8159]: Version: 0x10. Flags: 0x00 OBEX packet length: 2044
> obexd[8159]: Resizing stream chunks to 1844
> obexd[8159]: Selected driver: Object Push server
> obexd[8159]: REQDONE(0x3), CONNECT(0x0), (null)(0x0)
> obexd[8159]: obex_handle_input: poll event HUP ERR
> ^Cobexd[8159]: Terminating due to signal 2
> obexd[8159]: Cleanup plugins
> obexd[8159]: driver 0x805f554 transport bluetooth unregistered
> obexd[8159]: driver 0x805f570 transport usb unregistered
> obexd[8159]: driver 0x805f5a0 mimetype x-obex/folder-listing unregistered
> obexd[8159]: driver 0x805f5e0 mimetype x-obex/capability unregistered
> obexd[8159]: driver 0x805f620 mimetype (null) unregistered
> obexd[8159]: driver 0x805f6c0 mimetype application/vnd.nokia-backup unregistered
> obexd[8159]: driver 0x805f720 service Object Push server unregistered
> obexd[8159]: driver 0x805f780 service File Transfer server unregistered
> obexd[8159]: driver 0x805f7c0 service Nokia OBEX PC Suite Services unregistered
> obexd[8159]: driver 0x805f820 service Phonebook Access server unregistered
> obexd[8159]: driver 0x805f860 mimetype x-bt/phonebook unregistered
> obexd[8159]: driver 0x805f8a0 mimetype x-bt/vcard-listing unregistered
> obexd[8159]: driver 0x805f8e0 mimetype x-bt/vcard unregistered
> obexd[8159]: driver 0x805f940 service OBEX server for SyncML, using SyncEvolution unregistered
> obexd[8159]: driver 0x805f980 mimetype (null) unregistered
> obexd[8159]: manager_cleanup:
>
> And here's the packet trace from hcidump:
>
> 16:56:13 + exec /command/chpst -v -m 11333000 /usr/sbin/hcidump -i hci0 -a -V
> 16:58:30 HCI sniffer - Bluetooth packet analyzer ver 1.42
> 16:58:30 device: hci0 snap_len: 1028 filter: 0xffffffff
> 16:58:30 < HCI Command: Write Class of Device (0x03|0x0024) plen 3
> 16:58:30 class 0x5a0104
> 16:58:30 > HCI Event: Command Complete (0x0e) plen 4
> 16:58:30 Write Class of Device (0x03|0x0024) ncmd 1
> 16:58:30 status 0x00
> 16:58:30 < HCI Command: Write Extended Inquiry Response (0x03|0x0052) plen 241
> 16:58:30 fec 0x00
> 16:58:30 Complete local name: 'spotteswoode.dnsalias.org-0'
> 16:58:30 Complete service classes: 0x1115 0x1117 0x1116 0x1112 0x111f 0x110a 0x110c 0x110e 0x1103 0x1105
> 16:58:30 > HCI Event: Command Complete (0x0e) plen 4
> 16:58:30 Write Extended Inquiry Response (0x03|0x0052) ncmd 1
> 16:58:30 status 0x00
> 16:58:36 > HCI Event: Connect Request (0x04) plen 10
> 16:58:36 bdaddr 00:60:57:77:21:E1 class 0x500204 type ACL
> 16:58:36 < HCI Command: Accept Connection Request (0x01|0x0009) plen 7
> 16:58:36 bdaddr 00:60:57:77:21:E1 role 0x00
> 16:58:36 Role: Master
> 16:58:36 > HCI Event: Command Status (0x0f) plen 4
> 16:58:36 Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1
> 16:58:36 > HCI Event: Role Change (0x12) plen 8
> 16:58:36 status 0x00 bdaddr 00:60:57:77:21:E1 role 0x00
> 16:58:36 Role: Master
> 16:58:36 > HCI Event: Connect Complete (0x03) plen 11
> 16:58:36 status 0x00 handle 38 bdaddr 00:60:57:77:21:E1 type ACL encrypt 0x00
> 16:58:36 < HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
> 16:58:36 handle 38
> 16:58:36 > HCI Event: Page Scan Repetition Mode Change (0x20) plen 7
> 16:58:36 bdaddr 00:60:57:77:21:E1 mode 1
> 16:58:36 > HCI Event: Command Status (0x0f) plen 4
> 16:58:36 Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 0
> 16:58:36 > HCI Event: Max Slots Change (0x1b) plen 3
> 16:58:36 handle 38 slots 5
> 16:58:36 > HCI Event: Command Status (0x0f) plen 4
> 16:58:36 Unknown (0x00|0x0000) status 0x00 ncmd 1
> 16:58:36 > ACL data: handle 38 flags 0x02 dlen 12
> 16:58:36 L2CAP(s): Connect req: psm 1 scid 0x012a
> 16:58:36 < ACL data: handle 38 flags 0x02 dlen 16
> 16:58:36 L2CAP(s): Connect rsp: dcid 0x0040 scid 0x012a result 1 status 0
> 16:58:36 Connection pending - No futher information available
> 16:58:36 < ACL data: handle 38 flags 0x02 dlen 10
> 16:58:36 L2CAP(s): Info req: type 2
> 16:58:36 > HCI Event: Number of Completed Packets (0x13) plen 5
> 16:58:36 handle 38 packets 1
> 16:58:36 > HCI Event: Number of Completed Packets (0x13) plen 5
> 16:58:36 handle 38 packets 1
> 16:58:36 > HCI Event: Read Remote Supported Features (0x0b) plen 11
> 16:58:36 status 0x00 handle 38
> 16:58:36 Features: 0xbf 0x28 0x21 0x00 0x00 0x00 0x00 0x00
> 16:58:36 > HCI Event: QoS Setup Complete (0x0d) plen 21
> 16:58:36 status 0x00 handle 38 flags 0
> 16:58:36 Service type: 1
> 16:58:36 Token rate: 0
> 16:58:36 Peak bandwith: 0
> 16:58:36 Latency: 5000
> 16:58:36 Delay variation: -1
> 16:58:36 > ACL data: handle 38 flags 0x02 dlen 10
> 16:58:36 L2CAP(s): Command rej: reason 0
> 16:58:36 Command not understood
> 16:58:36 < ACL data: handle 38 flags 0x02 dlen 16
> 16:58:36 L2CAP(s): Connect rsp: dcid 0x0040 scid 0x012a result 0 status 0
> 16:58:36 Connection successful
> 16:58:36 > HCI Event: Number of Completed Packets (0x13) plen 5
> 16:58:36 handle 38 packets 1
> 16:58:36 < HCI Command: Remote Name Request (0x01|0x0019) plen 10
> 16:58:36 bdaddr 00:60:57:77:21:E1 mode 2 clkoffset 0x0000
> 16:58:36 > HCI Event: Command Status (0x0f) plen 4
> 16:58:36 Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
> 16:58:36 > ACL data: handle 38 flags 0x02 dlen 12
> 16:58:36 L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 0
> 16:58:36 < ACL data: handle 38 flags 0x02 dlen 18
> 16:58:36 L2CAP(s): Config rsp: scid 0x012a flags 0x00 result 0 clen 4
> 16:58:36 MTU 672
> 16:58:36 < ACL data: handle 38 flags 0x02 dlen 12
> 16:58:36 L2CAP(s): Config req: dcid 0x012a flags 0x00 clen 0
> 16:58:36 > HCI Event: Number of Completed Packets (0x13) plen 5
> 16:58:36 handle 38 packets 1
> 16:58:36 > HCI Event: Number of Completed Packets (0x13) plen 5
> 16:58:36 handle 38 packets 1
> 16:58:36 > ACL data: handle 38 flags 0x02 dlen 14
> 16:58:36 L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
> 16:58:36 Success
> 16:58:36 > HCI Event: Remote Name Req Complete (0x07) plen 255
> 16:58:36 status 0x00 bdaddr 00:60:57:77:21:E1 name 'ino_waiting>'
> 16:58:36 > ACL data: handle 38 flags 0x02 dlen 17
> 16:58:36 L2CAP(d): cid 0x0040 len 13 [psm 1]
> 16:58:36 SDP SS Req: tid 0x1 len 0x8
> 16:58:36 pat uuid-16 0x1105 (OBEXObjPush)
> 16:58:36 max 65535
> 16:58:36 cont 00
> 16:58:36 < ACL data: handle 38 flags 0x02 dlen 18
> 16:58:36 L2CAP(d): cid 0x012a len 14 [psm 1]
> 16:58:36 SDP SS Rsp: tid 0x1 len 0x9
> 16:58:36 count 1
> 16:58:36 handle 0x10009
> 16:58:36 cont 00
> 16:58:36 > HCI Event: Number of Completed Packets (0x13) plen 5
> 16:58:36 handle 38 packets 1
> 16:58:36 > ACL data: handle 38 flags 0x02 dlen 21
> 16:58:36 L2CAP(d): cid 0x0040 len 17 [psm 1]
> 16:58:36 SDP SA Req: tid 0x2 len 0xc
> 16:58:36 handle 0x10009
> 16:58:36 max 1024
> 16:58:36 aid(s) 0x0004 (ProtocolDescList)
> 16:58:36 cont 00
> 16:58:36 < ACL data: handle 38 flags 0x02 dlen 36
> 16:58:36 L2CAP(d): cid 0x012a len 32 [psm 1]
> 16:58:36 SDP SA Rsp: tid 0x2 len 0x1b
> 16:58:36 count 24
> 16:58:36 aid 0x0004 (ProtocolDescList)
> 16:58:36 < < uuid-16 0x0100 (L2CAP) > <
> 16:58:36 uuid-16 0x0003 (RFCOMM) uint 0x9 > <
> 16:58:36 uuid-16 0x0008 (OBEX) > >
> 16:58:36 cont 00
> 16:58:36 > HCI Event: Number of Completed Packets (0x13) plen 5
> 16:58:36 handle 38 packets 1
> 16:58:37 > ACL data: handle 38 flags 0x02 dlen 12
> 16:58:37 L2CAP(s): Connect req: psm 3 scid 0x012b
> 16:58:37 < ACL data: handle 38 flags 0x02 dlen 16
> 16:58:37 L2CAP(s): Connect rsp: dcid 0x0041 scid 0x012b result 0 status 0
> 16:58:37 Connection successful
> 16:58:37 > HCI Event: Number of Completed Packets (0x13) plen 5
> 16:58:37 handle 38 packets 1
> 16:58:37 > ACL data: handle 38 flags 0x02 dlen 12
> 16:58:37 L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 0
> 16:58:37 < ACL data: handle 38 flags 0x02 dlen 18
> 16:58:37 L2CAP(s): Config rsp: scid 0x012b flags 0x00 result 0 clen 4
> 16:58:37 MTU 672
> 16:58:37 < ACL data: handle 38 flags 0x02 dlen 16
> 16:58:37 L2CAP(s): Config req: dcid 0x012b flags 0x00 clen 4
> 16:58:37 MTU 1013
> 16:58:37 > HCI Event: Number of Completed Packets (0x13) plen 5
> 16:58:37 handle 38 packets 1
> 16:58:37 > HCI Event: Number of Completed Packets (0x13) plen 5
> 16:58:37 handle 38 packets 1
> 16:58:37 > ACL data: handle 38 flags 0x02 dlen 18
> 16:58:37 L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 4
> 16:58:37 MTU 1013
> 16:58:37 > ACL data: handle 38 flags 0x02 dlen 8
> 16:58:37 L2CAP(d): cid 0x0041 len 4 [psm 3]
> 16:58:37 RFCOMM(s): SABM: cr 1 dlci 0 pf 1 ilen 0 fcs 0x1c
> 16:58:37 < ACL data: handle 38 flags 0x02 dlen 8
> 16:58:37 L2CAP(d): cid 0x012b len 4 [psm 3]
> 16:58:37 RFCOMM(s): UA: cr 1 dlci 0 pf 1 ilen 0 fcs 0xd7
> 16:58:37 > HCI Event: Number of Completed Packets (0x13) plen 5
> 16:58:37 handle 38 packets 1
> 16:58:37 > ACL data: handle 38 flags 0x02 dlen 18
> 16:58:37 L2CAP(d): cid 0x0041 len 14 [psm 3]
> 16:58:37 RFCOMM(s): PN CMD: cr 1 dlci 0 pf 0 ilen 10 fcs 0x70 mcc_len 8
> 16:58:37 dlci 18 frame_type 0 credit_flow 15 pri 0 ack_timer 0
> 16:58:37 frame_size 667 max_retrans 0 credits 3
> 16:58:37 < ACL data: handle 38 flags 0x02 dlen 18
> 16:58:37 L2CAP(d): cid 0x012b len 14 [psm 3]
> 16:58:37 RFCOMM(s): PN RSP: cr 0 dlci 0 pf 0 ilen 10 fcs 0xaa mcc_len 8
> 16:58:37 dlci 18 frame_type 0 credit_flow 14 pri 0 ack_timer 0
> 16:58:37 frame_size 667 max_retrans 0 credits 7
> 16:58:37 > HCI Event: Number of Completed Packets (0x13) plen 5
> 16:58:37 handle 38 packets 1
> 16:58:37 > ACL data: handle 38 flags 0x02 dlen 8
> 16:58:37 L2CAP(d): cid 0x0041 len 4 [psm 3]
> 16:58:37 RFCOMM(s): SABM: cr 1 dlci 18 pf 1 ilen 0 fcs 0x32
> 16:58:37 < ACL data: handle 38 flags 0x02 dlen 8
> 16:58:37 L2CAP(d): cid 0x012b len 4 [psm 3]
> 16:58:37 RFCOMM(s): UA: cr 1 dlci 18 pf 1 ilen 0 fcs 0xf9
> 16:58:37 < ACL data: handle 38 flags 0x02 dlen 12
> 16:58:37 L2CAP(d): cid 0x012b len 8 [psm 3]
> 16:58:37 RFCOMM(s): MSC CMD: cr 0 dlci 0 pf 0 ilen 4 fcs 0xaa mcc_len 2
> 16:58:37 dlci 18 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 1 b3 0 len 0
> 16:58:37 > HCI Event: Number of Completed Packets (0x13) plen 5
> 16:58:37 handle 38 packets 1
> 16:58:37 > HCI Event: Number of Completed Packets (0x13) plen 5
> 16:58:37 handle 38 packets 1
> 16:58:37 > ACL data: handle 38 flags 0x02 dlen 12
> 16:58:37 L2CAP(d): cid 0x0041 len 8 [psm 3]
> 16:58:37 RFCOMM(s): MSC CMD: cr 1 dlci 0 pf 0 ilen 4 fcs 0x70 mcc_len 2
> 16:58:37 dlci 18 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 1 b3 0 len 0
> 16:58:37 < ACL data: handle 38 flags 0x02 dlen 12
> 16:58:37 L2CAP(d): cid 0x012b len 8 [psm 3]
> 16:58:37 RFCOMM(s): MSC RSP: cr 0 dlci 0 pf 0 ilen 4 fcs 0xaa mcc_len 2
> 16:58:37 dlci 18 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 1 b3 0 len 0
> 16:58:37 > HCI Event: Number of Completed Packets (0x13) plen 5
> 16:58:37 handle 38 packets 1
> 16:58:37 > ACL data: handle 38 flags 0x02 dlen 12
> 16:58:37 L2CAP(d): cid 0x0041 len 8 [psm 3]
> 16:58:37 RFCOMM(s): MSC RSP: cr 1 dlci 0 pf 0 ilen 4 fcs 0x70 mcc_len 2
> 16:58:37 dlci 18 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 1 b3 0 len 0
> 16:58:37 < ACL data: handle 38 flags 0x02 dlen 9
> 16:58:37 L2CAP(d): cid 0x012b len 5 [psm 3]
> 16:58:37 RFCOMM(d): UIH: cr 0 dlci 18 pf 1 ilen 0 fcs 0x8 credits 33
> 16:58:37 > ACL data: handle 38 flags 0x02 dlen 16
> 16:58:37 L2CAP(d): cid 0x0041 len 12 [psm 3]
> 16:58:37 RFCOMM(d): UIH: cr 1 dlci 18 pf 1 ilen 7 fcs 0xd2 credits 4
> 16:58:37 OBEX: Connect cmd(f): len 7 version 1.0 flags 0 mtu 2044
> 16:58:37 < ACL data: handle 38 flags 0x02 dlen 15
> 16:58:37 L2CAP(d): cid 0x012b len 11 [psm 3]
> 16:58:37 RFCOMM(d): UIH: cr 0 dlci 18 pf 0 ilen 7 fcs 0x14
> 16:58:37 OBEX: Connect rsp(f): status 200 len 7 version 1.0 flags 0 mtu 32767
> 16:58:37 Status 200 = Success
> 16:58:37 > HCI Event: Number of Completed Packets (0x13) plen 5
> 16:58:37 handle 38 packets 1
> 16:58:37 > HCI Event: Number of Completed Packets (0x13) plen 5
> 16:58:37 handle 38 packets 1
> 16:58:37 > ACL data: handle 38 flags 0x02 dlen 8
> 16:58:37 L2CAP(d): cid 0x0041 len 4 [psm 3]
> 16:58:37 RFCOMM(s): DISC: cr 1 dlci 18 pf 1 ilen 0 fcs 0xd3
> 16:58:37 < ACL data: handle 38 flags 0x02 dlen 8
> 16:58:37 L2CAP(d): cid 0x012b len 4 [psm 3]
> 16:58:37 RFCOMM(s): UA: cr 1 dlci 18 pf 1 ilen 0 fcs 0xf9
> 16:58:37 > HCI Event: Number of Completed Packets (0x13) plen 5
> 16:58:37 handle 38 packets 1
> 16:58:39 < ACL data: handle 38 flags 0x02 dlen 8
> 16:58:39 L2CAP(d): cid 0x012b len 4 [psm 3]
> 16:58:39 RFCOMM(s): DISC: cr 0 dlci 0 pf 1 ilen 0 fcs 0x9c
> 16:58:39 > HCI Event: Number of Completed Packets (0x13) plen 5
> 16:58:39 handle 38 packets 1
> 16:58:39 > ACL data: handle 38 flags 0x02 dlen 8
> 16:58:39 L2CAP(d): cid 0x0041 len 4 [psm 3]
> 16:58:39 RFCOMM(s): UA: cr 0 dlci 0 pf 1 ilen 0 fcs 0xb6
> 16:58:39 < ACL data: handle 38 flags 0x02 dlen 12
> 16:58:39 L2CAP(s): Disconn req: dcid 0x012b scid 0x0041
> 16:58:39 > HCI Event: Number of Completed Packets (0x13) plen 5
> 16:58:39 handle 38 packets 1
> 16:58:39 > ACL data: handle 38 flags 0x02 dlen 12
> 16:58:39 L2CAP(s): Disconn rsp: dcid 0x012b scid 0x0041
> 16:58:41 > ACL data: handle 38 flags 0x02 dlen 12
> 16:58:41 L2CAP(s): Disconn req: dcid 0x0040 scid 0x012a
> 16:58:41 < ACL data: handle 38 flags 0x02 dlen 12
> 16:58:41 L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x012a
> 16:58:41 > HCI Event: Number of Completed Packets (0x13) plen 5
> 16:58:41 handle 38 packets 1
> 16:58:45 < HCI Command: Disconnect (0x01|0x0006) plen 3
> 16:58:45 handle 38 reason 0x13
> 16:58:45 Reason: Remote User Terminated Connection
> 16:58:45 > HCI Event: Command Status (0x0f) plen 4
> 16:58:45 Disconnect (0x01|0x0006) status 0x00 ncmd 1
> 16:58:45 > HCI Event: Disconn Complete (0x05) plen 4
> 16:58:45 status 0x00 handle 38 reason 0x16
> 16:58:45 Reason: Connection Terminated by Local Host
> 16:58:49 < HCI Command: Write Class of Device (0x03|0x0024) plen 3
> 16:58:49 class 0x4a0104
> 16:58:49 > HCI Event: Command Complete (0x0e) plen 4
> 16:58:49 Write Class of Device (0x03|0x0024) ncmd 1
> 16:58:49 status 0x00
> 16:58:49 < HCI Command: Write Extended Inquiry Response (0x03|0x0052) plen 241
> 16:58:49 fec 0x00
> 16:58:49 Complete local name: 'spotteswoode.dnsalias.org-0'
> 16:58:49 Complete service classes: 0x1115 0x1117 0x1116 0x1112 0x111f 0x110a 0x110c 0x110e 0x1103
> 16:58:49 > HCI Event: Command Complete (0x0e) plen 4
> 16:58:49 Write Extended Inquiry Response (0x03|0x0052) ncmd 1
> 16:58:49 status 0x00
You can clearly see that obexd respond the connection request with 200
(ok) and after that there is no request from the remote device just a
clear disconnect:
16:58:37 < ACL data: handle 38 flags 0x02 dlen 15
16:58:37 L2CAP(d): cid 0x012b len 11 [psm 3]
16:58:37 RFCOMM(d): UIH: cr 0 dlci 18 pf 0 ilen 7 fcs 0x14
16:58:37 OBEX: Connect rsp(f): status 200 len 7 version 1.0
flags 0 mtu 32767
16:58:37 Status 200 = Success
16:58:37 > HCI Event: Number of Completed Packets (0x13) plen 5
16:58:37 handle 38 packets 1
16:58:37 > HCI Event: Number of Completed Packets (0x13) plen 5
16:58:37 handle 38 packets 1
16:58:37 > ACL data: handle 38 flags 0x02 dlen 8
16:58:37 L2CAP(d): cid 0x0041 len 4 [psm 3]
16:58:37 RFCOMM(s): DISC: cr 1 dlci 18 pf 1 ilen 0 fcs 0xd3
Have you tried transferring the same file with any other phone/stack?
This one seems very unlikely to be a obexd bug since there is not even
a request to transfer anything and as the connection itself seems ok,
no missing agent apparently, I don't see anything wrong here.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* obexd: cannot object-push certain files (large, w/ logs)
From: clemens fischer @ 2010-06-27 15:17 UTC (permalink / raw)
To: linux-bluetooth
'uname -rims' -> Linux 2.6.34-spott i686 AuthenticAMD, obexd-0.28
I cannot send certain files from my nokia-3650 cell phone to the linux
PC. I first thought they were too big with a bit less than 200kB, but
bigger files transfer fine. The problem is reproducable. The file in
question is Contacts.cdb, 171.8kB in size. I have the feeling that it
has to do with the type of file sent, but I have no idea what and where
to check. The files that work can be sent over and over without
problems, the ones that don't never do.
Here's the debug output from obexd:
0 3 # /l/libexec/obexd -nd -r /home/toor/mobile/nokia-niels/obex/ -a -o
obexd[8159]: Enabling debug information
obexd[8159]: manager_init:
obexd[8159]: Loading builtin plugins
obexd[8159]: driver 0x805f554 transport bluetooth registered
obexd[8159]: Plugin bluetooth loaded
obexd[8159]: driver 0x805f570 transport usb registered
obexd[8159]: Plugin usb loaded
obexd[8159]: driver 0x805f5a0 mimetype x-obex/folder-listing registered
obexd[8159]: driver 0x805f5e0 mimetype x-obex/capability registered
obexd[8159]: driver 0x805f660 mimetype x-obex/folder-listing registered
obexd[8159]: driver 0x805f620 mimetype (null) registered
obexd[8159]: Plugin filesystem loaded
obexd[8159]: driver 0x805f6c0 mimetype application/vnd.nokia-backup registered
obexd[8159]: Plugin backup loaded
obexd[8159]: driver 0x805f720 service Object Push server registered
obexd[8159]: Plugin opp loaded
obexd[8159]: driver 0x805f780 service File Transfer server registered
obexd[8159]: driver 0x805f7c0 service Nokia OBEX PC Suite Services registered
obexd[8159]: Plugin ftp loaded
obexd[8159]: driver 0x805f860 mimetype x-bt/phonebook registered
obexd[8159]: driver 0x805f8a0 mimetype x-bt/vcard-listing registered
obexd[8159]: driver 0x805f8e0 mimetype x-bt/vcard registered
obexd[8159]: driver 0x805f820 service Phonebook Access server registered
obexd[8159]: Plugin pbap loaded
obexd[8159]: driver 0x805f980 mimetype (null) registered
obexd[8159]: driver 0x805f940 service OBEX server for SyncML, using SyncEvolution registered
obexd[8159]: Plugin syncevolution loaded
obexd[8159]: Loading plugins /opt/obexd/0.28/lib/obex/plugins
obexd[8159]: bluetooth: listening on channel 9
obexd[8159]: bluetooth: FindAdapter(any)
obexd[8159]: bluetooth: Registered: Object Push server, handle: 0x10009
obexd[8159]: bluetooth: New connection from: 00:60:57:77:21:E1, channel 9
obexd[8159]: REQHINT(0x1), CONNECT(0x0), (null)(0x0)
obexd[8159]: REQ(0x2), CONNECT(0x0), (null)(0x0)
obexd[8159]: Version: 0x10. Flags: 0x00 OBEX packet length: 2044
obexd[8159]: Resizing stream chunks to 1844
obexd[8159]: Selected driver: Object Push server
obexd[8159]: REQDONE(0x3), CONNECT(0x0), (null)(0x0)
obexd[8159]: obex_handle_input: poll event HUP ERR
^Cobexd[8159]: Terminating due to signal 2
obexd[8159]: Cleanup plugins
obexd[8159]: driver 0x805f554 transport bluetooth unregistered
obexd[8159]: driver 0x805f570 transport usb unregistered
obexd[8159]: driver 0x805f5a0 mimetype x-obex/folder-listing unregistered
obexd[8159]: driver 0x805f5e0 mimetype x-obex/capability unregistered
obexd[8159]: driver 0x805f620 mimetype (null) unregistered
obexd[8159]: driver 0x805f6c0 mimetype application/vnd.nokia-backup unregistered
obexd[8159]: driver 0x805f720 service Object Push server unregistered
obexd[8159]: driver 0x805f780 service File Transfer server unregistered
obexd[8159]: driver 0x805f7c0 service Nokia OBEX PC Suite Services unregistered
obexd[8159]: driver 0x805f820 service Phonebook Access server unregistered
obexd[8159]: driver 0x805f860 mimetype x-bt/phonebook unregistered
obexd[8159]: driver 0x805f8a0 mimetype x-bt/vcard-listing unregistered
obexd[8159]: driver 0x805f8e0 mimetype x-bt/vcard unregistered
obexd[8159]: driver 0x805f940 service OBEX server for SyncML, using SyncEvolution unregistered
obexd[8159]: driver 0x805f980 mimetype (null) unregistered
obexd[8159]: manager_cleanup:
And here's the packet trace from hcidump:
16:56:13 + exec /command/chpst -v -m 11333000 /usr/sbin/hcidump -i hci0 -a -V
16:58:30 HCI sniffer - Bluetooth packet analyzer ver 1.42
16:58:30 device: hci0 snap_len: 1028 filter: 0xffffffff
16:58:30 < HCI Command: Write Class of Device (0x03|0x0024) plen 3
16:58:30 class 0x5a0104
16:58:30 > HCI Event: Command Complete (0x0e) plen 4
16:58:30 Write Class of Device (0x03|0x0024) ncmd 1
16:58:30 status 0x00
16:58:30 < HCI Command: Write Extended Inquiry Response (0x03|0x0052) plen 241
16:58:30 fec 0x00
16:58:30 Complete local name: 'spotteswoode.dnsalias.org-0'
16:58:30 Complete service classes: 0x1115 0x1117 0x1116 0x1112 0x111f 0x110a 0x110c 0x110e 0x1103 0x1105
16:58:30 > HCI Event: Command Complete (0x0e) plen 4
16:58:30 Write Extended Inquiry Response (0x03|0x0052) ncmd 1
16:58:30 status 0x00
16:58:36 > HCI Event: Connect Request (0x04) plen 10
16:58:36 bdaddr 00:60:57:77:21:E1 class 0x500204 type ACL
16:58:36 < HCI Command: Accept Connection Request (0x01|0x0009) plen 7
16:58:36 bdaddr 00:60:57:77:21:E1 role 0x00
16:58:36 Role: Master
16:58:36 > HCI Event: Command Status (0x0f) plen 4
16:58:36 Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1
16:58:36 > HCI Event: Role Change (0x12) plen 8
16:58:36 status 0x00 bdaddr 00:60:57:77:21:E1 role 0x00
16:58:36 Role: Master
16:58:36 > HCI Event: Connect Complete (0x03) plen 11
16:58:36 status 0x00 handle 38 bdaddr 00:60:57:77:21:E1 type ACL encrypt 0x00
16:58:36 < HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
16:58:36 handle 38
16:58:36 > HCI Event: Page Scan Repetition Mode Change (0x20) plen 7
16:58:36 bdaddr 00:60:57:77:21:E1 mode 1
16:58:36 > HCI Event: Command Status (0x0f) plen 4
16:58:36 Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 0
16:58:36 > HCI Event: Max Slots Change (0x1b) plen 3
16:58:36 handle 38 slots 5
16:58:36 > HCI Event: Command Status (0x0f) plen 4
16:58:36 Unknown (0x00|0x0000) status 0x00 ncmd 1
16:58:36 > ACL data: handle 38 flags 0x02 dlen 12
16:58:36 L2CAP(s): Connect req: psm 1 scid 0x012a
16:58:36 < ACL data: handle 38 flags 0x02 dlen 16
16:58:36 L2CAP(s): Connect rsp: dcid 0x0040 scid 0x012a result 1 status 0
16:58:36 Connection pending - No futher information available
16:58:36 < ACL data: handle 38 flags 0x02 dlen 10
16:58:36 L2CAP(s): Info req: type 2
16:58:36 > HCI Event: Number of Completed Packets (0x13) plen 5
16:58:36 handle 38 packets 1
16:58:36 > HCI Event: Number of Completed Packets (0x13) plen 5
16:58:36 handle 38 packets 1
16:58:36 > HCI Event: Read Remote Supported Features (0x0b) plen 11
16:58:36 status 0x00 handle 38
16:58:36 Features: 0xbf 0x28 0x21 0x00 0x00 0x00 0x00 0x00
16:58:36 > HCI Event: QoS Setup Complete (0x0d) plen 21
16:58:36 status 0x00 handle 38 flags 0
16:58:36 Service type: 1
16:58:36 Token rate: 0
16:58:36 Peak bandwith: 0
16:58:36 Latency: 5000
16:58:36 Delay variation: -1
16:58:36 > ACL data: handle 38 flags 0x02 dlen 10
16:58:36 L2CAP(s): Command rej: reason 0
16:58:36 Command not understood
16:58:36 < ACL data: handle 38 flags 0x02 dlen 16
16:58:36 L2CAP(s): Connect rsp: dcid 0x0040 scid 0x012a result 0 status 0
16:58:36 Connection successful
16:58:36 > HCI Event: Number of Completed Packets (0x13) plen 5
16:58:36 handle 38 packets 1
16:58:36 < HCI Command: Remote Name Request (0x01|0x0019) plen 10
16:58:36 bdaddr 00:60:57:77:21:E1 mode 2 clkoffset 0x0000
16:58:36 > HCI Event: Command Status (0x0f) plen 4
16:58:36 Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
16:58:36 > ACL data: handle 38 flags 0x02 dlen 12
16:58:36 L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 0
16:58:36 < ACL data: handle 38 flags 0x02 dlen 18
16:58:36 L2CAP(s): Config rsp: scid 0x012a flags 0x00 result 0 clen 4
16:58:36 MTU 672
16:58:36 < ACL data: handle 38 flags 0x02 dlen 12
16:58:36 L2CAP(s): Config req: dcid 0x012a flags 0x00 clen 0
16:58:36 > HCI Event: Number of Completed Packets (0x13) plen 5
16:58:36 handle 38 packets 1
16:58:36 > HCI Event: Number of Completed Packets (0x13) plen 5
16:58:36 handle 38 packets 1
16:58:36 > ACL data: handle 38 flags 0x02 dlen 14
16:58:36 L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
16:58:36 Success
16:58:36 > HCI Event: Remote Name Req Complete (0x07) plen 255
16:58:36 status 0x00 bdaddr 00:60:57:77:21:E1 name 'ino_waiting>'
16:58:36 > ACL data: handle 38 flags 0x02 dlen 17
16:58:36 L2CAP(d): cid 0x0040 len 13 [psm 1]
16:58:36 SDP SS Req: tid 0x1 len 0x8
16:58:36 pat uuid-16 0x1105 (OBEXObjPush)
16:58:36 max 65535
16:58:36 cont 00
16:58:36 < ACL data: handle 38 flags 0x02 dlen 18
16:58:36 L2CAP(d): cid 0x012a len 14 [psm 1]
16:58:36 SDP SS Rsp: tid 0x1 len 0x9
16:58:36 count 1
16:58:36 handle 0x10009
16:58:36 cont 00
16:58:36 > HCI Event: Number of Completed Packets (0x13) plen 5
16:58:36 handle 38 packets 1
16:58:36 > ACL data: handle 38 flags 0x02 dlen 21
16:58:36 L2CAP(d): cid 0x0040 len 17 [psm 1]
16:58:36 SDP SA Req: tid 0x2 len 0xc
16:58:36 handle 0x10009
16:58:36 max 1024
16:58:36 aid(s) 0x0004 (ProtocolDescList)
16:58:36 cont 00
16:58:36 < ACL data: handle 38 flags 0x02 dlen 36
16:58:36 L2CAP(d): cid 0x012a len 32 [psm 1]
16:58:36 SDP SA Rsp: tid 0x2 len 0x1b
16:58:36 count 24
16:58:36 aid 0x0004 (ProtocolDescList)
16:58:36 < < uuid-16 0x0100 (L2CAP) > <
16:58:36 uuid-16 0x0003 (RFCOMM) uint 0x9 > <
16:58:36 uuid-16 0x0008 (OBEX) > >
16:58:36 cont 00
16:58:36 > HCI Event: Number of Completed Packets (0x13) plen 5
16:58:36 handle 38 packets 1
16:58:37 > ACL data: handle 38 flags 0x02 dlen 12
16:58:37 L2CAP(s): Connect req: psm 3 scid 0x012b
16:58:37 < ACL data: handle 38 flags 0x02 dlen 16
16:58:37 L2CAP(s): Connect rsp: dcid 0x0041 scid 0x012b result 0 status 0
16:58:37 Connection successful
16:58:37 > HCI Event: Number of Completed Packets (0x13) plen 5
16:58:37 handle 38 packets 1
16:58:37 > ACL data: handle 38 flags 0x02 dlen 12
16:58:37 L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 0
16:58:37 < ACL data: handle 38 flags 0x02 dlen 18
16:58:37 L2CAP(s): Config rsp: scid 0x012b flags 0x00 result 0 clen 4
16:58:37 MTU 672
16:58:37 < ACL data: handle 38 flags 0x02 dlen 16
16:58:37 L2CAP(s): Config req: dcid 0x012b flags 0x00 clen 4
16:58:37 MTU 1013
16:58:37 > HCI Event: Number of Completed Packets (0x13) plen 5
16:58:37 handle 38 packets 1
16:58:37 > HCI Event: Number of Completed Packets (0x13) plen 5
16:58:37 handle 38 packets 1
16:58:37 > ACL data: handle 38 flags 0x02 dlen 18
16:58:37 L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 4
16:58:37 MTU 1013
16:58:37 > ACL data: handle 38 flags 0x02 dlen 8
16:58:37 L2CAP(d): cid 0x0041 len 4 [psm 3]
16:58:37 RFCOMM(s): SABM: cr 1 dlci 0 pf 1 ilen 0 fcs 0x1c
16:58:37 < ACL data: handle 38 flags 0x02 dlen 8
16:58:37 L2CAP(d): cid 0x012b len 4 [psm 3]
16:58:37 RFCOMM(s): UA: cr 1 dlci 0 pf 1 ilen 0 fcs 0xd7
16:58:37 > HCI Event: Number of Completed Packets (0x13) plen 5
16:58:37 handle 38 packets 1
16:58:37 > ACL data: handle 38 flags 0x02 dlen 18
16:58:37 L2CAP(d): cid 0x0041 len 14 [psm 3]
16:58:37 RFCOMM(s): PN CMD: cr 1 dlci 0 pf 0 ilen 10 fcs 0x70 mcc_len 8
16:58:37 dlci 18 frame_type 0 credit_flow 15 pri 0 ack_timer 0
16:58:37 frame_size 667 max_retrans 0 credits 3
16:58:37 < ACL data: handle 38 flags 0x02 dlen 18
16:58:37 L2CAP(d): cid 0x012b len 14 [psm 3]
16:58:37 RFCOMM(s): PN RSP: cr 0 dlci 0 pf 0 ilen 10 fcs 0xaa mcc_len 8
16:58:37 dlci 18 frame_type 0 credit_flow 14 pri 0 ack_timer 0
16:58:37 frame_size 667 max_retrans 0 credits 7
16:58:37 > HCI Event: Number of Completed Packets (0x13) plen 5
16:58:37 handle 38 packets 1
16:58:37 > ACL data: handle 38 flags 0x02 dlen 8
16:58:37 L2CAP(d): cid 0x0041 len 4 [psm 3]
16:58:37 RFCOMM(s): SABM: cr 1 dlci 18 pf 1 ilen 0 fcs 0x32
16:58:37 < ACL data: handle 38 flags 0x02 dlen 8
16:58:37 L2CAP(d): cid 0x012b len 4 [psm 3]
16:58:37 RFCOMM(s): UA: cr 1 dlci 18 pf 1 ilen 0 fcs 0xf9
16:58:37 < ACL data: handle 38 flags 0x02 dlen 12
16:58:37 L2CAP(d): cid 0x012b len 8 [psm 3]
16:58:37 RFCOMM(s): MSC CMD: cr 0 dlci 0 pf 0 ilen 4 fcs 0xaa mcc_len 2
16:58:37 dlci 18 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 1 b3 0 len 0
16:58:37 > HCI Event: Number of Completed Packets (0x13) plen 5
16:58:37 handle 38 packets 1
16:58:37 > HCI Event: Number of Completed Packets (0x13) plen 5
16:58:37 handle 38 packets 1
16:58:37 > ACL data: handle 38 flags 0x02 dlen 12
16:58:37 L2CAP(d): cid 0x0041 len 8 [psm 3]
16:58:37 RFCOMM(s): MSC CMD: cr 1 dlci 0 pf 0 ilen 4 fcs 0x70 mcc_len 2
16:58:37 dlci 18 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 1 b3 0 len 0
16:58:37 < ACL data: handle 38 flags 0x02 dlen 12
16:58:37 L2CAP(d): cid 0x012b len 8 [psm 3]
16:58:37 RFCOMM(s): MSC RSP: cr 0 dlci 0 pf 0 ilen 4 fcs 0xaa mcc_len 2
16:58:37 dlci 18 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 1 b3 0 len 0
16:58:37 > HCI Event: Number of Completed Packets (0x13) plen 5
16:58:37 handle 38 packets 1
16:58:37 > ACL data: handle 38 flags 0x02 dlen 12
16:58:37 L2CAP(d): cid 0x0041 len 8 [psm 3]
16:58:37 RFCOMM(s): MSC RSP: cr 1 dlci 0 pf 0 ilen 4 fcs 0x70 mcc_len 2
16:58:37 dlci 18 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 1 b3 0 len 0
16:58:37 < ACL data: handle 38 flags 0x02 dlen 9
16:58:37 L2CAP(d): cid 0x012b len 5 [psm 3]
16:58:37 RFCOMM(d): UIH: cr 0 dlci 18 pf 1 ilen 0 fcs 0x8 credits 33
16:58:37 > ACL data: handle 38 flags 0x02 dlen 16
16:58:37 L2CAP(d): cid 0x0041 len 12 [psm 3]
16:58:37 RFCOMM(d): UIH: cr 1 dlci 18 pf 1 ilen 7 fcs 0xd2 credits 4
16:58:37 OBEX: Connect cmd(f): len 7 version 1.0 flags 0 mtu 2044
16:58:37 < ACL data: handle 38 flags 0x02 dlen 15
16:58:37 L2CAP(d): cid 0x012b len 11 [psm 3]
16:58:37 RFCOMM(d): UIH: cr 0 dlci 18 pf 0 ilen 7 fcs 0x14
16:58:37 OBEX: Connect rsp(f): status 200 len 7 version 1.0 flags 0 mtu 32767
16:58:37 Status 200 = Success
16:58:37 > HCI Event: Number of Completed Packets (0x13) plen 5
16:58:37 handle 38 packets 1
16:58:37 > HCI Event: Number of Completed Packets (0x13) plen 5
16:58:37 handle 38 packets 1
16:58:37 > ACL data: handle 38 flags 0x02 dlen 8
16:58:37 L2CAP(d): cid 0x0041 len 4 [psm 3]
16:58:37 RFCOMM(s): DISC: cr 1 dlci 18 pf 1 ilen 0 fcs 0xd3
16:58:37 < ACL data: handle 38 flags 0x02 dlen 8
16:58:37 L2CAP(d): cid 0x012b len 4 [psm 3]
16:58:37 RFCOMM(s): UA: cr 1 dlci 18 pf 1 ilen 0 fcs 0xf9
16:58:37 > HCI Event: Number of Completed Packets (0x13) plen 5
16:58:37 handle 38 packets 1
16:58:39 < ACL data: handle 38 flags 0x02 dlen 8
16:58:39 L2CAP(d): cid 0x012b len 4 [psm 3]
16:58:39 RFCOMM(s): DISC: cr 0 dlci 0 pf 1 ilen 0 fcs 0x9c
16:58:39 > HCI Event: Number of Completed Packets (0x13) plen 5
16:58:39 handle 38 packets 1
16:58:39 > ACL data: handle 38 flags 0x02 dlen 8
16:58:39 L2CAP(d): cid 0x0041 len 4 [psm 3]
16:58:39 RFCOMM(s): UA: cr 0 dlci 0 pf 1 ilen 0 fcs 0xb6
16:58:39 < ACL data: handle 38 flags 0x02 dlen 12
16:58:39 L2CAP(s): Disconn req: dcid 0x012b scid 0x0041
16:58:39 > HCI Event: Number of Completed Packets (0x13) plen 5
16:58:39 handle 38 packets 1
16:58:39 > ACL data: handle 38 flags 0x02 dlen 12
16:58:39 L2CAP(s): Disconn rsp: dcid 0x012b scid 0x0041
16:58:41 > ACL data: handle 38 flags 0x02 dlen 12
16:58:41 L2CAP(s): Disconn req: dcid 0x0040 scid 0x012a
16:58:41 < ACL data: handle 38 flags 0x02 dlen 12
16:58:41 L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x012a
16:58:41 > HCI Event: Number of Completed Packets (0x13) plen 5
16:58:41 handle 38 packets 1
16:58:45 < HCI Command: Disconnect (0x01|0x0006) plen 3
16:58:45 handle 38 reason 0x13
16:58:45 Reason: Remote User Terminated Connection
16:58:45 > HCI Event: Command Status (0x0f) plen 4
16:58:45 Disconnect (0x01|0x0006) status 0x00 ncmd 1
16:58:45 > HCI Event: Disconn Complete (0x05) plen 4
16:58:45 status 0x00 handle 38 reason 0x16
16:58:45 Reason: Connection Terminated by Local Host
16:58:49 < HCI Command: Write Class of Device (0x03|0x0024) plen 3
16:58:49 class 0x4a0104
16:58:49 > HCI Event: Command Complete (0x0e) plen 4
16:58:49 Write Class of Device (0x03|0x0024) ncmd 1
16:58:49 status 0x00
16:58:49 < HCI Command: Write Extended Inquiry Response (0x03|0x0052) plen 241
16:58:49 fec 0x00
16:58:49 Complete local name: 'spotteswoode.dnsalias.org-0'
16:58:49 Complete service classes: 0x1115 0x1117 0x1116 0x1112 0x111f 0x110a 0x110c 0x110e 0x1103
16:58:49 > HCI Event: Command Complete (0x0e) plen 4
16:58:49 Write Extended Inquiry Response (0x03|0x0052) ncmd 1
16:58:49 status 0x00
regards, clemens fischer
^ permalink raw reply
* Re: [PATCH 5/5]bluetooth:hci_bcsp Fix operation on 'bcsp->msgq_txseq' may be undefined
From: Gustavo F. Padovan @ 2010-06-27 7:31 UTC (permalink / raw)
To: Justin P. Mattock; +Cc: linux-kernel, dhowells, sds, lenb, linux-bluetooth
In-Reply-To: <1277621246-10960-6-git-send-email-justinmattock@gmail.com>
Hi Justin,
* Justin P. Mattock <justinmattock@gmail.com> [2010-06-26 23:47:26 -0700]:
> Im seeing this building the kernel with gcc 4.6.0
> CC [M] drivers/bluetooth/hci_bcsp.o
> drivers/bluetooth/hci_bcsp.c: In function 'bcsp_prepare_pkt':
> drivers/bluetooth/hci_bcsp.c:247:20: warning: operation on 'bcsp->msgq_txseq' may be undefined
>
> Hopefully the below is a fix for this. Please let me know.
> Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
>
> ---
> drivers/bluetooth/hci_bcsp.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/bluetooth/hci_bcsp.c b/drivers/bluetooth/hci_bcsp.c
> index 40aec0f..0f892e7 100644
> --- a/drivers/bluetooth/hci_bcsp.c
> +++ b/drivers/bluetooth/hci_bcsp.c
> @@ -182,7 +182,7 @@ static struct sk_buff *bcsp_prepare_pkt(struct bcsp_struct *bcsp, u8 *data,
> struct sk_buff *nskb;
> u8 hdr[4], chan;
> u16 BCSP_CRC_INIT(bcsp_txmsg_crc);
> - int rel, i;
> + int rel, i, ret;
>
> switch (pkt_type) {
> case HCI_ACLDATA_PKT:
> @@ -243,8 +243,8 @@ static struct sk_buff *bcsp_prepare_pkt(struct bcsp_struct *bcsp, u8 *data,
>
> if (rel) {
> hdr[0] |= 0x80 + bcsp->msgq_txseq;
> - BT_DBG("Sending packet with seqno %u", bcsp->msgq_txseq);
> - bcsp->msgq_txseq = ++(bcsp->msgq_txseq) & 0x07;
> + BT_DBG("Sending packet with seqno %u", bcsp->msgq_txseq | ret);
> + ret = ++(bcsp->msgq_txseq) & 0x07;
> }
What are trying to do here? That is completely wrong, you are losting
the next txseq to be sent.
And please do not bother the linux-bluetooth mailing list with patches
to other subsystems. Send them in a way that only Bluetooth patches will
come to linux-bluetooth.
Regards,
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* Re: [PATCH] drivers: bluetooth: bluecard_cs.c: Fixed include error, changed to linux/io.h
From: Gustavo F. Padovan @ 2010-06-27 6:50 UTC (permalink / raw)
To: Cody Rester; +Cc: marcel, linux-bluetooth, linux-kernel
In-Reply-To: <1277619142-10751-1-git-send-email-codyrester@gmail.com>
* Cody Rester <codyrester@gmail.com> [2010-06-27 02:12:22 -0400]:
> Fixed include error, changed to linux/io.h
>
> Signed-off-by: Cody Rester <codyrester@gmail.com>
> ---
> drivers/bluetooth/bluecard_cs.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/bluetooth/bluecard_cs.c b/drivers/bluetooth/bluecard_cs.c
> index d9bf87c..89a4455 100644
> --- a/drivers/bluetooth/bluecard_cs.c
> +++ b/drivers/bluetooth/bluecard_cs.c
> @@ -37,7 +37,7 @@
> #include <linux/wait.h>
>
> #include <linux/skbuff.h>
> -#include <asm/io.h>
> +#include <linux/io.h>
>
> #include <pcmcia/cs_types.h>
> #include <pcmcia/cs.h>
> --
> 1.7.0.4
Acked-by: Gustavo F. Padovan <padovan@profusion.mobi>
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* [PATCH 5/5]bluetooth:hci_bcsp Fix operation on 'bcsp->msgq_txseq' may be undefined
From: Justin P. Mattock @ 2010-06-27 6:47 UTC (permalink / raw)
To: linux-kernel; +Cc: dhowells, sds, lenb, linux-bluetooth, Justin P. Mattock
In-Reply-To: <1277621246-10960-1-git-send-email-justinmattock@gmail.com>
Im seeing this building the kernel with gcc 4.6.0
CC [M] drivers/bluetooth/hci_bcsp.o
drivers/bluetooth/hci_bcsp.c: In function 'bcsp_prepare_pkt':
drivers/bluetooth/hci_bcsp.c:247:20: warning: operation on 'bcsp->msgq_txseq' may be undefined
Hopefully the below is a fix for this. Please let me know.
Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
---
drivers/bluetooth/hci_bcsp.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/bluetooth/hci_bcsp.c b/drivers/bluetooth/hci_bcsp.c
index 40aec0f..0f892e7 100644
--- a/drivers/bluetooth/hci_bcsp.c
+++ b/drivers/bluetooth/hci_bcsp.c
@@ -182,7 +182,7 @@ static struct sk_buff *bcsp_prepare_pkt(struct bcsp_struct *bcsp, u8 *data,
struct sk_buff *nskb;
u8 hdr[4], chan;
u16 BCSP_CRC_INIT(bcsp_txmsg_crc);
- int rel, i;
+ int rel, i, ret;
switch (pkt_type) {
case HCI_ACLDATA_PKT:
@@ -243,8 +243,8 @@ static struct sk_buff *bcsp_prepare_pkt(struct bcsp_struct *bcsp, u8 *data,
if (rel) {
hdr[0] |= 0x80 + bcsp->msgq_txseq;
- BT_DBG("Sending packet with seqno %u", bcsp->msgq_txseq);
- bcsp->msgq_txseq = ++(bcsp->msgq_txseq) & 0x07;
+ BT_DBG("Sending packet with seqno %u", bcsp->msgq_txseq | ret);
+ ret = ++(bcsp->msgq_txseq) & 0x07;
}
if (bcsp->use_crc)
--
1.7.1.rc1.21.gf3bd6
^ permalink raw reply related
* Re: How to programmatically pair device using bluez API
From: Gustavo F. Padovan @ 2010-06-27 6:30 UTC (permalink / raw)
To: Hieu Le Trung; +Cc: linux-bluetooth
In-Reply-To: <1277619176.6618.3.camel@localhost.localdomain>
Hi,
* Hieu Le Trung <hieuletrung@gmail.com> [2010-06-27 13:12:56 +0700]:
> Hi,
>
> I wonder how can I pair the device using BlueZ API. I've searched on the
> net but there is no place talk about this.
You can the CreatedPairedDevice() method from the Adapter interface. See
the doc/ dir inside the sources for more information.
Regards,
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* How to programmatically pair device using bluez API
From: Hieu Le Trung @ 2010-06-27 6:12 UTC (permalink / raw)
To: linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 143 bytes --]
Hi,
I wonder how can I pair the device using BlueZ API. I've searched on the
net but there is no place talk about this.
Thanks,
-Hieu
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* [PATCH] drivers: bluetooth: bluecard_cs.c: Fixed include error, changed to linux/io.h
From: Cody Rester @ 2010-06-27 6:12 UTC (permalink / raw)
To: marcel; +Cc: linux-bluetooth, linux-kernel, Cody Rester
Fixed include error, changed to linux/io.h
Signed-off-by: Cody Rester <codyrester@gmail.com>
---
drivers/bluetooth/bluecard_cs.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/bluetooth/bluecard_cs.c b/drivers/bluetooth/bluecard_cs.c
index d9bf87c..89a4455 100644
--- a/drivers/bluetooth/bluecard_cs.c
+++ b/drivers/bluetooth/bluecard_cs.c
@@ -37,7 +37,7 @@
#include <linux/wait.h>
#include <linux/skbuff.h>
-#include <asm/io.h>
+#include <linux/io.h>
#include <pcmcia/cs_types.h>
#include <pcmcia/cs.h>
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] Bluetooth: Bring back var 'i' increment
From: David Miller @ 2010-06-25 5:08 UTC (permalink / raw)
To: gustavo; +Cc: padovan, linux-bluetooth, netdev, marcel
In-Reply-To: <20100619002807.GD14514@vigoh>
From: "Gustavo F. Padovan" <gustavo@padovan.org>
Date: Fri, 18 Jun 2010 21:28:07 -0300
> * Gustavo F. Padovan <padovan@profusion.mobi> [2010-06-18 21:24:00 -0300]:
>
>> commit ff6e2163f28a1094fb5ca5950fe2b43c3cf6bc7a accidentally added a
>> regression on the bnep code. Fixing it.
>>
>> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
...
> Marcel, if you want I can carry the fix on my tree for -next.
I'll apply this bug fix to net-2.6 so it doesn't just rot like it is
currently.
Thanks.
^ permalink raw reply
* Re: Users need to manually run "hid2hci --method dell -v 413c -p 8158 --mode hci" even when udev rule is installed
From: Pacho Ramos @ 2010-06-24 15:01 UTC (permalink / raw)
To: Bastien Nocera; +Cc: linux-bluetooth
In-Reply-To: <1277390082.9334.129.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1398 bytes --]
El jue, 24-06-2010 a las 15:34 +0100, Bastien Nocera escribió:
> > > > This is still affecting to some users, can anybody help us? At least,
> > > > how could we check if udev is, at least, trying to execute hid2hci from
> > > > 97-bluetooth-hid2hci.rules file?
> > >
> > > 2 things.
> > >
> > > This is already fixed in udev upstream, and hid2hci doesn't live in
> > > bluez, but in udev now.
> > >
> > > This was also fixed recently in Fedora 14.
> > >
> > > Cheers
> > >
> >
> > Really thanks a lot! Seems to solve the problem :-D
>
> Was that sarcastic. I hope not, I sent this in good faith, because I
> fixed that exact same bug a couple of days before sending the mail.
>
> Cheers
>
?!
NO! It wasn't sarcastic :-O!
Simply take a look on my Changelog entry downstream (sent some days
ago):
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-wireless/bluez/ChangeLog?view=markup
*bluez-4.66-r1 (19 Jun 2010)
19 Jun 2010; Pacho Ramos <pacho@gentoo.org> +bluez-4.66-r1.ebuild:
Stop building hid2hci since it's replaced by >=sys-fs/udev-146[extras]
provided one. This should fix bug #315749 (reported by Balazs Nemeth,
Marcin Kryczek and others). Thanks a lot to Bastien Nocera for the tip
in
linux-bluetooth mailing list.
Sorry if I didn't express myself properly :-/, English is not my mother
tongue.
Best regards :-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH v3] audio: fix memory leak with typefinding
From: harri.mahonen @ 2010-06-24 15:01 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Harri Mahonen
From: Harri Mahonen <harri.mahonen@gmail.com>
Each time sbc_typefind is called and there is no syncword, sbc_finalize
never gets called. Instead of hardcoded syncword check, rely on
sbc_parse to do it properly.
---
audio/gstbluetooth.c | 16 ++++++++++------
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/audio/gstbluetooth.c b/audio/gstbluetooth.c
index 26dd4a5..3bc0690 100644
--- a/audio/gstbluetooth.c
+++ b/audio/gstbluetooth.c
@@ -50,21 +50,25 @@ static void sbc_typefind(GstTypeFind *tf, gpointer ignore)
sbc_t sbc;
guint8 *data = gst_type_find_peek(tf, 0, 32);
- if (sbc_init(&sbc, 0) < 0)
+ if (data == NULL)
return;
- if (data == NULL || *data != 0x9c) /* SBC syncword */
+ if (sbc_init(&sbc, 0) < 0)
return;
aux = g_new(guint8, 32);
memcpy(aux, data, 32);
- sbc_parse(&sbc, aux, 32);
- g_free(aux);
- caps = gst_sbc_parse_caps_from_sbc(&sbc);
- sbc_finish(&sbc);
+ if (sbc_parse(&sbc, aux, 32) < 0)
+ goto done;
+
+ caps = gst_sbc_parse_caps_from_sbc(&sbc);
gst_type_find_suggest(tf, GST_TYPE_FIND_POSSIBLE, caps);
gst_caps_unref(caps);
+
+done:
+ g_free(aux);
+ sbc_finish(&sbc);
}
static gchar *sbc_exts[] = { "sbc", NULL };
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH v2] audio: fix memory leak with typefinding
From: Luiz Augusto von Dentz @ 2010-06-24 14:54 UTC (permalink / raw)
To: harri.mahonen; +Cc: linux-bluetooth
In-Reply-To: <1277390241-9449-1-git-send-email-harri.mahonen@gmail.com>
Hi,
On Thu, Jun 24, 2010 at 5:37 PM, <harri.mahonen@gmail.com> wrote:
> From: Harri Mahonen <harri.mahonen@gmail.com>
>
> Each time sbc_typefind is called and there is no syncword, sbc_finalize
> never gets called. Instead of hardcoded syncword check, rely on
> sbc_parse to do it properly.
>
> Signed-off-by: Harri Mahonen <harri.mahonen@gmail.com>
> ---
> audio/gstbluetooth.c | 16 ++++++++++------
> 1 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/audio/gstbluetooth.c b/audio/gstbluetooth.c
> index 26dd4a5..3bc0690 100644
> --- a/audio/gstbluetooth.c
> +++ b/audio/gstbluetooth.c
> @@ -50,21 +50,25 @@ static void sbc_typefind(GstTypeFind *tf, gpointer ignore)
> sbc_t sbc;
> guint8 *data = gst_type_find_peek(tf, 0, 32);
>
> - if (sbc_init(&sbc, 0) < 0)
> + if (data == NULL)
> return;
>
> - if (data == NULL || *data != 0x9c) /* SBC syncword */
> + if (sbc_init(&sbc, 0) < 0)
> return;
>
> aux = g_new(guint8, 32);
> memcpy(aux, data, 32);
> - sbc_parse(&sbc, aux, 32);
> - g_free(aux);
> - caps = gst_sbc_parse_caps_from_sbc(&sbc);
> - sbc_finish(&sbc);
>
> + if (sbc_parse(&sbc, aux, 32) < 0)
> + goto done;
> +
> + caps = gst_sbc_parse_caps_from_sbc(&sbc);
> gst_type_find_suggest(tf, GST_TYPE_FIND_POSSIBLE, caps);
> gst_caps_unref(caps);
> +
> +done:
> + g_free(aux);
> + sbc_finish(&sbc);
> }
>
> static gchar *sbc_exts[] = { "sbc", NULL };
Looks great, but we don't use the signed-off-by thing.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* [PATCH v2] audio: fix memory leak with typefinding
From: harri.mahonen @ 2010-06-24 14:37 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Harri Mahonen
From: Harri Mahonen <harri.mahonen@gmail.com>
Each time sbc_typefind is called and there is no syncword, sbc_finalize
never gets called. Instead of hardcoded syncword check, rely on
sbc_parse to do it properly.
Signed-off-by: Harri Mahonen <harri.mahonen@gmail.com>
---
audio/gstbluetooth.c | 16 ++++++++++------
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/audio/gstbluetooth.c b/audio/gstbluetooth.c
index 26dd4a5..3bc0690 100644
--- a/audio/gstbluetooth.c
+++ b/audio/gstbluetooth.c
@@ -50,21 +50,25 @@ static void sbc_typefind(GstTypeFind *tf, gpointer ignore)
sbc_t sbc;
guint8 *data = gst_type_find_peek(tf, 0, 32);
- if (sbc_init(&sbc, 0) < 0)
+ if (data == NULL)
return;
- if (data == NULL || *data != 0x9c) /* SBC syncword */
+ if (sbc_init(&sbc, 0) < 0)
return;
aux = g_new(guint8, 32);
memcpy(aux, data, 32);
- sbc_parse(&sbc, aux, 32);
- g_free(aux);
- caps = gst_sbc_parse_caps_from_sbc(&sbc);
- sbc_finish(&sbc);
+ if (sbc_parse(&sbc, aux, 32) < 0)
+ goto done;
+
+ caps = gst_sbc_parse_caps_from_sbc(&sbc);
gst_type_find_suggest(tf, GST_TYPE_FIND_POSSIBLE, caps);
gst_caps_unref(caps);
+
+done:
+ g_free(aux);
+ sbc_finish(&sbc);
}
static gchar *sbc_exts[] = { "sbc", NULL };
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] audio: fix memory leak with typefinding
From: Harri Mähönen @ 2010-06-24 14:36 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <AANLkTimbLBxcU5nZE9UUQJGkHgMLe5LNnvLt1G0jckVF@mail.gmail.com>
On Thu, Jun 24, 2010 at 11:09 AM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Sorry, I misunderstood the problem, it is really gstreamer only issue,
> but I would suggest using the return of sbc_parse so we don't have to
> hardcode sbc sync word detection, something like the following:
Thank you for your comments, I agree with using sbc_parse to avoid
hardcoded sbc sync word detection. I'll repost updated patch.
Br,
Harri
^ permalink raw reply
* Re: Users need to manually run "hid2hci --method dell -v 413c -p 8158 --mode hci" even when udev rule is installed
From: Bastien Nocera @ 2010-06-24 14:34 UTC (permalink / raw)
To: pacho; +Cc: linux-bluetooth
In-Reply-To: <1276973964.16187.1.camel@localhost.localdomain>
On Sat, 2010-06-19 at 20:59 +0200, Pacho Ramos wrote:
> El sáb, 19-06-2010 a las 16:55 +0100, Bastien Nocera escribió:
> > On Sat, 2010-06-19 at 17:05 +0200, Pacho Ramos wrote:
> > > El sáb, 24-04-2010 a las 20:42 +0200, Pacho Ramos escribió:
> > > > Hello
> > > >
> > > > I would like to ask for help to try to find where could be the problem
> > > > causing this:
> > > > http://bugs.gentoo.org/show_bug.cgi?id=315749
> > > >
> > > > Reporter seems to need to manually run:
> > > > hid2hci --method dell -v 413c -p 8158 --mode hci
> > > >
> > > > to get bluetooth switched to hci mode.
> > > >
> > > > I don't understand why he needs to run it since involved udev rule file
> > > > seems to be properly installed.
> > > >
> > > > Could anybody help us on this please?
> > > >
> > > > Thanks a lot
> > >
> > > This is still affecting to some users, can anybody help us? At least,
> > > how could we check if udev is, at least, trying to execute hid2hci from
> > > 97-bluetooth-hid2hci.rules file?
> >
> > 2 things.
> >
> > This is already fixed in udev upstream, and hid2hci doesn't live in
> > bluez, but in udev now.
> >
> > This was also fixed recently in Fedora 14.
> >
> > Cheers
> >
>
> Really thanks a lot! Seems to solve the problem :-D
Was that sarcastic. I hope not, I sent this in good faith, because I
fixed that exact same bug a couple of days before sending the mail.
Cheers
^ permalink raw reply
* Re: [PATCH v3 1/3] Implements hci_reassembly to reassemble Rx packets
From: suraj @ 2010-06-24 9:40 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, Luis.Rodriguez, Jothikumar.Mothilal
In-Reply-To: <1276088748.31226.6.camel@atheros013-desktop>
Hi Marcel,
On Wed, 2010-06-09 at 18:35 +0530, suraj wrote:
> Implements feature to reassemble received HCI frames from any input stream.
>
> Signed-off-by: Suraj Sumangala <suraj@atheros.com>
> ---
> net/bluetooth/hci_core.c | 115 ++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 115 insertions(+), 0 deletions(-)
>
Can you please verify this implementation? Or direct me to someone who
has time to do it?
Regards
Suraj
^ permalink raw reply
* Re: hci_scodata_packet: hci1 SCO packet for unknown connection handle 42
From: Andrei Moraru @ 2010-06-24 9:28 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-bluetooth
In-Reply-To: <AANLkTini1WctunEp2H6bjod1BKdDgLaTsJGreb0JSwC6@mail.gmail.com>
Hello
On Wed, Jun 23, 2010 at 8:36 PM, Andrei Moraru
<andrei.moraru.n@gmail.com> wrote:
> On Tue, Jun 22, 2010 at 1:24 PM, Andrei Moraru
> <andrei.moraru.n@gmail.com> wrote:
>> On Fri, Jun 18, 2010 at 9:49 PM, Gustavo F. Padovan <gustavo@padovan.org> wrote:
>>> Hi Andrei,
>>>
>>> * Andrei Moraru <andrei.moraru.n@gmail.com> [2010-06-18 15:29:41 +0300]:
>>>
>>>> Hello,
>>>>
>>>> the machine is running CentOS and Asterisk 1.4.32
>>>>
>>>> there are installed bluez-4.66 and asterisk module chan_mobile
>>>>
>>>> The Asterisk crashes sometimes when is using FXO over the bluetooth
>>>> connection via chan_mobile
>>>>
>>>> uname -a:
>>>> 2.6.18-164.el5 #1 SMP Thu Sep 3 03:33:56 EDT 2009 i686 athlon i386 GNU/Linux
>>>
>>> Update your kernel to a 2.6.34 at least and see if you still have this
>>> issue.
>>>
>>> --
>>> Gustavo F. Padovan
>>> http://padovan.org
>>>
>>
>> updated the kernel version
>> #uname -a
>> Linux 2.6.34-default #2 SMP Mon Jun 21 17:55:19 EEST 2010 i686 i686
>> i386 GNU/Linux
>>
>> for building latest kernel, i used the old config of working 2.6.18 kernel.
>>
>> now, the system doesn't recognize any bluetooth adapter. The output of the
>> #hciconfig -a
>> is empty. Also:
>> # hcitool dev
>> Devices:
>> is empty.
>>
>> The output of the lsusb:
>> #lsusb
>> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>> Bus 002 Device 003: ID 0a12:0001 Cambridge Silicon Radio, Ltd
>> Bluetooth Dongle (HCI mode)
>> Bus 002 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd
>> Bluetooth Dongle (HCI mode)
>> Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
>>
>> the dbus-daemon is running:
>> # ps ax | grep dbus
>> 22252 ? Ss 0:00 dbus-daemon --system
>>
>> the version of bluez is 4.66, the latest.
>>
>> The problem is regarding the kernel config?
>>
>> - - - - - - - - - -
>> Andrei Moraru
>>
>
> The problem solved this way:
>
> 1) the kernel was rebuilt with HCI USB support, and the problem is
> gone; the command hciconfig -a shows connected BT dongles;
> 2) also, the 2.6.3x + kernel has compat-wireless stack available.
> I've built it, and i've rebuilt the Bluez-4.66
> 3) when started compat-wireless, got a lot of
>
> Jun 23 17:16:13 voip kernel: l2cap: Unknown symbol hci_conn_check_link_mode
> Jun 23 17:16:13 voip kernel: l2cap: disagrees about version of symbol
> bt_sock_link
>
> that means on my system some process used the old libbluetooth.so
> with lsof | grep blue* found that process, killed it, and reloaded the
> compat-wireless
>
> Hope it will be usefull for others.
>
> Andrei Moraru.
>
the /var/log/messages are filled with
hci_scodata_packet: hci1 SCO packet for unknown connection handle 0
hci_scodata_packet: hci1 SCO packet for unknown connection handle 43
btusb_isoc_complete: hci1 corrupted SCO packet
btusb_isoc_complete: hci1 corrupted SCO packet
hci_scodata_packet: hci1 SCO packet for unknown connection handle 42
Andrei Moraru.
^ permalink raw reply
* Re: [PATCH] audio: fix memory leak with typefinding
From: Luiz Augusto von Dentz @ 2010-06-24 8:09 UTC (permalink / raw)
To: harri.mahonen; +Cc: linux-bluetooth
In-Reply-To: <AANLkTikqyXXpC0guYSAZb4L-V6Cg5A_L6MJdcc5ChRpJ@mail.gmail.com>
Hi,
On Thu, Jun 24, 2010 at 10:52 AM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi,
>
> On Wed, Jun 23, 2010 at 10:10 PM, <harri.mahonen@gmail.com> wrote:
>> From: Harri Mahonen <harri.mahonen@gmail.com>
>>
>> sbc structure gets leaked each time when there is no data or SBC
>> syncword, because sbc_finalize is not called. Call sbc_init after
>> checking the data for syncword.
>>
>> Signed-off-by: Harri Mahonen <harri.mahonen@gmail.com>
>> ---
>> audio/gstbluetooth.c | 4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/audio/gstbluetooth.c b/audio/gstbluetooth.c
>> index 26dd4a5..11aefd7 100644
>> --- a/audio/gstbluetooth.c
>> +++ b/audio/gstbluetooth.c
>> @@ -50,10 +50,10 @@ static void sbc_typefind(GstTypeFind *tf, gpointer ignore)
>> sbc_t sbc;
>> guint8 *data = gst_type_find_peek(tf, 0, 32);
>>
>> - if (sbc_init(&sbc, 0) < 0)
>> + if (data == NULL || *data != 0x9c) /* SBC syncword */
>> return;
>>
>> - if (data == NULL || *data != 0x9c) /* SBC syncword */
>> + if (sbc_init(&sbc, 0) < 0)
>> return;
>>
>> aux = g_new(guint8, 32);
>
> We might want to have this fix inside sbc_init instead since others
> projects like pulseaudio may run into the same problem, also I guess
> it is a good practice to free any data allocated when returning an
> error.
Sorry, I misunderstood the problem, it is really gstreamer only issue,
but I would suggest using the return of sbc_parse so we don't have to
hardcode sbc sync word detection, something like the following:
diff --git a/audio/gstbluetooth.c b/audio/gstbluetooth.c
index 26dd4a5..9930820 100644
--- a/audio/gstbluetooth.c
+++ b/audio/gstbluetooth.c
@@ -50,21 +50,24 @@ static void sbc_typefind(GstTypeFind *tf, gpointer ignore)
sbc_t sbc;
guint8 *data = gst_type_find_peek(tf, 0, 32);
- if (sbc_init(&sbc, 0) < 0)
+ if (data == NULL)
return;
- if (data == NULL || *data != 0x9c) /* SBC syncword */
+ if (sbc_init(&sbc, 0) < 0)
return;
aux = g_new(guint8, 32);
memcpy(aux, data, 32);
- sbc_parse(&sbc, aux, 32);
- g_free(aux);
- caps = gst_sbc_parse_caps_from_sbc(&sbc);
- sbc_finish(&sbc);
+ if (sbc_parse(&sbc, aux, 32) < 0)
+ goto done;
+ caps = gst_sbc_parse_caps_from_sbc(&sbc);
gst_type_find_suggest(tf, GST_TYPE_FIND_POSSIBLE, caps);
gst_caps_unref(caps);
+
+done:
+ g_free(aux);
+ sbc_finish(&sbc);
}
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply related
* Re: [PATCH] audio: fix memory leak with typefinding
From: Luiz Augusto von Dentz @ 2010-06-24 7:52 UTC (permalink / raw)
To: harri.mahonen; +Cc: linux-bluetooth
In-Reply-To: <1277320206-6969-1-git-send-email-harri.mahonen@gmail.com>
Hi,
On Wed, Jun 23, 2010 at 10:10 PM, <harri.mahonen@gmail.com> wrote:
> From: Harri Mahonen <harri.mahonen@gmail.com>
>
> sbc structure gets leaked each time when there is no data or SBC
> syncword, because sbc_finalize is not called. Call sbc_init after
> checking the data for syncword.
>
> Signed-off-by: Harri Mahonen <harri.mahonen@gmail.com>
> ---
> audio/gstbluetooth.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/audio/gstbluetooth.c b/audio/gstbluetooth.c
> index 26dd4a5..11aefd7 100644
> --- a/audio/gstbluetooth.c
> +++ b/audio/gstbluetooth.c
> @@ -50,10 +50,10 @@ static void sbc_typefind(GstTypeFind *tf, gpointer ignore)
> sbc_t sbc;
> guint8 *data = gst_type_find_peek(tf, 0, 32);
>
> - if (sbc_init(&sbc, 0) < 0)
> + if (data == NULL || *data != 0x9c) /* SBC syncword */
> return;
>
> - if (data == NULL || *data != 0x9c) /* SBC syncword */
> + if (sbc_init(&sbc, 0) < 0)
> return;
>
> aux = g_new(guint8, 32);
We might want to have this fix inside sbc_init instead since others
projects like pulseaudio may run into the same problem, also I guess
it is a good practice to free any data allocated when returning an
error.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Is it valid BlueZ Serail-API ?
From: Chanyeol,Park @ 2010-06-24 4:05 UTC (permalink / raw)
To: linux-bluetooth
Hi
There is a log like the bottom.
Current Code doesn't have the below documents.(serial-api.txt) after
the git-log , however their code is still alive.
I am little bit confused.
Could you tell me whethr their API are valid or not?
If you explain why you removed, it would be helpul.
BR
Chanyeol.Park
Remove old serial-api.txt documentation file
author Marcel Holtmann <marcel@holtmann.org>
Mon, 22 Dec 2008 07:10:37 +0000 (08:10 +0100)
committer Marcel Holtmann <marcel@holtmann.org>
Mon, 22 Dec 2008 07:10:37 +0000 (08:10 +0100)
serial/Makefile.am patch | blob | history
serial/serial-api.txt [deleted file] patch | blob | history
http://git.kernel.org/?p=bluetooth/bluez.git;a=commitdiff;h=f463bec3023ba2b9eb44f2f72f21fdb66a06c826
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox