Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: LE Advertising: Command Disallowed
To:     Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc:     "Michael N. Moran" <mike@mnmoran.org>,
        "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
References: <d343e320-b368-e85b-d428-d5c000eb69df@doubly.so>
 <b86e5449-d784-deee-87d8-4bcf1b4b6308@mnmoran.org>
 <d2ebb802-3bb6-63ed-de42-e1a2b0c38f36@doubly.so>
 <CABBYNZKh2FBwVamTqznqaEO=1ksuhY=K9D4pQTbDszneLg1dag@mail.gmail.com>
From:   Devin Bayer <dev@doubly.so>
Message-ID: <cfee49fe-f4c1-e37a-64e2-94e2df927999@doubly.so>
Date:   Wed, 11 Nov 2020 22:07:08 +0100
MIME-Version: 1.0
In-Reply-To: <CABBYNZKh2FBwVamTqznqaEO=1ksuhY=K9D4pQTbDszneLg1dag@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 11/11/2020 21.53, Luiz Augusto von Dentz wrote:
> 
> You also need to ensure you are not mixing with extended advertisement
> commands, iirc if the stack does send
> BT_HCI_CMD_LE_READ_NUM_SUPPORTED_ADV_SETS it would already prevent the
> legacy version to work. Bottom line here is, either use entire stack
> or switch to user-channel with a proper stack, mixed handling won't
> cut anymore, and for the most part we should be covering all the
> advertisement features over D-Bus if we don't please let us know if
> there are still gaps.
> 

Hi Luiz,

I am not sure what you mean about mixed handling, but I am not using bluetoothd.
As you can see the entire log, I don't see any indication of
BT_HCI_CMD_LE_READ_NUM_SUPPORTED_ADV_SETS. Could that be a default from boot
that I need to disable?

BTW, what is "user-channel with a proper stack" ?

My issue with the D-BUS API is that I could never get reliable behavior of even
basic discovering and connecting; it's not about missing features.

~ Devin