BT passthrough LXC (access denied)

[moeff]

Hallo,

ich bekomme es leider nicht hin mein Bluetooth Modul (Intel AX200) in einem LXC Container zu nutzen. Auf dem Host läuft alles einwandfrei.

Host
lspci -v

02:00.0 Network controller: Intel Corporation Device 2723 (rev 1a)
        Subsystem: Intel Corporation Device 0084
        Flags: bus master, fast devsel, latency 0, IRQ 16
        Memory at f7c00000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: [c8] Power Management version 3
        Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
        Capabilities: [40] Express Endpoint, MSI 00
        Capabilities: [80] MSI-X: Enable+ Count=16 Masked-
        Capabilities: [100] Advanced Error Reporting
        Capabilities: [14c] Latency Tolerance Reporting
        Capabilities: [154] L1 PM Substates
        Kernel driver in use: iwlwifi
        Kernel modules: iwlwifi

hciconfig

hci0:   Type: Primary  Bus: USB
        BD Address: 60:F2:62:12:5B:37  ACL MTU: 1021:4  SCO MTU: 96:6
        UP RUNNING
        RX bytes:20717 acl:0 sco:0 events:3248 errors:0
        TX bytes:740662 acl:0 sco:0 commands:3220 errors:0

Container

lspci -v

02:00.0 Network controller: Intel Corporation Device 2723 (rev 1a)
        Subsystem: Intel Corporation Device 0084
        Flags: bus master, fast devsel, latency 0, IRQ 16
        Memory at f7c00000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: <access denied>
        Kernel driver in use: iwlwifi

Was muss ich tun um access denied hier weg zu bekommen?

Can't open HCI socket.: Address family not supported by protocol

Grüße Marco

 

[oguz]

hi,

wie machst du eigentlich den passthrough? mit bind mount?

Was muss ich tun um access denied hier weg zu bekommen?

wenn dein CT unpriviligiert ist, kann es sein dass du die file permissions von hci0 anpassen musst. (da unpriviligierte containers andere uid/gid mappen)

 

[CoolTux]

Bluetooth soll wohl nicht gehen mit Passthrough. Liegt an einer Eigenheit von BT

 

[moeff]

Bluetooth soll wohl nicht gehen mit Passthrough. Liegt an einer Eigenheit von BT

kann das wer bestätigen!

hi,

wie machst du eigentlich den passthrough? mit bind mount?

wenn dein CT unpriviligiert ist, kann es sein dass du die file permissions von hci0 anpassen musst. (da unpriviligierte containers andere uid/gid mappen)

CT ist unpriviligiert

Bus 003 Device 003: ID 8087:0029 Intel Corp.
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.01
  bDeviceClass          224 Wireless
  bDeviceSubClass         1 Radio Frequency
  bDeviceProtocol         1 Bluetooth
  bMaxPacketSize0        64
  idVendor           0x8087 Intel Corp.
  idProduct          0x0029

mapping über

lxc.mount.entry: /dev/bus/usb/003/003 dev/bus/usb/003/003 none bind,optional,create=file

hoffe jemand kann noch helfen. Gibt wenig dazu zu lesen im Netz...

Bei einer VM scheint es mit einem hostpci0: 02:00.0,pcie=1 zu klappen. Klappt hostpci auch in LXC?

 

[moeff]

Keiner mehr eine Idee?

 

[moeff]

Kann man denn bestätigen das BT in LXC nicht nutzbar ist? Wird daran gearbeitet, ich habe bisher nix offizielles gelesen.

 

[hilde0407]

Ich hänge mich hier mal dran! Ich habe selbiges Problem und bin daran am verzweifeln! Im Host läuft mein über USB angebundenes Bluetooth einwandfrei. Im Container, in dem ich mittels lxc.mount.entry überreichten USB Stick auch sehen. Im Container wird der Bluetooth Service aber nicht gestartet, da ein Zugriff verweigert wird (Permission denid). der Befehl hciconfig sagt auch, dass es kein hci0 gibt.
Ist es möglich, dass Bluetooth im Container nicht funktioniert, da die Kernel Module bereits im Host geladen wurden und daher ein Zugriff nicht möglich ist? Dann sollte es zu mindestens möglich sein, die dazugehörigen Kernelmodule zu blacklisten. Die einfache Lösung, statt eines Containers, eine VM zu nutzen, fällt bei mir leider aus, da der von mir genutzte Beelink T45 IOMMU nicht sauber läuft (Die VM startet dann nicht mehr)

 

