error on connect

When I connect from a pc to another (both running bluez, own programs), I get sometimes this error:
hci_acldata_packet: hci0 ACL packet for unknown connection handle 6

I can't reproduce it. sometimes it happen, sometimes not. If the error occures, the connection breaks down else it works fine...

What means this error?

Hi Marco,

Quoted 7 lines

When I connect from a pc to another (both running bluez, own programs), I get sometimes this error:
hci_acldata_packet: hci0 ACL packet for unknown connection handle 6

I can't reproduce it. sometimes it happen, sometimes not. If the error occures, the connection breaks down else it works fine...

What means this error?

it actually means what it says. You receive a data packet for a closed connection. What manufacturer is it? Is is not CSR.

Regards

Marcel

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

Yes. Broadcom dongles cause the problem.
Actually it's only the slave (listening dongle).

I tested all combinations with a minimal slave and master (only connects/accept connection and quit directly again).
the master (connecting one) doesn't care, csr and broadcom worked fine.

but the listening one gives the mentioned error (on more than 50% of the tries) I tried with a acer and ednet broadcom dongle.
A csr works just perfectly fine...

after the error, the dongle keeps waiting for a slave but won't access any more connections. so, basically the dongle is completly freezed.

Hi Marco,

Quoted 2 lines

Yes. Broadcom dongles cause the problem.
Actually it's only the slave (listening dongle).

what kind of Broadcom dongle is this?

Quoted 8 lines

I tested all combinations with a minimal slave and master (only connects/accept connection and quit directly again). the master (connecting one) doesn't care, csr and broadcom worked fine.

but the listening one gives the mentioned error (on more than 50% of the tries) I tried with a acer and ednet broadcom dongle. A csr works just perfectly fine...

after the error, the dongle keeps waiting for a slave but won't access any more connections. so, basically the dongle is completly freezed.

Send in the "hcidump -X -V" for it.

HCI Event: Connect Request (0x04) plen 10

HCI Event: Command Status (0x0f) plen 4

ACL data: handle 7 flags 0x02 dlen 12

HCI Event: Connect Complete (0x03) plen 11

HCI Event: Command Complete (0x0e) plen 6

HCI Event: Command Status (0x0f) plen 4

HCI Event: Max Slots Change (0x1b) plen 3

HCI Event: Disconn Complete (0x05) plen 4

HCI Event: Connect Request (0x04) plen 10

HCI Event: Command Status (0x0f) plen 4

HCI Event: Connect Complete (0x03) plen 11

HCI Event: Command Complete (0x0e) plen 6

ACL data: handle 7 flags 0x02 dlen 12

HCI Event: Command Status (0x0f) plen 4

HCI Event: Max Slots Change (0x1b) plen 3

ACL data: handle 7 flags 0x02 dlen 16

HCI Event: Number of Completed Packets (0x13) plen 5

ACL data: handle 7 flags 0x02 dlen 14

HCI Event: Number of Completed Packets (0x13) plen 5

ACL data: handle 7 flags 0x02 dlen 8

ACL data: handle 7 flags 0x02 dlen 18

ACL data: handle 7 flags 0x02 dlen 8

ACL data: handle 7 flags 0x02 dlen 12

ACL data: handle 7 flags 0x02 dlen 12

ACL data: handle 7 flags 0x02 dlen 8

ACL data: handle 7 flags 0x02 dlen 8

ACL data: handle 7 flags 0x02 dlen 8

ACL data: handle 7 flags 0x02 dlen 12

HCI Event: Number of Completed Packets (0x13) plen 5

HCI Event: Number of Completed Packets (0x13) plen 5

HCI Event: Disconn Complete (0x05) plen 4

Quoted 4 lines

Quoted 2 lines

Yes. Broadcom dongles cause the problem.
Actually it's only the slave (listening dongle).

what kind of Broadcom dongle is this?

I sent you pretty exactly one week ago the data from two broadcom 1.2 dongles (ednet and acer). Inform me if you need the informations again. both dongles now make the problem...

Quoted 8 lines

Quoted 8 lines

I tested all combinations with a minimal slave and master (only connects/accept connection and quit directly again).
the master (connecting one) doesn't care, csr and broadcom worked fine.

but the listening one gives the mentioned error (on more than 50% of the tries) I tried with a acer and ednet broadcom dongle.
A csr works just perfectly fine...

Quoted 5 lines

Quoted 2 lines

after the error, the dongle keeps waiting for a slave but won't access any more connections. so, basically the dongle is completly freezed.

Send in the "hcidump -X -V" for it.

I attached a successfull and a failed attemp from the listening acer dongle. Hope they are informative...

Hi Marco,

Quoted 3 lines

Quoted 3 lines

Quoted 2 lines

Yes. Broadcom dongles cause the problem.
Actually it's only the slave (listening dongle).

Quoted 4 lines

Quoted 1 line

what kind of Broadcom dongle is this?

I sent you pretty exactly one week ago the data from two broadcom 1.2 dongles (ednet and acer). Inform me if you need the informations again. both dongles now make the problem...

include them again, because my mailboxes are a little bit bigger ;)

Quoted 11 lines

Quoted 10 lines

Quoted 7 lines

I tested all combinations with a minimal slave and master (only connects/accept connection and quit directly again). the master (connecting one) doesn't care, csr and broadcom worked fine.

but the listening one gives the mentioned error (on more than 50% of the tries) I tried with a acer and ednet broadcom dongle. A csr works just perfectly fine...

after the error, the dongle keeps waiting for a slave but won't access any more connections. so, basically the dongle is completly freezed.

Send in the "hcidump -X -V" for it.

Quoted 2 lines

I attached a successfull and a failed attemp from the listening acer dongle. Hope they are informative...

These dumps gives no information about why you should receive a data packet with an invalid connection handle. However maybe the change of the packet types confuses the Broadcom dongle.

With what programs do you tested these things? I must try to reproduce it reliable.

Quoted 10 lines · Marcel Holtmann

Hi Marco,

Quoted 7 lines

Quoted 5 lines

Quoted 2 lines

Yes. Broadcom dongles cause the problem.
Actually it's only the slave (listening dongle).

what kind of Broadcom dongle is this?

Quoted 6 lines

Quoted 2 lines

I sent you pretty exactly one week ago the data from two broadcom 1.2 dongles (ednet and acer). Inform me if you need the informations again. both dongles now make the problem...

include them again, because my mailboxes are a little bit bigger ;)

here we go:
the file acer and ednet. my hcidump was from the acer.

Quoted 13 lines

Quoted 13 lines

Quoted 11 lines

Quoted 7 lines

I tested all combinations with a minimal slave and master (only connects/accept connection and quit directly again). the master (connecting one) doesn't care, csr and broadcom worked fine.

but the listening one gives the mentioned error (on more than 50% of the tries) I tried with a acer and ednet broadcom dongle. A csr works just perfectly fine...

after the error, the dongle keeps waiting for a slave but won't access any more connections. so, basically the dongle is completly freezed.

Send in the "hcidump -X -V" for it.

Quoted 8 lines

Quoted 2 lines

I attached a successfull and a failed attemp from the listening acer dongle. Hope they are informative...

These dumps gives no information about why you should receive a data packet with an invalid connection handle. However maybe the change of the packet types confuses the Broadcom dongle.

change of packet type? i'm not doing anything like these intentionally.

Quoted 2 lines

With what programs do you tested these things? I must try to reproduce it reliable.

