Re: Still can't claim interface, "No such file or directory" SOLVED!

[Kustaa Nyholm-2]

Hi Alen,

it works now! And you were right from the beginning!
It was the set config 0 when I should have used 1.

So how did I make such a pigs breakfast of it?

I wonder too!

So I've tried to reconstruct what happened.

> I'll skip directly to the part where you ran your program:
>
>> dd0e0600 806429271 S Co:2:004:0 s 00 09 0000 0000 0000 0
>> dd0e0600 806431484 C Co:2:004:0 0 0
>
>This is the Set-Configuration request.  The trace shows that the config
>was set to 0, not 1.
>>         USB_dev_handle dev = usb_open(device);
>>         assertOk(dev != null ? 0 : NON_STD_ERR, "usb_open");
>>
>>         ret = usb_set_configuration(dev, 1);
>>         assertOk(ret, "usb_set_configuration");

>Since your program tried to set config 1, the simplest conclusion is
>that the 1 got changed to 0 somewhere between your program and the
>kernel.  Most likely in the libusb bindings.

So I go and double check the java bindings, and no, can't find anything
there. So I go to my Java code and what do I see:

         ret = usb_set_configuration(dev, 0);

What, why, how?!?! I'd doubt myself but my mail to you which
shows (as quoted above) that I used usb_set_configuration(dev, 1);
and that was an honest and true copy/paste from the very code!

So what happened? I don't know, but I noticed earlier twice that
the Eclipse editor in Linux/Ubuntu has been out of sync with the
actual files on the system. Seems to happen if Eclipse is abruptly
quit. This is strange as this never happens with Eclipse on Mac OS X
or Windows. Has to be an Eclipse 'feature', I guess.

Ok, so the code was wrong because the editor showed one
thing and the file on disk had an other thing. However this
does not explain everything, for I have tried all this before
many times.

Your suggestion:

>I suggest you work around this bug by getting rid of the
>usb_set_configuration() call and adding back the
>usb_detach_kernel_driver_np() call.

started to ring a bell. If you look at my code you'll see
(or actually you don't see, because I did not include,
darn, the assertOk function) that the code exits as
soon as there is an error. So what must have happened
was that always one way or an other I have had my
system out of sync with my thinking, ie I try one thing,
then the the detach driver call works but the set config
is wrong , I fix that but now the detach fails because
it succeeded on the first try. And so I keep running circles.
Shot myself in the foot, now I feel like an idiot, after
30 years of coding! Oh well, I always maintain that
when the going gets though the sure cure to debug
things is to publicly humiliate yourself!

Thanks again Alan for your patience and support,
you really saved the day!

One more question, what happens with those
_np (no portable) functions on non Linux platforms?
Do they exists if they do, what happens if I call them?

br Kusti

PS

to give back to the  community and for posterity here
is a summary of what works:

On Ubuntu 9.04 the udev rules in

/lib/udev/rules.d/50-udev-default.rules

need to be modified as follows, open the file with:

sudo gedit /lib/udev/rules.d/50-udev-default.rules

locate the following rule:

# libusb device nodes
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", MODE="0664"

and change that to:

# libusb device nodes
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", MODE="0666"


And here  is the complete modified code that worked for me, note that this is Java,
but it is almost verbatim the same in C:


   static USB_device findDevice(int vendor, int product, int device) {      
     int busses = usb_find_busses();

      int devices = usb_find_devices();
      USB_device thedev = null;
      for (USB_bus bus = usb_get_busses(); bus != null; bus = bus.next) {
         for (USB_device dev = bus.devices; dev != null; dev = dev.next) {
            System.out.println(dev);
            if (vendor >= 0 && vendor != (dev.descriptor.idVendor & 0xFFFF))
               continue;
            if (product >= 0
                  && product != (dev.descriptor.idProduct & 0xFFFF))
               continue;
            if (device >= 0
                  && device != (dev.descriptor.bcdDevice & 0xFFFF))
               continue;
            System.out.println((dev.descriptor.idVendor & 0xFFFF) + " "
                  + (dev.descriptor.idProduct & 0xFFFF) + " "
                  + (dev.descriptor.bcdDevice & 0xFFFF));

            return dev;
         }
      }

      return null;
   }


   static public void main(String args[]) throws Exception {
      usb_load_library();

      usb_init();

      int ret;
      byte[] tmp = new byte[1024];

      usb_set_debug(10);

      USB_device device = findDevice(0x0FDE, 0xCA01, -1); // Ohio scientific
      assertOk(device != null ? 0 : NON_STD_ERR, "findDevice");

      USB_dev_handle dev = usb_open(device);
      assertOk(dev != null ? 0 : NON_STD_ERR, "usb_open");

      ret = usb_detach_kernel_driver_np(dev, 0);
      // assertOk(ret, "usb_detach_kernel_driver_np");

      ret = usb_set_configuration(dev, 1);
      assertOk(ret, "usb_set_configuration");

      ret = usb_claim_interface(dev, 0);
      assertOk(ret, "usb_claim_interface");

      byte initString[] = { 0x20, 0x00, 0x08, 0x01, 0x00, 0x00, 0x00, 0x00 };
      ret = usb_control_msg(dev, USB_ENDPOINT_OUT | USB_TYPE_CLASS
            | USB_RECIP_INTERFACE, HID_SET_REPORT, HID_OUTPUT_REPORT,
            HID_INTERFACE, initString, 8, 5000);
      assertOk(ret, "sending hid report");

      boolean interrupted = false;
      while (!interrupted) {
         ret = usb_interrupt_read(dev, 0x81, tmp, 8, 500);
         {
            if (ret > 0) {
               for (int i = 0; i < ret; ++i)
                  System.out.printf("%02X ", tmp[i]);
               System.out.println();
            }
         }
      }

      ret = usb_release_interface(dev, HID_INTERFACE);
      assertOk(ret, "usb_release_interface");

      ret = usb_close(dev);
      assertOk(ret, "usb_close");

   }





