Update the files required to build ipmitool 1.8.18

[whowutwut]

Regarding Issue #19

Includes changes to the source tree for patches and spec files to build ipmitool-xcat 1.8.18.

[whowutwut]

With the code changes in the pull request I'm able to build on RHEL 7.3 GA ppc64LE

[root@fs2vm112 ipmitool]# ./bldipmi.pl
...
...
+ cd ipmitool-1.8.18
+ '[' /root/rpmbuild/BUILDROOT/ipmitool-xcat-1.8.18-0.ppc64le ']'
+ '[' /root/rpmbuild/BUILDROOT/ipmitool-xcat-1.8.18-0.ppc64le '!=' / ']'
+ rm -rf /root/rpmbuild/BUILDROOT/ipmitool-xcat-1.8.18-0.ppc64le
+ exit 0
++++Trying to run command: [mkdir -p /tmp/build/rh7/ppc64le]
++++Trying to run command: [cp -rf  /root/rpmbuild/RPMS/ppc64le/ipmitool-xcat-1.8.18-0.ppc64le.rpm /tmp/build/rh7/ppc64le]
The obj file has been built successfully, you can get it here: /tmp/build/rh7/ppc64le
[root@fs2vm112 ipmitool]# ls -ltr /tmp/build/rh7/ppc64le
total 296
-rw-r--r-- 1 root root 300688 May 30 15:28 ipmitool-xcat-1.8.18-0.ppc64le.rpm

Check md5sum

[root@fs2vm112 ipmitool]# md5sum /tmp/build/rh7/ppc64le/ipmitool-xcat-1.8.18-0.ppc64le.rpm
dfe4425687f11bc14c9a3284685c27ef  /tmp/build/rh7/ppc64le/ipmitool-xcat-1.8.18-0.ppc64le.rpm

Ensure LAN Plus is active

[root@fs2vm112 ipmitool]# rpm -ihv /tmp/build/rh7/ppc64le/ipmitool-xcat*
Preparing...                          ################################# [100%]
Updating / installing...
   1:ipmitool-xcat-1.8.18-0           ################################# [100%]
[root@fs2vm112 ipmitool]#  /opt/xcat/bin/ipmitool-xcat -h  2>&1 | grep -i lanplus | grep "LAN Interface"
	lanplus       IPMI v2.0 RMCP+ LAN Interface 

[chenglch]

Thanks @whowutwut , looks good to me.

[whowutwut]

@chenglch Thanks, there were slight differences in the signal patch, If you can take a closer look there, that would be good. how would we verify this one?

The other thing, should we push LTC to see if they could submit a patch up for the ipmitool project for us? Or do we want to submit a patch, then we don't need to continue to create these patches. The files are not 100% identical so we cant just re-use the patch files.

[chenglch]

hi @whowutwut , the purpose of the code block below in the previous version is to make sure the leave_raw_mode(); and ipmi_sol_deactivate(intf, instance); are called while receiving the HUP signal. I do not know if we have to call ipmi_sol_deactivate function but I think it may help recover from the error state of SOL. The ipmitool sol activate command often waits at select system call( not while loop), this is why I added the check for error EINTR.
ipmi_sol_deactivate(intf, instance);

+                                if (errno == EINTR) {
+                                    bBmcClosedSession = 0;
+                                    keepAliveRet = 0;
+                                    break;
+                                }

As the signal problem often happens on our filestone machines.
First step, check the firmware if it loose console.

1. start ./ipmitool sol activate with the binary compiled just now
2. send SIGKILL to the ipmitool process. （With signal handler patch, SIGKILL is the only way to put the SOL into error state)
3. Then rerun ipmitool sol activate command.
4. Wait about 1-2 minutes, if the sol is disconnect automatically, this firmware is the version we need to test for the signal handler.

Second step: check the signal handler work around

1. ./ipmitool sol activate
2. send SIGHUP to the ipmitool process
3. ./ipmitool sol activate and then wait about 1-2 minutes, if the session is disconnected automatically, the signal fix may not work.

For our signal handler patch, I think it is hard to push to upstream as this is not a common issue, it is just a work around for the defect of firmware.

[chenglch]

The time format is wrong which cause the error while running make_deb.sh script.
-- Victor Hu <[email protected]> Tue, May 30, 2017 14:41:01 -0400
-->
-- Victor Hu <[email protected]> Tue, 30 May 2017 14:41:01 -0400