Hi, 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. -- Luiz Augusto von Dentz Engenheiro de Computação -- 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
