Captive portal problems

bardelot

The first problem should be fixed and for the second one a pull request exists.

Gertjan

The first problem should be fixed and for the second one a pull request exists.

The second issue has been handled here : https://github.com/bsdperimeter/pfsense/commit/f89afb4765f317a532cb71f3b3883e8f897cfebb

edit: might as well ignore this: 2.0.2 <> 2.1
re-edit: Tested - edited lines 75 and 77 for version 2.0.2 and resolved the missing '/' issue.

mdmogren

@freuter:

When I login I am still not allowed to use the network, but in captive portal status I am loged in.

I have the same issue. Hit login, just get the portal login page over and over. If I look at the status it shows I'm logged in to the captive portal. I've actually had this issue ongoing for several weeks now. Tried clean install. Using default settings and local authentication (username/password.)

Gertjan

Normally, you should have had the issue ;)
My post above points to the solution.

Enrica_CH

I have the same issue than user mdmogren. This issue isn't same than your description above.

The authentificated IP/MAC address isn't written to table 1 and 2 in ipfw. If i check "ipfw table all list" I can see the ip-address and MAC of authentificated client table 0 (zero). Therefore the filter ins't open and the redirected URL is redirected to login page again and so on.

Unfortunately I can't find the function "pfSense_ipfw_Tableaction". According to function portal_allow in captiveportal.inc the client should be entered in tables 1 and 2 what not happens.

bardelot

"pfSense_ipfw_Tableaction" is a function of the pfsense php module. Is there anything particular in the log? If not, can you add some logging before the "pfSense_ipfw_Tableaction" function to see what parameters are being used?

Enrica_CH

There is no log entry in syslog what could point to an error. There is also no error message during login.

I found out that C. Buechler has changed to function call in /etc/inc/captiveportal.inc on Dec 12 2012. see:

https://github.com/bsdperimeter/pfsense/commit/5d1105e686e959ec7958728eecf3be7c98db565f
Could it be that the order of parameters in function call is wrong?

Where can I find the code for this pfsense php module (folder, filename)?

bardelot

The parameter order is correct. It's zone, action, table, ip, mask, mac then pipe, but the zone is not used at the moment. You can find the source code in the pfsense-tools repo on github [1].

[1] https://github.com/bsdperimeter/pfsense-tools/blob/master/pfPorts/php53-pfSense-module/files/pfSense.c

Enrica_CH

Thanks for code. I can't fully understand it, especially how parameters are handed over. I see three parameters "&zone_len" and "&ip_len" and "&mac_len" but these aren't in function call. How are these set. I have seen that table no. zero is default value. It seems that the table number isn't handed over correctly and pfsense_ipfw_tableaction has used the default value.

I have no knowledge about debuging. So I can't help further. I hope somebody can solve this behaviour.

bardelot

Since the problem you're experiencing is different to the initial problem this thread was about you should actually create a new thread and choose a useful subject. If you're certain that it's a bug and not a configuration problem you can also create a bug report in redmine [1]. Just add a link here so that I get notified or I might miss the post.

The length parameters that you noticed are due to PHP's parameter parsing. A string is parsed into two variables (a char* and the length of the string) [2].

An easy option to start debugging would be to add a log_error call with the parameters that are passed to the pfSense_ipfw_Tableaction function. This would help to decide if the error is in the pfSense_ipfw_Tableaction function or before. Just add the following code line before the section with the pfSense_ipfw_Tableaction function call in "/etc/captiveportal.inc". e.g. right after "captiveportal_ipfw_set_context($cpzone);"

log_error(sprintf("zone: %s; ip: %s/%d; mac: %s; up: %d; down: %d", $cpzone, $clientip, $clientsn, $clientmac, $bw_up_pipeno, $bw_down_pipeno));

Btw: Are you using a zone name with special characters or so? Do you have the macfilter disabled? IPv6 enabled? 64bit OS?

[1] http://redmine.pfsense.org/
[2] http://svn.php.net/viewvc/php/php-src/trunk/README.PARAMETER_PARSING_API?view=markup

pinuche

@Erik_CH:

I have the same issue than user mdmogren. This issue isn't same than your description above.

The authentificated IP/MAC address isn't written to table 1 and 2 in ipfw. If i check "ipfw table all list" I can see the ip-address and MAC of authentificated client table 0 (zero). Therefore the filter ins't open and the redirected URL is redirected to login page again and so on.
…

