udev Regel erkennt Gerät nicht

[BlauerPinguin]

Moin

Ich programmiere Mikrocontroller und brauche dafür einen Brenner, den man über USB anschließt. Das Ding wird dann als serielles Gerät erkannt. Mit meiner IDE lese ich aber immer nur "Permission denied"

Mit sudo chmod 0666 /dev/ttyUSB0 kann ich das lösen. Das Gerät wird in der Gruppe dialout und mit root als Besitzer eingebunden und das muss ich halt nur ändern. Ich kann natürlich auch mich selbst als Nutzer in der Gruppe dialout platzieren (das Ding wird standardmäßig mit 0660 eingebunden)

Nur wollte ich das mit einer udev-Regel lösen:

SUBSYSTEM=="usb", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", OWNER="nutzername"

nutzername ist in meiner Datei natürlich durch den richtigen ersetzt. Wenn ich den Brenner neu einstecke, bin ich aber nie der Besitzer des Geräts. Sauerei. Ich habs doch bezahlt. Und nicht root.

An udevadm control --reload-rules habe ich gedacht und das produziert keine neuen Einträge in /var/log/syslog. Also vermute ich, die Regel ist richtig, aber das Gerät wird nicht erkannt. Aber idVendor und idProduct stammen aus lsusb und sind wirklich richtig.

Jemand ne Idee? Ich weiß es gibt ne Menge anderer Lösungen, aber wenn ich einfach sage es geht halt nicht kann ich nachts nicht ruhig schlafen.

Grüße
BlauerPinguin

[Rain_maker]

Sofern die Angaben zur USB-ID stimmen, wäre die Regel OK, eine analoge Regel funktioniert hier auch wunderbar (allerdings mit einer anderen Gruppe statt eines anderen Besitzers, sie auch das edit).

Kleiner Tipp, wie ich udev-Regeln teste:

Die selbe Regel einmal ganz vorne und einmal ganz hinten in die Abfolge setzen, also einmal 01-foo.rules und einmal 99-bar.rules.

Ein "udevadm trigger" nach dem Ändern wäre auch noch einen Versuch wert.

Es wäre nicht das erste Mal, daß die gesetzten Einstellungen durch eine spätere Regel wieder rückgängig gemacht würden.

Edit:

Man sollte aber unbedingt anmerken, daß es eindeutig die bessere Lösung wäre den Nutzer in die Gruppe dialout einzufügen.

Ausserdem weiß man nie so genau wie bestimmte Anwendungen reagieren bzw. ob sie davon ausgehen, daß ein Gerät in /dev root gehört.

[BlauerPinguin]

Danke für die schnelle Antwort.

Das Ändern der Reihenfolge ändert nichts. Auch udevadm trigger hat nichts bewirkt. Ist immernoch ein Gerät von root. Gibts denn ne Möglichkeit zu erfahren, ob udev denkt die Regel würde nicht auf das Gerät angewendet werden müssen, oder ob die Anwendung des OWNER="benutzer" irgendwie schiefläuft?

[Rain_maker]

Tja, keine Ahnung, was da schief geht, denn:



ls -l /dev/ttyUSB*
crw-rw---- 1 root dialout 188, 0 9. Mai 20:56 /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 1 9. Mai 20:56 /dev/ttyUSB1

Erzeugen der Datei 99-test.rules:


SUBSYSTEMS=="usb", ATTRS{idVendor}=="12d1", ATTRS{idProduct}=="1003", OWNER="nobody"

Als root ein "udevadm trigger" ....


ls -l /dev/ttyUSB*
crw-rw---- 1 nobody dialout 188, 0 9. Mai 20:59 /dev/ttyUSB0
crw-rw---- 1 nobody dialout 188, 1 9. Mai 20:59 /dev/ttyUSB1... und fertig.

[BlauerPinguin]

Danke. Es heißt anscheinend SUBSYSTEMS und nicht SUBSYSTEM. In den anderen Regeln steht aber auch SUBSYSTEM. Mit S am Ende klappts jetzt aber. Man ist das peinlich.


Danke sehr.

[Rain_maker]

Ja, so etwas passiert gerne mal, vor allem, weil es diese "Dubletten" mit und ohne S am Ende mehrfach gibt.

