[Bluez-users] error on connect

[Bluez-users] error on connect

[Marco Trudel]

Hello everybody

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?


regards
Marco


-------------------------------------------------------
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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] error on connect

[Marcel Holtmann]

Hi Marco,

> 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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] error on connect

[Marco Trudel]

Hello Marcel

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.

can I do something against it?

regards
Marco


Marcel Holtmann wrote:
> Hi Marco,
> 
> 
>>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
> Bluez-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-users
> 
> 


-------------------------------------------------------
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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] error on connect

[Marcel Holtmann]

Hi Marco,

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

what kind of Broadcom dongle is this?

> 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.

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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] error on connect

[Marco Trudel]

[-- Attachment #1: Type: text/plain, Size: 1063 bytes --]

Hello Marcel

Marcel Holtmann wrote:
> Hi Marco,
> 
> 
>>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...

> 
>>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.

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


regards
Marco

[-- Attachment #2: hcidump-failure.txt --]
[-- Type: text/plain, Size: 1260 bytes --]

> 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
> HCI Event: Command Status (0x0f) plen 4
    Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1
> ACL data: handle 7 flags 0x02 dlen 12
    L2CAP(s): Connect req: psm 3 scid 0x0040
> 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
> 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
> HCI Event: Command Status (0x0f) plen 4
    Change Connection Packet Type (0x01|0x000f) status 0x0c ncmd 1
    Error: Command Disallowed
> HCI Event: Max Slots Change (0x1b) plen 3
  0000: 07 00 05

And after the client quits:
> HCI Event: Disconn Complete (0x05) plen 4
    status 0x00 handle 6 reason 0x13
    Reason: Remote User Terminated Connection

[-- Attachment #3: hcidump-success.txt --]
[-- Type: text/plain, Size: 5290 bytes --]

> 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
> HCI Event: Command Status (0x0f) plen 4
    Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1
> 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
> 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
> ACL data: handle 7 flags 0x02 dlen 12
    L2CAP(s): Connect req: psm 3 scid 0x0040
> HCI Event: Command Status (0x0f) plen 4
    Change Connection Packet Type (0x01|0x000f) status 0x0c ncmd 1
    Error: Command Disallowed
< ACL data: handle 7 flags 0x02 dlen 16
    L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0040 result 0 status 0
      Connection successful
> HCI Event: Max Slots Change (0x1b) plen 3
  0000: 07 00 05                                          ...
> ACL data: handle 7 flags 0x02 dlen 16
    L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
      MTU 1024
< ACL data: handle 7 flags 0x02 dlen 14
    L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
      Success
< ACL data: handle 7 flags 0x02 dlen 16
    L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
      MTU 1024
> HCI Event: Number of Completed Packets (0x13) plen 5
    handle 7
> ACL data: handle 7 flags 0x02 dlen 14
    L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
      Success
> HCI Event: Number of Completed Packets (0x13) plen 5
    handle 7
> ACL data: handle 7 flags 0x02 dlen 8
    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): SABM: cr 1 dlci 0 pf 1 ilen 0 fcs 0x1c
< ACL data: handle 7 flags 0x02 dlen 8
    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): UA: cr 1 dlci 0 pf 1 ilen 0 fcs 0xd7
> ACL data: handle 7 flags 0x02 dlen 18
    L2CAP(d): cid 0x0040 len 14 [psm 3]
      RFCOMM(s): PN CMD: cr 1 dlci 0 pf 0 ilen 10 fcs 0x70 mcc_len 8
      dlci 10 frame_type 0 credit_flow 15 pri 7 ack_timer 0
      frame_size 1019 max_retrans 0 credits 7
< ACL data: handle 7 flags 0x02 dlen 18
    L2CAP(d): cid 0x0040 len 14 [psm 3]
      RFCOMM(s): PN RSP: cr 0 dlci 0 pf 0 ilen 10 fcs 0xaa mcc_len 8
      dlci 10 frame_type 0 credit_flow 14 pri 7 ack_timer 0
      frame_size 1019 max_retrans 0 credits 7
> ACL data: handle 7 flags 0x02 dlen 8
    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): SABM: cr 1 dlci 10 pf 1 ilen 0 fcs 0x8c
