[ previous ] [ next ] [ threads ]
 
 From:  Dinesh Nair <dinesh at alphaque dot com>
 To:  Manuel Kasper <mk at neon1 dot net>
 Cc:  m0n0wall dash dev at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall-dev] Captive portal support!
 Date:  Tue, 11 May 2004 01:09:35 +0800 (MYT)
On Mon, 10 May 2004, Manuel Kasper wrote:

> On 09.05.2004 22:41 -0400, Jason Grimm wrote:
>
> > I've seen this in commercial products.  A button called 'pass
> > thru' takes
> > you to a simple, multiple entry form to put in your 'pass thru'
> > MACs.  It calls up the MACs already setup for pass-thru and allows
> > you to add more. In the two instances I've used it the client
>
> Yep, I'll add that soon.

i'm pleased to announce that i've added pass thru macs in already. see
attached .tgz file with patches.

the tar file contains five patches to the following files:

etc/inc/captiveportal.inc
etc/inc/xmlparse.inc
usr/local/captiveportal/index.php
usr/local/www/services_captiveportal.php
usr/local/www/guiconfig.inc

(apply these patches while sitting at the root of the mounted mfsroot)

and two new files:

usr/local/www/services_captiveportal_mac.php
usr/local/www/services_captiveportal_mac_edit.php

(copy these two files into usr/local/www/ and make them executable by all)

this adds the Pass thru MAC functionality to the Captive Portal
introduced in 1.1b7 and since it's all in PHP, it should work on all
images once manuel integrates it into his codebase.

in essence, this is what it does:

/usr/local/captiveportal/index.php (which is what the mini_httpd redirects
captive connections to) checks to see if the incoming mac address is a
passthru mac previously saved. if it is, it generates the necessary rules
and allows the connection thru. the user will not be taken to the captive
portal html page at all. if it isn't a pass thru mac, then the user is
redirected to the captive portal html page.

once that is done, pruning of old addresses happens normally, i.e. a pass
thru mac _will_ be pruned when the captive portal timeout happens.
however, preventing passthru macs from being pruned is trivial. i did not
do this because of dhcp lease renewals. as the ipfw rules depend on the ip
address of the connecting host, not pruning the passthru macs may leave a
mac bound to a stale ip address it no longer carries. what do you guys
think about this ?

services_captiveportal_mac.php and services_captiveportal_mac_edit.php are
responsible for bookkeeping on the pass thru mac table. it's stored in the
config.xml under the repeating element <passthrumac> which itself contains
two elements, <mac> and <descr> which are self explanatory.

i've also changed services_captiveportal.php to add a tabbed menu to
access the above two scripts. xmlparse.inc was changed to add the
passthrumac xml element as a listarg.

interestingly, when i was editting guiconfig.inc, i noticed that the $g
global variable was not visible when the $d_XXXdirty_path variables are
being initialized because the require() directive which includes
globals.inc was happenning lower down. this resulted in all dirty_path
files being created in the / directory of the running m0n0wall
implementation instead of /var/run where it should. this wasnt a critical
bug, but fixing it was a good thing as well. this bug preexisted in the
1.1b7 release. the patch to guiconfig.inc also fixes this.

have fun, chaps.

Regards,                           /\_/\   "All dogs go to heaven."
dinesh at alphaque dot com                (0 0)    http://www.alphaque.com/
+==========================----oOO--(_)--OOo----==========================+
| for a in past present future; do                                        |
|   for b in clients employers associates relatives neighbours pets; do   |
|   echo "The opinions here in no way reflect the opinions of my $a $b."  |
| done; done                                                              |
+=========================================================================+