On Tue, 2004-05-11 at 02:05, Manuel Kasper wrote:
> (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! ;)

Whaddya mean stereotypes?  I thought all Swiss did this?  :)

> > 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. :)

You rock.

> > 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.

Great.  Will make this many more usables.

> > 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
> authentication.

Sounds sensible.

> 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
> etc.).

Sounds like you are enjoying this feature of m0n0wall.  :)

> 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 ?
> 
> http://m0n0.ch/wall/downloads/mini_httpd.c.patch
> (against mini_httpd 1.19)
> 
> http://m0n0.ch/wall/downloads/minicron.c
> 
> >> - 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.

Yes, I agree.  This *would* really be a handy feature.

-- 

Regards,

Hilton Travis                   Phone: +61-(0)7-3343-3889
Manager, Quark AudioVisual      Phone: +61-(0)419-792-394
         Quark Computers         http://www.QuarkAV.com/
(Brisbane, Australia)            http://www.QuarkAV.net/

Open Source Projects:		http://www.ares-desktop.org/
				http://www.mamboband.org/

Non Linear Video Editing Solutions & Digital Audio Workstations
 Network Administration, SmoothWall Firewalls, NOD32 AntiVirus
  Conference and Seminar AudioVisual Production and Recording

War doesn't determine who is right. War determines who is left.