Re: [Bluez-users] error on connect

[Marco Trudel <mtrudel@gmx.ch>]

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