USB Serial Port durchreichen verliert Verbindung

[kalter]

Hallo,

Ich habe ein Problem mit meinem USB Optolink Kabel zum auslesen meiner Viessmann Heizung.
Die Verbindung funktioniert. Aber nach ca 30 Minuten verliere ich die Verbindung zum USB Device.

Folgendes habe ich gemacht:
Unter Proxmox in der 103.conf das USB Gerät eingetragen.

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

Dann noch in der 50-myusb.rules eingetragen:

ACTION=="add", KERNEL=="ttyUSB[0-9]*", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", MODE="0666"

(Ich weiß, dass ich bei dieser Variant nicht das USB-Kabel abstecken darf. Da sonst eine Device Nummer zugewiesen wird)

Ich starte dann mein LXC container mit Vcontrold (daemon für die Heizung) und Iobroker.

Verbindung funktioniert
Aber nur ca 30 min. Dann bekomme ich ein Timeout.
Wenn ich dann den LXC container mit Vcontrold und Iobroker neu starte, bekomme ich den Fehler das, dass USB device nicht mehr erreichbar ist.

Kann mir da einer vielleicht weiter helfen ?
Ich denke das wird ein Problem bei dem Proxmox System sein ?? Nicht bei dem LXC Container ?

Schonmal ein Danke
mfg Manuel

 

[fireon]

Siehst du denn das USB Gerät am Proxmox noch wenn es im LXC nicht mehr funktioniert?

lsusb

Prüfe auch das Proxmox Log zu der Zeit wo das USB Gerät im LXC nicht mehr funktioniert. Event. findest du dort einen brauchbaren Ansatz.

journalctl -r

Und bitte auch noch deine Proxmoxversion:

pveversion

 

[kalter]

Hallo,

Die Version ist : pve-manager/7.1-7/df5740ad (running kernel: 5.13.19-2-pve)

Ich habe folgendes herrausgefunden:

Es geht um den Silicon Labs CP 210x.... Bus 001 Device 002.

Die USB Verbindung bricht wohl irgendwann zusammen. (evtl. weil ein zu langes Kabel verwendet wird???? 5m verlängert)
Zunächst bleibt Device auf 002. Aber nach einer Zeit wird aus der 002 eine 004. (wie wenn ich den USB Stecker ziehe und wieder rein stecke)
Danach funktioniert nichts mehr.

Auf Proxmox vor Verbindungsverlust:

lsusb
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 0cf3:e300 Qualcomm Atheros Communications QCA61x4 Bluetooth 4.0
Bus 001 Device 002: ID 10c4:ea60 Silicon Labs CP210x UART Bridge
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

lsusb im lxc ist genau gleich.

Wie bekomme ich es hin das die Device Nummer immer 002 bleibt ??

Die Log konnte ich noch nicht erstellen. Die Verbindung ist beim letzten Test mitten in der Nacht zusammengebrochen.

Hoffe du kannst damit was anfangen.

 

[fireon]

Also wenn es am Host schon nicht ok ist (dann hat es ja nichts mehr mit der Virtualisierung zu tun), würde ich mal tatsächlich phy nachsehen. Z.B. mal nen USB Verstärker zwischen hängen.

 

[kalter]

Ich habe heute ein neues Qualitativ hochwertiges Kabel benutzt. Es ist auch 1m kürzer. Aber keine Verbesserung.
USB-Repeater wäre dann noch ein Versuch wert.

Komisch ist nur, dass es mit einem Raspberry Pi 4 einwandfrei funktioniert . Ich probiere morgen nochmal die Proxmox log zu erstellen wenn der Fehler passiert.

 

[fireon]

Komisch ist nur, dass es mit einem Raspberry Pi 4 einwandfrei funktioniert .

Das ist ja schon mal was. Nun sind die Logs in PVE interessant.

 

[kalter]

Hallo,
habe leider momentan nicht viel Zeit. Bin aber gerade dran mal den zeitpunkt abzupassen um eine log zu erstellen. Sobald ich diese habe gebe ich bescheid.

 

[kalter]

Hallo nochmal,

um 4:13 laut iobroker log ist die verbindung nicht mehr aktiv. Hier die log dazu.
Kann aber nichts erkennen.

