Description of problem:
While using incorrect hashes, the fence_xvm detects the failure correctly but returns bad status, effectively faking successful fencing operation.
Correct hashes in the example below are sha256/sha256.

What's interesting is that sha256/sha512 combination results in successful fence. Is this expected behaviour?

[root@c1-node01:~]$ fence_xvm -C sha512 -c sha256 -k /etc/cluster/fence_xvm.key  -H c1-node02
Hash mismatch:
C = a6aec2b23580c27f9060a4f8149c42864db748478efdecec38f5a6002f5d5b26e1157c0fbb63d2a30304aa7de191e044152b02c04dcc34ee681fca2f977ad1e5
H = 599067580117c396b5846d0fe5e38fe9e871ce8566e283a87ce332794d2be5197e8caaf24285f7dd8578a5dc29735b410383f65540478cd5cd4f999ddbfe30d2
R = 0cf2eae9677c206cf0d74404d13949fd6c4ab1773fe68a8ef870976c51f5d0880000000000000000000000000000000000000000000000000000000000000000
Invalid response to challenge
(09:19:59) [root@c1-node01:~]$ echo $?
0

RHEL6 host fence_virtd.conf:
$ cat /etc/fence_virt.conf
		fence_virtd {
			listener = "multicast";
			backend = "libvirt";
		}

		listeners {
			multicast {
				key_file = "/etc/cluster/fence_xvm.key";
				address = "225.0.0.12";
				hash="sha256";
				auth="sha256";
				interface="virbr0";
			}
		}

		backends {
			libvirt { 
				uri = "qemu:///system";
			}
		}



Version-Release number of selected component (if applicable):
cman-2.0.115-101.el5

How reproducible:
always

Steps to Reproduce:
1. use fence_xvm with different parameters from what's in fence_virtd.conf
2.
3.
  
Actual results:
fencing operation reported as successful while it has actually failed


Expected results:
return code should be > 0 if response-challenge authentication fails.

Additional info: