[Bluez-devel] Rfcomm is not buffering received data?

[Bluez-devel] Rfcomm is not buffering received data?

[Manuel Naranjo]

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

Re: [Bluez-devel] Rfcomm is not buffering received data?

[Manuel Naranjo]

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

Re: [Bluez-devel] Rfcomm is not buffering received data?

[Manuel Naranjo]

Hello everyone,

I think this mail might got lost between all the spam we are getting
those days.

I'm starting to think that some how select() is not working for tty
devices. I had switched the tty device to raw mode (by using termios
calls). And still even though there's data on the tty buffer select
keeps returning 0. So far I'm using select as an sleep function, but
that's not it's purpose, not at all. Maybe I keep missing something?

BTW how's the state for server side rfcomm services? I mean you register
a service at a certain port via dbus, and you get locked (or you get a
function callback I don't know) when a connection was established and
you get the tty device name.

Thanks,
Manuel

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


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