Project

General

Profile

Actions
Copy link

Bug #8806

closed
AF RB

HA sync : Starting captiveportal doesn't fire ipfw rules on slave, even if HA is enabled.

Bug #8806: HA sync : Starting captiveportal doesn't fire ipfw rules on slave, even if HA is enabled.

Added by A FL about 8 years ago. Updated about 8 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Renato Botelho
Category:
Captive Portal
Target version:
2.4.4
Start date:
08/19/2018
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
All
Affected Architecture:
All

Description

When a CP zone is enabled, slave does not start the captive portal (despite "enabled" setting appear checked on the slave):
One workaround to this is to manually start captiveportal on the slave by clicking "submit" on the salve cp settings, or by rebooting the slave.

I think it would be better to automatically start the slave if captiveportal sync is ensabled in System-> High Avaliablity settings

JP Updated by Jim Pingle about 8 years ago Actions
Copy link
 #1

  • Target version set to 2.4.4

I wonder if this might be the same root cause as #8721

An XMLRPC sync used to trigger filter_configure via XMLRPC which handled refreshing a number of things on the secondary after a sync. It doesn't now, which may be the cause of these issues.

Updated by Anonymous about 8 years ago Actions
Copy link
 #2

  • Assignee set to Renato Botelho

Updated by Anonymous about 8 years ago Actions
Copy link
 #3

  • Priority changed from Normal to Normal-package

Updated by Anonymous about 8 years ago Actions
Copy link
 #4

  • Priority changed from Normal-package to Normal

RB Updated by Renato Botelho about 8 years ago Actions
Copy link
 #5

  • Status changed from New to In Progress

RB Updated by Renato Botelho about 8 years ago Actions
Copy link
 #6

  • Status changed from In Progress to Feedback

RB Updated by Renato Botelho about 8 years ago Actions
Copy link
 #7

  • % Done changed from 0 to 100

Applied in changeset commit:7cab6335bb56d2ac372a195719be28c55b2cb252.

AF Updated by A FL about 8 years ago Actions
Copy link
 #8

Working correctly on the last snapshot

This issue can be marked as resolved.

Updated by Anonymous about 8 years ago Actions
Copy link
 #9

  • Status changed from Feedback to Resolved
Actions
Copy link

Also available in: Atom