gallerie-connect.cpp and arm-listen.cpp
please note these are quick and dirty pasts of a c++ project. another thing to mention is that you have to edit the macaddresses because I hardcoded them (the pc's have multiple dongles).

thanks a lot!

regards
Marco

------------------------------------------------------------------------

hci0: Type: USB
BD Address: 00:02:72:C3:26:F5 ACL MTU: 377:10 SCO MTU: 16:0 UP RUNNING PSCAN ISCAN
RX bytes:390 acl:0 sco:0 events:17 errors:0
TX bytes:311 acl:0 sco:0 commands:17 errors:0
Features: 0xff 0xfe 0x0d 0x38 0x08 0x08 0x00 0x00
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH HOLD SNIFF PARK
Link mode: MASTER
Name: 'BlueZ (0)'
Class: 0x3e0100
Service Classes: Networking, Rendering, Capturing
Device Class: Computer, Uncategorized
HCI Ver: 1.2 (0x2) HCI Rev: 0xa LMP Ver: 1.2 (0x2) LMP Subver: 0x309
Manufacturer: Broadcom Corporation (15)

T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc= 46/900 us ( 5%), #Int=  2, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 0.00
S:  Product=USB OHCI Root Hub
S:  SerialNumber=c5056000
C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms
T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  4 Spd=12  MxCh= 0
D:  Ver= 2.00 Cls=e0(unk. ) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0a12 ProdID=0001 Rev=15.86
C:* #Ifs= 3 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=(none)
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=(none)
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=(none)
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=(none)
E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=(none)
E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=(none)
E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
I:  If#= 2 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=00 Driver=(none)
T:  Bus=01 Lev=01 Prnt=01 Port=01 Cnt=02 Dev#=  3 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=e0(unk. ) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0a5c ProdID=200a Rev= 0.01
S:  Manufacturer=Broadcom
S:  Product=CCBT2035BDGP23-1
S:  SerialNumber=000272C326F5
C:* #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=(none)
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=(none)
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=(none)
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=(none)
E:  Ad=83(I) Atr=01(Isoc) MxPS=  32 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  32 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=(none)
E:  Ad=83(I) Atr=01(Isoc) MxPS=  64 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  64 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=(none)
E:  Ad=83(I) Atr=01(Isoc) MxPS=  64 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  64 Ivl=1ms
I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=84(I) Atr=02(Bulk) MxPS=  32 Ivl=0ms
E:  Ad=04(O) Atr=02(Bulk) MxPS=  32 Ivl=0ms

------------------------------------------------------------------------

hci0: Type: USB
BD Address: 00:02:72:C3:F2:10 ACL MTU: 377:10 SCO MTU: 16:0 UP RUNNING PSCAN ISCAN
RX bytes:526 acl:0 sco:0 events:42 errors:0
TX bytes:323 acl:0 sco:0 commands:19 errors:0
Features: 0xff 0xfe 0x0d 0x38 0x08 0x08 0x00 0x00
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH HOLD SNIFF PARK
Link mode: ACCEPT MASTER
Name: 'btLapi'
Class: 0x100100
Service Classes:
Device Class: Computer, Uncategorized
HCI Ver: 1.2 (0x2) HCI Rev: 0x14 LMP Ver: 1.2 (0x2) LMP Subver: 0x309
Manufacturer: Broadcom Corporation (15)

T:  Bus=04 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=480 MxCh= 6
B:  Alloc=  0/800 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 2.00 Cls=09(hub  ) Sub=00 Prot=01 MxPS= 8 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.8-24.14-default ehci_hcd
S:  Product=EHCI Host Controller
S:  SerialNumber=0000:00:1d.7
C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=256ms

T:  Bus=03 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.8-24.14-default uhci_hcd
S:  Product=UHCI Host Controller
S:  SerialNumber=0000:00:1d.2
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

T:  Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc= 23/900 us ( 3%), #Int=  1, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.8-24.14-default uhci_hcd
S:  Product=UHCI Host Controller
S:  SerialNumber=0000:00:1d.1
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

T:  Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 16 Spd=12  MxCh= 0
D:  Ver= 1.10 Cls=e0(unk. ) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
P:  Vendor=0a5c ProdID=200a Rev= 0.01
S:  Manufacturer=Broadcom
S:  Product=CCBT2035BDGP23-2
S:  SerialNumber=000272C3F210
C:* #Ifs= 3 Cfg#= 1 Atr=a0 MxPwr=100mA
I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(unk. ) Sub=01 Prot=01 Driver=hci_usb
E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=(none)
E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=(none)
E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=(none)
E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=(none)
E:  Ad=83(I) Atr=01(Isoc) MxPS=  32 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  32 Ivl=1ms
I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=(none)
E:  Ad=83(I) Atr=01(Isoc) MxPS=  64 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  64 Ivl=1ms
I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(unk. ) Sub=01 Prot=01 Driver=(none)
E:  Ad=83(I) Atr=01(Isoc) MxPS=  64 Ivl=1ms
E:  Ad=03(O) Atr=01(Isoc) MxPS=  64 Ivl=1ms
I:  If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=84(I) Atr=02(Bulk) MxPS=  32 Ivl=0ms
E:  Ad=04(O) Atr=02(Bulk) MxPS=  32 Ivl=0ms

T:  Bus=01 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=12  MxCh= 2
B:  Alloc=  0/900 us ( 0%), #Int=  0, #Iso=  0
D:  Ver= 1.10 Cls=09(hub  ) Sub=00 Prot=00 MxPS= 8 #Cfgs=  1
P:  Vendor=0000 ProdID=0000 Rev= 2.06
S:  Manufacturer=Linux 2.6.8-24.14-default uhci_hcd
S:  Product=UHCI Host Controller
S:  SerialNumber=0000:00:1d.0
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=  0mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=09(hub  ) Sub=00 Prot=00 Driver=hub
E:  Ad=81(I) Atr=03(Int.) MxPS=   2 Ivl=255ms

------------------------------------------------------------------------

// g++ -O2 -lbluetooth gallerie-connect.cpp -o gallerie-connect

#include <sys/ioctl.h>
#include <sys/socket.h>
#include <sys/poll.h>
#include <bluetooth/bluetooth.h>
#include <bluetooth/rfcomm.h>
#include <bluetooth/hci.h>
#include <bluetooth/hci_lib.h>
#include <unistd.h>

#include <iostream>

using namespace std;

int main()

{
	struct sockaddr_rc laddr, raddr;
	int sock;

	str2ba("00:02:72:C3:F2:10", &laddr.rc_bdaddr);
	laddr.rc_family = AF_BLUETOOTH;
	laddr.rc_channel = 1;

	str2ba("00:02:72:C3:26:F5", &raddr.rc_bdaddr);
	raddr.rc_family = AF_BLUETOOTH;
	raddr.rc_channel = 5;

	if((sock = socket(AF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM)) < 0)
	{
		cout << "Can't create RFCOMM socket" << endl;
		exit(1);
	}

	if(bind(sock, (struct sockaddr *)&laddr, sizeof(laddr)) < 0)
	{
		cout << "Can't bind RFCOMM socket" << endl;
		close(sock);
		exit(1);
	}

	if(connect(sock, (struct sockaddr *)&raddr, sizeof(raddr)) < 0)
	{
		cout << "Can't connect RFCOMM socket" << endl;
		close(sock);
		exit(1);
	}

	cout << "connected" << endl;

	close(sock);
}

------------------------------------------------------------------------

// arm-linux-g++ -O2 -lbluetooth arm-listen.cpp -o arm-listen

#include <sys/ioctl.h>
#include <sys/socket.h>
#include <sys/poll.h>
#include <bluetooth/bluetooth.h>
#include <bluetooth/rfcomm.h>
#include <bluetooth/hci.h>
#include <bluetooth/hci_lib.h>
#include <unistd.h>

#include <iostream>

using namespace std;

int main()

{
	int sock, client;
	socklen_t alen;
	struct sockaddr_rc addr;

	str2ba("00:02:72:C3:26:F5", &addr.rc_bdaddr);
	addr.rc_family = AF_BLUETOOTH;
	addr.rc_channel = 5;
	alen = sizeof(addr);

	if((sock = socket(AF_BLUETOOTH, SOCK_STREAM, BTPROTO_RFCOMM)) < 0)
	{
		cout << "clientService: socket(...) failed" << endl;
		exit(1);
	}

	if(bind(sock, (struct sockaddr *)&addr, alen) < 0)
	{
		cout << "clientService: bind(...) failed" << endl;
		close(sock);
		exit(1);
	}

	if(listen(sock, 1) < 0)
	{
		cout << "clientService: listen(...) failed\n" << endl;
		exit(1);
	}

	client = accept(sock, (struct sockaddr *)&addr, &alen);
	cout << "connection here" << endl;
	close(client);

	close(sock);

	return 0;
}

have you already had luck regarding this topic?

I don't had the time to search my Broadcom dongles. Maybe you should try to get yourself some CSR based dongles.

HCI Event: Connect Request (0x04) plen 10

HCI Event: Command Status (0x0f) plen 4

HCI Event: Connect Complete (0x03) plen 11

HCI Event: Command Complete (0x0e) plen 6

Quoted 2 lines

I don't had the time to search my Broadcom dongles. Maybe you should try to get yourself some CSR based dongles.

Unfortunately I'm bound to the broadcom dongles for multipe reasons, so I'd be very grateful if you could take a look at the problem.

I did some hcidump tests and I think I figured out the source of the problem. Please forgive me that this email contains some information I already postet, it's just to give a whole picture...
This is the start of a successfull connection (please note my added #N#):

Quoted 1 line

HCI Event: Connect Request (0x04) plen 10

     bdaddr 00:02:72:C3:F2:10 class 0x3e0100 type ACL
< HCI Command: Accept Connection Request (0x01|0x0009) plen 7
     bdaddr 00:02:72:C3:F2:10 role 0x01
     Role: Slave

Quoted 1 line

HCI Event: Command Status (0x0f) plen 4

     Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1

#1#
#1#

Quoted 1 line

HCI Event: Connect Complete (0x03) plen 11

     status 0x00 handle 7 bdaddr 00:02:72:C3:F2:10 type ACL encrypt 0x00

< HCI Command: Write Link Policy Settings (0x02|0x000d) plen 4
handle 7 policy 0x0f
Link policy: RSWITCH HOLD SNIFF PARK

Quoted 1 line

HCI Event: Command Complete (0x0e) plen 6

     Write Link Policy Settings (0x02|0x000d) ncmd 1
     status 0x00 handle 7

< HCI Command: Change Connection Packet Type (0x01|0x000f) plen 4
handle 7 ptype 0xcc18
Packet type: DM1 DM3 DM5 DH1 DH3 DH5
#2# > ACL data: handle 7 flags 0x02 dlen 12
#2# L2CAP(s): Connect req: psm 3 scid 0x0040

If a broadcom dongle is listening, sometimes the ACL packet marked with #2# is received where the #1# lines are. Actually, looking at the hcidump of the sending dongle, that's the time the packet is sent (alway, dongle independant).

It looks like this too early packet now causes the (sensefull) "hci_acldata_packet: hci1 ACL packet for unknown connection handle 6" kernel error message. The dongle then waits for this acl package and thinks this connection is in etablishing phase, so it is blocked.

Quoted 1 line

From a quick look at the kernel code, it seems that an ACL packet for an

The question now is, who is responsible for holding this packed back? The kernel? The dongle itself?

Hi Marco,

Quoted 33 lines

Quoted 3 lines

I don't had the time to search my Broadcom dongles.

Maybe you should try to get yourself some CSR based dongles.

Unfortunately I'm bound to the broadcom dongles for multipe reasons, so I'd be very grateful if you could take a look at the problem.

I did some hcidump tests and I think I figured out the source of the problem. Please forgive me that this email contains some information I already postet, it's just to give a whole picture... This is the start of a successfull connection (please note my added #N#):

Quoted 1 line

HCI Event: Connect Request (0x04) plen 10

    bdaddr 00:02:72:C3:F2:10 class 0x3e0100 type ACL
< HCI Command: Accept Connection Request (0x01|0x0009) plen 7
    bdaddr 00:02:72:C3:F2:10 role 0x01
    Role: Slave

Quoted 1 line

HCI Event: Command Status (0x0f) plen 4

    Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1

#1#
#1#

Quoted 1 line

HCI Event: Connect Complete (0x03) plen 11

    status 0x00 handle 7 bdaddr 00:02:72:C3:F2:10 type ACL encrypt 0x00

< HCI Command: Write Link Policy Settings (0x02|0x000d) plen 4
handle 7 policy 0x0f
Link policy: RSWITCH HOLD SNIFF PARK

Quoted 1 line

HCI Event: Command Complete (0x0e) plen 6

    Write Link Policy Settings (0x02|0x000d) ncmd 1
    status 0x00 handle 7

< HCI Command: Change Connection Packet Type (0x01|0x000f) plen 4
handle 7 ptype 0xcc18
Packet type: DM1 DM3 DM5 DH1 DH3 DH5
#2# > ACL data: handle 7 flags 0x02 dlen 12
#2# L2CAP(s): Connect req: psm 3 scid 0x0040

Quoted 1 line

If a broadcom dongle is listening, sometimes the ACL packet marked with #2# is received where the #1# lines are. Actually, looking at the hcidump of the sending dongle, that's the time the packet is sent (alway, dongle independant).

do you have a dump where this actually happens?

Quoted 4 lines

It looks like this too early packet now causes the (sensefull) "hci_acldata_packet: hci1 ACL packet for unknown connection handle 6" kernel error message. The dongle then waits for this acl package and thinks this connection is in etablishing phase, so it is blocked.

Quoted 1 line

From a quick look at the kernel code, it seems that an ACL packet for an

unknown connection handle may corrupt the HCI flow control.

Quoted 1 line

The question now is, who is responsible for holding this packed back? The kernel? The dongle itself?

The dongle is responsible for that and actually it is only allowed to send data packets after the "Connect Complete" event. Otherwise we don't know its handle and thus can't correctly assign it to a connection.

Quoted 6 lines

Quoted 4 lines

If a broadcom dongle is listening, sometimes the ACL packet marked with #2# is received where the #1# lines are. Actually, looking at the hcidump of the sending dongle, that's the time the packet is sent (alway, dongle independant).

do you have a dump where this actually happens?

the dump of the listeining or the sending dongle?
for the listening one, I sent a hcidump from a successfull and failed connection. with a diff, you see exactly what I described.

Quoted 7 lines

Quoted 6 lines

It looks like this too early packet now causes the (sensefull) "hci_acldata_packet: hci1 ACL packet for unknown connection handle 6" kernel error message. The dongle then waits for this acl package and thinks this connection is in etablishing phase, so it is blocked.

From a quick look at the kernel code, it seems that an ACL packet for an

unknown connection handle may corrupt the HCI flow control.

I think exactly this happens...

Quoted 6 lines

Quoted 2 lines

The question now is, who is responsible for holding this packed back? The kernel? The dongle itself?

The dongle is responsible for that and actually it is only allowed to send data packets after the "Connect Complete" event. Otherwise we don't know its handle and thus can't correctly assign it to a connection.

but then it's strainge that these ACL packets are always sent before the "connection" successfull packet. or do I right now miss something?

Hi Marco,

Quoted 2 lines

Quoted 2 lines

Quoted 1 line

If a broadcom dongle is listening, sometimes the ACL packet marked with #2# is received where the #1# lines are. Actually, looking at the hcidump of the sending dongle, that's the time the packet is sent (alway, dongle independant).

Quoted 4 lines

Quoted 1 line

do you have a dump where this actually happens?

the dump of the listeining or the sending dongle?
for the listening one, I sent a hcidump from a successfull and failed connection. with a diff, you see exactly what I described.

I checked the thread and I found the listening one. The handles are matching and now I fully understand whats happening.

Quoted 6 lines

Quoted 4 lines

Quoted 3 lines

It looks like this too early packet now causes the (sensefull) "hci_acldata_packet: hci1 ACL packet for unknown connection handle 6" kernel error message. The dongle then waits for this acl package and thinks this connection is in etablishing phase, so it is blocked.

Quoted 1 line

From a quick look at the kernel code, it seems that an ACL packet for an

unknown connection handle may corrupt the HCI flow control.

I think exactly this happens...

However even if I fix the HCI flow control problem, the packet is still lost, because we don't know the connection handle at that time.

Quoted 7 lines

Quoted 5 lines

Quoted 1 line

The question now is, who is responsible for holding this packed back? The kernel? The dongle itself?

The dongle is responsible for that and actually it is only allowed to send data packets after the "Connect Complete" event. Otherwise we don't know its handle and thus can't correctly assign it to a connection.

but then it's strainge that these ACL packets are always sent before the "connection" successfull packet. or do I right now miss something?

This must be a bug in the Broadcom link manager firmware. Seems like BlueZ is "too fast" for these chips.

If you wanna workaround this problem you must put potential ACL data packets into a queue and then check this queue after you received the connection handle.

Does this happen with both Broadcom dongles you have?

You only saw that on the listing side, right?

Quoted 8 lines

Quoted 8 lines

Quoted 7 lines

Quoted 6 lines

It looks like this too early packet now causes the (sensefull) "hci_acldata_packet: hci1 ACL packet for unknown connection handle 6" kernel error message. The dongle then waits for this acl package and thinks this connection is in etablishing phase, so it is blocked.

From a quick look at the kernel code, it seems that an ACL packet for an

unknown connection handle may corrupt the HCI flow control.

Quoted 4 lines

Quoted 1 line

I think exactly this happens...

However even if I fix the HCI flow control problem, the packet is still lost, because we don't know the connection handle at that time.

yes, thats what seems strainge: why is this ACL packet sent that early? that doesn't make sense for me (but I din't develop bluetooth)... In my opinion, it should be sent after the connection is etablished.

Quoted 13 lines

Quoted 9 lines

Quoted 6 lines

Quoted 2 lines

The question now is, who is responsible for holding this packed back? The kernel? The dongle itself?

The dongle is responsible for that and actually it is only allowed to send data packets after the "Connect Complete" event. Otherwise we don't know its handle and thus can't correctly assign it to a connection.

but then it's strainge that these ACL packets are always sent before the "connection" successfull packet. or do I right now miss something?

This must be a bug in the Broadcom link manager firmware. Seems like BlueZ is "too fast" for these chips.

Quoted 3 lines

If you wanna workaround this problem you must put potential ACL data packets into a queue and then check this queue after you received the connection handle.

that's pretty ugly. Maybe there's another solution for this. I think that the problem isnt yet fully understood.

Quoted 1 line

You only saw that on the listing side, right?

what do you mean with this?
on the sending side - if i remember right - the acl packet is alway sent before the connection is successfull etablished. I'll check again...

Hi Marco,

Quoted 5 lines

Quoted 5 lines

Quoted 5 lines

Quoted 4 lines

Quoted 3 lines

It looks like this too early packet now causes the (sensefull) "hci_acldata_packet: hci1 ACL packet for unknown connection handle 6" kernel error message. The dongle then waits for this acl package and thinks this connection is in etablishing phase, so it is blocked.

Quoted 1 line

From a quick look at the kernel code, it seems that an ACL packet for an

unknown connection handle may corrupt the HCI flow control.

Quoted 8 lines

Quoted 4 lines

Quoted 1 line

I think exactly this happens...

However even if I fix the HCI flow control problem, the packet is still lost, because we don't know the connection handle at that time.

yes, thats what seems strainge: why is this ACL packet sent that early? that doesn't make sense for me (but I din't develop bluetooth)... In my opinion, it should be sent after the connection is etablished.

