No permission to acces trackIR device with ltr_gui

[GoogleCodeExporter]

I have a TrackIR 5 and I tryied to use it with last linuxtrack 0.99.7.

When I run ltr_gui this message is returned :
"TrackIR device was found, but you don't have permissions to access it.
 Please install the file 51-TIR.rules to the udev rules directory"

I installed the rules file before running ltr_gui. I restarted udev service, 
and I tried to reboot as well (I followed installation from wiki).

These were my installation steps :

1. copy linuxtrack 0.99.7 into /opt/linuxtrack-0.99.7 ( + symlink to 
/opt/linuxtrack )
2. export PATH with /opt/linuxtrack/bin/
3. copy 51-TAR.rules to /lib/udev/rules.d/ and restart udev service

I do not really know why I still don't have permissions.

Original issue reported on code.google.com by c.alva...@sgzdev.net on 11 Nov 2013 at 12:45

[GoogleCodeExporter]

Hello,
can you check, that the 51-TIR.rules file really is in the /lib/udev/rules.d 
directory?

If it is there, might I ask you which distro are you using? Also, can you 
attach here the contents of log (last pane, View logfile button, if I remember 
correctly).
Kind regards,

Michal

Original comment by f.jo...@email.cz on 11 Nov 2013 at 6:09

[GoogleCodeExporter]

Thnx for your quick answer.

I double checked, 51-TIR.rules is really in my /lib/udev/rules.d/. My distro is 
the Linux Mint Debian ( based on jessie ).

Seems to really be a permission issue, my knowledge stops there.

I attached log here.

Original comment by c.alva...@sgzdev.net on 11 Nov 2013 at 9:26

Attachments:

• linuxtrack.log

[GoogleCodeExporter]

Hello,
this is strange - so far noone reported such a problem... The log doesn't show 
any problems either.
Could you try running the following in terminal?

LIBUSB_DEBUG=3 /opt/linuxtrack-0.99.7/bin/ltr_gui

It should print some messages to the terminal, that might show what is going on 
in there... If they doesn't make sense to you, please attach them here, so I 
can take a look...

One more thing - is the TrackIR plugged directly to a computer, or through some 
hub? The thing is, that when going through hub, it sometimes causes strange 
problems (especially unpowered hubs).

Kind regards,

Michal

Original comment by f.jo...@email.cz on 11 Nov 2013 at 11:05

[GoogleCodeExporter]

Ok here is the point. With more debug I get this :

libusbx: error [_get_usbfs_fd] libusbx couldn't open USB device 
/dev/bus/usb/004/002: Permission denied
libusbx: error [_get_usbfs_fd] libusbx requires write access to USB device nodes

So I tried to run ltr_gui with sudo an all worked fine, I could install the 
firmware ( I didn't tried before because I believed the rules file was there to 
avoid running sudo ).

The question is, why aren't my rights ok without sudo ? Should I have to change 
the  "/dev/bus/usb/004/002" rights directly ?

Original comment by c.alva...@sgzdev.net on 11 Nov 2013 at 2:55

[GoogleCodeExporter]

Hello,
please, be very careful with that. Only applications that are meant to be run 
with superuser privileges should be ran using sudo or by root directly; as a 
rule of thumb - anything in /bin, /sbin or /usr/sbin should be OK, all other 
programs should be kept on user level.

So please don't run anything from linuxtrack package as root, it is not worth 
the risk.

To your problem - at this point, the possibilities are narrowing; the rule 
might be overridden by some other, it might be ignored for some reason (wrong 
permissions on the rule file itself?).

