Captive portal broken?
-
i wonder if anyone is experiencing a non-working captive portal on the 21st march snapshot?
no matter how i configure it it just times out on the client machine waiting for the login page. -
i wonder if anyone is experiencing a non-working captive portal on the 21st march snapshot?
no matter how i configure it it just times out on the client machine waiting for the login page.I did on earlier snapshots. According to Bug 1700 in redmine, the problem was fixed just yesterday (after the 21 March snapshot) but I haven't had a chance to try with anything more recent.
Bruce.
-
Try the most recent snapshot (check the sticky, automated snapshot builds are back on) and it may work, at least for IPv4
-
Thanks. i had actually made a configuration error on my side and i was going to edit the post but forgot.
RADIUS NAS IP attribute – i selected the wrong one. ::)
-
I'm running```
$ uname -a
FreeBSD pfsense2.example.org 8.3-RC2 FreeBSD 8.3-RC2 #1: Fri Mar 23 20:46:25 EDT 2012 root@FreeBSD_8.3_pfSense_2.1.snaps.pfsense.org:/usr/obj./usr/pfSensesrc/src/sys/pfSense_SMP.8 i386
$Captive portal is working for me with username and password login but not with voucher login. I was running pfSense 2.0.1, saved the configuration file, did a fresh install of pfSense 2.1 from pfSense-memstick-2.1-DEVELOPMENT-i386-20120227-2026.img.gz, restored the configuration file and upgraded using pfSense-Full-Update-2.1-DEVELOPMENT-i386-20120323-1942.tgz. The voucher use history is completely gone (all previously used vouchers are marked as _ready_ rather than _used_ in _Status_ -> _Captive Portal_, click on _Voucher Rolls_ tab), a voucher reported as _good for 300 Minutes_ by _Test Vouchers_ is not considered as valid by the login page (I get asked to enter a new voucher code). -
ya but is it dependable? can i go live with it?
and this new concept of zones? how does that work?
-
If you're using the SSL login, it seems that pfsense 2.1-DEVEL up to and including today's build, produces a malformed redirection URL, missing the colon between the hostname and port number:
HTTP/1.1 302 Found
Expires: Wed, 28 Mar 2012 02:01:49 GMT
Expires: 0
Cache-Control: max-age=180000
Cache-Control: no-store, no-cache, must-revalidate
Cache-Control: post-check=0, pre-check=0
Pragma: no-cache
Connection: close
Location: https://hotspot.mydomain.tld8001/index.php?zone=cpzone&redirurl=http%3A%2F%2Fwww.cnn.com%2F
Content-type: text/html
Content-Length: 0
Date: Mon, 26 Mar 2012 00:01:49 GMT
Server: lighttpd/1.4.29where hotspot.mydomain.tld is my CP's fqdn
-
The problem with the malformed URL in the 302 redirect seems to have been fixed, however I've noticed several other CP issues:
-
Pass-through MAC doesn't seem to be work. I've checked that the CP adds the usual pair of "allow ip from any to any MAC xyz" ipfw rules at the top of the ipfw ruleset), yet the hotspot ssl login dialogue is still displayed.
-
On CP Vouchers page, clicking "save" at the bottom of the page (without having changed any fields) will delete existing voucher rolls.
Note: In webGUI, the CP Zone field is empty (I just moved my pfsense 2.0.1 config.xml into 2.1-DEVEL) and the redirect URL is index.php?zone=cpzone&redirurl=
-
-
Prompted by my own experience described in reply 4 and this report:
- On CP Vouchers page, clicking "save" at the bottom of the page (without having changed any fields) will delete existing voucher rolls.
I took a look at the current configuration file on the 2.1 box and noticed the following snippet:```
<roll><number>0</number>
<minutes>300</minutes>
<comment>Roll 0</comment>
<count>64</count>
<used><active></active></used></roll>while the saved 2.0.1 configuration file had the following:<roll><number>0</number> <minutes>300</minutes> <comment>Roll 0</comment> <count>64</count> <used>/v////7///8B</used> <active></active></roll>It looks like the used history has been lost from the configuration file. The "db" files are all only 1 byte long:``` $ ls -l /var/db/voucher_*used_*.db -rw-r--r-- 1 root wheel 1 Mar 24 22:10 /var/db/voucher_cpzone_used_0.db -rw-r--r-- 1 root wheel 1 Mar 24 22:10 /var/db/voucher_cpzone_used_1.db -rw-r--r-- 1 root wheel 1 Mar 24 22:10 /var/db/voucher_cpzone_used_2.db -rw-r--r-- 1 root wheel 1 Mar 24 22:10 /var/db/voucher_cpzone_used_3.db -rw-r--r-- 1 root wheel 1 Mar 24 22:10 /var/db/voucher_cpzone_used_4.db -rw-r--r-- 1 root wheel 1 Mar 24 22:10 /var/db/voucher_cpzone_used_5.db -rw-r--r-- 1 root wheel 1 Mar 24 22:10 /var/db/voucher_cpzone_used_6.db -rw-r--r-- 1 root wheel 1 Feb 29 09:36 /var/db/voucher_used_0.db -rw-r--r-- 1 root wheel 1 Feb 29 09:36 /var/db/voucher_used_1.db -rw-r--r-- 1 root wheel 1 Feb 29 09:36 /var/db/voucher_used_2.db -rw-r--r-- 1 root wheel 1 Feb 29 09:36 /var/db/voucher_used_3.db -rw-r--r-- 1 root wheel 1 Feb 29 09:36 /var/db/voucher_used_4.db -rw-r--r-- 1 root wheel 1 Feb 29 09:36 /var/db/voucher_used_5.db -rw-r--r-- 1 root wheel 1 Feb 29 09:36 /var/db/voucher_used_6.db $ od /var/db/voucher_used_0.db 0000000 000012 0000001 $ -
The problem with the malformed URL in the 302 redirect seems to have been fixed, however I've noticed several other CP issues:
- Pass-through MAC doesn't seem to be work. I've checked that the CP adds the usual pair of "allow ip from any to any MAC xyz" ipfw rules at the top of the ipfw ruleset), yet the hotspot ssl login dialogue is still displayed.
Quick feedback:
CP asks for a voucher code from MACs in the passthrough list, apparently due to "set 0" / "set 1" issue:
00002 204 63503 set 0 allow ip from any to any MAC aa:aa:aa:aa:aa:aa any
00003 173 20884 set 0 allow ip from any to any MAC any aa:aa:aa:aa:aa:aa
00004 0 0 set 0 allow ip from any to any MAC bb:bb:bb:bb:bb:bb any
00005 0 0 set 0 allow ip from any to any MAC any bb:bb:bb:bb:bb:bb
00006 0 0 set 0 allow ip from any to any MAC 00:ff:12:34:56:99 any
00007 0 0 set 0 allow ip from any to any MAC any 00:ff:12:34:56:99
65291 0 0 set 1 allow pfsync from any to any
65292 0 0 set 1 allow carp from any to any
65301 628 28888 set 1 allow ip from any to any layer2 mac-type 0x0806
65302 0 0 set 1 allow ip from any to any layer2 mac-type 0x888e
65303 0 0 set 1 allow ip from any to any layer2 mac-type 0x88c7
65304 0 0 set 1 allow ip from any to any layer2 mac-type 0x8863
65305 0 0 set 1 allow ip from any to any layer2 mac-type 0x8864
65307 0 0 set 1 deny ip from any to any layer2 not mac-type 0x0800
