Bug @ pfSense_ipfw_Tableaction

azurata

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

cmb

Under what circumstances do you get 0.0.0.0 there? Not seeing that.

azurata

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

amstramgram

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

I 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

eri--

This is an ipfw command issue and not a kernel issue.

That command issue will be fixed before 2.2 release.

azurata

@cmb please push the fix to ipfw from your pfsense snapshot.
@cmb:

Under what circumstances do you get 0.0.0.0 there? Not seeing that.

regards azurata

cmb

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.

cmb

ticket opened on this.
https://redmine.pfsense.org/issues/4002

amstramgram

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

rbgarga

I've pushed fixes today, please try next round of snapshots

amstramgram

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