Hi Oleg, > >> is there really a problem? The LMP will send an error via HCI. > > > >The attempt to start SCO after the related ACL is no longer present > >makes no sense. > > > >Either after mode change event with no success or disconnection complete > >event the result is the same; there is no valid ACL to attempt > >SCO/eSCO. > > > >Error code 0x02 "unknown connection identifier" may apply for the > >command status event for setup synchronous connection command but the > >spec does not require it. > > Security classification that this case fits is partial DOS for voice services, which is > considered to be severe for emergency calls even for few seconds. > > Depending on chip - It will take awhile (several seconds) before response will pop > up and then no matter what we'll still go over sco/esco setup at top of non existing ACL as Matt says. > > Because whole thing is in kernel several seconds of audio may get lost before phone(userland) > will realize that SCO failed and route audio to speaker, if ever:) > > I'm not big fan of having all of this complication in kernel because of couple of screwed up headsets. > There's no problem doing similar logic in userland with tight control over particular HS and timing. this might break for a broken headset, but that is than a problem of the headset. Also until the SCO setup is completed the SCO socket should never be connected. So userspace can properly detect if SCO setup is in progress and route it to the speaker with a proper audio policy. So I think the emergency call argument is void. And broken headset is broken headset. If it wants to fail, it will fail eventually anyway. The patch gives it a chance to et this working without breaking other headsets. So disconnect event arriving on the ACL link and SCO setup pending is something we need to fix. That is correct. However that is a different issues actually. Since this can happen right now as well. 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
