[Nut-upsdev] bcmxcp: stop whining (and log spamming)

[Henning Brauer]

* Arnaud Quette <aquette.dev at gmail.com> [2006-08-23 23:49]:
> 1) the fact that you're seing "new connexion" msg is either due to
> real unsolicited connexions, but most probably to the fact that you're
> using a exotic monitoring method (== not upsmon).

it is the nagios nut plugin. there is no concept of a session.
I still consider he current logging extremely inappropriate; if you all 
don't agree so be it and I patch it away in the openbsd port (we 
believe in sensible defaults, and that includes not spamming logs - 
after all, the logs are there to spot real issues)

> Otherwise, you'll have to use upsd's ACL to avoid unsollicited connexions...

ACLs are in place, and of course the box is firewalled.

> Finally, and as told by Peter, there are (or should be) configurable
> mechanisms in your logd daemon.

It is all about sensible defaults, really.

> 2) the driver is not buggy. If you face wrong chksum, it's really that
> the board is buggy!

I highly doubt that. I see this on multiple units (and only one of them 
has this damn useless 6-cereal card that apprently introduces new 
issues), and when I was googl'ing for solutions I came accross quite 
some other reports of the same issue.
The units are HP/compaq R3000XR, apparently relabeled powerware 5125 
3000e RM. I went thru all the pain HP likes to burden on their 
customers to get them up to the latest firmware they provide, 1.09A, 
which improved things a bit (reported battery charge and ups load are 
now closer to reality). flashing these units is the horror, but the hw 
is nice, really ;)

Wonder wether the issues might be related to the fact that I am on a 
big endian 64bit strict alignment platform, a quick check didn't reveal 
anything tho (haven't checked in depth)

> I'm not sure about the firmware pb (too quickly read the thread)

that one is nasty, as easy as it seems.
these systems have a concept of multiple "CPUs", where the normal model 
with the 1-cerel card has only one, the inverter unit. the 6-cereal 
card shows up as second CPU. all CPUs have a firmware and report 
version. the current code lead to reporting firmware 0.91 for the UPS, 
which confuses big time, since it was at 1.03 even before I updated - 
0.91 is the 6-cereal card's firmware. Now the problem is, I don't think 
there is any way to match CPU #x to unit y, as in, CPU0 would always be 
the inverter (it is not, the cereal comes first if installed). the q&d 
fix for this specific model is to use the last CPU's version, not the 
first as the current code, but I am not certain wether that leads to 
the desired results on other models... thus the "ups.firmware.cpuX" 
proposal.

> Finally,  I understand the hanger of being borred by such things.

I dunno what everybody seems to read into my words.

There's some annoying things in nut, but all overall they're rather 
minor. using it for years now.

when I find a little more time I'll even look into fixing the (minor) 
issues in apcsmart with the SU DP models ;)

finally, if anyone has docs for the BCM/XCP protocol, Id appreciate a 
copy, that might help tracking down lurking bugs

-- 
Henning Brauer, hb at bsws.de, henning at openbsd.org
BS Web Services, http://bsws.de
OpenBSD-based Webhosting, Mail Services, Managed Servers, ...