It is not only your opinion. The specification defines it this way. This is simply a race condition inside the link manager.

Quoted 10 lines

Quoted 10 lines

Quoted 9 lines

Quoted 5 lines

Quoted 1 line

The question now is, who is responsible for holding this packed back? The kernel? The dongle itself?

The dongle is responsible for that and actually it is only allowed to send data packets after the "Connect Complete" event. Otherwise we don't know its handle and thus can't correctly assign it to a connection.

but then it's strainge that these ACL packets are always sent before the "connection" successfull packet. or do I right now miss something?

Quoted 8 lines

Quoted 6 lines

This must be a bug in the Broadcom link manager firmware. Seems like BlueZ is "too fast" for these chips.

If you wanna workaround this problem you must put potential ACL data packets into a queue and then check this queue after you received the connection handle.

that's pretty ugly. Maybe there's another solution for this. I think that the problem isnt yet fully understood.

The problem is clear. The Broadcom link manager has a race condition here. It should queue the package until they send the connect complete event.

Quoted 4 lines

Quoted 1 line

You only saw that on the listing side, right?

what do you mean with this?
on the sending side - if i remember right - the acl packet is alway sent before the connection is successfull etablished. I'll check again...

Please do so, but there should be no problem. We only send any data to the chip after we received the connect complete. All previous packages are queued.

