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. :)
> > 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
> 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
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 ?
> (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.
Yes, I agree. This *would* really be a handy feature.
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/
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.