[Nut-upsdev] USB comms dropout not detected

[Arjen de Korte]

Citeren Daniel O'Connor <doconnor op gsoft.com.au>:

> I have an MGE Ellipse 1000 connected to a FreeBSD 7.1 system and it
> works well except that if I yank the cable it doesn't detect a
> problem.. It seems to quite merrily read the old data (upsc reports the
> same values).

That means that the driver doesn't see this and assumes it is business  
as usual. Not so good.

> There is nothing logged by NUT to indicate comms is lost (usbhid-ups is
> still running).
>
> In the attached log I yanked the able at the 28 second mark and plugged
> it back in at the 48 second mark.
>
> It seems that usbhid-ups should know the UPS is no longer present but
> upsd doesn't seem to DTRT and mark the data stale (or perhaps
> usbhid-ups is re-sending the old data structure to upsd?).

The usbhid-ups driver doesn't know the 'Device not connected' error  
message means that the UPS is no longer connected. The libusb library  
is fairly verbose with error messages and not all of them are a sign  
of trouble. Therefor, we only assume the UPS is gone for specific ones  
and by default, they are disregarded.

If you add this error in the case statement around line 1350 in  
usbhid-ups.c that lists the conditions for reconnecting, you'll  
probably be fine. The driver will then tell the server that the data  
is stale after a couple of tries and reconnect once it is attached  
again.

> Also, I think that usbhid-ups should either try reconnecting to the UPS
> (ie search for a suitable device like it does when starting) or exit
> after several failed attempts.

It should indeed attempt to reconnect (which it will, if it knows this  
is needed). The latter suggestion is not a good idea, since we are not  
started by a hook in the kernel, so this would require operator  
intervention.

> I found when I was using libusb I could not detect if a device went away
> directly, in the end I settled for trying to read a string descriptor -
> since this is a mandatory operation a device always supports if it
> fails it indicates a catastrophic problem. (The lack of decent error
> codes in libusb [or maybe the FreeBSD version] is rather irritating).
>
> I guess really if usbhid-ups exits on error then it should really just
> be started by some system specific daemon on UPS connection (eg devd in
> FreeBSD).

We use that for the HAL enabled drivers, but these are more for  
desktop systems since they don't provide a socket for uspd to connect  
to (and therefor aren't much good in case multiple systems are  
connected to a single UPS).

Best regards, Arjen

PS  The logs you're posting seem to be gzipped twice. This is very confusing.
-- 
Please keep list traffic on the list