Re: [Bluez-devel] modify RFCOMM_DISC_TIMEOUT

["Carlos AM" <Carlos@naxus.biz>]

[-- Attachment #1: Type: text/plain, Size: 2203 bytes --]

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" <marcel@holtmann.org>
To: "Carlos AM" <Carlos@naxus.biz>
Cc: "BlueZ Mailing List" <bluez-devel@lists.sourceforge.net>
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

[-- Attachment #2: Type: text/html, Size: 3479 bytes --]