[moeff]

Hi,

ich hoffe ebenso das es hierfür eine Lösung gibt oder an dieser gearbeitet wird.

Grüße Marco

 

[Stefan_R]

Kann man denn bestätigen das BT in LXC nicht nutzbar ist? Wird daran gearbeitet, ich habe bisher nix offizielles gelesen.

Der pass-through von /dev devices an Container wurde noch nie ganz "offiziell" von PVE selbst unterstützt, allerdings sind "lxc." Einträge erlaubt, welche dann direkt an LXC weitergegeben werden. Das sollte funktionieren, solange es korrekt aufgesetzt wird.

Was auffällt, ist das im oben angegebenen Beispiel ein lxc.cgroup.devices.allow Eintrag fehlt. In diesem Post wird gut beschrieben, wie es wahrscheinlich funktionieren kann (auch den obersten Kommentar beachten, das 'chmod' ist für unprivilegierte Container notwendig, wie auch @oguz bereits erwähnt hat).

 

[hilde0407]

Also, ich habe dem Container, wie beschrieben das USB Device durchgereicht:

root@pve:~# root@pve:~# lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 8087:0a2a Intel Corp.
Bus 001 Device 003: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 Card Reader Controller
Bus 001 Device 002: ID 062a:4101 MosArt Semiconductor Corp. Wireless Keyboard/Mouse
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

root@pve:~# ls -l /dev/bus/usb/001/004
crw-rw-r-- 1 root root 189, 3 Jan 14 18:18 /dev/bus/usb/001/004

Im Configfile des Containers folgendermaßen durchgereicht:

arch: amd64
cores: 2
hostname: iobroker-slave
memory: 1024
net0: name=eth0,bridge=vmbr0,firewall=1,gw=192.168.178.1,hwaddr=F2:94:35:56:7E:1F,ip=192.168.178.131/24,type=veth
ostype: debian
rootfs: local-lvm:vm-111-disk-0,size=5G
swap: 1024
lxc.cgroup.devices.allow: c 189:3 rwm
lxc.mount.entry: /dev/bus/usb/001/004 dev/bus/usb/001/004 none bind,optional,create=file

Im Container zeigt lsusb:

root@iobroker-slave:~# lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 8087:0a2a Intel Corp.
Bus 001 Device 003: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 Card Reader Controller
Bus 001 Device 002: ID 062a:4101 MosArt Semiconductor Corp. Wireless Keyboard/Mouse
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

hciconfig zeigt zunächst nichts, da die bluetooth Sachen noch nicht installiert waren, diese also mit

apt install bluetooth && apt install bluez

installiert. Dabei kommt schon beim Start des Service folgender Fehler:

root@iobroker-slave:~# apt install bluetooth && apt install bluez
Reading package lists... Done
Building dependency tree       
Reading state information... Done
bluetooth is already the newest version (5.50-1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
2 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] y
Setting up bluez (5.50-1) ...
Job for bluetooth.service failed because the control process exited with error code.
See "systemctl status bluetooth.service" and "journalctl -xe" for details.
invoke-rc.d: initscript bluetooth, action "start" failed.
* bluetooth.service - Bluetooth service
   Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Sat 2020-01-18 21:38:15 UTC; 14ms ago
     Docs: man:bluetoothd(8)
  Process: 5164 ExecStart=/usr/lib/bluetooth/bluetoothd (code=exited, status=226/NAMESPACE)
 Main PID: 5164 (code=exited, status=226/NAMESPACE)

