* Re: [PATCH 1/1] Bluetooth: hidp: Add support for hidraw HIDIOCGFEATURE and HIDIOCSFEATURE
From: Jiri Kosina @ 2010-06-19 17:49 UTC (permalink / raw)
To: Alan Ott
Cc: Marcel Holtmann, David S Miller, Michael Poole, Bastien Nocera,
Eric Dumazet, linux-bluetooth, linux-kernel, netdev
In-Reply-To: <1276467601-9066-1-git-send-email-alan@signal11.us>
On Sun, 13 Jun 2010, Alan Ott 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>
Marcel, any word on this please? We already have USB counterpart in, so
it'd be nice to finalize the Bluetooth part as well.
Thanks.
> ---
> 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
>
>
--
Jiri Kosina
SUSE Labs, Novell Inc.
^ 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-19 18:59 UTC (permalink / raw)
To: Bastien Nocera; +Cc: linux-bluetooth
In-Reply-To: <1276962936.13559.143.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1173 bytes --]
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
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] Bluetooth: Reset the security level after an authentication failure
From: Gustavo F. Padovan @ 2010-06-20 4:08 UTC (permalink / raw)
To: johan.hedberg; +Cc: linux-bluetooth, Johan Hedberg
In-Reply-To: <1276848536-29895-1-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
* johan.hedberg@gmail.com <johan.hedberg@gmail.com> [2010-06-18 11:08:56 +0300]:
> From: Johan Hedberg <johan.hedberg@nokia.com>
>
> When authentication fails for a connection the assumed security level
> should be set back to BT_SECURITY_LOW so that subsequent connect
> attempts over the same link don't falsely assume that security is
> adequate enough.
>
> Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
> ---
> net/bluetooth/hci_event.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
It works fine to me.
Acked-by: Gustavo F. Padovan <padovan@profusion.mobi>
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* Re: [PATCH] Bluetooth: Update sec_level and auth_type for already existing connections
From: Gustavo F. Padovan @ 2010-06-20 4:14 UTC (permalink / raw)
To: Emeltchenko Andrei; +Cc: linux-bluetooth
In-Reply-To: <1276606565-4381-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
* Emeltchenko Andrei <Andrei.Emeltchenko.news@gmail.com> [2010-06-15 15:56:05 +0300]:
> From: Ville Tervo <ville.tervo@nokia.com>
>
> Update auth level for already existing connections if it is lower
> than required by new connection.
>
> Signed-off-by: Ville Tervo <ville.tervo@nokia.com>
> Reviewed-by: Emeltchenko Andrei <andrei.emeltchenko@nokia.com>
> Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
> ---
> net/bluetooth/hci_conn.c | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
What's the use case here? i.e., how do I test your patch?
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* Re: [PATCH] Bluetooth: check l2cap pending status before sending l2cap connect request
From: Andrei Emeltchenko @ 2010-06-21 9:16 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-bluetooth
In-Reply-To: <20100619005327.GE14514@vigoh>
On Sat, Jun 19, 2010 at 3:53 AM, Gustavo F. Padovan <gustavo@padovan.org> wrote:
> Hi Andrei,
>
> * Emeltchenko Andrei <Andrei.Emeltchenko.news@gmail.com> [2010-06-16 15:52:05 +0300]:
>
>> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>>
>> Due to race condition in L2CAP state machine L2CAP Connection Request
>> may be sent twice for SDP with the same source channel id. Problems
>> reported connecting to Apple products, some carkit, Blackberry phones.
>>
>> ...
>> 2010-06-07 21:18:03.651031 < ACL data: handle 1 flags 0x02 dlen 12
>> L2CAP(s): Connect req: psm 1 scid 0x0040
>> 2010-06-07 21:18:03.653473 > HCI Event: Number of Completed Packets (0x13) plen 5
>> handle 1 packets 1
>> 2010-06-07 21:18:03.653808 > HCI Event: Auth Complete (0x06) plen 3
>> status 0x00 handle 1
>> 2010-06-07 21:18:03.653869 < ACL data: handle 1 flags 0x02 dlen 12
>> L2CAP(s): Connect req: psm 1 scid 0x0040
>> ...
>>
>> Patch uses L2CAP_CONF_CONNECT_PEND flag to mark that L2CAP Connection
>> Request has been sent.
>>
>> Modified version of Ville Tervo patch.
>>
>> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>> ---
>> net/bluetooth/l2cap.c | 11 +++++++++--
>> 1 files changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
>> index fc81acb..1ed51ad 100644
>> --- a/net/bluetooth/l2cap.c
>> +++ b/net/bluetooth/l2cap.c
>> @@ -387,13 +387,16 @@ static void l2cap_do_start(struct sock *sk)
>> if (!(conn->info_state & L2CAP_INFO_FEAT_MASK_REQ_DONE))
>> return;
>>
>> - if (l2cap_check_security(sk)) {
>> + if (l2cap_check_security(sk) &&
>> + ! l2cap_pi(sk)->conf_state &
>> + L2CAP_CONF_CONNECT_PEND) {
>
> This is wrong, you have to add parentheses here:
> !(l2cap_pi(sk)->conf_state & L2CAP_CONF_CONNECT_PEND)
Ah! My mistake when rearranging patch. Thanks a lot for the review.
I will send a new patch when I will test everything.
Regards,
Andrei
>
>> struct l2cap_conn_req req;
>> req.scid = cpu_to_le16(l2cap_pi(sk)->scid);
>> req.psm = l2cap_pi(sk)->psm;
>>
>> l2cap_pi(sk)->ident = l2cap_get_ident(conn);
>>
>> + l2cap_pi(sk)->conf_state |= L2CAP_CONF_CONNECT_PEND;
>> l2cap_send_cmd(conn, l2cap_pi(sk)->ident,
>> L2CAP_CONN_REQ, sizeof(req), &req);
>> }
>> @@ -441,13 +444,16 @@ static void l2cap_conn_start(struct l2cap_conn *conn)
>> }
>>
>> if (sk->sk_state == BT_CONNECT) {
>> - if (l2cap_check_security(sk)) {
>> + if (l2cap_check_security(sk) &&
>> + ! l2cap_pi(sk)->conf_state &
>> + L2CAP_CONF_CONNECT_PEND) {
>
> Here too.
>
>> struct l2cap_conn_req req;
>> req.scid = cpu_to_le16(l2cap_pi(sk)->scid);
>> req.psm = l2cap_pi(sk)->psm;
>>
>> l2cap_pi(sk)->ident = l2cap_get_ident(conn);
>>
>> + l2cap_pi(sk)->conf_state |= L2CAP_CONF_CONNECT_PEND;
>> l2cap_send_cmd(conn, l2cap_pi(sk)->ident,
>> L2CAP_CONN_REQ, sizeof(req), &req);
>> }
>> @@ -3828,6 +3834,7 @@ static int l2cap_security_cfm(struct hci_conn *hcon, u8 status, u8 encrypt)
>>
>> l2cap_pi(sk)->ident = l2cap_get_ident(conn);
>>
>> + l2cap_pi(sk)->conf_state |= L2CAP_CONF_CONNECT_PEND;
>> l2cap_send_cmd(conn, l2cap_pi(sk)->ident,
>> L2CAP_CONN_REQ, sizeof(req), &req);
>> } else {
>> --
>> 1.7.0.4
>
> Otherwise the patch seem fine to me.
>>
>> --
>> 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
>
> --
> Gustavo F. Padovan
> http://padovan.org
>
^ permalink raw reply
* Re: [PATCH] Bluetooth: Update sec_level and auth_type for already existing connections
From: Andrei Emeltchenko @ 2010-06-21 11:41 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-bluetooth
In-Reply-To: <20100620041459.GB32372@vigoh>
Hi Gustavo,
On Sun, Jun 20, 2010 at 7:14 AM, Gustavo F. Padovan <gustavo@padovan.org> wrote:
> Hi Andrei,
>
> * Emeltchenko Andrei <Andrei.Emeltchenko.news@gmail.com> [2010-06-15 15:56:05 +0300]:
>
>> From: Ville Tervo <ville.tervo@nokia.com>
>>
>> Update auth level for already existing connections if it is lower
>> than required by new connection.
>>
>> Signed-off-by: Ville Tervo <ville.tervo@nokia.com>
>> Reviewed-by: Emeltchenko Andrei <andrei.emeltchenko@nokia.com>
>> Signed-off-by: Luciano Coelho <luciano.coelho@nokia.com>
>> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>> ---
>> net/bluetooth/hci_conn.c | 5 +++++
>> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> What's the use case here? i.e., how do I test your patch?
- Create a device using org.bluez.Adapter.CreateDevice() and
- immediately call org.bluez.adapter.CreatePairedDevice() to pair.
EXPECTED OUTCOME:
Devices are paired, and confirmation is asked on both.
ACTUAL OUTCOME:
Devices are paired without confirmation. If I wait 10 seconds after
CreateDevice, the confirmation is asked on both devices.
-- Regards,
Andrei
^ permalink raw reply
* Re: 2.6.35-rc3: Reported regressions 2.6.33 -> 2.6.34
From: Luis R. Rodriguez @ 2010-06-21 18:32 UTC (permalink / raw)
To: linux-wireless, linux-bluetooth
Cc: Rafael J. Wysocki, reinette chatre, j, adobriyan, tj,
Satish Eerpini, Petr Pisar, Pavel Machek
In-Reply-To: <g77CuMUl7QI.A.qMH.4ZpHMB@chimera>
On Sun, Jun 20, 2010 at 3:32 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> This message contains a list of some post-2.6.33 regressions introduced before
> 2.6.34, for which there are no fixes in the mainline known to the tracking team.
> If any of them have been fixed already, please let us know.
>
> If you know of any other unresolved post-2.6.33 regressions, please let us know
> either and we'll add them to the list. Also, please let us know if any
> of the entries below are invalid.
>
> Each entry from the list will be sent additionally in an automatic reply to
> this message with CCs to the people involved in reporting and handling the
> issue.
>
>
> Listed regressions statistics:
>
> Date Total Pending Unresolved
> ----------------------------------------
> 2010-06-21 114 36 28
> 2010-06-13 111 40 34
> 2010-05-09 80 27 24
> 2010-05-04 76 26 22
> 2010-04-20 64 35 34
> 2010-04-07 48 35 33
> 2010-03-21 15 13 10
I'm going to just leave in the 802.11, Bluetooth and PCMCIA ones below:
> Unresolved regressions
> ----------------------
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16111
> Subject : hostap_pci: infinite registered netdevice wifi0
> Submitter : Petr Pisar <petr.pisar@atlas.cz>
> Date : 2010-06-02 20:55 (19 days old)
The last entry on this one says we are not sure how to fix this...
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16084
> Subject : iwl3945 bug in 2.6.34
> Submitter : Satish Eerpini <eerpini@gmail.com>
> Date : 2010-05-23 6:37 (29 days old)
> Message-ID : <AANLkTik_7rxDBc0TKlAfoYyM5S6Cf_Hyxbr4W5ORnTsq@mail.gmail.com>
> References : http://marc.info/?l=linux-kernel&m=127459596015626&w=2
This is getting some love by Reinette.
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15717
> Subject : bluetooth oops
> Submitter : Pavel Machek <pavel@ucw.cz>
> Date : 2010-03-14 20:14 (99 days old)
> Message-ID : <20100314201434.GE22059@elf.ucw.cz>
> References : http://marc.info/?l=linux-kernel&m=126859771528426&w=4
> Handled-By : Marcel Holtmann <marcel@holtmann.org>
Pavel, is this still happening or was just spurious on 2.6.34-rc1?
> Regressions with patches
> ------------------------
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16138
> Subject : PCMCIA regression
> Submitter : Mikulas Patocka <mpatocka@redhat.com>
> Date : 2010-05-25 20:25 (27 days old)
> Message-ID : <Pine.LNX.4.64.1005251619020.12278@hs20-bc2-1.build.redhat.com>
> References : http://marc.info/?l=linux-kernel&m=127481913909672&w=2
> Handled-By : Dominik Brodowski <linux@brodo.de>
> Patch : https://bugzilla.kernel.org/attachment.cgi?id=26685
Linville, are you to get PCMCIA stuff now? Anyway Rafael, please
remove this, this is fixed.
> For details, please visit the bug entries and follow the links given in
> references.
>
> As you can see, there is a Bugzilla entry for each of the listed regressions.
> There also is a Bugzilla entry used for tracking the regressions introduced
> between 2.6.33 and 2.6.34, unresolved as well as resolved, at:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=15310
>
> Please let the tracking teak know if there are any Bugzilla entries that
> should be added to the list in there.
>
> Thanks!
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: 2.6.35-rc3: Reported regressions from 2.6.34
From: Luis R. Rodriguez @ 2010-06-21 18:49 UTC (permalink / raw)
To: linux-wireless, linux-bluetooth; +Cc: Rafael J. Wysocki, reinette chatre
In-Reply-To: <lc60d4toGTL.A.QzD._LpHMB@chimera>
On Sun, Jun 20, 2010 at 3:11 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> This message contains a list of some regressions from 2.6.34,
> for which there are no fixes in the mainline known to the tracking team.
> If any of them have been fixed already, please let us know.
>
> If you know of any other unresolved regressions from 2.6.34, please let us
> know either and we'll add them to the list. Also, please let us know
> if any of the entries below are invalid.
>
> Each entry from the list will be sent additionally in an automatic reply
> to this message with CCs to the people involved in reporting and handling
> the issue.
>
>
> Listed regressions statistics:
>
> Date Total Pending Unresolved
> ----------------------------------------
> 2010-06-21 46 37 26
> 2010-06-09 15 13 10
Leaving only the 802.11, and Bluetooth (none) ones:
> Unresolved regressions
> ----------------------
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16235
> Subject : [REGRESSION] [IWL3945] Broadcast is broken?
> Submitter : Maciej Rutecki <maciej.rutecki@gmail.com>
> Date : 2010-06-14 17:24 (7 days old)
> Message-ID : <201006141924.24061.maciej.rutecki@gmail.com>
> References : http://marc.info/?l=linux-kernel&m=127653628301300&w=2
As noted by Maxim, the fix is in some Intel tree, but not upstream yet
(if so why ?)
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16232
> Subject : 2.6.35-rc3 - WARNING:iwl_set_dynamic_key
> Submitter : Mario Guenterberg <mario.guenterberg@googlemail.com>
> Date : 2010-06-14 11:55 (7 days old)
> Message-ID : <20100614115510.GA7904@guenti-laptop>
> References : http://marc.info/?l=linux-kernel&m=127651695627147&w=2
Rafael, this one actually has a supplied patch by Reinette and she's
waiting on the user.
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16201
> Subject : SIOCGIWFREQ ioctl fails to get frequency info
> Submitter : nuh <nuh@mailinator.net>
> Date : 2010-06-14 10:45 (7 days old)
John is waiting on some user sample code to reproduce.
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16176
> Subject : Microcode errors with iwl3945
> Submitter : Steinar H. Gunderson <sgunderson@bigfoot.com>
> Date : 2010-06-10 19:28 (11 days old)
One issue replaced with another, but the microcode issues seems to be
fixed now on rc3.
> Regressions with patches
> ------------------------
> Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16196
> Subject : 2.6.35-rc2-git1 - WARNING: at net/wireless/mlme.c:341 cfg80211_send_assoc_timeout+0x107/0x11e [cfg80211]()
> Submitter : Miles Lane <miles.lane@gmail.com>
> Date : 2010-06-07 19:06 (14 days old)
> Message-ID : <AANLkTinmZh9GnrZLzOGi5Q_xHbky8cKdHAkOnsIA6_dZ@mail.gmail.com>
> References : http://marc.info/?l=linux-kernel&m=127593758817428&w=2
> Handled-By : Johannes Berg <johannes.berg@intel.com>
> Patch : http://marc.info/?l=linux-wireless&m=127608099427316&w=2
Patch confirmed to work.
> For details, please visit the bug entries and follow the links given in
> references.
>
> As you can see, there is a Bugzilla entry for each of the listed regressions.
> There also is a Bugzilla entry used for tracking the regressions from 2.6.34,
> unresolved as well as resolved, at:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=16055
>
> Please let the tracking team know if there are any Bugzilla entries that
> should be added to the list in there.
>
> Thanks!
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: 2.6.35-rc3: Reported regressions from 2.6.34
From: reinette chatre @ 2010-06-21 22:07 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, linux-bluetooth, Rafael J. Wysocki
In-Reply-To: <AANLkTikVpTyNyYWf5xIO_3ok4OwbhxoiD40G3PAK8zp8@mail.gmail.com>
On Mon, 2010-06-21 at 11:49 -0700, Luis R. Rodriguez wrote:
> On Sun, Jun 20, 2010 at 3:11 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=16235
> > Subject : [REGRESSION] [IWL3945] Broadcast is broken?
> > Submitter : Maciej Rutecki <maciej.rutecki@gmail.com>
> > Date : 2010-06-14 17:24 (7 days old)
> > Message-ID : <201006141924.24061.maciej.rutecki@gmail.com>
> > References : http://marc.info/?l=linux-kernel&m=127653628301300&w=2
>
> As noted by Maxim, the fix is in some Intel tree, but not upstream yet
> (if so why ?)
The patch was merged into our tree a few days ago. It will be sent
upstream after our validation passes, which should be by the end of this
week. The repo in which it was merged is accessible to all if the patch
is needed sooner - a link is now included in that bug report.
Reinette
^ permalink raw reply
* obexd: obex_handle_input: poll event HUP ERR
From: Jiri Slaby @ 2010-06-22 7:23 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Marcel Holtmann
Hi,
I have a problem with receiving files with obexd. After it receives
header (file name etc.) it hangs up the connection with
obex_handle_input: poll event HUP ERR
With obex-data-server, everything works as expected.
$ rpm -q obexd libopenobex1 bluez kernel-desktop|sort
bluez-4.64-2.6.x86_64 == should I try 4.66? ==
kernel-desktop-2.6.34-9.3.x86_64
libopenobex1-1.5-1.8.x86_64
obexd-0.27-6.2.x86_64
$ uname -a
Linux anemoi 2.6.34-9-desktop #1 SMP PREEMPT 2010-06-03 18:33:51 +0200
x86_64 x86_64 x86_64 GNU/Linux
$ strace -fo strace-obexd /usr/lib64/obex/obexd --nodaemon --opp --ftp
--root=Public --root-setup=/usr/lib64/obex/obexd-setup.sh -d
obexd[15862]: Enabling debug information
obexd[15862]: manager_init:
obexd[15862]: Loading builtin plugins
obexd[15862]: driver 0x61d800 transport bluetooth registered
obexd[15862]: Plugin bluetooth loaded
obexd[15862]: driver 0x61d840 mimetype x-obex/folder-listing registered
obexd[15862]: driver 0x61d8a0 mimetype x-obex/capability registered
obexd[15862]: driver 0x61d960 mimetype x-obex/folder-listing registered
obexd[15862]: driver 0x61d900 mimetype (null) registered
obexd[15862]: Plugin filesystem loaded
obexd[15862]: driver 0x61d9e0 service Object Push server registered
obexd[15862]: Plugin opp loaded
obexd[15862]: driver 0x61da80 service File Transfer server registered
obexd[15862]: driver 0x61db00 service Nokia OBEX PC Suite Services
registered
obexd[15862]: Plugin ftp loaded
obexd[15862]: driver 0x61dc20 mimetype x-bt/phonebook registered
obexd[15862]: driver 0x61dc80 mimetype x-bt/vcard-listing registered
obexd[15862]: driver 0x61dce0 mimetype x-bt/vcard registered
obexd[15862]: driver 0x61dba0 service Phonebook Access server registered
obexd[15862]: Plugin pbap loaded
obexd[15862]: driver 0x61dde0 mimetype (null) registered
obexd[15862]: driver 0x61dd60 service OBEX server for SyncML, using
SyncEvolution registered
obexd[15862]: Plugin syncevolution loaded
obexd[15862]: Loading plugins /usr/lib64/obex/plugins
obexd[15862]: bluetooth: listening on channel 9
obexd[15862]: bluetooth: listening on channel 10
obexd[15862]: bluetooth: FindAdapter(any)
obexd[15862]: bluetooth: Registered: Object Push server, handle: 0x10008
obexd[15862]: bluetooth: Registered: File Transfer server, handle: 0x10009
obexd[15862]: bluetooth: New connection from: 00:24:7D:65:55:C5, channel 9
obexd[15862]: REQHINT(0x1), CONNECT(0x0), (null)(0x0)
obexd[15862]: REQ(0x2), CONNECT(0x0), (null)(0x0)
obexd[15862]: Version: 0x10. Flags: 0x00 OBEX packet length: 65535
obexd[15862]: Resizing stream chunks to 65335
obexd[15862]: Selected driver: Object Push server
obexd[15862]: REQDONE(0x3), CONNECT(0x0), (null)(0x0)
obexd[15862]: REQHINT(0x1), PUT(0x2), (null)(0x0)
obexd[15862]: REQCHECK(0xb), PUT(0x2), (null)(0x0)
obexd[15862]: OBEX_HDR_NAME: 323mm=20 10kg.txt
obexd[15862]: OBEX_HDR_LENGTH: 28
obexd[15862]: OBEX_HDR_TYPE: text/plain
obexd[15862]: REQDONE(0x3), PUT(0x2), (null)(0x0)
obexd[15862]: obex_handle_input: poll event HUP ERR
^Cobexd[15862]: Terminating due to signal 2
obexd[15862]: Cleanup plugins
obexd[15862]: driver 0x61d800 transport bluetooth unregistered
obexd[15862]: driver 0x61d840 mimetype x-obex/folder-listing unregistered
obexd[15862]: driver 0x61d8a0 mimetype x-obex/capability unregistered
obexd[15862]: driver 0x61d900 mimetype (null) unregistered
obexd[15862]: driver 0x61d9e0 service Object Push server unregistered
obexd[15862]: driver 0x61da80 service File Transfer server unregistered
obexd[15862]: driver 0x61db00 service Nokia OBEX PC Suite Services
unregistered
obexd[15862]: driver 0x61dba0 service Phonebook Access server unregistered
obexd[15862]: driver 0x61dc20 mimetype x-bt/phonebook unregistered
obexd[15862]: driver 0x61dc80 mimetype x-bt/vcard-listing unregistered
obexd[15862]: driver 0x61dce0 mimetype x-bt/vcard unregistered
obexd[15862]: driver 0x61dd60 service OBEX server for SyncML, using
SyncEvolution unregistered
obexd[15862]: driver 0x61dde0 mimetype (null) unregistered
obexd[15862]: manager_cleanup:
strace of the process:
http://www.fi.muni.cz/~xslaby/sklad/obexd-strace
^ permalink raw reply
* Re: obexd: obex_handle_input: poll event HUP ERR
From: Johan Hedberg @ 2010-06-22 7:38 UTC (permalink / raw)
To: Jiri Slaby; +Cc: linux-bluetooth
In-Reply-To: <4C206507.40402@gmail.com>
Hi,
On Tue, Jun 22, 2010, Jiri Slaby wrote:
> I have a problem with receiving files with obexd. After it receives
> header (file name etc.) it hangs up the connection with
> obex_handle_input: poll event HUP ERR
libopenobex seems to be indicating REQDONE, so it doesn't look like
anything is necessarily wrong with obexd here. However, you'd need to
look at the HCI level trafic (output of "hcidump -XV") to determine
what's really going on (e.g. is it obexd or the client that's
disconnecting).
Johan
^ permalink raw reply
* Re: obexd: obex_handle_input: poll event HUP ERR
From: Jiri Slaby @ 2010-06-22 7:41 UTC (permalink / raw)
To: linux-bluetooth; +Cc: johan.hedberg
In-Reply-To: <20100622073841.GA13989@jh-x301>
On 06/22/2010 09:38 AM, Johan Hedberg wrote:
> On Tue, Jun 22, 2010, Jiri Slaby wrote:
>> I have a problem with receiving files with obexd. After it receives
>> header (file name etc.) it hangs up the connection with
>> obex_handle_input: poll event HUP ERR
>
> libopenobex seems to be indicating REQDONE, so it doesn't look like
> anything is necessarily wrong with obexd here. However, you'd need to
> look at the HCI level trafic (output of "hcidump -XV") to determine
> what's really going on (e.g. is it obexd or the client that's
> disconnecting).
Attached:
# hcidump -XV
HCI sniffer - Bluetooth packet analyzer ver 1.42
device: hci0 snap_len: 1028 filter: 0xffffffffffffffff
> HCI Event: Connect Request (0x04) plen 10
bdaddr 00:24:7D:65:55:C5 class 0x5a020c type ACL
< HCI Command: Accept Connection Request (0x01|0x0009) plen 7
bdaddr 00:24:7D:65:55:C5 role 0x00
Role: Master
> HCI Event: Command Status (0x0f) plen 4
Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1
> HCI Event: Role Change (0x12) plen 8
status 0x00 bdaddr 00:24:7D:65:55:C5 role 0x00
Role: Master
> HCI Event: Connect Complete (0x03) plen 11
status 0x00 handle 42 bdaddr 00:24:7D:65:55:C5 type ACL encrypt 0x00
< HCI Command: Read Remote Supported Features (0x01|0x001b) plen 2
handle 42
> HCI Event: Page Scan Repetition Mode Change (0x20) plen 7
bdaddr 00:24:7D:65:55:C5 mode 0
> HCI Event: Max Slots Change (0x1b) plen 3
handle 42 slots 5
> HCI Event: Command Status (0x0f) plen 4
Read Remote Supported Features (0x01|0x001b) status 0x00 ncmd 0
> HCI Event: Command Status (0x0f) plen 4
Unknown (0x00|0x0000) status 0x00 ncmd 1
> HCI Event: Read Remote Supported Features (0x0b) plen 11
status 0x00 handle 42
Features: 0xbf 0xee 0x0f 0xce 0x98 0x39 0x00 0x00
> ACL data: handle 42 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 1 scid 0x0040
< ACL data: handle 42 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0040 result 1 status 0
Connection pending - No futher information available
< ACL data: handle 42 flags 0x02 dlen 10
L2CAP(s): Info req: type 2
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 16
L2CAP(s): Info rsp: type 2 result 0
Extended feature mask 0x0003
Flow control mode
Retransmission mode
< ACL data: handle 42 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0040 result 0 status 0
Connection successful
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 10
L2CAP(s): Info req: type 2
< ACL data: handle 42 flags 0x02 dlen 16
L2CAP(s): Info rsp: type 2 result 0
Extended feature mask 0x0080
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
MTU 5120
< ACL data: handle 42 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 4
MTU 5120
< ACL data: handle 42 flags 0x02 dlen 12
L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 0
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 4
MTU 672
> ACL data: handle 42 flags 0x02 dlen 17
L2CAP(d): cid 0x0040 len 13 [psm 1]
SDP SS Req: tid 0x1 len 0x8
pat uuid-16 0x1105 (OBEXObjPush)
max 65535
cont 00
< HCI Command: Remote Name Request (0x01|0x0019) plen 10
bdaddr 00:24:7D:65:55:C5 mode 2 clkoffset 0x0000
< ACL data: handle 42 flags 0x02 dlen 18
L2CAP(d): cid 0x0040 len 14 [psm 1]
SDP SS Rsp: tid 0x1 len 0x9
count 1
handle 0x10000
cont 00
> HCI Event: Command Status (0x0f) plen 4
Remote Name Request (0x01|0x0019) status 0x00 ncmd 1
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 21
L2CAP(d): cid 0x0040 len 17 [psm 1]
SDP SA Req: tid 0x2 len 0xc
handle 0x10000
max 1024
aid(s) 0x0004 (ProtocolDescList)
cont 00
< ACL data: handle 42 flags 0x02 dlen 36
L2CAP(d): cid 0x0040 len 32 [psm 1]
SDP SA Rsp: tid 0x2 len 0x1b
count 24
aid 0x0004 (ProtocolDescList)
< < uuid-16 0x0100 (L2CAP) > <
uuid-16 0x0003 (RFCOMM) uint 0x9 > <
uuid-16 0x0008 (OBEX) > >
cont 00
> ACL data: handle 42 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 3 scid 0x0041
< ACL data: handle 42 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0041 scid 0x0041 result 0 status 0
Connection successful
> HCI Event: Remote Name Req Complete (0x07) plen 255
status 0x00 bdaddr 00:24:7D:65:55:C5 name 'Nokia 5800 gep'
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 4
MTU 32772
< ACL data: handle 42 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 4
MTU 32772
< ACL data: handle 42 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0041 flags 0x00 clen 4
MTU 1013
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x0041 flags 0x00 result 0 clen 4
MTU 1013
> ACL data: handle 42 flags 0x02 dlen 8
L2CAP(d): cid 0x0041 len 4 [psm 3]
RFCOMM(s): SABM: cr 1 dlci 0 pf 1 ilen 0 fcs 0x1c
< ACL data: handle 42 flags 0x02 dlen 8
L2CAP(d): cid 0x0041 len 4 [psm 3]
RFCOMM(s): UA: cr 1 dlci 0 pf 1 ilen 0 fcs 0xd7
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 18
L2CAP(d): cid 0x0041 len 14 [psm 3]
RFCOMM(s): PN CMD: cr 1 dlci 0 pf 0 ilen 10 fcs 0x70 mcc_len 8
dlci 18 frame_type 0 credit_flow 15 pri 0 ack_timer 0
frame_size 1008 max_retrans 0 credits 3
< ACL data: handle 42 flags 0x02 dlen 18
L2CAP(d): cid 0x0041 len 14 [psm 3]
RFCOMM(s): PN RSP: cr 0 dlci 0 pf 0 ilen 10 fcs 0xaa mcc_len 8
dlci 18 frame_type 0 credit_flow 14 pri 0 ack_timer 0
frame_size 1008 max_retrans 0 credits 7
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 8
L2CAP(d): cid 0x0041 len 4 [psm 3]
RFCOMM(s): SABM: cr 1 dlci 18 pf 1 ilen 0 fcs 0x32
< ACL data: handle 42 flags 0x02 dlen 8
L2CAP(d): cid 0x0041 len 4 [psm 3]
RFCOMM(s): UA: cr 1 dlci 18 pf 1 ilen 0 fcs 0xf9
< ACL data: handle 42 flags 0x02 dlen 12
L2CAP(d): cid 0x0041 len 8 [psm 3]
RFCOMM(s): MSC CMD: cr 0 dlci 0 pf 0 ilen 4 fcs 0xaa mcc_len 2
dlci 18 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 1 b3 0 len 0
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 12
L2CAP(d): cid 0x0041 len 8 [psm 3]
RFCOMM(s): MSC CMD: cr 1 dlci 0 pf 0 ilen 4 fcs 0x70 mcc_len 2
dlci 18 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 1 b3 0 len 0
< ACL data: handle 42 flags 0x02 dlen 12
L2CAP(d): cid 0x0041 len 8 [psm 3]
RFCOMM(s): MSC RSP: cr 0 dlci 0 pf 0 ilen 4 fcs 0xaa mcc_len 2
dlci 18 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 1 b3 0 len 0
> ACL data: handle 42 flags 0x02 dlen 12
L2CAP(d): cid 0x0041 len 8 [psm 3]
RFCOMM(s): MSC RSP: cr 1 dlci 0 pf 0 ilen 4 fcs 0x70 mcc_len 2
dlci 18 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 1 b3 0 len 0
< ACL data: handle 42 flags 0x02 dlen 9
L2CAP(d): cid 0x0041 len 5 [psm 3]
RFCOMM(d): UIH: cr 0 dlci 18 pf 1 ilen 0 fcs 0x8 credits 33
> ACL data: handle 42 flags 0x02 dlen 16
L2CAP(d): cid 0x0041 len 12 [psm 3]
RFCOMM(d): UIH: cr 1 dlci 18 pf 1 ilen 7 fcs 0xd2 credits 4
OBEX: Connect cmd(f): len 7 version 1.0 flags 0 mtu 65535
< ACL data: handle 42 flags 0x02 dlen 15
L2CAP(d): cid 0x0041 len 11 [psm 3]
RFCOMM(d): UIH: cr 0 dlci 18 pf 0 ilen 7 fcs 0x14
OBEX: Connect rsp(f): status 200 len 7 version 1.0 flags 0 mtu 32767
Status 200 = Success
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 89
L2CAP(d): cid 0x0041 len 85 [psm 3]
RFCOMM(d): UIH: cr 1 dlci 18 pf 1 ilen 80 fcs 0xd2 credits 1
OBEX: Put cmd(c): len 80
Name (0x01) = Unicode length 36
0000: 00 33 00 32 00 33 00 6d 00 6d 00 3d 00 32 00 30
.3.2.3.m.m.=.2.0
0010: 00 20 00 31 00 30 00 6b 00 67 00 2e 00 74 00 78 .
.1.0.k.g...t.x
0020: 00 74 00 00 .t..
Length (0xc3) = 28
Type (0x42) = Sequence length 11
0000: 74 65 78 74 2f 70 6c 61 69 6e 00 text/plain.
Time (0x44) = Sequence length 16
0000: 32 30 31 30 30 36 32 32 54 30 35 33 38 33 30 5a
20100622T053830Z
< ACL data: handle 42 flags 0x02 dlen 11
L2CAP(d): cid 0x0041 len 7 [psm 3]
RFCOMM(d): UIH: cr 0 dlci 18 pf 0 ilen 3 fcs 0x14
OBEX: Put rsp(f): status 403 len 3
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 8
L2CAP(d): cid 0x0041 len 4 [psm 3]
RFCOMM(s): DISC: cr 1 dlci 18 pf 1 ilen 0 fcs 0xd3
< ACL data: handle 42 flags 0x02 dlen 8
L2CAP(d): cid 0x0041 len 4 [psm 3]
RFCOMM(s): UA: cr 1 dlci 18 pf 1 ilen 0 fcs 0xf9
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
< ACL data: handle 42 flags 0x02 dlen 8
L2CAP(d): cid 0x0041 len 4 [psm 3]
RFCOMM(s): DISC: cr 0 dlci 0 pf 1 ilen 0 fcs 0x9c
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 8
L2CAP(d): cid 0x0041 len 4 [psm 3]
RFCOMM(s): UA: cr 0 dlci 0 pf 1 ilen 0 fcs 0xb6
< ACL data: handle 42 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x0041 scid 0x0041
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> ACL data: handle 42 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x0041 scid 0x0041
> ACL data: handle 42 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x0040 scid 0x0040
< ACL data: handle 42 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x0040
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
^ permalink raw reply
* Re: obexd: obex_handle_input: poll event HUP ERR
From: Johan Hedberg @ 2010-06-22 7:58 UTC (permalink / raw)
To: Jiri Slaby; +Cc: linux-bluetooth
In-Reply-To: <4C206924.50303@gmail.com>
Hi,
On Tue, Jun 22, 2010, Jiri Slaby wrote:
> > libopenobex seems to be indicating REQDONE, so it doesn't look like
> > anything is necessarily wrong with obexd here. However, you'd need to
> > look at the HCI level trafic (output of "hcidump -XV") to determine
> > what's really going on (e.g. is it obexd or the client that's
> > disconnecting).
>
> Attached:
Thanks.
> # hcidump -XV
<snip>
> < ACL data: handle 42 flags 0x02 dlen 11
> L2CAP(d): cid 0x0041 len 7 [psm 3]
> RFCOMM(d): UIH: cr 0 dlci 18 pf 0 ilen 3 fcs 0x14
> OBEX: Put rsp(f): status 403 len 3
So obexd is responding with "forbidden" to the client.
Possible reasons:
* obexd doesn't have write access to the directory it's trying to
write to
* You don't have an agent registered for obexd that could accept
the request or you're not running obexd in the auto-accept mode
(the -a switch).
Johan
^ permalink raw reply
* Re: obexd: obex_handle_input: poll event HUP ERR
From: Jiri Slaby @ 2010-06-22 8:04 UTC (permalink / raw)
To: linux-bluetooth; +Cc: johan.hedberg
In-Reply-To: <20100622075833.GA14319@jh-x301>
On 06/22/2010 09:58 AM, Johan Hedberg wrote:
>> # hcidump -XV
> <snip>
>> < ACL data: handle 42 flags 0x02 dlen 11
>> L2CAP(d): cid 0x0041 len 7 [psm 3]
>> RFCOMM(d): UIH: cr 0 dlci 18 pf 0 ilen 3 fcs 0x14
>> OBEX: Put rsp(f): status 403 len 3
>
> So obexd is responding with "forbidden" to the client.
> Possible reasons:
>
> * obexd doesn't have write access to the directory it's trying to
> write to
>
> * You don't have an agent registered for obexd that could accept
> the request or you're not running obexd in the auto-accept mode
> (the -a switch).
Yeah, -a solved the problem. What does it mean to have an agent
registered? What is agent?
Thanks.
^ permalink raw reply
* Re: obexd: obex_handle_input: poll event HUP ERR
From: Johan Hedberg @ 2010-06-22 8:13 UTC (permalink / raw)
To: Jiri Slaby; +Cc: linux-bluetooth
In-Reply-To: <4C206E7F.5000604@gmail.com>
On Tue, Jun 22, 2010, Jiri Slaby wrote:
> Yeah, -a solved the problem. What does it mean to have an agent
> registered? What is agent?
If you don't want obexd to go blindly accepting files from random remote
devices you'll probably want some sort of user interaction on the server
side, right? One possibility would be to have a GUI process show a
"Accept file from ..." dialog every time there's an incoming request.
You might also want to choose exactly where on the filesystem obexd
stores the incoming file. Such choices would be made by an agent, i.e.
a process separate from obexd that has through D-Bus told obexd that it
can take care of incoming requests. There's an example command line
agent written in python available at test/simple-agent in the obexd
source tree. The actual D-Bus API of an agent is documented in
doc/agent-api.txt in the same source tree.
Johan
^ permalink raw reply
* Re: hci_scodata_packet: hci1 SCO packet for unknown connection handle 42
From: Andrei Moraru @ 2010-06-22 10:24 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-bluetooth
In-Reply-To: <20100618184911.GA14514@vigoh>
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
^ permalink raw reply
* Re: obexd: obex_handle_input: poll event HUP ERR
From: Jiri Slaby @ 2010-06-22 16:16 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Bastien Nocera
In-Reply-To: <20100622081345.GA14746@jh-x301>
On 06/22/2010 10:13 AM, Johan Hedberg wrote:
> On Tue, Jun 22, 2010, Jiri Slaby wrote:
>> Yeah, -a solved the problem. What does it mean to have an agent
>> registered? What is agent?
>
> If you don't want obexd to go blindly accepting files from random remote
> devices you'll probably want some sort of user interaction on the server
> side, right? One possibility would be to have a GUI process show a
> "Accept file from ..." dialog every time there's an incoming request.
> You might also want to choose exactly where on the filesystem obexd
> stores the incoming file. Such choices would be made by an agent, i.e.
> a process separate from obexd that has through D-Bus told obexd that it
> can take care of incoming requests. There's an example command line
> agent written in python available at test/simple-agent in the obexd
> source tree. The actual D-Bus API of an agent is documented in
> doc/agent-api.txt in the same source tree.
I have gnome-bluetooth-2.30, but I guess it was not converted to act
also as obexd Agent yet.
thanks,
--
js
^ permalink raw reply
* Re: obexd: obex_handle_input: poll event HUP ERR
From: Bastien Nocera @ 2010-06-22 16:34 UTC (permalink / raw)
To: Jiri Slaby; +Cc: linux-bluetooth
In-Reply-To: <4C20E1C8.9020409@gmail.com>
On Tue, 2010-06-22 at 18:16 +0200, Jiri Slaby wrote:
> On 06/22/2010 10:13 AM, Johan Hedberg wrote:
> > On Tue, Jun 22, 2010, Jiri Slaby wrote:
> >> Yeah, -a solved the problem. What does it mean to have an agent
> >> registered? What is agent?
> >
> > If you don't want obexd to go blindly accepting files from random remote
> > devices you'll probably want some sort of user interaction on the server
> > side, right? One possibility would be to have a GUI process show a
> > "Accept file from ..." dialog every time there's an incoming request.
> > You might also want to choose exactly where on the filesystem obexd
> > stores the incoming file. Such choices would be made by an agent, i.e.
> > a process separate from obexd that has through D-Bus told obexd that it
> > can take care of incoming requests. There's an example command line
> > agent written in python available at test/simple-agent in the obexd
> > source tree. The actual D-Bus API of an agent is documented in
> > doc/agent-api.txt in the same source tree.
>
> I have gnome-bluetooth-2.30, but I guess it was not converted to act
> also as obexd Agent yet.
gnome-bluetooth doesn't have any Obex server bits. You'd need to use
gnome-user-share to have Obex server capabilities, and it doesn't use
obexd right now, but obex-data-server.
Patches welcome :)
Cheers
^ permalink raw reply
* panic after shutting down an ERTM socket
From: Nathan Holstein @ 2010-06-22 19:55 UTC (permalink / raw)
To: Linux Bluetooth
I'm seeing a crash from an ERTM socket after it's been shutdown. I'm
running a back-ported series of patches from 6 weeks ago (commit
dfc909b) on a 2.6.32 kernel.
The crash I'm seeing seems to be due to a monitor timeout firing after
the parent l2cap_conn has been deleted. Here's the relevant bits from
the crash dump:
[ 2825.234283] l2cap_disconn_cfm (4390): hcon c6895600 reason 8
[ 2825.234771] l2cap_conn_del (612): hcon c6895600 conn c681f540, err 110
[ 2825.235229] l2cap_sock_clear_timer (121): sock c688f800 state 5
[ 2825.235443] l2cap_chan_del (262): sk c688f800, conn c681f540, err 110
[ 2825.235931] l2cap_sock_clear_timer (121): sock c6f7b800 state 1
[ 2825.236175] l2cap_chan_del (262): sk c6f7b800, conn c681f540, err 110
[ 2825.237243] l2cap_sock_release (2189): sock c759a560, sk c688f800
[ 2825.237487] l2cap_sock_shutdown (2162): sock c759a560, sk c688f800
[ 2825.238433] l2cap_sock_release (2189): sock c75a0b60, sk c6f7b800
[ 2825.238677] l2cap_sock_shutdown (2162): sock c75a0b60, sk c6f7b800
[ 2825.239105] l2cap_sock_clear_timer (121): sock c6f7b800 state 9
[ 2825.239349] __l2cap_sock_close (730): sk c6f7b800 state 9 socket c75a0b60
[ 2825.239776] l2cap_sock_kill (720): sk c6f7b800 state 9
[ 2825.243804] l2cap_sock_clear_timer (121): sock c688f800 state 9
[ 2825.244232] __l2cap_sock_close (730): sk c688f800 state 9 socket c759a560
[ 2825.244659] l2cap_sock_kill (720): sk c688f800 state 9
[ 2825.244903] l2cap_sock_destruct (692): sk c688f800
[ 2829.417694] l2cap_send_sframe (366): pi c6f7b800, control 0x10
[ 2829.418365] Unable to handle kernel NULL pointer dereference at virtual address 0000000c
[ 2829.627502] [<bf002e50>] (l2cap_monitor_timeout+0xc8/0x21c [l2cap]) from [<c005f918>] (run_timer_softirq+0x1a4/0x258)
[ 2829.628143] [<c005f918>] (run_timer_softirq+0x1a4/0x258) from [<c005b380>] (__do_softirq+0x70/0xf8)
[ 2829.628814] [<c005b380>] (__do_softirq+0x70/0xf8) from [<c005b44c>] (irq_exit+0x44/0xa8)
[ 2829.629180] [<c005b44c>] (irq_exit+0x44/0xa8) from [<c002606c>] (asm_do_IRQ+0x6c/0x84)
[ 2829.629821] [<c002606c>] (asm_do_IRQ+0x6c/0x84) from [<c0026a8c>] (__irq_svc+0x4c/0x8c)
The crash occurs when accessing conn->mtu within l2cap_send_sframe.
Looking through the logs, it appears that commit fd24051 might fix this
issue. If not, I'll look into this further.
--nathan
^ permalink raw reply
* Re: panic after shutting down an ERTM socket
From: Gustavo F. Padovan @ 2010-06-22 21:52 UTC (permalink / raw)
To: Nathan Holstein; +Cc: Linux Bluetooth
In-Reply-To: <1277236515.14834.477.camel@strawberry>
Hi Nathan,
* Nathan Holstein <ngh@isomerica.net> [2010-06-22 15:55:15 -0400]:
> I'm seeing a crash from an ERTM socket after it's been shutdown. I'm
> running a back-ported series of patches from 6 weeks ago (commit
> dfc909b) on a 2.6.32 kernel.
>
> The crash I'm seeing seems to be due to a monitor timeout firing after
> the parent l2cap_conn has been deleted. Here's the relevant bits from
> the crash dump:
> [ 2825.234283] l2cap_disconn_cfm (4390): hcon c6895600 reason 8
> [ 2825.234771] l2cap_conn_del (612): hcon c6895600 conn c681f540, err 110
> [ 2825.235229] l2cap_sock_clear_timer (121): sock c688f800 state 5
> [ 2825.235443] l2cap_chan_del (262): sk c688f800, conn c681f540, err 110
> [ 2825.235931] l2cap_sock_clear_timer (121): sock c6f7b800 state 1
> [ 2825.236175] l2cap_chan_del (262): sk c6f7b800, conn c681f540, err 110
> [ 2825.237243] l2cap_sock_release (2189): sock c759a560, sk c688f800
> [ 2825.237487] l2cap_sock_shutdown (2162): sock c759a560, sk c688f800
> [ 2825.238433] l2cap_sock_release (2189): sock c75a0b60, sk c6f7b800
> [ 2825.238677] l2cap_sock_shutdown (2162): sock c75a0b60, sk c6f7b800
> [ 2825.239105] l2cap_sock_clear_timer (121): sock c6f7b800 state 9
> [ 2825.239349] __l2cap_sock_close (730): sk c6f7b800 state 9 socket c75a0b60
> [ 2825.239776] l2cap_sock_kill (720): sk c6f7b800 state 9
> [ 2825.243804] l2cap_sock_clear_timer (121): sock c688f800 state 9
> [ 2825.244232] __l2cap_sock_close (730): sk c688f800 state 9 socket c759a560
> [ 2825.244659] l2cap_sock_kill (720): sk c688f800 state 9
> [ 2825.244903] l2cap_sock_destruct (692): sk c688f800
> [ 2829.417694] l2cap_send_sframe (366): pi c6f7b800, control 0x10
> [ 2829.418365] Unable to handle kernel NULL pointer dereference at virtual address 0000000c
>
> [ 2829.627502] [<bf002e50>] (l2cap_monitor_timeout+0xc8/0x21c [l2cap]) from [<c005f918>] (run_timer_softirq+0x1a4/0x258)
> [ 2829.628143] [<c005f918>] (run_timer_softirq+0x1a4/0x258) from [<c005b380>] (__do_softirq+0x70/0xf8)
> [ 2829.628814] [<c005b380>] (__do_softirq+0x70/0xf8) from [<c005b44c>] (irq_exit+0x44/0xa8)
> [ 2829.629180] [<c005b44c>] (irq_exit+0x44/0xa8) from [<c002606c>] (asm_do_IRQ+0x6c/0x84)
> [ 2829.629821] [<c002606c>] (asm_do_IRQ+0x6c/0x84) from [<c0026a8c>] (__irq_svc+0x4c/0x8c)
>
> The crash occurs when accessing conn->mtu within l2cap_send_sframe.
>
> Looking through the logs, it appears that commit fd24051 might fix this
> issue. If not, I'll look into this further.
Yes, it is already fixed.
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* Re: Software caused connection abort (103 )
From: john michelle @ 2010-06-22 22:48 UTC (permalink / raw)
To: Gustavo F. Padovan, linux-bluetooth; +Cc: marcel, torvalds
In-Reply-To: <AANLkTimkZQRzE39WG6Kw9PlYJpXONwA-BvEZxym2J6gi@mail.gmail.com>
Dear Bluetooth community,
You are committing version after version and have time to add new
Features and the core stack have a major bug (software Caused
connection abort) that i
Have reported on the 7th of may the problem seems to be either in the
usb part of the
Kernel or the bluez stack, i am no kernel engineer so i came directly
to you for reporting
This problem and my requests to look into this problem are just
ignored. this is a blocker
Issue that would prevent and discourage any one from developing
application that rely on
Bluez sco capabilities, since during transmission the above mentioned
error just occurs.
I hope that my voice is heared and i would get a reply from the bluez commu=
nity.
John
On Wed, Jun 16, 2010 at 3:11 PM, john michelle <jhnmichelle@gmail.com> wrot=
e:
> On Sun, May 30, 2010 at 1:12 PM, john michelle <jhnmichelle@gmail.com> wr=
ote:
>> Hi Gustavo,
>>
>>>> Please post the output of hcidump when the connection abort happens.
>>>>
>>
>> Below is the output of hcidump the moments the software caused connectio=
n abort
>>
>> Dongle 1:
>>> HCI Event: Number of Completed Packets (0x13) plen 5
>> =A0. * . . .
>> < HCI Command: Reset (0x03|0x0003) plen 0
>> device: disconnected
>>
>> Dongle 2:
>>> HCI Event: Number of Completed Packets (0x13) plen 5
>> =A0. * . . .
>> < HCI Command: Reset (0x03|0x0003) plen 0
>> device: disconnected
>>
>>
>> I think something triggers hci reset which causes this problem, but what=
exactly
>> Triggers it i don't know.
>>
>>
>> John
>>
>>
>
>
> Hi all,
>
> Is anyone going to give this problem a try, it has been like a month now
> This is a real problem in the bluez stack and someone have to look in thi=
s
> Issue.
>
> John
>
>> On Mon, May 17, 2010 at 5:21 PM, john michelle <jhnmichelle@gmail.com> w=
rote:
>>>> Hi Jonh,
>>>>
>>>> First of all, don't do top posting in this mailing list. ;)
>>>>
>>>
>>> Thanks for the advise , will keep that in mind for future posts.
>>>
>>>> In which bluez/kernel version the problem started? Any hardware update
>>>> during this time? The problem happens when you are already tranfering
>>>> SCO data?
>>>>
>>>
>>> I tried bluez versions 3.XX =A0and kernel 2.6.26(I think) the problem
>>> occurs and the kernel panics with no core dumps.then i tried with
>>> bluez 4.53-4.62 with
>>> Kernel 2.6.31 and 2.6.32. the connection abort problem occurs but the
>>> kernel doesn't
>>> Panic. regarding the hardware update you mean the dongle or the box.Any=
way
>>> i changed both and tried different box's, this even happens on a box
>>> with 2 giga ram
>>> And core2 processor . as for the dongles i am using trust
>>>
>>> http://www.twenga.co.uk/prices-Bluetooth-2-USB-Adapter-10m-BT-2250p-TRU=
ST-Wireless-network-card-adapter-176178-0
>>>
>>> =A0and also using no name dongles all the same problem.
>>>
>>>> Please post the output of hcidump when the connection abort happens.
>>>>
>>>
>>> well that is going to be a hard one since i have more than one dongle i=
n place
>>> And very hard to predict which one will crash.i will work on this and u=
pdate
>>> You as soon as i have the hcidump log.
>>>
>>>
>>>
>>>> I tried reproduce this issue in L2CAP but it is a bit hard, lets
>>>> say it happen once in a thousand, so it's not easy to track it. I have
>>>> to try reproduce that using the SCO, but I'm not used to that layer ye=
t.
>>>> ;)
>>>
>>> I hoped that it happens 1 in 1000 in SCO , but it actually happens 1 in=
15
>>>
>>>
>>> John
>>>
>>>
>>>
>>>>
>>>> Regards,
>>>>
>>>>>
>>>>> John
>>>>>
>>>>> On Fri, May 7, 2010 at 3:53 PM, Gustavo F. Padovan <gustavo@padovan.o=
rg> wrote:
>>>>> > * john michelle <jhnmichelle@gmail.com> [2010-05-07 15:49:05 -0400]=
:
>>>>> >
>>>>> >> Hi Bluetooth hackers,
>>>>> >>
>>>>> >> i am having this consistent problem with bluez , from time to time=
i
>>>>> >> get the error Software caused connection abort (103 )
>>>>> >> And the bluetooth stick seems to disconnect and reconnects. this
>>>>> >> happens during an sco connection and it occurs even
>>>>> >> More when i am having the voice stream comming through the interne=
t
>>>>> >> rather than the lan.i don't know what exact
>>>>> >> Details you need to solve this problem please tell me and i will g=
ive
>>>>> >> you an immediate reply . i have linux kernel 2.6.33 and bluez 4.62
>>>>> >
>>>>> > I get the same problem sometimes when testing ERTM with l2test. So =
the
>>>>> > problem is on l2cap too. I didn't have time to debug this yet. Now =
that
>>>>> > someone else have confirmed it too, I'll to take a look at the prob=
lem.
>>>>> >
>>>>> >>
>>>>
>>>> --
>>>> Gustavo F. Padovan
>>>> http://padovan.org
>>>>
>>>
>>
>
^ permalink raw reply
* [PATCH] Bluetooth: check l2cap pending status before sending l2cap connect request
From: Emeltchenko Andrei @ 2010-06-23 7:30 UTC (permalink / raw)
To: linux-bluetooth
From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
Due to race condition in L2CAP state machine L2CAP Connection Request
may be sent twice for SDP with the same source channel id. Problems
reported connecting to Apple products, some carkit, Blackberry phones.
...
2010-06-07 21:18:03.651031 < ACL data: handle 1 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 1 scid 0x0040
2010-06-07 21:18:03.653473 > HCI Event: Number of Completed Packets (0x13) plen 5
handle 1 packets 1
2010-06-07 21:18:03.653808 > HCI Event: Auth Complete (0x06) plen 3
status 0x00 handle 1
2010-06-07 21:18:03.653869 < ACL data: handle 1 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 1 scid 0x0040
...
Patch uses L2CAP_CONF_CONNECT_PEND flag to mark that L2CAP Connection
Request has been sent.
Modified version of Ville Tervo patch.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
---
net/bluetooth/l2cap.c | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index bb00015..7f82f7b 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -409,13 +409,16 @@ static void l2cap_do_start(struct sock *sk)
if (!(conn->info_state & L2CAP_INFO_FEAT_MASK_REQ_DONE))
return;
- if (l2cap_check_security(sk)) {
+ if (l2cap_check_security(sk) &&
+ !(l2cap_pi(sk)->conf_state &
+ L2CAP_CONF_CONNECT_PEND)) {
struct l2cap_conn_req req;
req.scid = cpu_to_le16(l2cap_pi(sk)->scid);
req.psm = l2cap_pi(sk)->psm;
l2cap_pi(sk)->ident = l2cap_get_ident(conn);
+ l2cap_pi(sk)->conf_state |= L2CAP_CONF_CONNECT_PEND;
l2cap_send_cmd(conn, l2cap_pi(sk)->ident,
L2CAP_CONN_REQ, sizeof(req), &req);
}
@@ -464,13 +467,16 @@ static void l2cap_conn_start(struct l2cap_conn *conn)
}
if (sk->sk_state == BT_CONNECT) {
- if (l2cap_check_security(sk)) {
+ if (l2cap_check_security(sk) &&
+ !(l2cap_pi(sk)->conf_state &
+ L2CAP_CONF_CONNECT_PEND)) {
struct l2cap_conn_req req;
req.scid = cpu_to_le16(l2cap_pi(sk)->scid);
req.psm = l2cap_pi(sk)->psm;
l2cap_pi(sk)->ident = l2cap_get_ident(conn);
+ l2cap_pi(sk)->conf_state |= L2CAP_CONF_CONNECT_PEND;
l2cap_send_cmd(conn, l2cap_pi(sk)->ident,
L2CAP_CONN_REQ, sizeof(req), &req);
}
@@ -4407,6 +4413,7 @@ static int l2cap_security_cfm(struct hci_conn *hcon, u8 status, u8 encrypt)
l2cap_pi(sk)->ident = l2cap_get_ident(conn);
+ l2cap_pi(sk)->conf_state |= L2CAP_CONF_CONNECT_PEND;
l2cap_send_cmd(conn, l2cap_pi(sk)->ident,
L2CAP_CONN_REQ, sizeof(req), &req);
} else {
--
1.7.0.4
^ permalink raw reply related
* Re: hci_scodata_packet: hci1 SCO packet for unknown connection handle 42
From: Andrei Moraru @ 2010-06-23 17:36 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-bluetooth
In-Reply-To: <AANLkTimqxFFOM097G55yebL1VV7ZNOqmeeiEC7kyCu7A@mail.gmail.com>
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.
^ permalink raw reply
* [PATCH] audio: fix memory leak with typefinding
From: harri.mahonen @ 2010-06-23 19:10 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Harri Mahonen
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);
--
1.7.0.4
^ permalink raw reply related
* 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