I created a pull request #27 which is fixing the issue.

# nut-scanner -qNU
[nutdev1]
        driver = "usbhid-ups"
        port = "auto"
        vendorid = "051D"
        productid = "0002"
        product = "Back-UPS ES 700G FW:871.O2 .I USB FW:O2"
        serial = "5B1243T01934"
        vendor = "APC"
        bus = "002"

from nut.

On Apr 25, 2013, at 9:42 AM, Christian Wiese wrote:

I created a pull request #27 which is fixing the issue.

nut-scanner -qNU

[nutdev1]
driver = "usbhid-ups"
port = "auto"
vendorid = "051D"
productid = "0002"
product = "Back-UPS ES 700G FW:871.O2 .I USB FW:O2"
serial = "5B1243T01934"
vendor = "APC"
bus = "002"

My main concern: why are spaces getting added in the first place? Is this coming from a strange version of libusb? (A quick look at the nut-scanner source code didn't show any obvious reasons.)

Ref: #26 (comment)

from nut.

I doubt that it is a "strange version of libusb". I am using libusb 1.0.9 which was build from vanilla sources without any additional patches. Everything (including toolchain) is build from sources, so no third-party binary packages are involved. I also checked the official libusb git repository if there is a fix which might be related to libusb adding trailing spaces but as expected I didn't find anything about such an issue.
What if libusb doesn't take care at all if there a trailing spaces when reading device information taking the gathered infos as they are?
When doing a lsusb -v the "iProduct" and "iSerial" of that APC UPS is including the trailing spaces too, whereas other connected devices don't.

from nut.

On Apr 29, 2013, at 9:21 AM, Christian Wiese wrote:

I doubt that it is a "strange version of libusb". I am using libusb 1.0.9 which was build from vanilla sources without any additional patches.

Hmm. Just for completeness, which version of libusb-compat?

What if libusb doesn't take care at all if there a trailing spaces when reading device information taking the gathered infos as they are?

That's what is confusing me. Spaces are apparently not treated specially anywhere in libusb-1.0, libusb-compat, or NUT. USB descriptors tend to have explicit lengths, too. I'm concerned this is masking some off-by-one error.

On the other hand, I don't want to be too pedantic about this. I'm fine with merging this for now, possibly with a note in the documentation in case someone in the future figures out what is really going on.

@aquette or @balooloo : are either of you working on nut-scanner?

Ref: #26 (comment)

from nut.

Well - I didn't checked if I am using latest libusb-compat so until now every test was done using libusb-compat 0.1.3.
I updated to the latest libusb-compat 0.1.4 and rebuild nut without the patch for trimming trailing spaces, but the results are the same when running nut-scanner -qU.

product = "Back-UPS ES 700G FW:871.O2 .I USB FW:O2 " <-- one trailing space
serial = "5B1243T01934 " <-- two trailing spaces

Just in case I also rebuilt usbutils to check the output of lsusb -v again, and it shows the same amount of trailing spaces.

from nut.

I'm also inclined toward a FW bug.
Iirc, I created this rtrim for another such USB bug, so go ahead and merge
the pull request if you have time Charles.

Cheers

(sent from my eeePad... please excuse my brevity)
Le 1 mai 2013 03:05, "Christian Wiese" [email protected] a écrit :

Well - I didn't checked if I am using latest libusb-compat so until now
every test was done using libusb-compat 0.1.3.
I updated to the latest libusb-compat 0.1.4 and rebuild nut without the
patch for trimming trailing spaces, but the results are the same when
running nut-scanner -qU.

product = "Back-UPS ES 700G FW:871.O2 .I USB FW:O2 " <-- one trailing
space
serial = "5B1243T01934 " <-- two trailing spaces

Just in case I also rebuilt usbutils to check the output of lsusb -vagain, and it shows the same amount of trailing spaces.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/26#issuecomment-17263663
.

from nut.

Unfortunately I have only this UPS for testing purposes right now. It might makes sense to ask people on the nut mailinglist if they can send the result nut-scanner -qU if they have the same APC UPS.

from nut.

Is there any interest in merging the fix or call it workaround? Are you interested at all in patches from third-parties?

from nut.

@morfoh I didn't realize you weren't going to ask the mailing list about the results of running the nut-scanner command against this UPS. I suppose we can just merge this, and point people to this thread if they have problems.

from nut.

Closed via pull request #27.

from nut.

@clepple Sorry. When I tried to subscribe to the mailing list for actually being able to ask for nut-scanner results, the confirmation mails from mailman have been held back by some stupid central spam filter. After asking the responsible administrator several times to solve that issue, I gave up to bother him and most probably simply forgot about it. C'est la vie ;)
Anyway thanks a lot for merging!

from nut.

Just a note, if any problems arise with this pull, I've got a unit with the same symptoms and can test from now until it dies. Found this issue since Fedora 19 doesn't have the latest release yet apparently...

Output I get:

[nutdev1]
driver = "usbhid-ups"
port = "auto"
vendorid = "051D"
productid = "0002"
product = "Back-UPS RS 1500 FW:8.g8 .D USB FW:g8 "
serial = "JB0407002372 "
vendor = "American Power Conversion"
bus = "004"

from nut.