I understand that these two file changes can be split into two different issues/branches. It shouldn't be a huge problem because both changes are simple and small enough.

Some explanations:

1. lanplus.c ipmi_lan_poll_single(), I don't know why the three lines were added onto the 1.8.18 code. I did not see a point as these variables not used anymore after that line. Therefore, I removed them.

I did not review other interface handlers and verify if they are ok or not.

2. ipmi_hpmfwupg.c HpmfwupgGetComponentProperties(). This change helps those interfaces that doesn't clear the extra data buffer. However, it will also hide the interface handler problem.

3. I initially believed the HpmfwupgGetComponentProperties() should also help the OEM properties. Then I reviewed the code. I noticed HPMFWUPG_OEM_LENGTH is defined as only 4 (ipmi_hpmfwupg.h). I guess this is specific for the manufacture who requested this feature. However, HPM.1 specification says the length is defined by the OEM ad identified by the Manufacturer ID in Get Device ID command. IPMITool, as a generic tool, should not limit this size to be 4. As I don't know the history of this part, and I don't use this OEM property, I'll leave it as is until someone complains.

I just reviewed sendrecv functions of other interfaces (1.8.18 source code).

It appears to me only the open.c and lan.c are correct with different implementations. open.c sets only the next buffer byte to be '\0' while lan.c clears entire rest of the data buffer. lan.c method is slightly more secure, but I don't feel it's necessary.

I believe, serial_terminal.c, serial_basic.c, free.c, lipmi.c, and usb.c all have the same potential problem that the command handlers, like current HpmfwupgGetComponentProperties() may accidentally access the data bytes they shouldn't.

I mean, actually these interface sendrecv handlers are correct because the data_len are set correctly, and the downstream command handlers should not access data bytes beyond the data_len. Clearing the extra data buffer will hide the command handler issue.

I don't really know the bmc.c, dummy.c, and imb.c. I feel, bmc.c has the same issue. Anyway, please review all of them and see if they should be updated or not. Or review all the command handlers, and see if they ever access the data beyond rsp.data_len.

By the way, I tested serial_terminal interface, and confirmed extra data byte were printed by the hpm check command. For our application, we care about only the OpenIPMI and lan/lanplus interfaces.