Just to confirm as well, that it also
worked for me
regards,
Arif Ali MBCS
HPC Systems Architect
OCF plc
Tel: +44
(0)114 257 2200
Mob: +44
(0)7970 148 122
Fax: +44
(0)114 257 0022
Web: www.ocf.co.uk
Blog: blog.ocf.co.uk
Twitter: @ocfplc
Please note, any emails relating to an OCF Support request
must always be sent to [email protected]
for a ticket number to be generated or existing support ticket
to be updated. Should this not be done then OCF cannot be held
responsible for requests not dealt with in a timely manner.
OCF plc is a company registered in England and Wales.
Registered
number 4132533, VAT number GB 780 6803 14. Registered office
address: OCF plc, 5 Rotunda Business Centre, Thorncliffe Park,
Chapeltown, Sheffield, S35 2PG.
This message is private and confidential. If you have received
this message in error, please notify us and remove it from
your system.
On 01/02/13 14:28, Jarrod B Johnson wrote:
Thanks for the feedback, 2.7.7
and 2.8 will contain the workaround and I don't foresee a
reason for us to ever revive that check.
 Sten Wolf
---01/31/2013 08:24:30 PM---Thanks, That solved the issue.
From: Sten Wolf
<[email protected]>
To: xCAT Users Mailing list
<[email protected]>,
Date: 01/31/2013 08:24 PM
Subject: Re: [xcat-user] ipmi commands not
working if used as "rXXX" comands, but work as ipmitool-xcat
commands
Thanks,
That solved the issue.
I'm trying to raise the issue with Supermicro as well, hopefully
they'll fix their IPMI.
On 29/01//2013 18:14, Jarrod B Johnson
wrote:
Ok, looked through the capture.
The BMC violates the IPMI spec by not correctly setting the
target address field. (e.g. you can see in wireshark that the
protocol dissector blows up on the packet by saying 'Unkown
command' and claiming it says 'BROADCAST', this is all because
the byte at 0x38 is '00' and it should have been '0x81').
xCAT blows up for the same reason, the BMC is required to
correctly address responses and xCAT recently started caring
about that. xCAT actually blows up less than the dissector,
the dissector actually gets confused about the correct offsets
for the rest of the packet.
The good news is the reason for using multiple rqaddr values
(why our routing code had to actually check the value) was
removed and thus we can retire that check as well and tolerate
the spec violation.
Can you see if the following change allows it to work again?
--- a/xCAT-server/lib/perl/xCAT/IPMI.pm
+++ b/xCAT-server/lib/perl/xCAT/IPMI.pm
@@ -865,7 +865,7 @@ sub parse_ipmi_payload {
my @payload = @_;
#for now, just trash the headers, this has been validated
to death anyway
#except seqlun, that one is important
- unless ($payload[4] == $self->{seqlun} and $payload[0]
== $self->{rqaddr} and $payload[1]>>2 ==
$self->{expectednetfn} and $payload[5] ==
$self->{expecte
+ unless ($payload[4] == $self->{seqlun} and
$payload[1]>>2 == $self->{expectednetfn} and
$payload[5] == $self->{expectedcmd} ) {
#both sequence number and arqaddr must match, because
we are using rqaddr to extend the sequence number
#print "Successfully didn't get confused by stale
response ".$payload[4]." and ".($self->{seqlun}-4)."\n";
#hexdump(@payload);
Sten
Wolf ---01/29/2013 08:54:46 AM---Attached wireshark captures
of the "conversation" stream. tux401ipmi.cap has the issue.
From: Sten Wolf <[email protected]>
To: xCAT Users
Mailing list <[email protected]>,
Date: 01/29/2013
08:54 AM
Subject: Re:
[xcat-user] ipmi commands not working if used as "rXXX"
comands, but work as ipmitool-xcat commands
Attached wireshark captures of the "conversation" stream.
tux401ipmi.cap has the issue.
Interestingly, when attaching the node to an older xcat server
( running on centos 6.2 ) the result is correct. The capture
for the same node, from the older xcat server is attached as
tux401ipmi-external.cap
trying perl -e 'use Digest::SHA1; use Digest::HMAC_SHA1;'
didn't return anything.
trying ipmitool -I lanplus -C 2 <etc...> returned
correct result, same as without -C 2
trying perl -e 'use Crypt::Rijndael; use Crypt::CBC;' returned error:
Can't locate Crypt/Rijndael.pm in @INC (@INC contains:
/usr/local/lib64/perl5 /usr/local/share/perl5
/usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl
/usr/local/lib64/perl5 /usr/local/share/perl5
/usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl
/usr/lib64/perl5 /usr/share/perl5 .) at -e line 1.
BEGIN failed--compilation aborted at -e line 1.
trying /opt/xcat/lib/perl/xCAT/IPMI.pm. After
'Digest::HMAC_HA1->import()' there is a '1;'. Change that
to '0;' :
the result was the same as with '1' - timeout.
should I have done anything else after modifying IPMI.pm?
from comparing the cap files, it seems the new server doesn't
send the rmcp+ open session request, sending the same "get
channel" packet over and over...
any idea what can be done?
On 28/01//2013 16:56, Jarrod B Johnson wrote:
It may be interesting to review a libpcap capture at the
time of the attempt. I can probably more specifically
ascertain the issue.
I'll make a few speculative guesses as what could
theoretically be the problem.
-BMC is demanding IPMI 2, but xCAT's ipmi2support is
failing. Try: perl -e 'use Digest::SHA1; use
Digest::HMAC_SHA1;'. If that works, then xCAT should be
doing IPMI 2 by default if the BMC advertises it. I might
should make those hard rpm dependencies, since they are
in-distro for almost everyone.
-xCAT is doing IPMI2 and BMC requires IPMI2, but it more
specifically is requiring cipher suite 3 and xCAT's prereqs
for that are missing. To test this, try ipmitool -I lanplus
-C 2 <etc...>' and test for xCAT Cipher suite 3 by
doing: perl -e 'use Crypt::Rijndael; use Crypt::CBC;'
-Service processor can do IPMI 2, but does not support
mutual authentication (protection against impersonating a
BMC). ipmitool works because it doesn't bother to
authenticate the BMC at all (which actually means rcons is
hijackable so long as we use ipmitool). The most secure
workaround to try in such a case is to search for
'ipmi2support' in /opt/xcat/lib/perl/xCAT/IPMI.pm. After
'Digest::HMAC_HA1->import()' there is a '1;'. Change
that to '0;' to force IPMI 1.5 operation. *If* they don't
support IPMI 2 mutual authentication, then 1.5 would be more
secure. Note that doesn't mean that any functionality is
lost, we still issue IPMI 2 version commands when support
detected even if we use IPMI 1.5 protocol to convey them.
If you were interested in explicitly testing that last case,
you'd have to disable the check for matching authtype, the
return statement commented as 'not thinking about packets
that do not match our preferred auth type' would be that.
I probably should add a site entry to disable IPMI 2
support. I could also more specifically relax the mutual
authentication check, but I'd much rather the relatively few
manufacturers that can't pass that fix their firmware since
it's a much better security picture.
Sten Wolf ---01/27/2013 08:07:50 PM---Hi, I'm encountering
a strange issue with some SuperMicro machines, using xcat
2.7.6. All nodes are
From: Sten Wolf <[email protected]>
To: [email protected],
Date: 01/27/2013
08:07 PM
Subject: [xcat-user]
ipmi commands not working if used as "rXXX" comands, but
work as ipmitool-xcat commands
Hi,
I'm encountering a strange issue with some SuperMicro
machines, using xcat 2.7.6. All nodes are centos 6.3 (both
MN and compute nodes).
After configuring nodehm, ipmi tables the
rpower/rinv/rinstall/rvitals commands do not work. They
simply time out.
using the same credentials with ipmitool-xcat returns
correct results.
# ipmitool-xcat -I lanplus -H ipmi05 -U ADMIN -P ADMIN power
status
Chassis Power is on
while
# rpower n05 status
n05: Error: timeout
Firewall and selinux both disabled.
lsdef n05 confirms it's bmc is ipmi05.
using xcatdebug -f enable -d enable also confirms the
command is trying to connect to the ipmi address, with the
correct username and password, but getting no reply.
The only possible issue I could see is
'ipmiversion' => '1.5',
I haven't tried ipmitool -I lan yet, but I wonder if this
setting is user configurable in xcat?
BTW - nodeset works correctly, if I power cycle the nodes
manually, or with ipmitool, they install without further
issues.------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012,
HTML5, CSS,
MVC, Windows 8 Apps, _javascript_ and much more. Keep your
skills current
with LearnDevNow - 3,200 step-by-step video tutorials by
Microsoft
MVPs and experts. ON SALE this month only -- learn more
at:
http://p.sf.net/sfu/learnnow-d2d_______________________________________________
xCAT-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/xcat-user
[attachment
"tux401ipmi-external.cap" deleted by Jarrod B
Johnson/Raleigh/IBM] [attachment "tux401ipmi.cap" deleted by
Jarrod B Johnson/Raleigh/IBM] ------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012,
HTML5, CSS,
MVC, Windows 8 Apps, _javascript_ and much more. Keep your
skills current
with LearnDevNow - 3,200 step-by-step video tutorials by
Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d_______________________________________________
xCAT-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/xcat-user
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan_______________________________________________
xCAT-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/xcat-user
|
