From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <004501c4749c$9958f280$5000005a@naxus> From: "Carlos AM" To: "lista bluez" Subject: Re: [Bluez-devel] modify RFCOMM_DISC_TIMEOUT MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0032_01C474AC.DED6EA00" Sender: bluez-devel-admin@lists.sourceforge.net Errors-To: bluez-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Date: Wed, 28 Jul 2004 14:12:09 +0200 This is a multi-part message in MIME format. ------=_NextPart_000_0032_01C474AC.DED6EA00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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>=3D0) > > { > > n=3Dwrite(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=F3vil ------=_NextPart_000_0032_01C474AC.DED6EA00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi=20 Marcel

I think that i've finally found the origin of the errors. = The=20 kernel log
shows:

(...)
<4> Unknown HCI packet type=20 01
(...)

This message is dropped every five minutes = (aproximately)=20 and the packet
type is not always 01. It seems that the serial = communication=20 (UART) with
the bluetooth module (EYMF2CAMM from TAIYO YUDEN) isn't = very=20 confiable. Do
you agree?

I used to attach the hci device using = this=20 command:
/bluez/bluezmain hciattach -n /dev/tts/2 any 115200
and = always=20 works.

Then I configured the kernel with BCSP support and tried = to attach=20 the
device using:
/bluez/bluezmain hciattach -n /dev/tts/2 bcsp=20 115200
/bluez/bluezmain hciattach -n /dev/tts/2 swave = 115200

but none=20 of them work at all. The error message is [hcid] Can't init = device
hci0.=20 Connection timed out(110)

What do you think about = it?

Thanks=20 for your interest.
Best=20 Regards
CarlosAM

----- Original = Message=20 -----
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:=20 [Bluez-devel] modify RFCOMM_DISC_TIMEOU

> Hi = Carlos,
>
>=20 > I run a rfcomm server built on top of bluez using sockets, the=20 client
runs a
> > different bluetooth protocol = implementation that=20 is very buggy and
sometimes
> > stops the rfcomm = comunication=20 without sending a DISC. So the rfcomm
server
> > waits for = 20=20 seconds (RFCOMM_DISC_TIMEOUT) and then closes the
connections
> = >=20 and become available again. The sending loop of the server is:
>=20 >
> > //using sockets
> > //send until write = returns=20 -1
> > while(n>=3D0)
> > {
>=20 > n=3Dwrite(client,s,strlen(s));
>=20 > sleep(1);
> > }
> > = //go to=20 listen again
> >
> >
> > If the client simply = stops=20 the communication, not disconnect, the server
> > must be = available as=20 soon as possible. 20 seconds it's too long for our
> >=20 application.
>
> what you want is an idle timeout detection. = The=20 RFCOMM_DISC_TIMEOUT is
> not meant for doing this. Show us the = output of=20 "hcidump -x -t" while
> this happens.
>
>=20 Regards
>
> Marcel
>
>

Carlos AM
Naxus Conectividad=20 M=F3vil

------=_NextPart_000_0032_01C474AC.DED6EA00-- ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ Bluez-devel mailing list Bluez-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bluez-devel