{"id":13490604,"url":"https://github.com/ipmitool/ipmitool","last_synced_at":"2025-10-21T06:24:05.661Z","repository":{"id":37663450,"uuid":"128686483","full_name":"ipmitool/ipmitool","owner":"ipmitool","description":"An open-source tool for controlling IPMI-enabled systems","archived":true,"fork":false,"pushed_at":"2023-02-09T08:10:10.000Z","size":3233,"stargazers_count":1286,"open_issues_count":147,"forks_count":364,"subscribers_count":48,"default_branch":"master","last_synced_at":"2024-09-26T03:40:56.738Z","etag":null,"topics":["dcmi","fru","ipmi","remote-control","sensors","serial-over-lan"],"latest_commit_sha":null,"homepage":"","language":"C","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/ipmitool.png","metadata":{"files":{"readme":"README","changelog":"ChangeLog","contributing":null,"funding":null,"license":"COPYING","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null}},"created_at":"2018-04-08T22:18:30.000Z","updated_at":"2024-09-23T19:42:56.000Z","dependencies_parsed_at":"2022-07-12T16:42:33.554Z","dependency_job_id":"74005e2a-9958-41fb-8c3a-0ec318e794b2","html_url":"https://github.com/ipmitool/ipmitool","commit_stats":{"total_commits":2133,"total_committers":106,"mean_commits":20.12264150943396,"dds":0.706516643225504,"last_synced_commit":"be11d948f89b10be094e28d8a0a5e8fb532c7b60"},"previous_names":[],"tags_count":28,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ipmitool%2Fipmitool","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ipmitool%2Fipmitool/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ipmitool%2Fipmitool/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/ipmitool%2Fipmitool/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/ipmitool","download_url":"https://codeload.github.com/ipmitool/ipmitool/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":234569711,"owners_count":18854133,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["dcmi","fru","ipmi","remote-control","sensors","serial-over-lan"],"created_at":"2024-07-31T19:00:49.315Z","updated_at":"2025-09-28T23:30:21.940Z","avatar_url":"https://github.com/ipmitool.png","language":"C","funding_links":[],"categories":["C","Green Software Awesome List","others"],"sub_categories":["Contents"],"readme":"\n                              ipmitool\n                            Duncan Laurie\n                ipmitool-devel@lists.sourceforge.net\n\nOverview\n========\nipmitool is a utility for managing and configuring devices that support\nthe Intelligent Platform Management Interface.  IPMI is an open standard\nfor monitoring, logging, recovery, inventory, and control of hardware\nthat is implemented independent of the main CPU, BIOS, and OS.  The\nservice processor (or Baseboard Management Controller, BMC) is the brain\nbehind platform management and its primary purpose is to handle the\nautonomous sensor monitoring and event logging features.\n\nThe ipmitool program provides a simple command-line interface to this BMC.\nIt features the ability to read the sensor data repository (SDR) and print\nsensor values, display the contents of the System Event Log (SEL), print\nField Replaceable Unit (FRU) inventory information, read and set LAN\nconfiguration parameters, and perform remote chassis power control.\n\n\nBackground\n==========\nI originally wrote ipmitool while between projects and employeed at Sun\nMicrosystems.  Sun had just embarked on a new line of general-purpose x86\nservers that included an OEM Intel board with an IPMIv1.5 BMC on board.\nIt started with an idea that remote chassis power control would be a handy\nfeature for my systems in the lab and from there it grew into a multi-\npurpose tool that lots of people found useful.  I decided to release it\nunder a BSD license and give others the chance to make use of it.\n\nipmitool was not written to provide large-scale (aka Enterprise) management\napplication functionality.  The functionality that ipmitool proivides is\neasily accomplished by sending simple IPMI request messages and parsing\nthe returned response.  It is intended to be used by system administrators\nwho like the simplicity and scriptability of command-line utilities, as\nwell as those debugging or developing their own BMC implementations.\n\n\nRequirements\n============\nObviously the largest requirement is hardware with a service processor\nthat supports the IPMI specification.  Many x86-based servers are now\ncoming with IPMI support, check with your preferred hardware vendor\nabout available products.\n\nOnce you are certain you have the required hardware, you then need to\ndecide how you want to access the BMC.  The most common case involve\naccess through the System Interface or over the LAN.  (or serial, but\ncurrently ipmitool does not support the serial interface)\n\n\nSystem Interface\n----------------\nThere are multiple types of system interfaces, but they are all similar\nenough to allow a single well-designed driver to support them all.  \nDifferent types of system interfaces include Keyboard Controller Style\n(KCS), Block Transfer (BT), System Management Interface Chip (SMIC) and\nSMBus.  Different hardware vendors will have different preference and\nimplementations.\n\nOn Linux the OpenIPMI kernel driver should support all of these system\ninterfaces and it should be a simple matter of loading the right\nkernel modules and setting up the device node to use it.  The driver\nmodule names vary slightly in different kernel versions, but for all\nreleases you need these two modules:\n\n  ipmi_msghandler: incoming and outgoing message handler\n  ipmi_devintf: character device interface to IPMI driver\n\nFor 2.4.x and early 2.6.x kernels you need to choose a module based on\nthe type of system interface your hardware supports.  For example:\n\n  ipmi_kcs_drv: Keyboard Controller Style driver\n\nMore recent 2.6.x kernels have combined these into a single module:\n\n  ipmi_si: a universal IPMI system interface driver\n\nSee the documentation that comes with your distribution and/or kernel\nfor more information on what kernel modules are required.  Once the\nrequired modules are loaded and the driver has found a suitable system\ninterface to the BMC then you need to ensure the device node at\n/dev/ipmi0 is pointing at the correct major number.\n\nThis is because OpenIPMI is given a dynamically assigned major number\nwhen it is loaded, but depending on what other modules are present\nthis number may be anywhere from 254 on down.  The easiest way to tell\nis to check the output of /proc/devices and see what major number the\n\"ipmidev\" device is assigned to.\n\nThere is a sample script included with ipmitool called ipmi.init that\ncan be used to automate this process at bootup.\n\n\nLAN Interface\n-------------\nThis is often referred to as \"IPMI-over-LAN\" and defines how IPMI messages\ncan be sent to and from the BMC encapsulated in Remote Management Control\nProtocol (RMCP) packets which are then transferred as UDP datagrams.\n\nIPMI-over-LAN is only supported with version 1.5 and higher of the IPMI\nspecification.  The RMCP packet format is defined by the Alert Standard\nForum, and it has been followed up with the RMCP+ protocol that adds\nencryption and payload support.  The IPMIv2 specification was updated\naccordingly to to support the RMCP+ protocol and brings with it enhanced\nsecurity with encryption as well as support for Serial over LAN.\n\nThere are different types of LAN interfaces as well.  Some systems have\nshared management networks where the NIC will intercept UDP packets to\nport 623 and redirect them to the BMC over SMBUS.  This type of LAN\ninterface requires that the BMC be configured with the same settings that\nthe system uses.  It also suffers from an increased security risk just by\nthe nature of sharing that interface with normal traffic.\n\nI have also seen bugs in some implementations that have rendered the\nIPMI-over-LAN feature \"dangerous\" to enable in some situations.  (in\nparticular there can be an issue with RPC because it will sometimes choose\nto use port 623 and you will lose response packets...)\n\nThere is a sample shell script included with ipmitool called bmclanconf\nthat can be used to simplify the LAN settings configuration process using\nthe System Interface to configure the settings.  In some cases the\nhardware will come with a utility (often a DOS bootable CD) for configuring\nenabling the LAN interface as well.\n\nIn order to support the IPMIv2.0 interface you must have an OpenSSL library\nwith the required encryption functions.  Recent distributions should have\nno problems.  The IPMIv1.5 interface will attempt to use OpenSSL for MD5\nhash function at compile time but if that is not found it will use an\ninternal library.\n\nIPMB Dual Bridging in  IPMITOOL\n-------------------------------\n\nIPMI offers a standard messaging interface.\n\nThe following concepts are related to this messaging interface:\n\nChannel type     : Communication channel type (SMS/KCS, IPMB, LAN) \nChannel number   : Channel descriptor\nRequester        : Address of the requester\nResponder        : Address of the responder\nNetFN            : The logical function  for the request/response.\nCommand          : The command number \nSequence         : An ID identifiying the request/response pair\nMessage tracking : The ability to match request/response pair.\n\nWhen a communication is issued through any of the channels, an application \nformats a request and expect a response. \n\nDirect Command\n--------------\nThe simplest form of communication is a \"direct command\" using SMS/KCS\n\nExample:\n ipmitool raw 6 4\n  55 00\n\nThis send raw command 4 (selftest) from netfn 6(application) to KCS, the driver \ntakes care of 'message tracking' and provides the answer.\n\nHopefully, the application also includes a \"human readable\" instance of the API:\n ipmitool mc selftest\n Selftest: passed\n\nBridged Command\n---------------\nOne slightly more complicated communication mode is the so-called \n\"bridged command\" using IPMB. \n\nExample:\n ipmitool -m 0x94 -t 0x9a raw 6 4\n 55 00\n \n or\n \n ipmitool -m 0x94 -t 0x9a mc selftest\n Selftest: passed\n \n\nThis still sends the same command  4 (selftest) from netfn 6(application) to \nthe target. However, to do so, the command is encapsulated (by the driver) and\nsent using the command 0x34 (send message) from netfn 6(application) to KCS. \nThen KCS is polled by the driver until a message has been received, then the\ndriver uses command 0x33 (get message). The driver also tracks the message \nand makes sure the response matches the request. Then it decapsultates the\nmessage and gives the response back to the application.\n\nDual Bridged Command\n--------------------\nThings get a little more ugly when the application needs to reach a management\ncontroller sitting on an interface (or channel) not directly connected to the \nBMC/IPMC. In the case the application must encapsulate its message itself and \nrequest the IPMC to deal with message tracking itself.\n\nIts been working well with IPMITOOL on the LAN interface with:\n ipmitool -H \u003cip\u003e -U \u003cuser\u003e -P \u003cpassword\u003e -B 0 -T 0x8a  -m 0x20 -t 0x7a -b 7  \n    mc selftest\n\nHowever, trying to dual bridge commands locally with :\n ipmitool -B 0 -T 0x9a -m 0x94 -t 0x7a -b 7 mc selftest didn't work \n (it returned the same data as  ipmitool -m 0x20 -t 0x7a -b 7 mc selftest )\n \nThe reason was that the \"openipmi\" interface pluging didn't \nencapsulate/decapsulate the message and didn't even detect the intent\nto double bridge the request.\n\n ./src/ipmitool -B 0 -T 0x8a -m 0x94 -t 0x7a -b 7 mc selftest\n \n-B    0  : transit channel for first bridge level (channel 0: IPMB-0) \n-T 0x8a  : transit destination address (remote IPMC address)\n-m 0x94  : source address (local IPMC address on IPMB-0)\n-t 0x7a  : remote target (AMC IPMB-L address)\n-b    7  : remote channel (channel 7: IPMB-L)\n\nThe transit source address (remote IPMC address on remote channel) is \nautomatically assigned by the remote IPMC.\n\nPayload Size Limit\n------------------\nBecause some commands return a lot of data (fru read/get sdr) and because 2 \nlevels of encapsulation are used, some command will fail.\n\nFor instance this works.\n\nipmitool -H \u003cip\u003e -U \u003cuser\u003e -P \u003cpassword\u003e  -B 0 -T 0x8a  -m 0x94 -t 0x7a -b 7 \n    mc selftest\n\nbut this does not:\n    \nipmitool -H \u003cip\u003e -U \u003cuser\u003e -P \u003cpassword\u003e  -B 0 -T 0x8a  -m 0x94 -t 0x7a -b 7 \n    fru print.\n\n\n\nUsage\n=====\nAll invocations of ipmitool require specifying an interface to use, unless\nyou want to use the default interface as set at compile time.  Each call\nmust also specify a command to run.  You can see the list of supported\ninterfaces and which is default as well as a list of top level commands in\nthe usage output available with the -h option:\n\nusage: ipmitool [options...] \u003ccommand\u003e\n\n   -h            This help\n   -V            Show version information\n   -v            Verbose (can use multiple times)\n   -c            Display output in comma separated format\n   -I intf       Interface to use\n   -H hostname   Remote host name for LAN interface\n   -p port       Remote RMCP port [default=623]\n   -L level      Remote session privilege level [default=USER]\n   -A authtype   Force use of authtype NONE, PASSWORD, MD2 or MD5\n   -U username   Remote session username\n   -P password   Remote session password\n   -f file       Read remote session password from file\n   -a            Prompt for remote password\n   -E            Read password from IPMI_PASSWORD environment variable\n   -m address    Set local IPMB address\n   -t address    Bridge request to remote target address\n\nInterfaces:\n    open         Linux OpenIPMI Interface [default]\n    imb          Intel IMB Interface\n    lan          IPMI v1.5 LAN Interface\n    lanplus      IPMI v2.0 RMCP+ LAN Interface\n\nCommands:\n    raw          Send a RAW IPMI request and print response\n    lan          Configure LAN Channels\n    chassis      Get chassis status and set power state\n    event        Send pre-defined events to BMC\n    bmc          Print BMC status and configure global enables\n    sdr          Print Sensor Data Repository entries and readings\n    sensor       Print detailed sensor information\n    fru          Print built-in FRU and scan SDR for FRU locators\n    sel          Print System Evelnt Log\n    sol          Configure IPMIv2.0 Serial-over-LAN\n    user         Configure BMC users\n    channel      Configure BMC channels\n    session      Print session information\n    shell        Launch interactive IPMI shell\n    exec         Run list of commands from file\n    set          Set runtime variable for shell and exec\n\n\nCommands\n========\nMore help on the supported commands can be found by running them with the\nhelp argument, for example \"chassis help\".  There are a few commands with\nspecial meaning:\n\n\u003e shell:  This command will launch an shell interface to the ipmitool\n  command set.  You can use this for interactively entering commands to\n  monitor system status.  An example session:\n\n# ipmitool -I open shell\nipmitool\u003e chassis status\nSystem Power         : off\nPower Overload       : false\nPower Interlock      : inactive\nMain Power Fault     : false\nPower Control Fault  : false\nPower Restore Policy : always-off\nLast Power Event     : command\nChassis Intrusion    : active\nFront-Panel Lockout  : inactive\nDrive Fault          : false\nCooling/Fan Fault    : false\nipmitool\u003e user list 7\nID  Name             Callin  Link Auth  IPMI Msg   Channel Priv Limit\n1                    true    false      true       ADMINISTRATOR\nipmitool\u003e exit\n\n\u003e exec:  This command will read a text file and execute ipmitool commands\n  in sequence.  It can be used for scriptable commands:\n\n# cat lansetup.scr\nlan set 7 ipsrc static\nlan set 7 ipaddr 10.1.1.10\nlan set 7 netmask 255.255.255.0\nlan set 7 defgw ipaddr 10.1.1.254\n# ipmitool -I open exec lansetup.scr\nSetting LAN IP Address to 10.1.1.10\nSetting Lan Subnet Mask to 255.255.255.0\nSetting Lan Default Gateway IP to 10.1.1.254\n\n\u003e set:  This command can be used by the shell and exec modes to configure\n  various session parameters:\n\n  hostname \u003chost\u003e        Session hostname\n  username \u003cuser\u003e        Session username\n  password \u003cpass\u003e        Session password\n  privlvl \u003clevel\u003e        Session privilege level force\n  authtype \u003ctype\u003e        Authentication type force\n  localaddr \u003caddr\u003e       Local IPMB address\n  targetaddr \u003caddr\u003e      Remote target IPMB address\n  port \u003cport\u003e            Remote RMCP port\n  csv [level]            enable output in comma separated format\n  verbose [level]        Verbose level\n\n# cat getstatus.scr\nset hostname sf-v20z-1\nset password admin\nchassis status\n# ipmitool -I lan exec getstatus.scr\nSet session hostname to lx50\nSet session password\nSystem Power         : off\nPower Overload       : false\nPower Interlock      : inactive\nMain Power Fault     : false\nPower Control Fault  : false\nPower Restore Policy : always-off\nLast Power Event     : command\nChassis Intrusion    : active\nFront-Panel Lockout  : inactive\nDrive Fault          : false\nCooling/Fan Fault    : false\n\n\nipmievd\n=======\nIncluded with ipmitool is another utility called ipmievd that is a daemon\nwhich will listen for events from the BMC that are being sent to the SEL\nand also log those messages to syslog.  By default when run (as root) with\nno arguments it will daemonize and poll on the OpenIPMI device waiting for\nan event notification.  Upon receipt of an event it will log it to syslog\nwith the LOG_LOCAL4 facility.  You can test ipmievd by sending test events\nover the LAN interface with ipmitool:\n\nremote# ipmievd\n\nlocal$ ipmitool -I lan -H lx50 -P admin event help\nusage: event \u003cnum\u003e\n   1 : Temperature - Upper Critical - Going High\n   2 : Voltage Threshold - Lower Critical - Going Low\n   3 : Memory - Correctable ECC\nlocal$ ipmitool -I lan -H lx50 -P admin event 1\nSending Temperature - Upper Critical - Going High event to BMC\nlocal$ ipmitool -I lan -H lx50 -P admin event 2\nSending Voltage Threshold - Lower Critical - Going Low event to BMC\nlocal$ ipmitool -I lan -H lx50 -P admin event 3\nSending Memory - Correctable ECC event to BMC\n\nremote# tail /var/log/messages   (timestamps removed)\nipmievd: Waiting for events...\nipmievd: Temperature Sensor 30 - Upper Critical - going high\nipmievd: Voltage Sensor 60 - Lower Critical - going low\nipmievd: Memory Sensor 01 - Correctable ECC\n\n\nResources\n=========\nIPMItool homepage\nhttp://github.com/ipmitool/ipmitool\n\nIPMItool manpage\nhttps://github.com/ipmitool/ipmitool/blob/master/doc/ipmitool.1.in\n\nIntelligent Platform Management Interface specification\nhttps://www.intel.com/content/www/us/en/servers/ipmi/ipmi-home.html\n\nOpenIPMI project: Linux IPMI kernel driver and userland library\nhttp://openipmi.sourceforge.net\n\nIPMItool commit archive\nhttps://lists.sourceforge.net/lists/listinfo/ipmitool-cvs\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fipmitool%2Fipmitool","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fipmitool%2Fipmitool","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fipmitool%2Fipmitool/lists"}