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