Re: [Bluez-users] error on connect

[Marco Trudel <mtrudel@gmx.ch>]

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