timeout error on mei_recv_msg + possible cause / solution

[KillerLink]

Hello, I was trying to use the tool under ARCH-Linux 4.17.4-1 and got the following error message:

ME: timeout waiting for data: expected 8, available 6

The tool aborted afterwards.

To gather additional information i removed the return in return in me.c, line 289

This lead to the tool continueing, printing additional output, as well as an additional error message:

ME: response is missing data ME: not enough room in response buffer 4 != 6 ME: Firmware Version 7.1.1161.40 (code) 7.1.1161.40 (recovery) 0.0.0.0 (fitc)

I found it interesting that the difference for the first and second error message was both 2, and that the fitc version looks kinda off. Upon inspection i found that the total fitc data needs 4 sizeof(uint16_t) = 4 2 = 8 bytes, and the size is divided by 4 / shifted right by 2 in the comparison, and 8/4 = 2, exactly the error.

For testing i made the following change here if (mei_sendrecv(&mei, &mkhi, &data, &version, sizeof(version) ) < 0) { to if (mei_sendrecv(&mei, &mkhi, &data, &version, sizeof(version-2) ) < 0) { with the intent to purposely ignore the fitc data.

==> The Result of that change was a now error free output.

Of course, just subtracting 2 is not a general valid fix, i assume that on other laptops this data is available and should or must be read from the buffer. I'd suggest a dynamic detection of wether or not this information is available, or a define that changes the struct me_fw_version to [not] include the fitc part and modify the the according printf to [not] include the fitc if unavailable. But i currently do not know what criteria would indicate the presence / absence of the fitc version data to make that change in code.

My questions are now: 1) should this error message be updated to something like "response buffer size mismatch", because the condition is not a "smaller" (implied by the current error message) but an "unequal"? 2) Since i do not know a lot about Intel ME and its inner workings, i do not know whether my findings are correct and how a correct "fix" should be implemented?

[KillerLink]

On a side note, here is a picture of the output after i applied my temporary fix. i think it is kind of strange that it says that Intel Anti-Theft is ON, even though i disabled it in the BIOS (or is this common?), which makes me unsure if my fix might have influenced the result (in the circular buffer?) of the subsequent messages (for example by leaving unread data in the buffer). I

[zamaudio]

You're probably right, the tool doesn't work on all models of the ME because different number of bytes are returned by different models, I haven't worked it all out. Thanks for the report.