public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
* [Bluez-devel] modify RFCOMM_DISC_TIMEOUT
@ 2004-07-22 14:19 Carlos AM
  2004-07-22 17:32 ` Marcel Holtmann
  0 siblings, 1 reply; 5+ messages in thread
From: Carlos AM @ 2004-07-22 14:19 UTC (permalink / raw)
  To: lista bluez

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

Hi

I am developing a GPS unit that communicates via RFCOMM and I noticed that the timeout of the RFCOMM disconnection is 20 seconds.
¿Does exists a way to change this timeout from a rfcomm server program that uses sockets?
It seems that changing this #define in the rfcomm.h is not enough

Regards
Carlos AM
Naxus Conectividad Móvil

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

^ permalink raw reply	[flat|nested] 5+ messages in thread
* Re: [Bluez-devel] modify RFCOMM_DISC_TIMEOUT
@ 2004-07-28 12:12 Carlos AM
  2004-07-28 12:22 ` Marcel Holtmann
  0 siblings, 1 reply; 5+ messages in thread
From: Carlos AM @ 2004-07-28 12:12 UTC (permalink / raw)
  To: lista bluez

[-- 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 --]

^ permalink raw reply	[flat|nested] 5+ messages in thread
end of thread, other threads:[~2004-07-28 12:22 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-07-22 14:19 [Bluez-devel] modify RFCOMM_DISC_TIMEOUT Carlos AM
2004-07-22 17:32 ` Marcel Holtmann
     [not found]   ` <003b01c47095$488aa3e0$5000005a@naxus>
2004-07-23  9:39     ` Marcel Holtmann
  -- strict thread matches above, loose matches on Subject: below --
2004-07-28 12:12 Carlos AM
2004-07-28 12:22 ` Marcel Holtmann

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox