Hi Luiz,
> Finally find out what is the problem, we are currently sending DM to
> reject the connection when using DEFER_SETUP which is fine according
> to RFCOMM spec:
>
> "the responding implementation may replace the "proper" response on
> the Multiplexer Control channel with a DM frame, sent on the referenced DLCI
> to indicate that the DLCI is not open, and that the responder would not grant a
> request to open it later either."
>
> What it doesn't mention is which part is supposed to take down DLCI 0
> in case that there is no other DLC configured, from what I could find
> out the initiator is supposed to take down by sending DISC 0. This
> seems to work fine when using rctest, but some headset may not take
> any action when receiving the DM frame, so what can be done in this
> case?
>
> What about a timeout to trigger rfcomm_session_put and send DISC 0?
> This might solve the problem and we avoid the double DISC 0 in case
> the initiator stack implementation cope with DM.
so does this fixes it:
diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
index 374536e..266c3b7 100644
--- a/net/bluetooth/rfcomm/core.c
+++ b/net/bluetooth/rfcomm/core.c
@@ -1772,8 +1772,7 @@ static inline void rfcomm_process_dlcs(struct
rfcomm_sessi
rfcomm_dlc_clear_timer(d);
if (!d->out)
rfcomm_send_dm(s, d->dlci);
- else
- d->state = BT_CLOSED;
+ d->state = BT_CLOSED;
__rfcomm_dlc_close(d, ECONNREFUSED);
continue;
}
Regards
Marcel
--
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
