HCI_LE_Connection_Complete_Event is sent when HCI_LE_Enhanced_Connection_Complete should be sent.

[dlech]

‎Controller.create_le_connection‎() currently only sends HCI_LE_Connection_Complete_Event in response to HCI_LE_Create_Connection_Command.

bumble/bumble/controller.py

Lines 666 to 680 in 7fdc4f6

	# Say that the connection has completed
	self.send_hci_packet(
	# pylint: disable=line-too-long
	hci.HCI_LE_Connection_Complete_Event(
	status=hci.HCI_SUCCESS,
	connection_handle=connection.handle if connection else 0,
	role=hci.Role.CENTRAL,
	peer_address_type=peer_address.address_type,
	peer_address=peer_address,
	connection_interval=interval,
	peripheral_latency=latency,
	supervision_timeout=timeout,
	central_clock_accuracy=0,
	)
	)

However, it isn't quite so simple.

Bluetooth core spec v6.0 Vol 4, Part E says:

7.8.12 LE Create Connection command

...

Event(s) generated (unless masked away):

When the Controller receives the HCI_LE_Create_Connection command, the Controller
sends the HCI_Command_Status event to the Host. An HCI_LE_Connection_Complete
or HCI_LE_Enhanced_Connection_Complete event shall be generated when a
connection is created because of this command or the connection creation procedure
is cancelled; until one of these events is generated, the command is considered
pending. If a connection is created and the Controller supports the LE Channel
Selection Algorithm #2 feature, this event shall be immediately followed by an
HCI_LE_Channel_Selection_Algorithm event.

7.7.65.1 LE Connection Complete event

...

Note: This event is not sent if the HCI_LE_Enhanced_Connection_Complete event (see
Section 7.7.65.10) is unmasked.

7.7.65.10 LE Enhanced Connection Complete event

...

The HCI_LE_Enhanced_Connection_Complete event indicates to both of the Hosts
forming the connection that a new connection has been created. Upon the creation
of the connection a Connection_Handle shall be assigned by the Controller, and
passed to the Host in this event. If the connection creation fails, this event
shall be provided to the Host that had issued the HCI_LE_Create_Connection or
HCI_LE_Extended_Create_Connection command.

If this event is unmasked and the HCI_LE_Connection_Complete event is unmasked,
only the HCI_LE_Enhanced_Connection_Complete event is sent when a new
connection has been created.

3 OVERVIEW OF COMMANDS AND EVENTS

...

LE Enhanced Connection Complete event
4.2 [v1] C.24
5.4 [v2] C.69

...

C.24: Mandatory if the LE Controller supports Connection State and either LE
Feature (LL Privacy) or LE Feature (Extended Advertising) is supported,
otherwise optional if the LE Controller supports Connection State, otherwise
excluded.

...

C.69: Mandatory if LE Feature (Periodic Advertising with Responses - Advertiser)
or LE Feature (Periodic Advertising with Responses - Scanner) is supported,
otherwise excluded.

The Bumble implementation should be updated to follow the spec so that if HCI_LE_Enhanced_Connection_Complete is enabled in a controller and is not masked, it is sent in response to HCI_LE_Create_Connection.

This is particularly important because in the Linux kernel it specifically expects a certain response based on the LE Feature flags based on C.24 (it looks like the it hasn't been updated for C.69 yet though for Bluetooth 5.4).

https://github.com/torvalds/linux/blob/d26143bb38e2546fe6f8c9860c13a88146ce5dd6/net/bluetooth/hci_sync.c#L6630-L6641

https://github.com/torvalds/linux/blob/d26143bb38e2546fe6f8c9860c13a88146ce5dd6/include/net/bluetooth/hci_core.h#L2027-L2035

Because of this, using Bumble with the default controller settings via VHCI always triggers a 20 second timeout when connecting to a peripheral. hci.LeFeatureMask.LL_PRIVACY is set by default. The Linux kernel sees this and expects HCI_LE_Enhanced_Connection_Complete.

bumble/bumble/controller.py

Lines 264 to 277 in 7fdc4f6

	le_features: hci.LeFeatureMask = (
	hci.LeFeatureMask.LE_ENCRYPTION
	| hci.LeFeatureMask.CONNECTION_PARAMETERS_REQUEST_PROCEDURE
	| hci.LeFeatureMask.EXTENDED_REJECT_INDICATION
	| hci.LeFeatureMask.PERIPHERAL_INITIATED_FEATURE_EXCHANGE
	| hci.LeFeatureMask.LE_PING
	| hci.LeFeatureMask.LE_DATA_PACKET_LENGTH_EXTENSION
	| hci.LeFeatureMask.LL_PRIVACY
	| hci.LeFeatureMask.EXTENDED_SCANNER_FILTER_POLICIES
	| hci.LeFeatureMask.LE_2M_PHY
	| hci.LeFeatureMask.LE_CODED_PHY
	| hci.LeFeatureMask.CHANNEL_SELECTION_ALGORITHM_2
	| hci.LeFeatureMask.MINIMUM_NUMBER_OF_USED_CHANNELS_PROCEDURE
	)

[barbibulle]

Thanks for reporting this. You're entirely correct, this is something we need to fix.
In general, Bumble's virtual controller implementation isn't very complete or robust, as it is mostly used for local tests.
For a more complete and correct virtual controller, I recommend using Google's rootcanal project. The only downside, or course, is that it isn't pure python, so a native shared library and/or executable needs to be built for your target platform. There is a rootcanal Python module, which is convenient if you want to install precompiled runtimes for Mac, Linux and windows.