Eaton 9PX Resource unavailable, HID length mismatch

[desertwitch]

I have an Unraid user reporting their newly purchased Eaton 9PX fails to be detected.
He's tried NUT versions 2.7.4 up until Network UPS Tools 2.8.4.39-39+g009fbbd1b.
He's tried various USB ports, cables, hubs - all without success.

[ups]
driver = usbhid-ups
port = auto
debug_min = 6

[nutdev-usb1]
	driver = "usbhid-ups"
	port = "auto"
	vendorid = "0463"
	productid = "FFFF"
	product = "Eaton 9PX"
	serial = "REMOVED"
	vendor = "EATON"
	# bus = "001"
	# device = "012"
	# busport = "003"

We can see the following on every driver startup in their logs:

Oct 19 08:56:04 Serveur rc.nut:    0.354822#011[D2:132754] Checking device 7 of 8 (0463/FFFF)
Oct 19 08:56:04 Serveur rc.nut:    0.355709#011[D2:132754] - VendorID: 0463
Oct 19 08:56:04 Serveur rc.nut:    0.355710#011[D2:132754] - ProductID: ffff
Oct 19 08:56:04 Serveur rc.nut:    0.355710#011[D2:132754] - Manufacturer: EATON
Oct 19 08:56:04 Serveur rc.nut:    0.355711#011[D2:132754] - Product: Eaton 9PX
Oct 19 08:56:04 Serveur rc.nut:    0.355711#011[D2:132754] - Serial Number: REMOVED
Oct 19 08:56:04 Serveur rc.nut:    0.355712#011[D2:132754] - Bus: 001
Oct 19 08:56:04 Serveur rc.nut:    0.355712#011[D2:132754] - Bus Port: 011
Oct 19 08:56:04 Serveur rc.nut:    0.355713#011[D2:132754] - Device: 004
Oct 19 08:56:04 Serveur rc.nut:    0.355713#011[D2:132754] - Device release number: 0202
Oct 19 08:56:04 Serveur rc.nut:    0.355714#011[D2:132754] Trying to match device
Oct 19 08:56:04 Serveur rc.nut:    0.355714#011[D2:132754] match_function_subdriver (non-SHUT mode): matching a device...
Oct 19 08:56:04 Serveur rc.nut:    0.355715#011[D3:132754] match_function_regex: matching a device...
Oct 19 08:56:04 Serveur rc.nut:    0.355716#011[D2:132754] Device matches
Oct 19 08:56:04 Serveur rc.nut:    0.355717#011[D2:132754] Reading configuration descriptor 1 of 1
Oct 19 08:56:04 Serveur rc.nut:    0.355721#011[D3:132754] libusb_kernel_driver_active() returned 0: Success
Oct 19 08:56:04 Serveur rc.nut:    0.355729#011[D2:132754] Claimed interface 0 successfully
Oct 19 08:56:04 Serveur rc.nut:    0.355730#011[D3:132754] nut_libusb_set_altinterface: skipped libusb_set_interface_alt_setting(udev, 0, 0)
Oct 19 08:56:04 Serveur rc.nut:    0.355878#011[D2:132754] Retrieved HID descriptor (expected 9, got 9)
Oct 19 08:56:04 Serveur rc.nut:    0.355879#011[D3:132754] HID descriptor, method 1: (9 bytes) => 09 21 10 01 21 01 22 5f 12
Oct 19 08:56:04 Serveur rc.nut:    0.355880#011[D3:132754] HID descriptor length (method 1) 4703
Oct 19 08:56:04 Serveur rc.nut:    0.355881#011[D3:132754] HID descriptor, method 2: (9 bytes) => 09 21 10 01 21 01 22 84 04
Oct 19 08:56:04 Serveur rc.nut:    0.355882#011[D3:132754] HID descriptor length (method 2) 1156
Oct 19 08:56:04 Serveur rc.nut:    0.355882#011[D1:132754] Eaton device v2.02. Using full report descriptor
Oct 19 08:56:04 Serveur rc.nut:    0.355883#011[D2:132754] Warning: two different HID descriptors retrieved (Reportlen = 4703 vs. 1156)
Oct 19 08:56:04 Serveur rc.nut:    0.355884#011[D2:132754] HID descriptor length 4703
Oct 19 08:56:04 Serveur rc.nut:    0.355886#011[D2:132754] Unable to get Report descriptor: Resource temporarily unavailable

Not sure what to make of this, so hoping someone else has any ideas, maybe the HID descriptor length trips it up?
Found (similar?) issue #1983 (which seems to have a similar Resource temporarily unavailable error, although intermittent).

[jimklimov]

CC @arnaudquette-eaton - this should be up your alley?

My semi-educated guess is that useful report descriptors are about 800 bytes long. There were some devices with a couple dozen datapoints in under 300 bytes, but that is a stretch on how useful that monitoring is with so little data reported.

I think (gotta check when near a computer) that when we see two possible lengths (per different formulas), the driver picks a longer one assuming the short one is bogus. Here 4+KB is unusually long and seems more bogus to me than 1KB :-)

I am not sure if it ever tries to fall back to the rdlen variant it did not try first. Maybe a few lines to do so would be the solution?

[desertwitch]

Thanks for the response, Jim.
Seems like the logic comes from this piece of code:

nut/drivers/libusb0.c

Lines 622 to 632 in 2ad2346

	/* when available, always choose the second value, as it
	seems to be more reliable (it is the one reported e.g. by
	lsusb). Note: if the need arises, can change this to use
	the maximum of the two values instead. */
	if ((curDevice->VendorID == 0x463) && (curDevice->bcdDevice == 0x0202)) {
	upsdebugx(1, "Eaton device v2.02. Using full report descriptor");
	rdlen = rdlen1;
	}
	else {
	rdlen = rdlen2 >= 0 ? rdlen2 : rdlen1;
	}

Perhaps this device would need a similar override or indeed we should do some sanity-checking (upper bounded?).

[jimklimov]

Well, I don't think anything forbids there being hundreds of data points (that would be quite welcome, when valid).

I think there should be a fallback to try the other rdlen, and it may be not there yet.

[jimklimov]

Posted a PR with "fallback to try the other rdlen" (essentially, runs a loop over an array of one or two unique length values, populated in an opinionated order) - testing welcome :)

[desertwitch]

Posted a PR with "fallback to try the other rdlen" (essentially, runs a loop over an array of one or two unique length values, populated in an opinionated order) - testing welcome :)

Apologies, this must've gotten lost in my inbox, I'll try to get the user to test it.