1ipmimonitoring(8)               System Commands              ipmimonitoring(8)
2
3
4

NAME

6       ipmimonitoring - IPMI monitoring utility
7

SYNOPSIS

9       ipmimonitoring [OPTION...]
10

DESCRIPTION

12       ipmimonitoring  is  an  IPMI sensor monitoring tool that reports a sen‐
13       sor's record id, sensor name, sensor type name,  sensor  state,  sensor
14       reading (if appropriate), and the current sensor event.
15
16       Unlike  ipmi-sensors(8),  ipmimonitoring will also report a sensor in a
17       NOMINAL, WARNING, or CRITICAL state.  The sensor  state  is  an  inter‐
18       preted value based on the current sensor event. By mapping sensor read‐
19       ings into NOMINAL, WARNING, or CRITICAL  states,  it  makes  monitoring
20       easier  across  large numbers of nodes. For more general sensor reading
21       use, it is recommended that users use ipmi-sensors(8).
22
23       The sensor state interpretations are determined  by  the  configuration
24       file    /etc/ipmi_monitoring_sensors.conf.   See   ipmi_monitoring_sen‐
25       sors.conf(5) for more information  on  configuring  sensor  interpreta‐
26       tions.  Interpretation rules have not been written for all sensors per‐
27       mutations and types. Subsequently,  there  may  be  output  differences
28       between  ipmi-sensors(8) and ipmimonitoring when sensor interpretations
29       are not  available.  If  additional  sensor  interpretation  rules  are
30       needed, please contact the FreeIPMI maintainers. Default interpretation
31       rules may not be correct for a given motherboard. Users  should  verify
32       that the default settings match their expectations.
33
34       Some  sensors may have a sensor state, reading or event of "N/A" if the
35       information is unavailable. This is typical of a  sensor  that  is  not
36       enabled or not owned by a BMC. Please see --bridge-sensors option below
37       to deal with sensors not owned by a BMC. Sensors need not always report
38       a  sensor event. When a sensor event is not present, "NONE" is reported
39       for the sensor event.
40
41       Listed below are general IPMI options, tool specific  options,  trouble
42       shooting  information,  workaround  information,  examples,  and  known
43       issues. For a general introduction to FreeIPMI please see freeipmi(7).
44

GENERAL OPTIONS

46       The following options are general options for configuring IPMI communi‐
47       cation and executing general tool commands.
48
49       -D, --driver-type=IPMIDRIVER
50              Specify  the  driver type to use instead of doing an auto selec‐
51              tion.  The currently available outofband  drivers  are  LAN  and
52              LAN_2_0,  which  perform IPMI 1.5 and IPMI 2.0 respectively. The
53              currently available inband drivers are KCS, SSIF, OPENIPMI,  and
54              SUNBMC.
55
56       --disable-auto-probe
57              Do not probe in-band IPMI devices for default settings.
58
59       --driver-address=DRIVER-ADDRESS
60              Specify  the  in-band  driver  address to be used instead of the
61              probed value. DRIVER-ADDRESS should be prefixed with "0x" for  a
62              hex value and '0' for an octal value.
63
64       --driver-device=DEVICE
65              Specify the in-band driver device path to be used instead of the
66              probed path.
67
68       --register-spacing=REGISTER-SPACING
69              Specify the in-band  driver  register  spacing  instead  of  the
70              probed value.
71
72       -h, --hostname=IPMIHOST1,IPMIHOST2,...
73              Specify  the  remote host(s) to communicate with. Multiple host‐
74              names may be separated by comma or may be specified in  a  range
75              format; see HOSTRANGED SUPPORT below.
76
77       -u, --username=USERNAME
78              Specify  the username to use when authenticating with the remote
79              host.  If not specified, a null  (i.e.  anonymous)  username  is
80              assumed. The user must have atleast OPERATOR privileges in order
81              for this tool to operate fully.
82
83       -p, --password=PASSWORD
84              Specify the password to use when authenticationg with the remote
85              host.   If  not  specified,  a null password is assumed. Maximum
86              password length is 16 for IPMI 1.5 and 20 for IPMI 2.0.
87
88       -P, --password-prompt
89              Prompt for password  to  avoid  possibility  of  listing  it  in
90              process lists.
91
92       -k, --k-g=K_G
93              Specify  the  K_g  BMC  key  to use when authenticating with the
94              remote host for IPMI 2.0.  If  not  specified,  a  null  key  is
95              assumed. To input the key in hexadecimal form, prefix the string
96              with '0x'. E.g., the key 'abc' can be entered  with  the  either
97              the string 'abc' or the string '0x616263'
98
99       -K, --k-g-prompt
100              Prompt  for  k-g  to  avoid possibility of listing it in process
101              lists.
102
103       --session-timeout=MILLISECONDS
104              Specify the session timeout in milliseconds. Defaults  to  20000
105              milliseconds (20 seconds) if not specified.
106
107       --retransmission-timeout=MILLISECONDS
108              Specify  the  packet  retransmission  timeout  in  milliseconds.
109              Defaults to 1000 milliseconds (1 second) if not  specified.  The
110              retransmission  timeout  cannot be larger than the session time‐
111              out.
112
113       -a, --authentication-type=AUTHENTICATION-TYPE
114              Specify the IPMI 1.5 authentication type to use.  The  currently
115              available  authentication types are NONE, STRAIGHT_PASSWORD_KEY,
116              MD2, and MD5. Defaults to MD5 if not specified.
117
118       -I, --cipher-suite-id=CIPHER-SUITE-ID
119              Specify the IPMI 2.0 cipher suite ID to use. The Cipher Suite ID
120              identifies a set of authentication, integrity, and confidential‐
121              ity algorithms to use for IPMI 2.0 communication. The  authenti‐
122              cation  algorithm  identifies  the  algorithm to use for session
123              setup, the integrity algorithm identifies the algorithm  to  use
124              for session packet signatures, and the confidentiality algorithm
125              identifies the algorithm to use for payload encryption. Defaults
126              to  cipher  suite  ID  3  if not specified. The following cipher
127              suite ids are currently supported:
128
129              0 - Authentication Algorithm = None; Integrity Algorithm = None;
130              Confidentiality Algorithm = None
131
132              1  - Authentication Algorithm = HMAC-SHA1; Integrity Algorithm =
133              None; Confidentiality Algorithm = None
134
135              2 - Authentication Algorithm = HMAC-SHA1; Integrity Algorithm  =
136              HMAC-SHA1-96; Confidentiality Algorithm = None
137
138              3  - Authentication Algorithm = HMAC-SHA1; Integrity Algorithm =
139              HMAC-SHA1-96; Confidentiality Algorithm = AES-CBC-128
140
141              6 - Authentication Algorithm = HMAC-MD5; Integrity  Algorithm  =
142              None; Confidentiality Algorithm = None
143
144              7  -  Authentication Algorithm = HMAC-MD5; Integrity Algorithm =
145              HMAC-MD5-128; Confidentiality Algorithm = None
146
147              8 - Authentication Algorithm = HMAC-MD5; Integrity  Algorithm  =
148              HMAC-MD5-128; Confidentiality Algorithm = AES-CBC-128
149
150              11  - Authentication Algorithm = HMAC-MD5; Integrity Algorithm =
151              MD5-128; Confidentiality Algorithm = None
152
153              12 - Authentication Algorithm = HMAC-MD5; Integrity Algorithm  =
154              MD5-128; Confidentiality Algorithm = AES-CBC-128
155
156       -l, --privilege-level=PRIVILEGE-LEVEL
157              Specify  the privilege level to be used. The currently available
158              privilege levels are USER,  OPERATOR,  and  ADMIN.  Defaults  to
159              OPERATOR if not specified.
160
161       --config-file=FILE
162              Specify an alternate configuration file.
163
164       -W, --workaround-flags=WORKAROUNDS
165              Specify  workarounds to vendor compliance issues. Multiple work‐
166              arounds can be specified separated by  commas.  See  WORKAROUNDS
167              below for a list of available workarounds.
168
169       --debug
170              Turn on debugging.
171
172       -?, --help
173              Output a help list and exit.
174
175       --usage
176              Output a usage message and exit.
177
178       -V, --version
179              Output the program version and exit.
180

IPMIMONITORING OPTIONS

182       The following options are specific to Ipmimonitoring.
183
184       -v, --verbose
185              Increase verbosity in output. This option will output additional
186              sensors that are generally unreadable or uninterpretable.
187
188       -q, --quiet-readings
189              Do not output sensor reading values by default. This  option  is
190              particularly  useful if you want to use hostranged output across
191              a cluster and want to consolidate the output.
192
193       -r "RECORD-IDS-LIST", --record-ids="RECORD-IDS-LIST"
194              Specify sensors to show by record id. Multiple record ids can be
195              separated  by  commas or spaces. If both --record-ids and --sen‐
196              sor-types are specified, --record-ids takes precedence.  A  spe‐
197              cial  command  line record id of "all", will indicate all record
198              ids should be shown (may be  useful  for  overriding  configured
199              defaults).
200
201       -R "RECORD-IDS-LIST", --exclude-record-ids="RECORD-IDS-LIST"
202              Specify  sensors  to  not show by record id. Multiple record ids
203              can be separated by commas or spaces.  A  special  command  line
204              record  id  of  "none",  will  indicate  no record ids should be
205              excluded (may be useful for overriding configured defaults).
206
207       -t "SENSOR-TYPE-LIST", --sensor-types=SENSOR-TYPE-LIST
208              Specify sensor types to show sensor outputs for. Multiple  types
209              can  be  separated by commas or spaces. If both --record-ids and
210              --sensor-types are specified, --record-ids takes precedence.   A
211              special  command  line  type  of  "all", will indicate all types
212              should  be  shown  (may  be  useful  for  overriding  configured
213              defaults).
214
215       -T "SENSOR-TYPE-LIST", --exclude-sensor-types=SENSOR-TYPE-LIST
216              Specify  sensor  types  to not show sensor outputs for. Multiple
217              types can be eparated by commas or  spaces.  A  special  command
218              line  type  of "none", will indicate no types should be excluded
219              (may be useful for overriding configured defaults).
220
221       -L, --list-sensor-types
222              List sensor types.
223
224       -b, --bridge-sensors
225              By default, sensors readings are not attempted  for  sensors  on
226              non-BMC  owners.  By setting this option, sensor requests can be
227              bridged to non-BMC owners to obtain sensor readings  (experimen‐
228              tal). Bridging may not work on some interfaces/driver types.
229
230       --shared-sensors
231              Some  sensors  share  the same sensor data record (SDR). This is
232              typically utilized for system event log (SEL)  entries  and  not
233              for  sensor readings. However, there may be some motherboards in
234              which this format is utilized for multiple  active  sensors,  or
235              the  user  simply  has  interest  in  seeing  the permutation of
236              entries shared by a SDR entry. By setting this option, each sen‐
237              sor number shared by a record will be iterated over and output.
238
239       --interpret-oem-data
240              Attempt  to interpret OEM data, such as event data, sensor read‐
241              ings, or general extra info, etc. If an  OEM  interpretation  is
242              not available, the default output will be generated. Correctness
243              of OEM interpretations cannot be  guaranteed  due  to  potential
244              changes OEM vendors may make in products, firmware, etc. See OEM
245              INTERPRETATION below for confirmed supported motherboard  inter‐
246              pretations.
247
248       --ignore-non-interpretable-sensors
249              Ignore  non-interpretable  sensors  in  output. Although usually
250              identical,   this   is   semantically   different    that    the
251              --ignore-na-sensors  option in ipmi-sensors(8).  For example, if
252              an interpretation rule has not been written for a sensor, it may
253              not be output.
254
255       --entity-sensor-names
256              Output  sensor  names prefixed with their entity id and instance
257              number when appropriate. This may be necessary on  some  mother‐
258              boards  to help identify what sensors are referencing. For exam‐
259              ple, a motherboard may have multiple sensors named  'TEMP'.  The
260              entity  id  and  instance  number  may help clarify which sensor
261              refers to "Processor 1" vs. "Processor 2".
262
263       --no-sensor-type-output
264              Do not show sensor type output for each entry. On many  systems,
265              the sensor type is redundant to the name of the sensor. This can
266              especially be true if --entity-sensor-names  is  specified.   If
267              the  sensor  name  is sufficient, or if the sensor type is of no
268              interest to the user, this option can be specified  to  condense
269              output.
270
271       --comma-separated-output
272              Output fields in comma separated format.
273
274       --no-header-output
275              Do not output column headers. May be useful in scripting.
276
277       --non-abbreviated-units
278              Output  non-abbreviated  units (e.g. 'Amps' instead of 'A'). May
279              aid  in  disambiguation  of  units  (e.g.  'C'  for  Celsius  or
280              Coulombs).
281
282       --legacy-output
283              Output  in legacy format. Newer options may not be applicable to
284              leagcy output.
285
286       --sensor-config-file=FILE
287              Specify an alternate sensor configuration file.
288

