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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YZv55KMsuSYanfYp@rowland.harvard.edu>
Date:   Mon, 22 Nov 2021 15:13:24 -0500
From:   Alan Stern <stern@...land.harvard.edu>
To:     David Niklas <Hgntkwis@...mail.net>,
        Jiri Kosina <jikos@...nel.org>,
        Benjamin Tissoires <benjamin.tissoires@...hat.com>
Cc:     linux-kernel@...r.kernel.org, linux-usb@...r.kernel.org,
        linux-input@...r.kernel.org
Subject: Re: I need advice with UPS connection. (ping)

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.  

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 know what the full story is.  With luck, Jiri or Benjamin can 
help more.

Alan Stern