KERNEL vs. KERNELS

ATTR vs. ATTRS

SUBSYSTEM vs. SUBSYSTEMS

DRIVER vs. DRIVERS

Deshalb für ein Gerät mit der Gerätedatei "/dev/DAS_DINGEN" die Ausgabe von


udevadm info --query=all --attribute-walk --name=/dev/DAS_DINGEN

_ganz genau_ ansehen.

AFAIK gibt es immer nur einen Eintrag ohne das S am Ende, welcher sich eben direkt auf das genannte Gerät bezieht, die anderen stehen für Geräte, die beim "attribute-walk" sozusagen "entlang der Anschlüsse" liegen und deshalb sogenannte "parent devices" sind.

Ich vermute mal, daß der "SUBSYSTEM"-Eintrag zu obigem Gerät entweder

SUBSYSTEM="usb-serial"

oder

SUBSYSTEM="tty"

lauten dürfte.

Greetz,

RM

[BlauerPinguin]

Danke. Hier wird mir grad ne Menge klar. Bei einem Surfstick hatte ich mal ein ähnliches Problem mit udev. Wegen einer Verwechslung von ATTRS{Hackbrötchen} und ATTR{Kolbenrückholfeder} hat es da dann auch nicht geklappt. Werde ich nochmal probieren.

Und SUBSYSTEM ist laut udevadm info auch "tty". Und von den Optionen für udev hätte ich gerne schon beim Surfstick gewusst =D

Vielen Dank für die schnelle Hilfe.

Grüße
BlauerPinguin

[Rain_maker]

Das mit dem "SUBSYSTEM=tty" macht bei zweiter Überlegung auch wirklich Sinn, denn wie oben angemerkt, steht das soviel ich weiß für das Gerät, welches man direkt anfragt und bei den ganzen Einträgen, die als "Elterngeräte" gelten, wird eben das S angehängt.

Da man mit diesem Gerät über ein serielles Terminal kommuniziert, gehört es zum Subsystem "tty", daß es sich dabei um ein über USB angestöpseltes Gerät handelt, spielt für diese Kommunikation keine entscheidende Rolle, eine PCMCIA-Karte gleicher Funktion hätte auch "SUBSYSTEM==tty" aber eben andere "SUBSYSTEMS"-Einträge, wenn sich udev dann entlang der Anschlüsse hangelt.

Ein USB-Stöpsel, der als Massenspeicher angesprochen wird, hat zum Bleistift auch nicht "SUBSYSTEM==usb", sondern ... das verrate ich jetzt nicht, ist mit dem oben angegebenen Befehl leicht heraus zu finden und auch da macht es dann bei zweiter Überlegung Sinn, was da steht ....

Ich muss auch zugeben, daß mir gerade weil sich mit dem obigen Befehl die entsprechenden Regeln fast von selbst schreiben, gar nicht aufgefallen ist, wieso die Regel im ersten Post nicht funktionieren wird.

Ich hatte nur auf ordentliche Syntax geachtet und danach noch meine analoge Regel mittels Copy&Paste eingestellt, erst danach ist mir dann der Unterschied mit dem SUBSYSTEMS aufgefallen.

Man könnte übrigens noch eine Kleinigkeit hinzufügen



ACTION=="add|change", SUBSYSTEMS=="usb", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", OWNER="nutzername"aber in diesem Fall ist das wohl nur Kosmetik.

Es soll nur als Anregung dienen, was man da noch so alles treiben kann, udev kennt logischerweise auch ACTION="remove" und mit diesen ACTION-Bedingungen kann man dann auch so einige sinnvolle Dinge tun.

Greetz,

RM

[BlauerPinguin]

Ja, ich hab mir auch mal die Manpage zu udev reingetan und mit den Regeln ist ja wirklich allerhand möglich. Aber meiner Meinung nach kann man das ganze Potential erst ausschöpfen, wenn man auch die von udevadm gelesen hat. Dann ist udev ne echte Lösung für allerhand Problemchen und deutlich eleganter als den eigenen Nutzer einfach in der Gruppe zu platzieren die man noch so braucht. Wenn man als normaler Nutzer schon alles darf, bringen die Zugriffsrechte ja auch nichts.