* [PATCH 4/7] Bluetooth: Add Kconfig option for L2CAP Extended Features
From: Gustavo F. Padovan @ 2010-04-14 19:41 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, gustavo, jprvita, ulisses
In-Reply-To: <1271274112-7806-4-git-send-email-padovan@profusion.mobi>
The L2CAP Extended Features are still unstable and under development,
so we are adding them under the EXPERIMENTAL flag to get more feedback
on them. L2CAP Extended Features includes the Enhanced Retransmission
and Streaming Modes, Frame Check Sequence (FCS), and Segmentation and
Reassemby (SAR).
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Reviewed-by: João Paulo Rechi Vita <jprvita@profusion.mobi>
---
net/bluetooth/Kconfig | 13 +++++++++++++
net/bluetooth/l2cap.c | 4 ++++
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/net/bluetooth/Kconfig b/net/bluetooth/Kconfig
index ed37168..ee3b304 100644
--- a/net/bluetooth/Kconfig
+++ b/net/bluetooth/Kconfig
@@ -43,6 +43,19 @@ config BT_L2CAP
Say Y here to compile L2CAP support into the kernel or say M to
compile it as module (l2cap).
+config BT_L2CAP_EXT_FEATURES
+ bool "L2CAP Extended Features support (EXPERIMENTAL)"
+ depends on BT_L2CAP && EXPERIMENTAL
+ help
+ This option enables the L2CAP Extended Features support. These
+ new features include the Enhanced Retransmission and Streaming
+ Modes, the Frame Check Sequence (FCS), and Segmentation and
+ Reassembly (SAR) for L2CAP packets. They are a required for the
+ new Alternate MAC/PHY and the Bluetooth Medical Profile.
+
+ You should say N unless you know what you are doing. Note that
+ this is in an experimental state yet.
+
config BT_SCO
tristate "SCO links support"
depends on BT
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index b653039..63248aa 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -55,7 +55,11 @@
#define VERSION "2.14"
+#ifdef CONFIG_BT_L2CAP_EXT_FEATURES
+static int enable_ertm = 1;
+#else
static int enable_ertm = 0;
+#endif
static int max_transmit = L2CAP_DEFAULT_MAX_TX;
static int tx_window = L2CAP_DEFAULT_TX_WINDOW;
--
1.6.4.4
^ permalink raw reply related
* [PATCH 3/7] Bluetooth: Fix crash when monitor timeout expires
From: Gustavo F. Padovan @ 2010-04-14 19:41 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, gustavo, jprvita, ulisses
In-Reply-To: <1271274112-7806-3-git-send-email-padovan@profusion.mobi>
The code was crashing due to a invalid access to hci_conn after the
channel disconnect.
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Reviewed-by: João Paulo Rechi Vita <jprvita@profusion.mobi>
---
net/bluetooth/l2cap.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 657a411..b653039 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -1547,6 +1547,9 @@ static struct sk_buff *l2cap_create_iframe_pdu(struct sock *sk, struct msghdr *m
BT_DBG("sk %p len %d", sk, (int)len);
+ if (!conn)
+ return ERR_PTR(-ENOTCONN);
+
if (sdulen)
hlen += 2;
--
1.6.4.4
^ permalink raw reply related
* [PATCH 2/7] Bluetooth: Fix Indentation on L2CAP
From: Gustavo F. Padovan @ 2010-04-14 19:41 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, gustavo, jprvita, ulisses
In-Reply-To: <1271274112-7806-2-git-send-email-padovan@profusion.mobi>
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Reviewed-by: João Paulo Rechi Vita <jprvita@profusion.mobi>
---
net/bluetooth/l2cap.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index d38bfc2..657a411 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -1369,7 +1369,7 @@ static int l2cap_ertm_send(struct sock *sk)
return 0;
while ((skb = sk->sk_send_head) && (!l2cap_tx_window_full(sk)) &&
- !(pi->conn_state & L2CAP_CONN_REMOTE_BUSY)) {
+ !(pi->conn_state & L2CAP_CONN_REMOTE_BUSY)) {
if (pi->remote_max_tx &&
bt_cb(skb)->retries == pi->remote_max_tx) {
--
1.6.4.4
^ permalink raw reply related
* [PATCH 1/7] Bluetooth: Fix bug when retransmitting I-frames
From: Gustavo F. Padovan @ 2010-04-14 19:41 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, gustavo, jprvita, ulisses
In-Reply-To: <1271274112-7806-1-git-send-email-padovan@profusion.mobi>
If there is no frames to retransmit l2cap was crashing the kernel, now
we check if the queue is empty first.
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
Reviewed-by: João Paulo Rechi Vita <jprvita@profusion.mobi>
---
net/bluetooth/l2cap.c | 12 ++++++++----
1 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index c699fe9..d38bfc2 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -3530,7 +3530,8 @@ expected:
if (pi->conn_state & L2CAP_CONN_REJ_ACT)
pi->conn_state &= ~L2CAP_CONN_REJ_ACT;
else {
- sk->sk_send_head = TX_QUEUE(sk)->next;
+ if (!skb_queue_empty(TX_QUEUE(sk)))
+ sk->sk_send_head = TX_QUEUE(sk)->next;
pi->next_tx_seq = pi->expected_ack_seq;
l2cap_ertm_send(sk);
}
@@ -3577,7 +3578,8 @@ static inline void l2cap_data_channel_rrframe(struct sock *sk, u16 rx_control)
if (pi->conn_state & L2CAP_CONN_REJ_ACT)
pi->conn_state &= ~L2CAP_CONN_REJ_ACT;
else {
- sk->sk_send_head = TX_QUEUE(sk)->next;
+ if (!skb_queue_empty(TX_QUEUE(sk)))
+ sk->sk_send_head = TX_QUEUE(sk)->next;
pi->next_tx_seq = pi->expected_ack_seq;
l2cap_ertm_send(sk);
}
@@ -3609,12 +3611,14 @@ static inline void l2cap_data_channel_rejframe(struct sock *sk, u16 rx_control)
if (pi->conn_state & L2CAP_CONN_REJ_ACT)
pi->conn_state &= ~L2CAP_CONN_REJ_ACT;
else {
- sk->sk_send_head = TX_QUEUE(sk)->next;
+ if (!skb_queue_empty(TX_QUEUE(sk)))
+ sk->sk_send_head = TX_QUEUE(sk)->next;
pi->next_tx_seq = pi->expected_ack_seq;
l2cap_ertm_send(sk);
}
} else {
- sk->sk_send_head = TX_QUEUE(sk)->next;
+ if (!skb_queue_empty(TX_QUEUE(sk)))
+ sk->sk_send_head = TX_QUEUE(sk)->next;
pi->next_tx_seq = pi->expected_ack_seq;
l2cap_ertm_send(sk);
--
1.6.4.4
^ permalink raw reply related
* More patches to eL2CAP
From: Gustavo F. Padovan @ 2010-04-14 19:41 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, gustavo, jprvita, ulisses
Hi,
This set of patches fix two bugs, add L2CAP Extended Features to the Kconfig.
And as a RFC implements support for SOCK_STREAM and Local Busy condition
(patches 5 and 7). Comments are welcome. :)
The patchset is rebased against my last patchset sent to this mailing list.
Gustavo F. Padovan (7):
Bluetooth: Fix bug when retransmitting I-frames
Bluetooth: Fix Indentation on L2CAP
Bluetooth: Fix crash when monitor timeout expires
Bluetooth: Add Kconfig option for L2CAP Extended Features
Bluetooth: Add SOCK_STREAM support to L2CAP
Bluetooth: Implement missing parts of the Invalid Frame Detection
Bluetooth: Implement Local Busy Condition handling
include/net/bluetooth/l2cap.h | 6 +
net/bluetooth/Kconfig | 13 ++
net/bluetooth/l2cap.c | 331 +++++++++++++++++++++++++++++++++++++----
3 files changed, 320 insertions(+), 30 deletions(-)
^ permalink raw reply
* Re: detecting dead link
From: Luiz Augusto von Dentz @ 2010-04-14 19:29 UTC (permalink / raw)
To: Mike Tsai; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <35B17FE5076C7040809188FBE7913F983A1E128A57@SC1EXMB-MBCL.global.atheros.com>
Hi,
On Wed, Apr 14, 2010 at 7:31 PM, Mike Tsai <Mike.Tsai@atheros.com> wrote:
> Hi Luiz,
> [MT] Page timeout is for creating ACL data link. In this case, ACL link is already created so page timeout is not involved. The 20 second timeout is the default link supervision timeout and the 35 second timeout is the LMP timeout (actually 30 seconds). I think if you have the sniff log for the LMP, it would appear that one of the LMP might be lost during SCO negotiation and it is quite possibly due to the existing sniff mode. A proper implementation of host stack shall probably exit sniff mode first before start the SCO link creation. So the log would look like this,
>
> HCI command: Exit Sniff Mode
> HCI event: Command status, Exit Sniff Mode
> HCI event: Mode changed
> HCI command: Setup Synchronous Connection
That exactly what Im arguing about, we have a 30 sec LMP timeout
compared to 5 sec of page timeout , if we are not willing to wait more
than 5 sec for a new ACL link why would we wait 30 sec? This is
completely disproportional and we should probably need to respond way
before that thus my suggestion to derive the LMP timeout for the page
timeout. This not only affect SCO connection but any attempt to
transfer data in the middle of the link loss.
> I think the host was sending the commands out of order. It asks controller to set up SCO link before it asks controller to exit sniff mode. Note that both commands are async commands (meaning it will request controller to go through several state transition for those commands), so the controller might have hard time executing the host commands.
I guess it doesn't matter the order, as long as it detects the link
loss faster, things like PulseAudio cannot afford 30 sec of the stream
lost because the controller has lost the link, if the headset has been
moved away or shutdown in the middle of the playback we want to route
it back to the speaker as soon as possible.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* RE: detecting dead link
From: Mike Tsai @ 2010-04-14 16:31 UTC (permalink / raw)
To: Luiz Augusto von Dentz, linux-bluetooth@vger.kernel.org
In-Reply-To: <k2i2d5a2c101004140110s5834b2e6u86290c6466baa723@mail.gmail.com>
-----Original Message-----
From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of Luiz Augusto von Dentz
Sent: Wednesday, April 14, 2010 1:11 AM
To: linux-bluetooth@vger.kernel.org
Subject: detecting dead link
Hi,
It seems that most of the chips take a lot of time to detect that a
link in dead, due to out of range or power off (no hci disconnect),
the most common problem regarding this is when we try to connect SCO:
2010-03-31 18:40:19.975128 < HCI Command: Setup Synchronous Connection
(0x01|0x0028) plen 17
handle 11 voice setting 0x0060
2010-03-31 18:40:19.981780 > HCI Event: Command Status (0x0f) plen 4
Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
2010-03-31 18:40:33.318023 < ACL data: handle 11 flags 0x02 dlen 22
L2CAP(d): cid 0x0073 len 18 [psm 0]
0000: 69 ef 1d 0d 0a 2b 43 49 45 56 3a 20 32 2c 33 0d i....+CIEV: 2,3.
0010: 0a 3e .>
2010-03-31 18:40:33.318145 < HCI Command: Exit Sniff Mode (0x02|0x0004) plen 2
handle 11
2010-03-31 18:40:33.324615 > HCI Event: Command Status (0x0f) plen 4
Exit Sniff Mode (0x02|0x0004) status 0x00 ncmd 1
2010-03-31 18:40:51.207885 < ACL data: handle 11 flags 0x02 dlen 22
L2CAP(d): cid 0x0073 len 18 [psm 0]
0000: 69 ef 1d 0d 0a 2b 43 49 45 56 3a 20 32 2c 32 0d i....+CIEV: 2,2.
0010: 0a 3e .>
2010-03-31 18:40:54.965362 > HCI Event: Max Slots Change (0x1b) plen 3
handle 11 slots 5
2010-03-31 18:40:54.966094 > HCI Event: Synchronous Connect Complete (0x2c)
plen 17
status 0x08 handle 0 bdaddr 00:1E:DC:B3:40:9D type eSCO
Error: Connection Timeout
2010-03-31 18:40:54.968353 > HCI Event: Number of Completed Packets (0x13) plen
5
handle 11 packets 2
2010-03-31 18:40:54.968658 > HCI Event: Disconn Complete (0x05) plen 4
status 0x00 handle 11 reason 0x08
Reason: Connection Timeout
It took 35 sec to timeout where connections attempt normally only take
5 sec due to page timeout (configurable in main.conf), it is probably
due to being in sniff mode but even after exiting it takes another 20
sec to timeout (probably lmp timeout).
So I was wondering why this timeout is not derived from page timeout,
to me it seems quite obvious that if the connection doesn't complete
within page timeout there is something wrong since that is supposed to
be much faster on an active link, also if that assumption is correct
what would be the impact to have such a logic that takes page timeout
as timeout for any connection attempt in active/dead links dropping
them if the timeout is reached, of course this has to take into
account the user authorization framework/defer setup so it only
timeout if there is no activity in the link.
Hi Luiz,
[MT] Page timeout is for creating ACL data link. In this case, ACL link is already created so page timeout is not involved. The 20 second timeout is the default link supervision timeout and the 35 second timeout is the LMP timeout (actually 30 seconds). I think if you have the sniff log for the LMP, it would appear that one of the LMP might be lost during SCO negotiation and it is quite possibly due to the existing sniff mode. A proper implementation of host stack shall probably exit sniff mode first before start the SCO link creation. So the log would look like this,
HCI command: Exit Sniff Mode
HCI event: Command status, Exit Sniff Mode
HCI event: Mode changed
HCI command: Setup Synchronous Connection
I think the host was sending the commands out of order. It asks controller to set up SCO link before it asks controller to exit sniff mode. Note that both commands are async commands (meaning it will request controller to go through several state transition for those commands), so the controller might have hard time executing the host commands.
--
Luiz Augusto von Dentz
Computer Engineer
--
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
^ permalink raw reply
* detecting dead link
From: Luiz Augusto von Dentz @ 2010-04-14 8:10 UTC (permalink / raw)
To: linux-bluetooth
Hi,
It seems that most of the chips take a lot of time to detect that a
link in dead, due to out of range or power off (no hci disconnect),
the most common problem regarding this is when we try to connect SCO:
2010-03-31 18:40:19.975128 < HCI Command: Setup Synchronous Connection
(0x01|0x0028) plen 17
handle 11 voice setting 0x0060
2010-03-31 18:40:19.981780 > HCI Event: Command Status (0x0f) plen 4
Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
2010-03-31 18:40:33.318023 < ACL data: handle 11 flags 0x02 dlen 22
L2CAP(d): cid 0x0073 len 18 [psm 0]
0000: 69 ef 1d 0d 0a 2b 43 49 45 56 3a 20 32 2c 33 0d i....+CIEV: 2,3.
0010: 0a 3e .>
2010-03-31 18:40:33.318145 < HCI Command: Exit Sniff Mode (0x02|0x0004) plen 2
handle 11
2010-03-31 18:40:33.324615 > HCI Event: Command Status (0x0f) plen 4
Exit Sniff Mode (0x02|0x0004) status 0x00 ncmd 1
2010-03-31 18:40:51.207885 < ACL data: handle 11 flags 0x02 dlen 22
L2CAP(d): cid 0x0073 len 18 [psm 0]
0000: 69 ef 1d 0d 0a 2b 43 49 45 56 3a 20 32 2c 32 0d i....+CIEV: 2,2.
0010: 0a 3e .>
2010-03-31 18:40:54.965362 > HCI Event: Max Slots Change (0x1b) plen 3
handle 11 slots 5
2010-03-31 18:40:54.966094 > HCI Event: Synchronous Connect Complete (0x2c)
plen 17
status 0x08 handle 0 bdaddr 00:1E:DC:B3:40:9D type eSCO
Error: Connection Timeout
2010-03-31 18:40:54.968353 > HCI Event: Number of Completed Packets (0x13) plen
5
handle 11 packets 2
2010-03-31 18:40:54.968658 > HCI Event: Disconn Complete (0x05) plen 4
status 0x00 handle 11 reason 0x08
Reason: Connection Timeout
It took 35 sec to timeout where connections attempt normally only take
5 sec due to page timeout (configurable in main.conf), it is probably
due to being in sniff mode but even after exiting it takes another 20
sec to timeout (probably lmp timeout).
So I was wondering why this timeout is not derived from page timeout,
to me it seems quite obvious that if the connection doesn't complete
within page timeout there is something wrong since that is supposed to
be much faster on an active link, also if that assumption is correct
what would be the impact to have such a logic that takes page timeout
as timeout for any connection attempt in active/dead links dropping
them if the timeout is reached, of course this has to take into
account the user authorization framework/defer setup so it only
timeout if there is no activity in the link.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: obexd-0.22 causes gnome-bluetooth sendto dialog to stop closing when operation ends
From: Luiz Augusto von Dentz @ 2010-04-14 7:19 UTC (permalink / raw)
To: Bastien Nocera; +Cc: Vinicius Gomes, pacho, linux-bluetooth
In-Reply-To: <1271085759.6731.6348.camel@localhost.localdomain>
Hi,
On Mon, Apr 12, 2010 at 6:22 PM, Bastien Nocera <hadess@hadess.net> wrote:
> On Sat, 2010-04-10 at 11:17 -0300, Vinicius Gomes wrote:
>> Hi Pacho,
>>
>> 2010/4/10 Pacho Ramos <pacho@condmat1.ciencias.uniovi.es>:
>> > Hello
>> >
>> > This is a regression over obexd-0.21. After updating to 0.22,
>> > gnome-bluetooth sendto dialog no longer closes when operation finishes,
>> > even if file is already properly sent.
>> >
>>
>> We noticed this regression as well. Luiz already has a fix for this,
>> it was just not integrated yet.
>>
>> In case you want to take a look and perhaps help test it, the fix is here[1].
>
> Except that the patch is absolutely huge, and doesn't apply cleanly on
> 0.22 either.
For those wanting to have a quick fix for 0.22 you can revert
d57bffe46b71e17a640c11b389dd6da95f933729, which cause the extra
reference to be hold. In the meantime I will be doing some cleanups to
session code and moving the transfer logic to a separate file those
changes will probably be only available in 0.23.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: l2cap connection id in user-space
From: Gustavo F. Padovan @ 2010-04-14 5:51 UTC (permalink / raw)
To: Pavan Savoy; +Cc: Marcel Holtmann, linux-bluetooth, shitiz_kumar
In-Reply-To: <1271206772.22838.0.camel@localhost.localdomain>
Hi Pavan,
* Marcel Holtmann <marcel@holtmann.org> [2010-04-13 17:59:32 -0700]:
> Hi Pavan,
>
> > Is there a possibility as of now for me to extract the l2cap connection ID into my application ?
> >
> > I require 2 sets of information about an L2CAP connection in my bluetooth application, I require the connection ID on connection to a remote headset/sink, and also the maximum packet size for that connection (which I think is the MTU, I can get via the getsockopt).
>
> you need a recent kernel and then getsockname() and getpeername() will
> give you the SCID and DCID.
Sorry for the wrong info, I didn't know about that calls inside L2CAP.
;)
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* Re: l2cap connection id in user-space
From: Marcel Holtmann @ 2010-04-14 0:59 UTC (permalink / raw)
To: Pavan Savoy; +Cc: linux-bluetooth, shitiz_kumar
In-Reply-To: <112852.88977.qm@web94911.mail.in2.yahoo.com>
Hi Pavan,
> Is there a possibility as of now for me to extract the l2cap connection ID into my application ?
>
> I require 2 sets of information about an L2CAP connection in my bluetooth application, I require the connection ID on connection to a remote headset/sink, and also the maximum packet size for that connection (which I think is the MTU, I can get via the getsockopt).
you need a recent kernel and then getsockname() and getpeername() will
give you the SCID and DCID.
Regards
Marcel
^ permalink raw reply
* Re: l2cap connection id in user-space
From: Gustavo F. Padovan @ 2010-04-13 21:39 UTC (permalink / raw)
To: Pavan Savoy; +Cc: linux-bluetooth, shitiz_kumar
In-Reply-To: <956973.57311.qm@web94903.mail.in2.yahoo.com>
Hi Pavan,
* Pavan Savoy <pavan_savoy@yahoo.co.in> [2010-04-14 02:54:00 +0530]:
>
> --- On Wed, 14/4/10, Gustavo F. Padovan <gustavo@padovan.org> wrote:
>
> > From: Gustavo F. Padovan <gustavo@padovan.org>
> > Subject: Re: l2cap connection id in user-space
> > To: "Pavan Savoy" <pavan_savoy@yahoo.co.in>
> > Cc: linux-bluetooth@vger.kernel.org, shitiz_kumar@ti.com
> > Date: Wednesday, 14 April, 2010, 2:49 AM
> > Hi Pavan,
> >
> > * Pavan Savoy <pavan_savoy@yahoo.co.in>
> > [2010-04-14 02:26:41 +0530]:
> >
> > > Is there a possibility as of now for me to extract the
> > l2cap connection ID into my application ?
> >
> > bluez-hcidump does that. Look to its source code to learn
> > how.
>
> Yeah, correct, it does.
> However for that wouldn't I have to set filter for all ACL (or L2CAP) packets to even start receiving ACL (or L2CAP) packets ?
> strip off the l2cap_hdr and then get the channel ID from it.
>
> I was more or less looking to add in 1 more getsockopt option to specifically request for the l2cap_hdr ? (like the imtu/omtu which happens currently).
> Wouldn't this be the right way ?
No, we do not want such info on getsockopt. If you do that you'll have
to mantain it by yourself, which is not a good idea. The cid is L2CAP
specific, upper layers should not care about it.
>
> > >
> > > I require 2 sets of information about an L2CAP
> > connection in my bluetooth application, I require the
> > connection ID on connection to a remote headset/sink, and
> > also the maximum packet size for that connection (which I
> > think is the MTU, I can get via the getsockopt).
> > >
> >
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* Re: l2cap connection id in user-space
From: Pavan Savoy @ 2010-04-13 21:24 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-bluetooth, shitiz_kumar
In-Reply-To: <20100413211913.GA20489@vigoh>
--- On Wed, 14/4/10, Gustavo F. Padovan <gustavo@padovan.org> wrote:
> From: Gustavo F. Padovan <gustavo@padovan.org>
> Subject: Re: l2cap connection id in user-space
> To: "Pavan Savoy" <pavan_savoy@yahoo.co.in>
> Cc: linux-bluetooth@vger.kernel.org, shitiz_kumar@ti.com
> Date: Wednesday, 14 April, 2010, 2:49 AM
> Hi Pavan,
>
> * Pavan Savoy <pavan_savoy@yahoo.co.in>
> [2010-04-14 02:26:41 +0530]:
>
> > Is there a possibility as of now for me to extract the
> l2cap connection ID into my application ?
>
> bluez-hcidump does that. Look to its source code to learn
> how.
Yeah, correct, it does.
However for that wouldn't I have to set filter for all ACL (or L2CAP) packets to even start receiving ACL (or L2CAP) packets ?
strip off the l2cap_hdr and then get the channel ID from it.
I was more or less looking to add in 1 more getsockopt option to specifically request for the l2cap_hdr ? (like the imtu/omtu which happens currently).
Wouldn't this be the right way ?
> >
> > I require 2 sets of information about an L2CAP
> connection in my bluetooth application, I require the
> connection ID on connection to a remote headset/sink, and
> also the maximum packet size for that connection (which I
> think is the MTU, I can get via the getsockopt).
> >
>
> --
> Gustavo F. Padovan
> http://padovan.org
>
Send free SMS to your Friends on Mobile from your Yahoo! Messenger. Download Now! http://messenger.yahoo.com/download.php
^ permalink raw reply
* Re: l2cap connection id in user-space
From: Gustavo F. Padovan @ 2010-04-13 21:19 UTC (permalink / raw)
To: Pavan Savoy; +Cc: linux-bluetooth, shitiz_kumar
In-Reply-To: <112852.88977.qm@web94911.mail.in2.yahoo.com>
Hi Pavan,
* Pavan Savoy <pavan_savoy@yahoo.co.in> [2010-04-14 02:26:41 +0530]:
> Is there a possibility as of now for me to extract the l2cap connection ID into my application ?
bluez-hcidump does that. Look to its source code to learn how.
>
> I require 2 sets of information about an L2CAP connection in my bluetooth application, I require the connection ID on connection to a remote headset/sink, and also the maximum packet size for that connection (which I think is the MTU, I can get via the getsockopt).
>
--
Gustavo F. Padovan
http://padovan.org
^ permalink raw reply
* l2cap connection id in user-space
From: Pavan Savoy @ 2010-04-13 20:56 UTC (permalink / raw)
To: linux-bluetooth; +Cc: shitiz_kumar
Is there a possibility as of now for me to extract the l2cap connection ID into my application ?
I require 2 sets of information about an L2CAP connection in my bluetooth application, I require the connection ID on connection to a remote headset/sink, and also the maximum packet size for that connection (which I think is the MTU, I can get via the getsockopt).
please respond.
Send free SMS to your Friends on Mobile from your Yahoo! Messenger. Download Now! http://messenger.yahoo.com/download.php
^ permalink raw reply
* Re: Is hsp code in BlueZ and pulseaudio broken?
From: Zhu Yanhai @ 2010-04-13 7:52 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: linux-bluetooth, pulseaudio-discuss, vivian.zhang, guannan.ou,
Zheng Huan, Zhu Yanhai, Zhu, Yanhai
In-Reply-To: <h2i2d5a2c101004090532o6c7e33a4k7563fe8f628f3d6f@mail.gmail.com>
Hi,
I think this bug is caused by the buggy implement of eSCO on the Dell
BH200 headset. After echo 'Y' > /sys/module/sco/parameters/disable_esco,
everything is OK then.
Thanks,
Zhu Yanhai
2010/4/9 Luiz Augusto von Dentz <luiz.dentz@gmail.com>:
> Hi,
>
> On Fri, Apr 9, 2010 at 11:35 AM, Zhu Yanhai <zhu.yanhai@gmail.com> wrote:
>> 'hcitool con' reported there was no connections after that, and the
>> headset was power off automatically. And of course I can't see this
>> headset by
>> 'ilst-cards' or 'list-sinks' in pacmd.
>>
>> Is it because there is anything broken in the latest BlueZ +
>> Pulseaudio, or am I doing something wrong?
>
> It seems ok in bluetoothd size, maybe it is the suspend logic that
> disconnect sco after a few seconds when idle, but it doesn't seems to
> be the case here as also rfcomm connection is dropped somehow.
>
> --
> Luiz Augusto von Dentz
> Computer Engineer
>
^ permalink raw reply
* Re: obexd and phonebook-ebook.c (PBAP support)
From: Harald Schmitt @ 2010-04-12 15:38 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <4BB9A104.3050509@hschmitt.de>
Harald Schmitt schrieb:
> Harald Schmitt schrieb:
>> Hi,
>>
>> Is it possible that obexd has to call g_type_init() if
>> phonebook-ebook is used?
>> I think when you call e_book_new_default_addressbook() somewhere down
>> gconf_client_get_default() is called and it insists that
>> g_type_init() is called prior to its use.
>>
>> I tried to make obexd work on my N900, but I did not get there.
>> My car kit does not use PBAP because it finds the Nokia SyncML
>> profile and uses it, but the N900 does not communicate with bluetooth
>> devices other than PC or Mobiles via SyncML.
>> Is there a way to unregister a service from SDP?
>>
>> Regards,
>>
>> --
>> Harald
>> --
>> 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
>>
> Now I am using pbap-client from the obexd package from my notebook to
> test pbap on my N900. I am pretty far. All my contacts are read, but
> the obex message is not sent back successfully.
> Here is the syslog (I added some messages):
> Apr 5 09:56:35 Nokia-N900-51-1 obexd[1203]: pbap_get: pbap_get()
> Apr 5 09:56:35 Nokia-N900-51-1 obexd[1203]: phonebook_pullphonebook:
> phonebook_pullphonebook
> Apr 5 09:56:36 Nokia-N900-51-1 obexd[1203]: pbap_pullphonebook:
> phonebook_pullphonebook had no errors
> Apr 5 09:56:36 Nokia-N900-51-1 obexd[1203]:
> pbap_add_result_apparam_header: pbap_add_result_apparam_header
> maxlistcount=65535 rspsize=0
> Apr 5 09:56:36 Nokia-N900-51-1 obexd[1203]: pbap_get: pbap_get() no
> error
> Apr 5 09:56:36 Nokia-N900-51-1 obexd[1203]: pbap_get: pbap_get() addbody
> Apr 5 09:56:36 Nokia-N900-51-1 obexd[1203]: pbap_get: pbap_get()
> OBEX_ObjectSetRsp()
> Apr 5 09:56:36 Nokia-N900-51-1 obexd[1203]: PROGRESS(0x0), GET(0x3),
> (null)(0x0)
> Apr 5 09:56:36 Nokia-N900-51-1 obexd[1203]: ebookpull_cb:
> ebookpull_cb count=305 size=42944
> Apr 5 09:56:36 Nokia-N900-51-1 obexd[1203]: STREAMEMPTY(0x8),
> CONNECT(0x0), (null)(0x0)
> Apr 5 09:56:36 Nokia-N900-51-1 obexd[1203]: obex_write_stream:
> name=telecom/pb.vcf type=x-bt/phonebook tx_mtu=3896 file=(nil)
> Apr 5 09:56:36 Nokia-N900-51-1 obexd[1203]: STREAMEMPTY(0x8),
> CONNECT(0x0), (null)(0x0)
> Apr 5 09:56:36 Nokia-N900-51-1 obexd[1203]: obex_write_stream:
> name=telecom/pb.vcf type=x-bt/phonebook tx_mtu=3896 file=(nil)
> Apr 5 09:56:36 Nokia-N900-51-1 obexd[1203]: PROGRESS(0x0),
> (null)(0x10), (null)(0x0)
> Apr 5 09:56:37 Nokia-N900-51-1 obexd[1203]: REQDONE(0x3),
> (null)(0x10), (null)(0x3)
> Apr 5 09:57:00 Nokia-N900-51-1 obexd[1203]: obex_handle_input: poll
> event HUP ERR
>
> Best,
> Harald
I think the problem on my N900 is a bug in openobex 1.4, that is fixed
in 1.5:
http://git.kernel.org/?p=bluetooth/openobex.git;a=commit;h=52bf1445d2fa4b95dac4b98e1cb6e9dbb5d5ed7d
This situation applies on the way the PBAP plugin is implemented. To
make PBAP working with only replacing obexd, I think the only way is to
use the non-async e-book functions or could someone give me a hint to
something better?
Best,
Harald
^ permalink raw reply
* Re: obexd-0.22 causes gnome-bluetooth sendto dialog to stop closing when operation ends
From: Bastien Nocera @ 2010-04-12 15:22 UTC (permalink / raw)
To: Vinicius Gomes; +Cc: pacho, linux-bluetooth
In-Reply-To: <l2r2a9506371004100717p500f6b4o48e8a6d2dfb8f0c5@mail.gmail.com>
On Sat, 2010-04-10 at 11:17 -0300, Vinicius Gomes wrote:
> Hi Pacho,
>
> 2010/4/10 Pacho Ramos <pacho@condmat1.ciencias.uniovi.es>:
> > Hello
> >
> > This is a regression over obexd-0.21. After updating to 0.22,
> > gnome-bluetooth sendto dialog no longer closes when operation finishes,
> > even if file is already properly sent.
> >
>
> We noticed this regression as well. Luiz already has a fix for this,
> it was just not integrated yet.
>
> In case you want to take a look and perhaps help test it, the fix is here[1].
Except that the patch is absolutely huge, and doesn't apply cleanly on
0.22 either.
^ permalink raw reply
* Re: Regarding HS re-connection
From: Peter Dons Tychsen @ 2010-04-12 8:56 UTC (permalink / raw)
To: Iain Hibbert; +Cc: nirav rabara, linux-bluetooth
In-Reply-To: <1271059413.486818.580.nullmailer@galant.ukfsn.org>
Hello,
On Mon, 2010-04-12 at 09:03 +0100, Iain Hibbert wrote:
> I think your question stems from misunderstandings about pairing.
> Obviously, you can't force the HS to be paired with a device that it
> doesn't know about. You probably can't even connect to it unless you are
> paired with it.. Bluetooth is a cable-replacement technology and pairing
> is about setting up a trusted connection that does not need to be approved
> every time it needs to be made. If you can forcefully pair with a device,
> then any Joe with a radio could do it too from hundreds of meters away and
> there would be no security in that. That you the owner of each device must
> participate in the pairing process is intentional.
This is not always true. A portion of the newer headsets are in pairing
mode all of the time (or selected periods). If it at the same time uses
SSP and no other authentication, then there is not even a PIN which
blocks an attacker/connector (which is always 0000 on headsets anyway).
Personally i do not favor this approach, as it kills battery and makes
security a non existing function. Often this type of scheme is branded
as "pairing made simple" or similar. There is at least a few major
brands that do this, to avoid their hot-lines glowing with "i cannot
pair my headset!".
Thanks,
/pedro
^ permalink raw reply
* Re: Regarding HS re-connection
From: Iain Hibbert @ 2010-04-12 8:03 UTC (permalink / raw)
To: nirav rabara; +Cc: linux-bluetooth
In-Reply-To: <h2k912bb79a1004112146wd46cc9d6j36a0807563ed4d5d@mail.gmail.com>
On Mon, 12 Apr 2010, nirav rabara wrote:
> I am bit confused regarding logic behind HS reconnection with dongle.
> 1) I paired and connect with HS with Dongle.
> 2) Now I paired and connect this HS with few other Devices, so HS
> memory will be overwritten and won't be having any information of
> Dongle paired earlier.
>
> In such situation am I need to do repairing OR forcefully I can send
> the pairing information to HS.
** please don't do top-posting **
I think your question stems from misunderstandings about pairing.
Obviously, you can't force the HS to be paired with a device that it
doesn't know about. You probably can't even connect to it unless you are
paired with it.. Bluetooth is a cable-replacement technology and pairing
is about setting up a trusted connection that does not need to be approved
every time it needs to be made. If you can forcefully pair with a device,
then any Joe with a radio could do it too from hundreds of meters away and
there would be no security in that. That you the owner of each device must
participate in the pairing process is intentional.
regards,
iain
^ permalink raw reply
* Regarding HS re-connection
From: nirav rabara @ 2010-04-12 4:46 UTC (permalink / raw)
To: Iain Hibbert; +Cc: linux-bluetooth
Hi,
I am bit confused regarding logic behind HS reconnection with dongle.
1) I paired and connect with HS with Dongle.
2) Now I paired and connect this HS with few other Devices, so HS
memory will be overwritten and won't be having any information of
Dongle paired earlier.
In such situation am I need to do repairing OR forcefully I can send
the pairing information to HS.
Thanks for your suggestions in advance.
On Wed, Apr 7, 2010 at 3:02 PM, nirav rabara <niravrabara@gmail.com> wrote:
> hi Lain,
>
> Thanks for your suggestion,
>
>> you will probably find that because the HS device is very limited in
>> resources, it does not keep records of more than one paired device. So, if
>> you pair with another device it forgets about the first and you will not
>> be able to connect except that you pair it again.
>>
>
> Does it mean that once paired device information stored in our
> cellphones, if remote device(HS) doesn't have paired information, out
> cellphone will take care of re-pairing.
>
> So ultimately am I need to do pairing again??
>
>
> --
> With Regards,
> Nirav Rabara
>
--
With Regards,
Nirav Rabara
^ permalink raw reply
* Re: [PATCH] List with UUIDs per-adapter should be sorted
From: Johan Hedberg @ 2010-04-11 22:46 UTC (permalink / raw)
To: Francisco Alecrim; +Cc: linux-bluetooth
In-Reply-To: <1270762501-28643-1-git-send-email-francisco.alecrim@openbossa.org>
Hi Alecrim,
On Thu, Apr 08, 2010, Francisco Alecrim wrote:
> ---
> src/adapter.c | 5 +++--
> src/sdpd-database.c | 2 +-
> src/sdpd.h | 1 +
> 3 files changed, 5 insertions(+), 3 deletions(-)
This patch is now upstream. Thanks.
Johan
^ permalink raw reply
* Re: Mouse authentication regression after 4.63
From: Brian Rogers @ 2010-04-11 22:11 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <20100411103618.GA7676@jh-x301>
On 04/11/2010 03:36 AM, Johan Hedberg wrote:
> Hi Brian,
>
> On Sun, Apr 11, 2010, Brian Rogers wrote:
>
>> Upon trying out a newer version of BlueZ, I found a regression in
>> support for my mouse caused by the following commit:
>>
>> commit aee26b30bbc24cde464ba1a557c2b258ddec6432
>> Author: Johan Hedberg<johan.hedberg@nokia.com>
>> Date: Tue Mar 30 13:36:46 2010 +0300
>>
>> Make BtIO default security level MEDIUM
>>
>> MEDIUM makes more sense than the kernel default LOW which maps to "no
>> bonding" with SSP (something that's useful only for very special cases
>> such as OPP).
>>
>>
>> After this commit, when I turn on or move my mouse, I get prompted
>> for a PIN to use for the connection. "0000" won't work, and blank
>> isn't accepted, so the mouse can't connect. Deleting and re-pairing
>> my mouse doesn't work either. I suspect my mouse just does not
>> support encryption. I've never seen AUTH or ENCRYPT on my mouse in
>> the output of "hcitool con" and I can't enable encryption on a
>> working bluez using "hcitool auth". It just prompts for a PIN, and
>> disconnects the mouse when I enter one. And there's no documentation
>> on what PIN should be used with this mouse.
>>
>> With the above commit reverted, it works fine again. The mouse
>> information is below. Could this be a device-specific quirk? What
>> information is needed to resolve this?
>>
> I don't think this needs anything device specific. Authentication is
> optional for mice so we can't really have the HID sockets requiring
> higher security than LOW. The attached patch should fix the issue.
>
That did the trick. Thanks.
Brian
^ permalink raw reply
* Re: Implement AVCTP passthrough commands
From: Paolo Medici @ 2010-04-11 12:40 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <20100411083333.GA10451@ce.unipr.it>
[-- Attachment #1: Type: text/plain, Size: 511 bytes --]
Something like that (attached).
Paolo Medici wrote:
> Hi,
> Are there no contraindications to complete the implementation in audio/control.c of other commands (as well as VolumeUp/VolumeDown)?
> In this case, to try to control my iPod Touch, I would like to add remaining ones.
>
> Paolo
> --
> 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
>
>
[-- Attachment #2: control.c.diff --]
[-- Type: application/download, Size: 3397 bytes --]
^ permalink raw reply
* Re: Mouse authentication regression after 4.63
From: Johan Hedberg @ 2010-04-11 10:36 UTC (permalink / raw)
To: Brian Rogers; +Cc: linux-bluetooth
In-Reply-To: <4BC19B11.1090409@xyzw.org>
[-- Attachment #1: Type: text/plain, Size: 1532 bytes --]
Hi Brian,
On Sun, Apr 11, 2010, Brian Rogers wrote:
> Upon trying out a newer version of BlueZ, I found a regression in
> support for my mouse caused by the following commit:
>
> commit aee26b30bbc24cde464ba1a557c2b258ddec6432
> Author: Johan Hedberg <johan.hedberg@nokia.com>
> Date: Tue Mar 30 13:36:46 2010 +0300
>
> Make BtIO default security level MEDIUM
>
> MEDIUM makes more sense than the kernel default LOW which maps to "no
> bonding" with SSP (something that's useful only for very special cases
> such as OPP).
>
>
> After this commit, when I turn on or move my mouse, I get prompted
> for a PIN to use for the connection. "0000" won't work, and blank
> isn't accepted, so the mouse can't connect. Deleting and re-pairing
> my mouse doesn't work either. I suspect my mouse just does not
> support encryption. I've never seen AUTH or ENCRYPT on my mouse in
> the output of "hcitool con" and I can't enable encryption on a
> working bluez using "hcitool auth". It just prompts for a PIN, and
> disconnects the mouse when I enter one. And there's no documentation
> on what PIN should be used with this mouse.
>
> With the above commit reverted, it works fine again. The mouse
> information is below. Could this be a device-specific quirk? What
> information is needed to resolve this?
I don't think this needs anything device specific. Authentication is
optional for mice so we can't really have the HID sockets requiring
higher security than LOW. The attached patch should fix the issue.
Johan
[-- Attachment #2: input-sec-level.patch --]
[-- Type: text/x-diff, Size: 1454 bytes --]
diff --git a/input/device.c b/input/device.c
index 922dc98..e047009 100644
--- a/input/device.c
+++ b/input/device.c
@@ -886,6 +886,7 @@ static void control_connect_cb(GIOChannel *chan, GError *conn_err,
BT_IO_OPT_SOURCE_BDADDR, &idev->src,
BT_IO_OPT_DEST_BDADDR, &idev->dst,
BT_IO_OPT_PSM, L2CAP_PSM_HIDP_INTR,
+ BT_IO_OPT_SEC_LEVEL, BT_IO_SEC_LOW,
BT_IO_OPT_INVALID);
if (!io) {
error("%s", err->message);
@@ -964,6 +965,7 @@ static DBusMessage *input_device_connect(DBusConnection *conn,
BT_IO_OPT_SOURCE_BDADDR, &idev->src,
BT_IO_OPT_DEST_BDADDR, &idev->dst,
BT_IO_OPT_PSM, L2CAP_PSM_HIDP_CTRL,
+ BT_IO_OPT_SEC_LEVEL, BT_IO_SEC_LOW,
BT_IO_OPT_INVALID);
iconn->ctrl_io = io;
}
diff --git a/input/server.c b/input/server.c
index 93ceea6..7eddf93 100644
--- a/input/server.c
+++ b/input/server.c
@@ -187,6 +187,7 @@ int server_start(const bdaddr_t *src)
server, NULL, &err,
BT_IO_OPT_SOURCE_BDADDR, src,
BT_IO_OPT_PSM, L2CAP_PSM_HIDP_CTRL,
+ BT_IO_OPT_SEC_LEVEL, BT_IO_SEC_LOW,
BT_IO_OPT_INVALID);
if (!server->ctrl) {
error("Failed to listen on control channel");
@@ -199,6 +200,7 @@ int server_start(const bdaddr_t *src)
server, NULL, &err,
BT_IO_OPT_SOURCE_BDADDR, src,
BT_IO_OPT_PSM, L2CAP_PSM_HIDP_INTR,
+ BT_IO_OPT_SEC_LEVEL, BT_IO_SEC_LOW,
BT_IO_OPT_INVALID);
if (!server->intr) {
error("Failed to listen on interrupt channel");
^ permalink raw reply related
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