USB Device in unprivilegierten LXC durchreichen

[Hasenpups]

Hallo,

Ich habe ein USB Gateway von Dresden Elektronik (Conbee) welcher als USB Device und ttyUSB0 im Host sichtbar ist.

Diese Devices würde ich gerne in einen unprivilegierten LXC Container durch reichen. Leider scheitere ich. Die Devices sind im Container sichtbar aber scheinbar nicht ansprechbar.

Es geht um das Device an Bus 002 Device 003:

root@deCONZ:~# lsusb
Bus 002 Device 004: ID 0403:6015 Future Technology Devices International, Ltd Bridge(I2C/SPI/UART/FIFO)
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

root@deCONZ:~# ls -l /dev/tty*
crw-rw-rw- 1 nobody nogroup   5, 0 Apr  1 19:52 /dev/tty
crw------- 1 root   tty     136, 0 Apr  1 20:31 /dev/tty1
crw--w---- 1 root   tty     136, 1 Apr  1 20:26 /dev/tty2
crwxrwxrwx 1 nobody nogroup 188, 0 Apr  1 18:57 /dev/ttyUSB0

Was mich wunder ist, dass ttyUSB0 als nobody nogroup im LXC angezeigt wird.

Hat jemand eine Idee, was es noch sein könnte? In einer Debian VM auf dem gleichen System funktioniert der Stick.

Gruß
Stefan

 

[oguz]

Ins `/etc/pve/lxc/CTID.conf`

lxc.mount.entry: /dev/tty dev/tty none bind,optional,create=dir

hinzufügen. Danach auf dem Proxmox Host:

chown 100000:100000 /dev/ttyUSB0

durchführen. Man sollte dann sehen, dass die nobody:nogroup -> root:root wird.

 

[Hasenpups]

Meine Config sieht jetzt wie folgt aus:

arch: amd64
cores: 1
hostname: deCONZ
memory: 512
net0: name=eth0,bridge=vmbr0,hwaddr=F6:5F:C8:4A:0E:8C,ip=dhcp,type=veth
ostype: debian
rootfs: local-lvm:vm-107-disk-0,size=8G
swap: 512
unprivileged: 1

lxc.cgroup.devices.allow: c 189:* rwm
lxc.mount.entry: /dev/bus/usb/002/004 dev/bus/usb/002/004 none bind,optional,create=file
lxc.cgroup.devices.allow: c 188:* rwm
lxc.mount.entry: /dev/ttyUSB0 dev/ttyUSB0 none bind,optional,create=file

Und so im Host:

root@node1:~# ls -l /dev/bus/usb/002/004
crwxrwxrwx 1 100000 100000 189, 131 Apr  2 10:57 /dev/bus/usb/002/004
root@node1:~# ls -l /dev/ttyUSB0
crwxrwxrwx 1 100000 100000 188, 0 Apr  2 10:57 /dev/ttyUSB0

und so im LXC

root@deCONZ:~# ls -l /dev/ttyUSB0
crwxrwxrwx 1 root root 188, 0 Apr  2 10:57 /dev/ttyUSB0

leider kann ich trotzdem nicht auf das Device drauf zu greifen.

Scheinbar findet er das Device aber kann es trotzdem nicht öffnen:

root@deCONZ:~# GCFFlasher_internal -l
 ftdi_sio
GCFFlasher V2_11 (c) dresden elektronik ingenieurtechnik gmbh 2017/12/10

       1  FTDI device found

 device | vendor | product | serial  | description
--------|--------|---------|---------|----------------------
failed to open FTDI device (0) status = 3

root@deCONZ:~#

 

[oguz]

Can you try

strace -f GCFFlasher_internal -l

It looks like status = 3 means FT_DEVICE_NOT_OPENED. Maybe we can tell something from the strace output.

 

[Hasenpups]

Thank you for your support.

Attached is the strace output of this command.

 

[oguz]

