Hi Al,
Thanks for the help! I've been wanting to get this working for several
years ...
On 05/19/2011 02:24 AM, Albert Chu wrote:
The error messages in ipmi have to be taken with a grain of salt.
Yeah, unfortunately there's not much I can do when the vendor implements
something wrong. IIRC, in this case, the remote machine is reporting to
the client invalid "checks". Normally, this means the password was
wrong, but in this motherboard's case, it's b/c they were doing a hash
incorrectly.
Sure, I gather there are a lot of quirks with this hardware.
My main issue right now is that only one out of my seven Intel servers
(five of them S3420GP) respond to impiping. In-band works fine on all of
them, and I've used bmc-config to duplicate the configuration of the one
working machine on the other S3420GP boxen, changing only IP and MAC
addresses. I have a mix of public and private networks and udev
reassignments of NICs, but the machine that works is no different in
this respect from the others. Can I do something like nmap to see if the
port is open?
What is the minimal configuration needed for ipmiping to get a response?
What could be causing the block? I just lucked out to have at least one
working system, so at least I get to see how things should be behaving.
How can I reset and clear the configuration? I used "ipmitool mc reset
cold" and it seemed to wipe the configuration (but not reboot the
machine), but after a reboot it was back. As I said, I'm completely
green to this and haven't found anyone on my campus willing and able to
tell me what's going on.
Can you set this up with a daemon and e-mail warnings?
You mean like when sensors are out of whack? Or when a SEL entry
reports an issue?
This sort of thing -- customized criteria for automatic remote
monitoring. I'm not there yet though, as I can't even ping.
Cheers,
Dave
_______________________________________________
Freeipmi-users mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/freeipmi-users
