nut_libusb_open get some values failed, retrying...
#1548
Comments
mcuee
added
the
question
|
Please help to provide more info -- OS, libusb version used, more info about the device, etc. |
Oh I'm sorry, this is: |
|
Again, im not sure that is issue with libusb , but if you can confirm or give a hint ? So using NUT plugin for Unraid by @desertwitch also in networkupstools/nut#2562 but : nut_libusb_open get iManufacturer failed, retrying... https://github.com/user-attachments/files/16457007/nut.log networkupstools/nut#2571 (comment) more info from developer |
|
Thanks for the link. Currently NUT does not use HIDAPI, and I don't think anyone offered to contribute code to that extent, although that would be welcome :) NUT is a libusb user since 2003 (maybe before) though, with shims to use either libusb-0.1 or 1.0 in mainline for a couple of years now, and not only HID devices in the loop. If the API concepts are similar, same shims could be expanded to cover HIDAPI, I suppose, but I am probably not the one to figure out and do it well :( Despite the years of maintainership of largely other people's code, I am sadly vague about even the terminology, so please bear with me. Back to the original topic: from what I've gathered from the logs and discussions about this issue in NUT tracker, detailed e.g. here: networkupstools/nut#2571 (comment) our driver gets the report descriptor of about 2KB in size, and walks it to interpret particular reports. While there are no issues with most of the data points, queries for these 3 identification strings return an "Input/Output Error" code.
The puzzle here is that the same approach works for most of the other devices quite well (not 100%, I occasionally do see similar reports - usually in conjunction with inadequate So I guess the question for this tracker is whether we have stumbled on some well-known gardening equipment here, "do X or don't do Y, and the ailment is gone" sort of stuff? |
|
FWIW, HIDAPI was mentioned in the NUT issue tracker... once I think - right in the thread about getting libusb-1.0 into the mainline codebase: networkupstools/nut#300 (comment) |
Are your queries control transfers for requesting the device strings? I suppose you get the same error when running examples/xusb on the device? For getting these strings from the OS instead, there is work going on in PR #1532. I think lsusb and udevadm get these string values from the udev database without sending USB requests. |
|
Thanks for the quick reply! I'll try to track down the answer to how the info is queried, though likely tomorrow (now commuting home). I would defer to @masterwishx about building and running the example program against the actual device. |
I'm here to test when needed just need @desertwitch to compile or provide me config for compile in case. BTW now using the preview build for nut plugin from master where you added pr for Eaton 9E. |
|
To build xusb and other examples: |
im using Unraid (Slackware 15) and NUT plugin for Unraid maintained by @desertwitch , so i have build.slack from his package but also need config file that he is using , but he was kindly compiled for me before for pr's by @jimklimov |
Oh do you mean for xusb, but how it will work with nut? |
|
You can run it independently of nut, to see if you can read out the device descriptor strings, or if you get some error. |
Thanks i will try |
@jimklimov do you think it can help? |
|
You should run this independently of nut, so yes, stop nut while doing these tests. |
|
Unraid v6.12.11 that I'm using has libusb v1.0.26, I think I tryed to use v1.0.27 but it's not working with current unraid version. But like I said befor Unraid 7 beta2 has libusb-1.0.27. Maybe @desertwitch also know how to debug libusb in Unraid? |
|
@masterwishx Please try 1.0.27 then. You can run "sudo make install" after the "make" above if you have the 1.0.27 or git master sources, or get it from your distribution - sometimes there are possibilities of upgrading single packages. But please test xusb as instructed above first. Then afterwards you can back to debugging nut again. |
|
Sorry I don't really have anything useful to add here nor the time to help out with further diagnosis, considering this is for the most part an optical and not a functional, road-blocking issue for you (as we've established in the various other issues and repositories this has popped up in over the past weeks). I really don't mean this in a rude way but please, for sake of general etiquette, don't tag and ping me continuously everywhere - I would chime in if I had something useful to add or time to help out. For what it's worth, the compilation process on Slackware (which is the underlying OS of Unraid) is the same as with most other distributions - no special configurations or anything are really needed (those of my packaging process are unneeded for testing). |
OK, I'm really sorry for this, but it's not only optic problem but some values not avaliable becose of it. Optic problem not important for me. Sorry again I got it. Thanks for your help |
Thanks will try |
So, by the looks of it, in the initial device identification (where we loop to check if vendorid, productid and other criteria tell us that this driver likes this device), we:
In case of The big data dump ought to be I think that's all the digging I can wrap my head around at the moment... |
have error when trying
|
|
|
|
Did you install the build toolkits? I suppose those listed in NUT |
No, I had only experience to compile in Slackware VM or same but in docker AutoSlackPack. |
it seems becose it stored container path : |
|
tryed some times but get the same , also have:
howere v 1.0.26 worked , here also have in compile last line , but no success: |
|
Do "make clean" again and this time do "make CFLAGS=-static". Then the examples/xusb binary will have libusb embedded and you can copy it over and run anywhere without libtool coming in the way. |
Thanks, I will try it |
Thanks for advice ,have this after runned : |
|
config libusb-1.0.27.log @tormodvolden please check compile logs , becose as i said befor i dont have success on compile , its just stop when: |
Or as you mentioned it seems also OK? |
|
Thanks, now I can see what is wrong: This is a bug in the device firmware. It should have returned a valid descriptor listing which languages are supported for its string descriptors. On a typical device that includes the code 0x0409 for en_US language, which would give the byte sequence 04 (length of descriptor) 03 (type of descriptor) 09 04 (0x0409 in little-endian). |
Should I check also next 4 bytes if it will help?
|
|
Yes, thanks, it would be interesting! |
|
Strange, have the same ? |
|
|
|
Seems the reply is 4 bytes long, unbothered by being given an 8-byte buffer (just not using all of it). I wonder how those other programs got the strings though - ignored bogus output and assumed English? Had some other query? There's some other option to return 8/16-bit words instead of just 8-bit we expect here?.. |
|
The Linux kernel makes great efforts to workaround buggy devices. In this case, with a broken language identifier, it will assume en_US and request the en_US version of the string descriptor. If this is important to nut, I would recommend implementing a custom version of libusb_get_string_descriptor_ascii() which falls back to en_US (or simply assumes en_US in the case of Eaton devices). |
@tormodvolden Thanks a lot for your help I think I can close the issue now... @jimklimov I hope finally we found where the bug was... |
|
I guess we can at least explore the path. I'm traveling for the bext half a month so not sure when I'd get some quality computer time though. For the sake of future versions, I hope @arnaudquette-eaton can pass the bug to firmware team. :) Kudos to @tormodvolden for helping make sense of the bytes and knowing where to find them :) |
|
On the libusb side we should maybe add a warning to make this easier to spot the next time. |
|
@arnaudquette-eaton Do you perform any USB compliance testing on the devices? |
Closes libusb#1548 Signed-off-by: Tormod Volden <[email protected]>
|
@aquette You don't have to disclose any individual company's practices :) but I am curious about what manufacturers typically would do. I thought they had to run through some standard compliance tests before they can print the USB logo on their devices. There is for instance a test program at https://www.usb.org/compliancetools#anchor_usb3cv that according to the documentation will check the langid descriptor and string descriptors among other things. |
I don't think I have any usb logo on my ups 9E2000i only usb port. :) If for real, as you can see from NUT issue it was not solved for 1.5 years until you helped, however eaton devs was there :( |
|
@masterwishx as an OSS leader and dev, I'm retired for 6 years+ @tormodvolden would need to recheck. Keep in mind that I committed all these USB related things (kernel, libusb, NUT USB driver) 20 years ago... And as for all my OSS benevolent work (despite a potential interest for my employers), once done, I moved to something else... |
|
@tormodvolden sorry to bother you again as this issue was solved and maybe need to close it ? But have other issue if it is : Mostly looks like this :
|
|
@masterwishx Yes, if you have issues with interrupt transfers I would think it is a completely unrelated issue. |
Thanks, so it's related to NUT libusb or/and I can test it also with xusb as befor? |
i opened issue networkupstools/nut#2644 or i need open here also ? |
Not sure if related to libusb , but maybe any help from here would help to recognize some values for libusb NUT for Eaton 9E UPS
networkupstools/nut#2571
networkupstools/nut#1925
The text was updated successfully, but these errors were encountered: