Has anyone been able to get CP working flawless on iOS and Mac devices?

sbb

Test it again.

But this time, before pressing login a second time, check the captive portal sessions and see if the session was actually logged on. It looks to me like it will be. So instead of just pressing login a second time, bring up a web browser and try a site instead.

This is not a fix, but will confirm you're not dealing with a captive portal login problem but a site redirection problem instead.

Yeah same like Gertjan said. I am logged in after the first time cklicking the submit button. I can visit other sites, so it's a redirect problem.

@Derelict:

The device capture you sent shows a redirect to htv-tennis.de.

The pfSense capture you sent shows a redirect to spiegel.de

Why are they different?

I visited different sites when capturing the IP adress of the device and the ip adress of the pfsense machine.

@Derelict:

I think the device capture is the only one necessary. Set the count to zero and capture the entire session. Turn off wi-fi on the device, delete the portal session if any, turn on capture, then turn on the device wi-fi. Don't stop the capture until the actual destination page at least starts to load.

Here is a new caputure: http://www.file-upload.net/download-11630451/packetcapture.cap.html

skron

Please excuse if this is way off, but: do you see blocked packets in the firewall log (dropped by the default rule)?
Then it might be somehow the same as this: https://forum.pfsense.org/index.php?topic=111964

Because it would match the general setup - first opened page (that will get redirected) is same as after auth (that should go through), because it is both times the captive portal detection from Apple. If the connection is dropped, it seems like you have not authenticated - the second click on the login button builds a new connection, which will go through (as will any other new connection).

sbb

@skron:

Please excuse if this is way off, but: do you see blocked packets in the firewall log (dropped by the default rule)?
Then it might be somehow the same as this: https://forum.pfsense.org/index.php?topic=111964

Because it would match the general setup - first opened page (that will get redirected) is same as after auth (that should go through), because it is both times the captive portal detection from Apple. If the connection is dropped, it seems like you have not authenticated - the second click on the login button builds a new connection, which will go through (as will any other new connection).

yeah you could be right. I dunno how to export the firewall log. I tried to wait a longer time after clicking the submit button and I did get redirected. So exactly what you described in the other thread. The problem is users don't wait such a long time. A work around could be that I also define a "After authentication Redirection URL".

Gertjan

Derelict nailed it.
https://forum.pfsense.org/index.php?topic=112594.msg627568#msg627568 is the solution.
No more "double click", after hitting the logging button, the "Succces" from captive.apple.com will show right away :D

Btw : It's NOT a firewall, issue - mine didn't change the last several years - its a web server (nginx) setup issue, in combination with iDevices.

Derelict will post more info soon.

sbb

@Gertjan:

Derelict nailed it.
https://forum.pfsense.org/index.php?topic=112594.msg627568#msg627568 is the solution.
No more "double click", after hitting the logging button, the "Succces" from captive.apple.com will show right away :D

Btw : It's NOT a firewall, issue - mine didn't change the last several years - its a web server (nginx) setup issue, in combination with iDevices.

Derelict will post more info soon.

I did change keepalive_timeout to 0 also but it didn't work for me. Maybe I am doing something wrong

edit: works now! I killed the captiveportal.pid again and that did it. But I am afraid every time you edit the captive portal page keepalive_timeout resets to "65". I think Derelict will clarify and write an instruction how to solve it (he pmed me that instruction)

Derelict

I'm pretty sure this will only happen if the initial URL attempted is the same as the redirect URL after authentication. Else a new TCP session will be established and the keepalive will be irrelevant.

https://redmine.pfsense.org/issues/6421

Gertjan

@Derelict:

I'm pretty sure this will only happen if the initial URL attempted is the same as the redirect URL after authentication….

I do not redirect, leaving it up to the initial http request where the visitor goes after authentication.

redir.png_thumb

skron

@Derelict:

I'm pretty sure this will only happen if the initial URL attempted is the same as the redirect URL after authentication. Else a new TCP session will be established and the keepalive will be irrelevant.

https://redmine.pfsense.org/issues/6421