------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Alan Stern]

On Sat, 17 Oct 2009, Kustaa Nyholm wrote:

> One more question, what happens with those
> _np (no portable) functions on non Linux platforms?
> Do they exists if they do, what happens if I call them?

They don't exist.

>       USB_dev_handle dev = usb_open(device);
>       assertOk(dev != null ? 0 : NON_STD_ERR, "usb_open");
>
>       ret = usb_detach_kernel_driver_np(dev, 0);
>       // assertOk(ret, "usb_detach_kernel_driver_np");
>
>       ret = usb_set_configuration(dev, 1);
>       assertOk(ret, "usb_set_configuration");
>
>       ret = usb_claim_interface(dev, 0);
>       assertOk(ret, "usb_claim_interface");

This code still contains a bug I mentioned before: You should call
usb_set_configuration() _before_ usb_detach_kernel_driver_np().  I'm
surprised that this works at all; the claim_interface() should fail
because the driver you detached is supposed to get re-attached during
the set_configuration call.

Alan Stern


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Xiaofan Chen]

On Sun, Oct 18, 2009 at 2:34 AM, Kustaa Nyholm
<Kustaa.Nyholm@...> wrote:
> One more question, what happens with those
> _np (no portable) functions on non Linux platforms?
> Do they exists if they do, what happens if I call them?
>

They do not exist and the call will fail. So you have
to use ifdef or things like that. For Windows, you
can manually change the default kernel driver to
libusb-win32 device driver using Device Manager
(except for 64bit Vista and Windows 7 which require
a digital signature libusb-win32 does not have yet).

>
> to give back to the  community and for posterity here
> is a summary of what works:
>
> On Ubuntu 9.04 the udev rules in
>
> /lib/udev/rules.d/50-udev-default.rules
>
> need to be modified as follows, open the file with:
>
> sudo gedit /lib/udev/rules.d/50-udev-default.rules
>
> locate the following rule:
>
> # libusb device nodes
> SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", MODE="0664"
>
> and change that to:
>
> # libusb device nodes
> SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", MODE="0666"
>

Personally I use this "lazy rule" as well and it may be fine for single-user
systems (like mine). But it might be better to use other mechanism to
only change the permission of this device.


--
Xiaofan http://mcuee.blogspot.com

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Peter Stuge-4]

Kustaa Nyholm wrote:
> Shot myself in the foot, now I feel like an idiot, after
> 30 years of coding!

It's not your fault that eclipse has bugs.


> Oh well, I always maintain that when the going gets though the
> sure cure to debug things is to publicly humiliate yourself!

The real lesson we'll all relearn is that low-level tools are really
important. usbmon identified the problem. cat of the source code
would also have shown it. I understand that the Java bindings were
suspected. All these thick layers of code make for great obfuscation
of what is actually going on in the system.

> On Ubuntu 9.04 the udev rules in
>
> /lib/udev/rules.d/50-udev-default.rules
>
> need to be modified as follows, open the file with:
>
> sudo gedit /lib/udev/rules.d/50-udev-default.rules
>
> locate the following rule:
>
> # libusb device nodes
> SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", MODE="0664"
>
> and change that to:
>
> # libusb device nodes
> SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", NAME="bus/usb/$env{BUSNUM}/$env{DEVNUM}", MODE="0666"

