Hi Werner, It's possible the motherboard is not reporting supported authentication types correctly. You could give the "authcap" workaround a shot. However, if this is being non-compliant in the way that I think it is, the "authcap" workaround won't work (b/c it currently handles a different non-compliance bug). Could you send me the output from --debug? If we can verify the issue, I'll implement a new workaround for you.
BTW, if you need the intel20 workarounds for IPMI 2.0, you may need to upgrade. There were some bugs found a few releases ago. 0.7.4 - 12/15/08 ---------------- <snip> o Fix Intel IPMI 2.0 workarounds in all tools/libraries. <snip> Al On Wed, 2009-08-19 at 14:16 +0200, Werner Fischer wrote: > Dear freeipmi users/developers, > > I'm trying to monitor an Intel SR2500 server (this server has the Intel > S5000PAL mainboard in it). > > While I can monitor it using ipmitool, I keep getting errors with > ipmimonitoring from freeipmi. Also using the "-W" parameter for > workarounds (as described in the manpage of ipmimonitoring) doesn't > help: > > -------------------------------------------------------------------------- > [r...@tpw ~]# ipmitool -I lan -H 192.168.1.211 -U admin -P relation sdr > BB +1.2V Vtt | 1.20 Volts | ok > BB +1.5V AUX | 1.47 Volts | ok > BB +1.5V | 1.48 Volts | ok > BB +1.8V | 1.79 Volts | ok > BB +3.3V | 3.35 Volts | ok > BB +3.3V STB | 3.35 Volts | ok > ^C > [r...@tpw ~]# ipmimonitoring -h 192.168.1.211 -u admin -p relation > ipmi_monitoring_sensor_readings_by_record_id: authentication type unavailable > for attempted privilege level > [r...@tpw ~]# ipmimonitoring -h 192.168.1.211 -W="intel20" -u admin -p > relation > ipmi_monitoring_sensor_readings_by_record_id: authentication type unavailable > for attempted privilege level > [r...@tpw ~]# rpm -q freeipmi > freeipmi-0.5.1-3.fc9.i386 > [r...@tpw ~]# > -------------------------------------------------------------------------- > > I checked the manpage: > "authentication type unavailable for attempted privilege level" - The > authentication type you wish > to authenticate with is not available for this privilege level. Please > try again with an alternate > authentication type or alternate privilege level. It may also be > possible the available authenti- > cation types you can authenticate with are not correctly configured on > the remote BMC. > But the settings at the BMC side seem to be ok: > > -------------------------------------------------------------------------- > [r...@tpw ~]# ipmitool -I lan -H 192.168.1.211 -U admin -P relation lan print > 1 > Set in Progress : Set Complete > Auth Type Support : NONE MD5 PASSWORD > Auth Type Enable : Callback : > : User : > : Operator : > : Admin : MD5 PASSWORD > : OEM : > IP Address Source : Static Address > IP Address : 192.168.1.211 > Subnet Mask : 255.255.255.0 > MAC Address : 00:0e:0c:ea:92:a2 > [...] > [r...@tpw ~]# ipmimonitoring -h 192.168.1.211 -a MD5 -u admin -p relation > ipmimonitoring: authentication type unavailable for attempted privilege level > [r...@tpw ~]# > -------------------------------------------------------------------------- > > Also compiling the newest version and using it does not help: > -------------------------------------------------------------------------- > [r...@tpw ~]# ipmimonitoring -h 192.168.1.211 -u admin -p relation > ipmimonitoring: authentication type unavailable for attempted privilege level > [r...@tpw ~]# ipmimonitoring -h 192.168.1.211 -W="intel20" -u admin -p > relation > ipmimonitoring: authentication type unavailable for attempted privilege level > [r...@tpw ~]# rpm -q freeipmi > freeipmi-0.7.11-1.fc9.i386 > [r...@tpw ~]# > -------------------------------------------------------------------------- > > In contrast, monitoring a system with a new Supermicro X8DT3-F mainboard > works fine with freeipmi-0.5.1-3.fc9.i386 and also with > freeipmi-0.7.11-1.fc9.i386: > > -------------------------------------------------------------------------- > [r...@tpw ~]# ipmitool -I lan -H 10.10.10.233 -U ADMIN -P ADMIN sdr > CPU1 Temp | 0 unspecified | ok > CPU2 Temp | no reading | ns > System Temp | 45 degrees C | ok > CPU1 Vcore | 0.98 Volts | ok > CPU2 Vcore | no reading | ns > CPU1 DIMM | 1.51 Volts | ok > CPU2 DIMM | no reading | ns > ^C > [r...@tpw ~]# ipmimonitoring -h 10.10.10.233 -u ADMIN -p ADMIN > Record_ID | Sensor Name | Sensor Group | Monitoring Status| Sensor Units | > Sensor Reading > 4 | System Temp | Temperature | Nominal | C | 45.000000 > 5 | CPU1 Vcore | Voltage | Nominal | V | 0.976000 > 6 | CPU2 Vcore | Voltage | Nominal | V | 0.000000 > 7 | CPU1 DIMM | Voltage | Nominal | V | 1.512000 > 8 | CPU2 DIMM | Voltage | Nominal | V | 0.000000 > 9 | +1.5V | Voltage | Nominal | V | 1.504000 > 10 | +3.3V | Voltage | Nominal | V | 3.240000 > 11 | +3.3VSB | Voltage | Nominal | V | 3.240000 > 12 | +5V | Voltage | Nominal | V | 5.120000 > 13 | +12V | Voltage | Nominal | V | 12.190000 > 14 | VBAT | Voltage | Nominal | V | 3.240000 > 15 | Fan1 | Fan | Nominal | RPM | 6528.000000 > 16 | Fan2 | Fan | Nominal | RPM | 7072.000000 > 17 | Fan3 | Fan | Nominal | RPM | 0.000000 > 18 | Fan4 | Fan | Nominal | RPM | 0.000000 > 19 | Fan5 | Fan | Nominal | RPM | 5644.000000 > 20 | Fan6 | Fan | Nominal | RPM | 5304.000000 > 21 | Fan7 | Fan | Nominal | RPM | 7072.000000 > 22 | Fan8 | Fan | Nominal | RPM | 0.000000 > 23 | Intrusion | Physical Security | Nominal | N/A | '' > 24 | PS Failure | Power Supply | Nominal | N/A | '' > [r...@tpw ~]# > -------------------------------------------------------------------------- > > Does anybody have an idea how this problem could be fixed? > > best regards, > Werner > > > > _______________________________________________ > Freeipmi-users mailing list > Freeipmi-users@gnu.org > http://*lists.gnu.org/mailman/listinfo/freeipmi-users > -- Albert Chu ch...@llnl.gov Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory _______________________________________________ Freeipmi-users mailing list Freeipmi-users@gnu.org http://lists.gnu.org/mailman/listinfo/freeipmi-users
