Rfcomm is not buffering received data?

Bluez-devel Manuel Naranjo 1 participant 3 messages Nov 19, 2007 – Nov 26, 2007 Bluetooth drivers

Share & tools

Manuel Naranjo

author

2007-11-19 12:30 UTC #0 lore raw

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 [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Manuel Naranjo

author

2007-11-22 14:39 UTC #1 lore raw

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

Quoted 26 lines

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.

Quoted 12 lines

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/

Manuel Naranjo

author

2007-11-26 12:45 UTC #2 lore raw

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

Quoted 26 lines

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;

Quoted 5 lines

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