#50 The show_fru() stops printing in the middle of processing Board Info area with a single byte data for a field

[Yusuke Matsui]

I saw this issue with the show_fru() function in util/ifru.c.
If the data for the predefined field in Board Info area is just a single byte one, the loop to print the fields exit from there, and the rest of the fields won't be printed.

For example, if the Board Product Name is just 'x' for example, the Board Info area will contain these byte sequence "0xc1 0x78". The loop processing this Board Info area will break out from this loop by seeing this "0xc1" byte as it thinks there is no more info fields... So, the remaining fields, like, Board Serial Number, Board Part Number, "FRU File ID", and so on will not be printed by ifru.

      for (i = 0; i < NUM_BOARD_FIELDS; i++)
      {
         if (ChkOverflow((int)(pfru - pfru0),sfru,tl.len)) break;
         if (pfru[0] == FRU_END) break;  /*0xC1 = end*/           <--- !!
         if (!ValidTL(pfru[0]))
            printf("  ERROR - Invalid Type/Length %02x for %s\n",
                        pfru[0],board[i]);
         tl.type = (pfru[0] & FRU_TYPE_MASK) >> 6;
         tl.len  = pfru[0] & FRU_LEN_MASK;
         pfru++;
         {
           newstr[0] = 0;
           decode_string(tl.type,lang,pfru,tl.len,newstr,sizeof(newstr));
           printf("%s%s%c %s\n",devstr, board[i],bdelim,newstr);
         }
         pfru += tl.len;
      }

[Andy Cress]

Actually, the 0xC1 is empirically the end of the FRU data.
Keep in mind that the length portion of this byte (0x01) includes the current byte.
So if there were a one byte FRU data field with 'x', it would be 0xC2 0x78.
There are several firmware vendors who have garbage after the FRU_END byte, so it is needful to exit the loop when 0xC1 is encountered. Over the years, several firmware FRU data flaws have been handled via ChkOverflow() and ValidTL(), but the FRU_END 0xC1 cannot be changed.
Also, the NUM_BOARD_FIELDS is a limit on the loop, but many firmware vendors do not include all of the possible fields, so the FRU_END byte 0xC1 must be recognized and acted upon.

Have you encountered a firmware vendor whose FRU data is malformed that prompted this inquiry?

[Yusuke Matsui]

Thank you, Andy.

Actually I saw "0xC1 0x20" had been set to "Board Product Name" field in Board Info area. And I noticed the ipmiutil stopped to print Board Info area fields for "Board Product Name" and the remaining fields.

[Andy Cress]

Resolved the issue. The FRU data is ok now. No change to ipmiutil is warranted.