Date: Tue, 3 Aug 2004 12:56:17 -0400 From: Bill Moran <wmoran@potentialtech.com> To: Mark <admin@asarian-host.net> Cc: freebsd-questions@freebsd.org Subject: Re: One OR MORE of source and destination addresses? Message-ID: <20040803125617.06d9d0bd.wmoran@potentialtech.com> In-Reply-To: <200408031633.I73GXIBP038908@asarian-host.net> References: <20040803105731.197c7cd0.wmoran@potentialtech.com> <200408031601.I73G1NQE037756@asarian-host.net> <200408031633.I73GXIBP038908@asarian-host.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Mark <admin@asarian-host.net> wrote: > Mark wrote: > > > Bill Moran wrote: > > > >> How about using skipto instead of allow? Thus, if it passes the > >> first one, it can just skipto the next rule to be checked. i.e.: > >> > >> ipfw add 11 skipto 12 tcp from any to me 25 setup limit dst-addr 32 > >> ipfw add 12 allow tcp from any to me 25 setup limit src-addr 4 > >> > >> Thus, if rule 11 pases, it skips to rule 12. If it fails, it should > >> reject as always. The end result is that a packet _must_ pass both > >> rules to be allowed. > > > > I spoke too soon. :( It seems this sort of rules evokes a bug: > > > > http://lists.freebsd.org/pipermail/freebsd-ipfw/2004-April/001084.html > > > > My whole console is flooded with messages like these: > > > > "ipfw: install_state: entry already present, done" > > > > Is there a known patch? > > I just took a look at the code: > > if (q != NULL) { /* should never occur */ > if (last_log != time_second) { > last_log = time_second; > printf("ipfw: install_state: entry already present, done\n"); > } > return 0; > } > > What if I just hack the "printf ..." line out of there? Would that 'solve' > it? I know it's dirty; but would things still work? Theoretically, yes (note that I'm certainly no expert on this chunk of code) My reason for saying yes is: 1) The error seems to be that IPFW is trying to add the same stateful rule twice ... which means it _did_ get successfully added once. 2) When that condition occurs, the function returns 0. The comment at the top of the file states that the function returns 1 on failure, so it would appear that this condition is still considered successful. -- Bill Moran Potential Technologies http://www.potentialtech.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040803125617.06d9d0bd.wmoran>