SDR CACHE OPTIONS

290       This tool requires access to the sensor data repository (SDR) cache for
291       general  operation.  By default, SDR data will be downloaded and cached
292       on the local machine. The following options apply to the SDR cache.
293
294       -f, --flush-cache
295              Flush a cached version  of  the  sensor  data  repository  (SDR)
296              cache. The SDR is typically cached for faster subsequent access.
297              However, it may need to be flushed and re-generated if  the  SDR
298              has been updated on a system.
299
300       -Q, --quiet-cache
301              Do  not output information about cache creation/deletion. May be
302              useful in scripting.
303
304       --sdr-cache-directory=DIRECTORY
305              Specify an alternate directory for sensor data repository  (SDR)
306              caches to be stored or read from. Defaults to the home directory
307              if not specified.
308
309       --sdr-cache-recreate
310              If the SDR cache is out of date or invalid, automatically recre‐
311              ate  the  sensor data repository (SDR) cache. This option may be
312              useful for scripting purposes.
313

HOSTRANGED OPTIONS

315       The following options manipulate hostranged output. See HOSTRANGED SUP‐
316       PORT below for additional information on hostranges.
317
318       -B, --buffer-output
319              Buffer  hostranged output. For each node, buffer standard output
320              until the node has completed its IPMI operation. When specifying
321              this  option, data may appear to output slower to the user since
322              the the entire IPMI operation must complete before any data  can
323              be output.  See HOSTRANGED SUPPORT below for additional informa‐
324              tion.
325
326       -C, --consolidate-output
327              Consolidate hostranged output. The complete standard output from
328              every  node  specified  will  be consolidated so that nodes with
329              identical output are not output twice. A header will list  those
330              nodes  with  the consolidated output. When this option is speci‐
331              fied, no output can be seen until the  IPMI  operations  to  all
332              nodes  has  completed.  If  the  user  breaks out of the program
333              early, all currently consolidated output  will  be  dumped.  See
334              HOSTRANGED SUPPORT below for additional information.
335
336       -F, --fanout
337              Specify  multiple  host  fanout.  A "sliding window" (or fanout)
338              algorithm is used for parallel IPMI communication so that slower
339              nodes or timed out nodes will not impede parallel communication.
340              The maximum number of threads available at the same time is lim‐
341              ited by the fanout. The default is 64.
342
343       -E, --eliminate
344              Eliminate  hosts  determined  as undetected by ipmidetect.  This
345              attempts to remove the common issue of hostranged execution tim‐
346              ing  out  due  to  several nodes being removed from service in a
347              large cluster. The ipmidetectd daemon must  be  running  on  the
348              node executing the command.
349
350       --always-prefix
351              Always prefix output, even if only one host is specified or com‐
352              municating in-band. This option is primarily useful for  script‐
353              ing  purposes.  Option  will be ignored if specified with the -C
354              option.
355

