Bug 613836

Summary: invalid multicast address in corosync.conf file results in bad behavior
Product: Red Hat Enterprise Linux 6 Reporter: Steven Dake <sdake>
Component: corosyncAssignee: Angus Salkeld <asalkeld>
Status: CLOSED ERRATA QA Contact: Cluster QE <mspqa-list>
Severity: medium Docs Contact:
Priority: low    
Version: 6.0CC: agk, cluster-maint, djansa, fdinitto, jkortus, sdake
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: corosync-1.2.3-23.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 613835 Environment:
Last Closed: 2011-05-19 14:24:01 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 613835    
Bug Blocks:    
Attachments:
Description Flags
Only allow the multicast address range none

Description Steven Dake 2010-07-12 22:19:36 UTC 
+++ This bug was initially created as a clone of Bug #613835 +++

Description of problem:
corosync behaves erratically when invalid multicast address is specified in corosync.conf file.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. set multicast address to 220.1.1.1
2. corosync wont form configuration
3.
  
Actual results:
coroysnc fails in odd ways

Expected results:
error should be logged and corosync should fail to start

Additional info:
Comment 1 Angus Salkeld 2010-09-27 22:44:34 UTC 
Created attachment 450056 [details]
Only allow the multicast address range

Only allow the multicast address range (224.0.0.0 to 239.255.255.255).

trunk patch.
Comment 3 Jaroslav Kortus 2011-03-09 16:05:29 UTC 
Correct mcast address works well, autoconfigured also, manually specified non-mcast address results in:
cluster.conf (snip):
<cman>
		<multicast addr="1.192.239.192"/>
</cman>

$ service cman restart
Stopping cluster: 
   Leaving fence domain...                                 [  OK  ]
   Stopping gfs_controld...                                [  OK  ]
   Stopping dlm_controld...                                [  OK  ]
   Stopping fenced...                                      [  OK  ]
   Stopping cman...                                        [  OK  ]
   Waiting for corosync to shutdown:                       [  OK  ]
   Unloading kernel modules...                             [  OK  ]
   Unmounting configfs...                                  [  OK  ]
Starting cluster: 
   Checking if cluster has been disabled at boot...        [  OK  ]
   Checking Network Manager...                             [  OK  ]
   Global setup...                                         [  OK  ]
   Loading kernel modules...                               [  OK  ]
   Mounting configfs...                                    [  OK  ]
   Starting cman... corosync died: Could not read cluster configuration Check cluster logs for details
                                                           [FAILED]


Mar  9 10:01:20 z4 corosync[24704]:   [MAIN  ] Corosync Cluster Engine ('1.2.3'): started and ready to provide service.
Mar  9 10:01:20 z4 corosync[24704]:   [MAIN  ] Corosync built-in features: nss dbus rdma snmp
Mar  9 10:01:20 z4 corosync[24704]:   [MAIN  ] Successfully read config from /etc/cluster/cluster.conf
Mar  9 10:01:20 z4 corosync[24704]:   [MAIN  ] Successfully parsed cman config
Mar  9 10:01:20 z4 corosync[24704]:   [MAIN  ] parse error in config: mcastaddr is not a correct multicast address.
Mar  9 10:01:20 z4 corosync[24704]:   [MAIN  ] Corosync Cluster Engine exiting with status 8 at main.c:1679.

Works as expected.
Comment 4 errata-xmlrpc 2011-05-19 14:24:01 UTC 
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0764.html