Regards

Marcel

-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

Do I get this right:
- The ACL packet that cause the problem is sent before the connection is etablished. This is ok and defined in the specification.

- The received dongle is responsible to keep this packet back until the connection is etablished and process them then.

- the csr dongles seem to handle this correct.

- the broadcom dongle seem to don't handle this correct. they probably suffer a race condition. so they may work or may not work.

Hi Marco,

Quoted 3 lines

Do I get this right:
- The ACL packet that cause the problem is sent before the connection is etablished. This is ok and defined in the specification.

this is not ok and can also not happen since you only get the connection handle from the connect complete event. In BlueZ this is indicated with the hci_proto_connect_cfm() and only at that time the L2CAP layer starts sending out its connect request. Please check the sender side again.

Quoted 2 lines

- The received dongle is responsible to keep this packet back until the connection is etablished and process them then.

In general yes, they should queue the data packet.

Quoted 1 line

- the csr dongles seem to handle this correct.

So far I've never seen this problem with a CSR dongle. Not even with the very old ones.

Quoted 2 lines

- the broadcom dongle seem to don't handle this correct. they probably suffer a race condition. so they may work or may not work.

Maybe the stacks Broadcom tested their dongles with are needing some time before they can send out the first ACL data packet. Or they do other HCI tasks before they start L2CAP. However this is a problem with the dongle, because the ACL data packet is not allowed at that time.