HOSTRANGED SUPPORT

357       Multiple hosts can be input either as an explicit comma separated lists
358       of  hosts  or  a  range of hostnames in the general form: prefix[n-m,l-
359       k,...], where n < m and l < k, etc. The later form should not  be  con‐
360       fused  with  regular expression character classes (also denoted by []).
361       For example, foo[19] does not represent foo1 or foo9, but rather repre‐
362       sents a degenerate range: foo19.
363
364       This  range  syntax  is  meant only as a convenience on clusters with a
365       prefixNN naming convention and specification of ranges  should  not  be
366       considered  necessary -- the list foo1,foo9 could be specified as such,
367       or by the range foo[1,9].
368
369       Some examples of range usage follow:
370           foo[01-05] instead of foo01,foo02,foo03,foo04,foo05
371           foo[7,9-10] instead of foo7,foo9,foo10
372           foo[0-3] instead of foo0,foo1,foo2,foo3
373
374       As a reminder to the reader, some shells will interpret brackets ([ and
375       ])  for  pattern matching. Depending on your shell, it may be necessary
376       to enclose ranged lists within quotes.
377
378       When multiple hosts are specified by the user, a thread  will  be  exe‐
379       cuted  for each host in parallel up to the configured fanout (which can
380       be adjusted via the -F option). This will allow communication to  large
381       numbers of nodes far more quickly than if done in serial.
382
383       By  default,  standard  output  from each node specified will be output
384       with the hostname prepended to each line. Although this output is read‐
385       able  in  many  situations, it may be difficult to read in other situa‐
386       tions. For example, output from multiple nodes may be  mixed  together.
387       The -B and -C options can be used to change this default.
388
389       In-band  IPMI  Communication  will be used when the host "localhost" is
390       specified. This allows the user to add  the  localhost  into  the  hos‐
391       tranged output.
392

GENERAL TROUBLESHOOTING

