[ previous ] [ next ] [ threads ]
 From:  Manuel Kasper <mk at neon1 dot net>
 To:  m0n0wall dash dev at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall-dev] Captive portal support!
 Date:  Mon, 10 May 2004 18:05:05 +0200
(I'm putting my comments on the individual replies all in one message)

On 10.05.2004 08:35 +1000, Hilton Travis wrote:

> Not good to hear you had a crap weekend, but its great to hear you
> made full use of it.  However, I thought you'd be out looking at
> watches, making cheese, or starting a bank.  :)

Oh those stereotypes! ;)

> Here's the problem.  As of 1.1b6, the DNS Forwarder will use the
> LAN IP on the OPT1 interface, resulting in broken DNS resolution on
> the OPT1 interface.  I emailed the <users> list about this but got

That has silently changed in 1.1b7 because I found it to be an
annoyance as well. :)

On 10.05.2004 02:42 +0200, Adam Nellemann wrote:

> I don't know if "real" portal admins need this, but for my home
> network it would be nice if I could allow certain hosts to access
> my WLAN without going through the portal. This way I would be able

See below...

> whatever?) But I'd like to have some kind of built-in
> authentication (which should of course be optional). I imagine a
> pair of user/password fields near the button on the portal page,
> and a corresponding list of users/passwords in the webGUI or
> something like that? Perhaps this could even be made in such a way,

I'd say RADIUS is a fairly standard solution to this problem. Keeping
too much account information on m0n0wall is neither efficient nor
secure, and besides, account databases for captive portals are likely
to change often anyway.

> re-login whenever the timeout-period has expired (if nothing else,
> it must be a pain to keep track of the per-host activity I must
> assume is necessary to implement an idle-timout scheme?) Still it

No, should be easy actually - see below too. :)

> on the portal page. Perhaps there could be a drop-down with a few
> placement options for this, such as Left, Right, Center or
> something like that? Or (going overboard) a marker could be used in
> the body HTML window, indicating the placement of the button (ie.
> the text [BUTTON] in the HTML window would be replaced by the
> actual button on the page).

What do you folks think about this suggestion? Require the user to
supply the complete HTML, with a special tag where the button is to
go? Then again, we could just leave out that special tag issue,
because the HTML for the button is actually pretty simple, and just
supply the button HTML code on the portal setup page for the user's
convenience. Definitely a more flexible solution (think about people
who want to CSS-style their buttons or use an image as a button...).

> Finally, are there any other changes since the previous beta? (Do
> you by any chance have a changelog for the beta versions somewhere
> on the m0n0wall site?)

No (except for the DHCP server's DNS forwarder assignment on optional
interfaces) and no. Change logs for beta versions are always posted
along with the announcement on the mailing list.

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.

> page hosted off of the device.  This page looks to radius for
> authentication and there are some tricky things going on behind the
> scenes that are too long, detailed, and off-topic to be described
> here.  I did google it however and found some quick resources
> (http://www.mavetju.org/download/php-radius-1.2.tar.gz).  Since this

Looks easy enough to implement. So the portal would have two modes
("open/AUP" mode and "closed/RADIUS" mode), and with the latter you
would specify a RADIUS server and a shared secret for the

On 09.05.2004 21:56 -0700, Michael Mee wrote:

> Like others, I'd like to see optional activity based time extension

I guess that could be done by getting the last-match timestamp from
the client's ipfw rule. I'll give it a go.

> and an exception table for pre-declared MACs (handy for servers

Good idea, too. Just a list of MAC addresses that are always
permitted access.

Another thing - I'll probably also implement a list of IP addresses
that can be accessed without authenticating (agreeing) to the portal.
This could be used for more elaborate portal pages (to host images

On 10.05.2004 12:59 +0800, Dinesh Nair wrote:

> manuel, are the sources to the mini_httpd and other C proggies you
> used archived anywhere ?

(against mini_httpd 1.19)


>> - If some day we can get a concurrency/connection limit in
>> mini_httpd, that would be nice (for some basic DoS protection).
> once again, i could hack this up with the mini_httpd.c if it's
> available.

That would be cool! It would also make the webGUI more resistant to
DoS. We'd need a way of limiting the number of concurrent
connections, by client IP address if possible.

- Manuel