< ACL data: handle 7 flags 0x02 dlen 8
    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): UA: cr 1 dlci 10 pf 1 ilen 0 fcs 0x47
< ACL data: handle 7 flags 0x02 dlen 12
    L2CAP(d): cid 0x0040 len 8 [psm 3]
      RFCOMM(s): MSC CMD: cr 0 dlci 0 pf 0 ilen 4 fcs 0xaa mcc_len 2
      dlci 10 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 1 b3 0 len 0
< ACL data: handle 7 flags 0x02 dlen 8
    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): DISC: cr 0 dlci 10 pf 1 ilen 0 fcs 0xc
> ACL data: handle 7 flags 0x02 dlen 12
    L2CAP(d): cid 0x0040 len 8 [psm 3]
      RFCOMM(s): MSC CMD: cr 1 dlci 0 pf 0 ilen 4 fcs 0x70 mcc_len 2
      dlci 10 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 1 b3 0 len 0
< ACL data: handle 7 flags 0x02 dlen 12
    L2CAP(d): cid 0x0040 len 8 [psm 3]
      RFCOMM(s): MSC RSP: cr 0 dlci 0 pf 0 ilen 4 fcs 0xaa mcc_len 2
      dlci 10 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 1 b3 0 len 0
> ACL data: handle 7 flags 0x02 dlen 12
    L2CAP(d): cid 0x0040 len 8 [psm 3]
      RFCOMM(s): MSC RSP: cr 1 dlci 0 pf 0 ilen 4 fcs 0x70 mcc_len 2
      dlci 10 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 1 b3 0 len 0
< ACL data: handle 7 flags 0x02 dlen 9
    L2CAP(d): cid 0x0040 len 5 [psm 3]
      RFCOMM(d): UIH: cr 0 dlci 10 pf 1 ilen 0 fcs 0x76 credits 33
> ACL data: handle 7 flags 0x02 dlen 8
    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): DISC: cr 1 dlci 10 pf 1 ilen 0 fcs 0x6d
< ACL data: handle 7 flags 0x02 dlen 8
    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): UA: cr 1 dlci 10 pf 1 ilen 0 fcs 0x47
> ACL data: handle 7 flags 0x02 dlen 8
    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): UA: cr 0 dlci 10 pf 1 ilen 0 fcs 0x26
< ACL data: handle 7 flags 0x02 dlen 8
    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): DM: cr 1 dlci 10 pf 1 ilen 0 fcs 0xa6
> ACL data: handle 7 flags 0x02 dlen 8
    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): DISC: cr 1 dlci 0 pf 1 ilen 0 fcs 0xfd
< ACL data: handle 7 flags 0x02 dlen 8
    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): UA: cr 1 dlci 0 pf 1 ilen 0 fcs 0xd7
> ACL data: handle 7 flags 0x02 dlen 12
    L2CAP(s): Disconn req: dcid 0x0040 scid 0x0040
> HCI Event: Number of Completed Packets (0x13) plen 5
    handle 7
< ACL data: handle 7 flags 0x02 dlen 12
    L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x0040
> HCI Event: Number of Completed Packets (0x13) plen 5
    handle 7
> HCI Event: Disconn Complete (0x05) plen 4
    status 0x00 handle 7 reason 0x13
    Reason: Remote User Terminated Connection

Re: [Bluez-users] error on connect

[Marcel Holtmann]

Hi Marco,

> >>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...

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

> >>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.
> 
> 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.

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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] error on connect

[Marco Trudel]

