RFCOMM receiving data with 1 L2CAP packet missing

1
votes

I written android app using bluetooth's RFCOMM. I am sending 1 MB data to android app via same RFCOMM UUID.

I noticed that 1 L2CAP packet data has missed in my app. See below information for more details.

My android mobile bluetooth supporting maximum RFCOMM payload is 990 bytes, So the remote device is sending each L2CAP packet with payload of 990 bytes. Whenever I am sending data of 1K from remote device it has been divided into 2 L2CAP packets of 990 and 34 bytes each.

After receiving data in my android app, I checked each 1K data, there I noticed 1 L2CAP packet i.e., 990 bytes has been skipped in android.

I checked all data sending from remote device using analyzers. It is perfectly sending 1 MB data without any fail.

But In my android app only, I am not able to receive. This is not problem with my app, because I used Bluetooth Chat example code here.

I tested this several times, the 990 bytes of data lost is not at same index in 1MB data each time I run the test.

I tested this with 3 mobiles of android 2.2, 2.3.3 and 2.3.6 versions each mobile facinf same problem

But I am not getting any exceptions while receiving data from RFCOMM socket's InputStream also.

If anybody faced and solved my problem please help me.

2
androidbluetoothrfcomm
To clarify, you're saying that in the received data stream, you have received consecutive bytes of data that, in the sending stream, had 990 bytes of data between them? In other words, you sent "<stuff>A<990 bytes>B<stuff>" and received "<stuff>AB<stuff>"? – David Schwartz
@DavidSchwartz exactly I am getting like that only. That for 1 time in 1MB data – Yugandhar Babu
I can think of a lot of possible causes, and pretty much all of them are bugs in your code. Try this experiment -- log the number of bytes received in each of your calls to the low-level receiving function. See if they sum to the number of bytes you sent. If so, and 990 bytes are still missing, that proves your code lost them. – David Schwartz
I did same thing and also some more experiments – Yugandhar Babu
When you did that, was the sum of the number of bytes received in all the calls you made into the receiving function? Was it the number of bytes sent? Or was it 990 less? – David Schwartz

2 Answers

0
votes

Can you check with the HCIDump tool on the ACL data transmitted/recieved between two devices. If the data is matching with the HCI ACL Data packets /sent and recieved, then L2CAP in the recieving end is dropping some packet.

Take a look at this link and see if mtu might cause this issue.

http://people.csail.mit.edu/albert/bluez-intro/x559.html

Thanks Manivannan

0
votes

You may want to flush the stream after having sent all the data , It is possible that RFCOMM could buffer some data wiating for its PDU to fill up. See this - OutputStream::flush()