Mar 23 05:00:25 Server pveproxy[133804]: worker exit
Mar 23 04:58:01 Server pmxcfs[953]: [dcdb] notice: data verification successful
Mar 23 04:53:32 Server pvedaemon[122300]: <root@pam> successful auth for user 'root@pam'
Mar 23 04:46:14 Server systemd[1]: pve-daily-update.service: Consumed 2.013s CPU time.
Mar 23 04:46:14 Server systemd[1]: Finished Daily PVE download activities.
Mar 23 04:46:14 Server systemd[1]: pve-daily-update.service: Succeeded.
Mar 23 04:46:14 Server pveupdate[150114]: <root@pam> end task UPID:Server:00024A67:0035DC9D:623A9804:aptupdate::root@pam: OK
Mar 23 04:46:13 Server pveupdate[150119]: update new package list: /var/lib/pve-manager/pkgupdates
Mar 23 04:46:12 Server pveupdate[150114]: <root@pam> starting task UPID:Server:00024A67:0035DC9D:623A9804:aptupdate::root@pam:
Mar 23 04:46:11 Server systemd[1]: Starting Daily PVE download activities...
Mar 23 04:39:14 Server pveproxy[1124]: worker 148344 started
Mar 23 04:39:14 Server pveproxy[1124]: starting 1 worker(s)
Mar 23 04:39:14 Server pveproxy[1124]: worker 139642 finished
Mar 23 04:39:14 Server pveproxy[139642]: worker exit
Mar 23 04:38:32 Server pvedaemon[115626]: <root@pam> successful auth for user 'root@pam'
Mar 23 04:22:32 Server pvedaemon[115626]: <root@pam> successful auth for user 'root@pam'
Mar 23 04:18:06 Server pveproxy[1124]: worker 142995 started
Mar 23 04:18:06 Server pveproxy[1124]: starting 1 worker(s)
Mar 23 04:18:06 Server pveproxy[1124]: worker 125052 finished
Mar 23 04:18:06 Server pveproxy[125052]: worker exit
Mar 23 04:17:01 Server CRON[142710]: pam_unix(cron:session): session closed for user root
Mar 23 04:17:01 Server CRON[142711]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Mar 23 04:17:01 Server CRON[142710]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Mar 23 04:06:32 Server pvedaemon[115626]: <root@pam> successful auth for user 'root@pam'
Mar 23 04:04:49 Server pveproxy[1124]: worker 139642 started
Mar 23 04:04:49 Server pveproxy[1124]: starting 1 worker(s)
Mar 23 04:04:49 Server pveproxy[1124]: worker 121822 finished
Mar 23 04:04:49 Server pveproxy[121822]: worker exit
Mar 23 03:58:01 Server pmxcfs[953]: [dcdb] notice: data verification successful
Mar 23 03:53:08 Server pvedaemon[122300]: <root@pam> successful auth for user 'root@pam'
Mar 23 03:51:32 Server pvedaemon[122300]: <root@pam> successful auth for user 'root@pam'
Mar 23 03:41:53 Server pveproxy[1124]: worker 133804 started
Mar 23 03:41:53 Server pveproxy[1124]: starting 1 worker(s)
Mar 23 03:41:53 Server pveproxy[1124]: worker 123217 finished
Mar 23 03:41:53 Server pveproxy[123217]: worker exit
Mar 23 03:35:32 Server pvedaemon[115626]: <root@pam> successful auth for user 'root@pam'
Mar 23 03:19:32 Server pvedaemon[118264]: <root@pam> successful auth for user 'root@pam'
Mar 23 03:17:01 Server CRON[127509]: pam_unix(cron:session): session closed for user root
Mar 23 03:17:01 Server CRON[127510]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Mar 23 03:17:01 Server CRON[127509]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Mar 23 03:10:01 Server CRON[125739]: pam_unix(cron:session): session closed for user root
Mar 23 03:10:01 Server CRON[125740]: (root) CMD (test -e /run/systemd/system || SERVICE_MODE=1 /sbin/e2scrub_all -A -r)
Mar 23 03:10:01 Server CRON[125739]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Mar 23 03:07:14 Server pveproxy[1124]: worker 125052 started
Mar 23 03:07:14 Server pveproxy[1124]: starting 1 worker(s)
Mar 23 03:07:14 Server pveproxy[1124]: worker 107638 finished
Mar 23 03:07:14 Server pveproxy[107638]: worker exit
Mar 23 03:03:32 Server pvedaemon[115626]: <root@pam> successful auth for user 'root@pam'
Mar 23 03:00:05 Server pveproxy[1124]: worker 123217 started
Mar 23 03:00:05 Server pveproxy[1124]: starting 1 worker(s)
Mar 23 03:00:05 Server pveproxy[1124]: worker 110688 finished
Mar 23 03:00:05 Server pveproxy[110688]: worker exit
Mar 23 02:58:01 Server pmxcfs[953]: [dcdb] notice: data verification successful
Mar 23 02:56:35 Server pvedaemon[1115]: worker 122300 started
Mar 23 02:56:35 Server pvedaemon[1115]: starting 1 worker(s)
Mar 23 02:56:35 Server pvedaemon[1115]: worker 69029 finished
Mar 23 02:56:35 Server pvedaemon[69029]: worker exit
Mar 23 02:54:38 Server pveproxy[1124]: worker 121822 started
Mar 23 02:54:38 Server pveproxy[1124]: starting 1 worker(s)
Mar 23 02:54:38 Server pveproxy[1124]: worker 106814 finished
Mar 23 02:54:38 Server pveproxy[106814]: worker exit
Mar 23 02:47:32 Server pvedaemon[115626]: <root@pam> successful auth for user 'root@pam'

 