[-- Attachment #1: Type: text/plain, Size: 1836 bytes --]

Marcel Holtmann wrote:
> Hi Marco,
> 
> 
>>>>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...
> 
> 
> 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.

>>>>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.
>>
>>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.

> 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

[-- Attachment #2: acer --]
[-- Type: text/plain, Size: 4114 bytes --]

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

[-- Attachment #3: ednet --]
[-- Type: text/plain, Size: 4169 bytes --]

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

[-- Attachment #4: gallerie-connect.cpp --]
[-- Type: text/plain, Size: 1058 bytes --]

// 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);
}

[-- Attachment #5: arm-listen.cpp --]
[-- Type: text/plain, Size: 1035 bytes --]

// 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;
}

Re: [Bluez-users] error on connect

[Marco Trudel]

Hello Marcel

have you already had luck regarding this topic?


regards
Marco


Marco Trudel wrote:
> Marcel Holtmann wrote:
> 
>> Hi Marco,
>>
>>
>>>>> 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...
>>
>>
>>
>> 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.
> 
>>>>> 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.
>>>
>>>
>>> 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.
> 
>> 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;
> }


-------------------------------------------------------
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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] error on connect

[Marcel Holtmann]

Hi Marco,

> 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.

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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] error on connect

[Marco Trudel]

Hello Marcel

> 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#):

 > 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
 > HCI Event: Command Status (0x0f) plen 4
     Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1
#1#
#1#
 > 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
 > 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.

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

regards
Marco


-------------------------------------------------------
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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] error on connect

[Marcel Holtmann]

Hi Marco,

> > 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#):
> 
>  > 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
>  > HCI Event: Command Status (0x0f) plen 4
>      Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1
> #1#
> #1#
>  > 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
>  > 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).

do you have a dump where this actually happens?

> 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.

> 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.

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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] error on connect

[Marco Trudel]

Marcel Holtmann wrote:
> Hi Marco,
> 
> 
>>>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#):
>>
>> > 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
>> > HCI Event: Command Status (0x0f) plen 4
>>     Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1
>>#1#
>>#1#
>> > 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
>> > 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).
> 
> 
> 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.

>>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...

>>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?


regards
Marco


-------------------------------------------------------
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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] error on connect

[Marcel Holtmann]

Hi Marco,

> >>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.

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

> >>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...

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.

> >>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?

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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] error on connect

[Marco Trudel]

Marcel Holtmann wrote:
> Hi Marco,
> 
> 
>>>>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.
> 
> 
> I checked the thread and I found the listening one. The handles are
> matching and now I fully understand whats happening.

ok

>>>>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...
> 
> 
> 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.

>>>>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.

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


> Does this happen with both Broadcom dongles you have?

yes. this happens with both broadcom dongles.


 > 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...

regards
Marco


-------------------------------------------------------
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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] error on connect

[Marcel Holtmann]

Hi Marco,

> >>>>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...
> > 
> > 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.

> >>>>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.
> 
> 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.

>  > 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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] error on connect

[Marco Trudel]

Hello Marcel

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.


regards
Marco


Marcel Holtmann wrote:
> Hi Marco,
> 
> 
>>>>>>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...
>>>
>>>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.



>>>>>>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.
>>
>>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.
> 
> 
>> > 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
> Bluez-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-users
> 
> 



-------------------------------------------------------
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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] error on connect

[Marcel Holtmann]

Hi Marco,

> 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.

> - 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.

> - 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.

> - 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.

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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] error on connect

[Marco Trudel]

Marcel Holtmann wrote:
> Hi Marco,
> 
> 
>>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.

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


>>- 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.
> 
> 
>>- 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.
> 
> 
>>- 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...


regards
Marco


-------------------------------------------------------
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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] error on connect

[Marcel Holtmann]

Hi Marco,

> >>- 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...

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

> >>- 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.

> - (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.

> - 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.

> 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.

> - 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.

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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] error on connect

[Marco Trudel]

