Eaton 9E2000I unknown device and ups model

[masterwishx]

Using Unraid apcd working fine , but tryed plugin -NUT - Network UPS Tools by SimonFair . and having some valus unknow like model and device and missing serial number ...

[masterwishx]

https://github.com/SimonFair/NUT-unRAID/

[jimklimov]

Looking at that repo, "3 weeks ago" they added commits for a nut-2.8.0 bump, and https://github.com/SimonFair/NUT-unRAID/blob/master/packages/nut-2.8.0-x86_64-1.txz which contains files time-stamped 2022-04-30 (so same week as NUT 2.8.0 release). Your screenshots indicate a much older 2.7.4 NUT baseline. Wondering if an update can provide a quick fix, or if something remains to solve in the core.

Also, looking at integration changes like https://github.com/dmacias72/NUT-unRAID/pull/1/files I suppose there is a lot of unRAID-specific voodoo that is maintained outside of NUT and without cross-coordination as the two evolve (which could be welcome). In NUT, each driver and sub-driver has a lot of changes over time and is responsible for the info it publishes - doing this job well or poorly is another matter, to solve in NUT. External projects are sort of expected to use NUT-provided data "as is", or if they know there's a specific issue to solve - to update NUT and have good inputs this way. Changes like that PR do make sense technically, but I'm afraid can sum up to something less maintainable over time.

[jimklimov]

BTW, did apcd report anything about this device, that you don't see with NUT - e.g. the serial number? It may well be that the device does not serve it, or serves a useless value like a dozen of zeroes.

The device.model: unknown 2000 suggests to me that in fact the driver did get some string from libusb which talks to the actual device, so either some info got lost along the way or the device firmware was not sure what to say (the same firmware builds may be applied to different hardware, so maybe that box could not be identified by its controller for whatever reason).

[jimklimov]

CC @aquette @dzomaya : any ideas here? :)

[masterwishx]

that you don't see with NUT - e.g. the serial number

Yes it was show all data also serial number. But here no serial number and ups.productid=ffff

This is my first expirience of UPS so I'm little confused, I was thinking will be opposite, that apcd was not sure, but it found device and show all info.

[masterwishx]

they added commits for a nut-2.8.0 bump

i will check it,Thanks

[masterwishx]

Checked nut 2.80 ,but still unknown

[jimklimov]

Product ID may be ffff validly, if that's what the vendor put into the chip. I don't see Vendor ID in your screenshots (should be 0x0463). Some vendors put bogus values into the latter (0000, 0001, FFFF) which indeed do not help discern expected supported protocols etc. for those devices.

I can only guess that this device serves its serial number (and possibly correct name) on different USB report identifiers than its siblings... the mapping in NUT can be updated, but gotta figure out to what.

Are you in position to run NUT from command line on that system? (Or attach the UPS to another system temporarily for debugging?)

[masterwishx]

@jimklimov do you mean if I can run command line in Unraid? Sure I can. Or you mean install nut from command line? it's more complicated becose after reboot it's gone, so there is plugins that installs every boot, but it's possible in also in script I think.

I can switch back to apcd and get all info needed. I also have slave machine I need to connect, Main pc with Win11.

[masterwishx]

So I can connect to Main pc with Win11 if need, or just get all data from apcd in Unraid?

[jimklimov]

I think all the bits of info would help, and also an attempt to start the driver with higher debug verbosity -DDDDDD on command line, which should print out many "Path" lines from basic USB report descriptors that it finds. From those we can try to estimate IDs that are missing in current driver.

If it is possible to try building NUT from source to the extent of trying to make an usb-hid subdriver (see docs directory in github), that would even parse such findings into C mapping tables that we can merge with existing subdriver.

[masterwishx]

@jimklimov This is from default UPS in Unraid APCUPSD: Also found that remain time is more acurate here

if serial is needed i can send you in pm ...

[masterwishx]

Also much less details here ...

[masterwishx]

@jimklimov tryed to launch in command line in Unraid but having some errors, maybe you can help with this, if will not succeed with command line will try maybe build and connect in VM if possible...

[jimklimov]

FYI: I'll be mostly offline till mid-May. Good luck on your quest!

On Fri, Apr 28, 2023, 11:19 DaRK AnGeL @.***> wrote:

@jimklimov https://github.com/jimklimov tryed to launch in command line in Unraid but having some errors, maybe you can help with this, if will not succeed with command line will try maybe build and connect in VM if possible...

