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