Quoted 7 lines

Quoted 2 lines

- The ACL packet that cause the problem is sent before the connection is etablished. This is ok and defined in the specification.

this is not ok and can also not happen since you only get the connection handle from the connect complete event. In BlueZ this is indicated with the hci_proto_connect_cfm() and only at that time the L2CAP layer starts sending out its connect request. Please check the sender side again.

yes. I got this wrong. this way it makes much more sense...

Quoted 7 lines

Quoted 2 lines

- the broadcom dongle seem to don't handle this correct. they probably suffer a race condition. so they may work or may not work.

Maybe the stacks Broadcom tested their dongles with are needing some time before they can send out the first ACL data packet. Or they do other HCI tasks before they start L2CAP. However this is a problem with the dongle, because the ACL data packet is not allowed at that time.

ok. that leads me to some questions:
- what would be the behaviour of the listening dongle if you fix the flow control after this error occured?

- (just curious) How can you find out that this packet was processed too early? does bluez always know the order of processed packets like the hcidump shows?

- Are you interested in having this ACL datapacket queue you supposed inside bluez (kernel)? respectively, did you mean to do this in the program?

and two comments:
- you told bluez might be too fast for ednet. actually bluez looks like it's too fast for the nokia 6230 too. i've to wait 1 second before I close a connection, else the mobile phone doesn't get all packets. maybee this is a bigger problem (the speed thing)...