394       Most  often,  IPMI  problems  are due to configuration problems. Inband
395       IPMI problems are typically caused by improperly configured drivers  or
396       non-standard BMCs. IPMI over LAN problems involve a misconfiguration of
397       the remote machine's BMC.  Double check to make sure the following  are
398       configured  properly  in  the  remote  machine's  BMC:  IP address, MAC
399       address, subnet mask, username, user enablement, user privilege,  pass‐
400       word,   LAN  privilege,  LAN  enablement,  and  allowed  authentication
401       type(s). For IPMI 2.0 connections, double check to make sure the cipher
402       suite  privilege(s)  and  K_g key are configured properly. The bmc-con‐
403       fig(8) tool can be used to check and/or change these configuration set‐
404       tings.
405
406       The following are common issues for given error messages:
407
408       "username  invalid"  - The username entered (or a NULL username if none
409       was entered) is not available on the remote machine.  It  may  also  be
410       possible the remote BMC's username configuration is incorrect.
411
412       "password  invalid"  - The password entered (or a NULL password if none
413       was entered) is not correct. It may also be possible the  password  for
414       the user is not correctly configured on the remote BMC.
415
416       "password  verification timeout" - Password verification has timed out.
417       A "password invalid" error (described  above)  or  a  generic  "session
418       timeout" (described below) occurred.  During this point in the protocol
419       it cannot be differentiated which occurred.
420
421       "k_g invalid" - The K_g key entered (or a NULL  K_g  key  if  none  was
422       entered)  is  not  correct.  It may also be possible the K_g key is not
423       correctly configured on the remote BMC.
424
425       "privilege level insufficient" - An IPMI command requires a higher user
426       privilege  than  the one authenticated with. Please try to authenticate
427       with a higher privilege. This may require authenticating to a different
428       user which has a higher maximum privilege.
429
430       "privilege  level  cannot  be  obtained  for this user" - The privilege
431       level you are attempting to authenticate with is higher than the  maxi‐
432       mum  allowed for this user. Please try again with a lower privilege. It
433       may also be possible the maximum privilege level allowed for a user  is
434       not configured properly on the remote BMC.
435
436       "authentication  type  unavailable for attempted privilege level" - The
437       authentication type you wish to authenticate with is not available  for
438       this privilege level. Please try again with an alternate authentication
439       type or alternate privilege level. It may also be possible  the  avail‐
440       able  authentication  types you can authenticate with are not correctly
441       configured on the remote BMC.
442
443       "cipher suite id unavailable" - The cipher suite id you wish to authen‐
444       ticate  with  is not available on the remote BMC. Please try again with
445       an alternate cipher suite id. It may also  be  possible  the  available
446       cipher suite ids are not correctly configured on the remote BMC.
447
448       "ipmi  2.0  unavailable"  -  IPMI  2.0 was not discovered on the remote
449       machine. Please try to use IPMI 1.5 instead.
450
451       "connection timeout" - Initial IPMI communication failed. A  number  of
452       potential errors are possible, including an invalid hostname specified,
453       an IPMI IP address cannot be resolved,  IPMI  is  not  enabled  on  the
454       remote  server,  the network connection is bad, etc. Please verify con‐
455       figuration and connectivity.
456
457       "session timeout" - The IPMI session has timed out.  Please  reconnect.
458       If this error occurs often, you may wish to increase the retransmission
459       timeout. Some remote BMCs are considerably slower than others.
460
461       "device not found" - The specified device could not  be  found.  Please
462       check configuration or inputs and try again.
463
464       "driver  timeout"  -  Communication with the driver or device has timed
465       out. Please try again.
466
467       "message timeout" - Communication with the driver or device  has  timed
468       out. Please try again.
469
470       "BMC  busy"  - The BMC is currently busy. It may be processing informa‐
471       tion or have too many simultaneous sessions to manage. Please wait  and
472       try again.
473
474       "could  not  find inband device" - An inband device could not be found.
475       Please check configuration or specify specific device or driver on  the
476       command line.
477
478       Please  see  WORKAROUNDS below to also if there are any vendor specific
479       bugs that have been discovered and worked around.
480

IPMIMONITORING TROUBLESHOOTING

482       The following are common issues for given error  messages  specifically
483       for ipmimonitoring.
484
485       "sensor  config  file  parse  error"  -  A parse error was found in the
486       libipmimonitoring(3) sensor configuration file. Please see libipmimoni‐
487       toring(3).
488

WORKAROUNDS

