MIME-Version: 1.0
References: <e66fded8-91ee-6cb9-11be-162dd5c436aa@cisco.com>
In-Reply-To: <e66fded8-91ee-6cb9-11be-162dd5c436aa@cisco.com>
From:   Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Date:   Mon, 21 Jan 2019 14:34:06 +0200
Message-ID: <CABBYNZKhXUBp6e6DLxb4ZPZ66scScUU4N6CbzYCJ=dqQmakVXg@mail.gmail.com>
Subject: Re: Disconnection of signaling channel after AVDTP close
To:     =?UTF-8?Q?Per_Waag=C3=B8?= <pwaago@cisco.com>
Cc:     linux-bluetooth <linux-bluetooth@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Per,

On Thu, Jan 17, 2019 at 9:19 AM Per Waag=C3=B8 <pwaago@cisco.com> wrote:
>
> We have a product that implements an A2DP sink running bluez 5.50. I'm
> try to qualify this product with the Bluetooth SIG using the Profile
> Tuning Suite (PTS), but I am having trouble passing a test that verifies
> reported delay value (A2DP/SNK/SYN/BV-01-C).
>
> In that test, PTS configures an AVDTP stream and verifies the delay
> report, then opens the stream, streams some data and closes the stream.
> This is repeated. The problem seems to be that after the stream is
> closed, bluez immediately also closes the L2CAP signaling channel.
>
> I have pasted the problematic sequence from btmon at the bottom of this
> email, the problem is the last L2CAP Disconnection request.
>
> This was introduced with commit 7ece89b0b6 between version 5.47 and
> 5.48. Before that, there was always a one second delay before the
> signaling channel was disconnected,
> which was enough for PTS to configure a new stream.
>
> What was the rationale for always disconnecting immediately? Could there
> be circumstances where it would make sense to keep the signaling channel
> open a bit longer? Is there any other way we can force the channel to
> stay open?

Could you please try to check with the patch Ive just sent? That
should track who has closed/aborted the stream so in case the remote
have done it will set a timeout before destroying the session.


> Best regards,
> Per Waag=C3=B8
>
> --
>  > ACL Data RX: Handle 12 flags 0x02 dlen 7                #329 [hci0]
> 48.732441
>        Channel: 64 len 3 [PSM 25 mode 0] {chan 0}
>        AVDTP: Close (0x08) Command (0x00) type 0x00 label 2 nosp 0
>          ACP SEID: 1
> < ACL Data TX: Handle 12 flags 0x00 dlen 6                #330 [hci0]
> 48.732775
>        Channel: 64 len 2 [PSM 25 mode 0] {chan 0}
>        AVDTP: Close (0x08) Response Accept (0x02) type 0x00 label 2 nosp =
0
>  > ACL Data RX: Handle 12 flags 0x02 dlen 310              #331 [hci0]
> 48.736692
>  > ACL Data RX: Handle 12 flags 0x01 dlen 337              #332 [hci0]
> 48.771536
>        Channel: 65 len 643 [PSM 25 mode 0] {chan 1}
>  > ACL Data RX: Handle 12 flags 0x02 dlen 12               #333 [hci0]
> 48.771963
>        L2CAP: Disconnection Request (0x06) ident 30 len 4
>          Destination CID: 65
>          Source CID: 65
> < ACL Data TX: Handle 12 flags 0x00 dlen 12               #334 [hci0]
> 48.772019
>        L2CAP: Disconnection Response (0x07) ident 30 len 4
>          Destination CID: 65
>          Source CID: 65
> < ACL Data TX: Handle 12 flags 0x00 dlen 12               #335 [hci0]
> 48.772960
>        L2CAP: Disconnection Request (0x06) ident 4 len 4
>          Destination CID: 64
>          Source CID: 64
>  > HCI Event: Number of Completed Packets (0x13) plen 5    #336 [hci0]
> 48.778131
>          Num handles: 1
>          Handle: 12
>          Count: 2
>  > HCI Event: Number of Completed Packets (0x13) plen 5    #337 [hci0]
> 48.953264
>          Num handles: 1
>          Handle: 12
>          Count: 1
>  > HCI Event: Disconnect Complete (0x05) plen 4            #338 [hci0]
> 50.167143
>          Status: Success (0x00)
>          Handle: 12
>          Reason: Remote Device Terminated due to Power Off (0x15)
>


--
Luiz Augusto von Dentz