I agree very much with Xiaofan here. This udev rule change is fine for
development but not something I think you should recommend others to
implement.

Please provide your own .rules file instead, with a specific rule for
only your device, and which does something like set the device group
writable and owned by group console, or even sets a specific owner
for the device. Exactly what to do to make the user experience as
good as possible will depend on the user's distribution here.


//Peter

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Alan Stern]

On Sat, 17 Oct 2009, Kustaa Nyholm wrote:

> So what happened? I don't know, but I noticed earlier twice that
> the Eclipse editor in Linux/Ubuntu has been out of sync with the
> actual files on the system. Seems to happen if Eclipse is abruptly
> quit. This is strange as this never happens with Eclipse on Mac OS X
> or Windows. Has to be an Eclipse 'feature', I guess.

You ought to file a bug report about this with the Eclipse developers.

Alan Stern


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Graeme Gill]

Peter Stuge wrote:
> I agree very much with Xiaofan here. This udev rule change is fine for
> development but not something I think you should recommend others to
> implement.
>
> Please provide your own .rules file instead, with a specific rule for
> only your device, and which does something like set the device group
> writable and owned by group console, or even sets a specific owner
> for the device. Exactly what to do to make the user experience as
> good as possible will depend on the user's distribution here.

I think this points up a noticeable issue with Linux. You can't
expect an application developer to know or even figure out what
is the appropriate advice for every distribution, nor can you
expect a typical user to know what to do either. Even if the developer
half figures it out, it's still a maze of advice that will bamboozle
many (ie. see my attempt for users of my application here
<http://www.argyllcms.com/doc/Installing_Linux.html>). The only
viable course I can see for a chance smooth installation
is for the developer to create an installer that tried to
embody all the known ways that permissions and configurations need to
be tweaked to enable a USB device, but applications developers are not
likely to be experts in all the historical variations in udev syntax,
distribution variations etc. etc, so even this approach is fraught.

[There really is a lesson here in being too single minded about
the "right" technical way of doing things, and not thinking about
the application developer and end user experience.]

Graeme Gill.


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Michael Plante]

Graeme wrote:

>> I think this points up a noticeable issue with Linux. You can't
>> expect an application developer to know or even figure out what
>> is the appropriate advice for every distribution, nor can you
>> expect a typical user to know what to do either. Even if the developer
>> half figures it out, it's still a maze of advice that will bamboozle
>> many (ie. see my attempt for users of my application here
>> <http://www.argyllcms.com/doc/Installing_Linux.html>). The only
>> viable course I can see for a chance smooth installation
>> is for the developer to create an installer that tried to
>> embody all the known ways that permissions and configurations need to
>> be tweaked to enable a USB device, but applications developers are not
>> likely to be experts in all the historical variations in udev syntax,
>> distribution variations etc. etc, so even this approach is fraught.

While I usually have the luxury of using sudo instead of messing with udev
rules, the reference to historical variations and distribution variations
nevertheless makes me curious:  to what extent can autotools make udev
simpler to use?  At least superficially, it seems to be a similar problem,
but I'm largely ignorant of the details.

Michael



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Xiaofan Chen]

On Mon, Oct 19, 2009 at 8:54 AM, Graeme Gill <graeme2@...> wrote:

> I think this points up a noticeable issue with Linux. You can't
> expect an application developer to know or even figure out what
> is the appropriate advice for every distribution, nor can you
> expect a typical user to know what to do either. Even if the developer
> half figures it out, it's still a maze of advice that will bamboozle
> many (ie. see my attempt for users of my application here
> <http://www.argyllcms.com/doc/Installing_Linux.html>). The only
> viable course I can see for a chance smooth installation
> is for the developer to create an installer that tried to
> embody all the known ways that permissions and configurations need to
> be tweaked to enable a USB device, but applications developers are not
> likely to be experts in all the historical variations in udev syntax,
> distribution variations etc. etc, so even this approach is fraught.
>

I think for application developers, maybe a Wiki type article
or a summary page like yours are good.

Last time, we have a Wiki page for Piklab project
(before Sourceforge purged the old wiki). It is archived
here:
http://mcuee.blogspot.com/2009/07/piklab-wiki-page-usb-port-permission.html

Just a note about your page, SYSFS{idVendor} and SYSFS{idProduct}
are now deprecated and should be changed to
ATTR{idVendor} and ATTR{idProduct}.

Another point, I think udev-extra/devicekit is replacing PolicyKit/HAL.
But in general, the basic udev rules always work without messing
with other ways for relatively new distros, that is my experience.


--
Xiaofan http://mcuee.blogspot.com

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Peter Stuge-4]