[pid   865] open("/dev/bus/usb/002/004", O_RDWR) = 9
[pid   865] ioctl(9, USBDEVFS_GET_CAPABILITIES, 0x7cc5a0) = 0
[pid   865] write(7, "\1", 1)           = 1
[pid   865] ioctl(9, USBDEVFS_CLAIMINTERFACE, 0x7ffea8f24764) = -1 EBUSY (Device or resource busy)
[pid   865] futex(0x7ca528, FUTEX_WAIT_PRIVATE, 2, NULL <unfinished ...>
[pid   867] <... poll resumed> )        = 1 ([{fd=6, revents=POLLIN}])
[pid   867] futex(0x7ca528, FUTEX_WAKE_PRIVATE, 1) = 1
[pid   865] <... futex resumed> )       = 0
[pid   865] close(9)                    = 0
[pid   865] futex(0x7ca528, FUTEX_WAKE_PRIVATE, 1) = 0
[pid   865] write(1, "failed to open FTDI device (0) s"..., 43failed to open FTDI device (0) status = 3

Looks like something is using the device (Device or resource busy)? Maybe a daemon on host? `fuser` might reveal what's using it.

I would suggest you to use a VM instead. The software you're using is not open source (I think?) and we can't really help you much with it. USB passthrough works easier on VMs usually.

 

[Hasenpups]

Looks like something is using the device (Device or resource busy)? Maybe a daemon on host? `fuser` might reveal what's using it.

I would suggest you to use a VM instead. The software you're using is not open source (I think?) and we can't really help you much with it. USB passthrough works easier on VMs usually.

Thank you for your great support.

fuser did show nothing.

root@deCONZ:/dev# fuser /dev/bus/usb/002/004

I could already run the software with VM but I was thinking about the overhead. But maybe I have to stick with it.

 

[reg000]

leider kann ich trotzdem nicht auf das Device drauf zu greifen.

Scheinbar findet er das Device aber kann es trotzdem nicht öffnen:

root@deCONZ:~# GCFFlasher_internal -l
ftdi_sio
GCFFlasher V2_11 (c) dresden elektronik ingenieurtechnik gmbh 2017/12/10

       1  FTDI device found

device | vendor | product | serial  | description
--------|--------|---------|---------|----------------------
failed to open FTDI device (0) status = 3

root@deCONZ:~#

Schau dir mal diese Anleitung an. Unter "Tweak container environment" erklärt er wie er wie das geht. Bei mir hat es funktioniert.

Ich schaffe es aber nicht die Rechte meines USB Devices im Container anzupassen.

Host

root@pve:~# ls -l /dev/ttyUSB0
crw-rw-rw- 1 10000 10000 188, 0 Mar 17 02:50 /dev/ttyUSB0

LXC

root@phoscon:/home/martin# ls -l /dev/ttyUSB0
crw-rw-rw- 1 nobody nogroup 188, 0 Mar 17 01:51 /dev/ttyUSB0

Grundsätzlich hatte ich es auch so schon zwei mal funktioniert. Nach einem Neustart des Hosts dann wieder nicht mehr. Erklären kann ich mir das noch nicht.

 

[mafe68]

Wenn ich das richtig verstehe ist der Conrbee Stick sowas wie der Zigbee mit dem du Xiaomi Device ansprechen kannst. Habe hier einen Zigbee CC2530 laufen. Nur wird der als /dev/ttyACM0 angezeigt und auch so in der Config eingetragen. Weil du schreibst nach einen reboot ist der nicht mehr erreichbar, das hängt mit dem auch zusammen wenn man beim erstellen den Container nicht den Hacken bei Unprivilegierten Container raus nimmt. Da kann es sein das bei jedem Neustart nicht mehr erreichbar ist. Was für Container ist das wo du ihn durchreichen willst? (ioBroker, Fhem)

 

[CoolTux]

Vielleicht hilft das hier
https://tuxnetwiki-tuxnet.ddns.net/doku.php?id=it-wiki:proxmox:usb_passthrough

 

[reg000]

In dem Container läuft ausschließlich deCONZ, welches ich in privilegierten Containern noch nicht zum Laufen gebracht habe.

Inzwischen habe ich herausgefunden, dass die Phoscon Software nicht mehr mit dem Stick kommunizieren konnte, obwohl dieser als funktionsbereit angezeigt wurde und auch mit seinen Zigbee Geräten sprechen konnte. Zurücksetzen und Config neu einspielen hat geholfen. Auch ein Neustart des Hosts überlebt die Konfiguration jetzt.

Die Berechtigung auf den Stick konnte ich auch ohne Änderung der UID/GID lösen, indem ich auf dem Host dem USB Stick o+rw gegeben habe.

crw-rw-rw- 1 root dialout 188, 0 Mar 17 11:27 /dev/ttyUSB0

Das reicht für den Normalbetrieb ohne root aus. Jedoch nicht um den Stick flashen zu können.

Man kann auch eine udev Rule anlegen und diese dann an den Container durchreichen. Bringt imho aber keine Vorteile.