Jan 18 21:38:15 iobroker-slave systemd[1]: Starting Bluetooth service...
Jan 18 21:38:15 iobroker-slave systemd[5164]: bluetooth.service: Failed to set up mount namespacing: Permission denied
Jan 18 21:38:15 iobroker-slave systemd[5164]: bluetooth.service: Failed at step NAMESPACE spawning /usr/lib/bluetooth/bluetoothd: Permission denied
Jan 18 21:38:15 iobroker-slave systemd[1]: bluetooth.service: Main process exited, code=exited, status=226/NAMESPACE
Jan 18 21:38:15 iobroker-slave systemd[1]: bluetooth.service: Failed with result 'exit-code'.
Jan 18 21:38:15 iobroker-slave systemd[1]: Failed to start Bluetooth service.
dpkg: error processing package bluez (--configure):
 installed bluez package post-installation script subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of bluetooth:
 bluetooth depends on bluez; however:
  Package bluez is not configured yet.

dpkg: error processing package bluetooth (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 bluez
 bluetooth
E: Sub-process /usr/bin/dpkg returned an error code (1)

Der Befehl

hciconfig

zeigt dann:

root@iobroker-slave:~# hciconfig
Can't open HCI socket.: Address family not supported by protocol

Mich macht die Fehlermeldung: Permission denied stutzig! Es wäre toll, wenn jemand dazu eine Idee hätte!

 

[Stefan_R]

Also, ich habe dem Container, wie beschrieben das USB Device durchgereicht:

root@pve:~# ls -l /dev/bus/usb/001/004
crw-rw-r-- 1 root root 189, 3 Jan 14 18:18 /dev/bus/usb/001/004

Zuerst einmal, nur für den Fall, dass jemand auf ähnliche Fehler stößt, die nicht mit Bluetooth zu tun haben: Das USB-chardev hat hier immer noch die falschen permissions, wie bereits erwähnt, muss man diese ändern (z.B. chmod a+rw /dev/bus/usb/xxx/yyy).

Im Container zeigt lsusb:

root@iobroker-slave:~# lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 8087:0a2a Intel Corp.
Bus 001 Device 003: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 Card Reader Controller
Bus 001 Device 002: ID 062a:4101 MosArt Semiconductor Corp. Wireless Keyboard/Mouse
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Klar, weil 'lsusb' die devices vom Kernel bekommt, und USB devices nicht genamespaced sind (sprich, es werden immer alle devices vom Host angezeigt).

Grundsätzlich funktioniert das durchreichen von USB Geräten auch mit der geposteten Config...

Bluetooth soll wohl nicht gehen mit Passthrough. Liegt an einer Eigenheit von BT

...aber nach etwas mehr Nachforschen stellt sich heraus, dass Bluetooth-Dongles im speziellen wohl tatsächlich eine Ausnahme darstellen.

Bluetooth in Linux funktioniert als Netzwerk-Device, sprich, beim Laden des passenden Treibers für Bluetooth-Hardware registriert sich das 'hci' device nicht als USB, sondern als Netzwerk-Adapter. Das durchreichen der USB /dev-node ist damit also nutzlos, weil die Kommunikation über ganz andere Schnittstellen funktioniert.

Die BT Netzwerk Adapter sind allerdings nicht namespace-bar, können also nicht in einem Container verwendet werden. [0]
Es scheint, als wäre Unterstützung für solch ein Feature auch nicht geplant, [1] ist die neueste Quelle dich ich jetzt auf die Schnelle finden konnte - der Vorschlag wird dort recht schnell abgelehnt.

Ein Vorschlag aus [0] ist auch, den Bluetooth-Stack vom Host zu verwenden, und dafür den DBus Socket an den LXC-Gast weiterzugeben. Das klingt im ersten Moment allerdings nach einem ziemlichen Sicherheitsrisiko, ich bin nicht sicher ob man den DBus soweit absichern kann um so etwas nützlich zu machen. Da kann man dann gleich einen privilegierten Container verwenden, in dem sollte es theoretisch möglich sein.

Wäre in dem Fall wohl tatsächlich besser, einfach eine VM mit USB-passthrough zu verwenden...

[0] https://github.com/lxc/lxd/issues/3265
[1] https://lore.kernel.org/patchwork/patch/820786/

 

[DocMAX]

Still doesn't work with Bluetooth?