Re: I need advice with UPS connection. (ping)

On Tue, 23 Nov 2021 17:33:08 +0100
Benjamin Tissoires [off-list ref] wrote:

On Mon, Nov 22, 2021 at 10:35 PM Filipe Laíns [off-list ref]
wrote:

quoted

On Mon, 2021-11-22 at 15:13 -0500, Alan Stern wrote:  

quoted

On Mon, Nov 22, 2021 at 11:25:26AM -0500, David Niklas wrote:  

quoted

Ok, I first edited the kernel to return -ENOMEM like you
suggested but the UPS still disconnected. I then edited it again
to re-add the 1060 byte request and the UPS still disconnected.

I'm attaching the usbmon traces.
If you need any additional info I'll do my best to provide it.  

Holy cow!  I just realized what's going on.  And these little
changes we've been messing around with have nothing to do with it.

For the first time, I looked at the timestamps in the usbmon
traces.  It turns out that the disconnects occur several seconds
after the kernel retrieves the HID report descriptor from the
device.  Under normal conditions we would expect to see report
packets coming in from the device, starting just a fraction of a
second after the descriptor is received.  But that isn't happening
in the Linux traces, whereas it does happen in the Windows pcap log.

I would guess that the UPS is programmed to disconnect itself
electronically from the USB bus if it doesn't get any requests for
reports within a couple of seconds.  That certainly would explain
what you've been seeing.  I can't imagine why it would be
programmed to behave this way, but companies have been known to do
stranger things.

As for why the kernel doesn't try to get the reports...  That's a
little harder to answer.  Maybe Jiri or Benjamin will know
something about it.  

I am not sure exactly what is going on there.
There are a couple of things that come to my mind:
- for quite some time now, we don't fetch all reports whenever we
connect a new device. This was known to be problematic on some devices
(see all the devices with HID_QUIRK_NOGET or
HID_QUIRK_NO_INIT_REPORT), and the default to not poll input values on
plug for devices is actually safer. If you want to revert, we will
have to have a special driver for this one I guess
- HID_QUIRK_ALWAYS_POLL *might* be a way to force the device to stay
with a USB connection up.

quoted

quoted

The UPS's vendor ID is 0d9f (POWERCOM) and the product ID is 0004.
Now, the drivers/hid/hid-quirks.c file contains a quirk entry for
0d9f:0002 (product POWERCOM_UPS), which is probably an earlier
model of the same device, or a very similar device.  This quirk
entry is in the hid_ignore_list; it tells the HID core not to
handle the device at all.

I don't know why that quirk entry is present, and furthermore, it
can't directly affect what is happening with your device because
the product IDs are different.  Still, it is an indication that
something strange is going on behind the scenes.

Perhaps there is no kernel driver for these UPS devices?  Perhaps
the intention is that some user program will handle all the
communication when one of them is detected?  A quick search on
Google turns up usbhid-ups, part of Network USB Tools (NUT) --
maybe you need to install that package in order to use the device.  

I don't have enough experience with UPS here to be helpful,
unfortunately. But What Alan said made a lot of sense. Maybe the NUT
people will have a better insight.

<snip>

I'll send a message their way.

Thanks,
David