Date: Sat, 10 Jan 1998 11:11:56 -0600 (CST) From: Alex Nash <nash@mcs.net> To: shimon@simon-shapiro.org Cc: thyerm@camtech.net.au, current@freebsd.org, Studded@dal.net, kong@kkk.ml.org Subject: Re: Firewall in kernel? - Found it! Message-ID: <199801101711.LAA07393@nash.pr.mcs.net> In-Reply-To: <XFMail.980109215114.shimon@simon-shapiro.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 9 Jan, Simon Shapiro wrote:
> If this is a new kernel, then here is the explanation:
This is not the explanation for this particular problem, see #1 below.
> /usr/include/netinet/ip_fw.h has changed. That causes old /sbin/ipfw to
> fail.
make world rebuilds /usr/include before compiling /usr/src/sbin/ipfw,
so this should not be an issue.
> To make things more exciting, m,ake world also fails for the same reason.
> In /usr/src/lib/libalias/alias_db.c, it fails to compile because, in line
> 2062, it misses:
>
> #include <net/if.h>
This was unrelated to the ipfw interface change. This has to do with
the contents of the network include files being shuffled around.
> I guess, the idea that any header file change requires complete world and
> kernel compile and regression test prior to commit, is not as universally
> accepted as one may think.
We've seen three separate problems come to a head within the last few
days, I'll address two of them (and leave the other one for someone
else to explain):
1. rc.network checked for the presence of options IPFIREWALL by
invoking /sbin/ipfw and looking for a return value of 1. Anything
other than 1 was successful. I modified the return values of ipfw
(in an attempt to conform to sysexits(3)), but since I didn't
realize that rc.network was doing this, and my test situations
always had IPFIREWALL compiled into the kernel, I missed this.
Yes, I failed to test how my ipfw changes would break
things when IPFIREWALL was not in the kernel. Mea Culpa.
2. We had a cross commit (ok, it was separated by two days, but...).
I modified the ipfw interface on the 7th, and libalias was modified
to use ipfw (using the old interface) on the 9th. Result:
breakage. Even though both commits built and tested ok, this broke
because multiple developers were working in related areas. While
it could have been avoided in this case by the latter committer
performing a cvs update and discovering the breakage, there's
always a possibility (using our current development methodology)
of the cross commit occurring between the time that the update
takes place, and the time the source is committed.
Executive summary: We're all working for free towards a common goal,
let's not take people to task publically without knowing all the facts.
Alex
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801101711.LAA07393>