On Thu, Jul 9, 2009 at 12:37 PM, Nick Pelly<npelly@xxxxxxxxxx> wrote: > For the RFCOMM issue. > > This is the log when shutdown() is called on the rfcomm socket while > the ACL link is connecting: > > [ 132.856414] rfcomm:rfcomm_sock_shutdown: sock c5cb3a20, sk c63fca00 > [ 132.856933] rfcomm:__rfcomm_sock_close: sk c63fca00 state 5 socket c5cb3a20 > [ 132.857788] rfcomm:__rfcomm_dlc_close: dlc c61ea240 state 7 dlci 38 > err 0 session c63d4ba0 > [ 132.858612] rfcomm:rfcomm_send_disc: c63d4ba0 dlci 38 > [ 132.859069] rfcomm:rfcomm_send_frame: session c63d4ba0 len 4 > [ 132.859893] l2cap:l2cap_sock_sendmsg: sock c5cb38c0, sk c63fc800 > [ 132.860351] rfcomm:rfcomm_dlc_set_timer: dlc c61ea240 state 8 timeout 2000 > [ 133.863739] rfcomm:rfcomm_sock_release: sock c5cb3a20, sk c63fca00 > [ 133.864257] rfcomm:rfcomm_sock_shutdown: sock c5cb3a20, sk c63fca00 > [ 133.865081] rfcomm:rfcomm_sock_kill: sk c63fca00 state 5 refcnt 2 > [ 133.865539] rfcomm:rfcomm_sock_destruct: sk c63fca00 dlc c61ea240 > > > > I'm surprised to see d->state for the rfcomm_dlc is BT_CONFIG at > __rfcomm_dlc_close(), but looking at __rfcomm_dlc_open() this appears > to be intentional. > > We do not hit __l2cap_sock_close() > > We attempt a graceful rfcomm disconnected by sending the dlci > disconnected frame - but this does not make sense - since there is no > rfcomm connection yet. > > > Assuming that d->state == BT_CONFIG during this phase is correct, then > the attached patch will fix this issue. > > However - I don't know the rfcomm state machine - so this patch may > having side effects. Requesting comments. Any comments on this patch? It works for me, but my understanding of the RFCOMM state machine is naive. Nick -- 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
