Chassis Intrustion Detection doesn't work correctly

[thegushi]

Chassis intrusion causes my supermicro system to display "CRITICAL" when you log in via the web UI, so I'd like the plugin to pick up on it.

On an intruded system, it reports:

ID   | Name          | Type              | State    | Reading    | Units | Lower NR   | Lower C    | Lower NC   | Upper NC   | Upper C    | Upper NR   | Event
1612 | Chassis Intru | Physical Security | Nominal  | N/A        | N/A   | N/A        | N/A        | N/A        | N/A        | N/A        | N/A        | 'General Chassis Intrusion'

--------------------- end of debug output ---------------------
Sensor Type(s) physical_security Status: OK
Chassis Intru = 'General Chassis Intrusion' (Status: Nominal)

And when reset, it reports:

  output of FreeIPMI:
ID   | Name          | Type              | State    | Reading    | Units | Lower NR   | Lower C    | Lower NC   | Upper NC   | Upper C    | Upper NR   | Event
1612 | Chassis Intru | Physical Security | Nominal  | N/A        | N/A   | N/A        | N/A        | N/A        | N/A        | N/A        | N/A        | 'OK'

--------------------- end of debug output ---------------------
Sensor Type(s) physical_security Status: OK
Chassis Intru = 'OK' (Status: Nominal)

I suspect this is because it is expecting the IPMI device to tell it what states are "nominal", and there's no such threshhold as this.

[veitw]

IMO this sensor should not be handled by state monitoring but by event monitoring, as some systems might only report intrusion as sensor state while the case is open. It should also already be covered by check_ipmi_sensor's SEL monitoring, as the chassis intrusion should create an event in the log, and the alarm may be reset by deleting the event. I think Supermicro defining the alarm state as nominal indicates that they also consider event log monitoring the correct handling for this sensor.

[thegushi]

As mentioned on my other issue, the problem here is that the plugin hardcodes how it calls the reading of the SEL

Here's the raw output of the ipmi-sensors call to this host.

Record ID: 1880
Record Type: Full Sensor Record (1h)
ID String: Chassis Intru
Sensor Type: Physical Security (5h)
Sensor Number: 81
IPMB Slave Address: 10h
Sensor Owner ID: 20h
Sensor Owner LUN: 0h
Channel Number: 0h
Entity ID: system chassis (23)
Entity Instance: 1
Entity Instance Type: Physical Entity
Event/Reading Type Code: 6Fh
Accuracy: 0.000000
Sensor Direction: Unspecified
Positive Hysteresis: N/A
Negative Hysteresis: N/A
Assertion Event Enabled: 'General Chassis Intrusion'
Assertion Event Enabled: 'I/O Card area intrusion'
Assertion Event Enabled: 'LAN Leash Lost (system is unplugged from LAN)'
Assertion Event Enabled: 'Unrecognized Event = 0080h'
Assertion Event Enabled: 'Unrecognized Event = 0200h'
Assertion Event Enabled: 'Unrecognized Event = 0800h'
Assertion Event Enabled: 'Unrecognized Event = 1000h'
Assertion Event Enabled: 'Unrecognized Event = 2000h'
Assertion Event Enabled: 'Unrecognized Event = 4000h'
Deassertion Event Enabled: 'General Chassis Intrusion'
Deassertion Event Enabled: 'I/O Card area intrusion'
Deassertion Event Enabled: 'LAN Leash Lost (system is unplugged from LAN)'
Deassertion Event Enabled: 'Unrecognized Event = 0080h'
Deassertion Event Enabled: 'Unrecognized Event = 0200h'
Deassertion Event Enabled: 'Unrecognized Event = 0800h'
Deassertion Event Enabled: 'Unrecognized Event = 1000h'
Deassertion Event Enabled: 'Unrecognized Event = 2000h'
Deassertion Event Enabled: 'Unrecognized Event = 4000h'
Sensor State: Nominal
Sensor Event: 'General Chassis Intrusion'

What's missing here (compared to other sensors) is Sensor Reading:. It only shows the last event, and since there's no interpretable range for this sensor, just a list of discrete values, the older ipmitool does report discrete values in its readings.

That said if parsing the SEL is the way forward, I don't understand this line in check_ipmi_sensors:

        # Currently only memory sensor types in the event log are monitored
       push @selcmd, '--output-event-state', '--interpret-oem-data', '--entity-sensor-names', '--sensor-types=Memory,Processor';

Because in the help output, it specifically gives instructions as to how to limit physical security from the SEL output, which it's already doing, hardcoded:

  [-sx|--selexclude <sel exclude file>]
       use a sel exclude file to exclude entries from the system event log.
       Specify name and type pipe delimitered in this file to exclude an entry,
       for example: System Chassis Chassis Intru|Physical Security
       To get valid names and types use the -vvv option and take a look at:
       debug output for sel (-vvv is set). Don't use name and type from the
       web interface as sensor descriptions are not complete there.

freeipmi does have a way via a config file (freeipmi_interpret_sensor.conf) to map states to "Normal" or "Warning" or "Critical", but I was unable to get these to trigger on this state, I suspect because there's no "Reading" value.

One more datapoint for this: Supermicro does report discrete raw values for this when polled with ipmitool. I just don't know how to get freeipmi to interpret these values.

On an "intruded" system with a psu with one plug missing:

Chassis Intru    | 0x1        | discrete   | 0x0100| na        | na        | na        | na        | na        | na
PS1 Status       | 0x1        | discrete   | 0x0100| na        | na        | na        | na        | na        | na
PS2 Status       | 0xb        | discrete   | 0x0b00| na        | na        | na        | na        | na        | na

And on a healthy system:

Chassis Intru    | 0x0        | discrete   | 0x0000| na        | na        | na        | na        | na        | na
PS1 Status       | 0x1        | discrete   | 0x0100| na        | na        | na        | na        | na        | na
PS2 Status       | 0x1        | discrete   | 0x0100| na        | na        | na        | na        | na        | na

I don't know how/if it's even possible to get ipmi-sensors to output raw values. In theory, it has included an "oem" file that maps these values to real macros, but I can't see how to confirm that it's detecting/using the Supermicro mapping?