[Nut-upsuser] Return on experience with an Emerson/Liebert GXT3

Discussion:

paul.chavent

2014-10-01 13:46:58 UTC

Hi.

I would like to share with you my experience on trying to use nut with a Liebert GXT3 on a Debian wheezy with nut-server 2.6.4.

Please find my observations below.

(1) I've installed the packaged version of nut-server

# aptitude install nut-server

(2) I did some tuning for my configuration

#??cat << EOF >> /etc/nut/ups.conf
user=nut
[liebert]
??????? driver=usbhid-ups
??????? port=/dev/usb/hiddev0
??????? productid=0008
EOF
#??sed -i~ -e 's/MODE=none/Mode=standalone/g' /etc/nut/nut.conf
#??cat << EOF > /etc/udev/rules.d/90-nut-ups.rules
ACTION=="add|change", SUBSYSTEM=="usb|usb_device", ATTRS{idVendor}=="10af", ATTRS{idProduct}=="0008", MODE="664", GROUP="nut"?????????????????????????????????????????????????????????????????????????????
EOF

(3) I did some tests with /lib/nut/usbhid-ups, lsusb and usbhid-dump
It doesn't work out of the box.
After some investigation, it seems that the GXT3 usb device is a bit susceptible and "crash" after some USB requests.
I used wireshark to check at the protocol level (modprobe usbmon before launching wireshark). Here is what i can say :
?- after usb cable plugin, issue an 'lsusb -v' -> after the GET DESCRIPTOR Request DEBUG, the device sends Malformed responses.
?- after usb cable plugin, issue an 'usbhid-ups ... ' -> after the SET INTERFACE Request that succeed, all subsequent GET DESCRIPTOR responses are malformed.
?- after usb cable plugin, issue an 'usbhid-dump' -> the device proudly survive
These observations would need more insight.

But as a workaround, I've commented the "usb_set_altinterface(udev, 0);" call at line 225 of the drivers/libusb.c source file.
Thanks to this hack, the driver can dialog with the device.

# upsdrvctl -u nut start
Network UPS Tools - UPS driver controller 2.6.4
Network UPS Tools - Generic HID driver 0.38 (2.7.2.5)
USB communication driver 0.32
Using subdriver: Belkin HID 0.17

(4) I tryed to launch the server either by hand or with "service nut-server start".
It doesn't work out of the box due to setuid issues (the program runs as nobody).
As we can read in the man upsdrvctl :
"This [the setuid user] may be set in ups.conf with "user" in the global section."
This is also suggested in the Q.6 of the faq.