— Reply to this email directly, view it on GitHub https://github.com/networkupstools/nut/issues/1925#issuecomment-1527252848, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMPTFEY4O2DBTATHBWHA7TXDODSZANCNFSM6AAAAAAXIRS3LM . You are receiving this because you were mentioned.Message ID: @.***>

[masterwishx]

At all it's working fine, the only problem it's shows unknown 2000 ups.model,device.model and no serial number...

[aquette]

Hey I assume it's usbhid-ups which, as noted by Jim, can't retrieve all strings. Could you share a debug log of the driver? Using something like this should do it usbhid-ups -DDDDD -s test -d2

Also, an lsusb -vv as root could help

[masterwishx]

usbhid-ups -DDDDD -s test -d2

Sure I can, I will try...

[masterwishx]

runned 'lsusb -vv' it shows all info also serial number !

Bus 003 Device 002: ID 0463:ffff MGE UPS Systems UPS
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x0463 MGE UPS Systems
  idProduct          0xffff UPS
  bcdDevice            2.02
  iManufacturer           1 EATON
  iProduct                2 Eaton 9E
  iSerial                 4 Gxxxxxxxxxx7  ( hiden by me can send in pm if needed)
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0022
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower               20mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              0 
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.10
          bCountryCode           33 US
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength    1014
         Report Descriptors: 
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval              20
can't get debug descriptor: Resource temporarily unavailable
Device Status:     0x0001
  Self Powered

[masterwishx]

@aquette is it enough ?

[aquette]

I also need the output of usbhid-ups, to see what's wrong

[masterwishx]

also need the output of usbhid-ups, to see what's wrong

Ah OK, it should be run when nut is running? I tryed but having some errors..

[aquette]

First, stop the real driver, then launch the above command as root

[masterwishx]

@aquette tryed 'usbhid-ups -DDDDD -s test -d2 -x port=auto -u root 2>&1 | tee -a /mnt/user/DiskNas/usbhid-ups.txt' usbhid-ups.txt lsusb.txt

[masterwishx]

@jimklimov @aquette please check the files above .... let me know if this is enough ?

[masterwishx]

@jimklimov @aquette did you had time to check files maybe ?

[masterwishx]

@jimklimov @aquette is any news maybe ?

[jimklimov]

Sorry about the delay. The reports do indeed look puzzling a bit: while lsusb seems to say a lot (including the device iProduct and iSerial fields), the driver does not see them from get-go:

   0.289960 [D2] Checking device 8 of 9 (0463/FFFF)
   0.311147 [D1] nut_libusb_open get iManufacturer failed, retrying...
   0.332348 [D1] nut_libusb_open get iManufacturer failed, retrying...
   0.353600 [D1] nut_libusb_open get iManufacturer failed, retrying...
   0.374780 [D1] nut_libusb_open get iProduct failed, retrying...
   0.395962 [D1] nut_libusb_open get iProduct failed, retrying...
   0.417222 [D1] nut_libusb_open get iProduct failed, retrying...
   0.438631 [D1] nut_libusb_open get iSerialNumber failed, retrying...
   0.460000 [D1] nut_libusb_open get iSerialNumber failed, retrying...
   0.481267 [D1] nut_libusb_open get iSerialNumber failed, retrying...
   0.481286 [D2] - VendorID: 0463
   0.481291 [D2] - ProductID: ffff
   0.481296 [D2] - Manufacturer: unknown
   0.481301 [D2] - Product: unknown
   0.481306 [D2] - Serial Number: unknown
   0.481311 [D2] - Bus: 003
   0.481316 [D2] - Device: unknown
   0.481321 [D2] - Device release number: 0202
   0.481344 [D2] Trying to match device

which I am not sure why happens. But maybe it is this "unknown" string that leaks into the dstate collection about the device:

   4.052224 [D1] Path: UPS.Flow.[4].ConfigApparentPower, Type: Feature, ReportID: 0x74, Offset: 16, Size: 16, Value: 2000
...
   5.509746 [D2] get_model_name(unknown, 2000)
   5.509752 [D2] comparing with: ellipse 300
...
   5.510187 [D5] send_to_all: SETINFO ups.mfr "Eaton"
   5.510194 [D5] send_to_all: SETINFO ups.model "unknown 2000"
   5.510202 [D5] send_to_all: SETINFO ups.vendorid "0463"
   5.510209 [D5] send_to_all: SETINFO ups.productid "ffff"
   5.510214 [D2] Report descriptor retrieved (Reportlen = 2053)
   5.510219 [D2] Found HID device
   5.510227 [D1] Detected a UPS: unknown/unknown 2000
