Forum: PC Hard- und Software libftd2xx unter Linux, Rechtefrage


von Felix Adam (Gast)


Lesenswert?

Hallo Forum,


ich habe wie bei FTDI angegeben die libftd2xx.so.1.3.2 und die ... .a in 
den usr/local/lib/ und den /usr/lib/ Ordner gepackt und danach per make 
-B die Beispiele gebaut.

Nach den beiden Befehlen
  sudo rmmod ftdi_sio
  sudo rmmod usbserial

dann ausprobiert.

Leider scheint es so zu sein, dass die Rechte für diese Zugriffsart nur 
root überlassen werden. ein "sudo ./read" listet die Infos aus dem 
angeschlossenen FT232RL auf, während ein "./read" das hier liefert:

Library version = 0x10306
Opening port 0
FT_Open(0) failed

Die beiden "libftd2xx.so.1.3.2" haben (ich weiß, falscher Weg) ein chmod 
777 bekommen. Aber selbst so ist ein Zugriff nur mit "sudo ./read" 
möglich.

Dann habe ich der Lib die Gruppe "dialout" gegeben und dem Programm 
"read" auch. Leider ändert das auch nichts an dem root-Rechtevorbehalt.

Weiß jemand, wie man das Problem lösen kann? OS ist Linux Mint 18.1 in 
einer Virtualbox VM. Eine andere Zugriffsart per VCP kommt nicht 
infrage, da es mir um den Direct Access Mode geht, später für einen 
FT2232 mit höherer Datenrate in synchronem Modus.


Danke schonmal.

von Georg A. (georga)


Lesenswert?

Änder die 777 für die Libs mal lieber wieder auf 644  ;)

Nachdem die Lib im Userspace läuft, braucht sie trotzdem eine Methode, 
um auf die HW/USB zu kommen. Und das wird wohl das übliche 
Kernelinterface sein, das auch libusb nutzt. Damit das als non-root 
geht, braucht es normalerweise wiederum udev-Regeln, die ein "rohes" 
Device nach dem Anstecken für bestimmte Benutzer explit erlauben. 
Ungefähr so wie hier:

http://robots.mobilerobots.com/wiki/Linux_udev_USB_Device_Permissions_Configuration

Allerdings kenne ich jetzt Mint nicht, evtl. gehts da etwas anders.

von Martin H. (mahi)


Lesenswert?

Nachdem die Version der Biliothek ausgegegen wird, ist es wohl kein 
Rechteproblem beim Zugriff auf die Bibliothek, sondern auf das Device.

dialout betrifft wahrscheinlich nur VCP...

von Jemand (Gast)


Lesenswert?

Es würde nahe liegen, dass dein Benutzer einfach keinen ausreichenden 
Zugriff auf das Gerät hat. Um das dauerhaft zu beheben, kannst du eine 
udev-Regel für dein Gerät anlegen.
So sieht beispielsweise die mitgelieferte udev-Regel eines ST-LINK aus:
1
/etc/udev/rules.d/49-stlinkv2.rules
2
3
# stm32 discovery and evaluation boards, with onboard st/linkv2
4
5
SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="3748", MODE:="0666"                                                    
6
                                                                                                                                      
7
# If you share your linux system with other users, or just don't like the                                                             
8
# idea of write permission for everybody, you can replace MODE:="0666" with                                                           
9
# OWNER:="yourusername" to create the device owned by you, or with                                                                    
10
# GROUP:="somegroupname" and mange access using standard unix groups.
Die Vendor- und Product-ID bekommst du mit "lsusb". Anschließend mit 
"udevadm control --reload-rules" die Regeln neu laden und das Gerät neu 
verbinden.

von Felix Adam (Gast)


Lesenswert?

Danke für die Tipps.

Rechte der lib zunächst zurückgeändert auf Ursprung (755). Dann die 
udev-Regel abgeändert auf:

SUBSYSTEM=="usb", ATTR{idVendor}=="0403", ATTR{idProduct}=="6001",
    MODE :="0660"

(habe es aber auch mit SUBSYSTEMS und ATTRS ausprobiert, ebenfalls kein 
Unterschied)

Danach noch mit MODE:="0666". Aber auch keine Wirkung.

User wurde der Gruppe dialout hinzugefügt (geprüft in /etc/group, ist 
vorhanden).

Leider geht es weiterhin nicht für Nutzer außer root :-(. Ich probiere 
das dann gleich mal unter Debian, obwohl LM derzeit meine Wahl Nr. 1 
ist...


Erstmal danke.

von Georg A. (georga)


Lesenswert?

Du musst das Gerät ab- und wieder anstecken, damit die Änderungen 
wirksam werden.

von Felix Adam (Gast)


Lesenswert?

Ist auch nach jeder Änderung passiert ;-). Soviel ist mir schon bewusst.

