Hi, Sorry for posting this question into the list. However, I am thinking this question might be worth confirming with developers. This happens when testing IUT as RFCOMM responder for the Bluetooth SIG test plan RFCOMM: TP/RFC/BV-23-C. From the angel of protocol test result, the current implementation fails because the IUT ignores or responds with an incorrect response. In detail, there'll be two cases where the software will have a problem. 1. For command == RFCOMM_NSC and C/R bit = 1 (command), the function rfcomm_recv_mcc() will simply ignore and send no response. It seems the test plan requires a response a NSC response. 2. For command is not one of RFCOMM_NSC, RFCOMM_TEST, RFCOMM_FCON, RFCOMM_FCOFF, RFCOMM_MSC, RFCOMM_RLS, RFCOMM_RPN and RFCOMM_PN, the function rfcomm_recv_mcc() will not ignore but call rfcomm_send_nsc(s, cr, type) to respond with a NSC. However, when calling rfcomm_send_nsc, parameter cr is set to 0x02 which is extracted by __test_cr(). Then rfcomm_send_nsc() will use macro __mcc_type to re-assemble the byte by shifting it by 1 bit. #define __test_cr(b) ((b & 0x02)) // line 81 #define __mcc_type(cr, type) (((type << 2) | (cr << 1) | 0x01)) // line 94 This causes the C/R flag (which is already at right bit from __test_cr()) to be shifted by one more bit from bit 2 to bit 3. 3. For both case 1 and 2, another common problem is when rfcomm_send_nsc() re-assembles the response, at line 847, the first call to __mcc_type may be called with cr=0 because it's trying to give a response. Anyway, all of them are just my opinions based on analysis on current version(both bluetooth.git and bluetooth-next.git) and one or more could be wrong. So I am wondering before I post a patch, could anyone confirm they're valid problems? Thanks, Tim -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
