[ previous ] [ next ] [ threads ]
 From:  "Chris Buechler" <cbuechler at gmail dot com>
 Cc:  m0n0wall dash dev at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall-dev] $1000 prize for FreeBSD 6.1 port of m0n0wall
 Date:  Mon, 19 Jun 2006 20:45:23 -0400
On 6/19/06, Jonathan De Graeve <Jonathan dot De dot Graeve at imelda dot be> wrote:
> I also think that it would be fair to split a piece of the amount of
> money to the people who did the most of the job. (that's up to Manuel to
> decide offcourse)

I would agree this is fair.  Maybe split by lines of code in SVN, or
some other measure.  I doubt if this will end up being a solo project
(but who knows).

> We are very lucky having already some sort of 6.1 M0n0wall version
> called pfsense where the devs already learned a lot

This brings up another point....  What is m0n0wall 1.3 to be?  At this
point, with the description Manuel gave, you could take pfsense,
s/pfsense/m0n0wall/, change the colors, and almost be there.  Only
thing that wouldn't work at that point would be firmware upgrades, and
the image would be much too large to update current m0n0wall releases.

Here's my thought on what it should be, and some changes that'll be
necessary, IMO, for the initial 1.3 release.

1 - It should be on pf.  This gives us the option of CARP in the
future, and we already know IPFilter 4.x has at least some of the same
issues as IPF 3.x (broken MSS clamping being one of thsoe that's been
reported on this list).  From at least several hundred pfsense
installs if not more, we know pf on FreeBSD doesn't have the same
issues.  Also, we as a community have good connections with Max Laier,
who maintains the FreeBSD pf port.  If we've had any good connections
in the past with any IPFilter developers, I haven't heard of them.

2 - To supplement the new wireless drivers, we need more options and
capabilities on the wireless configuration page.  This should be very
easy to pull in from pfsense.  I'm running a WRAP with an Atheros card
and pfsense, and had a WPA AP up and running in literally 2 minutes
without really knowing what I was doing even.  :)  What pfsense has
works well, and has been well tested.

3 - IPsec changes - We have ipsec-tools, it's time to implement many
of the enterprise class capabilities that aren't available in the GUI
now.  I haven't looked into this at any great detail at this point,
but DPD, NAT-T, and Xauth should be considered must haves.

4 - Traffic shaper - What do we do here?  ALTQ is certainly a more
capable shaper than dummynet, but I believe there are some significant
limitations in the current pfsense implementation because it's very
difficult to wrap a GUI around.  I hope Scott can comment here.

One thing we need to be careful of is scope creep.  I'm strongly
against trying to implement every feature that pfsense has in the
initial 1.3 release.  No CARP, pfsync, or anything more than what I've
listed above should be attempted for the initial 1.3 release.

With hindsight being 20/20, I think pfsense would be better off right
now if the 1.0 release just got the basics done right - NAT,
firewalling, and the existing features that m0n0wall has.  Maybe even
yanking the traffic shaper completely for the 1.0 release (which would
have been done ages ago).  At that point, 1.1 could have added the
traffic shaper maybe, and 1.2 could have added CARP and pfsync.  (just
pulling potential scenarios out of the air)  Taking smaller steps like
that would have made it a lot easier to get to the point pfsense is at

First build a solid base, then expand upon that base.  pfsense 1.0, by
the time it's released, will have taken nearly two years.  Taking on a
small subset of the features it has likely would have gotten 1.0 done
in less than half that time (though there were other circumstances,
like FreeBSD issues that have since been resolved, that have held
things up as well).

m0n0wall now has the advantage of being able to import most of the
hard work from pfsense, so it shouldn't be extremely difficult or time
consuming to get the base features working.  But let's keep 1.3 pretty
basic, and then build off of that for future releases in the 1.3 line.

> PS there should be a 1.3 project coordinator, I'm willing todo that.

I vote for Jonathan to assume this role, as he's the most active
developer in the recent past.