Nice work, I'm running b6 now and can't wait to get the new beta on, I have
a good use for the portal support and am very interested in the development
of this feature.
Further comments in line below...
----- Original Message -----
From: "Adam Nellemann" <adam at nellemann dot nu>
Cc: <m0n0wall dash dev at lists dot m0n0 dot ch>
Sent: Sunday, May 09, 2004 8:42 PM
Subject: Re: [m0n0wall-dev] Captive portal support!
> Hi Manuel,
> As always I love to try out new features, even if I don't really have
> any use for them. So of course I installed the new beta and tried a
> simple portal setup. As I've come to expect, this new beta feature
> worked without a flaw. Great work once again, and in a single weekend too!
> Of course, it wouldn't be true to my nature if I hadn't a few remarks
> anyway, so here goes:
> 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 to use
> the WLAN myself, without the inconvinience of going through the
> portal, but still require my guests to use it (and thus also any
> "unwanted guests"). I can see at least two ways of do this: By
> allowing static DHCP mappings to bypass the portal, or by having a
> list on the portal page with "trusted" MAC addresses (or SSIDs or..?)
> But I wouldn't know if either is safe or smart?
>> 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 doesn't need to be handed a
static DHCP mapping or anything like that since this particular check is
only concerned with MAC and doesn't necessarily care where it got it's IP
> I know this feature is still in its infancy, and that the following
> can probably be done better with a stand-alone "portal server" (or
> 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, as to allow a
> stand-alone portal server to signal m0n0wall when to open or close a
> given host?
>> Currently, in the situation described above, we re-direct clients to a
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
security / auth feature is paramount on my list of requirements I would more
than willing to assist in developing, debugging, hosting the radius server
for testing, whatever needs to be done.
> There are probably good reasons why it is currently necessary to
> 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 would be nice
> if users didn't have to do this from time to time (especially since I
> must assume that a non-browser application, such as mail or ftp, will
> simply be disconnected with no "warning" or possibility of
>> This is another stock feature I've found in off-the-shelf products. It's
been a little bit of a headache, we've had to set the timeout fairly high,
long downloads still timeout however. If a timeout option is builtin I
would suggest some kind of keep alive mechanism to see whether the node is
still connected and if it is still passing traffic. Again, you get into DoS
issues here. Maybe you can make use of the rate limiting or traffic shaping
functionality to alarm on potential DoS attacks while maintaining constant
connectivity on what is deemed 'good' traffic. I don't know enough about
M0n0wall's use of these options to offer any real help. Sounds like a
handful, however, we're susceptible to DoS regardless, adding radius,
portal, rate-limiting etc. doesn't really change the threat, in fact it may
offer a solution or at least an alarm. Don't know??
> This is of course purely a matter of taste (and not of great
> importance), but I'd personally prefer to have the button centered 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).
>> Haven't looked at the new feature yet, but maybe a solution is that the
page that is served on :8000 is totally blank by default and can be left
open by the operator or admin of the device to paste in whatever they like?
That way you can put your login buttin wherever you want.
> Perhaps you could elaborate a little on your future plans (if any) for
> this feature. I for one would like to know where you plan to take
> this..? (Also it might prevent a lot of suggestions for features your
> already have planned or dismissed!)
> 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?)
> As always: Thanks for a great product, and for taking the time to
> making it even better!
>> No kidding, big thanks to the developers of M0n0wall; awesome project
that keeps getting better. I've been toying with probably 20 or so
distributions and projects over the last several months. I always keep two
CF cards for each platform; one with whatever code of the day I'm playing
with, and one with a stable build of M0n0wall. I always go back to the
M0n0wall CF to get any real use out of the device. Of all the testing I've
done I haven't seen a more agressive and active development team. Keep up
the great work.
> To unsubscribe, e-mail: m0n0wall dash dev dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash dev dash help at lists dot m0n0 dot ch