Bluetooth detection: better way to identify BT interface

[shawaj]

Similar to #88 but for BT instead of LTE

Currently, we identify "BT detected" by looking for the USB ID of the bluetooth module:

hm-diag/hw_diag/utilities/hardware.py

Lines 8 to 21 in 2a6efba

	def set_diagnostics_bt_lte(diagnostics):
	devices = {
	'BT': '0a12',
	'LTE': '2c7c'
	}
	for dev_type, dev_addr in devices.items():
	resp = os.popen('grep 0a12 /sys/bus/usb/devices/*/idVendor').read()
	if dev_addr in resp:
	diagnostics[dev_type] = True
	else:
	diagnostics[dev_type] = False
	return diagnostics

Whilst this works, it is a little bit cumbersome IMO, and doesn't allow checking for in-built bluetooth hardware (which we will have on future hardware - for example the light hotspots).

So ideally, we need a better way to identify the bluetooth interface. Perhaps by checking for a device with hcitool dev or hciconfig -a

[shawaj]

@marvinmarnold @vpetersson need to get this resolved in order for diagnostics to work properly with RockPi

[marvinmarnold]

Will keep an eye on this. Its in our next sprint (started today). @posterzh is about to start working on it.

[shawaj]

Sweet 👌

[posterzh]

There are 3 utilities for us to get BLE devices.

• hcitool dev
• hciconfig -a
• bluetoothctl list
  

To get list of bluetooth devices programatically, we can use dbus for that.

Bluetoothctl uses Bluez5. Bluez5 exposes interfaces in the DBus for each functionality it offers(https://stackoverflow.com/questions/41553982/dbus-monitor-to-watch-bluetooth-activity/41577555)

[vpetersson]

Well, there are more ways. Those are just CLI tools for interacting with a BLE device. You can find out if a BLE device is connected on kernel level instead (such as looking in /proc or /sys for instance).

While I don't love the current approach (grep 0a12 /sys/bus/usb/devices/*/idVendor) is way too hackish, I don't want to replace it with any other tool unless we can programmatically use it (with for instance exit codes) rather than trying to prase stings.

[posterzh]

@vpetersson I implemented getting the BLE devices and LTE devices programatically using dbus.
https://github.com/NebraLtd/hm-diag/pull/242/files#diff-1bc7190be6e1a8de2f5a4d659238a140f25dfff6cffa3587bc2e317b6d430709R57-R114

This draft implementation would fix both of #96 and #88
Also I confirm that it's possible to use all the features of nmcli cli using dbus.

To interact BLE and LTE devices with other than dbus, I played with several commands and they needs the diagnostics container to set network_mode to host and NET_ADMIN capability.
https://www.balena.io/docs/learn/develop/multicontainer/

The following commands works well when network_mode is set to host and have NET_ADMIN capability, without dbus enabled.

• hcitool dev : check the BLE device
• hciconfig -a : check the BLE device
• ifconfig wlan0 : check the LTE device

The following commands doesn't work without dbus enabled.

• bluetoothctl list
• nmcli

[shawaj]

@posterzh wlan0 is WiFi not LTE. LTE I believe would be wwan0 and would identify as a modem in NetworkManager / ModemManager

With regards to the other bits, I think dbus probably makes the most sense here as it's how we interface with Bluetooth and WiFi in hm-config container. This would also allow us to solve #226 in diagnostics in the future as well.

Not sure what @vpetersson and @marvinmarnold think?

@vpetersson re your comment on /sys or /proc - just for reference, for that we would need to enable the balena labels for bind mounting those pseudo filesystems into the container

[posterzh]

@shawaj In the today's standup meeting, @vpetersson confirmed that interacting in a programmatic way using dbus makes more sense.

[shawaj]

Sounds good to me 👍

[shawaj]

Closed by #242

[shawaj]

Reopening until merged to production

[posterzh]

@shawaj Make sense. I am writing a PR in helium-miner-software repository.