[ previous ] [ next ] [ threads ]
 
 From:  Dana Spiegel <dana at sociableDESIGN dot com>
 To:  <m0n0wall at lists dot m0n0 dot ch> <m0n0wall at lists dot m0n0 dot ch> <m0n0wall at lists dot m0n0 dot ch>
 Cc:  Michael Mee <mm2001 at pobox dot com>
 Subject:  Re: captive portal support
 Date:  Fri, 6 Feb 2004 00:30:35 -0500
I have posted my notes on best practices for a wireless captive portal. 
There may be a little overlap with what is already posted (thanks 
Mike!), but this should fill many of the gaps of how to do this.

http://socalfreenet.org/book/view/58

Comments are welcome.


Director, NYCwireless
dana at nycwireless dot net
www.nycwireless.net

On Jan 21, 2004, at 4:20 PM, Michael Mee wrote:

> Let's get this captive support sub-project going.  I propose that we:
>
> 1) move this to the m0n0wall developer mailing list
>
> There the traffic is <10 msgs/wk and its more appropriate). You can
> subscribe at m0n0wall dash dev dash subscribe at lists dot m0n0 dot ch and email to
> m0n0wall dash dev dash subscribe at lists dot m0n0 dot ch.
>
> 2) identify key tasks/people
>
> 3) Get going!
>
> Here's my start on (2).  I've created a set of pages,
> http://socalfreenet.org/captivewall,
> which everyone should be able to edit (with registration) and/or add
> comments to (anonymously). Here's a copy of one of the pages,  m0n0wall
> Captive Portal Design (looks much better in html,
> http://socalfreenet.org/book/view/58).
>
> User Usage Flow:
> a new user gets physical connectivity to the network
> they issue a DHCP request and are assigned an IP address (all
> un-authenticated IP's are firewalled so they can only talk on the local
> segment)
> As soon as they open their browser they will be forced a local web 
> page (see
> below)
> this web page will have a "Continue" button which must be pressed by 
> the
> user to continue
> after they continue their IP is granted access through the firewall
>
> Open questions:
> once the user does 'continue' do they have access until their lease 
> expires?
> (Or when?)
> do we need to create a separate tracking mechanism or can we piggyback 
> on
> the IP lease mechanism? (which implies, possibly, that static IPs, or
> preassigned-by-MAC DHCP IPs are exempt?)
>
> Admin Tools
> per development criteria, the captive portal page will be stored in
> config.xml and edited directly in the GUI. I propose a simple page 
> where
> admins can specify all text on the admin page (to allow for 
> localization).
> Note that there is no provision for a graphic due to the config.xml
> restriction
> page heading
> preface text
> legal wording
> continue button text
>
> there should be a way to disconnect a given IP which means that
> there should be a way to view all IPs in use
> if we decide on a timeout separate from dhcp lease timeout, then we'll 
> need
> to prompt and gather that info
>
> Future Features
> We won't try and do everything in this release. Here are some things 
> we can
> do next:
> automatically add throttle rules for each new IP based on a global 
> default
>
> cheers, michael
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch