I was talking to Marcel on the freenode chat and he suggested I post this issue to the mailing list...
I have some code where I make LE L2CAP connections to multiple sensor devices. On my laptop and any other x86-like device I have no problems with the code and everything works correctly. When I try to run the same code on several different ARM machines I have the same problem where the L2CAP sockets seem to get merged and all data returns on the last connected one.
Marcel asked for me to post the btmon logs of my problem but the logs essentially show that things are working correctly because I think it's getting all the data on the HCI level. You can see the 2 sensors have connection handles 64 and 65. However here is some output from my code (it's all coming down one file descriptor corresponding to the "78:c5:e5:6c:47:d3" device and the earlier file descriptor now receives nothing):
2013-10-28 20:18:54+0000 [-] 78:c5:e5:6c:47:d3 x-axis: -1
2013-10-28 20:18:54+0000 [-] 78:c5:e5:6c:47:d3 y-axis: -9
2013-10-28 20:18:54+0000 [-] 78:c5:e5:6c:47:d3 z-axis: -64
2013-10-28 20:18:54+0000 [-] 78:c5:e5:6c:47:d3 x-axis: -7
2013-10-28 20:18:54+0000 [-] 78:c5:e5:6c:47:d3 y-axis: -51
2013-10-28 20:18:54+0000 [-] 78:c5:e5:6c:47:d3 x-axis: 2
2013-10-28 20:18:54+0000 [-] 78:c5:e5:6c:47:d3 y-axis: -8
2013-10-28 20:19:10+0000 [-] 78:c5:e5:6c:47:d3 x-axis: -7
2013-10-28 20:19:10+0000 [-] 78:c5:e5:6c:47:d3 x-axis: -1
which corresponds to the btmon output:
[hci0] 20:18:54.359162 > ACL Data: handle 64 flags 0x02 dlen 8
04 00 04 00 1b 2a 00 ff .....*..
[hci0] 20:18:54.359454 > ACL Data: handle 64 flags 0x02 dlen 8
04 00 04 00 1b 2e 00 f7 ........
[hci0] 20:18:54.360633 > ACL Data: handle 64 flags 0x02 dlen 8
04 00 04 00 1b 32 00 c0 .....2..
[hci0] 20:18:54.561663 > ACL Data: handle 64 flags 0x02 dlen 8
04 00 04 00 1b 2a 00 f9 .....*..
[hci0] 20:18:54.564898 > ACL Data: handle 64 flags 0x02 dlen 8
04 00 04 00 1b 2e 00 cd ........
[hci0] 20:18:54.696646 > ACL Data: handle 64 flags 0x02 dlen 8
04 00 04 00 1b 2a 00 02 .....*..
[hci0] 20:18:54.698873 > ACL Data: handle 64 flags 0x02 dlen 8
04 00 04 00 1b 2e 00 f8 ........
[hci0] 20:19:10.383417 > ACL Data: handle 65 flags 0x02 dlen 8
04 00 04 00 1b 2a 00 f9 .....*..
[hci0] 20:19:10.439511 > ACL Data: handle 65 flags 0x02 dlen 8
04 00 04 00 1b 2a 00 ff .....*..
The ATT_OP_WRITE_CMD command to get the notifications are sent down the L2CAP sockets so communication towards the sensors seems to work correctly, it's just the data coming the other way is the issue.
-Tim
> I was trying to get a 3.4.67 kernel running on one ARM device but unfortu=
nately I can't seem to get the bluetooth dongle to be recognized (something=
to do with the USB code, I suspect). It's probably still an issue, though=
, so I'd really appreciate if you managed to find that patch!=0A=
=0A=
Okay, I found out that I could get my bluetooth dongle working if I used a =
powered hub (the internal USB sockets are working but have no power). So, =
I tried it out and have the same issue with mixed up L2CAP sockets.=0A=
=0A=
-Tim=
>> I actually need to know if bluetooth-next tree still has this issue. Tha=
t is first and foremost the one thing that needs to be checked.=0A=
=0A=
> I asked Tim to mention the kernel version on x86 vs. the version on=0A=
> ARM, because I vaguely remember this same issue being reported last=0A=
> year (or even 2011) and being fixed (If I find the patch, I will let=0A=
> you know). As Tim mentions later on, on x86 the issue does not happen=0A=
> on 3.8, but it is present on 3.2 (and I suspect it will also be=0A=
> present on 3.4 on x86 as well).=0A=
=0A=
I was going to say yesterday (until my computer suddenly died due to overhe=
ating): Can't it be assumed that it's okay in bluetooth-next since the iss=
ue seems to be gone with kernels > 3.4?=0A=
=0A=
I was trying to get a 3.4.67 kernel running on one ARM device but unfortuna=
tely I can't seem to get the bluetooth dongle to be recognized (something t=
o do with the USB code, I suspect). It's probably still an issue, though, =
so I'd really appreciate if you managed to find that patch!=0A=
=0A=
-Tim=0A=
=0A=