Sonoff (WLan) unter Proxmox reagiert unzuverlässig

[Allodo]

@thomas-braun
Wenn ich aber /dev/ttyACM0 eintrage, funktionert er doch einwandfrei

Mir geht es aber eigentlich um mein Sonoff-WLan-Geräte, welche nicht richtig funktionieren
Warum verlieren diese immer wieder den Kontakt?

Ach ja, den Sonoff-Adapter habe ich schon mal gelöscht und neu installiert, was aber keine Besserung brachte. Habe den Geräten eine andere Client-ID gegeben und diese waren auch unmittelbar sichtbar, es erschienen aber kurz darauf die "alten"Client-ID's unter Objekten, jedoch als Offline.

[Thomas Braun]

@allodo sagte in Sonoff (WLan) unter Proxmox reagiert unzuverlässig:

funktionert er doch einwandfrei

Aber nur solange sich das Gerät nicht ändert.
Deswegen verwendet man ja bevorzugt die by-id-Links, die ändern sich nämlich nicht.
Dazu muss das aber in einer VM auch richtig durchgereicht werden. Musst du mal in die Dokumentation schauen, wie das da richtig gemacht wird.

[Allodo]

@thomas-braun

Also so habe ich es in die config-Datei geschrieben.

lxc.cgroup2.devices.allow: c 189:* rwm
lxc.mount.entry: usb-ITEAD_SONOFF_Zigbee_3.0_USB_Dongle_Plus_V2_20221130105601-if00 dev/serial/by-id/usb-ITEAD_SONOFF_Zigbee_3.0_USB_Dongle_Plus_V2_2022113>
lxc.cgroup2.devices.allow: c 166:* rwm
lxc.mount.entry: /dev/ttyACM0 dev/ttyACM0 none bind,optional,create=file

Die korrekten Werte habe ich vorher ermittelt. Halte mich da nur an Anleitungen, da ich, wie erwähnt, kein Linuxcrack bin, sondern einfacher Anwender

[MartinP]

@allodo Kann mach doch inzwischen im Proxmox-Webinterface einstellen, und muss sich nicht mehr mit Konfig-Dateien herumschlagen ...

"Zugriffsrechte im CT" werden mit 0660 vorbesetzt ...
UID/GID muss man selbst eintragen

Finde im Konfig File dann

arch: amd64
cores: 2
dev0: /dev/ttyACM0,gid=1000,uid=1000
features: nesting=1
hostname: DebianTest
memory: 2048
net0: name=eth0,bridge=vmbr0,firewall=1,hwaddr=BC:24:11:8D:96:FE,ip=dhcp,type=veth
onboot: 1
ostype: debian
rootfs: local-lvm:vm-100-disk-0,size=16G
swap: 2080
unprivileged: 1
lxc.cap.drop: "sys_rawio audit_read"

[Allodo]

@martinp
Danke, das wusste ich nicht. Proxmox ist ja auch völliges Neuland für mich
Allerdings habe ich dort nur den Eintrag "Mount Point" und kann kein Gerät neu zuweisen

Ist ein priviliegerter Container, da ich meine automatischen Backups per CIFS auf meinen Windows-Rechner übertragen möchte. Habe gelesen, dass das wohl nur mit einem priviligierten Container gehen würde

[MartinP]

@allodo Habe ich auch im privilegierten Container

Das Device muss gesteckt sein, um es durchreichen zu können

[Allodo]

@martinp
Die stecken im hinteren USB-Port. Allerdings waren diese nicht beim Rechenzentrum-Knoten-Punkt unter Resource-Mappings aufgeführt. Habe danach die PVE mal neu gestartet, habe aber dennoch nur den Punkt Mount-Point unter Hinzufügen

Habe noch eine VM mit Raspberry-Matic laufen und dort wurde der USB-Stick von EQ3 sofort erkannte. Ist aber auch eine VM und kein LXC-Container.

[MartinP]

@allodo Hast Du denn Proxmox in einer aktuellen Version? 8.3.1 habe ich im Einsatz...

[Allodo]

@martinp
Ich habe die 8.1.3, wobei ich schon dist-upgrade gemacht habe, so wie es auf der Proxmoxseite steht, als auch über GUI.
Der Versionsstand ändert sich nicht

Das System sagt mir, es alles up-to-date

EDIT: Jetzt hat das Update geklappt und ich habe den Punkt ebenfalls
Wo bekomm ich denn die Info her, was bei UID und GID eingetragen werden kann?

[MartinP]

@allodo Manchmal vergisst man, Dienste neu zu starten, nach einem Update... Da lauert die neu installierte Version in Wartestellung, und es läuft immer noch die alte Version...

Da gibt es z. B. das Tool "needrestart" - hatte aber neulich eine Sicherheitslücke ...

startet sich selber, nach jedem "apt full-upgrade" und schaut, was umgehauen werden muss, macht es teilweise selber, und wenn das nicht geht (neues kernel z. B. ) gibt e einen Hinweis, dass man einen Neustart machen sollte...

root@pve:~# needrestart
Scanning processes...                                                                                                                                                                                                                
Scanning processor microcode...                                                                                                                                                                                                      
Scanning linux images...                                                                                                                                                                                                             

Running kernel seems to be up-to-date.

The processor microcode seems to be up-to-date.

No services need to be restarted.

No containers need to be restarted.

No user sessions are running outdated binaries.

No VM guests are running outdated hypervisor (qemu) binaries on this host.