Bug #1088
closed
Added by Alexander Kalashnikov almost 14 years ago.
Updated almost 14 years ago.
Affected Architecture:
All
Description
After http://redmine.pfsense.org/projects/pfsense/repository/revisions/7380bcdbe4be18bcb007f283b71fd5f83b51fced revision carp syncronization has been broken.
It seems like Ermal Luçi misunderstood the real purpose of the pfsense.check_firmware_version XMLRPC procedure.
According to source code pfsense.check_firmware_version calls check_firmware_version function which is used to check for an updated firmware version from pfsense.org, and it does not return a current version of running pfsense.
Dear Ermal Luçi,
May be you should create and register your own XMLRPC procedure (for example pfsense.get_running_firmware_version (I'm not sure why it's prefixed with "pfsense." in pfsense.check_firmware_version)) which will use /etc/version etc. files for this purpose?
Please, look at a beginning of check_firmware_version in /etc/inc/pfsense-utils.inc:
$rawparams = array("firmware" => array("version" => trim(file_get_contents('/etc/version'))),
"kernel" => array("version" => trim(file_get_contents('/etc/version_kernel'))),
"base" => array("version" => trim(file_get_contents('/etc/version_base'))),
"platform" => trim(file_get_contents('/etc/platform')),
"config_version" => $config['version']
);
Thank you.
- Status changed from New to Feedback
Will check in 5 hrs.
Current snapshots has been compiled with an old code.
Still broken.
Dec 10 13:41:43 php: : The other member is on older version of . Sync will not be done to prevent problems!
Dec 10 13:41:43 php: : New alert found: An error code was received while attempting XMLRPC sync with username admin http://10.10.0.2:88 - Code 2: Invalid return payload: enable debugging to examine incoming payload
Dec 10 13:41:43 php: : An error code was received while attempting XMLRPC sync with username admin http://10.10.0.2:88 - Code 2: Invalid return payload: enable debugging to examine incoming payload
Ok should be better than before on latest snapshot.
Be careful to have all the related commits.
I'm not sure fixed it or not, because after a configuration sync "Filter reload status" just hangs on "Syncing CARP data to http://..." however all data got sync-ed.
It seems like that is only a cosmetic issue.
After a configuration sync filter reload status file just remains untouched with the last message in it.
May be it should be updated (to 'Done') after a successfull config sync?
- Status changed from Feedback to Resolved
Hi guys, carp issue exist in following scenario, VMware pair with 4 interfaces: 1 outside, 1 inside, 1 sync and last as trunk with two VLANs. VIPs are created correctly when applied on the "physical" interfaces but when a VIP is assigned to a VLAN then the sync to the partner throws an error saying "sorry could not find a physical interface in this subnet" (message not exact), the VIP that were created for the VLAN interfaces dont show "backup" on the partner. I worked around it by disabling "syncronise Virtual IPs" on the CARP Settings on the master and create the VIPs manually on the partner backup - that works well and VIPs show as "backup". Havent tried it with previous BETA so not sure if it was working before. Can I help more? pls let me know
Also available in: Atom
PDF