Hi Marcel, Luiz,
----- Original Message -----
From: "Luiz Augusto von Dentz" <[email protected]>
To: "Marcel Holtmann" <[email protected]>
Cc: "Syam Sidhardhan" <[email protected]>;
<[email protected]>
Sent: Thursday, October 11, 2012 7:59 PM
Subject: Re: [PATCH 1/4] Bluetooth: Fix L2CAP PSM bind issue
> Hi Marcel,
>
> On Thu, Oct 11, 2012 at 3:56 PM, Marcel Holtmann <[email protected]>
> wrote:
>> Hi Syam,
>>
>>> >> Problem: If we bind a particular PSM with source address as
>>> >> BDADDR_ANY,
>>> >> then we are able to bind the same PSM with adapter address(or any
>>> >> other
>>> >> address), which is incorrect.
>>> >
>>> > why is this incorrect? Explain that to me.
>>> >
>>>
>>> Here there is a correction required in the commit message.
>>>
>>> As per my understanding the a particular PSM can be binded only once
>>> for a single adapter address. Kindly correct me if I'm wrong here.
>>
>> a PSM can be bound once per adapter address. And of course once per
>> BDADDR_ANY.
>>
>> So you can bind PSM 23 to BDADDR_ANY and 11:22:33:44:55:66. An incoming
>> connection to 11:22:33:44:55:66 will arrive to that specific socket, but
>> an incoming to all others will be handled by the BDADDR_ANY.
>>
>> The BDADDR_ANY is special. Consider it a wildcard bound with lower
>> priority. If overwritten with a specific address bound, that will be
>> considered first of course.
>>
>> If we are not doing it that way, than that is a bug.
>>
>> Outgoing connections should behave the same btw. If a specific address
>> is bound, than that will be used. If not available, then you can not
>> connect. If BDADDR_ANY is used, then the next available adapter will be
>> used.
>
> The real problem is by giving psm 0 the kernel should return the first
> available psm in the non-reserved space, but since we reuse the same
> code to do the matching it end up given both obexd and hdp the same
> psm, IMO in this case we should consider using Syam code and not
> __l2cap_global_chan_by_addr as the userspace is probably asking for a
> psm not in use which should exclude those in use by BDADDR_ANY.
>
It seems there is a bug.
I tried to listen first using BDADDR_ANY and then again listen
using the adapter address for a particular PSM. If I try to connect
on that particular PSM from the remote device, then the incoming
connection follows the order of the listen rather than the priority.
Ex:
1) Listen
-sh-4.1# /opt/l2test -d -P 11
l2test[3450]: Waiting for connection on psm 11 ...
2) Listen
-sh-4.1# /opt/l2test -w -P 11 -i hci0
l2test[3451]: Waiting for connection on psm 11 ...
If we try to connect from the remote device, then the connection goes to
First listen
-sh-4.1# /opt/l2test -n -P 11 00:02:4B:28:2C:48
Similarly if we swap the order of the listen 1 & 2, then connection goes to
hci0 one.
The following diff resolves the issue for me. I'm not sure its correct or
not.
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 33b5d34..12f9b52 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -1499,7 +1499,7 @@ static struct l2cap_chan *l2cap_global_chan_by_psm(int
state, __le16 psm,
src_any = !bacmp(&bt_sk(sk)->src, BDADDR_ANY);
dst_any = !bacmp(&bt_sk(sk)->dst, BDADDR_ANY);
if ((src_match && dst_any) || (src_any && dst_match)
||
- (src_any && dst_any))
+ (!c1 && src_any && dst_any))
c1 = c;
}
}
Regards,
Syam