...
   6.669136 [D5] send_to_all: SETINFO device.mfr "Eaton"
   6.669144 [D5] send_to_all: SETINFO device.model "unknown 2000"

UPDATE: yep, the method is unique to mge-hid.c and all the implicated logic is here:

• https://github.com/networkupstools/nut/blob/3a8deafcac9fbb755e3e9ec0cee2c13ca5dca39a/drivers/mge-hid.c#L1545-L1558

So the problem is very likely due to that original "libusb can't get the details", which may be a permissions problem or the device being busy due to someone else grabbing it with higher priority (hypervisor, OS drivers and daemons, etc.)

[jimklimov]

Just in case: are the udev.rules (or udev.hwdb) issues ruled out? Does the OS know to not grab certain VID:PID pairs and/or to re-own them to nut:nut or similar accounts?

[masterwishx]

Just in case: are the udev.rules (or udev.hwdb) issues ruled out? Does the OS know to not grab certain VID:PID pairs and/or to re-own them to nut:nut or similar accounts?

Thanks a lot for answer. about label you gave , im running and tested on v2.8.0 not v2.7.4 in unraid .

from usbhid-ups.txt:

So the problem is very likely due to that original "libusb can't get the details", which may be a permissions problem or the device being busy due to someone else grabbing it with higher priority (hypervisor, OS drivers and daemons, etc.)

The strange thing i can see all info when running ' lsusb -vv ' :

Just in case: are the udev.rules (or udev.hwdb) issues ruled out? Does the OS know to not grab certain VID:PID pairs and/or to re-own them to nut:nut or similar accounts?

i will try to check or will ask developer of plugin for Unraid ...

[masterwishx]

From plugin Developer: These are my udev rules, mainly plugin related:

root@computenode:~# cd /etc/udev/rules.d/ root@computenode:/etc/udev/rules.d# ls 70-persistent-net.rules 99_persistent_unassigned.rules 99_persistent_usb_manager.rules root@computenode:/etc/udev/rules.d# cat # PCI device 0x8086:0x15f3 (igc) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?", ATTR{address}=="d8:bb:c1:8c:c9:b0", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth", NAME="eth0" ACTION=="add", KERNEL=="sd", ENV{DEVTYPE}=="disk" RUN+="/usr/local/emhttp/plugins/unassigned.devices/scripts/rc.unassigned hotplug >/dev/null 2>&1 & disown" ACTION=="add", KERNEL=="sd", ENV{DEVTYPE}=="partition" RUN+="/usr/local/emhttp/plugins/unassigned.devices/scripts/rc.unassigned mount >/dev/null 2>&1 & disown" ACTION=="remove", KERNEL=="sd" ENV{DEVTYPE}=="disk" RUN+="/usr/local/emhttp/plugins/unassigned.devices/scripts/rc.unassigned reload >/dev/null 2>&1 & disown" ACTION=="remove", KERNEL=="sd" ENV{DEVTYPE}=="partition" RUN+="/usr/local/emhttp/plugins/unassigned.devices/scripts/rc.unassigned reload >/dev/null 2>&1 & disown" ACTION=="change", KERNEL=="sd", ENV{DEVTYPE}=="partition" RUN+="/usr/local/emhttp/plugins/unassigned.devices/scripts/rc.unassigned reload >/dev/null 2>&1 & disown" ACTION=="add",SUBSYSTEM=="usb",ENV{DEVTYPE}=="usb_device",RUN+="/usr/local/emhttp/plugins/usb_manager/scripts/rc.usb_manager usb_add >/dev/null 2>&1 & disown" ACTION=="remove",SUBSYSTEM=="usb",ENV{DEVTYPE}=="usb_device",RUN+="/usr/local/emhttp/plugins/usb_manager/scripts/rc.usb_manager usb_remove >/dev/null 2>&1 & disown" ACTION=="add",SUBSYSTEM=="tty",RUN+="/usr/local/emhttp/plugins/usb_manager/scripts/rc.usb_manager tty_add >/dev/null 2>&1 & disown"root@computenode:/etc/udev/rules.d#

[masterwishx]

this is my rules:

[masterwishx]

should be my model included in driver.list ? cant find 9E model in list ...

[masterwishx]

@jimklimov so the problem is becose 9E is missing in driver.list?

[jimklimov]

No, that list is for humans and nut-website rendered reports, AFAIK. The important part should be the vendorid and productid received from usb chip (and earon/mge/powerware are long known IDs) which also make their way into udev rules and similar configs, and the strings it tells to libusb (or here - does not tell due to something, hence "unknown" fallback).

