Hi Marcel, > I think we need to fix bt_att_send to return false when we got disconnected in between the individual commands. I did run some tests with the code here and if we receive a disconnect, we get stuck and the callback is never called. So when we have running longer procedures, we need to handle the cases where we loose the connection in the middle of it. > I'm actually aware of this issue and was trying to decide who is responsible for handling disconnects. I'm guessing that bt_att can use io_set_disconnect_handler to crate a handler for this case, in which I guess the right thing to do is to mark the bt_att structure as invalidated, cancel all pending ATT operations, and perhaps notify the user with a special callback (similar to the timeout callback)? The user will then have to create a new connection and pass the fd to bt_att_new to obtain a new instance. Does that make sense or is there a better place to handle disconnects in general? -Arman -- 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