- I made a try with windows. it played the listening part with the broadcom dongle. Unfortunately i haven't a hcidump here, but from more than 100 connection tries, every single one worked...
but as I said, this is not reliable because I don't know what windows is doing in background...

Hi Marco,

Quoted 8 lines

Quoted 7 lines

Quoted 2 lines

- The ACL packet that cause the problem is sent before the connection is etablished. This is ok and defined in the specification.

this is not ok and can also not happen since you only get the connection handle from the connect complete event. In BlueZ this is indicated with the hci_proto_connect_cfm() and only at that time the L2CAP layer starts sending out its connect request. Please check the sender side again.

Quoted 1 line

yes. I got this wrong. this way it makes much more sense...

please do a "hcidump -X -V" for the sender side, too. I like to look how the Broadcom responds here.

Quoted 11 lines

Quoted 7 lines

Quoted 2 lines

- the broadcom dongle seem to don't handle this correct. they probably suffer a race condition. so they may work or may not work.

Maybe the stacks Broadcom tested their dongles with are needing some time before they can send out the first ACL data packet. Or they do other HCI tasks before they start L2CAP. However this is a problem with the dongle, because the ACL data packet is not allowed at that time.

ok. that leads me to some questions:
- what would be the behaviour of the listening dongle if you fix the flow control after this error occured?

If this package really corrupts the internal HCI flow control states of BlueZ then this needs to be fixed. However this will not change anything of the behavior, because the L2CAP connect request packet will be still dropped.

Quoted 2 lines

- (just curious) How can you find out that this packet was processed too early? does bluez always know the order of processed packets like the hcidump shows?

The hcidump order should match the kernel queue order. Nobody really verified this, but I doubt that there is a problem.

Quoted 2 lines

- Are you interested in having this ACL datapacket queue you supposed inside bluez (kernel)? respectively, did you mean to do this in the program?

This must be done inside the kernel and it will be an ugly workaround.

Quoted 4 lines

and two comments:
- you told bluez might be too fast for ednet. actually bluez looks like
it's too fast for the nokia 6230 too. i've to wait 1 second before I close a connection, else the mobile phone doesn't get all packets. maybee this is a bigger problem (the speed thing)...

I meant this in comparison to the Windows stacks. We will do the final setup of the ACL link (packet type etc.) at the same time the L2CAP layer already sends its first commands. This is because BlueZ is fully multi-threaded and not one stupid state machine for all layers thing.

Quoted 3 lines

- I made a try with windows. it played the listening part with the
broadcom dongle. Unfortunately i haven't a hcidump here, but from more than 100 connection tries, every single one worked... but as I said, this is not reliable because I don't know what windows is doing in background...

If this is the Widcomm stack you can look at it with Spylite. For the XP stack I have no idea how to do that without an USB sniffer.

HCI Event: Command Status (0x0f) plen 4

HCI Event: Connect Complete (0x03) plen 11

HCI Event: Command Complete (0x0e) plen 6

