Moin.

An einer Kiste mit Arch-Linux hängen zwei verschiedene Funkgeräte (IC-R8600, IC-9700) des gleichen Herstellers (Icom), beide über USB mit dem Linuxrechner verbunden.
Das ältere Gerät (IC-R8600) verwendet den Silabs CP2102 Chip (genauer den CP2102-GMR) als UART Bridge, das neuere Gerät den CP2102N (genauer den CP2102N-A01-GQFN28R). Zu sehen ist die unterschiedliche Hardware in dmesg oder auch mit lsusb -v. Beide Chips nutzen das gleiche Treiber-Modul cp210x.

Jedes Gerät bildet zwei serielle Schnittstellen ab, für unterschiedliche Funktionen.

Um den Geräten persistente Namen zu geben (per symlink) habe ich udev-Rules erstellt. Die funktionieren prinzipiell auch.


Das Problem:
Wenn ich beim älteren Gerät auf den symlink zugreife, dann geht das.
Wenn ich beim neueren Gerät auf den symlink zugreife, dann geht das nicht, ich darf nicht schreiben.
Beide Symlinks haben die gleichen owner und Rechte.

Wenn ich bei beiden Geräten direkt auf de Geräte zugreife (/dev/ttyUSBx) dann geht alles, owner udn Rechte lassen das zu. Aber die Zuordnung ändert sich halt immer wieder, weswegen ich überhaupt mit den udev-Rules angefangen habe.


Der Unterschied ist das im
* ersten Fall (älteres Gerät, CP2102 chip) der Symlink auf das /dev/ttyUSBx Gerät zeigt (das root:uucp gehört)
* zweiten Fall (neueres Gerät, CP2102N chip) der Symlink auf das /dev/bus/usb/<n>/<m> Gerät zeigt (das root:root gehört). Dies obwohl für dieses Gerät ebenfalls /dev/ttyUSBx Geräte existieren... 
ekki@grappa ~ $ ll /dev/ic*
lrwxrwxrwx 1 root root 15 27. Aug 14:36 /dev/ic9700a -> bus/usb/001/020
lrwxrwxrwx 1 root root 15 27. Aug 14:36 /dev/ic9700b -> bus/usb/001/021
lrwxrwxrwx 1 root root  7 27. Aug 14:28 /dev/icr8600a -> ttyUSB0
lrwxrwxrwx 1 root root  7 27. Aug 14:28 /dev/icr8600b -> ttyUSB1

ekki@grappa ~ $ ll /dev/ttyUSB*
crw-rw---- 1 root uucp 188, 0 27. Aug 14:28 /dev/ttyUSB0
crw-rw---- 1 root uucp 188, 1 27. Aug 14:34 /dev/ttyUSB1
crw-rw---- 1 root uucp 188, 2 27. Aug 14:36 /dev/ttyUSB2
crw-rw---- 1 root uucp 188, 3 27. Aug 14:45 /dev/ttyUSB3

ekki@grappa ~ $ ll /dev/bus/usb/001
total 0
...
crw-rw-r-- 1 root root 189, 19 27. Aug 14:36 020
crw-rw-r-- 1 root root 189, 20 27. Aug 14:36 021
...

Wie erreiche ich, dass der Symlink auf /dev/ttyUSBx zeigt, und nicht auf /dev/bus/usb/001/nnn ?

Hier die udev-Rules:
ekki@grappa ~ $ cat /etc/udev/rules.d/93-icom.rules 
# Icom 

# IC-R8600
ATTRS{product}=="CP2102 USB to UART Bridge Controller", ATTRS{serial}=="IC-R8600 03001303 A", SYMLINK+="icr8600a"
ATTRS{product}=="CP2102 USB to UART Bridge Controller", ATTRS{serial}=="IC-R8600 03001303 B", SYMLINK+="icr8600b"

# IC-9700
ATTRS{product}=="CP2102N USB to UART Bridge Controller", ATTRS{serial}=="IC-9700 13002958 A", SYMLINK+="ic9700a"
ATTRS{product}=="CP2102N USB to UART Bridge Controller", ATTRS{serial}=="IC-9700 13002958 B", SYMLINK+="ic9700b"

Was ich bereits probiert habe:
- andere USB Anschlüsse am Rechner probiert
- nach dem Problem gegoogelt
- Datenblätter und Application Notes CP2102 und CP2102N verglichen
- beide Geräte zig mal aus- und wieder eingesteckt, und Log mitgelesen, das Problem ist reproduzierbar.



Irgendwelche Ideen?

