[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bluetooth-dev] rfcomm.c bug?



There seems to be a bug in rfcomm.c:
After figuring out if a UIH packet is long or short 
and then appropriately determining the length, the code
later ignores the information and grabs the length
using the short_frame structure (even though the code 
nicely uses the uih_data_start pointer).  This causes my
little-endian system to sometimes drop a byte (but my 
big-endian system seems ok).

See the patch below:

Index: rfcomm.c
===================================================================
RCS file: /cvsroot/openbt/linux/drivers/char/bluetooth/rfcomm.c,v
retrieving revision 1.123
diff -a -u -d -r1.123 rfcomm.c
--- rfcomm.c    2001/10/10 14:58:18     1.123
+++ rfcomm.c    2001/10/12 02:11:36
@@ -1268,7 +1268,7 @@
 #endif
                        D_REC(FNC"Local_credits:%d\n",
rfcomm->dlci[tmp_dlci].local_credits); 
                        uih_data_start++;
-                       if (short_pkt->h.length.len == 0) {
+                       if (uih_len == 0) {
                                break;
                        }
-
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com