I’m trying to attach a mini PCIe 3G modem to a LXC container, but that doesn’t seem to work.
Device is listed on Turris as ttyUSBx:
root@turris:~# ls -l /dev/ttyUSB*
crw-r–r-- 1 root root 188, 0 Jun 24 11:36 /dev/ttyUSB0
crw-r–r-- 1 root root 188, 1 Jun 24 11:36 /dev/ttyUSB1
crw-r–r-- 1 root root 188, 2 Jun 24 11:36 /dev/ttyUSB2
crw-r–r-- 1 root root 188, 3 Jun 24 11:36 /dev/ttyUSB3
crw-r–r-- 1 root root 188, 4 Jun 24 11:36 /dev/ttyUSB4
I added the following config in LXC container:
# Device mapping
lxc.cgroup.devices.allow = c 188:* rwm
lxc.mount.entry = /dev/ttyUSB0 dev/ttyUSB0 none bind,optional
lxc.mount.entry = /dev/ttyUSB1 dev/ttyUSB1 none bind,optional
lxc.mount.entry = /dev/ttyUSB3 dev/ttyUSB2 none bind,optional
lxc.mount.entry = /dev/ttyUSB3 dev/ttyUSB3 none bind,optional
lxc.mount.entry = /dev/ttyUSB4 dev/ttyUSB4 none bind,optional
But no sign of ttyUSBx in container:
root@LXC_NAME:~# ls -l /dev/ttyUSB*
ls: cannot access /dev/ttyUSB*: No such file or directory
About to do something similar. Hooking up a RFLink home automation gateway to a Home Assistant running on Debian/python3. Home Assistant is up and running (literally a 5-minute job!) and now I need the USB working. Was wondering how to route physical ports to container.
So I got curious; went and plugged the gateway into the Turris (backside USB).
The gateway is an Arduino Mega/2560 (CH340) with a radio frontend stuck to it. On the Turris i get the following response:
2017-06-24T19:52:08+02:00 info kernel: [165073.384676] usb 4-1: new full-speed USB device number 3 using xhci-hcd
2017-06-24T17:53:01+02:00 info /usr/sbin/cron[30567]: (root) CMD (/usr/bin/rainbow_button_sync.sh)
2017-06-24T17:54:01+02:00 info /usr/sbin/cron[31057]: (root) CMD (nethist_stats.lua)
.
.
Compare this to the output I got on my Debian-laptop:
Jun 24 19:55:05 flattop kernel: [1040967.273004] usb 1-2.2: new full-speed USB device number 6 using xhci_hcd
Jun 24 19:55:05 flattop kernel: [1040967.374160] usb 1-2.2: New USB device found, idVendor=1a86, idProduct=7523
Jun 24 19:55:05 flattop kernel: [1040967.374175] usb 1-2.2: New USB device strings: Mfr=0, Product=2, SerialNumber=0
Jun 24 19:55:05 flattop kernel: [1040967.374184] usb 1-2.2: Product: USB2.0-Serial
Jun 24 19:55:05 flattop mtp-probe: checking bus 1, device 6: “/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.2”
Jun 24 19:55:05 flattop mtp-probe: bus: 1, device: 6 was not an MTP device
Jun 24 19:55:05 flattop kernel: [1040967.505756] usbcore: registered new interface driver usbserial
Jun 24 19:55:05 flattop kernel: [1040967.507108] usbcore: registered new interface driver usbserial_generic
Jun 24 19:55:05 flattop kernel: [1040967.508278] usbserial: USB Serial support registered for generic
Jun 24 19:55:05 flattop kernel: [1040967.509661] usbcore: registered new interface driver ch341
Jun 24 19:55:05 flattop kernel: [1040967.509694] usbserial: USB Serial support registered for ch341-uart
Jun 24 19:55:05 flattop kernel: [1040967.509723] ch341 1-2.2:1.0: ch341-uart converter detected
Jun 24 19:55:05 flattop kernel: [1040967.510904] usb 1-2.2: ch341-uart converter now attached to ttyUSB0
Jun 24 19:55:06 flattop org.freedesktop.FileManager1[1510]: org.kde.baloo: “/org/kde/solid/udev/sys/devices/pci0000:00/0000:00:14.0/usb1/1-2/1-2.2/1-2.2:1.0/ttyUSB0/tty/ttyUSB0”
.
.
A somewhat more verbose output, eh?
To me it looks like Turris doesn’t recognize the CH340 serial-to-USB chip as being that. My Debian laptop does and instantiates a /dev/ttyUSB0 representing it.
If Turris doesn’t recognize the device, it won’t be possible to ‘forward’ it to my LXC container I guess.
So how does one get Turris to recognize an Arduino Mega?
If it not available:
a) you will need compile kernel yourself
b) you can ask for adding driver in kernel by default via email ?
c) compile module yourself and then modprobe it to kernel (if it is possible to OpenWRT. Honestly I dont know)
Done. Amazing how simple it is. Turris response is now:
2017-06-24T21:10:57+02:00 info kernel: [169801.695127] usb 4-1: new full-speed USB device number 4 using xhci-hcd
2017-06-24T21:10:57+02:00 info kernel: [169801.836874] ch341 4-1:1.0: ch341-uart converter detected
2017-06-24T21:10:57+02:00 info kernel: [169801.837714] usb 4-1: ch341-uart converter now attached to ttyUSB0
Next step is to get the device to turn up in the container
Cant link any USB as well, but I am 600km away from home so cannot do full experiments.
I would say that thislxc.mount.entry = /dev/ttyUSB0 dev/ttyUSB0 none bind,optional,create=dir lxc.mount.entry = /dev/ttyUSB1 dev/ttyUSB1 none bind,optional,create=dir lxc.mount.entry = /dev/ttyUSB3 dev/ttyUSB2 none bind,optional,create=dir lxc.mount.entry = /dev/ttyUSB3 dev/ttyUSB3 none bind,optional,create=dir lxc.mount.entry = /dev/ttyUSB4 dev/ttyUSB4 none bind,optional,create=dir
have to stay in config, its similiar to this lxc.mount.entry = /dev/dvb dev/dvb none bind,optional,create=dir
for the tuner.
In the /DEV DIRECTORY section I stumbled on the lxc.autodev option and tried it out. Bad idea. Turris lxc falls flat on its face trying to execute it, bringing the GUI to a standstill in the process.
Had to go into my container directory and manually remove autodev from conf to get the GUI going again. You have been warned.
Would this be a task to point the Turris devteam’s attention to? I mean - making hardware accessible from inside a container has potential use to everyone doing these little automation tasks for which the Turris is so well suited.
@Weafyr, once you come home I’d like to hear more on what you can learn from experiments. In your own time
No idea. Write so the official support email, referencing this thread?
We can hope the devs are reading along…
Anyways; we as users must remain aware of the fact that lxc machines are not number crunchers. They are aimed at lightweight tasks.
Again, a Home Assistant would - in my view - be just that. A lightweight task, handling input from hardware doing the heavy lifting and presenting an automation interface. But that’ll require beforementioned interface-transfer to be operational.
Hello all,
I am trying to run RFXTRX433E connected to Omnia and run OpenHAB in LXC container, here is what I have:
I have installed kmod-usb-serial-ftdi, result is that Omnia see the RFXTRX433E device:
[322483.927384] ftdi_sio 4-1:1.0: FTDI USB Serial Device converter detected
[322483.927624] usb 4-1: FTDI USB Serial Device converter now attached to ttyUSB0
If type lsusb I can see:
root@turris:/dev# lsusb
Bus 005 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 003: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@LXC_NAME:/dev# lsusb
Bus 005 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 004 Device 003: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
And also in /dev I can see ttyUSB0
root@LXC_NAME:/dev# ls -la ttyU*
crw-r–r-- 0 root root 188, 0 Mar 2 23:30 ttyUSB0
but OpenHAB is not able to communicate with RFXTRX433E device at all.
For those who do want to use a USB z-wave controller on a TO, be aware that it’s devicename can change during reboots. I use the following hotplug script (on the TO) to ensure the USB device always has the same name, in this case: /dev/zwave (the code is poorly written, but it works):
cat > /etc/hotplug.d/usb/10-usb_hotplug <<EOF
# logger -t DEBUG "hotplug usb: action='\$ACTION' product='\$PRODUCT' type='\$TYPE' interface='\$INTERFACE'"
# logger -t DEBUG "hotplug usb: devicename='\$DEVICENAME' devname='\$DEVNAME' devpath='\$DEVPATH'"
case "\$ACTION" in
add)
case "\$PRODUCT" in
658/200/*)
logger -t DEBUG "hotplug usb: Z-wave.me ZME_UZB1 has been connected!"
# DEVICE_NAME=\$(ls /sys/\$DEVPATH | grep ttyA)
DEVICE_NAME=\$(ls /dev | grep ttyACM*)
logger -t DEBUG "hotplug usb: DEVICE_NAME='\$DEVICE_NAME'"
if [ -z \${DEVICE_NAME} ];
then logger -t DEBUG "hotplug usb: Warning DEVICE_NAME is empty"
exit
fi
chmod a+rw /dev/\$DEVICE_NAME
ln -sf /dev/\$DEVICE_NAME /dev/zwave
logger -t DEBUG "hotplug usb: Symlink from /dev/\$DEVICE_NAME to /dev/zwave created"
;;
esac
;;
remove)
case "\$PRODUCT" in
658/200/*)
logger -t DEBUG "hotplug usb: Z-wave.me ZME_UZB1 has been removed!"
logger -t DEBUG "hotplug usb: Symlink from /dev/\$DEVICE_NAME to /dev/zwave destroyed"
;;
esac
;;
esac
EOF
Please note the text ‘658/200’, (found via lsusb) above, and ‘c 166’ (found via: ls -al /dev/tty*) below.
I note also you needed opkg install kmod-usb-serial-ftdi (for a RFXTRX433E), where I required opkg install kmod-usb-acm (for a zwave.me ZME-UZB1).
If you’re using LXC, I expose that USB device to LXC via:
if ! grep -q zwave /srv/lxc/${LXC_NAME}/config; then
cat >> /srv/lxc/${LXC_NAME}/config << EOF
# for lsusb in LXC-Container, fix error message "unable to initialize libusb: -99"
lxc.mount.entry = /dev/bus/usb dev/bus/usb none bind,optional,create=dir 0 0
# Setup USB passthrough for Z-Wave.me ZME-UZB1, with permissions a+rw (umask=000)
lxc.cgroup.devices.allow = c 166:* rwm
lxc.mount.entry = /dev/zwave dev/zwave none bind,optional,create=file,umask=000 0 0
EOF
fi;
Some of this code has been shamelessly copied from elsewhere, and I am sorry for not being able to provide attributions - however the following were relevant;
Tryin to get DVB USB dongle on LXC, but still cant see any TV adapter in tvheadend
Omnia - Tuner inside back USB port, 3.10.8
LXC - Debian Stretch
root@Doma:~ lsusb -t
/: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
|__ Port 1: Dev 5, If 0, Class=Vendor Specific Class, Driver=dvb_usb_rtl28xxu, 480M
|__ Port 1: Dev 5, If 1, Class=Vendor Specific Class, Driver=, 480M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
|__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=orion-ehci/1p, 480M
root@Doma:~ lsusb
Bus 005 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 005: ID 15f4:0131 HanfTek
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 174c:5106 ASMedia Technology Inc. Transcend StoreJet 25M3
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
root@Doma:~ ls -al /dev/bus/usb/004/005
crw-r--r-- 1 root root 189, 388 Nov 28 17:31 /dev/bus/usb/004/005
root@Doma:~ ls -la /dev/dvb/adapter0/
drwxr-xr-x 2 root root 140 Nov 28 18:28 .
drwxr-xr-x 3 root root 60 Nov 20 14:15 ..
crw-r--r-- 1 root root 212, 4 Nov 28 18:28 demux0
crw-r--r-- 1 root root 212, 5 Nov 28 18:28 dvr0
crw-r--r-- 1 root root 212, 3 Nov 28 18:28 frontend0
crw-r--r-- 1 root root 212, 19 Nov 28 18:28 frontend1
crw-r--r-- 1 root root 212, 7 Nov 28 18:28 net0
root@Debian:~ lsusb
Bus 005 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 004 Device 005: ID 15f4:0131 HanfTek
Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 002: ID 174c:5106 ASMedia Technology Inc. ASM1051 SATA 3Gb/s bridge
Bus 003 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
root@Debian:~ lsusb -t
/: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
|__ Port 1: Dev 5, If 0, Class=Vendor Specific Class, Driver=dvb_usb_rtl28xxu, 480M
|__ Port 1: Dev 5, If 1, Class=Vendor Specific Class, Driver=, 480M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 5000M
|__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci-hcd/1p, 480M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=orion-ehci/1p, 480M
But still no luck. What I am doing wrong?
dmesg
[1071400.221346] usb 4-1: new high-speed USB device number 5 using xhci-hcd
[1071400.378084] usb 4-1: dvb_usb_v2: found a 'Astrometa DVB-T2' in warm state
[1071400.448336] usb 4-1: dvb_usb_v2: will pass the complete MPEG2 transport stream to the software demuxer
[1071400.448409] DVB: registering new adapter (Astrometa DVB-T2)
[1071400.453887] i2c i2c-9: Added multiplexed i2c bus 10
[1071400.453898] rtl2832 9-0010: Realtek RTL2832 successfully attached
[1071400.456727] mn88473 9-0018: Panasonic MN88473 successfully attached
[1071400.456746] usb 4-1: DVB: registering adapter 0 frontend 0 (Realtek RTL2832 (DVB-T))...
[1071400.456833] usb 4-1: DVB: registering adapter 0 frontend 1 (Panasonic MN88473)...
[1071400.456946] r820t 10-003a: creating new instance
[1071400.468420] r820t 10-003a: Rafael Micro r820t successfully identified
[1071400.468491] r820t 10-003a: attaching existing instance
[1071400.475361] r820t 10-003a: Rafael Micro r820t successfully identified
[1071400.481932] Registered IR keymap rc-empty
[1071400.482137] input: Astrometa DVB-T2 as /devices/platform/soc/soc:internal-regs/f10f8000.usb3/usb4/4-1/rc/rc0/input3
[1071400.482144] rc0: Astrometa DVB-T2 as /devices/platform/soc/soc:internal-regs/f10f8000.usb3/usb4/4-1/rc/rc0
[1071400.482271] usb 4-1: dvb_usb_v2: schedule remote query interval to 200 msecs
[1071400.498355] usb 4-1: dvb_usb_v2: 'Astrometa DVB-T2' successfully initialized and connected
EDIT: I managed acess USB device by running TVHeadend under root instead of hts user… Unfortunatelly, DVB-T2 is still doesnt tune anything
Hi…In the “ID of container”.conf document, you add I think to anything you desire. However, you can add the “most noteworthy” organizer to permit all the under ones.
Also, in Proxmox rules, you allocate then the USB as per item ID and so forth
This way it doesn’t make any difference on the off chance that you change port.
Yet, in the event that you have more that one of similar USB things, you should separate with something different.