Danke.
Ekki
Ekki Plicht schrieb Wie erreiche ich, dass der Symlink auf /dev/ttyUSBx zeigt, und nicht auf /dev/bus/usb/001/nnn ?
Das kann ich dir nicht sagen, warum das "alte" Gerät "nur" /dev/ttyUSBx erzeugt und das "neue" eben zwei Devicepfade (/dev/ttyUSB und eben /dev/bus/usb/xx/yy, auf letztem werden dann die Symlinks abgebildet). Und ob man das ändern kann.

Aber das einfachste dürfte IMHO sein, die Rechte von /dev/usb/xx/yy eben auch wie gewünscht auf root:uucp zu setzen, dein eigentliches Problem sind ja die fehlenden Zugriffsrechte.
Dazu sollte reichen deine udev-Rules für das "neuere" Device um eine GROUP-Anweisung zu ergänzen, also statt
Ekki Plicht schrieb Hier die udev-Rules:
ekki@grappa ~ $ cat /etc/udev/rules.d/93-icom.rules 
# Icom 

# IC-R8600
ATTRS{product}=="CP2102 USB to UART Bridge Controller", ATTRS{serial}=="IC-R8600 03001303 A", SYMLINK+="icr8600a"
ATTRS{product}=="CP2102 USB to UART Bridge Controller", ATTRS{serial}=="IC-R8600 03001303 B", SYMLINK+="icr8600b"

# IC-9700
ATTRS{product}=="CP2102N USB to UART Bridge Controller", ATTRS{serial}=="IC-9700 13002958 A", SYMLINK+="ic9700a"
ATTRS{product}=="CP2102N USB to UART Bridge Controller", ATTRS{serial}=="IC-9700 13002958 B", SYMLINK+="ic9700b"
wäre dann für den IC-9700 
# IC-9700
ATTRS{product}=="CP2102N USB to UART Bridge Controller", ATTRS{serial}=="IC-9700 13002958 A", SYMLINK+="ic9700a", GROUP="uucp"
ATTRS{product}=="CP2102N USB to UART Bridge Controller", ATTRS{serial}=="IC-9700 13002958 B", SYMLINK+="ic9700b", GROUP="uucp"
Das würde dann die Rechte von (momentan) /dev/bus/usb/001/020 von root:root auf root:uucp ändern (ebenso für 021). Somit hättest du über die Symlinks auch wieder Schreibzugriff.
(Habe es gerade mal mit meinem Scanner angetestet).

Generell wäre noch lesenswert:
https://wiki.archlinux.org/index.php/Udev (speziell 2.2)
Mit udevadm info sowohl zum Device /dev/ttyUSB0 als auch /dev/ttyUSB2 wären evtl. Infos zu kriegen, warum das neuere Gerät als "Hauptdevice" eben auf /dev/bus/usb/xx/yy abbildet statt "nur" auf /dev/ttyUSB.
Also sowas anschauen/vergleichen wie: 
(fürs alte Gerät)
udevadm info -a -p $(udevadm info -q path -n /dev/ttyUSB0)

(und für neue Gerät)
udevadm info -a -p $(udevadm info -q path -n /dev/ttyUSB2)
Evtl. sieht man/Du dabei (Parents), warum das alte Gerät nur einen, das neuere eben zwei Devicebezeichner vom Kernel/Subsystem verpaßt bekommen.
Hi!

Danke...

Ich habe deinen Voschlag getestet, also den beiden udev-Regeln 
GROUP="uucp"
zugefügt.
Das funktioniert prinzipiell auch, d.h. die beiden Devices sind jetzt in dieser Group (wie mein User auch).

Beim Zugreifen auf das Device kommt es aber nun wieder zu einem anderen Fehler "FATAL: failed to add port: Filedes is not a tty" (Das ist ne Fehlermeldung von Picocom).

Im Log (dmesg, journalctl) sieht alles ganz aus wie immer, wenn man das Kabel dran steckt.

Wenn ich nach der Fehlermeldung googele kommt nur sehr wenig, auf der Linux Serial Liste gibts mit Greg K.H. ne kurze Diskussion dazu, ich kann aber nicht beurteilen ob das was mit meinem Problem zu tun hat.

Saudumm, das Ganze. Ich habe den EIndruck, das der CP2102N doch nicht so ganz pin-kompatibel zu seinem Vorgänger CP2102 ist. In der Tat gibt es da auch Unterschiede bei der Konfiguration, wie eine Application Note von Silabs beschreibt (AN976). Vielleicht muss ich mir doch mal den Source vom cp210x Modul angucken. :/