[-- Attachment #1: Type: text/plain, Size: 3659 bytes --]



Marcel Holtmann wrote:
> Hi Marco,
> 
> 
>>>>- 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...
> 
> 
> please do a "hcidump -X -V" for the sender side, too. I like to look how
> the Broadcom responds here.

here they are.
I attached the listening ones again because I updated to hcidump1.20.
The listening dongle is the acer, the sending one the ednet.

>>>>- 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.

I just found out that the listening dongle doesn't freeze. The connecting 
dongle runs into a timeout and disconnects propertly. After that 
connections are possible again.

>>- (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.

I'm sorry, I made a thinking mistake. This shure is not a problem...


>>- 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.

Actually I think this isn't needed because everything's fine again after 
the timeout.

>>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.
> 
> 
>>- 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...


regards
Marco

[-- Attachment #2: hcidump1.20_connecting_failure.txt --]
[-- Type: text/plain, Size: 850 bytes --]

< HCI Command: Create Connection (0x01|0x0005) plen 13
    bdaddr 00:02:72:C3:26:F5 ptype 0xcc18 rswitch 0x01 clkoffset 0x0000
    Packet type: DM1 DM3 DM5 DH1 DH3 DH5
> HCI Event: Command Status (0x0f) plen 4
    Create Connection (0x01|0x0005) status 0x00 ncmd 1
> HCI Event: Connect Complete (0x03) plen 11
    status 0x00 handle 6 bdaddr 00:02:72:C3:26:F5 type ACL encrypt 0x00
< ACL data: handle 6 flags 0x02 dlen 12
    L2CAP(s): Connect req: psm 3 scid 0x0040
< HCI Command: Write Link Policy Settings (0x02|0x000d) plen 4
    handle 6 policy 0x0f
    Link policy: RSWITCH HOLD SNIFF PARK
> HCI Event: Command Complete (0x0e) plen 6
    Write Link Policy Settings (0x02|0x000d) ncmd 1
    status 0x00 handle 6
> HCI Event: Number of Completed Packets (0x13) plen 5
    handle 6
> HCI Event: Max Slots Change (0x1b) plen 3
    handle 6 slots 5

[-- Attachment #3: hcidump1.20_connecting_success.txt --]
[-- Type: text/plain, Size: 4920 bytes --]

< HCI Command: Create Connection (0x01|0x0005) plen 13
    bdaddr 00:02:72:C3:26:F5 ptype 0xcc18 rswitch 0x01 clkoffset 0x0000
    Packet type: DM1 DM3 DM5 DH1 DH3 DH5
> HCI Event: Command Status (0x0f) plen 4
    Create Connection (0x01|0x0005) status 0x00 ncmd 1
> HCI Event: Connect Complete (0x03) plen 11
    status 0x00 handle 6 bdaddr 00:02:72:C3:26:F5 type ACL encrypt 0x00
< ACL data: handle 6 flags 0x02 dlen 12
    L2CAP(s): Connect req: psm 3 scid 0x0040
< HCI Command: Write Link Policy Settings (0x02|0x000d) plen 4
    handle 6 policy 0x0f
    Link policy: RSWITCH HOLD SNIFF PARK
> HCI Event: Command Complete (0x0e) plen 6
    Write Link Policy Settings (0x02|0x000d) ncmd 1
    status 0x00 handle 6
> HCI Event: Number of Completed Packets (0x13) plen 5
    handle 6
> ACL data: handle 6 flags 0x02 dlen 16
    L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0040 result 0 status 0
      Connection successful
< ACL data: handle 6 flags 0x02 dlen 16
    L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
      MTU 1024
> HCI Event: Max Slots Change (0x1b) plen 3
    handle 6 slots 5
> ACL data: handle 6 flags 0x02 dlen 14
    L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
      Success
> ACL data: handle 6 flags 0x02 dlen 16
    L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
      MTU 1024
< ACL data: handle 6 flags 0x02 dlen 14
    L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
      Success
< ACL data: handle 6 flags 0x02 dlen 8
    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): SABM: cr 1 dlci 0 pf 1 ilen 0 fcs 0x1c
> ACL data: handle 6 flags 0x02 dlen 8
    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): UA: cr 1 dlci 0 pf 1 ilen 0 fcs 0xd7
< ACL data: handle 6 flags 0x02 dlen 18
    L2CAP(d): cid 0x0040 len 14 [psm 3]
      RFCOMM(s): PN CMD: cr 1 dlci 0 pf 0 ilen 10 fcs 0x70 mcc_len 8
      dlci 10 frame_type 0 credit_flow 15 pri 7 ack_timer 0
      frame_size 1019 max_retrans 0 credits 7
> ACL data: handle 6 flags 0x02 dlen 18
    L2CAP(d): cid 0x0040 len 14 [psm 3]
      RFCOMM(s): PN RSP: cr 0 dlci 0 pf 0 ilen 10 fcs 0xaa mcc_len 8
      dlci 10 frame_type 0 credit_flow 14 pri 7 ack_timer 0
      frame_size 1019 max_retrans 0 credits 7
< ACL data: handle 6 flags 0x02 dlen 8
    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): SABM: cr 1 dlci 10 pf 1 ilen 0 fcs 0x8c
> ACL data: handle 6 flags 0x02 dlen 8
    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): UA: cr 1 dlci 10 pf 1 ilen 0 fcs 0x47