490       With  so  many different vendors implementing their own IPMI solutions,
491       different vendors may implement their IPMI protocols  incorrectly.  The
492       following  lists  the workarounds currently available to handle discov‐
493       ered compliance issues.
494
495       When possible, workarounds have been implemented so they will be trans‐
496       parent  to  the  user. However, some will require the user to specify a
497       workaround be used via the -W option.
498
499       The hardware listed below may only indicate the hardware that a problem
500       was  discovered  on.  Newer  versions  of hardware may fix the problems
501       indicated below. Similar machines from vendors may or may  not  exhibit
502       the  same  problems.  Different vendors may license their firmware from
503       the same IPMI firmware developer, so it may be worthwhile to try  work‐
504       arounds listed below even if your motherboard is not listed.
505
506       "idzero"  -  This  workaround option will allow empty session IDs to be
507       accepted by the client. It works around IPMI sessions that report empty
508       session  IDs  to  the client. Those hitting this issue may see "session
509       timeout" errors. Issue observed on Tyan S2882 with M3289 BMC.
510
511       "unexpectedauth" - This workaround option will  allow  unexpected  non-
512       null  authcodes  to  be  checked as though they were expected. It works
513       around an issue when packets contain non-null authentication data  when
514       they  should  be null due to disabled per-message authentication. Those
515       hitting this issue may see "session timeout" errors. Issue observed  on
516       Dell PowerEdge 2850,SC1425. Confirmed fixed on newer firmware.
517
518       "forcepermsg" - This workaround option will force per-message authenti‐
519       cation to be used no matter what is advertised by the remote system. It
520       works  around an issue when per-message authentication is advertised as
521       disabled on the remote system, but it is actually required for the pro‐
522       tocol.  Those  hitting  this  issue  may  see "session timeout" errors.
523       Issue observed on IBM eServer 325.
524
525       "endianseq" - This workaround option will flip the endian of  the  ses‐
526       sion  sequence  numbers  to allow the session to continue properly.  It
527       works around IPMI 1.5 session  sequence  numbers  that  are  the  wrong
528       endian.  Those  hitting  this  issue  may see "session timeout" errors.
529       Issue observed on some Sun ILOM 1.0/2.0 (depends on  service  processor
530       endian).
531
532       "authcap"  - This workaround option will skip early checks for username
533       capabilities, authentication capabilities, and K_g  support  and  allow
534       IPMI  authentication  to  succeed.  It  works around multiple issues in
535       which the remote system does not properly report username capabilities,
536       authentication  capabilities,  or  K_g status. Those hitting this issue
537       may  see  "username  invalid",  "authentication  type  unavailable  for
538       attempted privilege level", or "k_g invalid" errors.  Issue observed on
539       Asus  P5M2/P5MT-R/RS162-E4/RX4,  Intel  SR1520ML/X38ML,  and  Sun  Fire
540       2200/4150/4450 with ELOM.
541
542       "intel20"  - This workaround option will work around several Intel IPMI
543       2.0 authentication issues. The issues covered include padding of  user‐
544       names,  automatic  acceptance of a RAKP 4 response integrity check when
545       using the integrity algorithm MD5-128, and password truncation  if  the
546       authentication  algorithm is HMAC-MD5-128. Those hitting this issue may
547       see "username invalid", "password invalid", or  "k_g  invalid"  errors.
548       Issue  observed  on Intel SE7520AF2 with Intel Server Management Module
549       (Professional Edition).
550
551       "supermicro20" - This workaround option will work around several Super‐
552       micro  IPMI 2.0 authentication issues on motherboards w/ Peppercon IPMI
553       firmware. The issues covered include handling invalid length  authenti‐
554       cation  codes.  Those  hitting  this  issue  may see "password invalid"
555       errors.  Issue observed on Supermicro H8QME with SIMSO  daughter  card.
556       Confirmed fixed on newerver firmware.
557
558       "sun20" - This workaround option will work work around several Sun IPMI
559       2.0 authentication issues. The issues covered include invalid  lengthed
560       hash  keys,  improperly  hashed keys, and invalid cipher suite records.
561       Those hitting this issue may see  "password  invalid"  or  "bmc  error"
562       errors.   Issue  observed  on  Sun Fire 4100/4200/4500 with ILOM.  This
563       workaround automatically includes the "opensesspriv" workaround.
564
565       "opensesspriv" - This workaround option will slightly alter  FreeIPMI's
566       IPMI 2.0 connection protocol to workaround an invalid hashing algorithm
567       used by the remote system. The privilege level  sent  during  the  Open
568       Session  stage  of an IPMI 2.0 connection is sometimes invalid and used
569       for hashing keys instead of the privilege level sent during  the  RAKP1
570       connection  stage. Those hitting this issue may see "password invalid",
571       "k_g invalid", "bad rmcpplus status code", or "privilege  level  cannot
572       be  obtained  for  this  user  "  errors.  Issue  observed  on Sun Fire
573       4100/4200/4500 with ILOM,  Inventec  5441/Dell  Xanadu  II,  Supermicro
574       X8DTH,  Supermicro  X8DTG, Supermicro X8DTU, and Intel S5500WBV/Penguin
575       Relion 700. This workaround is automatically triggered with the "sun20"
576       workaround.
577
578       "integritycheckvalue"  -  This  workaround  option  will work around an
579       invalid integrity check value during an IPMI 2.0 session  establishment
580       when  using  Cipher  Suite  ID 0. The integrity check value should be 0
581       length, however the remote motherboard responds with a non-empty field.
582       Those  hitting  this issue may see "k_g invalid" errors. Issue observed
583       on Supermicro  X8DTG,  Supermicro  X8DTU,  and  Intel  S5500WBV/Penguin
584       Relion 700.
585

