Return-Path: Message-ID: <54FDD188.4000201@ubnt.com> Date: Mon, 09 Mar 2015 18:59:52 +0200 From: Andrejs Hanins MIME-Version: 1.0 To: Tim Tisdall CC: Marcel Holtmann , linux-bluetooth@vger.kernel.org Subject: Re: bt dongle goes awry after too many connections References: <6EDCDCB4-6F4D-4DE6-88DB-88D333FC2CCC@holtmann.org> <54FDBBD2.10608@ubnt.com> <185295B8-ABD9-4EDF-B290-12C430CCA906@holtmann.org> <54FDCEBC.2050705@ubnt.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed List-ID: On 2015.03.09. 18:53, Tim Tisdall wrote: > On Mon, Mar 9, 2015 at 12:47 PM, Andrejs Hanins wrote: >> Sure, I noticed that lots of work has been done lately in regard to LE, so >> I'm indeed using 5.28 daemon@3.19.x kernel in LE-only mode and so far so >> good. >> One of the useful things which still seems to be missing is the control over >> LE advertisements via D-Bus iface. "Discoverable" property change does not >> affect LE advs. I'm currently using 'hciconfig hci0 leadv' to make it work. >> But still, LE advs stop and do not re-start after adapter is >> connected/disconnected to some peripheral. > It's doing what I'd expect then... I expect dongles to be reset if > they're unplugged and then re-attached. I don't know if there's an > expectation for devices to be returned to their last state if they're > disconnected and re-connected when using DBUS, though. I didn't mean physically re-plugging the adapter. LE advs stop when adapter (controlled via D-Bus) is connected to some other device and does not start again when connection is closed. The adapter itself stays as it is. > I've pretty > much avoided the DBUS interface since most of what I'm doing is simply > not possible through it.