Bug @ pfSense_ipfw_Tableaction
-
In the captiveportal.inc, function portal_allow(), when
if (!isset($config['captiveportal'][$cpzone]['nomacfilter'])) $_gb = @pfSense_ipfw_Tableaction($cpzoneid, IP_FW_TABLE_XADD, 1, $clientip, $clientsn, $clientmac, $bw_up_pipeno); else $_gb = @pfSense_ipfw_Tableaction($cpzoneid, IP_FW_TABLE_XADD, 1, $clientip, $clientsn, NULL, $bw_up_pipeno); if (!isset($config['captiveportal'][$cpzone]['nomacfilter'])) $_gb = @pfSense_ipfw_Tableaction($cpzoneid, IP_FW_TABLE_XADD, 2, $clientip, $clientsn, $clientmac, $bw_down_pipeno); else $_gb = @pfSense_ipfw_Tableaction($cpzoneid, IP_FW_TABLE_XADD, 2, $clientip, $clientsn, NULL, $bw_down_pipeno);
the variable $clientip will hold the client IP, but when passed to pfSense_ipfw_Tableaction it will not be used, instead the IP will allways be 0.0.0.0 in the ipfw table.
This function is at /usr/local/lib/php/20121212/pfSense.so
I can't find the source.regards azurata
-
Under what circumstances do you get 0.0.0.0 there? Not seeing that.
-
1. fresh snapshot amd64 install with pfSense-memstick-2.2-BETA-amd64-20141105-1226.img;
2. add user1 with captive portal login privilege;
3. enable captive portal on lan and wan;
4. try to open google.com and get redirected to the captive portal page and login as user1;
5. redirected to google.com;
6. check firewall table 1 and 2 with ipfw -x 2 table 1 list;ipfw -x 2 table 2 list;
7. the IP of user1 at ipfw tables will be 0.0.0.0;
8. kill user1
9. check firewall table 1 and 2 with ipfw -x 2 table 1 list;ipfw -x 2 table 2 list;
10. rule is still there and user is not redirected to the captive portal anymore.regards azurata
-
Hi,
I write just to support you azurata and say that i can reproduce this issue with FreeBSD 2.2 BETA 10.1-RC4-p1
I allow myself to point your previous topic about this problem
https://forum.pfsense.org/index.php?topic=81984.0I can add that i have test with and without authentication, with or without mac filter, with i386 and x64 distro.
If i flush table 1 et 2 after kill user, i can authenticate again but it disconnect all user and the issue stay the same.Regards
-
This is an ipfw command issue and not a kernel issue.
That command issue will be fixed before 2.2 release.
-
-
I have the same ipfw as the rest of you. I'll try the mentioned circumstance when I have a moment and make sure there's a bug ticket open with the exact specifics.
-
ticket opened on this.
https://redmine.pfsense.org/issues/4002 -
Hi,
Perhaps tickets #4001 and #4002 on redmine are linked all together.@Ermal thanks for patching #4002 but the trouble with #4001 is still there.
I've tried the last snapshot and it's better but an user who is disconnected from his session is blocked, and can't re-authenticate a second time.
With the last snapshot (Thu Nov 13 06:05:47 CST 2014 ) ipfw tables 1 and 2 are now populated correctly with ip and mac address (and not 0.0.0.0/32) but when i kill one user, his records stay in tables 1 and 2… and i need to flush manualy tables (and i kill all users... because i don't know how to flush only one ip/mac) to authenticate again.
regards
-
I've pushed fixes today, please try next round of snapshots
-
Hi,
I've tried this morning. (built on Thu Nov 13 22:13:57 CST 2014 )
It works (for me) like a charm.Thank you very much
Regards