HCI Event: Number of Completed Packets (0x13) plen 5

HCI Event: Max Slots Change (0x1b) plen 3

HCI Event: Command Status (0x0f) plen 4

HCI Event: Connect Complete (0x03) plen 11

HCI Event: Command Complete (0x0e) plen 6

HCI Event: Number of Completed Packets (0x13) plen 5

ACL data: handle 6 flags 0x02 dlen 16

HCI Event: Max Slots Change (0x1b) plen 3

ACL data: handle 6 flags 0x02 dlen 14

ACL data: handle 6 flags 0x02 dlen 16

ACL data: handle 6 flags 0x02 dlen 8

ACL data: handle 6 flags 0x02 dlen 18

ACL data: handle 6 flags 0x02 dlen 8

ACL data: handle 6 flags 0x02 dlen 12

ACL data: handle 6 flags 0x02 dlen 8

ACL data: handle 6 flags 0x02 dlen 12

HCI Event: Number of Completed Packets (0x13) plen 5

ACL data: handle 6 flags 0x02 dlen 8

ACL data: handle 6 flags 0x02 dlen 8

ACL data: handle 6 flags 0x02 dlen 8

ACL data: handle 6 flags 0x02 dlen 12

HCI Event: Number of Completed Packets (0x13) plen 5

HCI Event: Command Status (0x0f) plen 4

HCI Event: Disconn Complete (0x05) plen 4

HCI Event: Connect Request (0x04) plen 10

HCI Event: Command Status (0x0f) plen 4

ACL data: handle 7 flags 0x02 dlen 12

HCI Event: Connect Complete (0x03) plen 11

HCI Event: Command Complete (0x0e) plen 6

HCI Event: Command Status (0x0f) plen 4

HCI Event: Max Slots Change (0x1b) plen 3

HCI Event: Connect Request (0x04) plen 10

HCI Event: Command Status (0x0f) plen 4

HCI Event: Connect Complete (0x03) plen 11

HCI Event: Command Complete (0x0e) plen 6

HCI Event: Command Status (0x0f) plen 4

ACL data: handle 7 flags 0x02 dlen 12

HCI Event: Max Slots Change (0x1b) plen 3

ACL data: handle 7 flags 0x02 dlen 16

ACL data: handle 7 flags 0x02 dlen 14

ACL data: handle 7 flags 0x02 dlen 8

ACL data: handle 7 flags 0x02 dlen 18

ACL data: handle 7 flags 0x02 dlen 8

ACL data: handle 7 flags 0x02 dlen 12

HCI Event: Number of Completed Packets (0x13) plen 5

ACL data: handle 7 flags 0x02 dlen 8

ACL data: handle 7 flags 0x02 dlen 12

ACL data: handle 7 flags 0x02 dlen 8

ACL data: handle 7 flags 0x02 dlen 8

ACL data: handle 7 flags 0x02 dlen 12

HCI Event: Number of Completed Packets (0x13) plen 5

HCI Event: Disconn Complete (0x05) plen 4

Quoted 8 lines

Quoted 5 lines

- I made a try with windows. it played the listening part with the broadcom dongle. Unfortunately i haven't a hcidump here, but from more than 100 connection tries, every single one worked...
but as I said, this is not reliable because I don't know what windows is doing in background...

If this is the Widcomm stack you can look at it with Spylite. For the XP stack I have no idea how to do that without an USB sniffer.

It's a widcomm. But I think I can live with the timeout and will not check what windows is exactly doing...

Hi Marco,

Quoted 8 lines

Quoted 6 lines

Quoted 3 lines

- I made a try with windows. it played the listening part with the
broadcom dongle. Unfortunately i haven't a hcidump here, but from more than 100 connection tries, every single one worked... but as I said, this is not reliable because I don't know what windows is doing in background...

If this is the Widcomm stack you can look at it with Spylite. For the XP stack I have no idea how to do that without an USB sniffer.

It's a widcomm. But I think I can live with the timeout and will not check what windows is exactly doing...

try to get the HCI only log with Spylite. I am really interested in what they are doing.

Regards

Marcel

-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

Hi Marco,

Quoted 8 lines

Quoted 6 lines

Quoted 3 lines

- I made a try with windows. it played the listening part with the
broadcom dongle. Unfortunately i haven't a hcidump here, but from more than 100 connection tries, every single one worked... but as I said, this is not reliable because I don't know what windows is doing in background...

If this is the Widcomm stack you can look at it with Spylite. For the XP stack I have no idea how to do that without an USB sniffer.

It's a widcomm. But I think I can live with the timeout and will not check what windows is exactly doing...

try to get the HCI only log with Spylite. I am really interested in what they are doing.

Regards

Marcel

-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
Bluez-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users

Unfortunately spylite isn't supplied with my widcomm driver cd as mentioned on http://www.broadcom.com/products/bluetooth_faq_btw.php#_server and I'm not able to find it on widcom.com/broadcom.com...