[ previous ] [ next ] [ threads ]
 From:  Fred Wright <fw at well dot com>
 To:  m0n0wall dash dev at lists dot m0n0 dot ch
 Subject:  Source Patches
 Date:  Sat, 11 Sep 2004 00:19:19 -0700 (PDT)
On Sun, 5 Sep 2004, Jim Gifford wrote:

> Are the patches available from
> http://m0n0.ch/wall/downloads/kernel-patches.tgz safe for a
> non-m0n0wall system?

It depends on what you mean by "safe". :-)

I don't think any of them would do anything really nasty, but some may not
be appropriate.  In general, changes can be broken down into about four

1) Bug fixes.

2) Unequivocal improvements.

3) Changes for particular configurations.

4) Changes for particular preferences.

While #1 and #2 can be applied unconditionally, #3 and #4 shouldn't be.  I
believe the current collection of m0n0wall patches includes *some* things
that should really be conditional but aren't.  I.e. the "conditional" is
implemented by conditionally including the patch. :-)

On Sun, 5 Sep 2004, Jim Gifford wrote:

> However, I had some problems applying all the patches.  The patches in
> kernel-patches.tgz were these:
> clock.c.patch         ip_input.c.patch    ng_pptpgre.c.patch
> if_ethersubr.c.patch  ip_nat.c.patch.old  ng_pptpgre.c.patch2
> if_xl.c.patch        ip_output.c.patch   subr_diskslice.c.patch

Umm, that doesn't even look like the 4.10 patch set.

I ran into a number of problems with the 4.10 patches, which I sorted
out.  I didn't keep careful notes, but the problems included:

1) Being referenced to something other than the release version.

2) Missing the path to the file.

3) Having the wrong path to the file.

4) Having the wrong timestamp for the base file, even though the content
apparently matched.

And of course there's the usual problem of all the timestamps being local.

On Sat, 11 Sep 2004, Leonard E. Nielsen wrote:

> ipnatmss.patch is trying to patch a file mlf_ipl.c that does not exist. 
> Then it patches a file named mlfk_ipl.c that does exist and that patch 
> works. Is this an either/or type patch?

Sort of.  One is the for the userland version, and one is for the kernel
version.  Only the latter is actually used in m0n0wall.  The former
actually exists, but the patch has the wrong path for it.  The one for the
kernel actually lives in *both* paths, although the patch doesn't reflect

> ip_fil3.4.33-icmpcks-fix.diff and ip_state.c.patch fails. They also seem to 
> be modifying the ipfilter code.

Probably because you're using the IPFilter 3.4.31 code bundled with
FreeBSD 4.10, rather than the 3.4.33 version that m0n0wall uses.

Personally, I think before/after source files are a better way to
represent changes when the number of files involved isn't too large.  That
way everything is much clearer, and you can always make diffs in your
favorite format if you like.  The main downside is that it makes
"selective inclusion" difficult, but that should really be done by
preprocessor conditionals, anyway.

Here I have the sources organized in three layers:

1) .../FreeBSD/4.10/	has release sources exactly as they appear as
			loaded from the DVD to /usr/src

2) .../FreeBSD/upd4.10/	has "official updates" to that.  Currently this
			means just IPFilter 3.4.33

3) .../FreeBSD/pat4.10/	has m0n0wall's & my patches, with the original
			versions renamed to xxxx.orig

The idea is that by copying or union-mounting 3 over 2 over 1, you get the
proper sources.

#2 is essentially the files from the IPFilter 3.4.33 archive reorganized
into the FreeBSD directory layout.  As with the 3.4.31 distributed with
FreeBSD 4.10, the kernel modules appear in *both* /contrib/ipfilter *and*
/sys/contrib/netinet/ipfilter, but unlike the "official" version, the
latter copies haven't had the RCS IDs changed to say "FreeBSD".  There are
no .orig files in this set.

#3 includes the m0n0wall patches from the archive on the website, my IPsec
fixes that will probably be in the next m0n0wall beta, and a couple of
minor bootloader tweaks.  Note that for IPFilter changes, the .orig files
match the 3.4.33 (upd4.10) versions, not the 3.4.31 versions.

I've put archives of the latter two in my personal FTP area.  This has a
pretty limited bandwidth quota, so I'll have to take them down if there
are too many hits.  See:


If someone else wants to host these, let me know.

Note that I *believe* these sources to agree with Manuel's, but haven't
confirmed it.

> Is there an easier way to add the HZ=1000 option?

I sure hope you're using a fast processor with that setting. :-)

					Fred Wright