Yes, that would explain both issues - the one here, and the one in the linked thread.

In case of the iOS/mac devices, it is the device itself opening the the same URL before/after auth (for CP detection) with the initial request.

Thanks for looking into and opening a new bug on this!

kabrutus

Wow this page had grown some legs since Friday. Can someone send me the info on how to fix the issue? Where would i make this edit?

I wonder what keepalive_timeout 0 in he portal's nginx.conf file would do here.

Thanks for all your help. :)

Gertjan

@kabrutus:

….
Can someone send me the info on how to fix the issue? Where would i make this edit?

I wonder what keepalive_timeout 0 in he portal's nginx.conf file would do here.

Its not a secret, I can make it public:

If you are in a position to change keepalive_timeout from 65 to 0 in the nginx config for the captive portal and kill -HUP that instance of nginx in the shell and test again I think that will fix this.

It's in /var/etc/nginx-zone_name-CaptivePortal.conf

( and if you have a https portal running, change also /var/etc/nginx-zone_name-CaptivePortal-SSL.conf )

zone_name is of cours your Captive portal zone name.
More then ONE zone can exist !

Open a SSH connection.
Open the file(s).
Look for keepalive_timeout 65
Change it to keepalive_timeout 5
Save file (s)
Now, determine the "ningx" processes with :
ps ax | grep

This will return something like:

[2.3.1-RELEASE][admin@pfsense.brit-hotel-fumel.net]/root: ps ax | grep "/nginx"
 6018  -  Is       0:00.00 nginx: master process /usr/local/sbin/nginx -c /var/etc/nginx-webConfigurator.conf (nginx)
 7174  -  Is       0:00.01 nginx: master process /usr/local/sbin/nginx -c /var/etc/nginx-cpzone1-CaptivePortal.conf (nginx)
 8681  -  Is       0:00.01 nginx: master process /usr/local/sbin/nginx -c /var/etc/nginx-cpzone1-CaptivePortal-SSL.conf (nginx)
29823  1  S+       0:00.00 grep /nginx

(Note : again, I have also the https portal running, so I have a " /var/etc/nginx-zone_name-CaptivePortal-SSL.conf " instance.
My case informs me that process 7174 and 8681 needs to be restart (from here, the SSH access, NOT by the GUI !!)

kill -HUP 7171
kill -HUP 8681

Done.

IF - and only IF - you want to make this more permanent (until the next update / upgrade)
and
Some PHP editing doesn't scare you
AND
You are able to help-and-repair yourself if you messed up and you know that this is heavy beta, thus side effects aren't know ….
AND
You accept that with your modified pfSense core code you can't ask for help here (no need to explain, right ?)

THEN

edit /etc/inc/system.inc
and look for "keepalive_timeout"

BE CAREFUL : this PHP code is used to start the GUI web server AND the Captive portal server(s).

I edited mine like this:

....
	sendfile        on;

	access_log      syslog:server=unix:/var/run/log,facility=local5 combined;

EOD;

	if ($captive_portal !== false) {
		$nginx_config .= "\tlimit_conn_zone \$binary_remote_addr zone=addr:10m;\n";
		$nginx_config .= "\tkeepalive_timeout 5;\n";
	}
	else
	{
		$nginx_config .= "\tkeepalive_timeout 65;\n";
	}

        if ($cert <> "" and $key <> "") {
.....

(NO, I'm not posting a 'diff' :) and yes, the code is very easy to understand for those with some PHP knowledge).

I decided to edit /etc/inc/system.inc because the web server(s) config file(s) are regenerated every time they start or get restarted (for example when pfSense reboots).

If doubt, wait for the update ;)

PS : Derelict proposed a
keepalive_timeout 0
but I used a
keepalive_timeout 5

Because "0" is zero (which is extremely short and close to nothing) and "5" is just a little bit lesser as "65" and …..... "5" worked for me :)

kabrutus

Awesome! Thanks guys!

Derelict

It will be keepalive_timeout 0 in 2.3.1_2.

https://redmine.pfsense.org/issues/6421