Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <SJ0PR13MB5755B252BAE811BDFE22E3F7FE809@SJ0PR13MB5755.namprd13.prod.outlook.com>
 <SJ0PR13MB5755BDD8A189504972CCAF8DFE809@SJ0PR13MB5755.namprd13.prod.outlook.com>
In-Reply-To: <SJ0PR13MB5755BDD8A189504972CCAF8DFE809@SJ0PR13MB5755.namprd13.prod.outlook.com>
From:   Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Date:   Thu, 7 Jul 2022 13:29:37 -0700
Message-ID: <CABBYNZ+1+z++f-uDJ+AHpF1swwVBigqRe4jUTL55GUa0o1tfvg@mail.gmail.com>
Subject: Re: [BUG] Extended Scan Hangs
To:     John Klug <John.Klug@multitech.com>
Cc:     Linux-Bluetooth MailingList <linux-bluetooth@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi John,

On Wed, Jul 6, 2022 at 3:56 PM John Klug <John.Klug@multitech.com> wrote:
>
> I was running btmon through pcat to avoid running out of space on the device.  I think this was causing packets to be cut off midstream at the end.
>
> Here is the btmon output when turning scan off:
>
>       LE Extended Advertising Report (0x0d)
>         Num reports: 1
>         Entry 0
>           Event type: 0x0010
>             Props: 0x0010
>               Use legacy advertising PDUs
>             Data status: Complete
>           Legacy PDU Type: ADV_NONCONN_IND (0x0010)
>           Address type: Random (0x01)
>           Address: 06:62:7D:C6:64:48 (Non-Resolvable)
>           Primary PHY: LE 1M
>           Secondary PHY: No packets
>           SID: no ADI field (0xff)
>           TX power: 127 dBm
>           RSSI: -68 dBm (0xbc)
>           Periodic advertising interval: 0.00 msec (0x0000)
>           Direct address type: Public (0x00)
>           Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
>           Data length: 0x1f
>         1e ff 06 00 01 09 20 02 74 f5 eb a3 76 9d e7 b5  ...... .t...v...
>         11 e6 85 a0 41 ca 09 4d 27 f1 f6 dc a5 5f bc     ....A..M'...._.
>         Company: Microsoft (6)
>           Data: 0109200274f5eba3769de7b511e685a041ca094d27f1f6dca55fbc
> @ MGMT Command: Stop Discovery (0x0024) plen 1                                                                                                           {0x0001} [hci0] 159.216816
>         Address type: 0x06
>           LE Public
>           LE Random
> @ MGMT Event: Command Complete (0x0001) plen 4                                                                                                           {0x0001} [hci0] 159.220056
>       Stop Discovery (0x0024) plen 1
>         Status: Rejected (0x0b)
>         Address type: 0x06
>           LE Public
>           LE Random

Looks like a bug in the kernel since it is rejecting the stop
discovery, have you checked if there are any fixes for it later on?