AF_MCTP는 리눅스 커널이 MCTP(Management Component Transport Protocol)를 소켓 인터페이스로 노출할 때 사용하는 주소 패밀리입니다. Linux kernel docs, Management Component Transport Protocol (MCTP) 문서를 기준으로 리눅스 MCTP 소켓 구조와 사용자 공간 도구인 mctp 명령·mctpd 데몬, 그리고 PLDM 인코딩·디코딩 라이브러리인 libpldm과 OpenBMC pldmd 데몬의 역할을 정리합니다.
핵심 요약
리눅스 커널은 MCTP를 네트워크 스택처럼 제공하여, 프로그램이 socket(AF_MCTP, SOCK_DGRAM, 0)으로 소켓을 열고 EID와 메시지 타입을 지정해 메시지를 주고받게 합니다. 인터페이스·주소·경로는 mctp 명령으로 조회·설정하고, 버스 오너로서 원격 엔드포인트에 EID를 할당하며 경로·이웃 테이블을 관리하는 일은 mctpd 데몬이 맡습니다. PLDM 메시지를 인코딩·디코딩하는 라이브러리는 libpldm이며, OpenBMC에서 이를 서비스로 실행하는 데몬은 pldmd입니다. 이 글의 테스트 환경에서는 MCTP가 없는 커널에서 Errno 97을 확인하고, 사용자 공간 도구(mctp, libpldm) 빌드와 PLDM Base GetPLDMTypes 요청 바이트 인코딩까지 검증했습니다.
리눅스는 AF_MCTP로 MCTP를 어떻게 제공합니까?
한 줄 답: 리눅스 커널은 AF_MCTP(PF_MCTP) 주소 패밀리와 SOCK_DGRAM 소켓을 통해 MCTP를 제공하며, struct sockaddr_mctp 구조체로 네트워크·EID·메시지 타입·태그를 지정합니다.
리눅스 커널의 MCTP 문서에 따르면, MCTP를 켠 커널에서는 AF_MCTP(또는 PF_MCTP) 주소 패밀리를 사용하며 소켓 타입은 SOCK_DGRAM만 사용 가능합니다. 프로토콜 인자는 0을 전달하여 int sd = socket(AF_MCTP, SOCK_DGRAM, 0); 형태로 소켓을 생성합니다. 물리 인터페이스 드라이버는 DSP0236의 바인딩(binding)에 해당하며, 개별 인터페이스(link)는 바인딩의 인스턴스입니다.
소켓 주소 구조체인 struct sockaddr_mctp는 smctp_family, smctp_network, smctp_addr, smctp_type, smctp_tag 필드를 가지며, 전체 네트워크와 전체 주소를 뜻하는 상수로 MCTP_NET_ANY(0x0)와 MCTP_ADDR_ANY(0xff)가 정의되어 있습니다. 요청을 수신해 처리하는 소켓은 bind()를 호출합니다. 아래는 커널 문서에 수록된 bind() 예시 코드입니다(커널 문서 예시이며 이 글에서 실행하지 않았습니다).
struct sockaddr_mctp addr;
addr.smctp_family = AF_MCTP;
addr.smctp_network = MCTP_NET_ANY;
addr.smctp_addr.s_addr = MCTP_ADDR_ANY;
addr.smctp_type = MCTP_TYPE_PLDM;
addr.smctp_tag = MCTP_TAG_OWNER;
int rc = bind(sd, (struct sockaddr *)&addr, sizeof(addr));바인드된 소켓은 TO(Tag Owner) 비트가 설정된 메시지, 즉 들어오는 요청만 수신합니다. bind() 호출 시 smctp_tag 필드에 사용할 수 있는 유일한 유효 값은 MCTP_TAG_OWNER입니다. 메시지를 보낼 때는 sendto(), sendmsg(), send()를 사용하며, 네트워크와 주소 필드로 원격지 주소를 지정합니다. 송신 시 MCTP_TAG_OWNER를 지정하면 커널이 태그를 생성하며, 할당 가능한 태그가 없으면 호출은 EAGAIN을 보고합니다. 응용 프로그램은 송신 버퍼의 첫 번째 바이트로 메시지 타입 바이트를 넣습니다.
MCTP 패킷 헤더 필드와 EID·바인딩의 기본 개념은 「MCTP·PLDM이란? 서버 장치 관리 구조와 MCTP 패킷·EID·바인딩 동작 원리」(시리즈 이전 편)에서 다룹니다.
mctp 명령과 mctpd는 무엇이 다릅니까?
한 줄 답: mctp 명령은 iproute2의 ip처럼 커널 MCTP 스택의 상태를 조회·관리하는 명령행 유틸리티이고, mctpd는 버스 오너로서 원격 엔드포인트에 EID를 할당하고 경로와 이웃 테이블을 관리하는 MCTP Control 프로토콜 데몬입니다.
CodeConstruct/mctp 저장소 README에 따르면, mctp는 커널 MCTP 스택의 상태를 조회하고 관리하는 작은 명령행 유틸리티로 iproute2의 ip 명령과 비슷합니다. README 사용법에 나와 있는 하위 명령은 link, address, route, neigh, monitor입니다. 다음은 README에 적힌 명령 구문입니다(README 사용법 구문이며 실행 출력이 아닙니다).
mctp link set <ifname> [up|down] [mtu <mtu>] [network <net>] [bus-owner <physaddr>]
mctp address add <eid> dev <ifname>
mctp route add <eid>[-<eid>] via <ifname> [mtu <mtu>]반면 mctpd는 MCTP Control 프로토콜을 구현한 데몬으로, 로컬 호스트가 버스 오너(bus owner) 역할을 수행할 때 필요합니다. 주요 역할은 원격 엔드포인트에 EID를 할당하고 그에 따른 경로(route)와 이웃 테이블(neighbour-table) 항목을 관리하는 것입니다. mctpd는 인터페이스를 활성화하고 로컬 주소를 할당한 뒤 시스템 서비스로 실행해야 하며, D-Bus 인터페이스를 노출하고 기본적으로 /etc/mctpd.conf에서 설정을 읽습니다. 이 저장소는 Meson으로 빌드하며, -Dtests=false 옵션을 주면 테스트 의존성을 건너뜁니다.
PLDM은 어디서 처리합니까?
한 줄 답: PLDM 메시지의 인코딩과 디코딩은 libpldm 라이브러리가 담당하고, OpenBMC에서 PLDM을 서비스로 처리하는 데몬은 openbmc/pldm 저장소의 pldmd입니다.
openbmc/libpldm은 PLDM 메시지를 인코딩하고 디코딩하는 라이브러리입니다. 이 라이브러리의 base.h 헤더에는 GetPLDMTypes 명령 코드가 0x4로, 요청 페이로드 길이 상수인 PLDM_GET_TYPES_REQ_BYTES가 0으로 정의되어 있습니다.
openbmc/pldm 저장소는 PLDM을 서비스로 처리하는 OpenBMC 데몬인 pldmd 실행 파일을 meson.build로 빌드하며, README에는 systemctl restart pldmd 명령이 안내되어 있습니다. PLDM 타입별 역할과 메시지 흐름 상세는 「PLDM 타입이란? Base·모니터링(PDR·센서)·펌웨어 업데이트·RDE 정리」(시리즈 이전 편)에서 정리합니다.
이 글의 테스트 환경에서는 어디까지 확인했습니까?
한 줄 답: 테스트 환경의 커널은 AF_MCTP를 제공하지 않아 소켓 생성 시 Errno 97이 반환되었으므로 패킷 송수신은 수행하지 않았으며, 사용자 공간 도구(mctp, libpldm) 빌드와 GetPLDMTypes 요청 바이트 인코딩까지 확인했습니다.
이 글의 테스트 환경에서는 커널 설정을 변경하지 않고 현재 커널이 AF_MCTP를 제공하는지 먼저 확인했습니다. python3에서 AF_MCTP 상수 값인 45로 SOCK_DGRAM 소켓 생성을 시도한 결과는 다음과 같습니다(출력의 ... 줄은 생략된 트레이스백 줄을 뜻합니다).
$ python3 -c 'import socket; socket.socket(45, socket.SOCK_DGRAM)'
...
OSError: [Errno 97] Address family not supported by protocol위와 같이 Errno 97(Address family not supported by protocol)이 발생하여 테스트 머신의 커널이 AF_MCTP를 제공하지 않는 것을 확인했습니다. 따라서 실제 MCTP 패킷 송수신이나 링크·주소·경로 설정, mctpd 및 pldmd 실행은 수행하지 않았습니다.
이어서 사용자 공간 도구인 CodeConstruct/mctp(커밋 f3b843d)를 클론하고 -Dtests=false 옵션으로 빌드했습니다(meson setup 출력은 버리고 ninja 출력은 tail -1로 마지막 줄만 남겼습니다).
$ git clone --depth 1 https://github.com/CodeConstruct/mctp src-mctp
$ (cd src-mctp && rm -rf build && meson setup build -Dtests=false >/dev/null && ninja -C build | tail -1)
[22/22] Linking target mctp
$ ls src-mctp/build | grep -E "^mctp"
mctp
mctp-bench
mctp-bench.p
mctp-client
mctp-client.p
mctp-echo
mctp-echo.p
mctp-req
mctp-req.p
mctp.p빌드 결과물 목록에 mctpd는 없습니다. Meson 로그에 Run-time dependency libsystemd found: NO (tried pkg-config and cmake)가 기록되어 있으며, 프로젝트의 meson.build가 libsystemd를 찾았을 때만 mctpd를 빌드하기 때문입니다.
다음으로 openbmc/libpldm(커밋 be4f63e)을 클론하고 같은 방식으로 빌드했습니다.
$ git clone --depth 1 https://github.com/openbmc/libpldm src-libpldm
$ (cd src-libpldm && rm -rf build && meson setup build -Dtests=false >/dev/null && ninja -C build | tail -1)
[33/33] Linking target bindings/cpp/libpldm++.so.0.18.0빌드한 libpldm을 사용해 PLDM Base(Type 0)의 GetPLDMTypes 요청 메시지를 바이트로 인코딩만 하는 C 프로그램(pldm_encode.c)을 작성했습니다.
/* libpldm로 PLDM Base(Type 0) "GetPLDMTypes" 요청 메시지를 인코딩해 바이트를 출력 (MCTP 전송 없음, 인코딩만) */
#include <libpldm/base.h>
#include <stdio.h>
#include <stdint.h>
int main(void) {
uint8_t buf[sizeof(struct pldm_msg_hdr) + PLDM_GET_TYPES_REQ_BYTES];
struct pldm_msg *msg = (struct pldm_msg *)buf;
int rc = encode_get_types_req(1 /* instance id */, msg);
printf("encode_get_types_req rc=%d len=%zu bytes:", rc, sizeof(buf));
for (size_t i = 0; i < sizeof(buf); i++) printf(" %02x", buf[i]);
printf("\n");
printf("request=%u instance_id=%u header_ver=%u pldm_type=%u command=0x%02x\n",
msg->hdr.request, msg->hdr.instance_id, msg->hdr.header_ver, msg->hdr.type, msg->hdr.command);
return rc;
}이 프로그램을 컴파일하고 실행한 결과는 다음과 같습니다.
$ gcc -std=c11 -Wall -Isrc-libpldm/include -Isrc-libpldm/build/include pldm_encode.c -Lsrc-libpldm/build/src -lpldm -o pldm_encode
$ env LD_LIBRARY_PATH=src-libpldm/build/src ./pldm_encode
encode_get_types_req rc=0 len=3 bytes: 81 00 04
request=1 instance_id=1 header_ver=0 pldm_type=0 command=0x04두 번째 출력 줄이 보여 주듯, 인코딩된 3바이트(81 00 04) 헤더의 필드는 request=1, instance_id=1, header_ver=0, pldm_type=0, command=0x04입니다. 이 메시지는 메모리 버퍼에 인코딩만 한 것이며 MCTP 소켓으로 전송하지 않았습니다.
실제 MCTP 장치와 통신하려면 무엇이 더 필요합니까?
한 줄 답: MCTP를 켠 커널과 바인딩 드라이버가 준비된 환경이라면 mctp 명령으로 링크 활성화·로컬 EID·경로를 설정하고 mctpd를 시스템 서비스로 실행한 뒤, AF_MCTP 소켓으로 PLDM 요청 바이트를 보냅니다.
실제 MCTP 장치가 연결된 환경이라면 먼저 MCTP를 켠 커널과 물리 버스용 바인딩 드라이버(예: I2C 등)가 필요합니다. MCTP를 쓸 수 있는 커널에서 인터페이스가 준비되면 mctp 명령으로 링크를 올리고 로컬 EID와 경로를 설정합니다. 아래는 예시 명령(이 글에서 실행하지 않음, 출력 없음)입니다.
mctp link set <ifname> up
mctp address add <eid> dev <ifname>
mctp route add <eid> via <ifname>그다음 mctpd를 시스템 서비스로 실행하여 버스 오너로서 원격 엔드포인트에 EID를 할당하고 경로와 이웃 테이블을 관리하게 합니다. 이후 응용 프로그램이 AF_MCTP 소켓을 열고 송신 버퍼의 첫 바이트에 메시지 타입 바이트를 넣은 뒤, 앞서 인코딩한 GetPLDMTypes 바이트 같은 PLDM 요청을 전송하는 순서입니다. 이 흐름은 MCTP를 켠 커널을 전제로 한 설명이며, 이 글의 테스트 환경에서는 실행하지 않았습니다.
자주 묻는 질문은 무엇입니까?
한 줄 답: 커널의 MCTP 제공 여부 확인 방법, 링크·주소 설정 시 필요한 권한, 그리고 Python에서의 AF_MCTP 소켓 생성 확인 범위를 정리했습니다.
커널에 MCTP가 있는지 어떻게 확인합니까?
socket(AF_MCTP, SOCK_DGRAM, 0) 호출이 Errno 97(Address family not supported by protocol)로 실패하면 실행 중인 커널이 MCTP를 제공하지 않는 상태이며, 이 글의 테스트 환경에서도 동일하게 확인했습니다.
root 권한이 필요합니까?
일반적으로 네트워크 링크·주소·경로 설정을 변경하는 작업에는 관리자 권한이 필요합니다.
Python으로도 해 볼 수 있습니까?
이 글에서는 AF_MCTP에 해당하는 상수 45를 사용해 소켓 생성만 시도해 보았으며, 이 커널에서는 Errno 97로 실패했습니다. 그 이후 동작은 이 글에서 테스트하지 않았습니다.
함께 보면 좋은 글은 무엇입니까?
한 줄 답: MCTP 패킷 헤더·EID·바인딩 원리와 PLDM 타입별 구조를 다룬 시리즈 이전 편입니다.
- 「MCTP·PLDM이란? 서버 장치 관리 구조와 MCTP 패킷·EID·바인딩 동작 원리」(시리즈 이전 편)
- 「PLDM 타입이란? Base·모니터링(PDR·센서)·펌웨어 업데이트·RDE 정리」(시리즈 이전 편)
출처는 어디입니까?
한 줄 답: 리눅스 커널 MCTP 문서와 CodeConstruct/mctp, openbmc/libpldm, openbmc/pldm 저장소입니다.
- Linux kernel docs, Management Component Transport Protocol (MCTP) (확인 2026-10-31)
- CodeConstruct/mctp (확인 2026-10-31)
- openbmc/libpldm (확인 2026-10-31)
- openbmc/pldm (확인 2026-10-31)
AF_MCTP is the socket address family used by the Linux kernel to expose the Management Component Transport Protocol (MCTP) to user space. Based on the Linux kernel docs, Management Component Transport Protocol (MCTP), this post covers how Linux MCTP sockets work, how the mctp utility and mctpd daemon differ, and how libpldm and OpenBMC's pldmd handle PLDM messages.
Summary
The Linux kernel provides MCTP as a network stack where applications open sockets via socket(AF_MCTP, SOCK_DGRAM, 0) and specify an EID and message type to exchange messages. The mctp command-line utility queries and configures links, addresses, and routes, while the mctpd daemon acts as the bus owner to assign EIDs to remote endpoints and manage routes and neighbour-table entries. The libpldm library encodes and decodes PLDM messages, and pldmd runs PLDM as a service in OpenBMC. In this post's test environment—where the kernel does not provide MCTP and returns Errno 97—we verify building the user-space tools (mctp, libpldm) and encoding a PLDM Base GetPLDMTypes request into bytes.
How does Linux provide MCTP via AF_MCTP?
One-line answer: The Linux kernel provides MCTP through the AF_MCTP (PF_MCTP) address family and SOCK_DGRAM sockets, using struct sockaddr_mctp to specify the network, EID, message type, and tag.
According to the Linux kernel MCTP documentation, on a kernel with MCTP support, applications use the AF_MCTP (or PF_MCTP) address family, and only SOCK_DGRAM sockets are supported. A socket is opened with protocol 0 via int sd = socket(AF_MCTP, SOCK_DGRAM, 0);. Physical interface drivers correspond to the "bindings" of DSP0236, and each interface ("link") is an instance of a binding.
The socket address structure struct sockaddr_mctp contains smctp_family, smctp_network, smctp_addr, smctp_type, and smctp_tag, along with wildcard constants MCTP_NET_ANY (0x0) and MCTP_ADDR_ANY (0xff). A receiving (request-handling) socket calls bind(). Below is the bind() example from the kernel documentation (kernel documentation example, not run here):
struct sockaddr_mctp addr;
addr.smctp_family = AF_MCTP;
addr.smctp_network = MCTP_NET_ANY;
addr.smctp_addr.s_addr = MCTP_ADDR_ANY;
addr.smctp_type = MCTP_TYPE_PLDM;
addr.smctp_tag = MCTP_TAG_OWNER;
int rc = bind(sd, (struct sockaddr *)&addr, sizeof(addr));A bound socket only receives messages with the TO (Tag Owner) bit set, meaning incoming requests; for bind(), the only valid smctp_tag value is MCTP_TAG_OWNER. Sending uses sendto(), sendmsg(), or send(), where the network and address fields define the remote address. When sending with MCTP_TAG_OWNER, the kernel generates a tag, and if no tag can be allocated the call reports EAGAIN. The application places the message type byte as the first byte of the buffer.
For the meaning of MCTP header fields, EIDs, and bindings, see "What are MCTP and PLDM? Server device management and how MCTP packets, EIDs and bindings work" (previous in series).
How do the mctp command and mctpd differ?
One-line answer: mctp is a command-line utility similar to iproute2's ip for querying and managing the kernel MCTP stack, whereas mctpd is an MCTP control protocol daemon that acts as a bus owner to assign EIDs and manage routes and neighbour-table entries.
According to the CodeConstruct/mctp README, mctp is a small command-line utility to query and manage the state of the kernel MCTP stack, similar to iproute2's ip. The subcommands listed in the README usage are link, address, route, neigh, and monitor. Below are syntax lines from the README (README usage text, not run output):
mctp link set <ifname> [up|down] [mtu <mtu>] [network <net>] [bus-owner <physaddr>]
mctp address add <eid> dev <ifname>
mctp route add <eid>[-<eid>] via <ifname> [mtu <mtu>]By contrast, mctpd is a daemon implementing the MCTP control protocol and is needed for the local host to act as bus owner. Its main job is assigning EIDs to remote endpoints and managing the resulting routes and neighbour-table entries. mctpd should run as a system service after interfaces are enabled and local addresses are assigned; it exposes a D-Bus interface and reads configuration from /etc/mctpd.conf by default. The project builds with Meson, and passing -Dtests=false skips test dependencies.
Where is PLDM handled?
One-line answer: The libpldm library handles encoding and decoding PLDM messages, while pldmd in the openbmc/pldm repository is the daemon that handles PLDM as a service in OpenBMC.
openbmc/libpldm is a PLDM encode/decode library. In its base.h header, the GetPLDMTypes command code is 0x4 and PLDM_GET_TYPES_REQ_BYTES is 0.
In the openbmc/pldm repository, meson.build builds an executable named pldmd (the OpenBMC PLDM daemon that handles PLDM as a service), and its README shows systemctl restart pldmd. For details on each PLDM type, see "What are PLDM types? Base, monitoring (PDRs and sensors), firmware update and RDE" (previous in series).
What was verified in this post's test environment?
One-line answer: Because the test machine's kernel does not provide AF_MCTP and fails with Errno 97 on socket creation, no packets were sent or received; verification covered building the user-space tools (mctp, libpldm) and encoding a GetPLDMTypes request into bytes.
Without changing kernel settings, we first checked whether the test machine's kernel provides AF_MCTP. Attempting to create a SOCK_DGRAM socket in python3 using constant 45 for AF_MCTP produced the following result (the ... line indicates omitted traceback lines):
$ python3 -c 'import socket; socket.socket(45, socket.SOCK_DGRAM)'
...
OSError: [Errno 97] Address family not supported by protocolBecause socket() failed with Errno 97 (Address family not supported by protocol), the running kernel does not provide AF_MCTP. Nothing was sent or received, no link, address, or route was configured, and neither mctpd nor pldmd was run.
Next, we cloned and built the user-space repository CodeConstruct/mctp (commit f3b843d) with -Dtests=false (the meson setup output is discarded and only the last ninja line is kept with tail -1):
$ git clone --depth 1 https://github.com/CodeConstruct/mctp src-mctp
$ (cd src-mctp && rm -rf build && meson setup build -Dtests=false >/dev/null && ninja -C build | tail -1)
[22/22] Linking target mctp
$ ls src-mctp/build | grep -E "^mctp"
mctp
mctp-bench
mctp-bench.p
mctp-client
mctp-client.p
mctp-echo
mctp-echo.p
mctp-req
mctp-req.p
mctp.pmctpd is not in the build output because the Meson log reports Run-time dependency libsystemd found: NO (tried pkg-config and cmake) and the project's meson.build only builds mctpd when libsystemd is found.
We then cloned and built openbmc/libpldm (commit be4f63e) the same way:
$ git clone --depth 1 https://github.com/openbmc/libpldm src-libpldm
$ (cd src-libpldm && rm -rf build && meson setup build -Dtests=false >/dev/null && ninja -C build | tail -1)
[33/33] Linking target bindings/cpp/libpldm++.so.0.18.0Using libpldm, we wrote a small C program (pldm_encode.c) whose comment notes that it encodes a PLDM Base (Type 0) GetPLDMTypes request message and prints the resulting bytes without any MCTP transmission:
/* libpldm로 PLDM Base(Type 0) "GetPLDMTypes" 요청 메시지를 인코딩해 바이트를 출력 (MCTP 전송 없음, 인코딩만) */
#include <libpldm/base.h>
#include <stdio.h>
#include <stdint.h>
int main(void) {
uint8_t buf[sizeof(struct pldm_msg_hdr) + PLDM_GET_TYPES_REQ_BYTES];
struct pldm_msg *msg = (struct pldm_msg *)buf;
int rc = encode_get_types_req(1 /* instance id */, msg);
printf("encode_get_types_req rc=%d len=%zu bytes:", rc, sizeof(buf));
for (size_t i = 0; i < sizeof(buf); i++) printf(" %02x", buf[i]);
printf("\n");
printf("request=%u instance_id=%u header_ver=%u pldm_type=%u command=0x%02x\n",
msg->hdr.request, msg->hdr.instance_id, msg->hdr.header_ver, msg->hdr.type, msg->hdr.command);
return rc;
}Building and running pldm_encode.c produced the following output:
$ gcc -std=c11 -Wall -Isrc-libpldm/include -Isrc-libpldm/build/include pldm_encode.c -Lsrc-libpldm/build/src -lpldm -o pldm_encode
$ env LD_LIBRARY_PATH=src-libpldm/build/src ./pldm_encode
encode_get_types_req rc=0 len=3 bytes: 81 00 04
request=1 instance_id=1 header_ver=0 pldm_type=0 command=0x04As the second output line states, the encoded 3-byte message (81 00 04) has header fields request=1, instance_id=1, header_ver=0, pldm_type=0, and command=0x04. The message was only encoded into the buffer and was not sent over MCTP.
What else is needed to communicate with a real MCTP device?
One-line answer: On a kernel with MCTP support and a physical binding driver, you bring the link up and configure the local EID and route with mctp, run mctpd as a system service, and send the encoded PLDM request bytes over an AF_MCTP socket.
On a kernel with MCTP support—built with MCTP enabled plus a binding driver such as I2C—you first bring the link up and configure a local address and route using mctp. Below are example commands (not run here, no output):
mctp link set <ifname> up
mctp address add <eid> dev <ifname>
mctp route add <eid> via <ifname>After the link and local address are configured, you run mctpd as a system service so that it acts as bus owner and assigns EIDs to remote endpoints. An application can then open an AF_MCTP socket and send a PLDM request—such as the encoded GetPLDMTypes bytes with the message type byte placed first in the buffer. This flow assumes a kernel with MCTP support and was not run in this post's test environment.
What are the frequently asked questions?
One-line answer: These questions cover how to check whether the running kernel provides MCTP, privilege requirements for configuring links and addresses, and what was tested from Python.
How do you check whether the kernel provides MCTP?
If socket(AF_MCTP, SOCK_DGRAM, 0) fails with Errno 97 (Address family not supported by protocol), the running kernel does not provide MCTP—as observed in this post's test.
Are root privileges required?
In general, changing network link, address, and route settings requires administrator privileges.
Can you try this from Python?
This post only tried creating the socket in Python with constant 45 for AF_MCTP, and it failed with Errno 97 on this kernel; beyond that, it is untested here.
What related posts are worth reading?
One-line answer: These previous parts of the series cover MCTP packet headers, EIDs, and bindings, as well as PLDM types and message flows.
- "What are MCTP and PLDM? Server device management and how MCTP packets, EIDs and bindings work" (previous in series)
- "What are PLDM types? Base, monitoring (PDRs and sensors), firmware update and RDE" (previous in series)
What are the sources?
One-line answer: The sources are the Linux kernel MCTP documentation and the CodeConstruct/mctp, openbmc/libpldm, and openbmc/pldm repositories.
- Linux kernel docs, Management Component Transport Protocol (MCTP) (checked 2026-10-31)
- CodeConstruct/mctp (checked 2026-10-31)
- openbmc/libpldm (checked 2026-10-31)
- openbmc/pldm (checked 2026-10-31)
