You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
IN order to test against a live MCTP server, we need a request tool that is more flexible than just an echo request. Specifically:
The client needs to be able to specify the type code in the header. Currently that is hard coded to 1, but MCTP control messages (needed for baseline testing ) are 0. SPDM messages are type 5.
The client assumes it is sending an echo packet, and confirms the length and fields accordingly. This is not used for any actual server and should become alternate, not default behavior.
The output should be parsable, which means that non-payload output should be suppressible.
The text was updated successfully, but these errors were encountered:
To address point 1, (the type field), I used modified my version to have a type command line parameter. If this parameter is missing, it defaults to 1, so existing behavior is maintained.
So mctp_req and mctp_echo were originally intended just for testing the kernel MCTP stack - where the type/content/etc of the message data wasn't important at all - just that we could get a message sent and a reply received.
If you want to turn mctp_req into a more generic tool for creating MCTP messages, that's fine; there's no real need to keep current behaviour if it causes problems with new code - as long as we have some way to test a simple request/response message through the AF_MCTP transport.
IN order to test against a live MCTP server, we need a request tool that is more flexible than just an echo request. Specifically:
The text was updated successfully, but these errors were encountered: