Duncan, The command line and password prompting code will accept any user password less than or equal to 20 bytes in length and the ipmi set passowrd code knows how to properly send an IPMI message to set the password to a length greater than 16 bytes. But, current code does not properly constrain the password to less than or equal to 16 bytes when connecting over lan (which has a maximum of 16 byte passwords).
The problem is that you can specify the -I lan with a > 16 byte password, which is the problem. Basically, the maximum length of the password is 16 bytes for lan and 20 bytes for lanplus. The code needs to enforce this. Does this help? Jim -- Jim Mankovich | jm...@hp.com -- On 4/25/2012 2:21 PM, Duncan Idaho wrote: > On Tue, Apr 24, 2012 at 5:42 PM, Albert Chu<ch...@llnl.gov> wrote: >> On Tue, 2012-04-24 at 10:18 -0700, Duncan Idaho wrote: >>> >>> On Tue, Apr 24, 2012 at 6:52 PM, Albert Chu<ch...@llnl.gov> wrote: >>> I see that the original bug was specified against the -I lan >>> interface >>> (i.e. IPMI 1.5), but the IPMI 2.0 password length max is 20. >>> Not sure >>> if this is being accounted for in the code changes for -I >>> lanplus. >>> >>> Al >>> >>> >>> >>> Albert, >>> >>> I would like to ask you for clarification in this case, because I find >>> IPMI specification being quite confusing. They're talking about >>> storing passwords as 16 byte or 20 byte and internal tag in one >>> paragraph. Yet talking about use of 16b and 20b passwords in other. >>> I'm referring to pages 297-298. >>> As I understand it, password length is up to 16 bytes and the only >>> difference is storage method and latter use determined how was >>> password stored. >> Hi Duncan, >> >> The storing of 16 vs 20 byte passwords is something only handled on the >> BMC/server side. It's not really anything that the client side should >> really be worried about. >> >> IMO, the client side should only worried about the input from the user. >> It should allow max 16 byte passwords for IPMI 1.5 (-I lan) and 20 byte >> passwords for IPMI 2.0 (-I lanplus). >> >> I noticed in the ipmitool source that the README.lanplus file says, "We >> do not currently support 20 byte passwords." So it's possible >> internally 20 byte passwords aren't yet supported, so there could be >> more work to do. But I'll leave that for you guys to decide. At the >> minimum, if a user types in a 20 password for IPMI 2.0, it shouldn't say >> "password too long". >> >> Al >> > Al, > > thanks for clarification. I've re-read IPMI specification and found my > "assurance". > > I propose 'user set password' to be extended for non-mandatory option > to allow user to choose whether password is 16byte or 20byte with > default to 16bytes. > If I understood it correctly, telling between 16byte and 20byte is > only the length of the password in request. However, what if password > is shorter? So, that's why the switch. > > As for LAN+, I don't know why they haven't implemented it. I'm a bit > confused though, whether we are talking about limiting password length > in 'lib/ipmi_user.c' or "globally"? Jim? I'm under impression only > 'lib/ipmi_user.c' is under the discussion now in which case, I'll take > a look at it. > > I hope it makes at least a bit of sense. It feels a bit of frantic. > > --Duncan > >>> To be honest, I haven't read IPMI specification back and forth(only >>> bits I needed or were interesting), so it is possible it is explained >>> somewhere in there. >>> >>> Thank you for clarification, >>> --Duncan >>> >>> > I'll try to post a patch for review for the 16 character >>> username >>> > limit sometime this week. >>> > >>> > Do you what you can with the resources you have a hand. >>> > Any/All help is much appreciated. >>> > >>> > -- Jim Mankovich | jm...@hp.com -- >>> > >>> > On 4/23/2012 12:22 PM, Duncan Idaho wrote: >>> > > >>> > > On Mon, Apr 23, 2012 at 6:26 PM, Jim Mankovich >>> <jm...@hp.com> wrote: >>> > > [...] >>> > > report and I could not find any existing >>> resolution to in >>> > > the TOB CVS for ipmitool. If anyone >>> > > has any time to work on ipmitool, please look at >>> Tracker >>> > > items first for something to do. >>> > > >>> > > >>> > > Time, yes(sometimes). Machines to test at? No. >>> > > And some stuff, well the most of it, will require some >>> IPMI capable >>> > > hardware to test and develop at. So it won't be that easy >>> to get >>> > > devs. >>> > > >>> > > Anyway. Once we agree on code in 'lib/ipmi_user.c', I >>> could take a >>> > > look at >>> > > >>> >>> http://sourceforge.net/tracker/?func=detail&aid=3001519&group_id=95200&atid=610550 >>> and >>> http://sourceforge.net/tracker/?func=detail&aid=3184687&group_id=95200&atid=610550 >>> . That's where they'll go right? btw this sounds like a BMC(IPMI stack) to >>> me as well and reportee should report it to his vendor. >>> > > >>> > > --Duncan >>> > > >>> >>> -- >>> Albert Chu >>> ch...@llnl.gov >>> Computer Scientist >>> High Performance Systems Division >>> Lawrence Livermore National Laboratory >>> >>> >>> >> -- >> Albert Chu >> ch...@llnl.gov >> Computer Scientist >> High Performance Systems Division >> Lawrence Livermore National Laboratory >> >> > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Ipmitool-devel mailing list Ipmitool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
