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

[David Niklas]

On Tue, 23 Nov 2021 17:33:08 +0100
Benjamin Tissoires <benjamin.tissoires@xxxxxxxxxx> wrote:

> On Mon, Nov 22, 2021 at 10:35 PM Filipe Laíns <lains@xxxxxxxxxxxxx>
> wrote:
> >
> > On Mon, 2021-11-22 at 15:13 -0500, Alan Stern wrote:  
> > > On Mon, Nov 22, 2021 at 11:25:26AM -0500, David Niklas wrote:  
> > > > 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.
> 
> > >
> > > 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