Hi Marcel I think that i've finally found the origin of the errors. The kernel log shows: (...) <4> Unknown HCI packet type 01 (...) This message is dropped every five minutes (aproximately) and the packet type is not always 01. It seems that the serial communication (UART) with the bluetooth module (EYMF2CAMM from TAIYO YUDEN) isn't very confiable. Do you agree? I used to attach the hci device using this command: /bluez/bluezmain hciattach -n /dev/tts/2 any 115200 and always works. Then I configured the kernel with BCSP support and tried to attach the device using: /bluez/bluezmain hciattach -n /dev/tts/2 bcsp 115200 /bluez/bluezmain hciattach -n /dev/tts/2 swave 115200 but none of them work at all. The error message is [hcid] Can't init device hci0. Connection timed out(110) What do you think about it? Thanks for your interest. Best Regards CarlosAM ----- Original Message ----- From: "Marcel Holtmann" To: "Carlos AM" Cc: "BlueZ Mailing List" Sent: Friday, July 23, 2004 11:39 AM Subject: Re: [Bluez-devel] modify RFCOMM_DISC_TIMEOU > Hi Carlos, > > > I run a rfcomm server built on top of bluez using sockets, the client runs a > > different bluetooth protocol implementation that is very buggy and sometimes > > stops the rfcomm comunication without sending a DISC. So the rfcomm server > > waits for 20 seconds (RFCOMM_DISC_TIMEOUT) and then closes the connections > > and become available again. The sending loop of the server is: > > > > //using sockets > > //send until write returns -1 > > while(n>=0) > > { > > n=write(client,s,strlen(s)); > > sleep(1); > > } > > //go to listen again > > > > > > If the client simply stops the communication, not disconnect, the server > > must be available as soon as possible. 20 seconds it's too long for our > > application. > > what you want is an idle timeout detection. The RFCOMM_DISC_TIMEOUT is > not meant for doing this. Show us the output of "hcidump -x -t" while > this happens. > > Regards > > Marcel > > Carlos AM Naxus Conectividad Móvil