[masterwishx]

OK, so anything I can do from my side? Like I said befor, if I'm using builded in Unraid - Apc UPS deamon, its shows all info. But I like more the Nut becose of a lot detailed info in it.

[jimklimov]

Interesting point: is the other daemon stopped when you are trying with NUT?

[jimklimov]

The udev.rules file is generated during NUT build based on driver sources available. It would have same info (in udev markup) as e.g. https://github.com/networkupstools/nut/blob/master/scripts/upower/95-upower-hid.hwdb - a lot more than you posted above.

FWIW, a good moment to check if unRaid uses actually udev or some other implementation (devd, upower, ...) to manage device node access rights etc.

[masterwishx]

no files at hwdb.d :

Do you mean this ? its founded vendor (0463) and id (ffff)

[masterwishx]

Interesting point: is the other daemon stopped when you are trying with NUT?

Sure, I stopped apc ups, befor installing nut plugin, otherwise it will not work....

[jimklimov]

Can you check what user apcd ran as? Maybe that is different from what nut build there wants, and got baked into OS configs somehow?

Are programs executed directly, or is there some redirection into containers involved, etc?

[masterwishx]

Can you check what user apcd ran as? Maybe that is different from what nut build there wants, and got baked into OS configs somehow? OK i will check ...

Are programs executed directly, or is there some redirection into containers involved, etc?

NO containers, Apcd is Unraid Native now but was plugin befor i think . NUT is the Plugin for Unraid and its intstalled directy.

All the plugins that installed in Unraid , saved on flash . so when server boot from Flash they initialing (installing) befor dockers starts.

So they both directly installed . as you can see at end they get GID 218 etc...

[jimklimov]

As a quick check: can you see who "owns" the device node for the UPS? e.g.:

# ps -ef | grep usbhid
nut        10928       1  0 May09 ?        00:07:36 /usr/local/ups/bin/usbhid-ups -FF -a eco650

# ls -la /proc/10928/fd | grep usb
lrwx------ 1 root root 64 Jun 29 11:37 8 -> /dev/bus/usb/003/005

### This process is the only one accessing the device (not sure if system-level
### delegations into VMs/containers would show up like this though):

# fuser /dev/bus/usb/003/005
/dev/bus/usb/003/005: 10928

# lsof /dev/bus/usb/003/005
COMMAND     PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
usbhid-up 10928  nut    8u   CHR 189,260      0t0 1346 /dev/bus/usb/003/005

### Note same "003/005" as for the UPS attached to this system as seen via lsusb:
# lsusb | grep 463
Bus 003 Device 005: ID 0463:ffff MGE UPS Systems UPS

# ls -la /dev/bus/usb/003/005
crw-rw-r-- 1 root nut 189, 260 Jun 29 11:37 /dev/bus/usb/003/005
### Note the "nut" group above, as assigned by udev

[masterwishx]

As a quick check: can you see who "owns" the device node for the UPS? e.g.:

[masterwishx]

@jimklimov in my case its "root"

[jimklimov]

Thanks. So, to summarize: even though the driver is running as root, and maybe there are no competitors (who is 6609? was it somehow fuser itself or something else?), libusb in usbhid-ups won't tell the basic iProduct etc. fields used during matching and which lsusb does see, but the driver sees further info from the actual protocol query/response.

So a sort of sideways solution could be to ensure these values (if "unknown") by querying something additionally over USB HID protocol, if the device serves those data points.

But the primary direct solution would be to find out why they are "unknown" in the first place and avoiding that. And documenting in how-to's for posterity.

[masterwishx]

i found 6609 its smb deamon , maybe its used becose of netserver ups mode in my case , im using for Windows client (my Main PC)

[masterwishx]

from plugin developer question "What does udevadm info /dev/bus/usb/003/002 show for you." it shows all the info!

[jimklimov]

I've picked "Ask the audience" :)

Maybe someone else on the mailing lists knows linux/libusb guts better to help here...

[SimonFair]

@jimklimov @masterwishx Let me know if you me to check stuff on Unraid side.

Libusb vers

    libusb-1.0.so.0 (libc6,x86-64) => /usr/lib64/libusb-1.0.so.0
    libusb-1.0.so (libc6,x86-64) => /usr/lib64/libusb-1.0.so
    libusb-0.1.so.4 (libc6,x86-64) => /usr/lib64/libusb-0.1.so.4