However, the drivers/upsdrvctl.c do_upsconf_args function do not handle "user" global declaration (at least in the git repository, i haven't checked the debian patches).

So i think that either the manual or the implementation is broken.

As a workaround i added an UPSDRVCTL_OPTIONS to the /etc/init.d/nut-server scripts and set UPS*_OPTIONS to "-u nut".
Thanks to this hack, the driver and the daemon start.

# service nut-server start
[ ok ] Starting NUT - power devices information server and drivers:? driver(s). upsd.

(5) After those steps, everything "seems" to works better :

# upsc liebert at localhost
battery.charge: 99
battery.charge.low: 20
battery.charge.warning: 0
battery.type: PbAc
battery.voltage: 1.0
battery.voltage.nominal: 0.0
device.mfr: Emerson Network Power
device.model: Liebert GXT3
device.serial: 1106000077AF453
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 2
driver.parameter.port: /dev/usb/hiddev0
driver.parameter.productid: 0008
driver.version: 2.7.2.5
driver.version.data: Belkin HID 0.17
driver.version.internal: 0.38
ups.mfr: Emerson Network Power
ups.model: Liebert GXT3
ups.productid: 0008
ups.serial: 1106000077AF453
ups.status: OL CHRG
ups.vendorid: 10af

(6) Future.
I'm not sure that the subdriver is the best match for this device. What do you think about trying the liebert-hid one ?
If you haven't any solution yet, we can also discuss about a good patch for solving the "set_altinterface" issue. Any suggestions ?
And about the "user" key of the ups.conf files, can i suggest a patch for taking it into account in the drivers and the servers ?

I'm waiting for your feedback and comments.

Regards.

Paul.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: drivers_libusb_c.patch
Type: text/x-patch
Size: 363 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20141001/7983d1ca/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: etc_init.d_nut-server.patch
Type: text/x-patch
Size: 871 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20141001/7983d1ca/attachment-0001.bin>

Charles Lepple

2014-10-02 01:03:21 UTC

Permalink

Post by paul.chavent
(3) I did some tests with /lib/nut/usbhid-ups, lsusb and usbhid-dump
It doesn't work out of the box.
After some investigation, it seems that the GXT3 usb device is a bit susceptible and "crash" after some USB requests.
- after usb cable plugin, issue an 'lsusb -v' -> after the GET DESCRIPTOR Request DEBUG, the device sends Malformed responses.
- after usb cable plugin, issue an 'usbhid-ups ... ' -> after the SET INTERFACE Request that succeed, all subsequent GET DESCRIPTOR responses are malformed.
- after usb cable plugin, issue an 'usbhid-dump' -> the device proudly survive
These observations would need more insight.
But as a workaround, I've commented the "usb_set_altinterface(udev, 0);" call at line 225 of the drivers/libusb.c source file.
Thanks to this hack, the driver can dialog with the device.

We independently ran across problems with the usb_set_altinterface() call. The plan is to remove it before 2.7.3 is released:

https://github.com/networkupstools/nut/issues/138

That issue also includes an override setting, so if I can't get any other testers, I plan to merge it as-is.

Post by paul.chavent
# upsdrvctl -u nut start
Network UPS Tools - UPS driver controller 2.6.4
Network UPS Tools - Generic HID driver 0.38 (2.7.2.5)
USB communication driver 0.32
Using subdriver: Belkin HID 0.17
(4) I tryed to launch the server either by hand or with "service nut-server start".
It doesn't work out of the box due to setuid issues (the program runs as nobody).

It should run as user "nut" in Debian. You may want to reinstall the nut-server package, and check the post-inst error messages to make sure that the "nut" user is created, and that it is in the "nut" group as well.

Post by paul.chavent
"This [the setuid user] may be set in ups.conf with "user" in the global section."
This is also suggested in the Q.6 of the faq.
However, the drivers/upsdrvctl.c do_upsconf_args function do not handle "user" global declaration (at least in the git repository, i haven't checked the debian patches).

Not sure that is where the "user" declaration is being parsed. upsdrvctl just passes arguments to the drivers via the command line (including "-u", although that is not read from the configuration file, but from upsdrvctl's command line).

Post by paul.chavent
So i think that either the manual or the implementation is broken.

Can you show us the exact configuration syntax you are using?

Post by paul.chavent
(6) Future.
I'm not sure that the subdriver is the best match for this device. What do you think about trying the liebert-hid one ?

You are welcome to try the liebert-hid subdriver, but it does not look similar.

There are some fixes that were added in 2.6.4 to try and work around incorrect exponents in the voltages. You can try starting the usbhid-ups driver directly, adding "-DDD" to see if any messages are logged about "assuming correction factor =". It could be that we did not cover all the different ways those values could be wrong.

--
Charles Lepple
clepple at gmail

paul.chavent

2014-10-02 01:03:21 UTC

Permalink

Post by Charles Lepple
https://github.com/networkupstools/nut/issues/138
That issue also includes an override setting, so if I can't get any other testers, I plan to merge it as-is.

Ok, great.

Post by Charles Lepple
It should run as user "nut" in Debian. You may want to reinstall the nut-server package, and check the post-inst error messages to make sure that the "nut" user is created, and that it is in the "nut" group as well.

The user nut and the group nut have been created..

Post by Charles Lepple
Not sure that is where the "user" declaration is being parsed. upsdrvctl just passes arguments to the drivers via the command line (including "-u", although that is not read from the configuration file, but from upsdrvctl's command line).

https://github.com/networkupstools/nut/blob/master/drivers/upsdrvctl.c#L60

I'm quite sure that it is the place where the config file is parsed...

And the init script of the debian package don't explicitly append "-u nut" in wheezy. See the attached patch in my first message.

Post by Charles Lepple
Can you show us the exact configuration syntax you are using?

8<-----/etc/nut/ups.conf------
user = nut

[liebert]
??? driver = usbhid-ups
??? port = /dev/usb/hiddev0
??? productid = 0008
8<----------------

Post by Charles Lepple
There are some fixes that were added in 2.6.4 to try and work around incorrect exponents in the voltages. You can try starting the usbhid-ups driver directly, adding "-DDD" to see if any messages are logged about "assuming correction factor =". It could be that we did not cover all the different ways those values could be wrong.

Ok, i will give it a try.

Regards.

Paul.

Charles Lepple

2014-10-02 12:39:20 UTC

Permalink

Post by paul.chavent

The user nut and the group nut have been created..

Ah, right, because you are using the Debian upsdrvctl with a hand-compiled driver. I would recommend copying the whole Debian ./configure line, including the part that sets the default user and group to "nut".

Post by paul.chavent

https://github.com/networkupstools/nut/blob/master/drivers/upsdrvctl.c#L60
I'm quite sure that it is the place where the config file is parsed...

What I should have said is that upsdrvctl is not where the "user = " is being interpreted (although you are correct, it is parsed and ignored). I was thinking of this line in the driver core:

https://github.com/networkupstools/nut/blob/master/drivers/main.c#L295

Post by paul.chavent
And the init script of the debian package don't explicitly append "-u nut" in wheezy. See the attached patch in my first message.

Since we don't ship that init file in the generic NUT source package anymore, that will need to be discussed with the Debian maintainers - probably at http://bugs.debian.org

Post by paul.chavent

Post by Charles Lepple
Can you show us the exact configuration syntax you are using?

8<-----/etc/nut/ups.conf------
user = nut
[liebert]
driver = usbhid-ups
port = /dev/usb/hiddev0
productid = 0008
8<----------------

Ok, i will give it a try.
Regards.
Paul.

--
Charles Lepple
clepple at gmail

paul.chavent

2014-10-03 11:50:08 UTC

Permalink

Post by Charles Lepple

Post by paul.chavent

The user nut and the group nut have been created..

Post by paul.chavent

https://github.com/networkupstools/nut/blob/master/drivers/upsdrvctl.c#L60
I'm quite sure that it is the place where the config file is parsed...

https://github.com/networkupstools/nut/blob/master/drivers/main.c#L295

Post by paul.chavent
And the init script of the debian package don't explicitly append "-u nut" in wheezy. See the attached patch in my first message.

Since we don't ship that init file in the generic NUT source package anymore, that will need to be discussed with the Debian maintainers - probably at http://bugs.debian.org

My bad. The user global directive is parsed by the driver, not by the upsdrvctl. And the debian init script doesn't need any changes, my settings had been messed up. All is working out of the box now.
Hopefully, you know the code better than me :)

Post by Charles Lepple

Post by paul.chavent

I've tried both belkin-hid and liebert-hid drivers. You can finds logs of the belkin-hid in attachment. I don't see any "assuming correction factor =" messages.

However. Could you give me some more hints please ?

(1) appart the liebert_line_voltage and liebert_config_voltage functions, i don't see any differences in the belkin-hid and liebert-hid drivers.
Why not move all liebert related functions in the liebert-hid driver ?

(2) i don't understand how the driver selection is done ? if i just add the vendorid/productid to the liebert_usb_device_table, the lookup seems to stop in the belkin driver (perhaps because belkin_claim got "possibly supported" and that the "productid" value is present ?).
How do you suggest to implement the addition of this device ?
(for my tests, i commented the belkin lookup entry to force the usage of the liebert one).

(3) in the hid report, we have several items with the same name (see attached lsusb dump).
How it is handled by the lookup table ? Is there any indexing possible ?

(4) would it be usefull to add missing items to the driver's hid to nu lookup table (even in the the unmapped part) ? Do you recommend me to work on the liebert or on the belkin file ?

Thanks for your help.

Regards.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: usbhid-ups-belkin-driver.log
Type: text/x-log
Size: 30906 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20141003/92c08dfd/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lsusb.log
Type: text/x-log
Size: 14129 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20141003/92c08dfd/attachment-0003.bin>

Charles Lepple

2014-10-03 13:42:49 UTC

Permalink

Post by paul.chavent
Hi

...

Post by paul.chavent

I've tried both belkin-hid and liebert-hid drivers. You can finds logs of the belkin-hid in attachment. I don't see any "assuming correction factor =" messages.

This is what I was referring to (from the belkin-hid log):

1.325782 Report[buf]: (5 bytes) => 05 53 00 48 00
1.325799 Path: UPS.PowerSummary.ConfigVoltage, Type: Feature, ReportID: 0x05, Offset: 16, Size: 16, Value: 0
1.325814 ConfigVoltage = 0 -> assuming correction factor = 1e+08

You may need to bump the debug level to 5 to see the full exponent processing (cf get_unit_expo() in libhid.c). Please gzip the log - it will be big.

Post by paul.chavent
However. Could you give me some more hints please ?
(1) appart the liebert_line_voltage and liebert_config_voltage functions, i don't see any differences in the belkin-hid and liebert-hid drivers.
Why not move all liebert related functions in the liebert-hid driver ?

I would prefer not to move things around too much, unless we can get people to test the other models. I realize it is annoying that the subdriver names do not match the brands, but the idea is that the matching happens automatically.

Post by paul.chavent
(2) i don't understand how the driver selection is done ? if i just add the vendorid/productid to the liebert_usb_device_table, the lookup seems to stop in the belkin driver (perhaps because belkin_claim got "possibly supported" and that the "productid" value is present ?).
How do you suggest to implement the addition of this device ?
(for my tests, i commented the belkin lookup entry to force the usage of the liebert one).

Right, in usbhid-ups.c, the liebert_subdriver entry is after the belkin_subdriver.

Post by paul.chavent
(3) in the hid report, we have several items with the same name (see attached lsusb dump).
How it is handled by the lookup table ? Is there any indexing possible ?

I will have more time to look at this later, but at a quick glance, I did not see what you were referring to (the lsusb dump, while comprehensive, is hard to parse). Bear in mind that many vendors duplicate Input and Feature HID elements.

Post by paul.chavent
(4) would it be usefull to add missing items to the driver's hid to nu lookup table (even in the the unmapped part) ?

Sure, although the unmapped entries are just for debugging - we will want to eventually rename them to official NUT names, or comment them out again before checking the driver in to version control.

Post by paul.chavent
Do you recommend me to work on the liebert or on the belkin file ?

Probably belkin-hid.

Post by paul.chavent
Thanks for your help.

Thanks for testing!

--
Charles Lepple
clepple at gmail

paul.chavent

2014-10-06 07:31:58 UTC

Permalink

???? 1.325782??? Report[buf]: (5 bytes) => 05 53 00 48 00
???? 1.325799??? Path: UPS.PowerSummary.ConfigVoltage, Type: Feature, ReportID: 0x05, Offset: 16, Size: 16, Value: 0
???? 1.325814??? ConfigVoltage = 0 -> assuming correction factor = 1e+08
You may need to bump the debug level to 5 to see the full exponent processing (cf get_unit_expo() in libhid.c). Please gzip the log - it will be big.

See attachment

OK, i suppose that this issue will be solved when all the liebert devices will be moved in the liebert-hid driver, in the future.

Post by paul.chavent
(3) in the hid report, we have several items with the same name (see attached lsusb dump).
How it is handled by the lookup table ? Is there any indexing possible ?

Please find in attachment the hid report descriptor : there are several Charging/Discharging fields.
I'm wondering if it gives the status of the different (additional) battery composing the system ?

Post by paul.chavent
(4) would it be useful to add missing items to the driver's hid to nu lookup table (even in the the unmapped part) ?

Sure, although the unmapped entries are just for debugging - we will want to eventually rename them to official NUT names, or comment them out again before checking the driver in to version control.

Is there a list of all official NUT names (i haven't searched yet) ?

Cheers.

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: hid-report-descriptor-fields.txt
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20141006/c2aee3db/attachment-0001.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: usbhid-ups.log.gz
Type: application/x-gzip
Size: 19758 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20141006/c2aee3db/attachment-0001.bin>

Charles Lepple

2014-10-06 13:04:45 UTC

Permalink

Post by paul.chavent
Hi

1.325782 Report[buf]: (5 bytes) => 05 53 00 48 00
1.325799 Path: UPS.PowerSummary.ConfigVoltage, Type: Feature, ReportID: 0x05, Offset: 16, Size: 16, Value: 0
1.325814 ConfigVoltage = 0 -> assuming correction factor = 1e+08
You may need to bump the debug level to 5 to see the full exponent processing (cf get_unit_expo() in libhid.c). Please gzip the log - it will be big.

See attachment

I think I see what is going on.

0.368670 Report[buf]: (5 bytes) => 05 4e 00 48 00
0.368698 PhyMax = 0, PhyMin = 0, LogMax = 1, LogMin = 0
0.368723 Unit = 00000000, UnitExp = 0
0.368747 Exponent = 0
0.368776 Path: UPS.PowerSummary.Voltage, Type: Feature, ReportID: 0x05, Offset: 0, Size: 16, Value: 0
0.368805 Input/OutputVoltage = 0 -> assuming correction factor = 1e+07

offset 0, size 16 in Report[buf] is '4e 00' (0x004e == 78) but LogMax is 1 (and it should be 0xffff to match the size).

This is annoying, because it means that we can't simply scale the values. I don't know of an easy way to fix this, short of adding a way to override the HID Report Descriptor.

While we're here, does a battery voltage of 72V nominal sound reasonable for your unit?

Post by paul.chavent

OK, i suppose that this issue will be solved when all the liebert devices will be moved in the liebert-hid driver, in the future.

I'm not sure I understand why we would want do this. We really have two different "Liebert" cases: the rebranded Phoenixtec hardware (which basically complies with the HID PDC spec, although does not provide much information), and the buggy Liebert/Belkin hardware. Call it inertia or laziness, but combining the two means lots of extra testing to make sure we do not break existing device support.

Post by paul.chavent

Post by paul.chavent
(3) in the hid report, we have several items with the same name (see attached lsusb dump).
How it is handled by the lookup table ? Is there any indexing possible ?

Please find in attachment the hid report descriptor : there are several Charging/Discharging fields.
I'm wondering if it gives the status of the different (additional) battery composing the system ?

If so, they are not reporting the presence of such a battery:

0.428188 Report[buf]: (2 bytes) => 0c 05
0.428215 PhyMax = 0, PhyMin = 0, LogMax = 1, LogMin = 0
0.428240 Unit = 00000000, UnitExp = 0
0.428264 Exponent = 0
0.428290 hid_lookup_path: 00840004 -> UPS
0.428316 hid_lookup_path: 00840024 -> PowerSummary
0.428344 hid_lookup_path: 008500d1 -> BatteryPresent
0.428373 Path: UPS.PowerSummary.BatteryPresent, Type: Input, ReportID: 0x0c, Offset: 4, Size: 1, Value: 0

Post by paul.chavent

Post by paul.chavent
(4) would it be useful to add missing items to the driver's hid to nu lookup table (even in the the unmapped part) ?

Sure, although the unmapped entries are just for debugging - we will want to eventually rename them to official NUT names, or comment them out again before checking the driver in to version control.

Is there a list of all official NUT names (i haven't searched yet) ?

http://www.networkupstools.org/docs/developer-guide.chunked/apas01.html

--
- Charles Lepple
http://ghz.cc/charles/

paul.chavent

2014-10-10 10:44:16 UTC

Permalink

Hi

On 10/06/2014 03:04 PM, Charles Lepple wrote:> I think I see what is going on.

???? 0.368670??? Report[buf]: (5 bytes) => 05 4e 00 48 00
???? 0.368698??? PhyMax = 0, PhyMin = 0, LogMax = 1, LogMin = 0
???? 0.368723??? Unit = 00000000, UnitExp = 0
???? 0.368747??? Exponent = 0
???? 0.368776??? Path: UPS.PowerSummary.Voltage, Type: Feature, ReportID: 0x05, Offset: 0, Size: 16, Value: 0
???? 0.368805??? Input/OutputVoltage = 0 -> assuming correction factor = 1e+07
offset 0, size 16 in Report[buf] is '4e 00' (0x004e == 78) but LogMax is 1 (and it should be 0xffff to match the size).
This is annoying, because it means that we can't simply scale the values. I don't know of an easy way to fix this, short of adding a way to override the HID Report Descriptor.
While we're here, does a battery voltage of 72V nominal sound reasonable for your unit?

Yes, that's it.

Post by paul.chavent
OK, i suppose that this issue will be solved when all the liebert devices will be moved in the liebert-hid driver, in the future.

Ok, i didn't understand the purpose of the liebert-hid driver.
Moreover, I don't see any problem with the actual code organization, I'd just need to understand.

Post by paul.chavent
Please find in attachment the hid report descriptor : there are several Charging/Discharging fields.
I'm wondering if it gives the status of the different (additional) battery composing the system ?

???? 0.428188??? Report[buf]: (2 bytes) => 0c 05
???? 0.428215??? PhyMax = 0, PhyMin = 0, LogMax = 1, LogMin = 0
???? 0.428240??? Unit = 00000000, UnitExp = 0
???? 0.428264??? Exponent = 0
???? 0.428290??? hid_lookup_path: 00840004 -> UPS
???? 0.428316??? hid_lookup_path: 00840024 -> PowerSummary
???? 0.428344??? hid_lookup_path: 008500d1 -> BatteryPresent
???? 0.428373??? Path: UPS.PowerSummary.BatteryPresent, Type: Input, ReportID: 0x0c, Offset: 4, Size: 1, Value: 0

Yes the presence of the battery isn't reported as i expected.

Post by paul.chavent

Post by Charles Lepple

Post by paul.chavent
(4) would it be useful to add missing items to the driver's hid to nu lookup table (even in the the unmapped part) ?

Sure, although the unmapped entries are just for debugging - we will want to eventually rename them to official NUT names, or comment them out again before checking the driver in to version control.

Please find attached the patches i have applied to the current master.

Post by paul.chavent
Is there a list of all official NUT names (i haven't searched yet) ?

http://www.networkupstools.org/docs/developer-guide.chunked/apas01.html

Thank you.

Paul.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-drivers-fix-possible-memory-leak.patch
Type: text/x-patch
Size: 637 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20141010/97f15d8c/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-drivers-add-Liebert-GXT3-device.patch
Type: text/x-patch
Size: 2475 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20141010/97f15d8c/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-drivers-Liebert-GXT3-workaround.patch
Type: text/x-patch
Size: 652 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20141010/97f15d8c/attachment-0005.bin>