[Top][All Lists]
[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??
> > >
> > >
> >
> >
>
>
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Freeipmi-devel] Re: RE: RE: libfreeipmi - sequence numbers,
Albert Chu <=