< ACL data: handle 6 flags 0x02 dlen 12
    L2CAP(d): cid 0x0040 len 8 [psm 3]
      RFCOMM(s): MSC CMD: cr 1 dlci 0 pf 0 ilen 4 fcs 0x70 mcc_len 2
      dlci 10 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 1 b3 0 len 0
< ACL data: handle 6 flags 0x02 dlen 8
    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): DISC: cr 1 dlci 10 pf 1 ilen 0 fcs 0x6d
> ACL data: handle 6 flags 0x02 dlen 12
    L2CAP(d): cid 0x0040 len 8 [psm 3]
      RFCOMM(s): MSC CMD: cr 0 dlci 0 pf 0 ilen 4 fcs 0xaa mcc_len 2
      dlci 10 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 1 b3 0 len 0
< ACL data: handle 6 flags 0x02 dlen 12
    L2CAP(d): cid 0x0040 len 8 [psm 3]
      RFCOMM(s): MSC RSP: cr 1 dlci 0 pf 0 ilen 4 fcs 0x70 mcc_len 2
      dlci 10 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 1 b3 0 len 0
> ACL data: handle 6 flags 0x02 dlen 8
    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): DISC: cr 0 dlci 10 pf 1 ilen 0 fcs 0xc
< ACL data: handle 6 flags 0x02 dlen 8
    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): UA: cr 0 dlci 10 pf 1 ilen 0 fcs 0x26
< ACL data: handle 6 flags 0x02 dlen 8
    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): DISC: cr 1 dlci 0 pf 1 ilen 0 fcs 0xfd
> ACL data: handle 6 flags 0x02 dlen 12
    L2CAP(d): cid 0x0040 len 8 [psm 3]
      RFCOMM(s): MSC RSP: cr 0 dlci 0 pf 0 ilen 4 fcs 0xaa mcc_len 2
      dlci 10 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 1 b3 0 len 0
> HCI Event: Number of Completed Packets (0x13) plen 5
    handle 6
< ACL data: handle 6 flags 0x02 dlen 12
    L2CAP(s): Disconn req: dcid 0x0040 scid 0x0040
> ACL data: handle 6 flags 0x02 dlen 8
    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): UA: cr 1 dlci 10 pf 1 ilen 0 fcs 0x47
> ACL data: handle 6 flags 0x02 dlen 8
    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): DM: cr 1 dlci 10 pf 1 ilen 0 fcs 0xa6
> ACL data: handle 6 flags 0x02 dlen 8
    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): UA: cr 1 dlci 0 pf 1 ilen 0 fcs 0xd7
> ACL data: handle 6 flags 0x02 dlen 12
    L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x0040
> HCI Event: Number of Completed Packets (0x13) plen 5
    handle 6
< HCI Command: Disconnect (0x01|0x0006) plen 3
    handle 6 reason 0x13
    Reason: Remote User Terminated Connection
> HCI Event: Command Status (0x0f) plen 4
    Disconnect (0x01|0x0006) status 0x00 ncmd 1
> HCI Event: Disconn Complete (0x05) plen 4
    status 0x00 handle 6 reason 0x16
    Reason: Connection Terminated by Local Host

