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.



  • @cylent:

    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.


  • Rebel Alliance Developer Netgate

    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
    $



  • 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.29

    where 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:

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

    2. 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:

    @dhatz:

    1. 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
    $  
    


  • @dhatz:

    The problem with the malformed URL in the 302 redirect seems to have been fixed, however I've noticed several other CP issues:

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


Log in to reply