Supermicro Motherboards and ipmitool

[EffrafaxOfWug]

So, I've been experimenting with implementing 10Gb stuffs on my home network given that it's now becoming reasonably cheap and power-efficient to do so. One of the surprising caveats I ran into was realising that apparently neither of the Intel NIC's I'm using support Wake-on-LAN (something I use in combination with rtcwake on my backup server).

No problem says I, I'll just replace those routines with the handy ipmitool and use that to wake up the box instead. However I couldn't get it to work against my backup server, and on further testing I couldn't get it to work against other motherboards either. ssh and http work fine of course.

Basically every command I end up throwing at the IPMI interface fails with an error that indicates it's unable to communicate with it:

effrafax@wug:~$ ipmitool -v -I lanplus -H lamuella -U admin power status
Password:
Get Auth Capabilities error
Error issuing Get Channel Authentication Capabilities request
Error: Unable to establish IPMI v2 / RMCP+ session

I figured it might be a firewall issue of some description but even after turning off all the rules between my regular server LAN and the IPMI LAN, I got the same result.

Bizarrely however, ipmitool remoting to offsite works perfectly:

effrafax@wug:~$ ipmitool -I lanplus -H nowwhat.ipmi -U admin power status
Password:
Chassis Power is on

Is there some IPMI setting I need to flip or some firewall ports that need opening? The only discrepancy I can see in the nmap scans of working vs. non-working hosts is 623/udp being shown as "filtered";

Working host nowwhat (offsite):

root@wug:~# nmap nowwhat.ipmi
PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
443/tcp  open  https
5900/tcp open  vnc

root@wug:~# nmap -sU nowwhat.ipmi
PORT    STATE SERVICE
123/udp open  ntp
623/udp open  asf-rmcp

Non-working host lamuella:

root@wug:~# nmap lamuella.ipmi
PORT     STATE SERVICE
22/tcp   open  ssh
80/tcp   open  http
443/tcp  open  https
5900/tcp open  vnc

root@wug:~# nmap -sU lamuella.ipmi
PORT    STATE         SERVICE
123/udp open          ntp
623/udp open|filtered asf-rmcp

The only thing I could find on the net matching the above was a Dell user (not Supermicro) although there was mention there that a setting needed to be changed to allow the IPMI interface to accept remote instructions; does such a thing need to be done for some SM boards? I did worry it was the firewall rules I use to govern access from one VLAN to the other, but even disabling them temporarily made no difference.

And failing that, does anyone have any idea what might be wrong with my IPMI setup here?

 

[pcmoore]

Perhaps this is just a cut-n-paste error, but in the nmap example you used "lamuella.ipmi" for the remote system, but in the ipmitool example you used "lamuella". You should be pointing ipmitool as the IPMI interface, what happens when you run ipmitool against "lamuella.ipmi"?

 

[EffrafaxOfWug]

Sorry yeah, cut'n'paste and tidy-up error, It was indeed directed at the IPMI interface and not the regular one.

 

[sean]

Resurrecting this from last year because I had the same problem yesterday. The BMC would respond with a packet but nothing else remotely.

ipmitool -vv -I lan -L USER -H BMCHOST -U metrics -E chassis power status
Sending IPMI/RMCP presence ping packet
Received IPMI/RMCP response packet:
  IPMI Supported
  ASF Version 1.0
  RMCP Version 1.0
  RMCP Sequence 255
  IANA Enterprise 34359742910

ipmi_lan_send_cmd:opened=[1], open=[2776512]
  No response from remote controller
Get Auth Capabilities command failed
Error: Unable to establish LAN session
Error: Unable to establish IPMI v1.5 / RMCP session

I shut down the entire system, including pulling the power plug, and now ipmitool works great. Exact same command from my shell history completes in under a second instead of taking ten to time out.