Hi Szymon, On Mon, Oct 13, 2014, Szymon Janc wrote: > rfcomm_send_nsc expects CR to be either 0 or 1 since it is later > passed to __mcc_type macro and shitfed. Unfortunatelly CR extracted > from received frame type was not sanitized and shifted value was passed > resulting in bogus response. > > Note: shifted value was also passed to other functions but was used > only in if satements so this bug appears only for NSC case. > > The CR bit in the value octet shall be set to the same value > as the CR bit in the type field octet of the not supported command > frame but the CR bit for NCS response should be set to 0 since it is > always a response. > > This was affecting TC_RFC_BV_25_C PTS qualification test. > > Signed-off-by: Szymon Janc <szymon.janc@xxxxxxxxx> > --- > > V3: fixed invalid CR > V2: moved sanitization to macro ifself > added second patch that also fix __test_pf > > net/bluetooth/rfcomm/core.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Both of these patches have been applied to bluetooth-next. Thanks. Johan -- 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
