freeipmi-devel
[Top][All Lists]
Advanced

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

[Freeipmi-devel] Re: RE: RE: libfreeipmi - sequence numbers


From: Albert Chu
Subject: [Freeipmi-devel] Re: RE: RE: libfreeipmi - sequence numbers
Date: Fri, 29 Oct 2004 14:56:47 -0700

Hi Andrew,

Just for kicks, what kind of machine are you working with?

Also, is there any way to get your code with the FreeIPMI changes?  I
don't have an i386 box to work with.

Al

--
Albert Chu
address@hidden
Lawrence Livermore National Laboratory

----- Original Message -----
From: "Cress, Andrew R" <address@hidden>
Date: Friday, October 29, 2004 2:51 pm
Subject: RE: RE: libfreeipmi - sequence numbers

> 
> The SEL record itself doesn't use the sequence number.
> I'm using MD2 authtype.
> I don't think the BMC is objecting to the authtype, because it works
> with MD2 as long as the bounds check isn't there.
> 
> Andy
> 
> -----Original Message-----
> From: Albert Chu [mailto:address@hidden 
> Sent: Friday, October 29, 2004 5:22 PM
> To: Cress, Andrew R
> Cc: Ian Zimmerman; address@hidden
> Subject: Re: RE: libfreeipmi - sequence numbers
> 
> 
> Hey Andrew,
> 
> Hmmm.  What is strange is that removing the bounds check should
> theoretically not do anything.  Even if the bounds check isn't done,
> internally the code would truncate all the data greater than 6 bits,
> theoretically doing the same thing as when you wrap the requester
> sequence number.  
> 
> What type of authentication are you using?  If its MD2 or MD5, perhaps
> we are doing the calculation incorrectly in the ipmi_lan_cmd() path of
> code.  Ipmipower is our only tool that uses md2/md5, and it doesn't 
> useipmi_lan_cmd(), but uses ipmi_lan_sendto/recvfrom, so there 
> could be a
> bug lingering in there somewhere.  That could easily explain why 
> the BMC
> chooses to ignore packets.  Its not because of the sequence 
> numbers, but
> rather the auth code isn't correct.  Does the remote machine have per
> msg authentication enabled?
> 
> I don't know the sel part of the ipmi specification that well.  AB, 
> Balahave more knowledge in this chunk of IPMI.  Is the requester 
> sequencenumber used in some particularly special way?  
> 
> Al
> 
> --
> Albert Chu
> address@hidden
> Lawrence Livermore National Laboratory
> 
> ----- Original Message -----
> From: "Cress, Andrew R" <address@hidden>
> Date: Friday, October 29, 2004 1:34 pm
> Subject: RE: libfreeipmi - sequence numbers
> 
> > Al/Ian,
> > 
> > I do understand the rq_seq being output and used in the lan 
> header, 
> > andthe other is in the session header.  And I see that the lan 
> > header in
> > section 12.4 defines rq_seq as 6 bits (8 - 2 for lun).  So, we 
> may be
> > dealing with something more subtle here.  However, the empirical 
> > fact is
> > that it doesn't work as coded (I'm calling ipmi_lan_cmd), and 
> with the
> > patch below, it does work for up to 0x10B packets in a test 
> > session. 
> > 
> > If you have a better solution, I'm open to it.
> > Without a fix of some kind, I can't use the FreeIPMI LAN interface.
> > 
> > Attached is my test version of showsel (i386 Linux), to exhibit the
> > problem.  It looks for libfreeipmi.so.0.
> > "showsel -N ipminodename -x"  
> > The -x option shows debug messages with the rq_seq listed.
> > As long as there are more than 63 SEL records, the 0.1.0 library 
> will> abort, and the patched one works fine.  If the app attempts 
> to conform
> > by wrapping the rq_seq, the session will hang (BMC silently discards
> > packets).  
> > 
> > Andy
> > 
> > --- libfreeipmi/src/ipmi-lan-interface.c.orig   2004-10-28
> > 10:38:04.000000000 -0400
> > +++ libfreeipmi/src/ipmi-lan-interface.c        2004-10-28
> > 17:26:58.000000000 -0400
> > @@ -108,7 +108,7 @@
> > {
> >   if ((net_fn > IPMI_NET_FN_TRANSPORT_RS)
> >       || (rs_lun > IPMI_BMC_IPMB_LUN_OEM_LUN2)
> > -      || (rq_seq > IPMI_LAN_SEQ_NUM_MAX)
> > +     /*  || (rq_seq > IPMI_LAN_SEQ_NUM_MAX)   /* ARCress +++*/
> >       || (obj_msg == NULL))
> >     {
> >       errno = EINVAL;
> > 
> > -----Original Message-----
> > From: Albert Chu [mailto:address@hidden 
> > Sent: Friday, October 29, 2004 12:05 PM
> > To: Cress, Andrew R
> > Cc: address@hidden
> > Subject: Re: RE: RE: RE: [Freeipmi-devel] Using libfreeipmi 
> interface> 
> > 
> > Hi Andrew,
> > 
> > > Where did the 0x3f arbitrary sequence limit come from anyway?  I
> > > couldn't find any reference to sequence number limits in the 
> IPMI 
> > spec> or platform specs.
> > 
> > The 0x3f comes from the fact the requester sequence number is 6 bits
> > long.  You can see this in section 7.3, figure 7-1 of the IPMI 
> 1.5 
> > spec. (That section is pointed to by section 12.4, which 
> discusses 
> > IPMI over
> > Lan).  
> > 
> > I get the feeling you are passing in session sequence numbers, 
> > which are
> > 32 bits, in place of the requester sequence numbers, which are 6 
> bits> long.  The session sequence number is passed to the 
> fill_hdr_session()> function when building a packet and the 
> requester sequence number is
> > passed to fill_lan_msg_hdr().
> > 
> > Al
> > 
> > --
> > Albert Chu
> > address@hidden
> > Lawrence Livermore National Laboratory
> > 
> > ----- Original Message -----
> > From: "Cress, Andrew R" <address@hidden>
> > Date: Friday, October 29, 2004 7:44 am
> > Subject: RE: RE: RE: [Freeipmi-devel] Using libfreeipmi interface
> > 
> > > 
> > > re: IPMI_LAN_SEQ_NUM_MAX (=0x3F)
> > > 
> > > As a use case, to understand the problem this causes, one of my
> > > applications 'showsel' allows reading the IPMI SEL.  This can 
> be 
> > quite> long on Intel platforms (e.g. 4032 record capacity on one 
> > test system
> > > here).  On one test system, with 257 SEL records, the sequence 
> > number> increments to 267 (0x10B), and wrapping the sequence 
> number 
> > during 
> > > thissession causes the IPMI chipset to ignore the command with a
> > > duplicate/lower sequence number (and the app/lib would hang).  
> This> > would also affect the fish/sel script/app similarly.  The 
> sequence> > number is 32 bits, and incrementing up through that 
> capacity is 
> > > allowed.My Tiger (ia64) system isn't up right now, but as I 
> > recall, 
> > > it behaves
> > > the same way.
> > > 
> > > Where did the 0x3f arbitrary sequence limit come from anyway?  I
> > > couldn't find any reference to sequence number limits in the 
> IPMI 
> > spec> or platform specs.
> > > 
> > > So, my position is that it is not just inappropriate to check 
> > sequence> number bounds at 0x3f, but invalid for IPMI 1.5 
> platforms 
> > with LAN
> > > support (a bug).
> > > 
> > > Andy
> > > 
> > > -----Original Message-----
> > > From: Albert Chu [mailto:address@hidden 
> > > Sent: Thursday, October 28, 2004 8:04 PM
> > > To: Cress, Andrew R
> > > Cc: address@hidden
> > > Subject: Re: RE: RE: [Freeipmi-devel] Using libfreeipmi interface
> > > 
> > > 
> > > > I also found a problem with the  IPMI_LAN_SEQ_NUM_MAX (=0x3F).
> > > > There isn't any precedent in IPMI 1.5 for this, and limiting 
> > the 
> > > 32-
> > > > bitsequence number to 6 bits causes some problems, since the 
> > BMC 
> > > > LAN won't handle wrapping the sequence number back to 0 or 1 
> > > after 63 
> > > > (0x3f).
> > > 
> > > I'm not quite convinced this is a problem.  The bounds check 
> > makes the
> > > user knowledgeable to the fact that arbitrary sequence numbers 
> > aren't> allowed.  I spoke to a few other developers I work with, 
> > and they feel
> > > that the bounds checking is more appropriate.  Ab, Ian, Bala, 
> > what are
> > > your thoughts??
> > > 
> > > 
> > 
> > 
> 
> 





reply via email to

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