All of lore.kernel.org
 help / color / mirror / Atom feed
From: Manuel Naranjo <manuel@aircable.net>
To: BlueZ development <bluez-devel@lists.sourceforge.net>
Subject: Re: [Bluez-devel] Rfcomm is not buffering received data?
Date: Thu, 22 Nov 2007 11:39:51 -0300	[thread overview]
Message-ID: <474594B7.2070005@aircable.net> (raw)
In-Reply-To: <474181FA.2010906@aircable.net>

Hello guys,

I've been able to fix this, by switching the tty node to raw mode. But
still something is not working well, select returns 0 even though
there's data in the buffer.

Here's the fix if anyone wants to know:
    int fd = fileno(data->fd);
   
    struct termios tio;
   
    tcgetattr(fd, &tio);

    tcflush(fd, TCIOFLUSH);
   
    tio.c_lflag &= ~(ECHO | ICANON | IEXTEN | ISIG);
    tio.c_iflag &= ~(BRKINT | ICRNL | ISTRIP | IXON);
    tio.c_cflag &= ~(CSIZE | PARENB);
    tio.c_cflag |= CS8;
    tio.c_oflag &= ~(OPOST);

    cfmakeraw(&tio);
   
    tio.c_cc[VMIN] = 0;
    tio.c_cc[VTIME] = 0;

I think we should add a comment about this in the wiki, what do you think?

Cheers,
Manuel
> Hello everyone,
>
> I'm working on a dbus version of obexftp [1]. My goal was to remove all
> the calls to hci-lib and replace those for the dbus equivalent. It
> wasn't a though task, but now I'm facing a huge problem.
>
> It took me almost 5 hours to detect the problem, firstly I thought that
> the phone wasn't replying the request, but then after a brilliant idea I
> probed that the phone was replying because hcidump was showing that. My
> first conclusion was: "someone else is reading /dev/rfcomm# and erasing
> the buffer before I can read it"
>
> Then I checked with fuser which PIDs where using that file. For my
> surprise there where two PIDs, one was my program the other was the
> serial port service from BlueZ. I enabled gdb and did step debugging
> until I faced the first write function, and then I kill the serial port
> service PID. But I wasn't lucky at all, someone was still reading the
> rfcomm.
>
> Well after a couple of hours of thinking I cammed to the conclusion that
> some how the rfcomm device is not buffering the data it receives. I'm
> sure that the rfcomm buffer is not been overflowed, as the first reply
> from the phone is not more than 30 bytes long. I'm gonna start going
> through the rfcomm kernel sources, but if someone knows what's going on
> please let me know.
>
> I'm working on an Open Source Proximity Marketing Solution, and this is
> the last thing I need to finish before doing the official announcement
> (Marcel do you mind if I send a mail to the list saying this?)
>
> Thanks,
> Manuel
>
> [1] http://code.google.com/p/proximitymarketing/
>
>
>
>   


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

  reply	other threads:[~2007-11-22 14:39 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-19 12:30 [Bluez-devel] Rfcomm is not buffering received data? Manuel Naranjo
2007-11-22 14:39 ` Manuel Naranjo [this message]
2007-11-26 12:45   ` Manuel Naranjo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=474594B7.2070005@aircable.net \
    --to=manuel@aircable.net \
    --cc=bluez-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.