[Detlef Paschke]

Wie bekomme ich es hin das die Device Nummer immer 002 bleibt ??

Hallo,
ich habe hier schon seit ewigen Zeiten einen "FTDI USB Serial Device converter" ohne Probleme in Betrieb.
Für das Durchreichen in der VM habe ich "Hersteller/Geräte ID verwenden" und nicht "USB Port verwenden" ausgewählt, um dieses Problem zu umgehen.

UDEV-Rules gibt es unter Proxmox für den Konverter nicht, sondern nur in der VM selbst.

# Datei: /etc/udev/rules.d/20-usb-serial-converter.rules
# FTDI-Seriellwandler an USB
SUBSYSTEM=="tty", ATTRS{product}=="USB Serial Converter", ATTRS{serial}=="FTG7NCGM", SYMLINK+="ttyUSBfax"

Viele Grüße
Detlef Paschke

 

[kalter]

Hallo,

Nach 3 verschiedenen USB Verlängerungskabeln hat es nun funktioniert.
Es war eben nur etwas komisch weil die Verbindung immer zur selben Zeit abgebrochen ist. (4:15 Uhr)

Durchreichen by Serial hab ich noch geändert.


Danke für die Tips.

mfg Manuel

 

[DerGraf]

Hallo Zusammen.

Ich habe das selbe Problem. Nach einer gewissen Zeit, meist innerhalb weniger Tage, bricht die Verbindung kurzzeitig ab und im Container ist keine Verbindung mehr möglich. Der Optilink ist mittels udev rule auf /dev/viessmann verlinkt.
Beim manuellen Aus- und Einstecken springt der Optolink von ttyUSB3 auf ttyUSB4 auf ttyUSB1 usw. Hier linkt PVE aber sauber auf /dev/viessmann, jedoch ist im LXC keine Verbindung mehr möglich.

Um eine Verbindung wieder herzustellen zu können muss ich den PVE komplett neustarten. LXC Neustart reicht nicht. Es muss doch möglich sein eine Verbindung im Betrieb wieder herzustellen.

Für Tipps Danke ich im Voraus.

 

[DerGraf]

Nochmal Hallo.

Optolink ist wieder rausgeflogen. In den udev-rules habe ich sogar die Neuerstellung des devices nach reconnect mittels lcx-attach versucht. Klappt auch nicht

Folgende Logs wurden erstellt:

Aug 15 00:38:33 pve kernel: usb usb1-port4: disabled by hub (EMI?), re-enabling...
Aug 15 00:38:33 pve kernel: usb 1-4: USB disconnect, device number 7
Aug 15 00:38:33 pve kernel: cp210x ttyUSB1: failed set request 0x12 status: -19
Aug 15 00:38:33 pve kernel: cp210x ttyUSB1: failed set request 0x0 status: -19
Aug 15 00:38:33 pve kernel: cp210x ttyUSB1: cp210x converter now disconnected from ttyUSB1
Aug 15 00:38:33 pve kernel: cp210x 1-4:1.0: device disconnected
Aug 15 00:38:33 pve kernel: usb 1-4: new full-speed USB device number 10 using xhci_hcd
Aug 15 00:38:34 pve kernel: usb 1-4: New USB device found, idVendor=10c4, idProduct=ea60, bcdDevice= 1.00
Aug 15 00:38:34 pve kernel: usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Aug 15 00:38:34 pve kernel: usb 1-4: Product: CP2102 USB to UART Bridge Controller
Aug 15 00:38:34 pve kernel: usb 1-4: Manufacturer: Silicon Labs
Aug 15 00:38:34 pve kernel: usb 1-4: SerialNumber: 0001
Aug 15 00:38:34 pve kernel: cp210x 1-4:1.0: cp210x converter detected
Aug 15 00:38:34 pve kernel: usb 1-4: cp210x converter now attached to ttyUSB3
Aug 15 00:38:34 pve systemd-udevd[169605]: ttyUSB3: Process '/usr/bin/lxc-attach -n 102 -u 0 -g 0 chown root:dialout /dev/viessmann' failed with exit code 1.
Aug 15 00:38:34 pve systemd-udevd[169605]: ttyUSB3: Process '/usr/bin/lxc-attach -n 102 -u 0 -g 0 chmod 660 /dev/viessmann' failed with exit code 1.

Ich stehe irgendwie auf dem Schlauch.