[Nut-upsuser] Belkin Regulator Pro dropping connection and halting

Arjen de Korte nut+users at de-korte.org
Thu Dec 2 10:08:11 UTC 2010


Citeren Arnaud Quette <aquette.dev op gmail.com>:

>> Thanks for the suggestions, I've added the flush statement as well as some
>> debugging information. As this is a intermittent issue I decided to try
>> overloading the UPS by sending it repeated beeper commands while watching
>> the debug output. What appears to happen is that the UPS returns an unknown
>> "~00R000" response. This means get_belkin_reply() returns -1, causing a
>> datastale state is set when called from do_status().
>
> you should remove the datastale() call since upsd will automatically flag
> the device as stalled if it has failed to update its data for 15 seconds
> (default of MAXAGE).

Not at all!

The upsd server will only declare the *driver* stale if it fails to  
respond within MAXAGE seconds. However, as long as it keeps answering  
the PING from the server, it will not be declared stale. This  
mechanism is something completely different from what happens if the  
driver calls dstate_datastale(). In that case the driver tells the  
upsd server that the *UPS* fails to respond. See the chapter on  
"Staleness control" in docs/new-drivers.txt.

What really needs to be done, is that the driver doesn't treat the  
"~00R000" reply as an error condition. Apparently the UPS acknowledges  
the receipt of data, without further response (indicating that 0 bytes  
follow). The belkin driver doesn't accept this at the moment and  
requires that a reply follows. This is what needs to be changed.

Last but not least, in most drivers, we allow a couple of missed  
replies before we call dstate_datastale() so that glitches don't lead  
to automatic reconnects.

Best regards, Arjen
-- 
Please keep list traffic on the list (off-list replies will be rejected)




More information about the Nut-upsuser mailing list