Re: [4.48] SDP Discovery not reset on error

Johan Hedberg
2009-09-04T06:31:43Z

Hi Peter,

On Thu, Sep 03, 2009, Peter Hurley wrote:
> I believe that SDP Discovery initiated during rfcomm_connect is left in
> an inconsistent state when there is an error (such as when the remote
> device is off).
>
> In the log capture below, an attempt to connect (via
> gnome-bluetooth/bluetooth-applet) to the headset fails because the
> device is off. When the device is turned back on, and another attempt
> is made to connect, SDP discovery fails again (Operation already in
> progress).
>
>> Sep 3 21:21:52 dev-wkstn bluetoothd[2724]: State changed /org/bluez/2724/hci0/dev_00_0D_FD_1E_99_30: HEADSET_STATE_DISCONNECTED -> HEADSET_STATE_CONNECT_IN_PROGRESS
>> Sep 3 21:21:57 dev-wkstn bluetoothd[2724]: adapter_get_device(00:0D:FD:1E:99:30)
>> Sep 3 21:21:57 dev-wkstn bluetoothd[2724]: Unable to get service record: Host is down (112)
>> Sep 3 21:21:57 dev-wkstn bluetoothd[2724]: telephony-dummy: device 0x7f71751e8230 disconnected
>> Sep 3 21:21:57 dev-wkstn bluetoothd[2724]: State changed /org/bluez/2724/hci0/dev_00_0D_FD_1E_99_30: HEADSET_STATE_CONNECT_IN_PROGRESS -> HEADSET_STATE_DISCONNECTED
>> Sep 3 21:23:00 dev-wkstn bluetoothd[2724]: State changed /org/bluez/2724/hci0/dev_00_0D_FD_1E_99_30: HEADSET_STATE_DISCONNECTED -> HEADSET_STATE_CONNECT_IN_PROGRESS
>> Sep 3 21:23:00 dev-wkstn bluetoothd[2724]: Unable to get service record: Operation already in progress (114)
>> Sep 3 21:23:00 dev-wkstn bluetoothd[2724]: telephony-dummy: device 0x7f71751e8230 disconnected
>> Sep 3 21:23:00 dev-wkstn bluetoothd[2724]: State changed /org/bluez/2724/hci0/dev_00_0D_FD_1E_99_30: HEADSET_STATE_CONNECT_IN_PROGRESS -> HEADSET_STATE_DISCONNECTED
>
> Initially I was thinking that bt_cancel_discovery() needed to be called
> or that cleanup in one of the failed: targets in the series of functions
> and callbacks in common/glib_helper.c was the problem, but after a quick
> scan perhaps the problem lies on the SDP server side? Suggestions?

You might want to take a hcidump output of the second connect failure,
i.e. run "hcidump -XV" as root while trying to connect. It would also be
interesting to know if this is reproducable with later BlueZ versions like
4.52. I tried to do a few quick tests with it but was unable to reproduce
the issue.

Johan