Bug #12156
closed
Enabling captive portal in high availability sync causes it to crash
Added by Tomas Modenese almost 3 years ago.
Updated almost 3 years ago.
Category:
High Availability
Description
Hi,
as described in the subject, if i toggle "Captive Portal" option in the High availability menu, the sync between two firewalls stop to working.
In the slave fw the following error is reported:
PHP ERROR: Type: 1, File: /usr/local/www/xmlrpc.php, Line: 342, Message: Uncaught Error: Cannot unset string offsets in /usr/local/www/xmlrpc.php:342
Stack trace:
#0 /usr/local/share/pear/XML/RPC2/Server/CallHandler/Instance.php(141): pfsense_xmlrpc_server->restore_config_section(Array, 900)
#1 /usr/local/share/pear/XML/RPC2/Backend/Php/Server.php(135): XML_RPC2_Server_Callhandler_Instance->__call('pfsense.restore...', Array)
#2 /usr/local/share/pear/XML/RPC2/Backend/Php/Server.php(99): XML_RPC2_Backend_Php_Server->getResponse()
#3 /usr/local/www/xmlrpc.php(954): XML_RPC2_Backend_Php_Server->handleCall()
#4 {main}
- Status changed from New to Feedback
From the code around that point it looks like maybe you have a broken or invalid voucher configuration. Can you attach the <voucher> [...] </voucher> section of your configuration? You can redact -- but not remove -- the private info, at least leave some placeholder in there like "xxxxx" so we can tell the difference between something missing or empty and so on.
<voucher>
<charset>2345678abcdefhijkmnpqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ</charset>
<rollbits>16</rollbits>
<ticketbits>10</ticketbits>
<checksumbits>5</checksumbits>
<magic>158148548</magic>
<exponent>32683</exponent>
<publickey>LS0tLS1CRUdJTiBQVUJMSUMgS0VZLS0tLS0NCk1DTXdEUVlKS29aSWh2Y05BUUVCQlFBREVnQXdEd0lKQU1vcXhKLzJnNi9MQWdKL3F3PT0NCi0tLS0tRU5EIFBVQkxJQyBLRVktLS0tLQ0K</publickey>
<privatekey>XXXX</privatekey>
<msgnoaccess>Voucher invalid</msgnoaccess>
<msgexpired>Voucher expired</msgexpired>
<enable></enable>
<roll>
<number>4</number>
<minutes>10080</minutes>
<comment></comment>
<count>100</count>
<used>/v//af9Pn//v/6b/Hw==</used>
<active></active>
</roll>
<ospiti>
<charset>2345678abcdefhijkmnpqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ</charset>
<rollbits>16</rollbits>
<ticketbits>10</ticketbits>
<checksumbits>5</checksumbits>
<magic>1593633074</magic>
<exponent>57177</exponent>
<publickey>LS0tLS1CRUdJTiBQVUJMSUMgS0VZLS0tLS0NCk1DUXdEUVlKS29aSWh2Y05BUUVCQlFBREV3QXdFQUlKQUlYVy9kNkJuejMzQWdNQkFBRT0NCi0tLS0tRU5EIFBVQkxJQyBLRVktLS0tLQ==</publickey>
<privatekey>XXXXX</privatekey>
<descrmsgnoaccess><![CDATA[Voucher invalid]]></descrmsgnoaccess>
<descrmsgexpired><![CDATA[Voucher expired]]></descrmsgexpired>
<enable></enable>
<roll>
<zone>ospiti</zone>
<number>1</number>
<minutes>10080</minutes>
<descr></descr>
<count>100</count>
<used>AAAAAAAAAAAAAAAAAA==</used>
<active></active>
<lastsync>1626876529</lastsync>
</roll>
</ospiti>
</voucher>
I can replicate this with the provided config snippet, but the issue here is that the provided voucher config here isn't associated with a particular captive portal zone.
It should be formatted like this (where test is the name of my zone)
<voucher>
<test>
<charset>2345678abcdefhijkmnpqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ</charset>
<rollbits>16</rollbits>
<ticketbits>10</ticketbits>
<checksumbits>5</checksumbits>
<magic>158148548</magic>
<exponent>32683</exponent>
<publickey>LS0tLS1CRUdJTiBQVUJMSUMgS0VZLS0tLS0NCk1DTXdEUVlKS29aSWh2Y05BUUVCQlFBREVnQXdEd0lKQU1vcXhKLzJnNi9MQWdKL3F3PT0NCi0tLS0tRU5EIFBVQkxJQyBLRVktLS0tLQ0K</publickey>
<privatekey>XXXX</privatekey>
<msgnoaccess>Voucher invalid</msgnoaccess>
<msgexpired>Voucher expired</msgexpired>
<enable></enable>
<roll>
<number>4</number>
<minutes>10080</minutes>
<comment></comment>
<count>100</count>
<used>/v//af9Pn//v/6b/Hw==</used>
<active></active>
</roll>
<ospiti>
<charset>2345678abcdefhijkmnpqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ</charset>
<rollbits>16</rollbits>
<ticketbits>10</ticketbits>
<checksumbits>5</checksumbits>
<magic>1593633074</magic>
<exponent>57177</exponent>
<publickey>LS0tLS1CRUdJTiBQVUJMSUMgS0VZLS0tLS0NCk1DUXdEUVlKS29aSWh2Y05BUUVCQlFBREV3QXdFQUlKQUlYVy9kNkJuejMzQWdNQkFBRT0NCi0tLS0tRU5EIFBVQkxJQyBLRVktLS0tLQ==</publickey>
<privatekey>XXXXX</privatekey>
<descrmsgnoaccess><![CDATA[Voucher invalid]]></descrmsgnoaccess>
<descrmsgexpired><![CDATA[Voucher expired]]></descrmsgexpired>
<enable></enable>
<roll>
<zone>ospiti</zone>
<number>1</number>
<minutes>10080</minutes>
<descr></descr>
<count>100</count>
<used>AAAAAAAAAAAAAAAAAA==</used>
<active></active>
<lastsync>1626876529</lastsync>
</roll>
</ospiti>
</test>
</voucher>
So we need some more information. Somehow the config was mangled and formatted incorrectly.
Most likely because config was imported from an old version of pfsense (2.0.2), in fact in UI config was blank and I had to recreate it manually.
However adding the zone name tag didn't solve the issue.
- Subject changed from Enabling captive portal in high availability sync causes it to crash to Enabling captive portal in high availability sync causes it to crash
- Status changed from Feedback to Closed
It's hard to say what happened here exactly, but this is either a support issue or an edge case (i.e. upgrading from a version of pfSense that is nearly 10 years old). You're better off using the config that you have on hand and recreating the environment afresh. You might even blow out any captive portal / voucher config in your XML prior to proceeding with that just to be sure.
From a quick glance at the code I agree -- it's also possible they restored just the captive portal section of a configuration from an older version so it didn't go through the upgrade process correctly.
Either way it's an outlier and not a valid configuration.
If someone can come up with a way to make it happen from a fresh install without restoring anything, list the steps out and we can look into it deeper.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by