Captive portal problems

Gertjan · Jan 14, 2013, 11:57 PM

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

Enrica_CH · Jan 16, 2013, 2:03 PM

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 · Jan 16, 2013, 2:49 PM

"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 · Jan 17, 2013, 9:15 AM

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 · Jan 17, 2013, 10:44 AM

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 · Jan 17, 2013, 9:41 PM

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 · Jan 17, 2013, 10:37 PM

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 · Jan 18, 2013, 4:01 PM

@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 · Jan 18, 2013, 4:13 PM

@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 · Jan 18, 2013, 4:35 PM

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 · Jan 18, 2013, 5:33 PM

@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 · Jan 20, 2013, 2:41 PM

@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 · Jan 21, 2013, 5:53 AM

@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 · Jan 21, 2013, 8:17 AM

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

pinuche · Jan 21, 2013, 10:24 AM

@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 · Jan 21, 2013, 10:26 AM

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

bardelot · Jan 21, 2013, 11:01 AM

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.

mdmogren · Jan 22, 2013, 11:11 PM

@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.

Starting with which snapshot? Still broke in Jan 22

m4st3rc1p0 · Jan 31, 2013, 10:21 PM

had the same issue on 2.0.3 i try to gitsync to resolved the issue but its not working still looping on authentication page.

here's my built.

i386 pfsense 2.0.3

bardelot · Jan 31, 2013, 10:52 PM

@m4st3rc1p0:
The problem that was fixed here only appeared on the 64bit 2.1 snapshots and was due to the pfSense php module. On the 2.0.3 version the addition of IP addresses is not handled using the php module but the ipfw binary. So while the symptoms are similar the problems are different.

To get your problem sorted out quickly I suggest you create a new thread in the Captive Portal (2.0.3) board. To begin with exactly describe your setup and the problems you are experiencing. You may also want to add the output of the command "ipfw table all list" and "ipfw show" after a user tries to log in.