Bluetooth: Userchan: Add support for TCP Connection

[vChavezB]

Added support to connect to an HCI TCP Server. This allows to do integration tests with other frameworks that support a virtual hci interface.

The use cases I see for this are:

• Test automatically mobile apps with zephyr applications. E.g. Android Emulator
• Integration tests that depend on Zephyr Bluetooth Peripheral devices without the real zephyr hardware. e.g., Test the correct
  functionality of a Bluetooth gateway by assigning a virtual hci controller bridge.

Attached is a proof of concept to show case emulating an Android device and connecting to a Zephyr Bluetooth sample (peripheral_hr). I am using the experimental python software from Google called bumble for connecting the Zephyr TCP HCI client and the Android netsim

https://github.com/google/bumble

Upper left screen is the HCI traffice between zephyr bluetooth stack (host) and the android-netsim (Controller). Lower window is the zephyr binary running the peripheral_hr example in the Windows Subsystem for Linux. And on the right is the Android emulator running with Android API 34 and the NRF Connect App to test the GATT notification of the peripheral_hr sample.

pof_tcp_hci_zephyr.mp4

[carlescufi]

LGTM

[aescolar]

Thanks @vChavezB
Just a few relatively minor things that caught my eye.

[aescolar]

Just 2 trivial nits from me, which do not really warrant another pass unless you want to.

[vChavezB]

I will start adding the documentation about how to use the virtual controller here

https://github.com/vChavezB/zephyr/blob/641720da22721a7dd6ddba8eeb6a297b6675c6be/doc/connectivity/bluetooth/bluetooth-tools.rst?plain=1#L186

Edit: I have added the first documentation on how to use the virtual controller with an example.

[aescolar]

Thank you very much for the update @vChavezB

[vChavezB]

Thanks for the input @aescolar will modify accordingly.

[vChavezB]

I have added the changes proposed by @aescolar for the docs and reverted the condition return value for sscanf .

[Thalley]

Since bt_dev_index is global, I suggest to make arg_hci_idx local, and do this check where arg_hci_idx is assigned. IMO there should be no reason to keep arg_hci_idx as a global value

[vChavezB]

I made arg_hci_idx global to leave it for discussion. The question for me is where should user argument values be checked?

Directly when cmd_bt_dev_found is called or btuserchan_check_arg ?

If the bt index would be checked in cmd_bt_dev_found would it not make sense to also check the other arguments (i.e., ip address, port number) in this function ?

It was not clear to me if btuserchan_check_arg was just used to check if the argument --bt-dev was set or if it should also check the argument values.

[aescolar]

Directly when cmd_bt_dev_found is called or btuserchan_check_arg ?

It is a bit better to check directly in cmd_bt_dev_found, no need to keep going if there is a bad cmd line argument.

would it not make sense to also check the other arguments (i.e., ip address, port number) in this function ?

Yep

[vChavezB]

• I have moved the argument value checks to cmd_bt_dev_found.
• Removed redundant statement hci_socket = false; when the argument correspondes to an IP address and port number because hci_socket is static.
• Capitalization of Bluetooth, TCP and HCI in the docs for the virtual controller sections.

[aescolar]

I'm even happier with the PR now :)

[vChavezB]

Sorry there was a build error, hopefully it should now work 👍

Forgot a local variable that was used in btuserchan_check_arg when moving the checks to cmd_bt_dev_found

[vChavezB]

There seems to be some errors but I am not sure if they are related to the change of the hci user channel source file.

[aescolar]

There seems to be some errors but I am not sure if they are related to the change of the hci user channel source file.

Not related to this PR, main is broken right now, I queued a fix here: #61733

[vChavezB]

ok thanks for the update, I have just updated a condition which was incorrect

https://github.com/vChavezB/zephyr/blob/c7445a10bcac73121dc94e6a97018101c7e288d0/drivers/bluetooth/hci/userchan.c#L299

As I was not considering hci interfaces with index 0 i.e., hci0.

[Thalley]

Thanks for the PR and the quick updates :)

[vChavezB]

No problem, thanks a lot for the input !