Michael Plante wrote:
> to what extent can autotools make udev simpler to use?

Not much, as things stand.


> At least superficially, it seems to be a similar problem, but I'm
> largely ignorant of the details.

The udev problem can only be solved at deployment. This is one thing
that distributions (should) take care of themselves.

HAL and all the Kits are fine new inventions. But what if I don't
like them and my systems have neither? (Rhetorical)

A standalone udev rule file is not as good as proper distribution
integration, but as others have said, most of the time it's really
all that is needed.


//Peter

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Kustaa Nyholm-2]

>>       USB_dev_handle dev = usb_open(device);
>>       assertOk(dev != null ? 0 : NON_STD_ERR, "usb_open");
>>
>>       ret = usb_detach_kernel_driver_np(dev, 0);
>>       // assertOk(ret, "usb_detach_kernel_driver_np");
>>
>>       ret = usb_set_configuration(dev, 1);
>>       assertOk(ret, "usb_set_configuration");
>>
>>       ret = usb_claim_interface(dev, 0);
>>       assertOk(ret, "usb_claim_interface");
>
> This code still contains a bug I mentioned before: You should call
> usb_set_configuration() _before_ usb_detach_kernel_driver_np().  I'm
> surprised that this works at all; the claim_interface() should fail
> because the driver you detached is supposed to get re-attached during
> the set_configuration call.
>
> Alan Stern
>

Hi Alan,

in the interest of correctness I tried to call usb_set_configuration
before usb_detach_kernel_driver_np, but that results in device busy
error on the call to usb_set_configuration. Sort of chicken and
egg issue, eh?

I can, however, leave out the usb_set_configuration , and the code still
works (presumably it uses the sole (default) configuration on the
device), so would that be more correct?

If you are correct that usb_set_configuration should reattach the
(usbhid) driver is this (that it appears to work) just a timing issue and
and a fluke and I'm heading for trouble if I leave the usb_set_configuration
as it is now?


br Kusti



------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Alan Stern]

On Mon, 19 Oct 2009, Kustaa Nyholm wrote:

> > This code still contains a bug I mentioned before: You should call
> > usb_set_configuration() _before_ usb_detach_kernel_driver_np().  I'm
> > surprised that this works at all; the claim_interface() should fail
> > because the driver you detached is supposed to get re-attached during
> > the set_configuration call.
> >
> > Alan Stern
> >
>
> Hi Alan,
>
> in the interest of correctness I tried to call usb_set_configuration
> before usb_detach_kernel_driver_np, but that results in device busy
> error on the call to usb_set_configuration. Sort of chicken and
> egg issue, eh?

You're right; my advice was wrong.  It's an obscure situation.

usb_set_configuration() will fail unless no drivers are bound to any
interfaces in the current configuration.  (That's why you need to
detach usbhid first.)  On the other hand, if it succeeds then kernel
drivers get bound to the interfaces in the new config _only_ if the new
config is different from the old one!  (That's why you don't need to
detach usbhid afterward.)

I think it was done this way in order to support programs like yours.  
Still, it's best to program defensively.

> I can, however, leave out the usb_set_configuration , and the code still
> works (presumably it uses the sole (default) configuration on the
> device), so would that be more correct?

Yes, I think it would.  For Linux, at least.  Other operating systems
can behave differently.

> If you are correct that usb_set_configuration should reattach the
> (usbhid) driver is this (that it appears to work) just a timing issue and
> and a fluke and I'm heading for trouble if I leave the usb_set_configuration
> as it is now?

If your device had more than one configuration then you would have to
detach the kernel drivers both before and after the
usb_set_configuration() call.  That's the most general approach.  But
with only one config, it's probably best to leave that call out
entirely.

Alan Stern


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Xiaofan Chen]

On Mon, Oct 19, 2009 at 10:06 PM, Alan Stern <stern@...> wrote:
>> I can, however, leave out the usb_set_configuration , and the code still
>> works (presumably it uses the sole (default) configuration on the
>> device), so would that be more correct?
>
> Yes, I think it would.  For Linux, at least.  Other operating systems
> can behave differently.
>

For example, it is necessary to call usb_set_configuration for
Windows libusb-win32 device driver. Without calling it, the device is
left in unconfigured mode. The main reason is that the code is sharing
with libusb-win32 filter driver and it is problematic to set configuration
for the filter driver (because other driver is bound to the device).
There is a patch for this behavior but the released code is like this.


--
Xiaofan http://mcuee.blogspot.com

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel