Am Donnerstag, 6. Juni 2013, 09:52:09 schrieb Robert Kiendl:

Hi,

I guess there is a permission problem accessing the device. Under normal conditions udev is doing the permission stuff when plugging in the device. I have had once the similar issue for own compiled binary mipsbe for mikrotik and tplink devices. Because of the lack of udev is simply altered the permission after plugging the dongle (something like /dev/dvb/adapter[something] perms 755) This made it work afterwards.

Hope this info helps,

Ciao Robert, 73 de oe6rke

I have figured out the device is unter /dev/usb/001/004 and I changed the permissions from 744 to 755 but this does not change anything. rtl_test is running with root permissions.... There are only the folders block, bus, char, dsl_vr9, input, net and pts under /dev...

Maybe it is a permission problem - but I have no idea where to look.

Best regards Andreas, df8oe

Am Donnerstag, 6. Juni 2013, 16:21:25 schrieb Alan Corey:

I don't know anything about your OS, but look at the 3rd line down in your posted listing:

open("/usr/lib/freetz/librtlsdr.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)

It isn't finding the library. That same message repeats many times throughout your listing. It's not finding many libraries from looking at it again. If you're using cmake you can probably fix the paths to libraries in your CMakeCache.txt in the build directory. If not you might need to set an LDFLAGS in your environment or something.

If the process doesn't have execute permissions on all the directories in the paths it won't find anything either because it can't search there. Does it work if you run as root?

Hi Alan,

I was not using cmake because there is no cmake posible on that embedded machine. I wrote a makefile by myself and gave linkeroption for the paths of the libraries. As you see the binary tries search at different places and fails - until it finds successfully at /usr/lib/...

This repeats for all needed libraries. It is nicky - but I don't think it is critical. May be that can be figured out - but that is my first makefile for this machine.

Luckily it finds all libraries at the end.

The binary is executed as root.

For Robert tells me something about missing permissions I took a look at some permissions in /dev/usb and saw some of them are --r--r--r - no w! So I changed this permissions to -rw-rw-rw and the errors disappeared for these files. But you see there are much errors "Inappropriate ioctl for device" and many of them are still present and I can't see why.

df8oe, Andreas

Am Donnerstag, 6. Juni 2013, 21:18:25 schrieb Peter Stuge:

df8oe@gmx.de wrote:

...

when I start the software (usb-dongle connected) it throws a usb_claim_interface error -5

$ grep -- -5 src/libusb/libusb/libusb.h LIBUSB_ERROR_NOT_FOUND = -5,

From the log: (thanks)

ioctl(5, USBDEVFS_CLAIMINTERFACE, 0x7fd063c4) = -1 ENOENT (No such file or directory)

The kernel is saying that the interface doesn't exist.

lsusb -v for this device run on the fritzbox would be interesting.

Hi Peter,

here the output of lsusb -v: http://www.df8oe.de/lsusb.txt

df8oe, Andreas

Am Freitag, 7. Juni 2013, 12:37:34 schrieb Peter Stuge:

...

I think the interface cannot be opened

The interface can not be claimed because the kernel doesn't think that it exists. The error is actually really clear.

...

When I plug in the stick correspondent devices are created under /dev/usb/

USB is a packet bus with highly structured communication. Device nodes in /dev are not a good reference.

df8oe@gmx.de wrote:

...

here the output of lsusb -v: http://www.df8oe.de/lsusb.txt

Unfortunately the fritzbox has a useless mini lsusb program as opposed to the actual lsusb utility from the usbutils package. It would be great if you could build the real one.

Somewhat less effort and still interesting would be to mount debugfs and then cat /sys/kernel/debug/usb/devices

Other than that, it would be helpful if you could build a libusb binary with debug logging enabled. See http://libusb.org/wiki/debug for copypaste instructions that would apply to a host build. You must modify them as appropriate for your cross build of course.

For debugging is not enabled by default in this kernel and building a new one and/or complete lsusb, I looked for another way to get the needed information. I noticed that the debugging package "listusb" is available for the box and I build it. Here the output of listusb -v:

http://www.df8oe.de/listusb.txt

Can you see there what is going wrong?

df8oe, Andreas

Am Freitag, 7. Juni 2013, 16:44:25 schrieb Peter Stuge:

df8oe@gmx.de wrote:

...

For debugging is not enabled by default in this kernel

What is your kernel version and what is your libusb-1.0 version?

...

http://www.df8oe.de/listusb.txt

One thing that sticks out is:

wTotalLength 8704

Another is:

wMaxPacketSize 0x0002 1x 2 bytes

These clearly show an endianness problem which would more likely be in your version of libusb-1.0 than in the kernel.

//Peter

Linux version 2.6.32.41 (gcc version 4.6.3 (Buildroot 2011.11) ) #1 Fri Feb 15 15:09:13 CET 2013 mips GNU/Linux

libusb-1.0.9 http://svn.freetz.org/trunk/make/libs/libusb1/

The problem is I cannot take a "normal-standard" distribution because this is a dsl/voip/Wlan/DECT-Router working with mips-processor and I must use the installed system adding some useful components. So I choose "freetz", with is an extension for the installed software for this embedded system. Because important modules are not open source I am not free in choosing a quite different kernel eg.

But I dont give up hoping the problem can be fixed...

I have contact with the freetz-maintainers and if there is a problem in the libusb1 and I can tell them where it is - they will update to a version without the bug (??)

df8oe, Andreas

Am Samstag, 8. Juni 2013, 01:12:11 schrieb Peter Stuge:

df8oe@gmx.de wrote:

...

...

What is your kernel version and what is your libusb-1.0 version?

Linux version 2.6.32.41 (gcc version 4.6.3 (Buildroot 2011.11) ) #1 Fri Feb 15 15:09:13 CET 2013 mips GNU/Linux

This kernel version is over two years old. I don't want to think about how many THOUSAND commits there have been in the kernel since then.

Because the kernel is modified by the supplier AVM I choose an very easy possibility: I installed Debian on a Raspberry Pi and compiled rtlsdr there. It was working at the first try :) Many thanks for your replies - but I see no easy way to get the driver running on the embedded system without the risk of destroying other functions... The power consumption of the RP is not so high - so I have 2 "servers" running in my network ;)

Andreas, df8oe