freeipmi-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Freeipmi-users] Intel S3420GP invalid integrity check value


From: Albert Chu
Subject: Re: [Freeipmi-users] Intel S3420GP invalid integrity check value
Date: Thu, 19 May 2011 14:04:17 -0700

Hi David,

On Thu, 2011-05-19 at 13:33 -0700, David Liontooth wrote:
> Hi Al,
> 
> Really appreciate the help; this subsystem is complicated!
> 
> On 05/19/2011 06:58 PM, Albert Chu wrote:
> >
> >> 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?
> > Using nmap should work to see if the port is open (or more notably, if
> > you can nmap the IP you configure for IPMI.
> Very cool -- that works, though it reports ports 22 and 5120 rather than 
> the 623 I thought IPMI uses.
> As expected, it does not work from localhost. It also confirms that six 
> of my seven servers haven't opened the ipmi port -- that's a dismal 
> success rate.
> 
> >> 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.
> > It should simply be enabling IPMI (via Lan_Channel), configuring a
> > proper IP, MAC, subnet, gateway, etc.
> I take it users don't need to be configured for ipmiping or nmap to work 
> -- this is enough:
> 
> Lan Param(3) IP address: 192 168 0 56
> Lan Param(4) IP addr src: 01 : Static
> Lan Param(5) MAC addr: 00 15 17 ad d7 22
> Lan Param(6) Subnet mask: 255 255 255 0
> Lan Param(7) IPv4 header: 1e 00 00
> Lan Param(10) BMC grat ARP: 03 : Grat-ARP enabled, ARP-resp enabled
> Lan Param(11) grat ARP interval: 09 : 4.5 sec
> Lan Param(12) Def gateway IP: 192 168 0 178
> Lan Param(13) Def gateway MAC: 00 e0 81 5f e9 2f
> 
> Lan Param(3) IP address: 192 168 0 57
> Lan Param(4) IP addr src: 01 : Static
> Lan Param(5) MAC addr: 00 15 17 ad d6 f4
> Lan Param(6) Subnet mask: 255 255 255 0
> Lan Param(7) IPv4 header: 1e 00 00
> Lan Param(10) BMC grat ARP: 03 : Grat-ARP enabled, ARP-resp enabled
> Lan Param(11) grat ARP interval: 09 : 4.5 sec
> Lan Param(12) Def gateway IP: 192 168 0 178
> Lan Param(13) Def gateway MAC: 00 e0 81 5f e9 2e
> 
> It looks like the BMC has accepted these values, but I still cannot 
> ipmiping it (first works, second not).
> Any other settings needed for ipmiping access?

Nah.  That's about it.  Although the above does remind me, is ARPing
setup properly?  It looks like you have gratuitous ARPs enabled, which
should be fine.  If you look at your local arp table (/sbin/arp), is the
remote host MAC found?  If not, then atleast you have a core issue to
investigate.

> >   If you're configuring an
> > identical IP address as the host machine, it may be worth configuring a
> > different one just to try.
> 
> If I use the same IP address for IPMI as for the host machine, I'm able 
> to ipmiping it -- yay!!
> But -- I'm no longer able to ssh into it normally, nmap shows IPMI 
> having taken it over -- so I had to reset it.
> Is there a way around this? Could I reuse the IP addresses for IPMI?

Is it possible you've configured the same MAC address for two different
IPs?  That would definitely be a cause for many of the issues you're
describing.

Al

> > I've witnessed some motherboards not "take" a configuration until you
> > hard-reset the node.  Hard-reset meaning hitting the power button
> > physically.  Or you can cold-reset the BMC by running
> >
> > bmc-device --cold-reset
> >
> > to get the same affect. (I believe this is the equivalent of mc reset
> > cold below)
> >
> > It's also possible there could be something in your BIOS affecting
> > things.  I've seen some motherboards have BIOS options for putting the
> > ethernet card into certain modes which allow/not-allow IPMI.
> Thanks. I'll try the bmc-device reset -- I don't have physical access at 
> the moment.
> 
> The option of using the same IP address intrigues me, since I was able 
> to ping then.
> 
> Dave
> 
> >> 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.
> > Some motherboards have factory reset capabilities, but they are
> > manufacturer/OEM specific.  I haven't come across one for Intel
> > motherboards yet, so there aren't any in ipmi-oem yet.
> >
> >>>> 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.
> > FreeIPMI doesn't have something that high level/specific at the moment
> > (I've been thinking of writing one, but haven't had the time to).
> > FreeIPMI currently has libraries/tools that are more for others to build
> > upon for that feature.
> >
> > Al
> >
> >> Cheers,
> >> Dave
> >>
> 
-- 
Albert Chu
address@hidden
Computer Scientist
High Performance Systems Division
Lawrence Livermore National Laboratory




reply via email to

[Prev in Thread] Current Thread [Next in Thread]