3 Replies Latest reply on Jun 24, 2015 4:58 PM by PabloM_Intel

    BlueZ: Reliability and Error Checking of RFCOMM packets


      Hello Everyone,


      So I'm testing the different ways in which data can be wireless exchanged between the Edisons. Right now, I am transferring files over an RFCOMM connection that is pragmatically established.



      - The two devices are paired (as described in the Intel Edison Bluetooth Guide)

      - A 1 MByte is being read by client and sent to server in chunks of 1024 bytes. Client and server code are modified versions of the client/server code on this link: http://people.csail.mit.edu/albert/bluez-intro/x502.html.

      - The client connects and sends the file then exits, server continues running

      - After two seconds, a new client instance (same machine) transmits the same file again

      - After each transmission, the server (which has a copy of the file) runs a cmp command and records number of different bytes.



      - When the client and the server are both Edisons, out of the 100 transmissions, there is an average of five transmissions which contain a corrupted byte. The number of bytes is not changed, just one is replaced by another.

      - When the client and the server are both laptops (with Bluez running same code), there is no error

      - When the client is a laptop and server is an Edison, there is average of three transmissions which contain a corrupted byte.

      - When the client is an Edison and the server is a laptop there is no error.



      According to my understanding of the Bluez stack, RFCOMM is supposed to be reliable because it requests a reliable L2CAP channel. The Baseband does error checking and drops corrupted packets, then L2CAP does not ACK those packets and they're retransmitted until the end of the flash time-out set by the L2CAP implementation. I tried setting the flash time-out to infinity, but nothing changed. So here are my current guesses and I would really appreciate any more thoughts on the matter:
      - Is "Error check" done by the baseband and L2CAP on the entire packets, including payload, or just the headers/size/etc..?
      - Is the problem with the L2CAP implementation with Bluez over Yocto, which can be fixed/recovered, or is it in the baseband layer? (It does not drop corrupted packets). quest


      However, my main question is:

      has anyone else faced the same issue? Is there a problem with Bluez's implementation of RFCOMM on Yocto or am I just doing something wrong?


      Also: I've been trying to sniff the bluetooth packets to debug this problem, but I'm only seeing the HCI_EVT packets. If anyone has any idea as to why I'm not seeing the RFCOMM packets that will also be very helpful.


      Thanks in advance,

      Aliaa Essameldin