Return-Path: MIME-Version: 1.0 In-Reply-To: <56126614.5050303@steev.me.uk> References: <56126614.5050303@steev.me.uk> Date: Mon, 5 Oct 2015 17:11:34 +0300 Message-ID: Subject: Re: Gone away BLE device still available in dbus From: Luiz Augusto von Dentz To: Steven Davies Cc: linux-bluetooth Content-Type: text/plain; charset=UTF-8 Sender: linux-bluetooth-owner@vger.kernel.org List-ID: Hi Steven, On Mon, Oct 5, 2015 at 2:59 PM, Steven Davies wrote: > I have two BLE devices which are visible to the bluetooth stack on my > host machine. One of them is at the edge of the reception range and > sometimes the host can't connect to it. I would expect bluez to remove > the record of this device after a timeout (3 minutes?) but it doesn't > seem to. Instead, when trying to connect to the device I see this debug > output: Only if the device is temporary, but as soon as you attempt to connect to it will be considered persistent since you want to connect to it later. Note that BlueZ does use passive scanning in case a driver has auto_connect flag so it would reconnect automatically if the device start advertising, in that case it is even more important to keep the device registered in the bus so that you can disable auto connect by calling Device1.Disconnect or Device1.Block. > Oct 5 12:35:57 bang bluetoothd[3801]: src/device.c:device_connect_le() > Connection attempt to: B0:B4:48:B9:77:03 > Oct 5 12:36:17 bang bluetoothd[3801]: > src/adapter.c:connect_failed_callback() hci0 B0:B4:48:B9:77:03 status 2 > Oct 5 12:36:17 bang bluetoothd[3801]: plugins/policy.c:conn_fail_cb() > status 2 > Oct 5 12:36:17 bang bluetoothd[3801]: > src/adapter.c:bonding_attempt_complete() hci0 bdaddr B0:B4:48:B9:77:03 > type 1 status 0x2 > Oct 5 12:36:17 bang bluetoothd[3801]: > src/device.c:device_bonding_complete() bonding (nil) status 0x02 > Oct 5 12:36:17 bang bluetoothd[3801]: > src/device.c:device_bonding_failed() status 2 > Oct 5 12:36:17 bang bluetoothd[3801]: src/adapter.c:resume_discovery() > Oct 5 12:36:17 bang bluetoothd[3801]: src/device.c:att_connect_cb() > connect error: Transport endpoint is not connected (107) > Oct 5 12:36:17 bang bluetoothd[3801]: src/device.c:att_error_cb() > Enabling automatic connections > > This returns the message "GDBus.Error:org.bluez.Error.Failed: Software > caused connection abort (36)" through dbus. We might need the HCI logs to know what could be causing this error, usually the error in case a page timeout occurs or passive scanning cannot find the device is host is down. > Should the device not be removed from the device list after a timeout? Nope, that is on purpose if you attempt to connect, perhaps we should even document to avoid such confusion. -- Luiz Augusto von Dentz