[-- Attachment #4: hcidump1.20_listening_failure.txt --]
[-- Type: text/plain, Size: 1108 bytes --]

> HCI Event: Connect Request (0x04) plen 10
    bdaddr 00:02:72:C3:F1:FE class 0x3e0100 type ACL
< HCI Command: Accept Connection Request (0x01|0x0009) plen 7
    bdaddr 00:02:72:C3:F1:FE role 0x01
    Role: Slave
> HCI Event: Command Status (0x0f) plen 4
    Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1
> ACL data: handle 7 flags 0x02 dlen 12
    L2CAP(s): Connect req: psm 3 scid 0x0040
> HCI Event: Connect Complete (0x03) plen 11
    status 0x00 handle 7 bdaddr 00:02:72:C3:F1:FE type ACL encrypt 0x00
< HCI Command: Write Link Policy Settings (0x02|0x000d) plen 4
    handle 7 policy 0x0f
    Link policy: RSWITCH HOLD SNIFF PARK
> 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
> HCI Event: Command Status (0x0f) plen 4
    Change Connection Packet Type (0x01|0x000f) status 0x0c ncmd 1
    Error: Command Disallowed
> HCI Event: Max Slots Change (0x1b) plen 3
    handle 7 slots 5

[-- Attachment #5: hcidump1.20_listening_success.txt --]
[-- Type: text/plain, Size: 4968 bytes --]

> HCI Event: Connect Request (0x04) plen 10
    bdaddr 00:02:72:C3:F1:FE class 0x3e0100 type ACL
< HCI Command: Accept Connection Request (0x01|0x0009) plen 7
    bdaddr 00:02:72:C3:F1:FE role 0x01
    Role: Slave
> HCI Event: Command Status (0x0f) plen 4
    Accept Connection Request (0x01|0x0009) status 0x00 ncmd 1
> HCI Event: Connect Complete (0x03) plen 11
    status 0x00 handle 7 bdaddr 00:02:72:C3:F1:FE type ACL encrypt 0x00
< HCI Command: Write Link Policy Settings (0x02|0x000d) plen 4
    handle 7 policy 0x0f
    Link policy: RSWITCH HOLD SNIFF PARK
> 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
> HCI Event: Command Status (0x0f) plen 4
    Change Connection Packet Type (0x01|0x000f) status 0x0c ncmd 1
    Error: Command Disallowed
> ACL data: handle 7 flags 0x02 dlen 12
    L2CAP(s): Connect req: psm 3 scid 0x0040
< ACL data: handle 7 flags 0x02 dlen 16
    L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0040 result 0 status 0
      Connection successful
> HCI Event: Max Slots Change (0x1b) plen 3
    handle 7 slots 5
> ACL data: handle 7 flags 0x02 dlen 16
    L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
      MTU 1024
< ACL data: handle 7 flags 0x02 dlen 14
    L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
      Success
< ACL data: handle 7 flags 0x02 dlen 16
    L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
      MTU 1024
> ACL data: handle 7 flags 0x02 dlen 14
    L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 0
      Success
> ACL data: handle 7 flags 0x02 dlen 8
    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): SABM: cr 1 dlci 0 pf 1 ilen 0 fcs 0x1c
< ACL data: handle 7 flags 0x02 dlen 8
    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): UA: cr 1 dlci 0 pf 1 ilen 0 fcs 0xd7
> ACL data: handle 7 flags 0x02 dlen 18
    L2CAP(d): cid 0x0040 len 14 [psm 3]
      RFCOMM(s): PN CMD: cr 1 dlci 0 pf 0 ilen 10 fcs 0x70 mcc_len 8
      dlci 10 frame_type 0 credit_flow 15 pri 7 ack_timer 0
      frame_size 1019 max_retrans 0 credits 7
< ACL data: handle 7 flags 0x02 dlen 18
    L2CAP(d): cid 0x0040 len 14 [psm 3]
      RFCOMM(s): PN RSP: cr 0 dlci 0 pf 0 ilen 10 fcs 0xaa mcc_len 8
      dlci 10 frame_type 0 credit_flow 14 pri 7 ack_timer 0
      frame_size 1019 max_retrans 0 credits 7
> ACL data: handle 7 flags 0x02 dlen 8
    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): SABM: cr 1 dlci 10 pf 1 ilen 0 fcs 0x8c
