Message-ID: <42652B35.7060803@gmx.ch>
From: Marco Trudel <mtrudel@gmx.ch>
MIME-Version: 1.0
To: bluez-users@lists.sourceforge.net
Subject: Re: [Bluez-users] error on connect
References: <425FFF54.6000701@gmx.ch> <1113607202.16433.42.camel@pegasus>	 <42616275.1090103@gmx.ch> <1113682195.18450.0.camel@pegasus>	 <4261BCFB.8040204@gmx.ch> <1113702363.18450.26.camel@pegasus>	 <426237CF.5060604@gmx.ch>  <4263F8DF.1040400@gmx.ch>	 <1113849662.16233.118.camel@pegasus>  <42651A2E.2080601@gmx.ch>	 <1113923580.2469.7.camel@pegasus>  <426522C6.10700@gmx.ch> <1113925620.2469.26.camel@pegasus>
In-Reply-To: <1113925620.2469.26.camel@pegasus>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Sender: bluez-users-admin@lists.sourceforge.net
Errors-To: bluez-users-admin@lists.sourceforge.net
Reply-To: bluez-users@lists.sourceforge.net
Date: Tue, 19 Apr 2005 18:00:53 +0200

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