[Nut-upsdev] usbhid-ups reconnect/string-descriptor failure (issue #3531, , PowerWalker VI 850 SHL / Phoenixtec 06da:ffff) - version comparison, , offer to build+test a package

[Wolfgang Neuwirth]

Hi,

Apologies in advance for the length of this message - I wanted to lay
out the concrete version-by-version evidence rather than just assert a
conclusion, in case it's useful for triage.

Following up on issue #3531 (usbhid-ups: recurring, non-self-recovering
failure to read USB string descriptors, PowerWalker VI 850 SHL /
Phoenixtec 06da:ffff), where Jim Klimov suggested testing against a newer
NUT release than the Debian-packaged 2.8.1 I was running.

Debian Trixie (stable) currently packages nut 2.8.1-5 - the same version
I already had installed and reported the issue against. I looked through
the actual release notes between 2.8.1 and the current 2.8.5 to see
what, concretely, has changed around USB string descriptor handling and
reconnect behaviour, rather than relying on version numbers alone.
Summary below, and an offer at the end.

What changed, version by version (from the official NUT release notes):

- NUT 2.8.2 (PR #2604, issues #1925, #414): introduced
   nut_usb_get_string() with a fallback en_US query for devices reporting
   a broken LANGID. Quote from the release notes: "This notably manifested
   in inability to query the device Manufacturer, Model and Serial Number
   values with some buggy device firmware or hardware." This description
   matches my symptom (iManufacturer/iProduct/iSerialNumber read failures)
   closely.

- However, per the 2.8.5 release notes: "USB drivers could truncate
   strings received from devices as a fallout of PR #2604 merged in NUT
   v2.8.3; this should now be fixed" (PR #3211, issue #3201). So the fix
   most relevant to my symptom shipped in 2.8.2, but had its own
   regression (string truncation) that was only corrected in 2.8.5.
   Versions 2.8.2/2.8.3/2.8.4 sit in between with a different
   string-handling bug.

- NUT 2.8.2 (PR #2699): "insufficient permissions on everything" is no
   longer logged in isolation when some devices were accessible but simply
   did not match - a clarifying line is added. I saw exactly this
   potentially-misleading message in my own logs (other, unrelated USB
   devices on the bus correctly showing access-denied, which is normal and
   unrelated to the actual UPS).

- NUT 2.8.5 / current master (issue #3116): "Improved handling of
   transient LIBUSB_ERROR_IO failures during polling. Some devices
   (CyberPower, etc.) have firmware bugs causing random I/O errors on
   certain HID reports. The driver now skips failing reports and continues
   polling rather than triggering expensive reconnection attempts. True
   disconnections are still detected via other error codes or when all
   polls fail." This looks directly relevant to avoiding the kind of
   indefinite, non-recovering reconnect loop I reported, though I can't
   yet confirm it covers the exact error codes I saw (ENODEV/EPROTO/
   ESHUTDOWN during open/enumeration, not LIBUSB_ERROR_IO during
   steady-state polling).

- Master/planned 2.8.6 (PR #3423): on reconnect, success is now reported
   more visibly (not only in debug), and driver state is no longer reset
   to "quiet" while still looping to reconnect.

- Master/planned 2.8.6: the idowell-hid subdriver now explicitly
   distinguishes devices sharing the Phoenixtec vendor ID (0x06da, the
   same VID as my device) by device strings, rather than risking
   cross-matching - a sign of active, recent work in exactly this VID's
   handling.

Honest caveat: I have not been able to reproduce the original spontaneous
failure on demand (it occurred twice, ~9 days apart, with no physical
trigger, over roughly 290,000 unproductive reconnect attempts the second
time). A physical cable pull/reinsert, by contrast, has always recovered
cleanly on 2.8.1. So confirming whether 2.8.5 actually fixes the
spontaneous case is not something I can do quickly or on demand - it
would require running 2.8.5 for an extended period and waiting to see if
the failure recurs.

Offer: Debian Trixie itself only ships 2.8.1-5, so testing 2.8.5 isn't a
simple "apt upgrade" for me. I'm willing to build a local .deb package,
based on the current Debian testing/unstable nut source package
(2.8.4+really-2) with the upstream 2.8.5 source substituted in. I have a
Debian Trixie system available for this, and would install/run the result
under Proxmox VE 9.2 for an extended real-world test against this exact
hardware. One thing I can't confidently judge in advance: whether the
existing Debian patches will apply cleanly against the 2.8.5 source, or
whether they'd need actual code-level adjustment rather than just
re-basing - if it comes to that, I'd appreciate guidance or a pointer to
someone who could help with that specific step.

I have already built a small permanent diagnostic capture tool (attached:
NWA-P17_WinPower-USB-Capture_v1.0_EN.docx) for a different piece of
software on the same UPS, which uses strace against the relevant process
to keep a rolling buffer and only write incident data to disk around an
actual failure, with a size cap so it can run unattended indefinitely.
The approach and lessons learned in that document (buffer sizing,
recovery detection, avoiding false positives on routine restarts,
keeping resource overhead negligible) should translate reasonably
directly to a similar capture tool for usbhid-ups itself, to hopefully
get a proper record if the original failure recurs under 2.8.5.

Would this - building and running a 2.8.5-based package against this
specific hardware over time, with instrumented capture in place - be
useful input toward resolving the interface issue in #3531, or is there
a better-targeted way I could help?

Thank you for the work on NUT.


Best regards,
Wolfgang

-- 
Ing. Wolfgang Neuwirth
Attergaustraße 4/2
4864 Attersee am Attersee
AUSTRIA

phone (mobile): +43 (660) 6817 271
mailto: wolfgang.neuwirth at nwa.at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NWA-P17_WinPower-USB-Capture_v1.0_EN.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 13488 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/nut-upsdev/attachments/20260721/eed79ac8/attachment.docx>