So here are few more things to check (I'm looking at a way to "debug these 
rules").
  - in /lib/udev/rules.d rename the 51-TIR.rules to 99-TIR.rules (it should make sure it is last rule to take effect)
  - make sure the file is owned by user root, group root and have read/write permissions for user and the rest is read only
Kind regards,

Michal

Original comment by f.jo...@email.cz on 12 Nov 2013 at 4:01

[GoogleCodeExporter]

Hi,
did you have any luck finding the problem?
Kind regards,

Michal

Original comment by f.jo...@email.cz on 6 Dec 2013 at 5:41

[GoogleCodeExporter]

Hello,

For now I'am just running it with sudo because it works. I know it's a bad idea 
but I didn't found why rules file isn't set on device with my user account. ( 
While rights seemed to be OK for rules' file and udev demon)

Original comment by c.alva...@sgzdev.net on 6 Dec 2013 at 12:57

[GoogleCodeExporter]

Hi,
I just wrote a post at XPlane.org forum that might help you find out what is 
going on with that udev rule:

http://forums.x-plane.org/index.php?showtopic=72733#entry784444

Hope it helps,

Michal

Original comment by f.jo...@email.cz on 10 Dec 2013 at 12:22

[GoogleCodeExporter]

Seem to be usefull, I had no idea about udev debugging, I can provide more 
information then.
When I delete or put the rules file in /lib/udev/rules.d/ it is automatically 
detected and displayed, I does not return errors. The file seem to be ok. Then 
I tried connecting my tir with debbuging, I had many new information but I am 
not sure to understand all of that, so I attached the full log I the message.

What I understood is the following :

Device was detected correctly
    udev_builtin_add_property: ID_VENDOR=131d

Rules where loaded 
    udev_rules_apply_to_event: MODE 0666 /lib/udev/rules.d/99-TIR.rules:1

It created a device node ( but I don't know if it's ok )
    udev_node_add: creating device node '/dev/bus/usb/004/005', devnum=189:388, mode=01666, uid=0, gid=0

There is some other rules that were loaded, but I don't know if it generates 
any conflict.

Any idea ?

Original comment by c.alva...@sgzdev.net on 10 Dec 2013 at 7:54

Attachments:

• tir-debug.log

[GoogleCodeExporter]

Hi,
my udevd log looks very similar, the only real difference is, that mine doesn't 
have there these lines:

[123854.810481] [30970] spawn_read: '/sbin/modprobe -b 
usb:v131Dp0158d0000dc00dsc00dp00ic00isc00ip00in00'(err) 'FATAL: Module 
usb:v131Dp0158d0000dc00dsc00dp00ic00isc00ip00in00 not found.'
[123854.810703] [30970] spawn_wait: '/sbin/modprobe -b 
usb:v131Dp0158d0000dc00dsc00dp00ic00isc00ip00in00' [31177] exit with return 
code 1

Anyway, this line is exactly what we need:
[123854.778279] [30970] udev_node_mknod: set permissions /dev/bus/usb/004/005, 
021666, uid=0, gid=0

So if you go there and check the permissions, of /dev/bus/usb/004/005 (beware, 
might be different this time) - what are they? Is there read/write for others?
Kind regards,

Michal

Original comment by f.jo...@email.cz on 11 Dec 2013 at 3:59

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

it's always created with "crw-rw-rwT  1 root root"

I noticed the file always increase each time I replug the device (005, then 
006, etc)

Original comment by c.alva...@sgzdev.net on 11 Dec 2013 at 9:49

[GoogleCodeExporter]

Well, that is correct - with these permissions the device should be 
accessible...
Can you try and rerun the ltr_gui according to the post number 3? It seems to 
me, that  this is actually mix of two different problems.

One more thing that comes to my mind - if you run 'lsof | grep usb' does any 
other process have that device open? If yes, you might check with 'ps auxww' 
what process is that...

Kind regards,

Michal

Original comment by f.jo...@email.cz on 12 Dec 2013 at 3:28

[GoogleCodeExporter]

device file is not listed in the output, does this mean it is not used by any 
other process ?

Original comment by c.alva...@sgzdev.net on 13 Dec 2013 at 12:40

[GoogleCodeExporter]

Yes...

Can you try and rerun the ltr_gui according to the post number 3 and check the 
log, if there is any indication of the problem?

Kind regards,

Michal

Original comment by f.jo...@email.cz on 13 Dec 2013 at 1:07

[GoogleCodeExporter]

Greetings,

had the same problem with Crunchbang linux, another debian based distro.

Solved it by changing the udev rule to the following:
SUBSYSTEM=="usb", ATTRS{idVendor}=="131d", GROUP="adm", MODE="0666"

and adding myself to that group. 

Thanks for your work.

Original comment by arglm...@googlemail.com on 17 Jan 2014 at 11:48

[GoogleCodeExporter]

Hello,
I just tried it on the debian-mint and it turned out that there is a file 
91-permissions.rules, that was overriding the permissions set by 51-TIR.rules.
The solution is to move the 51-TIR.rules to 92-TIR.rules - it works well that 
way.

The reason the above change works too, is the fact, that it changes the default 
group, which isn't overriden and the default rules 664 give the group the right 
to access the device.

Kind regards,

Michal

Original comment by f.jo...@email.cz on 2 Feb 2014 at 2:18

[GoogleCodeExporter]

Original comment by f.jo...@email.cz on 2 Feb 2014 at 2:18

• Changed state: Started

[GoogleCodeExporter]

Confirming that the renaming from 51- to 91- fixes the issue on debian stable.

Original comment by folken...@gmail.com on 14 Nov 2014 at 3:45