tripplite_usb: match_by_unitid() rejects devices with non-zero Unit ID when `upsid` is unconfigured (v2.8.1 regression)

[jsalas-field]

Summary

match_by_unitid() in drivers/tripplite_usb.c (NUT 2.8.1, driver internal version 0.35) unconditionally compares the UPS's device-reported Unit ID against a config-derived value that silently defaults to 0 when upsid is not set in ups.conf. Since most Tripp Lite units ship with a factory-default Unit ID of 65535 (per DEFAULT_UPSID elsewhere in the same file), any user who does not explicitly set upsid = 65535 (or their actual persisted ID) in ups.conf will have their device rejected at match time, with the driver logging the unhelpful, unrelated "insufficient permissions on everything" fallback message.

This was encountered as an apparent regression after a Proxmox VE 8→9 / Debian 12→13 upgrade, where a previously-working tripplite_usb config (with no upsid set) began failing to connect to a Tripp Lite SMART500RT1U (09ae:0001).

Root cause

v2.8.1 tag, drivers/tripplite_usb.c, match_by_unitid():

char *value = getval("upsid");
int config_unit_id = 0;                 // defaults to 0, not DEFAULT_UPSID
if (value != NULL) {
    config_unit_id = atoi(value);
}

/* always queries device, regardless of whether upsid was configured */
if (tl_model != TRIPP_LITE_OMNIVS && tl_model != TRIPP_LITE_SMART_0004) {
    ret = send_cmd(u_msg, sizeof(u_msg), u_value, sizeof(u_value) - 1);
    ...
    unit_id = (int)((unsigned)(u_value[1]) << 8) | (unsigned)(u_value[2]);
}

if (config_unit_id == unit_id) {
    return 1;
} else {
    return 0;   /* rejects device: logged upstream as "Caller doesn't like this device" */
}

Compare to the current master branch, which has an early exit:

char *value = getval("upsid");
...
if (value == NULL) {
    return 1;   /* match any device — correct behavior when upsid is unconfigured */
}
...

master skips both the device query and the comparison entirely when upsid is unset. v2.8.1 does not — it always queries the device and always compares, defaulting the "expected" side of the comparison to 0. Since a UPS's actual Unit ID is essentially never 0 in practice (factory default is 65535), this makes tripplite_usb unusable out of the box for any user who hasn't explicitly set upsid in ups.conf, unless they happen to have previously set the device's Unit ID to 0 via upsrw.

It's unclear whether this was fixed in master intentionally as a bugfix (in which case it should be backported/released) or is coincidentally different for unrelated reasons — flagging both possibilities for maintainer triage.

Reproduction

Environment:

• NUT 2.8.1-5 (Debian trixie package), driver internal version 0.35
• Tripp Lite SMART500RT1U, USB 09ae:0001, binary SMART protocol (3005)
• ups.conf:

  [TrippLiteUPS]
          driver = tripplite_usb
          port = auto
          vendorid = 09ae
          productid = 0001
          pollinterval = 5

(no upsid set)

Result: driver fails to start. Debug (-DDD) trace shows the device is correctly detected, matched by VID/PID, interface claimed, and HID descriptor read successfully — then rejected immediately after a 'U' (unit ID query) command is sent, with libusb1's generic "Caller doesn't like this device" / "No matching USB/HID UPS found" / "insufficient permissions on everything" messages following. The permissions message is misleading; actual USB permissions, udev rules, and privilege drop were all confirmed working via manual driver invocation as root.

Fix: adding upsid = 65535 (the device's actual, factory-default Unit ID, confirmed via the driver's own Unit ID: 65535 debug log) to ups.conf resolves the issue immediately. Confirmed working via upsc: battery.charge: 100
ups.status: OL
ups.id: 65535
...

Suggested fix

Backport the master branch's early-exit behavior (if (value == NULL) return 1;) to the 2.8.1 release line, or otherwise ensure match_by_unitid() does not reject devices when upsid is left unconfigured. At minimum, the documentation (tripplite_usb(8)) should clearly state that upsid is effectively required in ups.conf for this driver version, since the current default behavior silently breaks matching rather than falling back to "any device."

Environment

• Host OS: Debian 13 (trixie), post Proxmox VE 8→9 upgrade
• NUT: 2.8.1-5 (Debian package)
• Driver: tripplite_usb, internal version 0.35
• Device: Tripp Lite SMART500RT1U, 09ae:0001, protocol 3005 (binary SMART)

[jimklimov]

Fair point, just one nuance: here in the upstream NUT project, there are currently no "release line" branches to backport into. There is a "tip of master branch" and historic snapshots of varying age and obsolecense, from "previous tip a couple of days ago" to "something tagged that packagers of a stable distro picked as their baseline a decade ago" (we do still get reports for NUT v2.7.4).

So backporting is a packagers' head-ache sadly - thanks for pointing out what exactly is likely to help.

CC @bigon