OEM INTERPRETATION

587       The  following  motherboards are confirmed to have atleast some support
588       by the --interpret-oem-data option. While highly probable the OEM  data
589       interpretations  would work across other motherboards by the same manu‐
590       facturer, there are no guarantees.
591
592       Currently None
593

EXAMPLES

595       # ipmimonitoring
596
597       Show all sensors on the local machine.
598
599       # ipmimonitoring --record-ids="82 11 7 102"
600
601       Show sensors #82, #11, #7 and #102 on the local machine.
602
603       # ipmimonitoring --sensor-types=TEMPERATURE
604
605       Show all sensors in TEMPERATURE type on the local machine.
606
607       # ipmimonitoring -h ahost -u myusername -p mypassword
608
609       Show all sensors on a remote machine using IPMI over LAN.
610
611       # ipmimonitoring -h mycluster[0-127] -u myusername -p mypassword
612
613       Show all sensors across a cluster using IPMI over LAN.
614

KNOWN ISSUES

616       On older operating systems, if you input your username,  password,  and
617       other  potentially  security  relevant information on the command line,
618       this information may be discovered by other users when using tools like
619       the  ps(1) command or looking in the /proc file system. It is generally
620       more secure to input password information with options like the  -P  or
621       -K  options.  Configuring security relevant information in the FreeIPMI
622       configuration file would also be an appropriate way to hide this infor‐
623       mation.
624
625       In  order  to  prevent  brute force attacks, some BMCs will temporarily
626       "lock up" after a number of remote authentication errors. You may  need
627       to  wait awhile in order to this temporary "lock up" to pass before you
628       may authenticate again.
629
630       Some sensors may be output because the owner of the sensor is  not  the
631       BMC.  To  attempt  to bridge sensors and access sensors not on the BMC,
632       users may wish to try the -b or --bridge-sensors options.
633

FILES

635       /etc/ipmi_monitoring_sensors.conf
636

REPORTING BUGS

638       Report bugs to <freeipmi-users@gnu.org> or <freeipmi-devel@gnu.org>.
639
641       Copyright (C) 2007-2010 Lawrence Livermore National Security, LLC.
642       Copyright (C) 2006-2007 The Regents of the University of California.
643
644       This program is free software; you can redistribute it and/or modify it
645       under  the  terms of the GNU General Public License as published by the
646       Free Software Foundation; either version 2 of the License, or (at  your
647       option) any later version.
648

SEE ALSO

650       libipmimonitoring(3),   ipmi_monitoring_sensors.conf(5),   freeipmi(7),
651       ipmi-sensors(8)
652
653       http://www.gnu.org/software/freeipmi/
654
655
656
657ipmimonitoring 0.8.8              2010-07-21                 ipmimonitoring(8)
Impressum