Issues After Update from 24.03 to 24.11

Cornel

@Gertjan
Indeed I am using Kea. Also found now that this error was unrelated and coincidental.

What I do to get this error is opening the page https://captive.xxx.xxx:8003

It worked and stopped working. Only thing I changed between working and the error below, is disconnected and reconnected WAN. On Interface page.

The line 1745-1748 you mentioned in the other comment is there:
$isipv6 = is_ipaddrv6($cliip);
$interfaces = array_filter(explode(",", config_get_path("captiveportal/{$cpzone}/interface", [])));
foreach ($interfaces as $cpif) {

1801-1803
$listenporthttp = $cpcfg['listenporthttp'] ? $cpcfg['listenporthttp'] : ($cpcfg['zoneid'] + 8000);
$ifip = portal_ip_from_client_ip($cliip);
if (!$ifip) {

1822-1825
$cpcfg = config_get_path("captiveportal/{$cpzone}", []);
$ourhostname = portal_hostname_from_client_ip($clientip);
$protocol = (isset($cpcfg['httpslogin'])) ? 'https://' : 'http://';
$portal_url = "{$protocol}{$ourhostname}/index.php?zone={$cpzone}";

Gertjan

It's the PHP function that complains.

@Cornel said in Issues After Update from 24.03 to 24.11:

Message: Uncaught TypeError: explode():

The second argument must be of type a string.
The second argument is what the function config_get_path("captiveportal/{$cpzone}/interface", "") returns.
This return the value of <interface> in the config file, should be a string, or 'nothing' (or false ?) if it was not found.

So, as asked before : what did you see ? (look at the files I sited above) ...

..... .....

If you do this - I've not tested this :

then you have a collection of interfaces ... and this collection is known also an "array" ... (wtf)
Not sure if that is 'ok'.
Solution : select just one interface, not more then one ?!

Lol : text help text says, and I've never noticed it : "Select the interface(s) to enable for captive portal."
Ok, granted. This start to smell like a bug. Just use 1 interface for now, the 'code' isn't ready for more the one.
Would love to test drive this, and I'll do so tomorrow (23h00 here now). Now, I can't, hotel is loaded, so is my captive portal. Talking down the portal down is plain dangerous.

Cornel

Solved - very obvious reason.... I should have used:

https://captive.xxxxxx.org:8003/index.php?zone=wireless_guest

If I ommit the /index.php?zone=wireless_guest this error is thrown which is obvious if you look at what line 1746 does.

So probably this is also the explanation for the situation of @mcconju

Gertjan

@Cornel said in Issues After Update from 24.03 to 24.11:

https://captive.xxxxxx.org:8003/index.php?zone=wireless_guest

You should use that where ??

Cornel

@Gertjan When I was testing how my custom captive portal html code was shown. I had some issues with my portal page and was reloading it often to check how my html was shown. Somehow along the way I got distracted, closes the browser window and entered just the captive portal url without the /indec.php?zone= part. Then this error is thrown.

Gertjan

About the array issue :

@Gertjan said in Issues After Update from 24.03 to 24.11:

Would love to test drive this, and I'll do so tomorrow (23h00 here now). Now, I can't, hotel is loaded, so is my captive portal. Talking down the portal down is plain dangerous.

I've added a second interface my portal :

No fire, no smoke. Could login just fine.

@Cornel said in Issues After Update from 24.03 to 24.11:

which is obvious if you look at what line 1746 does.

Line 1746 use the variable $cpzone, which is mandatory.
In your case, $cpzone will be set to "wireless_guest".

But the page called /index.php?zone=wireless_guest

and look, at what happens at line 38 in index.php :

$cpzone = strtolower($_REQUEST['zone']);
$cpcfg = config_get_path("captiveportal/{$cpzone}", []);

and a couple of lines lower : if there is no captive portal config the the zone name, bail out.

if (empty($cpcfg)) {
	log_error("Submission to captiveportal with unknown parameter zone: " . htmlspecialchars($cpzone));
	portal_reply_page($redirurl, "error", gettext("Internal error"));
	ob_flush();
	return;
}

Without a zone parameter you would find many lines telling you that "Submission to captiveportal with unknown parameter zone: ". There won't be any PHP errors. index.php would have been bailed out long before that.

You can test the portal pages with

Cornel

@Gertjan I agree that if you call the captive portal as intended it works. However if you manually open just the portal url without adding the 'query string' i.e. without '?zone=' the error is thrown. What happens in your setup when you do this?

Gertjan

@Cornel said in Issues After Update from 24.03 to 24.11:

What happens in your setup when you do this?

-> ->

Thanks for insisting.

I saw your PHP ERROR: Type: 1, File: /etc/inc/captiveportal.inc, Line: 1746, Message: Uncaught TypeError: explode(): Argument #2 ($string) must be of type string, array given in /etc/inc/captiveportal.inc:1746
Stack trace:
#0 /etc/inc/captiveportal.inc(1746): explode()
#1 /etc/inc/captiveportal.inc(1804): portal_ip_from_client_ip()
#2 /etc/inc/captiveportal.inc(1825): portal_hostname_from_client_ip()
#3 /usr/local/captiveportal/index.php(60): portal_reply_page()
#4 {main}
  thrown

The test :

if (empty($cpcfg)) {

line 59, fails to do it job. [edit : and I'm wrong, line 59 works just fine, see next posts ]
I'll get back to this.

Cornel

@Gertjan

Thanks for insisting.

You are welcome

line 59, fails to do it job.

I'll get back to this.

Much appreciated

Gertjan

@Cornel

It took me a while, but the issue was hiding in plain sight.

Here :

@Gertjan said in Issues After Update from 24.03 to 24.11:

#3 /usr/local/captiveportal/index.php(60): portal_reply_page()

When $cpcfg is empty, because the url contain an non existent or invalid "&zone=xxxxxx" parameter this gets execute :

	log_error("Submission to captiveportal with unknown parameter zone: " . htmlspecialchars($cpzone));
	portal_reply_page($redirurl, "error", gettext("Internal error"));
	ob_flush();
	return;

It took me a while ... but found that, before everything terminates, portal_reply_page) is called and portal_reply_page() uses $cpcfg and presumes it's valid.
But in this case, it wasn't. hence the PHP error.

	// log_error("Submission to captiveportal with unknown parameter zone: " . htmlspecialchars($cpzone));

	portal_reply_page($redirurl, "error", gettext("Internal error"));
	ob_flush();
	return;

(A) Solution :

if (empty($cpcfg)) {
	log_error("Submission to captiveportal with unknown parameter zone: " . htmlspecialchars($cpzone));
	// portal_reply_page($redirurl, "error", gettext("Internal error"));
	echo gettext("Internal error");
	ob_flush();
	return;
}

mcconju

Looking through the config file and everything seems correct as with yours. Yet the errors keeps coming. It's still happening...

Gertjan

@mcconju said in Issues After Update from 24.03 to 24.11:

the errors keeps

What errors ?
Can you show them ?
The same as shown above ?

The bug that has been found in this thread is probably already years old.
Yet, nobody was confronted with it.
And there is an obvious reason : a captive portal visitor :
Doesn't know that he is using a portal ...
Should have an access method, like a voucher code that he bought upfront, or an access code + password that he found in the hotel room. They connect to the known SSID.
And that's it : the login page will show up, and the portal user now sees why he held a voucher code in other other hand.

Nobody has to type in a 'URL' to access the portal.
Which means that nobody can make errors during manual typing of the portal login page access URL. As this is never needed.

And that's why the issue never popped up before.
The admin make the portal work, and that's it.

if you need to test the login page : click here :

Anyway, the fault has been located.
The fault has been located.
3 options now:
Do nothing, and don't type bad URLS, and you'll be fine. A future upgrade will handle the issue.
Do what I've shown above.
if there is a third option needed : tell me all about it.

Cornel

@Gertjan said in Issues After Update from 24.03 to 24.11:

@Cornel

It took me a while, but the issue was hiding in plain sight.

Thx - glad we now fully understand what was happening.