On 2020-01-03, Marcos Madeira | Secure Networks <[email protected]>
wrote:
> Hello misc,
>
> I am looking to use several Riello UPSs of model IPG 800 DE with OpenBSD
> through the nut port. These UPSs also go by the name iPlug. This is a
> compact UPS with only a single USB-B connector for connectivity as is
> usual with low-end UPSs. However, I am facing an obstacle due to how
> OpenBSD is discovering the UPS via the USB interface.
First: it may actually just be providing a RS232->USB bridge, in which
case there is a chance that NUT may be able to talk to it using some
serial protocol on the ucom device provided by ucycom, rather than via
the USB protocol. So it maybe worth experimenting with that first.
Otherwise:
> From my readings, the UPS should have been discovered as an ugen device,
> but it is being discovered as ucycom0, which uses uhidev (Human
> Interface Device), so it is just a virtual device. The device
> information is the following:
Depending on what NUT needs to do to talk to this device it may be enough
to just disable ucycom. For a quick test you can do this manually at the
boot loader: "boot -c", "disable ucycom", "quit".
If not then you can try building a kernel with this added to the
usb_quirks[] table in usb_quirks.c which would knock it out of attaching
to uhid (in which case you shouldn't need to do anything to disable
ucycom).
{ { USB_VENDOR_CYPRESS, USB_PRODUCT_CYPRESS_USBRS232, ANY, { UQ_BAD_HID }},
> 1. dmesg
>
> # dmesg
(it's always better to include full rather than trimmed dmesg)
> uhidev0 at uhub1 port 2 configuration 1 interface 0 "Cypress
> Semiconductor USB to Serial" rev 2.00/0.01 addr 2
> uhidev0: iclass 3/0
> ucycom0 at uhidev0
> ucom0 at ucycom0 portno 0
> 2. USB information as per NUT
>
> # ktrace /usr/local/bin/riello_usb -a ups -u root -DDDDDDDD
>
> 0.087109 Checking device (04B4/5500) (001/002)
> 0.107117 - VendorID: 04b4
> 0.107274 - ProductID: 5500
> 0.107525 - Manufacturer: Cypress Semiconductor
> 0.107758 - Product: USB to Serial
> 0.107964 - Serial Number: unknown
> 0.108207 - Bus: 001
> 0.108425 - Device release number: 0001
> 0.108624 Trying to match device
> 0.108862 Device matches
> 0.109309 nut_usb_set_altinterface: skipped
> usb_set_altinterface(udev, 0)
> 0.113138 HID descriptor, method 1: (9 bytes) => 09 21 11 01 00 01
> 22 25 00
> 0.113300 HID descriptor length (method 1) 37
> 0.113553 i=0, extra[i]=09, extra[i+1]=21
> 0.113810 HID descriptor, method 2: (9 bytes) => 09 21 11 01 00 01
> 22 25 00
> 0.114051 HID descriptor length (method 2) 37
> 0.114289 HID descriptor length 37
> 0.121122 Report descriptor retrieved (Reportlen = 37)
> 0.121376 Found HID device
> 0.121860 send_to_all: SETINFO ups.vendorid "04b4"
> 0.122051 send_to_all: SETINFO ups.productid "5500"
> 0.122414 send_to_all: SETINFO device.type "ups"
> 0.122645 send_to_all: SETINFO driver.version "2.7.4"
> 0.122908 send_to_all: SETINFO driver.version.internal "0.03"
> 0.123132 send_to_all: SETINFO driver.name "riello_usb"
> 0.123364 entering start_ups_comm()
> 0.127118 send: features report ok
> 0.127656 USB: Send_USB_Packet: send_usb_packet, err = -78
> Function not implemented
> 0.127826 Cypress_command send: err -78
> 0.128023 riello_command err: -78
> 0.128251 Get identif err: read byte: -78
> 0.128500 No communication with UPS
>
> 3. When running the usbhid-ups binary like '2.', nut just skips over the
> device with the message 'Device does not match - skipping'
>
> According to the following, the VENDOR:PRODUCT_ID has been reserved for
> a long time to "Cypress CY7C637xx and CY7C640/1xx series USB to RS232
> bridges":
They're microcontrollers that can do various USB things depending on
how they're programmed.
> Am I out of luck in connecting this to OpenBSD as not cycom by default
> and without disabling both cycom and uhidev (including keyboard, mouse,
> ...)? I have seen Stuart's recommendation on the nut-upsuser lists, but
> is there something that needs to be done on OpenBSD kernel to prevent
> this from happening taking into consideration users of cycom? I am not
> too familiar with the usb part of the kernel.
>
> https://alioth-lists.debian.net/pipermail/nut-upsuser/2014-September/009224.html
>
> Thank you for your consideration,
>
In all honesty, if it needs to be done via USB, I would probably stick
it on an rpi running linux and use NUT's network support if you need to
signal OpenBSD boxes.