[ previous ] [ next ] [ threads ]
 
 From:  Dana Spiegel <dana at sociableDESIGN dot com>
 To:  "Michael Mee" <mm2001 at pobox dot com>
 Cc:  <m0n0wall at lists dot m0n0 dot ch>
 Subject:  Re: [m0n0wall] Re: captive portal support
 Date:  Wed, 21 Jan 2004 16:42:52 -0500
Thanks for taking the first step Mike!

I'll update this with best-practices information, hopefully this 
weekend.

I'd also like to start designing what the pages will look like through 
the m0n0wall interface (meaning what can be adjusted, and how).

Also, there are some captive portal solutions out there for BSD, which 
I'll attempt to identify and highlight for people.


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