* Re: [PATCH 3/3] Bluetooth: Synchronize SCO/eSCO connection requests to ACL state
From: Matthew Wilson @ 2010-07-14 20:55 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Perelet, Oleg, Ron Shaffer, linux-bluetooth@vger.kernel.org,
Wilson, Matt
In-Reply-To: <1279135803.6282.58.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 755 bytes --]
Marcel,
On Jul 14, 2010, at 2:30 PM, Marcel Holtmann <marcel@holtmann.org> wrote:
>>
>>
>>
>
> is there really a problem? The LMP will send an error via HCI. So we do
> get the mode changed event, but just with an error. And since we are not
> checking the error at all, we just go ahead with the SCO setup attempt
> in that case.
The attempt to start SCO after the related ACL is no longer present makes no sense.
Either after mode change event with no success or disconnection complete event the result is the same; there is no valid ACL to attempt SCO/eSCO.
Error code 0x02 "unknown connection identifier" may apply for the command status event for setup synchronous connection command but the spec does not require it.
-Matt
[-- Attachment #2: Type: text/html, Size: 2140 bytes --]
^ permalink raw reply
* RE: [PATCH 3/3] Bluetooth: Synchronize SCO/eSCO connection requests to ACL state
From: Marcel Holtmann @ 2010-07-14 19:30 UTC (permalink / raw)
To: Perelet, Oleg; +Cc: Ron Shaffer, linux-bluetooth@vger.kernel.org, Wilson, Matt
In-Reply-To: <BCDE476F204B134B8B235FB275BC3AD810407AA0CD@NALASEXMB01.na.qualcomm.com>
Hi Oleg,
> >I find your patch actually highly complicated. So I tried to capture
> >your intend the in the attached patch (only compiled test) and it would
> >be good if you can try that.
>
> Marcel, your fix is mode delicate compared to original and has same functionality.
>
> There's small problem with both yours & Rons - there's no error handling for case when other device will never ACK's unsniff - you pretty much DOS session if there's no reply. No real HS will do that but it may present security flaw. I do not know how severe is that
>
> I attached original conversation when we 1st time seen the problem.
is there really a problem? The LMP will send an error via HCI. So we do
get the mode changed event, but just with an error. And since we are not
checking the error at all, we just go ahead with the SCO setup attempt
in that case.
Regards
Marcel
^ permalink raw reply
* RE: [PATCH 3/3] Bluetooth: Synchronize SCO/eSCO connection requests to ACL state
From: Perelet, Oleg @ 2010-07-14 19:20 UTC (permalink / raw)
To: Marcel Holtmann, Ron Shaffer
Cc: linux-bluetooth@vger.kernel.org, Wilson, Matt
In-Reply-To: <1278972477.6282.10.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1794 bytes --]
>I find your patch actually highly complicated. So I tried to capture
>your intend the in the attached patch (only compiled test) and it would
>be good if you can try that.
Marcel, your fix is mode delicate compared to original and has same functionality.
There's small problem with both yours & Rons - there's no error handling for case when other device will never ACK's unsniff - you pretty much DOS session if there's no reply. No real HS will do that but it may present security flaw. I do not know how severe is that
I attached original conversation when we 1st time seen the problem.
Oleg.
-----Original Message-----
From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of Marcel Holtmann
Sent: Monday, July 12, 2010 5:08 PM
To: Ron Shaffer
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: [PATCH 3/3] Bluetooth: Synchronize SCO/eSCO connection requests to ACL state
Hi Ron,
> Certain headsets such as the Motorola H350 will reject SCO and eSCO
> connection requests while the ACL is transitioning from sniff mode
> to active mode. Add synchronization so that SCO and eSCO connection
> requests will wait until the ACL has fully transitioned to active mode.
I find your patch actually highly complicated. So I tried to capture
your intend the in the attached patch (only compiled test) and it would
be good if you can try that.
So in general it makes no difference which mode we are in. If a mode
change is pending, then we have to delay the SCO setup. And once we are
done we the mode change we just setup the SCO link. So in theory that
should be enough. Not sure if that is true. I could have overlooked
something since I don't really have tested the patch at all ;)
Regards
Marcel
[-- Attachment #2: Type: message/rfc822, Size: 4099 bytes --]
From: "Perelet, Oleg" <operelet@quicinc.com>
To: Nick Pelly <npelly@google.com>, "Shaffer, Ron" <rshaffer@quicinc.com>
Subject: RE: mot hs850
Date: Fri, 19 Mar 2010 10:00:16 -0700
Nick, finally we understand what's wrong with HS830 (I think I called it 850 before:)
It won't accept eSCO(or SCO for that matter, packet types do not apply in this problem) until it ack's unsniff requests - dumb but reality.
This involved a bit more logic after doing:
+ acl->power_save = 1;
+ hci_conn_enter_active_mode(acl);
+
in
http://git.kernel.org/?p=linux/kernel/git/holtmann/bluetooth-2.6.git;a=blobdiff;f=net/bluetooth/hci_conn.c;h=b10e3cdb08f87358ca64d0db8cf83c27f5ad624a;hp=b7c4224f4e7dee01288dd31f4581f7a8821c7a21;hb=c390216b3e868b16d8154939f4b6f8c16dbd9a9f;hpb=88d1a0cf659438a66135661538ae332b23f8635a
you actually need to wait for ack for it before doing hci_setup_sync. Ron extending kernel do to that and we'll mail you patch.
But honestly I think this sort of change should live in userland. Problem is that you do not have libbuetooth up in Java to issue unsniff request and wait for ack for it. Maybe having raw hci going up from java? I do not know - have you thought about this?
Oleg.
-----Original Message-----
From: Nick Pelly [mailto:npelly@google.com]
Sent: Tuesday, March 16, 2010 4:45 PM
To: Shaffer, Ron
Cc: Perelet, Oleg
Subject: Re: mot hs850
On Tue, Mar 16, 2010 at 2:35 PM, Shaffer, Ron <rshaffer@quicinc.com> wrote:
> Hey Nick:
>
>> -----Original Message-----
>> From: Nick Pelly [mailto:npelly@google.com]
>> Sent: Tuesday, March 16, 2010 4:19 PM
>> To: Perelet, Oleg
>> Cc: Shaffer, Ron
>> Subject: Re: mot hs850
>>
>> I haven't tested with that one....what happens?
>
> The issue the we've run into is an eSCO negotiation problem with mot h350.
> It fails to make eSCO or SCO connection after adding in the patch below to
> handle the slow eSCO negotiation when in sniff.
>
> In particular, we request eSCO with 3-EV5, the headset says no let's do 2-EV3,
> then we say how about 3-EV3, and the headset says go pound sand.
>
> It really looks like a headset issue that we're trying to work around.
>
> I took a look at Bluetooth: Allow SCO/eSCO packet type selection for outgoing
> SCO connections,
> http://android.git.kernel.org/?p=kernel/common.git;a=commit;
> h=3b077241e02041b1f03fee912896b8de1d7ac096
>
> and I was wondering if the above behavior is what you saw prior to this patch.
The packet type selection patch was motivated by other headsets, but
can probably be used to resolve this issue as well. I think if you
experiment with disabling 3-EV3 and maybe 3-EV5 packet types with this
headset we might find packets that work. Please let me know if you
find the right packet mask so we can roll it in. With Froyo we are
introducing a config file to set packet type masks with known bad
headsets
I don't want to revert the exit sniff mode patch - it fixes a lot of
slow SCO problems and makes sense.
Nick
^ permalink raw reply
* Re: [PATCH] Additional handling incoming call indication for HS
From: Hedberg Johan (Nokia-D/Helsinki) @ 2010-07-14 17:08 UTC (permalink / raw)
To: Radoslaw Jablonski; +Cc: linux-bluetooth
In-Reply-To: <1279120839-14050-1-git-send-email-ext-jablonski.radoslaw@nokia.com>
Hi,
On Wed, Jul 14, 2010, Radoslaw Jablonski wrote:
> Some headsets expect incoming call indication before they can send ATA
> command. In current implementation of telephony we do not send outband
> notyfication about incoming call when call previously was in WAITING
> state. And without that kind of notyfication BH-108 and BackBeat 903
> headset cannot send ATA command - user is unable to answer to that call
> from headset.
>
> Added handling for that case in func handle_call_status(). When phone now
> is in CSD_CALL_STATUS_MT_ALERTING and previously was in
> CSD_CALL_STATUS_WAITING that means we need to send incoming call
> notyfication (it was not sent earlier because new call was waiting for end
> of active call). This will send RING commands to headset if it is needed.
> ---
> audio/telephony-maemo6.c | 15 ++++++++++++---
> 1 files changed, 12 insertions(+), 3 deletions(-)
Thanks. The patch is now pushed upstream.
Johan
^ permalink raw reply
* [PATCH] Additional handling incoming call indication for HS
From: Radoslaw Jablonski @ 2010-07-14 15:20 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Radoslaw Jablonski
Some headsets expect incoming call indication before they can send ATA
command. In current implementation of telephony we do not send outband
notyfication about incoming call when call previously was in WAITING
state. And without that kind of notyfication BH-108 and BackBeat 903
headset cannot send ATA command - user is unable to answer to that call
from headset.
Added handling for that case in func handle_call_status(). When phone now
is in CSD_CALL_STATUS_MT_ALERTING and previously was in
CSD_CALL_STATUS_WAITING that means we need to send incoming call
notyfication (it was not sent earlier because new call was waiting for end
of active call). This will send RING commands to headset if it is needed.
---
audio/telephony-maemo6.c | 15 ++++++++++++---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/audio/telephony-maemo6.c b/audio/telephony-maemo6.c
index 046620c..6e5166b 100644
--- a/audio/telephony-maemo6.c
+++ b/audio/telephony-maemo6.c
@@ -976,7 +976,7 @@ static void handle_create_requested(DBusMessage *msg)
static void handle_call_status(DBusMessage *msg, const char *call_path)
{
struct csd_call *call;
- dbus_uint32_t status, cause_type, cause;
+ dbus_uint32_t status, cause_type, cause, prev_status;
int callheld = telephony_get_indicator(maemo_indicators, "callheld");
if (!dbus_message_get_args(msg, NULL,
@@ -1000,10 +1000,11 @@ static void handle_call_status(DBusMessage *msg, const char *call_path)
return;
}
+ prev_status = call->status;
DBG("Call %s changed from %s to %s", call_path,
- call_status_str[call->status], call_status_str[status]);
+ call_status_str[prev_status], call_status_str[status]);
- if (call->status == (int) status) {
+ if (prev_status == status) {
DBG("Ignoring CSD Call state change to existing state");
return;
}
@@ -1043,6 +1044,14 @@ static void handle_call_status(DBusMessage *msg, const char *call_path)
EV_CALLSETUP_ALERTING);
break;
case CSD_CALL_STATUS_MT_ALERTING:
+ /* Some headsets expect incoming call notification before they
+ * can send ATA command. When call changed status from waiting
+ * to alerting we need to send missing notification. Otherwise
+ * headsets like Nokia BH-108 or BackBeat 903 are unable to
+ * answer incoming call that was previously waiting. */
+ if (prev_status == CSD_CALL_STATUS_WAITING)
+ telephony_incoming_call_ind(call->number, number_type(
+ call->number));
break;
case CSD_CALL_STATUS_WAITING:
break;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] Additional handling incoming call indication for HS
From: Hedberg Johan (Nokia-D/Helsinki) @ 2010-07-14 14:33 UTC (permalink / raw)
To: Radoslaw Jablonski; +Cc: linux-bluetooth
In-Reply-To: <1279116737-27025-1-git-send-email-ext-jablonski.radoslaw@nokia.com>
Hi,
On Wed, Jul 14, 2010, Radoslaw Jablonski wrote:
> Some headsets expect incoming call indication before they can send ATA
> command. In current implementation of telephony we do not send outband
> notyfication about incoming call when call previously was in WAITING state.
> And without that kind of notyfication BH-108 and BackBeat 903 headset cannot
> send ATA command - user is unable to answer to that call from headset.
>
> Added handling for that case in func handle_call_status(). When phone now is
> in CSD_CALL_STATUS_MT_ALERTING and previously was in CSD_CALL_STATUS_WAITING
> that means we need to send incoming call notyfication (it was not sent earlier
> because new call was waiting for end of active call). This will send RING
> commands to headset if it is needed.
> ---
> audio/telephony-maemo6.c | 15 ++++++++++++---
> 1 files changed, 12 insertions(+), 3 deletions(-)
Thanks for the patch. There are a few issues that'll need to be fixed
before pushing it upstream. The most serious one is this:
audio/telephony-maemo6.c: In function ‘handle_call_status’:
audio/telephony-maemo6.c:1007: error: comparison between signed and
unsigned integer expressions
Please always check compilation with ./bootstrap-configure since that'll
cause any warnings to show up as errors.
Another issue is the commit message width. Please keep it at a maximum
of 74 characters so that it's nicely viewable using git log on a
80-character wide terminal.
And then the following (minor) whitespace issue:
> + if(prev_status == CSD_CALL_STATUS_WAITING)
There should be a space between the if and the parenthesis. Otherwise
the patch was fine. So please fix these issues and resubmit. Thanks.
Johan
^ permalink raw reply
* [PATCH] Additional handling incoming call indication for HS
From: Radoslaw Jablonski @ 2010-07-14 14:12 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Radoslaw Jablonski
Some headsets expect incoming call indication before they can send ATA
command. In current implementation of telephony we do not send outband
notyfication about incoming call when call previously was in WAITING state.
And without that kind of notyfication BH-108 and BackBeat 903 headset cannot
send ATA command - user is unable to answer to that call from headset.
Added handling for that case in func handle_call_status(). When phone now is
in CSD_CALL_STATUS_MT_ALERTING and previously was in CSD_CALL_STATUS_WAITING
that means we need to send incoming call notyfication (it was not sent earlier
because new call was waiting for end of active call). This will send RING
commands to headset if it is needed.
---
audio/telephony-maemo6.c | 15 ++++++++++++---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/audio/telephony-maemo6.c b/audio/telephony-maemo6.c
index 046620c..6255c28 100644
--- a/audio/telephony-maemo6.c
+++ b/audio/telephony-maemo6.c
@@ -976,7 +976,7 @@ static void handle_create_requested(DBusMessage *msg)
static void handle_call_status(DBusMessage *msg, const char *call_path)
{
struct csd_call *call;
- dbus_uint32_t status, cause_type, cause;
+ dbus_uint32_t status, cause_type, cause, prev_status;
int callheld = telephony_get_indicator(maemo_indicators, "callheld");
if (!dbus_message_get_args(msg, NULL,
@@ -1000,10 +1000,11 @@ static void handle_call_status(DBusMessage *msg, const char *call_path)
return;
}
+ prev_status = call->status;
DBG("Call %s changed from %s to %s", call_path,
- call_status_str[call->status], call_status_str[status]);
+ call_status_str[prev_status], call_status_str[status]);
- if (call->status == (int) status) {
+ if (prev_status == (int) status) {
DBG("Ignoring CSD Call state change to existing state");
return;
}
@@ -1043,6 +1044,14 @@ static void handle_call_status(DBusMessage *msg, const char *call_path)
EV_CALLSETUP_ALERTING);
break;
case CSD_CALL_STATUS_MT_ALERTING:
+ /* Some headsets expect incoming call notification before they
+ * can send ATA command. When call changed status from waiting
+ * to alerting we need to send missing notification. Otherwise
+ * headsets like Nokia BH-108 or BackBeat 903 are unable to
+ * answer incoming call that was previously waiting. */
+ if(prev_status == CSD_CALL_STATUS_WAITING)
+ telephony_incoming_call_ind(call->number,
+ number_type(call->number));
break;
case CSD_CALL_STATUS_WAITING:
break;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH v7 1/4] add one more buffer for stream reassembly
From: suraj @ 2010-07-14 13:03 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Suraj Sumangala, linux-bluetooth@vger.kernel.org,
Jothikumar Mothilal
In-Reply-To: <1279111625.6282.48.camel@localhost.localdomain>
Hi Marcel
On Wed, 2010-07-14 at 18:17 +0530, Marcel Holtmann wrote:
> Hi Suraj,
>
> Next please be more verbose there and
> prefix the subject with Bluetooth:
>
> Regards
>
> Marcel
Thanks, I will be careful next time.
Regards
Suraj
^ permalink raw reply
* Re: [PATCH v7 1/4] add one more buffer for stream reassembly
From: Marcel Holtmann @ 2010-07-14 12:47 UTC (permalink / raw)
To: Suraj Sumangala; +Cc: linux-bluetooth, Jothikumar.Mothilal
In-Reply-To: <1279111314.6282.46.camel@localhost.localdomain>
Hi Suraj,
> > Additional reassembly buffer to keep track of stream reasembly
> >
> > Signed-off-by: Suraj Sumangala <suraj@atheros.com>
> > ---
> > include/net/bluetooth/hci_core.h | 4 ++--
> > net/bluetooth/hci_core.c | 6 +++---
> > 2 files changed, 5 insertions(+), 5 deletions(-)
>
> I am failing to apply this patch against bluetooth-next-2.6 tree. Can
> you please ensure they apply cleanly.
forget about this. Problem was on my side. So I applied all for patches
and fixed up the commit messages. Next please be more verbose there and
prefix the subject with Bluetooth:
Regards
Marcel
^ permalink raw reply
* Re: [PATCH v7 1/4] add one more buffer for stream reassembly
From: Marcel Holtmann @ 2010-07-14 12:41 UTC (permalink / raw)
To: Suraj Sumangala; +Cc: linux-bluetooth, Jothikumar.Mothilal
In-Reply-To: <1279092739-4623-1-git-send-email-suraj@atheros.com>
Hi Suraj,
> Additional reassembly buffer to keep track of stream reasembly
>
> Signed-off-by: Suraj Sumangala <suraj@atheros.com>
> ---
> include/net/bluetooth/hci_core.h | 4 ++--
> net/bluetooth/hci_core.c | 6 +++---
> 2 files changed, 5 insertions(+), 5 deletions(-)
I am failing to apply this patch against bluetooth-next-2.6 tree. Can
you please ensure they apply cleanly.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Added support for bluetooth controller shipped with iMac i5
From: Cyril Lacoux (Yack) @ 2010-07-14 9:07 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1279094407.6282.27.camel@localhost.localdomain>
Le mercredi 14 juillet 2010 12:00:07, vous avez =C3=A9crit :
Marcel,
> patch has been applied. Thanks.
Thanks, some users will enjoy 2.6.36 :-)=20
Regards,
=2D-=20
Cyril Lacoux -- BOFH excuse #423:
It's not RFC-822 compliant.
^ permalink raw reply
* Re: [PATCH] Added support for bluetooth controller shipped with iMac i5
From: Marcel Holtmann @ 2010-07-14 8:00 UTC (permalink / raw)
To: Cyril Lacoux; +Cc: linux-bluetooth
In-Reply-To: <1279088967-13430-1-git-send-email-clacoux@ifeelgood.org>
Hi Cyril,
> Device class is ff(vend.) instead of e0(wlcon).
>
> Output from command `usb-devices`:
> T: Bus=01 Lev=03 Prnt=03 Port=00 Cnt=01 Dev#= 6 Spd=12 MxCh= 0
> D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
> P: Vendor=05ac ProdID=8215 Rev=01.82
> S: Manufacturer=Apple Inc.
> S: Product=Bluetooth USB Host Controller
> S: SerialNumber=7C6D62936607
> C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
> I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
> I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
> I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=00 Driver=(none)
>
> Signed-off-by: Cyril Lacoux <clacoux@ifeelgood.org>
> ---
> drivers/bluetooth/btusb.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
patch has been applied. Thanks.
Regards
Marcel
^ permalink raw reply
* [PATCH v7 4/4] Implemented HCI frame reassembly for Rx from stream
From: Suraj Sumangala @ 2010-07-14 7:32 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Jothikumar.Mothilal, Suraj Sumangala
In-Reply-To: <1279092739-4623-3-git-send-email-suraj@atheros.com>
Implemented frame reassembly implementation for reassembling fragments
received from stream.
Signed-off-by: Suraj Sumangala <suraj@atheros.com>
---
include/net/bluetooth/hci_core.h | 1 +
net/bluetooth/hci_core.c | 35 +++++++++++++++++++++++++++++++++++
2 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 28e5eee..350b3e6 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -437,6 +437,7 @@ void hci_event_packet(struct hci_dev *hdev, struct sk_buff *skb);
int hci_recv_frame(struct sk_buff *skb);
int hci_recv_fragment(struct hci_dev *hdev, int type, void *data, int count);
+int hci_recv_stream_fragment(struct hci_dev *hdev, void *data, int count);
int hci_register_sysfs(struct hci_dev *hdev);
void hci_unregister_sysfs(struct hci_dev *hdev);
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 451e266..995c9f9 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -1163,6 +1163,41 @@ int hci_recv_fragment(struct hci_dev *hdev, int type, void *data, int count)
}
EXPORT_SYMBOL(hci_recv_fragment);
+#define STREAM_REASSEMBLY 0
+
+int hci_recv_stream_fragment(struct hci_dev *hdev, void *data, int count)
+{
+ int type;
+ int rem = 0;
+
+ do {
+ struct sk_buff *skb = hdev->reassembly[STREAM_REASSEMBLY];
+
+ if (!skb) {
+ struct { char type; } *pkt;
+
+ /* Start of the frame */
+ pkt = data;
+ type = pkt->type;
+
+ data++;
+ count--;
+ } else
+ type = bt_cb(skb)->pkt_type;
+
+ rem = hci_reassembly(hdev, type, data,
+ count, STREAM_REASSEMBLY, GFP_ATOMIC);
+ if (rem < 0)
+ return rem;
+
+ data += (count - rem);
+ count = rem;
+ } while (count);
+
+ return rem;
+}
+EXPORT_SYMBOL(hci_recv_stream_fragment);
+
/* ---- Interface to upper protocols ---- */
/* Register/Unregister protocols.
--
1.7.0.4
^ permalink raw reply related
* [PATCH v7 3/4] Modified hci_recv_fragment() to use hci_reassembly
From: Suraj Sumangala @ 2010-07-14 7:32 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Jothikumar.Mothilal, Suraj Sumangala
In-Reply-To: <1279092739-4623-2-git-send-email-suraj@atheros.com>
modified packet based reassembly function hci_recv_fragment() to use hci_reassembly()
Signed-off-by: Suraj Sumangala <suraj@atheros.com>
---
net/bluetooth/hci_core.c | 85 ++++++----------------------------------------
1 files changed, 11 insertions(+), 74 deletions(-)
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 477c4a6..451e266 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -1142,87 +1142,24 @@ static int hci_reassembly(struct hci_dev *hdev, int type, void *data,
return remain;
}
-/* Receive packet type fragment */
-#define __reassembly(hdev, type) ((hdev)->reassembly[(type) - 1])
-
int hci_recv_fragment(struct hci_dev *hdev, int type, void *data, int count)
{
+ int rem = 0;
+
if (type < HCI_ACLDATA_PKT || type > HCI_EVENT_PKT)
return -EILSEQ;
- while (count) {
- struct sk_buff *skb = __reassembly(hdev, type);
- struct { int expect; } *scb;
- int len = 0;
-
- if (!skb) {
- /* Start of the frame */
-
- switch (type) {
- case HCI_EVENT_PKT:
- if (count >= HCI_EVENT_HDR_SIZE) {
- struct hci_event_hdr *h = data;
- len = HCI_EVENT_HDR_SIZE + h->plen;
- } else
- return -EILSEQ;
- break;
-
- case HCI_ACLDATA_PKT:
- if (count >= HCI_ACL_HDR_SIZE) {
- struct hci_acl_hdr *h = data;
- len = HCI_ACL_HDR_SIZE + __le16_to_cpu(h->dlen);
- } else
- return -EILSEQ;
- break;
-
- case HCI_SCODATA_PKT:
- if (count >= HCI_SCO_HDR_SIZE) {
- struct hci_sco_hdr *h = data;
- len = HCI_SCO_HDR_SIZE + h->dlen;
- } else
- return -EILSEQ;
- break;
- }
-
- skb = bt_skb_alloc(len, GFP_ATOMIC);
- if (!skb) {
- BT_ERR("%s no memory for packet", hdev->name);
- return -ENOMEM;
- }
-
- skb->dev = (void *) hdev;
- bt_cb(skb)->pkt_type = type;
-
- __reassembly(hdev, type) = skb;
-
- scb = (void *) skb->cb;
- scb->expect = len;
- } else {
- /* Continuation */
-
- scb = (void *) skb->cb;
- len = scb->expect;
- }
-
- len = min(len, count);
-
- memcpy(skb_put(skb, len), data, len);
-
- scb->expect -= len;
-
- if (scb->expect == 0) {
- /* Complete frame */
+ do {
+ rem = hci_reassembly(hdev, type, data, count,
+ type - 1, GFP_ATOMIC);
+ if (rem < 0)
+ return rem;
- __reassembly(hdev, type) = NULL;
+ data += (count - rem);
+ count = rem;
+ } while (count);
- bt_cb(skb)->pkt_type = type;
- hci_recv_frame(skb);
- }
-
- count -= len; data += len;
- }
-
- return 0;
+ return rem;
}
EXPORT_SYMBOL(hci_recv_fragment);
--
1.7.0.4
^ permalink raw reply related
* [PATCH v7 2/4] Implements hci_reassembly to reassemble Rx packets
From: Suraj Sumangala @ 2010-07-14 7:32 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Jothikumar.Mothilal, Suraj Sumangala
In-Reply-To: <1279092739-4623-1-git-send-email-suraj@atheros.com>
Implements feature to reassemble received HCI frames from any input stream
Signed-off-by: Suraj Sumangala <suraj@atheros.com>
---
include/net/bluetooth/bluetooth.h | 1 +
net/bluetooth/hci_core.c | 109 +++++++++++++++++++++++++++++++++++++
2 files changed, 110 insertions(+), 0 deletions(-)
diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
index ff77e8f..d6b150c 100644
--- a/include/net/bluetooth/bluetooth.h
+++ b/include/net/bluetooth/bluetooth.h
@@ -138,6 +138,7 @@ struct sock *bt_accept_dequeue(struct sock *parent, struct socket *newsock);
struct bt_skb_cb {
__u8 pkt_type;
__u8 incoming;
+ __u16 expect;
__u8 tx_seq;
__u8 retries;
__u8 sar;
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 0ded790..477c4a6 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -1033,6 +1033,115 @@ int hci_recv_frame(struct sk_buff *skb)
}
EXPORT_SYMBOL(hci_recv_frame);
+static int hci_reassembly(struct hci_dev *hdev, int type, void *data,
+ int count, __u8 index, gfp_t gfp_mask)
+{
+ int len = 0;
+ int hlen = 0;
+ int remain = count;
+ struct sk_buff *skb;
+ struct bt_skb_cb *scb;
+
+ if ((type < HCI_ACLDATA_PKT || type > HCI_EVENT_PKT) ||
+ index >= NUM_REASSEMBLY)
+ return -EILSEQ;
+
+ skb = hdev->reassembly[index];
+
+ if (!skb) {
+ switch (type) {
+ case HCI_ACLDATA_PKT:
+ len = HCI_MAX_FRAME_SIZE;
+ hlen = HCI_ACL_HDR_SIZE;
+ break;
+ case HCI_EVENT_PKT:
+ len = HCI_MAX_EVENT_SIZE;
+ hlen = HCI_EVENT_HDR_SIZE;
+ break;
+ case HCI_SCODATA_PKT:
+ len = HCI_MAX_SCO_SIZE;
+ hlen = HCI_SCO_HDR_SIZE;
+ break;
+ }
+
+ skb = bt_skb_alloc(len, gfp_mask);
+ if (!skb)
+ return -ENOMEM;
+
+ scb = (void *) skb->cb;
+ scb->expect = hlen;
+ scb->pkt_type = type;
+
+ skb->dev = (void *) hdev;
+ hdev->reassembly[index] = skb;
+ }
+
+ while (count) {
+ scb = (void *) skb->cb;
+ len = min(scb->expect, (__u16)count);
+
+ memcpy(skb_put(skb, len), data, len);
+
+ count -= len;
+ data += len;
+ scb->expect -= len;
+ remain = count;
+
+ switch (type) {
+ case HCI_EVENT_PKT:
+ if (skb->len == HCI_EVENT_HDR_SIZE) {
+ struct hci_event_hdr *h = hci_event_hdr(skb);
+ scb->expect = h->plen;
+
+ if (skb_tailroom(skb) < scb->expect) {
+ kfree_skb(skb);
+ hdev->reassembly[index] = NULL;
+ return -ENOMEM;
+ }
+ }
+ break;
+
+ case HCI_ACLDATA_PKT:
+ if (skb->len == HCI_ACL_HDR_SIZE) {
+ struct hci_acl_hdr *h = hci_acl_hdr(skb);
+ scb->expect = __le16_to_cpu(h->dlen);
+
+ if (skb_tailroom(skb) < scb->expect) {
+ kfree_skb(skb);
+ hdev->reassembly[index] = NULL;
+ return -ENOMEM;
+ }
+ }
+ break;
+
+ case HCI_SCODATA_PKT:
+ if (skb->len == HCI_SCO_HDR_SIZE) {
+ struct hci_sco_hdr *h = hci_sco_hdr(skb);
+ scb->expect = h->dlen;
+
+ if (skb_tailroom(skb) < scb->expect) {
+ kfree_skb(skb);
+ hdev->reassembly[index] = NULL;
+ return -ENOMEM;
+ }
+ }
+ break;
+ }
+
+ if (scb->expect == 0) {
+ /* Complete frame */
+
+ bt_cb(skb)->pkt_type = type;
+ hci_recv_frame(skb);
+
+ hdev->reassembly[index] = NULL;
+ return remain;
+ }
+ }
+
+ return remain;
+}
+
/* Receive packet type fragment */
#define __reassembly(hdev, type) ((hdev)->reassembly[(type) - 1])
--
1.7.0.4
^ permalink raw reply related
* [PATCH v7 1/4] add one more buffer for stream reassembly
From: Suraj Sumangala @ 2010-07-14 7:32 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Jothikumar.Mothilal, Suraj Sumangala
Additional reassembly buffer to keep track of stream reasembly
Signed-off-by: Suraj Sumangala <suraj@atheros.com>
---
include/net/bluetooth/hci_core.h | 4 ++--
net/bluetooth/hci_core.c | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 600372d..28e5eee 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -66,7 +66,7 @@ struct bdaddr_list {
struct list_head list;
bdaddr_t bdaddr;
};
-
+#define NUM_REASSEMBLY 4
struct hci_dev {
struct list_head list;
spinlock_t lock;
@@ -123,7 +123,7 @@ struct hci_dev {
struct sk_buff_head cmd_q;
struct sk_buff *sent_cmd;
- struct sk_buff *reassembly[3];
+ struct sk_buff *reassembly[NUM_REASSEMBLY];
struct mutex req_lock;
wait_queue_head_t req_wait_q;
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index aeb2982..0ded790 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -914,7 +914,7 @@ int hci_register_dev(struct hci_dev *hdev)
skb_queue_head_init(&hdev->cmd_q);
skb_queue_head_init(&hdev->raw_q);
- for (i = 0; i < 3; i++)
+ for (i = 0; i < NUM_REASSEMBLY; i++)
hdev->reassembly[i] = NULL;
init_waitqueue_head(&hdev->req_wait_q);
@@ -973,7 +973,7 @@ int hci_unregister_dev(struct hci_dev *hdev)
hci_dev_do_close(hdev);
- for (i = 0; i < 3; i++)
+ for (i = 0; i < NUM_REASSEMBLY; i++)
kfree_skb(hdev->reassembly[i]);
hci_notify(hdev, HCI_DEV_UNREG);
@@ -1034,7 +1034,7 @@ int hci_recv_frame(struct sk_buff *skb)
EXPORT_SYMBOL(hci_recv_frame);
/* Receive packet type fragment */
-#define __reassembly(hdev, type) ((hdev)->reassembly[(type) - 2])
+#define __reassembly(hdev, type) ((hdev)->reassembly[(type) - 1])
int hci_recv_fragment(struct hci_dev *hdev, int type, void *data, int count)
{
--
1.7.0.4
^ permalink raw reply related
* [PATCH] Added support for bluetooth controller shipped with iMac i5
From: Cyril Lacoux @ 2010-07-14 6:29 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Cyril Lacoux
In-Reply-To: <1278681678.10421.114.camel@localhost.localdomain>
Device class is ff(vend.) instead of e0(wlcon).
Output from command `usb-devices`:
T: Bus=01 Lev=03 Prnt=03 Port=00 Cnt=01 Dev#= 6 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=05ac ProdID=8215 Rev=01.82
S: Manufacturer=Apple Inc.
S: Product=Bluetooth USB Host Controller
S: SerialNumber=7C6D62936607
C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=btusb
I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=00 Driver=(none)
Signed-off-by: Cyril Lacoux <clacoux@ifeelgood.org>
---
drivers/bluetooth/btusb.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 5d9cc53..6fcb971 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -59,6 +59,9 @@ static struct usb_device_id btusb_table[] = {
/* Generic Bluetooth USB device */
{ USB_DEVICE_INFO(0xe0, 0x01, 0x01) },
+ /* Apple iMac11,1 */
+ { USB_DEVICE(0x05ac, 0x8215) },
+
/* AVM BlueFRITZ! USB v2.0 */
{ USB_DEVICE(0x057c, 0x3800) },
--
1.7.1
^ permalink raw reply related
* hcitools parameter question
From: Ronny Pau @ 2010-07-14 2:58 UTC (permalink / raw)
To: linux-bluetooth
Hi all,
Has anyone tried to execute the "AFH_Host_Channel_Classification" HCI
command using hcitools? how do I pass in the 10 octet long parameter?
Thanks,
Ronny
^ permalink raw reply
* scotest cause linux 2.6.34.1 memory leak?
From: manfred Dong @ 2010-07-14 2:51 UTC (permalink / raw)
To: linux-bluetooth
Hi
I am trying scotest in bluez on linux-2.6.34.1 with 2 PCs.
I switched off the bluetooth-udev and remove l2cap and rfcomm modules.
Then do following commands separately on 2 PCs.
1. ./scotest -r
2. ./scotest -s <BD_ADDR>
Then using "free", I found sending PC's free memory decreased fast,
and never restored even I kill the lt-scotest process.
Shortly then, Linux can not work normally.
Did any one meet this ever?
The data path for me should be scotest-> sco.ko->btusb.ko.
Thanks
^ permalink raw reply
* Re: [PATCH v6 1/4] add one more buffer for stream reassembly
From: Marcel Holtmann @ 2010-07-13 21:03 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: Suraj Sumangala, linux-bluetooth, Jothikumar.Mothilal
In-Reply-To: <20100713210104.GA3106@vigoh>
Hi Gustavo,
> > And don't forget to modify the __reassembly macro to do -1 instead of -2
> > now. Since we said we keep the [0] for the stream reassembly.
>
> The __reassembly macro is removed in the following patches.
I know, but I prefer to keep these patches in a bisectable fashion to
have them make sense by itself.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH v6 1/4] add one more buffer for stream reassembly
From: Gustavo F. Padovan @ 2010-07-13 21:01 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Suraj Sumangala, linux-bluetooth, Jothikumar.Mothilal
In-Reply-To: <1279054151.6282.22.camel@localhost.localdomain>
Hi Marcel,
* Marcel Holtmann <marcel@holtmann.org> [2010-07-13 17:49:11 -0300]:
> Hi Suraj,
>
> > Additional reassembly buffer to keep track of stream reasembly
> >
> > Signed-off-by: Suraj Sumangala <suraj@atheros.com>
> > ---
> > include/net/bluetooth/hci_core.h | 4 ++--
> > net/bluetooth/hci_core.c | 4 ++--
> > 2 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
> > index 600372d..10ad3ed 100644
> > --- a/include/net/bluetooth/hci_core.h
> > +++ b/include/net/bluetooth/hci_core.h
> > @@ -66,7 +66,7 @@ struct bdaddr_list {
> > struct list_head list;
> > bdaddr_t bdaddr;
> > };
> > -
> > +#define NUM_REASSEMBLY_BUFFER 4
>
> Just call it NUM_REASSEMBLY.
>
> > struct hci_dev {
> > struct list_head list;
> > spinlock_t lock;
> > @@ -123,7 +123,7 @@ struct hci_dev {
> > struct sk_buff_head cmd_q;
> >
> > struct sk_buff *sent_cmd;
> > - struct sk_buff *reassembly[3];
> > + struct sk_buff *reassembly[NUM_REASSEMBLY_BUFFER];
> >
> > struct mutex req_lock;
> > wait_queue_head_t req_wait_q;
> > diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> > index aeb2982..5df09fd 100644
> > --- a/net/bluetooth/hci_core.c
> > +++ b/net/bluetooth/hci_core.c
> > @@ -914,7 +914,7 @@ int hci_register_dev(struct hci_dev *hdev)
> > skb_queue_head_init(&hdev->cmd_q);
> > skb_queue_head_init(&hdev->raw_q);
> >
> > - for (i = 0; i < 3; i++)
> > + for (i = 0; i < NUM_REASSEMBLY_BUFFER; i++)
> > hdev->reassembly[i] = NULL;
> >
> > init_waitqueue_head(&hdev->req_wait_q);
> > @@ -973,7 +973,7 @@ int hci_unregister_dev(struct hci_dev *hdev)
> >
> > hci_dev_do_close(hdev);
> >
> > - for (i = 0; i < 3; i++)
> > + for (i = 0; i < NUM_REASSEMBLY_BUFFER; i++)
> > kfree_skb(hdev->reassembly[i]);
> >
> > hci_notify(hdev, HCI_DEV_UNREG);
>
> And don't forget to modify the __reassembly macro to do -1 instead of -2
> now. Since we said we keep the [0] for the stream reassembly.
The __reassembly macro is removed in the following patches.
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* Re: [PATCH v6 1/4] add one more buffer for stream reassembly
From: Marcel Holtmann @ 2010-07-13 20:49 UTC (permalink / raw)
To: Suraj Sumangala; +Cc: linux-bluetooth, Jothikumar.Mothilal
In-Reply-To: <1279013611-4775-1-git-send-email-suraj@atheros.com>
Hi Suraj,
> Additional reassembly buffer to keep track of stream reasembly
>
> Signed-off-by: Suraj Sumangala <suraj@atheros.com>
> ---
> include/net/bluetooth/hci_core.h | 4 ++--
> net/bluetooth/hci_core.c | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
> index 600372d..10ad3ed 100644
> --- a/include/net/bluetooth/hci_core.h
> +++ b/include/net/bluetooth/hci_core.h
> @@ -66,7 +66,7 @@ struct bdaddr_list {
> struct list_head list;
> bdaddr_t bdaddr;
> };
> -
> +#define NUM_REASSEMBLY_BUFFER 4
Just call it NUM_REASSEMBLY.
> struct hci_dev {
> struct list_head list;
> spinlock_t lock;
> @@ -123,7 +123,7 @@ struct hci_dev {
> struct sk_buff_head cmd_q;
>
> struct sk_buff *sent_cmd;
> - struct sk_buff *reassembly[3];
> + struct sk_buff *reassembly[NUM_REASSEMBLY_BUFFER];
>
> struct mutex req_lock;
> wait_queue_head_t req_wait_q;
> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> index aeb2982..5df09fd 100644
> --- a/net/bluetooth/hci_core.c
> +++ b/net/bluetooth/hci_core.c
> @@ -914,7 +914,7 @@ int hci_register_dev(struct hci_dev *hdev)
> skb_queue_head_init(&hdev->cmd_q);
> skb_queue_head_init(&hdev->raw_q);
>
> - for (i = 0; i < 3; i++)
> + for (i = 0; i < NUM_REASSEMBLY_BUFFER; i++)
> hdev->reassembly[i] = NULL;
>
> init_waitqueue_head(&hdev->req_wait_q);
> @@ -973,7 +973,7 @@ int hci_unregister_dev(struct hci_dev *hdev)
>
> hci_dev_do_close(hdev);
>
> - for (i = 0; i < 3; i++)
> + for (i = 0; i < NUM_REASSEMBLY_BUFFER; i++)
> kfree_skb(hdev->reassembly[i]);
>
> hci_notify(hdev, HCI_DEV_UNREG);
And don't forget to modify the __reassembly macro to do -1 instead of -2
now. Since we said we keep the [0] for the stream reassembly.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 1/1] Makes FindAdapter() accept lower-case hex addresses
From: Johan Hedberg @ 2010-07-13 19:53 UTC (permalink / raw)
To: Elvis Pfützenreuter; +Cc: linux-bluetooth
In-Reply-To: <1279046782-16444-1-git-send-email-epx@signove.com>
Hi Elvis,
On Tue, Jul 13, 2010, Elvis Pfützenreuter wrote:
> ---
> src/manager.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/src/manager.c b/src/manager.c
> index cbbca1e..9b90cab 100644
> --- a/src/manager.c
> +++ b/src/manager.c
> @@ -337,7 +337,7 @@ static gint adapter_address_cmp(gconstpointer a, gconstpointer b)
> adapter_get_address(adapter, &bdaddr);
> ba2str(&bdaddr, addr);
>
> - return strcmp(addr, address);
> + return strcasecmp(addr, address);
The patch is now upstream. Thanks.
Johan
^ permalink raw reply
* [PATCH 1/1] Makes FindAdapter() accept lower-case hex addresses
From: Elvis Pfützenreuter @ 2010-07-13 18:46 UTC (permalink / raw)
To: linux-bluetooth; +Cc: epx
---
src/manager.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/manager.c b/src/manager.c
index cbbca1e..9b90cab 100644
--- a/src/manager.c
+++ b/src/manager.c
@@ -337,7 +337,7 @@ static gint adapter_address_cmp(gconstpointer a, gconstpointer b)
adapter_get_address(adapter, &bdaddr);
ba2str(&bdaddr, addr);
- return strcmp(addr, address);
+ return strcasecmp(addr, address);
}
struct btd_adapter *manager_find_adapter(const bdaddr_t *sba)
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 1/2] Bluetooth: Add Fixed Channels support to bind syscall.
From: Anderson Lizardo @ 2010-07-13 17:30 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-bluetooth, marcel, Gustavo F. Padovan
In-Reply-To: <AANLkTiltwpMN2U3tVry3I-77HDl5-KYsPZHmFqeD58Nl@mail.gmail.com>
On Tue, Jul 13, 2010 at 2:26 PM, Anderson Lizardo
<anderson.lizardo@openbossa.org> wrote:
> If sk->sport is always filled with either cid or psm , why not have
> just a single "__l2cap_sock_addr" function ?
In other words, my suggestion is to keep __l2cap_get_sock_by_addr() as
is (as it already checks for sport) and use it both for PSM and CID.
This could potentially allow a bit of refactoring on the
l2cap_sock_bind() changes as well.
Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
^ 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