I have the same problem than mdmogren and Erik_CH… Client authentificated but redirected to login page again and again.

bardelot

@pinuche:

I have the same problem than mdmogren and Erik_CH… Client authentificated but redirected to login page again and again.

There can be various reasons why the redirection is not working, you need to be more specific. e.g.

which snapshot are you using?
32bit or 64bit?
Does the problem only occur with certain browsers (e.g IE had once such a problem)
Does it happen for every website? http and https (if enabled)? Websites with and without a full path?
Are you using multiple captiveportal zones?
output of "ipfw table all list" after the user has logged in
describe your captiveportal config, e.g. using radius, nomacauth, etc..
…

Ideally you should create a new topic as the original problem of this topic has been resolved.

Enrica_CH

I will provide you all information this weekend or on monday. How can I split or migrate these forum entries in a new topic? BTW the topic name is still valid ("captive portal problem") but you are right, it's not the same issue. I'm sure it's a bug then i installed a complete new installation to test this behaviour. I describ it later because I have to go now. Thanks. erik

bardelot

@Erik_CH:

I will provide you all information this weekend or on monday. How can I split or migrate these forum entries in a new topic? BTW the topic name is still valid ("captive portal problem") but you are right, it's not the same issue. I'm sure it's a bug then i installed a complete new installation to test this behaviour. I describ it later because I have to go now. Thanks. erik

You cannot split the topic yourself, but you can simply copy the useful parts and add a link to the old posts for reference. I know it's not always easy to choose a good topic name but "captive portal problem" can just be anything. A better subject would probably be "Captive Portal does not redirect after successful login" or "Captive Portal does not write authorized IP and MAC to ipfw tables".

bardelot

@Erik_CH:
I made some changes to the pfSense php module that should fix the problem of the IP/MAC addresses being added to the wrong table on 64bit platforms. As the patch is not yet included in the current snapshot you have to manually replace the pfSense module. You can download the new module here [1] and replace the old one in "/usr/local/lib/php/20090626". Make sure the rights are set correctly "chmod 555 /usr/local/lib/php/20090626/pfSense.so" and execute "killall php" such that the correct module is loaded.

[1] http://www.twinsquared.ch/bcyrill/download/get/pfsense/pfSense.so (64bit only)

mdmogren

@bardelot:

@pinuche:

I have the same problem than mdmogren and Erik_CH… Client authentificated but redirected to login page again and again.

There can be various reasons why the redirection is not working, you need to be more specific. e.g.

which snapshot are you using?

32bit or 64bit?

Does the problem only occur with certain browsers (e.g IE had once such a problem)

Does it happen for every website? http and https (if enabled)? Websites with and without a full path?

Are you using multiple captiveportal zones?

output of "ipfw table all list" after the user has logged in

describe your captiveportal config, e.g. using radius, nomacauth, etc..
…

Ideally you should create a new topic as the original problem of this topic has been resolved.

-Tried lots of recent snapshots in the last month, but currently still have this issue on 2.1-BETA1 (amd64) built on Sat Jan 19 20:44:15 EST 2013
-64 bit
-Same issue with Chrome, FF, and IE
-Happens for every website - only using http. Tried lots of different URLs with/without full path
-Just 1 Captive Portal Zone
-Using Local Auth Only and all other settings default
-Here is the ipfw table all list after authenticating and captive portal status showing user logged in but the username shows "unauthenticated":

[2.1-BETA1][admin@pfsense.localdomain]/root(1): ipfw table all list
---table(0)---
192.168.1.100/32 mac a0:88:b4:54:63:48 2045 0 0

bardelot

@mdmogren:
Can you try the above pfSense module? I made some changes that should fix the problem.

pinuche

@bardelot:

@mdmogren:
Can you try the above pfSense module? I made some changes that should fix the problem.

I have the same config and the same symptom than mdmogren (last snapshot, 64bits, every browser, …) and I just tried this module : it works ! :)
Cool, thanks a lot !

Enrica_CH

That's it! With your patch my test instance is working correctly. Thank you bardelot.

bardelot

I'm happy to have solved that mystery. The patch has just been added to the repo, so it will be included in the new snapshots.