Gruß,
Ekki
Ekki Plicht schrieb Ich habe deinen Voschlag getestet, also den beiden udev-Regeln 
GROUP="uucp"
zugefügt.
Das funktioniert prinzipiell auch, d.h. die beiden Devices sind jetzt in dieser Group (wie mein User auch).

Beim Zugreifen auf das Device kommt es aber nun wieder zu einem anderen Fehler "FATAL: failed to add port: Filedes is not a tty" (Das ist ne Fehlermeldung von Picocom).
In den Programmen gibst du als "Gerät" deine per udev erstellten Symlinks ein? Also /dev/icr8600a und dev/ic9700a.
Würde es dann funktionieren, wenn du (vor Start der Programme) die Symlinks für den IC-9700 per Hand auf die /dev/ttyUSBx Devices zeigen lassen würdest?. Nach Anstecken der Geräte also ein: 
ln -sf /dev/ttyUSB2 /dev/ic9700a
ln -sf /dev/ttyUSB3 /dev/ic9700b
(kleines L in ln)

Jetzt würden ja auch beim 9700er die Symlinks auf die ttyUSB-Devices zeigen, wie es die udev-Regel für den 8600er per se "richtig" macht. (-> kontrollieren)
Die angeführte Fehlermeldung(not a tty) macht IMHO soweit "Sinn", weil das Device /dev/ttyUSBx wirklich als "Terminal" agiert (es hat als major/minor Opcodes 188 (1,2,...). Der Major 188 identifiziert die Devices wohl als "Terminals". Für den 9700 lassen wir die Symlinks aber auf /dev/bus/usb/xx/yy zeigen (bzw. udev macht das), und diese Devices haben als Opcode nun 189 (1,2,...) - was sie aber nicht als "Terminal" kennzeichnet -> ergo Fehler.

Ich bin mit Devices und udev auch nicht sehr fit, aber ich stelle es mir so vor:

Deine Funkadapter sind USB-Geräte. Somit tauchen diese mit ihrer USB-Funktionalität als Devices logischerweise in /dev/bus/usb/ auf. Über die Ansprache /dev/bus/usb/xx/yy kann für den Adapter nun "normale" USB-Kommunikation abgewickelt werden (z.B.: wieviel Strom brauchst du? USB1 oder USB2?). Auf dieser Ebene unterscheiden die Geräte sich nicht von einer USB-Maus.
Gleichzeitig haben deine Funkadapter aber eine spezielle Funktionalität - was sie wieder von einer Maus unterscheidet. Diese Funktionalität wird dann über /dev/ttyUSBx bereitgestellt (Opcode).

Angenommen es gibt in der Kommunikation von tty's die Programmfunktion "Get_TTY_ID" und dein picocom würde diese Funktion aufrufen. Wenn der Aufruf an /dev/ttyUSBx geht, dann wird diese auch beantwortet. Geht sie aber (wie momentan) "nur" an das allgemeinere /dev/bus/usb/xx/yy dann wird der Funktionsaufruf nicht verstanden, da es diese Programm(Device)-Funktion in der Kommunikation für den generellen USB-Bus nicht gibt.

Den Unterschied (auch im gleichen Treiber) zwischen dem 8600 und dem 9700 könnte ich mir so erklären:
1) Beide Geräte haben mindest zwei Devicenodes mit denen kommuniziert werden kann: den generic USB-Bus Teil und den speziellen /dev/ttyUSB Teil.

2) Der 8600er hat in seiner Devicenode-Priorität nun
a) /dev/ttyUSB
b) /dev/bus/usb/xx/yy
Ein per udev-Regel erstellter Symlink verweist nun richtigerweise auf das spezielle Device mit dem richtigen Opcode

3) Beim 9700er ist es nun umgekehrt, warum auch immer. Was eben zu den angeführten Problemen führt: Das allgemeine USB-Bus-Device hat die "falschen" Besitzer-Rechte (haben wir korrigiert), und zum zweiten kann es nicht die zum "Funken" notwendige Funktionalität liefern.

Also kurz gesagt: Biege mal per Hand die für den 9700er verwendeten Symlinks um, damit diese auf die /dev/ttyUSB Devices zeigen.
Wenn das dann für die Programme genügt (picocom), dann muß man diese Verlinkung halt fix/automatisch herbiegen. Ob das per udev-Regel möglich ist bin ich mir nicht sicher, evtl. per Programmaufruf (ln / link) in einer Regel. Oder sonstwie im Startvorgang. Wichtig wäre erstmal ob das wie vorgeschlagen so funktionieren würde.