NOTE:
To run python scripts from this directory when the Bumble package isn't installed in your environment,
put .. in your PYTHONPATH: export PYTHONPATH=..
Run two virtual controllers, one connected to a soft device written in python with a simple GATT server, and the other connected to an external host.
In this configuration, a BlueZ stack running on a Linux host is connected to a Bumble virtual controller, attached to a local link bus to a second, in-process, virtual controller, itself used by a virtual device with a GATT server.
In this setup, the virtual controllers and host run on a mac desktop, and the BlueZ stack on a Linux VM. A UDP socket communicates HCI packets between the macOS host and the Linux guest.
In a terminal, run socat to bridge a UDP socket to a local PTY.
The PTY is used a virtual HCI UART.
(in this example, the mac's IP address seen from the Linux VM is 172.16.104.1, replace it with
the appropriate address for your environment. (you may also use a port number other than 22333 used here)
socat -d -d -x PTY,link=./hci_pty,rawer UDP-SENDTO:172.16.104.1:22333,bind=:22333
In the local directory, socat creates a symbolic link named hci_pty that points to the PTY.
In a second terminal, run
sudo btattach -P h4 -B hci_pty
This tells BlueZ to use the PTY as an HCI UART controller.
(optional) In a third terminal, run sudo btmon. This monitors the HCI traffic with BlueZ, which is great to see what's going on.
In a fourth terminal, run sudo bluetoothctl to interact with BlueZ as a client. From there, you can scan, advertise, connect, etc.
In a macOS terminal, run
python run_controller.py device1.json udp:0.0.0.0:22333,172.16.104.161:22333
This configures one of the virtual controllers to use a UDP socket as its HCI transport. In this example, the ip address of the Linux VM is 172.16.104.161, replace it with the appropriate
address for your environment.
Once both the Linux and macOS processes are started, you should be able to interact with the
bluetoothctl tool on the Linux side and scan/connect/discover the virtual device running on
the macOS side. Relevant log output in each of the terminal consoles should show what it going on.
In setup, both the BlueZ stack and tools as well as the Bumble virtual stack are running on the same host.
In a terminal, run the example as
python run_controller.py device1.json pty:hci_pty
In the local directory, a symbolic link named hci_pty that points to the PTY is created.
From this point, run the same steps as in the previous example to attach the PTY to BlueZ and use
bluetoothctl to interact with the virtual controller.
Run a host application connected to a 'real' BLE controller over a UART HCI to a dev board running Zephyr in HCI mode (could be any other UART BLE controller, or BlueZ over a virtual UART). The application connects to a Bluetooth peer specified as an argument. Once connected, the application hosts a GATT client that discovers all services and all attributes of the peer and displays them.
Run a host application connected to a 'real' BLE controller over a UART HCI to a dev board running Zephyr in HCI mode (could be any other UART BLE controller, or BlueZ over a virtual UART). The application connects to a Bluetooth peer specified as an argument. The application hosts a simple GATT server with basic services and characteristics.
Run a host application connected to a 'real' BLE controller over a UART HCI to a dev board running Zephyr in HCI mode (could be any other UART BLE controller, or BlueZ over a virtual UART), that starts scanning and prints out the scan results.