Aber ich suche mal nach einem Beispiel, in dem ein Skript von der Regel 
aufgerufen wird. So könnte ich testen, ob die Regel wirklich aufgerufen 
wird. Test wäre, einen Text in eine Datei schreiben lassen.


Nebenbei habe ich auch unter Debian den Zugriff getestet. Aber auch hier 
geht es nur als root. Leider steht das im FTDI-Dokument auf Seite 6 auch 
nicht anders ....

http://www.ftdichip.com/Support/Documents/AppNotes/AN_220_FTDI_Drivers_Installation_Guide_for_Linux.pdf

Ich glaube, ich muss einen eigenen Treiber schreiben, um diese 
Rechte-"Lücke" zu überbrücken.

von Felix Adam (Gast)


Lesenswert?

So, die Regel wurde umgeschrieben:

SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", 
RUN+="/home/felix/test.sh"

mit test.sh:
1
#!/bin/sh
2
echo "Hallo" >> /home/felix/test.txt

bei jedem Dranstecken vom FTDI wird jetzt ein Hallo an test.txt 
angehängt. Geht zuverlässig wie es scheint.

Jetzt noch abgeändert auf:

SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", 
MODE="0777"

(0777 zu Testzwecken!). Geht aber trotzdem nur für root, nicht für 
andere User :-(

von Georg A. (georga)


Lesenswert?

Ruf doch das Testprogramm mal mit strace auf. Da sollte man doch sehen, 
an welcher Stelle es scheitert...

von Felix Adam (Gast)


Lesenswert?

So, eine Lösung ist diese (wenn auch unschön weil auf einen User 
festgenagelt):

SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001",
OWNER="felix"

Dasselbe mit Group wie hier scheint auch zu laufen (mit felix in der 
Gruppe "dialout"):

SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001",
GROUP="dialout"

Diese beiden Dinge muss ich unter Linux Mint noch ausprobieren!



Damit die eigentlichen VCP-Treiber nicht stören, kann man diese in die 
Datei

/etc/modprobe.d/fbdev-blacklist.conf (debian)
/etc/modprobe.d/blacklist.conf (Linux Mint (ausprobiert))

eintragen in der Form:

blacklist ftdi_sio
blacklist usbserial


Achtung:
Das hat sicherlich einen Effekt auf alle FTDI-Devices. Eine Mischung aus 
VCP und D2XX unter Linux geht (wohl) nicht.


strace kenne ich noch nicht. Wie nutzt man das? (nur der Ergänzung 
halber für diesen Beitrag)

von Georg A. (georga)


Lesenswert?

Felix Adam schrieb:
> strace kenne ich noch nicht. Wie nutzt man das? (nur der Ergänzung
> halber für diesen Beitrag)

strace <binary> <arguments>

Das zeigt alle Systemcalls, deren Parameter und deren Ergebnis an, auch 
in Bibliotheken. Damit sieht man gerade bei so unklaren Fällen, wann zB. 
ein Permission Denied zurückkommt oder wo es klemmt (blocking read, 
...). Oder an welchen obskuren Orten Konfigurationsfiles etc. gesucht 
und gefunden werden...

Gibt dazu noch ltrace, das auch Bibliothek-Calls ausgibt.

: Bearbeitet durch User
von Felix Adam (Gast)


Lesenswert?

Das ist klasse, wusste ich bislang nicht.


Ich habe außerdem unter Linux Mint weiter getestet, hier lässt sich die 
udev-Regel aber nicht zur Funktion bewegen :-(.

Es gibt zwei rules-Ordner:

/etc/udev/rules.d/ (leer)
/lib/udev/rules.d/ (viel drin)

Egal wo ich meine .rules-Datei ablege, hier passiert einfach nix...
Ich probiere mal noch etwas weiter. Scheint aber dann doch auf ein 
anderes Linux hinaus zu laufen. Doofe Sache.

von Felix Adam (Gast)


Lesenswert?

Die Installation von Linux Mint scheint buggy in Virtualbox. Plötzlich 
ging sudo nano nicht mehr, weil ich angeblich keine Berechtigung mehr 
hatte, jetzt ist udevadm weg?!?

Ich probiere das mal in einem System außerhalb einer VM und melde mich 
dann wieder.

von Felix Adam (Gast)


Lesenswert?

Also, es geht auch unter Linux Mint.

Die udev-Regel muss so aussehen:

ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", 
ATTRS{idProduct}=="6001", OWNER="felix"

oder so:

ACTION=="add", SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", 
ATTRS{idProduct}=="6001", GROUP="dialout"


Wenn man dann noch ftdi_sio und usbserial in die Blacklist unter 
/etc/modprobe.d/blacklist.conf eingetragen hat, dann ist der Zugriff per 
ftd2xx auch unter Linux Mint (18.1) möglich.

Bin happy :-).

Danke für den Udev-Rules- und udevadm-Tipp. Der hat viel Zeit gespart. 
strace kommt jetzt bei der Anwendungsentwicklung sicherlich ab und an 
zum Zuge.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.