lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CABBYNZLtbEnU3wfnym0P8gamh1_5GcUHKvAnxh4GpcBC3G56uQ@mail.gmail.com>
Date: Wed, 7 Feb 2024 11:33:59 -0500
From: Luiz Augusto von Dentz <luiz.dentz@...il.com>
To: patchwork-bot+bluetooth@...nel.org
Cc: marcel@...tmann.org, johan.hedberg@...il.com, 
	linux-bluetooth@...r.kernel.org, linux-kernel@...r.kernel.org, 
	netdev@...r.kernel.org
Subject: Re: [PATCH v4 0/2] Bluetooth: Improve retrying of connection attempts

Hi Jonas,

On Wed, Feb 7, 2024 at 11:10 AM <patchwork-bot+bluetooth@...nel.org> wrote:
>
> Hello:
>
> This series was applied to bluetooth/bluetooth-next.git (master)
> by Luiz Augusto von Dentz <luiz.von.dentz@...el.com>:
>
> On Tue,  6 Feb 2024 12:08:12 +0100 you wrote:
> > Since commit 4c67bc74f016 ("[Bluetooth] Support concurrent connect
> > requests"), the kernel supports trying to connect again in case the
> > bluetooth card is busy and fails to connect.
> >
> > The logic that should handle this became a bit spotty over time, and also
> > cards these days appear to fail with more errors than just "Command
> > Disallowed".
> >
> > [...]
>
> Here is the summary with links:
>   - [v4,1/2] Bluetooth: hci_conn: Only do ACL connections sequentially
>     https://git.kernel.org/bluetooth/bluetooth-next/c/456561ba8e49
>   - [v4,2/2] Bluetooth: Remove pending ACL connection attempts
>     https://git.kernel.org/bluetooth/bluetooth-next/c/8e14d581d125
>
> You are awesome, thank you!
> --
> Deet-doot-dot, I am a bot.
> https://korg.docs.kernel.org/patchwork/pwbot.html

Something is not quite right with these changes:

L2CAP BR/EDR Client - Timeout - test passed
L2CAP BR/EDR Client - Timeout - teardown
Bluetooth: hci0: command 0x0408 tx timeout
  Index Removed callback
    Index: 0x0000
L2CAP BR/EDR Client - Timeout - teardown complete
L2CAP BR/EDR Client - Timeout - done
L2CAP BR/EDR Client - Timeout                        Passed      22.329 seconds

The test seems to be blocked on teardown then the command times out,
0x0408 is HCI_OP_CREATE_CONN_CANCEL so I wonder why it would be timing
out. Anyway the test uses SO_SNDTIMEO to set a timeout at the socket
level but it doesn't seem it is used while creating the connection so
it probably needs to be passed down or something.


-- 
Luiz Augusto von Dentz

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