< ACL data: handle 7 flags 0x02 dlen 8
    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): UA: cr 1 dlci 10 pf 1 ilen 0 fcs 0x47
< ACL data: handle 7 flags 0x02 dlen 12
    L2CAP(d): cid 0x0040 len 8 [psm 3]
      RFCOMM(s): MSC CMD: cr 0 dlci 0 pf 0 ilen 4 fcs 0xaa mcc_len 2
      dlci 10 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 1 b3 0 len 0
< ACL data: handle 7 flags 0x02 dlen 8
    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): DISC: cr 0 dlci 10 pf 1 ilen 0 fcs 0xc
> ACL data: handle 7 flags 0x02 dlen 12
    L2CAP(d): cid 0x0040 len 8 [psm 3]
      RFCOMM(s): MSC CMD: cr 1 dlci 0 pf 0 ilen 4 fcs 0x70 mcc_len 2
      dlci 10 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 1 b3 0 len 0
< ACL data: handle 7 flags 0x02 dlen 12
    L2CAP(d): cid 0x0040 len 8 [psm 3]
      RFCOMM(s): MSC RSP: cr 0 dlci 0 pf 0 ilen 4 fcs 0xaa mcc_len 2
      dlci 10 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 1 b3 0 len 0
> HCI Event: Number of Completed Packets (0x13) plen 5
    handle 7
> ACL data: handle 7 flags 0x02 dlen 8
    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): DISC: cr 1 dlci 10 pf 1 ilen 0 fcs 0x6d
< ACL data: handle 7 flags 0x02 dlen 8
    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): UA: cr 1 dlci 10 pf 1 ilen 0 fcs 0x47
> ACL data: handle 7 flags 0x02 dlen 12
    L2CAP(d): cid 0x0040 len 8 [psm 3]
      RFCOMM(s): MSC RSP: cr 1 dlci 0 pf 0 ilen 4 fcs 0x70 mcc_len 2
      dlci 10 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 1 b3 0 len 0
> ACL data: handle 7 flags 0x02 dlen 8
    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): UA: cr 0 dlci 10 pf 1 ilen 0 fcs 0x26
< ACL data: handle 7 flags 0x02 dlen 8
    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): DM: cr 1 dlci 10 pf 1 ilen 0 fcs 0xa6
> ACL data: handle 7 flags 0x02 dlen 8
    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): DISC: cr 1 dlci 0 pf 1 ilen 0 fcs 0xfd
< ACL data: handle 7 flags 0x02 dlen 8
    L2CAP(d): cid 0x0040 len 4 [psm 3]
      RFCOMM(s): UA: cr 1 dlci 0 pf 1 ilen 0 fcs 0xd7
> ACL data: handle 7 flags 0x02 dlen 12
    L2CAP(s): Disconn req: dcid 0x0040 scid 0x0040
< ACL data: handle 7 flags 0x02 dlen 12
    L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x0040
> HCI Event: Number of Completed Packets (0x13) plen 5
    handle 7
> HCI Event: Disconn Complete (0x05) plen 4
    status 0x00 handle 7 reason 0x13
    Reason: Remote User Terminated Connection

Re: [Bluez-users] error on connect

[Marcel Holtmann]

Hi Marco,

> >>- 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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] error on connect

[Marco Trudel]

I'll do it on friday or saturday.

regards
Marco


Marcel Holtmann wrote:
> Hi Marco,
> 
> 
>>>>- 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
> Bluez-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-users
> 
> 


-------------------------------------------------------
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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] error on connect

[Marco Trudel]

Hello Marcel

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...

Can you send it to me?


regards
Marco


Marcel Holtmann wrote:
> Hi Marco,
> 
> 
>>>>- 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
> Bluez-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-users
> 
> 


-------------------------------------------------------
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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users

Re: [Bluez-users] error on connect

[Marcel Holtmann]

Hi Marco,

> 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...

I think that I have a CD with it somewhere, but actually I have no idea
where to search. Most times I simply throw the CD away when I get myself
another dongle. Sorry.

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
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users